客先常駐について - 急がば回れ、選ぶなら近道
客先常駐は増加傾向に見える。 別に統計資料はないので、どちらかというと体感的なものだけど、ベンダーからユーザーへの常駐は増加している気がする。これはまぁスタイルはいろいろで、完全に委任契約のものから、継続SIを仕事として請負契約の形になっているが作業的には客先にずっといるというスタイルのものをある。ベンダーの人員というよりも、ベンダーの下請け・孫請けが常駐していることが多い。さらに、多くの場合、戦力になっているのは、フロントの一次受けではなくて、下請け・孫請けの部隊だったりする。そんなこともあるので、地方の中小企業の場合は、さすがにフロントのサヤ抜きが、馬鹿馬鹿しいので、直接に契約に切り替えることも多い。 いずれしても、SIという位置づけのものまで含めると、この種の「派遣の一種」のような常駐モードの人員は相当いて、SEから運用・コンサルまでITに関わる分野では、非常に幅広くかつ大きなビジネ
クラウドのためのクラウド〜VMware Cloud on AWSの意味 - 急がば回れ、選ぶなら近道
記事とか詳細とかはこっち http://www.atmarkit.co.jp/ait/articles/1708/28/news097.html https://cloud.vmware.com/vmc-aws http://www.publickey1.jp/blog/17/vmwarevcloud_air.html まぁ概ねこんな感じ 単純に見れば、AWS上でVMWareが使えるので、VMで動いているシステムがそのままAWSで使えるようになりました。便利ですね。はい、おしまいの話ではある。が、それは二重の意味で「表層的」な見方だ。そもそもVMWareがクラウドから撤退し、AWSの軍門に降ったというエポックメイキングなものとして見るべきだと思う。 ・ハード調達の争いの決着 結局のところ、DCを含めたハードウェアの調達という点で、競争に決着がつきつつあるということかと。VMWareの規模を
Asakusaとメニーコア - 急がば回れ、選ぶなら近道
アドベントカレンダーのエントリーなんで、軽めに。 AsakusaはもともとHadoopでバッチ処理を開発・実行するためのフレームワークだ。これは別に今でもかわっていない。ただし、実行基盤は増えているし、推奨基盤も変わりつつある。現在のところの推奨基盤はバッチあたりで利用するデータ処理の規模が単ノードで完了するような場合はM3BPで、そうでない場合すなわち複数ノードにまたがるような場合は、Sparkを推奨している。これは僕らが経験した「すべてのワークロード」でSpark/M3BPがHadoopの特にMapreduceでの実行結果を凌駕しているためだ。AsakusaDSLはどのプラットフォームでも完全互換なので、コンパイルし直すだけでそのまま動く。MapreduceからSparkの移行は非常に簡単だ。ということで可能ならSpark/M3BPの方が速いので、そっち方がいいのではないでしょうか、と
ビットコインとブロックチェーンと分散合意 - 急がば回れ、選ぶなら近道
先日、分散システムをいろいろやっているメンバーで集まって、話題のブロックチェーンとかビットコインやらの勉強会をやってので、まとめておく。 いろいろ意見はあると思うけど、勉強会では問題意識は大体、共有できたと思う。まずは、キーノートやってもらったS社のMさんに感謝申し上げます。すごくわかりやすかった。やはり分散系をやっている人からの解説は、視点とか問題意識が同じなので参考になる。 以下、自分の個人的見解。合っているかどうかはシラン。 1. 現状の「ブロックチェーンとビットコイン」（以下オリジナルとする）は、そのままでは分散合意とは関係ない。 これはクリアだと思う。端的にいうとビザンチン将軍問題とは「まったく関係ない。」 だから「ブロックチェーンとビットコイン」がビザンチン将軍問題の解決になっているという話は、まずは「まとはずれ」だと思う。現状の「ブロックチェーンとビットコイン」は、分散合意は
RSA（Rack-Scale-Architecture) - 急がば回れ、選ぶなら近道
一応、Asakusaのアドベントカレンダーのネタです。 いろいろ今後のAsakusaの対応について、現状を踏まえて一回まとめます。 1.ビックデータの敗北 まず、現状のビックデータの現状はちゃんと踏まえておきたい。というのは、いままでの分散処理の技術革新は、クラウド・ビックデータ関連を中心で進んできたわけで、当然次の流れはその「歴史」を考慮しなければ、ビジネス的な先はないでしょう。 まず、経験的には日本での「ビックデータ」の実行基盤としての大規模クラスターの展開はほぼ全滅に近いと思います。特に、日本ではPByteを越えるデータはその辺に転がっているものではありません。もちろん何百台・何千台ものクラスターを構成・運用しているところもありますが、おそらく十指を越える程度でしょう。日本の企業数が5万としても、99.9%の企業はそんなクラスターは持っていません。ただし、企業数が多いので結果としての
Asakusa on Spark - 急がば回れ、選ぶなら近道
Asakusa on Spark AsakusaがSpark上で動くようになりました。 Asakusa on Spark (Developer Preview) — Asakusa Framework Developer Preview 0.2.2 documentation すでに実際に本番に利用しています。 ノーチラス・テクノロジーズがさくらインターネットにAsakusa Frameworkで開発した大規模データの高速処理基盤を導入し、顧客単位での精度の高い原価計算を実現高速処理基盤はApache Spark™で構築 | NAUTILUS OSSとしての公開を行いましたので、内容や位置づけをまとめておきます。例によってノーチラスは社内でいろんな意見は当然出ていますが、今回は概ね一致している感じです。 パフォーマンス 概ね「業務バッチ処理という観点で見れば、すべからくHadoopMapR
エンタープライズという言葉に意味はあるのか？ - 急がば回れ、選ぶなら近道
「エンタープライズ」という言葉 IT業界では、一応、「エンタープライズ」という言い方があります。残念ながら明確な定義がありません。自分は「一般企業の業務系システムのIT」に対応する言い方だと思っています。大抵はこの意味で通じます。が、これでは漠然としすぎていて定義としては役に立ちません。現実の用例としては、対比的に用いられることが多く、ありがちの用法としては、特にWeb系と対比して、よりしっかりやっているとか、より硬派な仕組みを作っているとか、よりまともな産業に属しているとか、そんなニュアンスで使われます。まぁ、特に品質あたりではよく言われる言葉ですね。「それエンタープライズじゃ通用しない。」マスコミや特に雑誌でよく使われる言葉でもあります。明確な定義があることはほぼありません。 さらに、よく聞く言い方で「エンタープライズでも使われてます」という言い方があります。特にWeb系での利用がメイ
2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道
というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減（または横ばい）というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ
システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
パトリオット法は日本のDCに適用されるのか？についてのメモ - 急がば回れ、選ぶなら近道
・Disclaimer自分は弁護士ではないし、その手の専門家ではありません。よってここに書いてあることを信じて、何かを行ってヤバい事になっても一切責任は負いませんし、それは自身の責任で処理してくださいね。まじめに会社の公式見解でもなければ、クラウドベンダーの代弁でもありません。 ・問題 自分の問題は以下、単純に「業務系システムを日本国内のDCのクラウドに上げている状態で、パトリオット法が適用された時に、そのクラウド上の業務系データが、一方的に米局政府に差し押さえられるということが起こりうるか？」という点につきます。 ・個人的な結論 結論から言うと、それは「ない」ですね。つまり、一方的かつ直接的に国内DCのデータが米国政府に押さえられることはないと思います。勿論、一定の要件を満たしたテロ等の嫌疑がある場合にはすべて正式の手続きに則った上で、米国当局の要請をうけて日本の司法がしかるべき手続きを
「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
"BigData"では何が問題なのか？ - 急がば回れ、選ぶなら近道
”ビッグデータで奇跡が起こる” はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。 従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基本的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。 とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある（と思う）。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の２点だ。 1 Webのログ解析 というか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
