本シェルジュの村上です。

今日紹介するのは、発売前からAmazonランキングで1位になっていた、みずほ銀行のシステムトラブルについての書籍です。

私は10年前まで、大手のシステムインテグレータに勤めていました。幸いなことに（？）、担当していたお客様は金融系ではありませんでした。一般の会社の会計や給与計算などのシステムを担当していました。それでも色々苦労はありましたが、追い詰められての徹夜というのはありませんでした。

担当していたのがバックオフィス系の業務のシステムであり、多少トラブルがあっても、

「今すぐ動かせーーーー！」と言われるケースは少なかったからです。

しかし、基幹系のシステムではそうはいきません。システムが止まる、すなわち会社の活動が止まってしまうことになりかねません。

特に直接的なお金のやり取りが発生するATMを含めた金融の基幹システムが止まるのは社会インフラとしても大問題になってしまいます。本書のみずほのシステムを担当されていたエンジニアの方のプレッシャーは半端なものではなかったでしょう。

一方で、本書を読みすすめると、経営陣の緊張感のなさは笑ってしまいそうなシーンが多数ありました。

本書では3度目のプロジェクトは成功事例として描かれています。

もちろん、完成してスタートしているので成功と言ってもいいかもしれませんが、遅延を繰り返しており、当初の予定からすると金額的にも時間的にも大成功だったとは言えないと思います。

それなのに、本書の第1部では、苦労の末に成功に導いたというトーンで書かれています。

社長とかえらいさんのインタビューはあっても構いませんが、3度目のプロジェクトについては実際の「現場の声」がほとんど書かれておらず、その点については、かなり物足りなかったです。

それでも、1度目と2度目の失敗については、厳しく断罪されています。

過去（第2部、第3部）については胸が痛くなるような緊迫感が伝わってきます。

当たり前のことですが、
リーダーが明確な方針を持っていないとIT導入はうまくいきません。
業務の要件が明確に整理できていないと、そもそもITも決まりません。
業務の要件が見えていても、今の要件をすべてそのままで実現したいというと、莫大なコストがかかります。

ITは失敗事例に事欠きませんが、このような大規模失敗事例を改めて学ぶという意味では、読む価値がある一冊になるでしょう。

１）本日紹介する書籍

『みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 』

日経コンピュータ (著)他, 256ページ、 日経BP (2020/2/14)
https://amzn.to/32n8Spj

２）本書を選んだ理由　　　　どんな人が読むべき？

ITに携わる人、特に受託開発に携わる人、
そして一番読んでほしいのは、ITを発注する側の責任者です。

３）付箋　　本書からの内容抽出です

第1部　（三度目の正直）

みずほＦＧやみずほ銀行は、老朽化していた勘定系システムについて「まだ使い続けられる」と油断していた。

「過去の苦い経験から、要件定義においてユーザー部門が『今のままで良い』『アズイズでよろしく頼む』との態度をとるのが最悪だと学んだ」。

そこでみずほＦＧはコードを自動生成する「超高速開発ツール」を全面的に採用した。生のコードを書かせなくすることで属人性を排除した。

「コーディングの作業量は五分の一に減った」

ツールでしかプログラムを生成しない方針を徹底したことで、プログラムの構造を統一できたのだ。一部のエンジニアからは「手で書いた方が速いし、シンプルなプログラムができる」という不満も出たが、「ツールを使えば属人性を取り除けるため、保守性が高まる」（みずほＩＲの山本健文銀行システム横断開発推進ＰＴ長）と判断し、その方針を貫いた。

みずほＦＧの石井専務はＭＩＮＯＲＩの開発を通じて育った人材を「益荒男（ますらお）」と表現する。ＭＩＮＯＲＩの開発で鍛えられた人材が現在、海外系や証券系、投資顧問系など別のシステム開発に参加し、一騎当千の活躍をしているという。

第2、3部　（過去の失敗について）

二十三年前の設計思想が影響拡大を招く

