著名エンジニアが、独自の視点で「おすすめ書籍」の紹介を行う本連載。

今回の語り手は、Xで『情シス女子の社内バトル漫画』を発信している現役エンジニア・よんてんごP（@yontengoP）さんだ。

彼が取り上げたのは、巨大プロジェクトの「失敗から学ぶ」ための一冊『ポストモーテム みずほ銀行システム障害 事後検証報告』（日系BP）。誰もが不幸になる最悪のトラブルを防ぐために、私たちが日々の業務で持つべき視点について語ってもらった。

本書をピックアップした背景

今回お勧めする本を一冊選ぶにあたって、どんな書籍がいいだろうかと考えてみました。

既にこの連載では、多くのエンジニアたちが多様な書籍を推薦しています。ただ、紹介されている内容は主に「最適な方法を得るにはどうするか」「より良いコードを書くためには」など、今いる場所から更にステップアップしよう、前に進もうといった“光”寄りの書籍が多い印象でした。

しかし、私のこれまでの読書遍歴的にそういった“光”の書籍は多くなく、どうしたものかと考えた結果、今回は「失敗から学ぶ」系の書籍をお勧めしたいと思います。いつもと違う毛色になってしまうことはご容赦下さい（笑）

というわけで今回ご紹介する書籍は、『ポストモーテム みずほ銀行システム障害 事後検証報告』です。

IT業界にいる方ならば一度は聞いたことがあるであろう、システム開発における失敗例として必ず名前があがる“青い銀行”こと、みずほ銀行のシステムトラブルについて取り上げた本です。

みずほ銀行のシステム障害に関する書籍は各社からいくつか出ていますが、本書は日経BPから2022年3月に刊行されたものです。なお日経BPは『みずほ銀行システム統合、苦闘の19年史』という書籍も出しており、本書はその第二弾となります。

この『19年史』も、20年2月に発売後5日で5万部を売り上げたという名著です。ご興味がある方はそちらもお読みください。私も両方読みました。

本書で得られた学び・教訓

みずほ銀行のシステムトラブルは、主に02年4月と11年3月に起きていますが、本書で取り上げられているのは、それらに続く21年2月から起きたトラブルの内容になります。

みずほ銀行では過去二回の教訓を踏まえ「もう二度とトラブルは起こさないぞ」という気概の下、11年6月からシステム刷新プロジェクトが進められ、19年には新システム「MINORI」が稼働開始しました。

このMINORIに関しては、SOA（サービス指向アーキテクチャー）やアプリケーションのコンポーネント化（部品化）など、過去のシステム障害の経験を踏まえ、長い時間をかけたからこその施策が盛り込まれています。本書の前作『19年史』でも、「MINORI」に期待する内容が書かれていました。

しかし結果としては、21年2月に再度みずほ銀行のシステムは障害を起こし、なおかつ翌年2月までに計11回ものシステム障害を起こすことになっています。

金融庁による業務改善命令の中で、「言うべきことを言わない、言われたことだけしかしない姿勢」という震え上がるようなワードが使われていたことが、当時ネットでも大いに、良くない方向で話題になってしまいました。

過去の経験に学んで作られたシステムだったにも関わらず、なぜここまでの大きなインシデントが立て続けに発生し、ついには金融庁からもド怒りのコメントを出されるに至ったのでしょうか。

本書を読んでいくにつれてその原因が明らかになっていくのですが、ゾッとするのは、それらの原因がどこの現場でもあり得る、恐ろしく身近な内容に起因しているという点にあります。

何も、みずほ銀行やその周りのベンダーの担当者が手を抜いていたとか、世間一般に比べて能力が低かったということではありません。なんなら、大銀行の中枢の人間たちなのだから、相当優秀で有能な人々が多いはずです。

私たちの会社、現場、チームでも往々にして起きるような「まあ、このくらいは……」という話が、最終的にとてつもないシステムトラブルに繋がっていく。そんな、最悪のピタゴラスイッチみたいな話が次々と登場してくるのです。

初動の悪さと遅さで被害が拡大

