大規模 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に近い人にとって参考になるだろう。これが、本書の前半だ。
