みずほ銀行が2021年2月から2022年2月までの12カ月の間に、合計11回起こしたシステム障害。本書「ポストモーテム みずほ銀行システム障害事後検証報告」（日経BP）は、原因や背景を検証し、システムを安定稼働させるための一般的な教訓を導き出そうとしたものである。「ポストモーテム みずほ銀行システム障害事後検証報告」（日経コンピュータ著）日経BP著者はIT専門誌「日経コンピュータ」編集部。本書の刊行は同誌にとって一つの「けじめ」だった、と書いている。どういうことなのか。15の謎、その原因とは？みずほファイナンシャルグループは2度の大規模システム障害を経て、老朽化した勘定系システムを全面刷新し、新システム「MINORI」を2019年7月に全面稼働させた。その経緯を、「日経コンピュータ」は2020年2月に書籍「みずほ銀行システム統合、苦闘の19年史」としてまとめた。「MINORI」の開発には4000億円が投じられ、なかなか完成しないことから「IT業界のサクラダ・ファミリア」と揶揄されたそうだ。「勘定系システムを複数のコンポーネントに分割し、コンポーネント間のつながりを緩やかにすることで、障害の影響を極小化する狙いがあった」と説明していた。だが、実際には、システムを構成するコンポーネントをまたいで、連鎖する障害が発生したのである。ATM（現金自動預け払い機）が通帳やカードを取り込む事態が発生した2021年2月28日の1回目のシステム障害はよく知られている。ところが、それ以外のシステム障害を含め、行内で何が起きたのかを詳しく追っている。11回のシステム障害の大半は、よくある小さなシステム障害のままで済んだが、1回目と2021年8月20日の5回目のシステム障害は、金融機関ではあり得ない問題が次々に生じ、深刻なトラブルとなった。そこには、「なぜデータベースは更新不能になったのか」「なぜそれがATMのカード取り込みにつながったのか」「なぜ警告やエラーは見逃されたのか」など15の謎があるとして、技術的に詳しく解説している。いくつかの誤解を正すかなり専門的な内容を含むので、読んでもただちに理解できない項目も多いが、「他行では1990年代に改めた仕様」「アプリのエラー設計に問題あり」「緊急事態の『司令塔』に情報届かず」などの指摘を読むと、「なるほど」と納得するだろう。なぜ、みずほ銀行でシステム障害が続くのか？検査に入った金融庁は、直接的な原因とその背景、それらの事象を生み出した「真因」に分けて分析。「真因」を4つ挙げている。1 システムに係るリスクと専門性の軽視2 IT現場の実態軽視3 顧客影響に対する感度の欠如、営業現場の実態軽視4 言うべきことを言わない、言われたことしかしない姿勢これらは報道され、特に4つ目の消極的な姿勢については記憶している人も多いだろう。本書の読みどころは、第5章「障害を繰り返す みずほ銀行のシステム、その歴史を紐解く」にあるだろう。合併以来のシステムの歴史を振り返るとともに、いくつかの誤解を正している。たとえば、新システム「MINORI」について、一部で「旧3行のシステムをつぎはぎした」ものであるかのように論じられているが、誤解だとしている。要件定義からやり直して、コードを新規開発したという。従来のコードの再利用もしていない。また、「旧3行どこか一つの勘定系システムに片寄せしなかった」ことが問題だという指摘に対しては、さまざまな事情があったと説明している。旧みずほコーポレート銀行のものは、大企業向けの取引に特化したシステムであり、旧みずほ銀行が扱う個人や中小企業向けの取引には向いていなかった。一方で、旧みずほ銀行の「STEPS」は、システムの老朽化が著しく全面刷新が必要だった。また、STEPSが富士通製メインフレームで稼働することも問題だった。富士通がメインフレームの製造・販売をいずれ終了することは予見されていたからだ（2022年に正式発表）。つまり、STEPSへの片寄せも不可能だった。システム障害を「語り継ぐ」取り組み実施新システム「MINORI」は、勘定系システムを、複数のコンポーネントに分割し、コンポーネントごとに異なるアーキテクチャのハードウェアで、分散稼働させる方針を採用した。また、コンポーネントによって開発するITベンダーが異なる「マルチベンダー体制」をとった。本書は、「マルチベンダー体制」に問題があったとすれば、システムが複雑になり、運用しづらいものになったことだ、と指摘している。「こんな複雑なシステム構成は、当社なら運用部門が認めないだろう。運用が難しすぎるからだ」という、他の金融機関の情報システム担当者の声を紹介している。開発部門にリソースが優先的に割り当てられ、運用部門が軽視されたことが、連続システム障害の背景にあった、と見ている。最後に、みずほ銀行以外の国内や海外の金融機関で起きたシステム関連のトラブルを比較していて、興味深い。システム障害を想定した訓練を行っているかどうかが異なるという。他のメガバンクは、年に1回必ずシステム障害を想定していた訓練を行っていたのに対し、みずほ銀行は行っていなかったのだ。みずほ銀行では、要員を増員し、部門横断の統制組織を復活させ、障害を想定した訓練を始めるなどの対策をとっている。また、障害を「語り継ぐ」取り組みも行っている。タイトルの「ポストモーテム」とは、直訳すると「検視」または「死体解剖」だが、米国のIT企業では、システム障害が発生した後の「事後検証報告書」をそう呼ぶそうだ。特に、米グーグルの電子メールサービス「Gmail」が2011年に障害を起こした際に発表されたポストモーテムが、有名。グーグルがデータを磁気テープにバックアップしていることが初めて明らかになり、信頼感を高めた。今回のみずほ銀行のポストモーテムから、金融機関のみならず、システム開発にかかわる多くの人が教訓をくみ取ることだろう。（渡辺淳悦）「ポストモーテム みずほ銀行システム障害事後検証報告」日経コンピュータ著日経BP1980円（税込）
記事に戻る