ポストモーテム みずほ銀行システム障害 事後検証報告

著者 : 日経コンピュータ

• 日経BP (2022年3月17日発売)

作品紹介・あらすじ

なぜ繰り返すのか、メガバンクの失敗に学ぶ

みずほ銀行で2021年2月からの12カ月間に11回ものシステム障害が発生した。
2002年、2011年と大規模システム障害を起こし、それを反省して2019年までに勘定系システムを全面刷新したみずほ銀行だったが、トラブルは繰り返された。

システム障害はなぜ起きたのか。みずほ銀行ではなぜシステム障害が繰り返されるのか。
情報システムは人が開発・運用するものでトラブルは避けられないのだから、情報システムを利用する組織には、システム障害が起きても顧客や業務に影響を与えないで済ませられるレジリエンシー(復元性)が必要だ。

情報システムの専門誌「日経コンピュータ」が執筆する本書は、みずほ銀行の失敗を教訓に、組織のレジリエンシーを高めるための方策を探る。

感想・レビュー・書評

[横さんの感想 · 2022年4月18日]

良書。読み終えたとき、銀行の勘定系システムを知るには、うってつけのテキストと感じました。情報システムの関係者へ向けたメッセージです。

表題のポストモーテムとは、事後検証報告書（直訳は、検視、死体解剖）、要は事後の振り返りです。

コンピュータの仕組みを知らない方は、読み進むのは、難しいかもしれないが、かじったことのある方であれば、IT用語のほうは、苦にはならないのではないか。むしろ、金融関連の用語を知らないと進みずらいではと感じました。
流れは、第３章で１５の疑問、第４章でなぜ重大障害が頻発したかの結論に至ります。振り返りとはここまで。また再発防止策について、７章にまとめられています。

金融庁からの指摘・原因
①システムを開発したのはいいが、品質を確保するために十分なテストをしなかった。
②稼働させた後に保守体制を十分に整備しなかった。（保守要員を１／３にカットした）
③障害に備えて、十分に訓練しなかった。

筆者は上記に加えて、他行が１社に片寄せした勘定系システムを、いがみあう４社に分散した結果、十分なコミュニケーションがとられないままに、システムがリリースされて障害が多発したと指摘しています．２度のシステム合併は各ベンダーに禍根を残したとも指摘しています。IBM 日立 富士通 NTTデータ

三菱ＵＦＪ　3300億円
三井住友　　1000億円
みずほ　　　8000憶円（4000億はDKB,FKBの片寄せ、4000億は3みずほの再構築）

上記がメガバンクの、合併にともなうシステム統合の費用です。
みずほは、多額の投資を取り戻そうと、運用費用をけずって、好決算をたたき出したのに、障害を引き起こして信用を失うという結果につながっています

また、三菱ＵＦＪとほぼ同規模だったみずほですが、４つのベンダーをたばねるために倍以上のコストがかかっています。「みえる化」というか、わかりやすさが、情報システムの構築コストにいかに大切かがうかがいしれます。

筆者のおもいというか結論は、以下です。

「ポストモーテム」は、失敗からの学びを大切にする文化の代表例だ。本書が多くの読者にとって、みずほ銀行の失敗を学び、より良い情報システムを築き上げるための教訓とする過程の一助になることを願っている

貴重な資料

P48　銀行システムの主な要素と勘定系システムの位置づけ
P50 勘定系システム「MINORI」の全体像とシステム障害が発生した箇所
P51 MINORIの主要機能と担当ベンダー
P129 MINORIの監視体制
P158 データベース冗長化対策の手法
P163 MINORI関連システム概要（インフラ基盤構成）
P185 大手銀行の勘定系システムの変遷
P195 銀行オンラインシステムの歴史
P212 みずほ情報総研の委託先体制
P217 メガバンクのシステム統合プロジェクトの比較
P233 MINORI稼働後に開発を始めたＡＰＩゲートウェイ
他　第7章　各再発防止策が集約されています

目次は以下です。