夜間の一括処理で問題が発生しています」。みずほ銀行のシステム担当役員である萩原忠幸常務執行役員は、十五日午前三時三十分頃に初めて、システム担当者から障害の報告を受けた。システム担当役員が障害発生を知るまで、最初のトラブル発生から十七時間かかった計算になる。システム障害時の緊急連絡にしては、あまりにも時間がかかりすぎた。

なんとか九時に間に合ってくれ──。萩原常務とシステム担当者の思いは通じなかった。それどころか、システム障害の影響を抑えるはずの「正しい判断」が、システム障害の影響範囲を広げることになる。

みずほ銀行の勘定系システムは一九八八年に稼働を開始した。その後、みずほ銀行は、ＡＴＭの二十四時間稼働、インターネットバンキング、携帯電話からの振り込みといった新サービスを投入する一方、一括処理の上限値の設定を、二十三年間一度も見直さなかった。それどころか、現在のシステム担当者は上限値の設定がある事実すら知らなかった。

システム監査部門、なにやってるの！

みずほ銀行についても、システム部門の品質管理チームによるチェック、監査部門によるチェック、持ち株会社のみずほフィナンシャルグループによる外部監査の枠組みはあった。ところが、負荷テストを実施していないという問題にだれも気付かなかった

主責任は、ほとんどの場合、ユーザ企業にあります。

みずほ銀行の勘定系システムの問題は、みずほ銀行自身の責任であり、システム開発会社やコンピューター・メーカーの責任ではない。

みずほ銀行の二度のシステム障害は、どちらも経営陣のＩＴ軽視、ＩＴ理解不足に原因がある。この、根本原因を見逃した結果、みずほは失敗を繰り返してしまった

三頭取に質問した。「ＣＩＯは経営会議のメンバーではないのでしょうか？」

「ご指摘の通り、経営会議の常勤メンバーとしてＣＩＯをおいたほうがいいかもしれません。ただしシステムが分かる役員がいないのです」

現場の担当者はほぼ一カ月、自宅にほとんど帰らず、口座振替の処理を続けた。幸か不幸か、テレビや新聞を見て怒っている暇など無かったのであろう。

「人が育った」。みずほフィナンシャルグループ（ＦＧ）の坂井辰史社長はシステム完全統合プロジェクトの成果についてこう述べた。

４）今日の気づき

CIOが役員になっていなかった、というのが衝撃でした。

ITをわかっていない人が先導していた、そもそもITに興味がなかった、ということであれば失敗したのも仕方なかったのでしょう。

ITが万能だとは思いませんが、企業にとって（特に金融業にとって）、IT無しではなんの業務も進まない時代になっています。

経営者は「ITがわからない」と言って、担当者に丸投げすることだけは避けないと、みずほまでいかなくても効果の出ないIT導入になってしまいます。

中小企業の多くはITはわからないから対応しないと、言う状況が続いています。わかなくても、わかろうとする努力を早くはじめ、ITを活用していかないと、世の中から取り残された企業になってしまいかねない、と改めて感じました。

最後に、実際に携わった現場の方々が大規模プロジェクトを成し遂げた！という満足感を得られているといいな、と思いました。

５）本書の目次

≪目次≫

はじめに
第一部 IT業界のサグラダファミリア、ついに完成す
第1章 三十五万人月、四千億円台半ば、巨大プロジェクトはこうして始まった
第2章 さらば八〇年代、新システム「MINORI」の全貌
第3章 参加ベンダー千社、驚愕のプロジェクト管理
第4章 緊張と重圧、一年がかりのシステム移行
第5章 次の課題はデジタル変革
第6章 「進退を賭けて指揮した」
みずほフィナンシャルグループ 坂井辰史社長 インタビュー

第二部 震災直後、「またか」の大規模障害
第7章 検証、混迷の十日間
第8章 重なった三十の不手際
第9章 一年をかけた再発防止策

第三部 合併直後、「まさか」の大規模障害
第10章 現場任せが諸悪の根源
第11章 無理なシステム統合計画を立案
第12章 大混乱の二〇〇二年四月

おわりに

ーーーー

『みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」 』

日経コンピュータ (著)他, 256ページ、 日経BP (2020/2/14)
https://amzn.to/3c85hQa