2021年2月28日（日）朝、みずほ銀行の各支店のATMが、カードや通帳が挿入されたまま返却されないトラブルが起きます。

運の悪いことに、この日は日曜日なので店舗に行員はおらず、利用客は仕方なくATMにくっついている非常用電話に対応を仰ぎます。この非常電話は、ATM専用の対応窓口であるATMセンターに繋がっており、遠隔でATMを操作して通帳やカードを返却する権限を持っていました。

しかし、各地でATMでのトラブルが増えるにつれてATMセンターへの問い合わせが殺到し、電話は繋がらなくなっていきます。やむを得ず別のコールセンターに連絡しても、そのコールセンターはATM操作権限がないためできることがなく、結局元のATMセンターに電話しろと言われてしまう。

利用客は再度、元のATMセンターに電話をかけます。その間もカードや通帳はATMの中に入れっぱなしなので、離れることもできません。

結果、ATM前にはどんどん利用客が渋滞してしまい、やっと順番が来た利用客は次々にATMを操作してカードや通帳が吸い込まれていくという、悪夢のような状況が生まれます。

月末かつ日曜日。現場には対処できる行員や担当者がいない。コールセンターには繋がらない。結果としてどんどん被害は広がっていく……。最悪も最悪です。

ここまででも既に、だいぶ「うわぁ……」と思うことが重なっていますが、本書の中ではこの後も、初動の悪さと遅さに起因する話が出てきます。

・このような状況にも関わらず、その情報を銀行頭取は昼になって、しかもネットニュースで知る
・取り込まれてしまったカードについて「後で返却するので帰って大丈夫」という案内が掲示される
・「現在ATMに不具合があります」というお知らせの案内がすぐに出せず、被害が増え続ける

情報が頭取まで上がってこなかった理由については、起きている障害規模を小さく見積もったために、頭取まで伝えるようなインシデントではないと判断されたことが原因になります。

さらにこれらのATMトラブルの根本原因についても、後に「DBのindexファイルの扱いが原因」と分かるのですが、

・indexファイルの扱いが特殊なものであると運用担当者が知らない
・メールで異常があることを通知されるが、それに気付かなかった
・担当者が「こうであろう」と思い回答し、結果として被害が広がった

など、「気付かなかった」「知らなかった」「●●だと思った」という内容が所狭しと登場していきます。

システム開発の失敗に「単一の爆弾」は存在しない

ここだけ読むと「随分と杜撰な対応だな」「適当な仕事じゃないか」と思われるかもしれません。

ですが、何かのトラブルがあった際に「慌てて作業を焦り、原因を特定せずに急いで対応する」経験をしたことがある人は、決して少なくないと思います。自己保身や「怒られたくない」という気持ちから報告が遅れたり、トラブルの範囲を狭めて被害を低めに見積もったりすることは、正直なところ、どこの職場や現場でも往々にして発生するものです。

あるいは、会社全体で進めているプロジェクトに対して、そこに横槍を刺すようなことは言い出しづらいというパターンもあるかもしれません。

実際にみずほ銀行でも、「紙の通帳を廃止して年間16億円の節約につなげる」プロジェクトが進んでおり、そのために月末や年度末というタイミングで処理の一括切替を強行したことが、上記ATMのトラブルの遠因になっていました。（システムトラブルの影響で、結局この「紙の通帳廃止プロジェクト」は中止という結末を迎えています）

ともかく、本書を読んでいけばいくほど、この特異な障害事例の引き金は、私たちの身の回りにも普通に起きていることだと痛感します。あるいは、身に覚えがある「何の変哲もない対応」の重なりによって最終的に引き起こされたものだと分からされていくのです。

システム開発に銀の弾丸が存在しないように、システム開発の失敗にも「単一の爆弾」などは存在しません。

何気ない誰かのちょっとした見過ごしや設計ミス、このくらい大丈夫だろうといった火種が積み重なって、こうした大規模障害に発展するものなのだということを、まざまざと見せつけられます。

どんな人に読んで欲しいか

全ての技術者、なんなら技術者以外にも読んでほしいところではありますが、割とindexファイルなど技術的な話も多いので、難しいかもしれません。

