Gartner Column：第43回 厳しすぎたみずほ銀行のレッスンから学ぶ
| 【国内記事】 | 2002.4.15 |
みずほ銀行のシステム障害については，既にかなりの報道がなされている。ここではバッシングするのではなく，このような過ちを繰り返さないためにどうすべきかを前向きに考えてみよう。
なお，このコラムの内容は，現時点における報道などから判断した私個人の見解であり，ガートナーとしての公式見解ではないことをお断りしておく。
メディア等で典型的に聞かれる議論として，旧3行間の勢力争いにより3種類の勘定系（いわゆる預金オンライン系）システムが残ってしまったこと自体が問題であるというものがある。しかし，これは，ポイントをはずした見方だろう。
一般的に言って，（順調に稼動している）既存システムをできるだけ残し，中継システムを介して相互にやり取りを行わせることで緩やかな統合を行わせるという方法自体は間違ったことではない。
もちろん，このようなやり方は最も効率的というわけではないし，業務レベルの完全な統合が達成されるわけではない。しかし，時間的な制約が大きい条件下では，あえて疎結合型の統合を行っておき，外部からはあたかもひとつのシステムであるかのように見せておいて，その後，時間をかけて本格的な統合を行うというのは現実的な選択肢である。
過去のシステムなど捨ててしまって，新規システムを一から構築すればよいではないかというのは，銀行オンラインシステムの複雑性を知らない人だけが言えることだ。
ガートナーでは，上記のような疎結合型の統合形態で使用される中継システムをインテグレーションブローカと呼んでおり，単なる間に合わせ的ソリューション以上の積極的な意味付けを行っている。インテグレーションブローカを使用することで，情報システムは変化に迅速に対応できる柔軟性を確保できるのである。経営環境が激変する中，効率性よりも柔軟性を重んじるのは決して間違った判断ではないだろう（特に，これは金融業界で当てはまることだ）。
実際，日米問わず，金融機関を中心とした多くの企業が，このようなインテグレーションブローカを使用した統合形式を使用している。そもそも，インテグレーションブローカの考え方自体は，アナリストやコンサルタントが机上で考案したものではなく，1980年代後半から1990年代初頭の再編期にあった米国の金融機関の情報システム部門が必要に迫られて採用したベストプラクティスなのである。
M&Aが頻繁に起こる環境下で，システムを完全に一体化する密結合型の統合を行っていては変化に対応しきれないがゆえに生まれたアーキテクチャなのだ。
問題は，このようなアーキテクチャにあるのではなく，その実装のやり方にあったというべきだろう。報道によれば，旧3行間の勢力争いにより意思決定が遅れ，実際の統合作業が開始されたのはかなり後になってからのことであったと言われている。また，昨年の夏頃よりスケジュールに無理があったことが判明していたのに，もともとのカットオーバー日付を死守するために，相当に無理なスケジュールを継続してしまったようだ。
一般に，ソフトウェア開発が遅延した時に開発を加速するために開発者を増員すると納期はますます遅れる。これは，ソフトウェア開発に関する大古典「人月の神話――狼人間を撃つ銀の弾はない」において述べられている。いわゆる「ブルックスの法則」である（もし，読者の方でこの本を読んでいない方がいらっしゃたらなら，是非一読しておくべきだろう。第33回で触れたワインバーグ氏の著作と共にITにおける基本中の基本書である）。
結果として，納期を死守するためにテストフェーズを圧縮するというソフトウェア開発では一番してはいけないことをしてしまったのではないだろうか？ そして，「開発者がテストケースを作ってはならない」「テストでうまくいかないことが，本番でうまくいくことはない」「テストデータはできるだけとんでもないエラーデータ（全件エラーなど）も用意すべきである」などのソフトウェア開発の基本がないがしろにされてしまったのではと私は想像している。
と，ここまで書いてきたような話は，ITの現場である程度経験をつんできた方（ましてや，銀行システムを担当されてきた方）なら周知のはずである（もし，そうでないとしたら，日本のエンジニアリング能力は私が考える以上の問題を抱えていることになる）。
どうやら，納期に間に合わない，また，無理に間に合わせようとすれば品質上のリスクが大きいという現場の声が最終的な意思決定者にエスカレートされる前に企業内の指揮系統のどこかで消えてしまっていた，ないし，意思決定者がエスカレートされてきた意見に耳を貸さなかったことが問題の根本的原因のように思える。
つまり、経営戦略とIT戦略を何か別のものとして扱っている点こそが問題といえるのではないだろうか？ 明らかに、（特に金融業においては）もはやITは業務プロセスを補助するだけの存在ではない、IT≒業務プロセスなのだ。つまり、ITは経営戦略の重要な一部になっていなければならない。
単に責任者を処分しただけではこの問題は解決しない。経営戦略とIT戦略の整合性を取ることこそが、このような過ちを繰り返さない唯一の方法である。
経営戦略とIT戦略の整合性（アラインメント）確保はこのコラムで扱うには大きすぎるトピックだが、不整合が発生していないかを知るための簡単な方法について述べておこう。企業の全社的な長中期戦略に関する文章をチェックしてみよう。もし、その中でITについて全く触れられていないとしたら、その企業では経営とITの整合性確保が十分できていない可能性があり、要注意と言っていいだろう。
[栗原 潔 ，ガートナージャパン]
