IBMの敗訴と巨大SIの終焉

NEFSSでの次期システム開発をめぐるIBMとスルガ銀行の裁判は７４億円の賠償を認める判決がでましたが、IBMは控訴したようです。正直勝ち目はないんじゃないかと思いますが、いずれにしても高裁で決着がつくことでしょう。
地方銀行のシステムすらパッケージで構築できないという日本の特殊性がよく話題になりますが、そもそもSaleforceが良く使われるようになったのはそのカスタマイズ性も一つの要因であるということも考えてみると、業務をシステムに合わせるというのは必ずしも正解というわけではないんじゃないかと思っています。なので、オーダーメイドなシステムは競争力、独自性という観点からは必要だし、ある一定以上のプロセス改善を進めると、必ず「標準的なプロセス」が対応できなくなる地点がやってきて、そこで諦めるかどうかが経営戦略レベルの決定になってきちゃったりしますよね。なので、最近は業務プロセスをパッケージ化したものではなく、プロセスルールを自動でシステム化するツールが流行り始めています。
この手のツールの売り文句はもちろん、「ユーザーの要件をそのままシステム化できる！」ですが、かつてCOBOLが「ユーザーが直接作れるからプログラマーは要らなくなる！」だったことを思うとそんなウマい話がないことは自明ですね。もっとも、とりあえず使えるレベルのものなら出来てしまう域には達し始めています。
でも、システムにとって結構大事なのは、トラブルなく動かし続けることができる、ということです。例えば、進捗管理ツールとか、資産管理システムとか、止まったら即業務に影響が出ないものについては、適当に作って適当に運用すればいいんだけど、在庫管理システムとか、勘定系システムはそうは行きませんよね。外部との連携もだいぶ標準化されつつあるものの、まだまだ独自のI/Fが沢山残っています。また、運用、管理がめんどくさいからこそクラウドは流行るわけですが…
さて、僕は相変わらず某巨大システム関連の仕事をしています。やればやるほど不毛な仕事だと思います。
システム再構築には「夢」があります。そして、その夢を実現するための「アイディア」がベンダーから提示されます。ざっとみて、その夢とアイディアは、絵空事ではありません。しかし、なんででしょう。設計が終わると暗澹たる気分になるのは。
もはや、ベンダーにもSIerにもそのちゃんとしたコンセプトを現実のシステムに落としこむだけの実力のある人はいません。また、発注者側もその既存の巨大システムと対立するコンセプトをトップダウンのプロジェクトして、きちんと推進出来るだけの人がいません。結果として、既存システムの無茶な要求に工数を食われ、バラバラの部署で分担している新システムの部署間調整に工数を取られ、障害の責任をどこに押し付けるかの調整に工数を取られ…はっきりいって、工数の４割は本来不要な工数ですよ。
工数だけの問題ならいいんですが、部署間の政治的な意図によって、担当者が全力を出しきれない（出すといろいろ押し付けられる）システムになっています。
巨大システムの問題は、ステークホルダーが多くなりすぎること、それをどんなにトップダウンで制御しようとしても結局責任を負わされるのが嫌な人が多いからうまく行かないことです。そんなユーザー側の空気をベンダーも読んでいて、できるだけ責任を被らないような動きをしています。いや、お前ら出したコンセプトを実現するために全力出さないと本当に絵に描いた餅になるよ？

ここで振り返ると、はじめの「夢」「システム化のアイディア」はたしかに正しいんです。正しいのですが、それに完全に沿ってシステム化が行われないと全く意味がないというか、むしろ害ばかり残ります。効率化したはずのところに大変非効率なドキュメントがついて回ったりします。いや、そのドキュメントなくすためにそういう形にしたのに！そういうルールを含めてきちんと整備できるベンダーの担当者もいない。旧態然とした客にきちんと立ち向かってルールを変えさせる（これは客のTOPはわかっているのだから本当はできる）ことをしない。結果として、アイディアを分割された各部署が思い思いのやり方で設計する。当然できたものは擦り合いません。

こういうのが、巨大なSIの現状。もはやシステムは自重で倒れるところに近づいています。

これを改善するにはどうしたらいいんでしょうね。SIerも作業が細分化した結果、グランドデザインが出来る人材が少なくなってきています。たしかに、個々の設計、実装をするにあたってはグランドデザインができなくてもいいという部分はあります。でも、隣の部署が作っているものときちんと整合性のとれたシステムとして設計できるかどうかは、そういう視点で見れる人が何人いるかにかかっていたりするんですよ？

結局、簡単なシステム開発（EOD）ってのは、あくまで開発のところであって、設計が簡単になるわけではありません（施工方法が標準化されても誰しもが建築士になれるわけではないのと一緒です）。巨大システムはもはやボトムアップでのみやってきた人の手に追える全体像じゃなくなってきています。でも人月商売の世界でシステム設計士の地位はそれほど高くないのが現状です。これには雇う側にも問題があって、いわゆる平均単価の世界に落とし込まれてしまうと、設計士に高待遇をすることが難しくなってしまいます。実態に即したまともな資格がないってのも問題かもしれません。

そろそろ巨大システム（当然Googleもfacebookも巨大ですが、ここでは従来型のホスト・サーバ群をイメージしています）を持つ事自体が企業の存続リスクになってくるのではないかと思っています。膨大なトランザクション量、膨大な保有データ量があることによって巨大システムでなくてはならないというのは幻想になりつつあります（もっとも、例えばgoogleやfacebookが如何に技術力があろうが勘定系システムのトランザクションと考えた時に同じようにさくっと実現できるかというとそうではないと思いますが）。

もはやクラウドはバズワードではなく、また次にその地位を占めるのはビッグデータでしょう。でもビッグデータってなにそれって感じですよね。現場では。確かにどちらかというとBI方面に近いところが中心なんですけど、そのデータ処理技術は既存のデータの持ち方を変える大きな変革です。巨大システムの巨大さと、それに伴って発生しているシステム（あるいは処理）間の密結合を一気に変えることができる可能性を感じています。ぶっちゃけ巨大システムなんてオンラインの負荷さえ何とかしてしまえば、あとは如何にバッチ処理を間に合わせるかであって、速さを実現するために急いでやるための無理矢理な連携とか、ありえないほど発生する中間データとか、毎日用意する集計結果とかが全部要らなくなって、適当にデータ貯めとけばよくなったら何もかも楽チンですよ。正規化も要らなければなおさら。

基盤的にはダウンサイジングじゃありません。でも、業務処理という観点から見るともはや既存のやり方は限界ですが、まったく違うパラダイムの導入で巨大システムからの脱却を図ることができると思っています。ただ、例えばHadoopであればノードの絶え間なく続く故障に対応する運用をしなければなりません。でも、今の巨大システムって壊れない前提で壊れたらベンダー呼んで対応して障害報告して…こういう運用まで変えられないと対応できませんよね。

巨大システムが巨大システムのまま死ぬのか、それとも新たな形に脱皮できるのか、決断をできる企業とできない企業で明暗をわけるのがあと３年以内のタイミングなんじゃないかと思います。