35万人月MINORIの開発『みずほ銀行システム統合、苦闘の19年史』を読んだ

35万人月、4千億円をかけたみずほ銀行システム統合プロジェクト「MINORI」完成までを描いた『みずほ銀行システム統合、苦闘の19年史』を読みました。

みずほ銀行システム統合、苦闘の19年史　
史上最大のITプロジェクト「3度目の正直」
(日経コンピュータ)

Amazon

楽天

Yahoo!

サトナカ (@souiunogaii)

この記事を書いている私は、某SIerに勤務しながら、
WEB系エンジニア・インフラエンジニアに憧れて、プログラミングおよびインフラ技術の勉強をしています。

こういった私が、この本を読んでの感想を書きます。

『みずほ銀行システム統合、苦闘の19年史』のもくじ

この本は、大きく三部構成になっていました。

新しい勘定系システム「MINORI」の開発プロジェクト
2011年3月の震災直後の大規模障害
2002年4月の経営統合直後の大規模障害

第一部　IT業界のサグラダファミリア、ついに完成す

第１章　三十五万人月、四千億円半ば、巨大プロジェクトはこうして始まった
第２章　さらば八〇年代、新システム「MINORI」の全貌
第３章　参加ベンダー千社、驚愕のプロジェクト管理
第４章　緊張と重圧、一年がかりのシステム移行
第５章　次の課題はデジタル変革
第６章　「進退を賭けて指揮した」[みずほフィナンシャルグループ　坂井辰史社長インタビュー]

第二部　震災直後、「またか」の大規模障害

第７章　検証、混迷の十日間
第８章　重なった三十の不手際
第９章　一年をかけた再発防止策

第三部　合併直後、「まさか」の大規模障害

第１０章　現場任せが諸悪の根源
第１１章　無理なシステム統合計画を立案
第１２章　大混乱の二〇〇二年四月

ついに完成した「IT業界のサグラダファミリア」、その裏側に迫る

みずほフィナンシャルグループ（FG）が2011年から進めてきた「勘定系システム」の刷新・統合プロジェクトが2019年7月、ついに完了した。
富士通、日立製作所、日本IBM、NTTデータを筆頭に1000社ものシステムインテグレーターが参加したものの、2度にわたって開発完了が延期になったことから、なかなか完成しないスペイン・バルセロナの教会にちなんで「IT業界のサグラダファミリア」とまで呼ばれた史上最大級のITプロジェクトだ。みずほFGは完了までに8年もの年月と、35万人月、4000億円台半ばをつぎ込んだ。
1980年代に稼働した「第3次オンラインシステム」の全面刷新は、第一勧業銀行、富士銀行、日本興業銀行の3行が統合したみずほFGにとって、2000年の発足以来の悲願だった。
しかしシステム刷新は何度も挫折し、2002年と2011年には大規模なシステム障害を引き起こした。80年代の非効率的な事務フローが残ったままになるなど、勘定系システムの老朽化は経営の足かせになっていた。
なぜみずほ銀行のシステム刷新は、これほどまでに長引いたのか。そして今回はどうやって完了に導いたのか。「メガバンクの勘定系システムとして初となるSOA（サービス指向アーキテクチャー）全面導入」「AS IS（現状通り）を禁止した要件定義」「1000社のシステムインテグレーターを巻き込んだプロジェクト管理」など、新勘定系システム「MINORI」開発の全貌と、みずほ銀行がこれから目指す金融デジタル化戦略を、みずほFGにおける19年の苦闘の歴史を追いかけ続けた情報システム専門誌「日経コンピュータ」が解き明かす。
多くの日本企業が直面する情報システムの老朽化問題、「2025年の崖」を乗り越えるヒントがここにある。
引用元：日経ブックナビ『みずほ銀行システム統合、苦闘の19年史　史上最大のITプロジェクト「3度目の正直」』内容紹介

『みずほ銀行システム統合、苦闘の19年史』を読んでの感想

とにかく「お疲れさまでした」の思い

プロジェクトに関わった方々には、とにかく「お疲れさまでした」の思い。そして、今後のみずほのシステムの開発・保守を続ける方がへ、「引き続き頑張ってください」の気持ち。

私自身は、別にみずほ銀行に口座を持ってはおらず、仕事でも、みずほ銀行のシステム開発にも一切関係が無いので、
まったくの外部の第三者という目線で、この本を読ませてもらったのですが、
それでも、SIer勤務のサラリーマンとしては、
現場の開発者やユーザーの方々の数々の苦難を想像すると、
とにかく「お疲れさまでした」という思いを強く感じました。

実際の画面や写真もあり、図や表も分かりやすくて、部外者が読んでも、すんなり内容を理解できる書き方になっていますし、
企業名も登場人物名も、実際の名前で書かれているので、当時のリアルな状況が伝わってきました。

システム開発に携わる人なら読んでおいて損は無い一冊

