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

日経コンピュータ

日経ＢＰ（2022/03発売）

• サイズ 46判／ページ数 312p／高さ 19cm
• 商品コード 9784296110919
• NDC分類 338.5
• Cコード C0055

出版社内容情報

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

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

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

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

感想・レビュー

※以下の感想・レビューは、株式会社ブックウォーカーの提供する「読書メーター」によるものです。

[KAZOO]

2年前にこれと同じ日経BP社から出された「みずほ銀行システム統合、苦闘の19年史」と対で読むと面白いですね。マッチ、ポンプのような感じです。前の本ではほめて今回のは1年間で10以上の障害を出したのでかなり厳しい対応となっています。もともと日経BP社はIT大賞をみずほのシステムに対して与えてていますがおかしなことで、見積金額をはるかにオーバーししかもと工期を2度も延長したプロマネがなっていないシステムに対し何で与えたのでしょう。この本はその禊なんですかね？分析はきちんとしてくれたようですが

2022/04/02

[Willie the Wildcat]

1年間で計11回のシステム障害を”強弱”で分類し、構成図も含めて論理的に考察。妥協の産物がコトの発端となり、金融庁が真因を要約。本題の障害分析は、他者批判ではなく、自己点検の意味で振り返る。Tech/Ops両面での指揮官不在、ワークフローもない旧石器時代のITSM、仕様記載不備・監視設定無し・PD時のログ未確認などのイロハの問題、MIMもF2Fの会議やメール連絡に拘る危機感のなさ、全てが本質的な課題。一方、疑問#12「SOA」の件は、元開発SEとして違和感。技術屋は最善と考える技術を追求するのも仕事也。

2022/03/22

[TATA]

みずほ銀行の数度にわたるシステムトラブルの分析内容。どうしても後付けで悪く書かれるだろうからある程度割り引いて読まなきゃと思っていたけども、金融インフラを支えるということはいかに困難なのかと思い知る。言われたことしかやらない風土とかアレコレと辛辣な指摘はあるわけだけど半ば公益企業としての振る舞いはあるべきなのだと。被害が拡大する様は読んでてゾッとします。普段からの備えを行うことこそ巨大インフラを支える企業のなすべきこと、なるほどな。

2024/06/27

[ゲオルギオ・ハーン]

本書を読むことにしたのは「前作の『苦闘の19年史』で褒めていた割にまた障害が起こったことをどう説明するのかな」という意地悪な理由からだった。システム的な説明もしているが、金融庁が指摘しているとおり、システム的にも問題はある(勘定系システムを４つのベンダーの共同作業にしていること、SOAをアピールしているがあまり強味になっている感じがない)が根本的にはみずほ銀行自体の体制に問題があるように読めた。日経コンピュータは前半で批判しているが、後半でいきなり同情的に弁護していくため八方美人な印象が強い。

2022/08/04

[白ねこ師匠]

［★★★／△］みずほ銀行で2021年2月から2022年2月の12ヶ月間に繰り返し発生したシステム障害について、企業風土などにも切り込んで原因を分析した詳細な事後検証報告。この業界に携わる人なら一読しておいた方がいいと思う。分かりやすく書こうとする筆者の努力が随所に見られ好感を覚えたが、それでも難解。初めの事象説明の章で、まずい点がいくつも重なってどんどんと深みにはまっていく経緯は、読んでいていたたまれなくなり読み進めるのが辛かった。

2022/09/03