あらすじ
なぜ繰り返すのか、メガバンクの失敗に学ぶ
みずほ銀行で2021年2月からの12カ月間に11回ものシステム障害が発生した。
2002年、2011年と大規模システム障害を起こし、それを反省して2019年までに勘定系システムを全面刷新したみずほ銀行だったが、トラブルは繰り返された。
システム障害はなぜ起きたのか。みずほ銀行ではなぜシステム障害が繰り返されるのか。
情報システムは人が開発・運用するものでトラブルは避けられないのだから、情報システムを利用する組織には、システム障害が起きても顧客や業務に影響を与えないで済ませられるレジリエンシー(復元性)が必要だ。
情報システムの専門誌「日経コンピュータ」が執筆する本書は、みずほ銀行の失敗を教訓に、組織のレジリエンシーを高めるための方策を探る。
感情タグBEST3
Posted by ブクログ
ITインフラの保守、運用に関わる者としてゾッとする話でしたが、非常にためになりました。
前に読んだ「みずほ銀行システム統合 苦闘の19年史」よりも、障害内容に対する考察（なぜなぜ）が深い。
Posted by ブクログ
2021/2-2022/2の11回にわたるシステム障害について書かれている。
面白かったのは2・4・5章（≒障害発生回数）。
事実が書かれていることと、内部精通者がいるのか？というくらいに詳しく書かれていて面白い。
銀行システムを担当するエンジニアは全員読んだほうが良い良書。逆に、銀行システムを担当していても、システムを触ったことがない担当者だと、描いてある内容でわからない部分は多いような気がする。
Posted by ブクログ
前作でシリーズ完結っぽかったところ、新展開でまた新作が読めた。「気付かなかった」「見落とした」が何回出てくるのか、という所が個人的には今回ツボった。MINORIの各部の健康状態をリアルタイムでインフォグラフィクス化して公開、とかすると良いんじゃないかと思った。HDDの弾が死んで黄色になって、4時間後には交換して緑に戻って、みたいなの、インフラ屋はやるけど、世間の人、知らんだろうし。僕は、割と大きいシステムをベンダから引き継いだ時、それまで引き渡す立場だったので、これはブラックボックスで掌握感がないって感じて、それが後にLC4RIに繋がったりしてる。そこを運用現場がどう感じてたのか気になるかな。これは所与で改善できませんとかだったら、まあ仕事楽しくないよね。
Posted by ブクログ
最近の仕事で、みずほ総研（MHIR）の方と一緒に働いているのですが。
有名なみずほFGの各障害が詳細に記載されていて
その原因追及や、根本原因などの分析が秀逸
SEとして読んでいて、よく理解できて、
身につまされる内容。
さらに、今の関連しているPJTと悪い部分が非常に
よく似ている。
今回のPJTでも、なんなりの障害は発生しそうである。
関連者に読んでほしいと思われます。
Posted by ブクログ
ー 金融庁はこうしたシステム上やガバナンス上の問題点が発生する「真因」として、「①システムに係るリスクと専門性の軽視」「② IT現場の実態軽視」「③顧客影響に対する感度の欠如、営業現場の実態軽視」「④言うべきことを言わない、言われたことだけしかしない姿勢」があると指摘する。
この中でひときわ目を引くのは「④言うべきことを言わない、言われたことだけしかしない姿勢」だ。金融庁は具体的な例を2つ挙げている。1つはみずほ銀行でシステム障害が発生した際、経営トップが障害の第一報を受けても、具体的な指示を出さなかったことが問題だとした。もう1つはみずほFGの取締役会でシステム障害について提言や意見が述べられても、執行部門がそうした提言や意見に基づいて具体的な行動をとらなかったことが問題だとした。 ー
なぜ、12ヶ月で11回のシステム障害が発生したのか。原因、背景、真因を徹底的に検証した作品。
15個の「なぜ」とか、読んでいて止まらない面白さ。知的興奮を呼び起こす作品。
Posted by ブクログ
良書。読み終えたとき、銀行の勘定系システムを知るには、うってつけのテキストと感じました。情報システムの関係者へ向けたメッセージです。
表題のポストモーテムとは、事後検証報告書（直訳は、検視、死体解剖）、要は事後の振り返りです。
コンピュータの仕組みを知らない方は、読み進むのは、難しいかもしれないが、かじったことのある方であれば、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章 各再発防止策が集約されています
目次は以下です。
はじめに
第１章 前代未聞、１２か月で１１回のシステム障害
第２章 行内で何が起きたのか、システム障害の真相
第３章 なぜ障害は拡大した、１５個の疑問
第４章 金融庁が分析する「原因」「背景」「真因」
第５章 障害を繰り返すみずほ銀行のシステム、その歴史を紐解く
第６章 なぜみずほ銀行でだけ、何度も障害が起きるのか
第７章 みずほ銀行は立ち直れるのか
おわりに
Posted by ブクログ
良書。前作よりも専門的な説明に踏み込んでおり、詳しい人によりわかりやすくなっている。慣れない人でも、うまくその後の説明で補足を入れてるので、たいへん気を使って書かれた本だなという印象である。
現場のエンジニア、特に運用寄りのエンジニアは読むのが良いと思う。ただ、夜寝る前に読むのはお勧めしないけれど。
Posted by ブクログ
システム開発に携わる立場から見ると、要件定義やプロジェクト進行のみならず、リリース後の監視・運用保守体制がいかに重要であるか痛いほど伝わる事例集となっていた。
システム障害の事後検証報告ということもあり、IT業界の人間でなければ文中に出てくる用語や仕組みの理解を深めるのは難しいものと思われる。
しかしながら、本書では障害発生時における顧客対応・危機管理面において、みずほ銀行の組織態勢不備が大きな課題として挙げられている点にも注目したい。
「積極的に声を上げることでかえって責任問題となるリスクをとるよりも、自らの持ち場でやれることをやっていたといえるための行動をとる方が、組織内の行動として合理的な選択になってしまう」（システム障害特別調査委員会の調査報告書より）
このような悪しき企業風土は、一定の規模感をもった組織であれば、どこでも発生しうる可能性は多分にあるだろう。日頃から部署間の連携やコミュニケーションをスムーズに行える体制づくりをすべきだということを、改めて思い知らされた一冊である。
失敗から学ぶ文化の醸成は、もはやどの組織でも必要不可欠な要素となっている。本ポストモーテムの知見が広く共有されることで、自らシステムの課題発見や解決方法の模索ができる人材がひとりでも多く育成されることを願っている。
Posted by ブクログ
みずほ銀行の大規模障害について知ってる人は多いと思うが、その原因や対策について語られているもの中々ないと思うのでその意味でとても良い振り返りではある。web系のサービス開発や運用していた身からするとある意味当たり前のことだと感じる部分もあるけど、銀行という昔からあるシステムとの差分があるなと感じた。
Posted by ブクログ
一連の障害の事象や背景だけでなく、他行との比較や、過去の銀行統廃合とそれに伴うシステムの変遷についても触れており、学びがあった。
観点に基づき、予兆があるかもしれないという意識でチェック・レビューすること。
障害が発生した際は迅速にエスカレーション。BCP訓練時の想像力。
また、それらの仕組み化。
Posted by ブクログ
ニュースで流れていたが、
実際にどんな被害があったのか（一般の方は、キャッシュカードが出てこない、電話繋がらない）が鮮明な書いてあります。
また、それにおける次々と起こる問題。
下手なノンフィクションを読むより全然タメになる内容が、多数ありました。
システルトラブルの事例として、参考に良い一冊でした。
Posted by ブクログ
組織のしがらみや歪みが究極的に煮詰まって、システム障害という形で発露したと感じました。また組織運営を行う上で、貴重な事例の一つとして定期的に読んでおります。いわゆる会社の上層部と呼ばれる方もこの本は他山の石として読んだほうがいいと思います。
Posted by ブクログ
みずほ銀行の一連の障害についてとてもわかりやすく纏められている本。自分の職業柄、涙と冷や汗なくしては読み通せなかった……
特に2022年2月の大障害（ATMにカードが吸い込まれ続けたやつ）については、事前の開発時にも運用手順でもたくさんの「たら、れば（防げたのに）」網があったのに、全て突破してしまった結果なんだなと。人の振り見て我が振り直せ。
Posted by ブクログ
日経コンピュータは"みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」"を出版してしまったという黒歴史も踏み台に、120%の検証報告書を見事に作りあげて出してきました。
「マルチベンダーが必ずしも悪いわけではない」とはあるけど、やっぱりマルチベンダーは悪だよね。
でも根本原因は第一勧銀と富士の間で「どっちのシステムが良いか」を現場でベンダーも巻き込んで延々と議論させた挙句に政治的決着で処理した当時の上層部じゃないか？というのが感想。
にしても通帳やカードを飲み込んでも吐き出せない仕様のATMとか英国かよ！？と。
Posted by ブクログ
みずほ銀行のコンピュータ障害の事後検証報告書。日経コンピュータの記者が執筆。ふ～ぅ。読みでがあった。なぜみずほ銀行のコンピュータ・システムが何回も障害を起こしたのかの謎をひも解く。読んでみて、みずほ銀行のシステムは他行のシステムとはずいぶんと異色であることが分かった。システムが疎結合でマルチベンダー・システムであることだ。他行はシングル・ベンダーで緊密結合システムが多い。そのため、システムが複雑になり運用でも難しさがある。その運用をみずほ銀行は軽視していたようだ。エラー・ログの抽出検索システムもなく、障害時には生のエラーログを画面で逐一調べていたというのは驚きだった。
Posted by ブクログ
昨年幾度もニュースを賑わした、みずほ銀行のシステム障害の事後検証報告をまとめた一冊である。
著者にあたる日経コンピュータは、今回問題が発生したみずほのMINORIシステム稼働直後に開発の経緯をまとめた本を出しているが、そちらは未読。どうやらMINORIシステムの開発過程を高く評価するスタンスだったようで、障害が発生してから手のひら返しかよと批判もあるようだけど、ひとまずそれは脇に置いて、本書に絞った感想を書いてみようと思う。
本家の報告書を読んでいないのであくまで印象だが、基本的には公になってる事実以上の障害の「真因」には直接的に踏み込んでいないように読める。
一応日経コンピュータ編集部の「考察」は所々で散見されるし、実はよく読むと言外に見えてくるものもあったりするんだけど、今回のシステム障害の事象に限っていえば、報告書の整理整頓にとどまっている印象だ。
もちろんそれは報道の正確さを求められる新聞社の系列雑誌の態度としては正しい。
であれば一般に公開されている報告書を読めばいいじゃん、となるところだが、さすがにそこはプラスアルファがあって、MINORIシステムの統合の歴史を振り返ったり（各ベンダーの覇権争いの話とかがあって、個人的にはここが一番面白かった）とか、他のメガバンクや海外での障害事例などが出てきたりしているところが本書のオリジナリティであろうかと思う。
先に「報告書の整理整頓」と書いたが、実はその点に関してはあまりうまくいっていないようにも思える。
一番気になったのは同じ内容の繰り返しが多い点で、例えばインデックスファイルの更新上限が64万件の話なんかは、正直分かったからもういいよという感じがした。
報告書ではない一般向けの書籍なのだから、内容の水増し感を出さないよう、もう少し構成を工夫すべきだったのではないだろうか。
本書はBtoCのシステムを発注する側、特に情報システム部の責任者は読んでおいたほうがいいと思う。
一応自分もシステム開発に携わっている人間なので、言い訳に聞こえたら申し訳ないのだが、テスト等による信頼性向上の取り組みに開発側が全力を挙げることを前提にしても、残念ながらこの規模のシステムであれば、バグを完全に無くすことはまず不可能である。
なので、もし障害が発生した場合に備えてシミュレーションを数多くしておく必要もあるだろうし、それでも事前に全ての問題発生を予見してマニュアル化するのは不可能なのだから、重要なのは有事の際にリスクを最小化する判断を責任者がスピード感をもって下せるか、結局ここに尽きるのかなと思う。
そのあたりの危機意識がみずほの関係者に不足していた、というのが本書から導き出された私なりの考えである。
Posted by ブクログ
20220519-0604 多発するみずほのシステムトラブルを、日経コンピュータ社員も被害にあった当日のドキュメンタリーが生々しい。こういう記憶は(事故や災害でも)日々薄れていくものだから、アーカイブとして残していく必要性を痛感した（だからこそ「動かないコンピュータ」の連載は続くのだろう。）糾弾・告発からは一歩引いて冷静に分析している。報告書って感じ。
Posted by ブクログ
しっかりと中立的に書かれている印象。マルチベンダやレガシーさが障害を呼んだのではなく、システム運用やシステムへの軽視が根底ということがよくわかった。
システム技術のリテラシーや勘所がある人が企業トップにいないとダメだと思う、、システムは利用するのは簡単だが、とても複雑でそれを開発運用できる人材はポコポコいるわけではない、ということを経営者たちは本書を読んで理解するべきだと思う。
Posted by ブクログ
2019年に満を持してリリースされた新システムが2021年2月からの1年間で計11回のシステム障害を引き起こしてしまったみずほ銀行。その事後検証報告からの学びを目的として書かれた一冊。前著に当たる『みずほ銀行システム統合、苦闘の19年史』がプロジェクトの進め方の話が中心だったのに対して本書はかなり技術寄りの内容。非エンジニア職の人にはハードルが高いと思われる。その分エンジニアには多くの学びを提供してくれる。また、後世に残す記録としても重要。冷笑・嘲笑でネタ的に消費するのではなく（みずほ銀行を笑えるITエンジニアは真に優秀か超の付く能天気のどちらかだろう）自身の担当システムで本質的に同じ原因の問題が起きないか考えながらじっくり読みたい。
Posted by ブクログ
専門用語も多く、システム素人の私には難しいところもあったが、システム障害の全体像・問題点が分かりやすく整理されている。いくらみずほFG・みずほ銀行が対外公表している資料を読み込んでも、理解はできないだろうが、本書のおかげですっきり分かった。
旧3行のシステム駆け引きから、すでに不幸が始まっており、何度も障害を繰り返しながらも抜本的なアクションがとられなかった。唯我独尊で、他のメガバンクや海外の動向から学ぶことはあろうに、忖度や馴れ合いの結果、不確実性を増していったということだろう。
私が一昨年まで暮らしたシンガポールのネットバンクは、UIが良く統一感があり、大変利用しやすい。一方、みずほ銀行（だけでなく他の邦銀）は、非常に操作しづらい。みずほの歴史は日本の停滞の20年と重なり合う。
本書「おわりに」で紹介されている、みずほの窓口でのやりとり。令和の時代に昭和を引きずり、一部IT機器が出てきたかと思えば、iPadではなくMINORIタブレット。。。そんなみずほもGoogleと提携したとのこと。しがらみをかなぐり捨てて、飛躍してほしい。（一口座保有者として希望。）
Posted by ブクログ
2020年にみずほ銀行システム統合史を上梓した日経コンピュータが、2021年から起こったみずほ銀行のシステムトラブルを整理した一冊。IT業界にみをおくものとしては読んでいて居た堪れなくなってしまうが、前書よりも価値のある一冊と言える。
みずほで起こったトラブルを淡々とインシデント分析を繰り返し、問題の本質に迫ろうとしている。往々にして、みずほのトラブルは三行の体制によるガバナンスの効かなさが生み出したものと語られがちだが（場合によってはドロドロの情念を絡めた読み物として）、情実的な部分を排除してあくまでシステム的観点から分析している。
この書は、みずほのトラブルに学ぶことはもちろん、インシデント分析の実施の仕方についても深い見識を与えてくれる。
Posted by ブクログ
みずほ銀行で1年に11回発生したシステム障害の内容、原因と再発防止策がまとまった一冊。冒頭から、読んでいると具合が悪くなる大規模障害の話題で、五千件を超えるカード・通帳がATMに取り込まれていく経緯が緊迫感あふれる様子で描かれる。
直近の大規模システム改修に問題があったというより、運用手順が不明確、組織の連携が遅い、障害レベルを人が判断…など障害発生後の対応が後手に回ったことが障害影響を拡大させたことが分かる。
特に恐ろしかったのが、為替送金の取引遅延障害で、遅延を取り戻すためにAML（資金洗浄防止）システムを省略しても問題ないと最高コンプラ責任者が判断し省略した結果、外為法違反した一件。現場だけではなくコンプラ責任者がこの判断をしたということで、他の業務でもちゃんと法令遵守しているか疑いたくなる。
100を超える再発防止策が形骸化しないことを願う。
Posted by ブクログ
外から見てこれだけのポストモーテムができるのだから、内部でポストモーテムして、次に活かせば、より早くより深く、改善が進むのではないかと思う。障害事象解説の図は分かりやすい。ただ、門外漢からすると細かすぎて読み物としてはちょっと飽きが来る。必要な人にとっては必要な情報なのだとは思うけれど。
Posted by ブクログ
2021年2月〜2022年2月までで合計11回のシステム障害。
冒頭から障害に関する記載の嵐。結局最後までずっと障害。
著者はITに詳しく、分かり易く伝えることをすごく意識しているのが伝わってくる。兎に角すごい取材力。
だだ、本書はITが分からない人は少し難しいと思う。
一方で、仕事でITに携わっている人であれば、アプリ、インフラ、運用のどの領域であっても、この本を読むことで、自身がこれまでのIT業務で経験した反省点を思い出させてくれる一冊。
内容の重複記載が多いのは難点。日経CPに掲載したものをコピペで纏めているからだろうか‥。
障害原因をしっかりと深掘りして、過剰なプロセスを増やすことなく、効率的にかつ適切に改善へと繋げて欲しい。
昔は運用部門には凄い怖い人がいて、アプリが持ってくる依頼を厳しくチェックして、牽制していたという話も聞いたことがあるが全体としては、アプリ＞インフラ＞運用のヒエラルキーは変わらない。
※データベースの統合を検討。IBMのIMSやdb2、富士通のSymfowareServer、日立のHiRDBの乱立を解消し運用をシンプルにとの事（備忘）
周回遅れのシステムあるある集
第１章から第３章は同じ話の繰り返しで水増し感がある。後段は、以前の「苦闘の19年史」とさして変わらず、既読感が強い。半額でいいんじゃないだろうか。周回遅れの他人の不幸は面白いし、システム屋は読んでおく必要があるだろう。同じ轍を踏まないために。
Posted by ブクログ
みずほ銀行のシステム障害に関する検証結果をまとめたもの。内容は読み応えあってエンジニアの自分にはとても役に立つ内容だった。
ただそれ以前に、みずほ銀行ダメだこりゃ。
