「みずほ銀行システム統合、苦闘の19年史」とても読み応えがあったが、引っかかるところもあり。。

雑記

「みずほ銀行システム統合、苦闘の19年史」ざっくりあらすじ

発売前から界隈では話題になっていたこの本、僕も発売日に買いました。近所の本屋に全然売ってなくて、車で30分のジュンク堂までわざわざ買いに行きましたよ。エンジニアの端くれとして非常に読み応えがあり、久しぶりに本を一晩で読み終えました。ざっくりしたあらすじは以下の通り。

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

みずほ銀行の合併から新システム「MINORI」が完成するまでの約20年の歴史を振り返る章。過去の障害事件を乗り越えて完成した新システムがいかに素晴らしいかを説明しています。キーワードは「ソフトウェアのコンポーネント化」「属人性排除」など。

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

2011年の東日本大震災義援金振り込み殺到をトリガーにした2度目の大規模障害を説明した章。何が原因で大規模障害が起きてしまったを詳細に説明している。キーワードは「技術的負債」と「仕様の属人化」など。

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

2002年のみずほ銀行合併直後に発生した1度目の大規模障害を説明した章。キーワードは「IT軽視」「トップダウンマネジメントの欠如」あたり。

キーワードを見ればわかる通り、IT業界を経験した人であれば誰もが心当たりのある話題ばかりです。第1部なんて、オブジェクト指向やプロジェクトマネジメントの入門書に書かれているような内容を実践しましたと言っているに等しいです。このレベルの開発規模のプロジェクトでも、いや、だからこそ、重要なのは開発の基礎基本を徹底するってことなんですかね。

個人的に一番読み応えがあったのが第2部です。大規模障害に対して現場・経営層が右往左往する様子を時系列で詳細にまとめてあり、読んでいて胃がキリキリしてきます。自動処理が出来ずに現場エンジニアが人力で奮闘し、それが故にヒューマンエラーを引き起こして障害は更に拡大していく。。。ただでさえ未曾有の震災で日本全体が混乱状態の最中、家にも帰れずひたすらバグと戦い続けた気持ちは察するに余りあります。

読んでいて引っかかった点

本自体は非常に面白かったのですが、読んでいて「ホントか?」と引っかかった点があります。

それは「属人性排除」について。参加ベンダー1000社という驚異のプロジェクト規模なので、当然エンジニア毎にプログラミングスキル・記述の癖が異なります。それに起因する属人化や保守性低下を避けるために、コードを自動生成する「超高速開発ツール」を採用したらしいです。業務ルールを記述した設計書をインプットすれば、ソースコードとテストコードを100%自動生成してくれるとか。しかも自動生成コードを手直しすることは許さず、この方針を貫いたとの記述がありました。

超高速開発ツールの採用もシステム品質の向上に一役買った。ツールでしかプログラムを生成しない方針を徹底したことで、プログラムの構造を統一できたのだ。一部のエンジニアからは「手で書いた方が速いし、シンプルなプログラムができる」という不満も出たが、「ツールを使えば属人性を取り除けるため、保守性が高まる」と判断し、その方針を貫いた。

引用元:日経コンピュータ、山端 宏実、岡部 一詩、中田 敦、大和田 尚孝、谷島 宣之 著(2020年)『みずほ銀行システム統合、苦闘の19年史』(73ページ)

この「自動生成コードオンリー、手直しゼロ」というのはちょっと信じがたい。。。完璧なシステム設計をして、完璧なコンポーネント化をしないと実現不可能な芸当なはず。しかしこの規模のシステムを1ミリの隙もなく設計するのは現実的ではない。だとすると、このツールのインプットとなる「設計書」の部分で様々な設計不備を吸収していた可能性があります。言ってしまえば設計書の記述方法自体がプログラム言語と等価で、超高速開発ツールがJavaやCOBOLにコンパイル(厳密には変換かな?)しているだけではないのかと推測しました。こうなると属人化する言語が変わるだけで、あまり意味があるとは思えない。いや、このツールに縛られる分余計にタチが悪いかもしれない。このあたりの真実を、実際の現場の人に聞いてみたいです。上で引用した「手で書いた方が速いし、シンプルなプログラムができる」というエンジニアの意見が、ツールを導入した経営層と現場の温度差を表しているように思えてならないのです。

属人化も含め、「第1章」は基本的に新システムの成果が語られており、少し綺麗事に感じてしまう部分がありました。大規模障害の詳細を語った「第2章」「第3章」で生々しく現場のリアルを感じることができるので、余計にそう感じてしまいます。章構成として第1章がラストであったなら、「2度の大規模障害でズタボロ」→「入念に再発防止策を立てて新システム完成!」という流れで腹に落ちたかもしれません。

エンジニアなら一度は読むべき一冊だと思う

とまぁ気になる点もありましたが、非常に読み応えがあって面白い本でした。冒頭で書いたように、エンジニアが一度は直面するキーワードが随所に盛り込まれていて、自分事に置き換えて読むことができるのです。これほどの開発規模になっても、結局ハマるポイントは同じなんだなぁとしみじみしてしまいました。3時間程度で読めるボリュームなので、ITに限らずエンジニアの方はぜひ読んでみることをおすすめします!