はじめに
第１章　前代未聞、１２か月で１１回のシステム障害
第２章　行内で何が起きたのか、システム障害の真相
第３章　なぜ障害は拡大した、１５個の疑問
第４章　金融庁が分析する「原因」「背景」「真因」
第５章　障害を繰り返すみずほ銀行のシステム、その歴史を紐解く
第６章　なぜみずほ銀行でだけ、何度も障害が起きるのか
第７章　みずほ銀行は立ち直れるのか
おわりに

[鈴木すすきさんの感想 · 2023年4月29日]

当方、システムエンジニアなこともあり、大変面白く、興味深く、そして恐ろしく読んだ。システム運用の大事さが身に染みる。

本書で一番印象的だったのは、最初の統合の際、第一勧銀・富士通と富士銀・日本IBMが真っ向から対立してシステム比較を行い、決定的に仲が悪くなったという点だ。
しかもこの裏に、本当はトップレベルで落とし所が決まっていたのに、ボトムアップで検討させるために敢えて現場に比較させたと言う事情があるらしく、なお胸が痛む。

1点気になったのは、メインサイトの副系に切り替えられないとわかった後、DRサイトへの切り替え判断が遅れたという指摘だ。
本来DRサイトはメインサイト全滅を想定していたことを考えると、DR切り替えの決断は慎重にすべきだし、無理に業務に間に合わせてDR切り替えを行っていたら二次被害が出ていたかもしれない。
どの時点でDR切り替えを判断するかというチェックポイントに関する議論・合意はもっと早めにすべきだったように思うが（本書に書いてないだけで実際はしていたかもしれないが）、「DR切り替えの判断が遅れたから業務に影響出た」という指摘は適切でないように思う。
セブン銀行がメインとDRを定期的に入れ替えているという話はとても勉強になったし、良い運用だと思う。

[くりくんさんの感想 · 2023年1月1日]

2021年2月〜2022年2月までで合計11回のシステム障害。
冒頭から障害に関する記載の嵐。結局最後までずっと障害。

著者はITに詳しく、分かり易く伝えることをすごく意識しているのが伝わってくる。兎に角すごい取材力。

だだ、本書はITが分からない人は少し難しいと思う。
一方で、仕事でITに携わっている人であれば、アプリ、インフラ、運用のどの領域であっても、この本を読むことで、自身がこれまでのIT業務で経験した反省点を思い出させてくれる一冊。

内容の重複記載が多いのは難点。日経CPに掲載したものをコピペで纏めているからだろうか‥。

障害原因をしっかりと深掘りして、過剰なプロセスを増やすことなく、効率的にかつ適切に改善へと繋げて欲しい。

昔は運用部門には凄い怖い人がいて、アプリが持ってくる依頼を厳しくチェックして、牽制していたという話も聞いたことがあるが全体としては、アプリ＞インフラ＞運用のヒエラルキーは変わらない。

※データベースの統合を検討。IBMのIMSやdb2、富士通のSymfowareServer、日立のHiRDBの乱立を解消し運用をシンプルにとの事（備忘）

[あかたさんの感想 · 2022年6月10日]

みずほ銀行で2021/02〜2022/02の12ヶ月間で起きた11回の一連のシステム障害に関するポストモーテム。
何でこんなに？と思ったが、いざ現場にいたら連携がうまくいかずになるべくしてなったのかもしれないと思った。
参考にあがってたセブン銀行の東阪交互運用方式はすごいと思った。ここまでやらないとダメなのかぁ、勉強になった。
156冊目読了。

[nyonboo48さんの感想 · 2023年11月7日]

外から見てこれだけのポストモーテムができるのだから、内部でポストモーテムして、次に活かせば、より早くより深く、改善が進むのではないかと思う。障害事象解説の図は分かりやすい。ただ、門外漢からすると細かすぎて読み物としてはちょっと飽きが来る。必要な人にとっては必要な情報なのだとは思うけれど。

[ゆうだいさんの感想 · 2023年6月25日]