自社システムの設計・構築担当や運用担当の方はぜひ読んでほしいですし、SESで他社のシステムに携わっている人も、特に読んでおいてほしいです。

また、もしもあなたが業務において、

・自分に関連するシステムの全容は全て把握している
・よく理解せず、手順書に書いてあるから、とりあえず前例踏襲で作業をしたことはない
・運用やオペレーションの不備や不足があれば、障害になる前に即座に対応して改善している

といった超絶鉄人では無い限り、あるいはあなたが鉄人だったとしても、周囲があなたに呼応して対応してくれる鉄人集団でない限りは、本書を読んでおくことをお勧めします。

実務での活用方法

本書を読んで「よし、明日から全ての業務内容とコードと周辺知識を学び、全知全能になるぞ！」というのは、流石に負荷が高すぎます。

特に銀行システムなどの規模になれば、システム機能の全てを網羅して理解している人間など、銀行内にもほとんどいないのではないでしょうか。

私が過去に手がけた案件でも、システム規模が大きくなりすぎた結果、「社内で誰も知らないDBのテーブルがあるので、どうにか調べてくれ。消していいのかどうかすら分からない」という案件がありました。（ちなみに結果として、消してはダメでした。そのくらい、巨大システムというのは人の手には負えないものなのでしょう……）

ただ、少なくとも自分が今やっている、あるいはよく理解しないままに漫然と作業している結果として、「“運が悪ければ”、このくらいの障害が起きる可能性がある」と知っているかどうかで、行動は変わってくると思います。

社内や部署の仕事の進め方などを大きく変革させることはなくとも、いざという時に、自分の方に飛んでくるかもしれない火の粉の量を減らしておくことはできるかもしれません。

そういう意味で「ああ、私の今やっているこの業務は、下手をするとこういう恐ろしい展開になるのですねぇ〜」という、“あるかもしれない未来”の予測としてこの本を活用してほしいと思います。

まとめ

冒頭のATM障害の件では、その原因の一つとして下記の点が挙げられています。

運用では70万件のDB更新が行われるのに、テストの際には8万件しか行っていなかった。
▼
結果として、64万件以上処理を行うと処理が行えなくなるという不具合が発覚しなかった。
▼
そのために、運用上のリスクとして基本設計書にも詳細設計書にも書かれていなかった。

テストの際に「まあ、バカ正直に全件やらなくても、一部だけやれば大丈夫でしょう！」などという話に接したことがある人間としては、ついつい肝を冷やしました。

同じような経験がある、あるいは現在進行形でそんな経験をされている方は、ぜひ「本当にこのテストケースで大丈夫か……？」と確認しておいてほしいです。

特に社内システム保守などの際には、どうしてもベンダーの出してきた書類を鵜呑みにして捺印して終わりになりがちです。現職で情シスをやっている立場の身からしても、その気持ちは痛いほど分かります。

しかし、「本当にここはこれでいいのかな？」「ここって●●の場合は大丈夫なんですか？」と、不明点があれば確認して、後顧の憂いを断ち切っておくのは重要です。

また、可能な限りで良いので、日頃から自分で情報収集するなどして、自社で使っているシステムやネットワーク、各種機器などに不具合は出ていないか、トラブルは起きていないかを調べましょう。

そうやって「他社／他人に任せているから大丈夫だろう」の火種を一つでも減らしていくことが、誰もが不幸になる最終的な大破壊から免れうる方法なのだと思います。

エンジニア
よんてんごP（@yontengoP）

大学卒業後、教育業界での就業経験を経てIT業界へ転身。SES企業でシステム開発に数年従事した後、商社の情報システム部で勤務。その後、フリーランス、AIベンチャーを経由して、現在は再び企業の情シス部門に勤務する傍ら、副業でフリーランスとしても活動。自身のキャリアで得た知見や「ブラック企業」体験をSNSで発信し、多くのフォロワーを持つ。名前の由来は、過去に描いていた「4.5コマ漫画」から

文／よんてんごP　編集／今中康達（編集部）