その本の「はじめに」には、著者の「伝えたいこと」がギュッと詰め込まれています。この連載では毎日、おすすめ本の「はじめに」と「目次」をご紹介します。今日は 『ポストモーテム みずほ銀行システム障害 事後検証報告』 です。
【はじめに】
ポストモーテム（Postmortem）──。米国のIT企業は、システム障害が発生した後に社内外の関係者と共有する事後検証報告書をそう呼ぶ。
ポストモーテムとは直訳すると「検視」または「死体解剖」だ。人が突然死去した際に、司法機関が遺体を解剖するなどして死因を調べ、犯罪性の有無を明らかにする。
情報システムは生き物と同じで、どこに悪い部分が隠されているのか、外見からだけではうかがい知れない。人間であればその死因は、解剖して初めて明らかになる。それと同じように情報システムでトラブルが発生した原因も「解剖」して調べる必要がある。システムが記録する「エラーログ」を分析したり、システムを運用する担当者に話を聞いたりする作業が解剖に当たる。
ただし犯罪捜査であればポストモーテムは犯人逮捕などの証拠に使うのに対して、IT業界の場合はそうではない。ポストモーテムはシステム障害における犯人を探す道具ではなく、発生した事象から教訓を得て、今後の取り組みに生かすために使う。
チェスの感想戦も英語ではポストモーテムと呼ぶ。IT業界のポストモーテムもその用法に近い。プロジェクトマネジメントの教科書的存在である「PMBOK（プロジェクトマネジメント知識体系）」も、ソフトウエア開発プロジェクトなどが終わった際に行う反省会をポストモーテムと呼んでいる。
ポストモーテムは学びの宝庫だ。特に大手クラウド事業者などがシステム障害の後に公表するポストモーテムは、本来なら外部からは知り得ないクラウド内部の技術的な詳細や運用の実態、設計思想などを教えてくれる。
その中でも米Google（グーグル）の電子メールサービス「Gmail」が2011年2月に障害を起こした際に発表されたポストモーテムは、IT業界に大きな驚きを与えた。
Gmailではこのとき、メールデータを格納するサーバー群のソフトウエアに存在したバグが原因で、メールデータが削除される障害が発生した。当時のGmailのユーザー数は推定2億人で、全体の0.02％、およそ4万人のユーザーのメールの一部が削除された。ただしグーグルはユーザーのメールデータを磁気テープにバックアップしていたので、削除されたデータは障害発生から4日後までに復元できた。こうした経緯が後日、ポストモーテムとして公開された。
グーグルがデータのバックアップに磁気テープを使っているという事実は、このポストモーテムで初めて明らかになった。そして多くのIT技術者が、グーグルが無料サービスであるGmailのデータを厳重に保護していることに良い意味で驚いた。グーグルはシステム障害のポストモーテムを公開することで、自社のクラウドサービスに対する信頼感を高められたのだ。
さらにこの一件は、データ保護手段としての磁気テープの有用性が見直されるきっかけにもなった。グーグル社内の知見やノウハウがポストモーテムを通じて社外に共有されることで、世界中のIT技術者の知見が底上げされる結果につながったわけだ。
IT業界におけるポストモーテムは、失敗を非難するためにあるのではなく、失敗から得た経験を教訓とするためにある。そのことをご理解頂けたろうか。
本書は、みずほ銀行が2021年2月から2022年2月までの12カ月の間に合計11回起こした一連のシステム障害に関するポストモーテムを目指して執筆したものだ。
みずほ銀行のシステム障害を巡っては、監督官庁である金融庁や財務省が行政処分を下し、持ち株会社であるみずほフィナンシャルグループの社長やみずほ銀行の経営幹部が引責辞任している。しかし本書は、みずほ銀行の糾弾を目的とはしない。
情報システムは人が開発・運用するものなのだから、ソフトウエアのバグやハードウエアの故障、オペレーションミスなどは避けられない。金融庁によれば日本の金融機関では2020年の1年間だけで、約1500件ものシステム障害が発生しているという。システム障害が発生しているのはみずほ銀行だけではない。もちろん金融機関以外の事業会社でも、システム障害は日々発生し続けている。
重要なのは、システム障害が発生しても業務を通常通りに続けられるレジリエンシー（復元性）を有していることだ。そのためには企業はシステム障害がどのようなものか理解し、そこから復元する術を身につけると共に、情報システムに対して実装していく必要がある。みずほ銀行のシステム障害については、社会全体がこれを教訓にし、システム障害に対する理解を深め、レジリエンシーを高めるきっかけにするのが望ましい。それにはポストモーテムが必要だ。
みずほフィナンシャルグループ自身も、システム障害を4回起こした2021年3月の時点で社外の有識者や専門家で構成する第三者委員会である「システム障害特別調査委員会」を設けて社内調査を行った。その調査報告書は2021年6月に一般公開された。しかしこの調査報告書は、障害の原因を突き止めることに重きが置かれていた。またみずほ銀行ではその後も2022年2月までにさらに7回のシステム障害が発生したが、それらに関する調査報告書は公開されていない。
そこで本書は、みずほ銀行が起こした合計11回のシステム障害について、原因や背景を検証すると共に、他の金融機関などで行われている対策などと比較することで、システムを安定稼働させるための一般的な教訓を導き出そうとした。
みずほ銀行は第一勧業銀行と富士銀行、日本興業銀行の3行が統合して発足した2002年4月と、東日本大震災が発生した2011年3月にも大規模なシステム障害を起こした。企業情報システムの専門誌である我々「日経コンピュータ」はその度にシステム障害に関する詳細を報じると共に、本書と同目的の書籍を刊行している。そうした経験に基づき過去2度の大規模システム障害と今回の連続システム障害を比較することによって、システム障害の背後にあるみずほ銀行特有の企業体質などについても考察を試みている。
本書を刊行することは、日経コンピュータにとっては一つの「けじめ」でもある。みずほフィナンシャルグループは2度の大規模システム障害を経て、老朽化した勘定系システムを全面刷新し、新システム「MINORI」を2019年7月に全面稼働させた。何度もシステム刷新プロジェクトに失敗した同社が社内を立て直してシステム開発を成功させた経緯を、我々は2020年2月に書籍「みずほ銀行システム統合、苦闘の19年史」としてまとめた。
我々は2020年の書籍で、MINORIの開発過程やMINORIに込めたみずほ銀行の狙いなどは描けたが、MINORIそのものの評価はできなかった。今回のようなシステム障害が発生するとの予測もできていない。
稼働し始めたばかりの情報システムについて評価したり、障害が発生するかどうか予測したりするのが不可能なのは当たり前だ。しかし2020年の書籍では、MINORIについてこのような説明をしている。
MINORIの最大の特徴は「SOA（サービス指向アーキテクチャー）」を全面採用した点にある。勘定系システムを複数のコンポーネントに分割し、コンポーネント間のつながりを緩やかにすることで、障害の影響を極小化する狙いがあった。
実際にはMINORIでは、システムを構成するコンポーネントをまたいでトラブルが連鎖する障害が発生した。みずほ銀行がMINORIに込めた狙いを報じた日経コンピュータにとって、それが機能しなかった原因を考察して報じるのは責務だと考えている。
35万人月という労力と4500億円もの巨費を投じたMINORIは、みずほフィナンシャルグループ全体が「次世代金融業」に転換する礎になるはずだった。しかしMINORIやその周辺システムが立て続けに障害を起こしたことで、みずほ銀行は再発防止への対応に追われただけでなく、金融庁が2021年9月に下した行政処分によって当面のシステム更新などを見直すよう命ぜられた。次世代金融業への転換も足踏み状態となっている。
情報システムは企業経営にとって大きな武器であると同時に足枷（かせ）にもなり得る。みずほ銀行で起きた一連の事象は、他の企業でいつ起きても不思議ではない。
社会全体がみずほ銀行で起きたシステム障害を教訓とし、システム障害に対するレジリエンシーを高める──。本書がその一助になることを願っている。
なお銀行名や登場人物の役職は、特記しない限り当時のものを記載している。
2022年3月 日経コンピュータ編集部 中田 敦
【目次】