2021年から2022年にかけて、みずほ銀行で発生したシステム障害の事後検証報告。ポストモーテムは直訳すると検死ですが、米国のIT企業が障害発生後に社内外関係者と共有する報告書もそう呼ばれているそうです。
ICT業界の片隅にいる自分としても読んでおかねばと思い読了。みずほ銀行の"MINORI"のシステム構成から丁寧に説明していて比較的読みやすいです。
マルチベンダーって凄いな…と思いましたが、本著曰く「マルチベンダー体制がトラブルに結びつくとは限らない」「問題があったとすれば、コンポーネントを担当するITベンダーによってDBMSやミドルウェアがバラバラになり、システムが複雑になって、利用しづらいものになったこと」だと言います。

端的には、わかりづらいモノは作っちゃダメだってコトなのかもしれません。
ただ、背景には銀行のリテールが儲からなくなってシステムが単なる金食い虫扱いになってしまい、開発にお金も時間もかけられなくなってしまった、というままならなさがあります。
（しかし、他行はそれでもシングルベンダーを維持してみずほ銀行ほどのトラブルは起こっていない訳で。。）

あとはちょっと細かい感想です。
本著を読んでいてつい苦笑してしまったのは、「監視担当者は、問題がありそうなエラーメッセージを見つけたら、その(略)紙を印刷して(略)報告する必要があった」というくだり。
あと、みずほ誕生時に、どの銀行のシステムを使うべきか等の「ボトムアップ型のシステム論争」を経営トップが何度も繰り返し、これがお互いを批判して部門同士の仲が悪くなって意思疎通の難しい風土を作ってしまった…というのは痛恨事だと思います。線引きは難しいものの、トップダウンで決めるべきことは決める、としないとこうなってしまうんだなと。。

個人的な学びとしては、こういった「障害をしっかり振り返って、継承していく」営み（みずほ銀行の再発防止策にも「定期的・継続的なシステム障害の語り継ぎ」が挙げられています）は大事だと感じました。
…こないだもミスったし！悔恨の念が強いうちに纏めておこうかと思います。
ITがこれだけ普及した世の中、システム障害というのは誰にとっても他人事にはならないと思います。こういった本に触れることは大事だなと。。

しかし、トラブルが起きてるからと言ってわざわざみずほのATMに行ってキャッシュカードを突っ込む日経BPの記者さんは、有難いカナリアなんでしょうか。。

[DRMさんの感想 · 2022年3月30日]

専門用語も多く、システム素人の私には難しいところもあったが、システム障害の全体像・問題点が分かりやすく整理されている。いくらみずほFG・みずほ銀行が対外公表している資料を読み込んでも、理解はできないだろうが、本書のおかげですっきり分かった。
旧3行のシステム駆け引きから、すでに不幸が始まっており、何度も障害を繰り返しながらも抜本的なアクションがとられなかった。唯我独尊で、他のメガバンクや海外の動向から学ぶことはあろうに、忖度や馴れ合いの結果、不確実性を増していったということだろう。
私が一昨年まで暮らしたシンガポールのネットバンクは、UIが良く統一感があり、大変利用しやすい。一方、みずほ銀行（だけでなく他の邦銀）は、非常に操作しづらい。みずほの歴史は日本の停滞の20年と重なり合う。
本書「おわりに」で紹介されている、みずほの窓口でのやりとり。令和の時代に昭和を引きずり、一部IT機器が出てきたかと思えば、iPadではなくMINORIタブレット。。。そんなみずほもGoogleと提携したとのこと。しがらみをかなぐり捨てて、飛躍してほしい。（一口座保有者として希望。）

[yoshio2018さんの感想 · 2022年10月4日]

みずほ銀行のコンピュータ障害の事後検証報告書。日経コンピュータの記者が執筆。ふ～ぅ。読みでがあった。なぜみずほ銀行のコンピュータ・システムが何回も障害を起こしたのかの謎をひも解く。読んでみて、みずほ銀行のシステムは他行のシステムとはずいぶんと異色であることが分かった。システムが疎結合でマルチベンダー・システムであることだ。他行はシングル・ベンダーで緊密結合システムが多い。そのため、システムが複雑になり運用でも難しさがある。その運用をみずほ銀行は軽視していたようだ。エラー・ログの抽出検索システムもなく、障害時には生のエラーログを画面で逐一調べていたというのは驚きだった。

