日本史に残る巨大 IT プロジェクトから学べること『みずほ銀行システム統合 苦闘の19年史』
大規模 IT プロジェクトの成功事例と、大規模システム障害の失敗事例を合わせた一冊。読み手に応じ、さまざまな学びが得られる。
困難な状況で、プロジェクトを成功に導く教訓を学ぶこともできるし、史上最悪のシステム障害がどのように発生し、波及していったかを生々しく読めるし、二度と起こさないための再発防止策を具体的にピックアップすることもできる。
- 「東京スカイツリー7本」の ITプロジェクト
- なぜアズイズ（As-is）が問題なのか
- プロジェクト推進体制を強化する具体的な方法
- 2002年と2011年の大規模システム障害の顛末
- IT システムの赤の女王説
- 日経コンピュータの「演出」
1. 東京スカイツリー7本分
IT業界のサグラダファミリアと呼ばれてきた、みずほの勘定系システム「MINORI」が、2019.7月、ついに完成した。
- 4,000億円という巨費を投じて
- 富士通、日立製作所、日本IBM、NTTデータを筆頭に1,000社のSIerを巻き込み
- みずほ銀行、みずほコーポレート銀行、みずほ信託銀行のシステム要件を元に
- 8年の歳月をかけて要件定義・設計開発・テストを進め
- 足かけ2年、計6回システムを止めてデータ移行を行い
- みずほFGの400営業店の事務担当17,000人が利用する勘定系システムを作り上げた
東京スカイツリーで換算すると、7本建てられるというMINORI。その元となるのは以下の勘定系システムになる。
- みずほ銀行の勘定系システム「STEPS」
- みずほコーポレート銀行の「C-base」
- みずほ信託銀行「BEST」
この場合、普通なら「片寄せ」、つまりどれか一つのシステムに統合させることで、開発コストやリスクを下げようとする。ところが、旧システムから一切を引き継がず、一から作り直す完全な新規開発だったという。
当然、順風満帆で進まない。要件定義に難航し、2度のリリース延期を強いられ、体制の抜本的な見直しを行い、産みの苦しみを経てきた。終わらないプロジェクトに、「横浜駅・渋谷駅とどっちが先か」などとも揶揄されていた。
そこで、みずほFG（ファイナンシャルグループ）の人々は、どこに苦しみ、どんな工夫を積み重ね、どうやって課題を発見・克服していったか。
2. アズイズ（As-is）を殺せ
MINORIの要件定義は4年遅れたという。システムが担う機能面や求められる性能を明確にしていくフェーズなのだが、そもそも現状がどうなっているのかを掘り起こすのに難航したとある。
そこで徹底されたのは、「アズイズ（As-is）の全面禁止」だ。As-is とは、今の・現状の姿のこと。
もとは、現状の業務フローや手順書を洗い出すことを指す。そして To-be というあるべき姿と照らし合わせ、システムがどのような役割をはたすかを検討する。
しかし、「アズイズ」という言葉が独り歩きし、ユーザ部門が「現状のままで良い」「業務を変えずにシステムで効率化してくれ」という要求を押し付けるために使われるようになる。現在の業務をろくに調べもせず、「アズイズでよろしく」―――これを変えるため、アズイズを全面禁止にする。
代わりに、To-be をユーザ部門に考えさせる。
銀行業務を棚卸して、あるべき業務フローを描かせる。そうすることで、なぜその業務を行っているかを考え、全体の中での位置づけや、先行・後続業務の必要性も検討しはじめるようになったという。
「前からやってたから」「そう引き継がれたから」という発想から離れ、「そもそもその業務は何なのか」と考えさせるための、アズイズ禁止令なのだ。これ、CIOの命令だからできたものだと考える。強制力さえあれば、かなり有効な技だろう。
3. プロジェクト推進体制を強化する
それまで、各グループの情報システム部門がバラバラに動いていたという。
みずほFG、みずほ銀行、みずほコーポレート銀行のそれぞれに情報システム部門と企画部門があり、連携コストがかかっていたとある。これらを統合し、持ち株会社であるみずほFGに一本化させ、そこでシステム刷新を推進する体制に改めたという。
そして、みずほFGのCIOは、「みずほグループCIO」に就任し、システム担当役員、常務取締役を兼務し、さらに取締役副社長・副頭取まで兼務させる。
かつて、みずほFGのCIOは取締役会のメンバーではなかったという。つまり、情報戦略の最高責任者を一段低く見なしていたのだ。それを改め、CIOの立場をより重くし、経営トップの強いリーダーシップが発揮できるようにしたとある。
そして、実働部隊はみずほ情報総研となる。そのトップ「情報システムグループ長」はみずほFGの情報システム部門の兼任とし、権力を集める。その上で、情報総研のベテランをFGに出向させることで、「システムが分かる持ち株会社」を作り上げる。これまで、どれだけ冷遇されてきたかが惻隠されて泣けてくる。
他にも、様々な施策が紹介されている。
例えば、会社や部門間の利害を調整し、全体最適の視点で意思決定を下すためのタスクフォース＋事業部会の両輪体制や、ユーザ部門に上流工程支援ツールXupperを強制的に使わせるスルタンなやり方、移行管理システム「みずほ天眼システム」が解説されている。
特に、全てのコードを自動生成させることを徹底したのは驚いた。「超高速開発ツール」を採用し、コードに混ざる属人性を排除したという。しかも、「生成されたコードの手修正すら禁止」とある。処理の冗長化による性能問題が懸念されるが、そこもうまく乗り越えている。
巨大な組織を編成する方針から、開発体制や方式の作り方まで、こうした施策は、CIOか、CIOに近い人にとって参考になるだろう。これが、本書の前半だ。
4. 2002年と2011年の大規模システム障害
本書の後半では、みずほ銀行で起きた、2度の大規模システム障害を分析する。
まず、第一勧業、富士、日本興業の経営統合に伴うシステム統合において、2002年に発生したもの。
- 現場に丸投げされた統合方針の決定が紆余曲折し
- 結果、システム統合のスケジュール・統合作業が遅れに遅れ
- 予定していたシステム運用テストの開始がずれ込み
- ろくなテスト検証が果たされないまま開業が見切り発車され
- 開業初日からATMの障害が発生し、公共料金の自動引き落とし等の口座振替に遅延
- トラブル発生後も対応が遅れるなどで、振替の遅延が拡大、大混乱となった
次に、2011年、東日本大震災の義援金口座に振り込みが殺到したことがトリガーとなって引き起こされたもの。
- 2007年に口座の設定を誤っていたため
- 義援金の殺到を適切にさばけず異常終了を引き起こし
- その復旧に8時間かかり、38万件が積み残された
- それが翌日のオンライン起動に影響を及ぼし
- 二重振込、振替遅延、ATM一部停止を引き起こした
- さらに未処理データが雪だるま式に膨らむ悪循環に陥り
- 勘定系システムが強制終了することになり、全業務が停止した
最初は単なる業務エラーなのに、想定外が重なり、大規模障害へと被害が拡大してゆく。その様子は生々しく、読んでるこっちの胃が痛くなる。即辞表を叩きつけ、逃げ出したくなるようなエグい話が淡々と描かれている。
5. IT システムの赤の女王説
前任者の不手際による障害について、詰められたことはないだろうか？
わたしはある。前任者が誰であれ、現在が自分の担当なのだから、詰問にも耐えるし火消しにも努力を惜しまない。
だが、その前任者が何代も前の人で、ひょっとすると自分が入社する以前に設計されたことが、時代の移り変わりとともに、利用状況に合わなくなり、不具合となって潜み、何かのきっかけに顕在化し、それが重なりシステム障害となる。
リスクが顕在化するまで、システム更改の必要性が挙げられては「予算がないから」と先送りされる。経営層の言い分は、「何も起きていないから」だが、その安定運用するために膨大なインシデントが人力で回避されているという現実は見ていない。
システムは、リリースしたその日から陳腐化が始まる。
目まぐるしく変わる環境変化に対し、「何も起きない」として安定稼働するため全力を尽くす。その様は、まるで「その場にとどまるためには、全力で走り続けなければならない」と言った、ルイス・キャロルの物語の女王のようだ。
6. 日経コンピュータの「演出」
2度にわたるシステム障害の経緯と原因、暫定対処と本格対処の分析は、圧巻だ。
特に、p.188の再発防止策の一覧は、ブラックボックスと化したレガシーシステムが引き起こす問題を乗り越えるための対策として、そのまま使えるだろう。
だが、随所で気になる点があった。日経コンピュータの面目躍如というか、よりセンセーショナルにしようという「演出」に引っ掛かったり、みずほFG社長のインタビューの編集が気になった。
もともと、複数の雑誌記事の寄せ集めのため、まとめると不具合に見えるものなのかもしれぬ。特に気になったことを2点、書いてみよう。
一つめ、2011年のシステム障害について。
最初のエラーは、3/14 AM10:16 に起きたものだが、内容は、義援金口座に振込が殺到し、一日に受け付けられる上限値を超えたという業務エラーだ。担当は別口座を設けて、そこを案内する対処を行った。
このエラーが、担当役員に伝わるのに17時間かかり、頭取に伝わるのに21時間かかったことを、「不手際」としている（p.161 重なった三十の不手際）。
もちろん甚大なシステム障害になったことは否定しないが、この業務エラーを伝えなかったことを、17時間ないし21時間の遅延にするのはさすがに酷だろう。
二つめ、社長インタビューにおける、COBOLの扱いについて。
勘定系システムを刷新し、新たなシステムMINORIを作り上げたことに胸を張る件で、「COBOLやFORTRANをベースにしたシステムをいつまでも使い続けるわけにはいかない」という発言がある。
COBOLって、よく「枯れている」といわれているが、古くて時代遅れという意味ではなく、不具合は出尽くしており、アーキテクチャーとして安定していると思う。
社長の言い分とは裏腹に、p.66 にある、MINORIの業務コンポーネントごとの開発言語一覧が明瞭だ。
様々なコンポーネントがあるが、MINORIの主要業務である「取引メイン」「為替取引」「顧客管理（CIF）」「流動性預金」「手数料」は、COBOLで書かれている。これは、もともとは日本IBMが1980年代に開発したミドルウェア「SAIL」を採用したためであると解説されている（p.44 十五年を経て復活したミドルウェア）。
これ、社長が知らないのなら問題だし、事実でないなら記事が問題だろう。別々のタイミングで掲載された記事を集める際、書き方を改めるべきだったのかもしれぬ。
いずれにせよ、学ぶところ、憤慨するところ、胃が痛くなるところ大の一冊なり。お薦めしなくても SIer な人は手にするだろうが、涙なしでは読めない一冊でもある。
| 固定リンク
コメント