旧システムが抱えていた課題と、新システムでの強み、導入時の研修や、移行時のポイントなど、
システム開発に携わる人なら、何かしら勉強になる点がたくさんちりばめられていて、
読んでおいて損は無い一冊だと思います。

実務を担うみずほIRの司令塔があった中目黒の拠点は、天眼システムを100インチほどの大型ディスプレーに表示していた。みずほIRの池谷俊通常務は「昔はチェックポイントの一覧表を拡大コピーして、作業が終わるたびに色を塗っていた。今回はそんなやり方で済むレベルではなかった」と話す。
（中略）
さらに、事前の訓練も繰り返した。まずはみずほIRの横断組織のメンバーらが主要四ベンダーなどに出向いて障害事例や対応策を聞き、その上で訓練プランをつくった。
（中略）
最終段階には十個の障害が同時に発生した場合の対応まで訓練したという。

2011年3月と2002年4月の二度の大規模システム障害の発生原因から現場でのリカバリ完了までのリアルな描写

第二部では、2011年3月の震災の義援金振込をきっかけにした大規模システム障害が、
第三部では、2002年4月の統合直後の大規模システム障害の様子が、
これまた、リアルに描かれています。

まったくの外部の第三者が読んでも、当時の現場でのシステム担当者の方々や、営業店での行員の方々の対応、
の様子が結構、細かくドラマのように書かれていて、当時の緊迫感が伝わってきました。

通常の要因では足りないため、旧富士銀と旧興銀の担当者や関連会社のエンジニアが動員されて、手分けをして口座振替の処理を進めていった。富士通などコンピューター・メーカーのエンジニアたちも、二十四時間体制のローテーション勤務をして、支援をした。
現場の担当者が必至で作業をしているとき、テレビや新聞は、「みずほ失墜」と連呼し続けた。
「みずほのトラブルはまもなく解決するので、預金者は心配しないでほしい」と発言すべき柳沢伯夫金融庁担当相は、「金融庁は事前に警告した」と自らの責任を回避する発言だけを繰り返した。電力会社やガス会社の社長たちは、「損害賠償する」と声明を出した。
こうした声をよそに現場の担当者はほぼ一カ月、自宅にほとんど帰らず、口座振替の処理を続けた。幸か不幸か、テレビや新聞を見て怒っている暇など無かったのであろう。現場の踏ん張りにより、たまっていた口座振替の処理をなんとか4月18日には終えることができた。
しかし、まだ家には帰れない。4月30日に1200万件の振替が新たに来る。みずほ銀行の担当者たちは、口座振替プログラムを再度見直し、30日に備えた。おそらく気力・体力の限界を超えていたと思われるが、みずほ銀行の現場は、4月30日をなんとか乗り切った。

旧3行と富士通、IBM、日立のベンダー間の駆け引きも

また、富士通やIBM、日立、といった各ベンダーと旧3行との駆け引きの様子も、
かなり細かく書かれていて、
「大企業のシステム統合って、本当にドラマだなぁ」と感じました。

富士通の馬場俊介みずほ事業部事業部長は「当社は既存システムを手掛けてきた立場。IBMの基盤上でアプリケーションを開発する判断を下すのは正直難しかった」と明かす。とはいえ、これだけの大型案件に参画しないわけにはいかない。富士通は苦渋の決断を下し、みずほFGの提案を受け入れた。
基盤とアプリケーション開発のベンダーが異なることで特有の難しさも生まれた。富士通はIBMの基板上で動作するCOBOLプログラムを開発しなければならなかった。
（中略）
中核のDBMSも入れ替えた。STEPSは富士通の階層型DB「AIM」だった。それをオープン系システムについてはRDBに移行した。富士通が担当する領域は「Symfoware Server」、日立の部分は「HiRDB」、日本IBMの担当分は「DB2」といった具体だった。担当するベンダー色が色濃く出た。
メインフレーム上で稼働する業務アプリケーションに関しては、顧客情報を格納するCIFだけをDB2に移行。残りは日本IBMのネットワーク型DBである「IMS」を使う。流動性預金などメインフレーム上で動く業務アプリケーションのデータモデルには変更を加えなかった。

印象に残った言葉「ソフトは稼働した瞬間から陳腐化する」

この本の「おわりに」に書いてあった言葉で、特に印象に残ったのが『ソフトは稼働した瞬間から陳腐化する』というものです。

「ソフトは稼働した瞬間から陳腐化する」。日立製作所で数々のシステム開発プロジェクトを率いた塩塚啓一副社長の持論だ。みずほはここで一息入れず、それこそ次のシステム再構築に向けて準備に入るぐらいの気構えを持ちたい。
（中略）
当初の設計思想を知る人が去り、度重なる変更によってプログラムが複雑になっていく「結末」の悲惨さを、みずほは誰よりもよく知るはずだ。