[saltuscafeさんの感想 · 2022年8月13日]

2021年2月から2022年2月までの約1年間の間にみずほ銀行で起こった11件のシステム障害について、その原因、対応状況と反省点を分かりやすく整理してくれており、大変勉強になった。

世間でよく言われるのが、みずほ銀行が前身となった旧3行のシステムをつぎはぎに承継しており、それがトラブルの原因になったという話であるが、本書を読んでそれは誤りであるという点をまず認識することができた。

みずほで現在稼働しているシステムであるMINORIは、2010年代に入ってから全く新しいシステムとして開発されており、他のメガバンクと比べても旧行のシステムとは縁の切れたシステムである。

一方で、銀行の勘定系システムは必然的に複雑であり、その設計思想と運用の体制の間で密接に連携が取れていないと、大規模なシステム障害を防ぐことができないということもよくわかった。

MINORIは、サービス指向アーキテクチャ（SOA）と呼ばれる開発思想に基づき、システムをいくつものコンポーネントに分け、それらの間のつながりを疎にすることで、1か所のトラブルが他の部分に極力波及しないようにする設計を取り入れている。

しかし、今回の複数のシステム障害で、そのコンポーネント間の影響の隔離のための機能を、運用側が解除したり、設定におけるミスをすることによって、影響が拡大してしまったケースがあったということも分かった。

結果として、システムの運用に関する体制や訓練が十分ではなかったため、せっかくの設計思想も機能しなかったということである。

銀行自体が巨大なシステム産業になっている中で、IT部門の体制の強さが、銀行自体の経営の強さに直結するという状況を、とてもよく理解できた。

また、運用部門とIT部門の連携のまずさが、顧客に対する対応の遅れにつながり、事態の悪化を招いたということも指摘されている。

システム側で問題が起こっているにも拘らず営業店舗や経営本部にはその状況が伝わっておらず、ATMにおける現金や通帳の取り込みや決済の遅れなどの影響の拡大を抑えるための、現場レベルでの適切な対応が取られていなかった。

巨大システムにおいては、開発側と運用側、そして経営側の間の意思疎通や状況の共有が非常に重要である。それは、福島第一原発の事故などの際にも同じことが言われてきた。

そういった側面から、システム自体の改良やIT部門の体制の刷新だけではなく、本書でも提言されていた部門横断的な体制の強化や、顧客目線でシステムの安定性を評価するサイト・リライアビリティー・エンジニアリング（SRE）といった考え方も、重要なのであろうと感じた。

一つのシステムを例に、実際のトラブル事例を検証しながら、開発から運用、そして経営側の課題まで網羅的に見ることができるという点で、非常に有益なケーススタディになっていると感じた。

[sotaさんの感想 · 2022年6月9日]

ー　金融庁はこうしたシステム上やガバナンス上の問題点が発生する「真因」として、「①システムに係るリスクと専門性の軽視」「② IT現場の実態軽視」「③顧客影響に対する感度の欠如、営業現場の実態軽視」「④言うべきことを言わない、言われたことだけしかしない姿勢」があると指摘する。

この中でひときわ目を引くのは「④言うべきことを言わない、言われたことだけしかしない姿勢」だ。金融庁は具体的な例を2つ挙げている。1つはみずほ銀行でシステム障害が発生した際、経営トップが障害の第一報を受けても、具体的な指示を出さなかったことが問題だとした。もう1つはみずほFGの取締役会でシステム障害について提言や意見が述べられても、執行部門がそうした提言や意見に基づいて具体的な行動をとらなかったことが問題だとした。　ー

なぜ、12ヶ月で11回のシステム障害が発生したのか。原因、背景、真因を徹底的に検証した作品。

15個の「なぜ」とか、読んでいて止まらない面白さ。知的興奮を呼び起こす作品。