日経コンピュータのレビュー一覧

システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識

仕事でシステム保守をしているので、明日は我が身という気持ちで読みました。
設定ミスや操作ミスの話は肝が冷えました(笑)

企業名などは伏せられた状態でいろんな原因のシステムダウン事例が紹介されていて、不謹慎ですがこういうトラブル系の話を読むのが好きなので面白かったです。

どれだけ万全に対策をしていてもダウンは起きるので、発生したときに「見直す機会ができた」と前向きに捉えるという話は、なるほどなーと思いました。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

噂でしか知らなかった、みずほ銀行のシステム障害がなぜ起きたか、システム統合の道のりがどうだったか、細かに知ることが出来た。
結果論目線ではあるがアンチパターンからプロジェクト管理、品質として大事なことが掴めたように思う。しかしメガバンクの歴史と規模は凄い。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

やっとよめた
2021年に喜劇をくりかえしているし、その前に出版されたからみずほを褒める感じに書いているのが不評の原因に思うが、本質的にはレガシーシステム対する批判であり、どこにでも起こりうる地獄の一例としては学びが多い

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

みずほ銀行の大規模障害について知ってる人は多いと思うが、その原因や対策について語られているもの中々ないと思うのでその意味でとても良い振り返りではある。web系のサービス開発や運用していた身からするとある意味当たり前のことだと感じる部分もあるけど、銀行という昔からあるシステムとの差分があるなと感じた。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

取材力がすごい。ただ、用語用語は分かってもななめ読みしようとすると、さすがに体制が複雑でわかりづらかった。経営陣が全くITわかってないことが分かった。ただ、PJ終盤や震災以降の部分はかなりしっかりとしたマネジメント体制を引いていると感じた。あとはローコード開発やテストの進捗確認ツールなどについても。

業務に活かせる話としては、十分な間を取って「質問ありますか」のタイムを
設けるなど、意外と基本のところからの意識が大事だと分かった。

また、SOAをかなり早い段階から考案していたことに感心した。（障害は起きているが）
ポストモーテム編もぜひ読みたい。

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

一連の障害の事象や背景だけでなく、他行との比較や、過去の銀行統廃合とそれに伴うシステムの変遷についても触れており、学びがあった。

観点に基づき、予兆があるかもしれないという意識でチェック・レビューすること。
障害が発生した際は迅速にエスカレーション。BCP訓練時の想像力。
また、それらの仕組み化。

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

ニュースで流れていたが、
実際にどんな被害があったのか（一般の方は、キャッシュカードが出てこない、電話繋がらない）が鮮明な書いてあります。

また、それにおける次々と起こる問題。
下手なノンフィクションを読むより全然タメになる内容が、多数ありました。

システルトラブルの事例として、参考に良い一冊でした。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

みずほ銀行のシステム障害は利用者として経験？してきましたが、この本を読んでその原因の一端が分かったような気がします。

特に第三部は……登場人物が多すぎて、誰が何を考えていたのかを理解するだけでも大変でした。これでは上手く行かないなと思いました。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

自社のシステムに対する経営層の理解不足、トップダウンで自社の進むべき道を指し示せなかったこと、現場レベルでのすり合わせ・協議となり方針が決められないことなど、大規模システム開発において失敗する要素が詰まっている。システム統合となると過去のやり方を変えることになるので現場レベルでは収束しないため、どれだけトップが悪者になって推し進めれるかが肝だと感じた。

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

組織のしがらみや歪みが究極的に煮詰まって、システム障害という形で発露したと感じました。また組織運営を行う上で、貴重な事例の一つとして定期的に読んでおります。いわゆる会社の上層部と呼ばれる方もこの本は他山の石として読んだほうがいいと思います。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

・みずほ銀行のシステム刷新までの過程と2度のシステム障害の背景について詳細に解説している一冊

・エンジニアとして一応読んでおくかと思い手に取った
・みずほ銀行の新システムがいつまでも完成せずにサクラダファミリアと呼ばれてることは知ってたけど大きいシステム障害を2回起こしてることをまず知らなかった

・金融というお金が密接に関係する業界で大きなシステムを統合するのはさぞ大変だろうと関係者を労いたい
・みずほFGは2度の失敗から学び、システム刷新という大仕事を乗り越えて組織として強くなったんだなと思う
・1度目のシステム障害については3行統合後の内部での争いが結果としてシステム障害に繋がっていてヤレヤレという印象
・2度目のシステム障害については、たしかにシステム周りの知識不足な経営層が大きな原因の1つではあるけど、同じように知識不足な経営層がいる企業はたくさんありそうなのでこれを糧に我がふり直す企業が出てくればいいなと思う
・そしてエンジニアの仕事が増えて欲しい笑
・MINORIを活用したみずほ銀行のこれからのIT戦略に期待

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

前半はみずほこんなことやって頑張ったぜ！ドヤ！みたいな内容。生のコードを書けなくして属人化を防ぐ超高速開発ツールなど、なかなかおもろい仕組みを使っていたのが興味深かった。しかし、ツール名が「超高速開発ツール」というのがダサい。
コロナが流行る前からWeb会議を使っていたのは先進的だと思う。（とはいえ、私もIT企業に勤めていて、コロナ前からWeb会議使ってたから、IT企業的には普通なのかしら）

後半がめちゃくちゃ面白かった。2011年と2002年のシステム障害の発生の原因について細かく描写している。仕様書やデータフローがなかったり、合併時のシステム統合の際に役員の中に有識者がいないなどとにかくやばい。システムくらい勉強しろよ。
エンジニアが本当に気の毒。
社内政治とか読み物としては面白かったけど、当事者にはなりたくないと思った。
みずほのシステムの関係者の皆様お疲れ様です…

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

みずほ銀行の一連の障害についてとてもわかりやすく纏められている本。自分の職業柄、涙と冷や汗なくしては読み通せなかった……
特に2022年2月の大障害（ATMにカードが吸い込まれ続けたやつ）については、事前の開発時にも運用手順でもたくさんの「たら、れば（防げたのに）」網があったのに、全て突破してしまった結果なんだなと。人の振り見て我が振り直せ。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

障害発生とその対応の話は学ぶべきことが非常に多い。規模も業界も違うが頷ける話が多かった。

大規模障害の原因を突き詰めると個々のプログラムの品質よりも組織の風土や統制、経営層の理解といった部分へ通じてくる。

システムは人が作って運用している以上、
どの企業でも本書のようなことが起こりうることは知っておかなければならないと感じた

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

どこかで読まねばと思いつつ、ようやく読んだ1冊。幸いというかエンジニアのキャリアの中でこのプロジェクトに関わることはなかったけれど、当時「ブラックホール（＝行ったら帰ってこれない）」と呼ばれていたプロジェクトを全体感に立って振り返っていて大いに横展開できる反省点は盗もうと思った1冊だった。やっぱりエラーハンドリングもそうだけど、初動とトップのITへの理解が大切。もし自分が関わることになっていたとしたら、どの辺を担当することになってそこで力を果たして発揮できただろうか、とか思いながら読んだ1冊でした。

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

日経コンピュータは"みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」"を出版してしまったという黒歴史も踏み台に、120%の検証報告書を見事に作りあげて出してきました。
「マルチベンダーが必ずしも悪いわけではない」とはあるけど、やっぱりマルチベンダーは悪だよね。
でも根本原因は第一勧銀と富士の間で「どっちのシステムが良いか」を現場でベンダーも巻き込んで延々と議論させた挙句に政治的決着で処理した当時の上層部じゃないか？というのが感想。
にしても通帳やカードを飲み込んでも吐き出せない仕様のATMとか英国かよ！？と。

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

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

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

昨年幾度もニュースを賑わした、みずほ銀行のシステム障害の事後検証報告をまとめた一冊である。
著者にあたる日経コンピュータは、今回問題が発生したみずほのMINORIシステム稼働直後に開発の経緯をまとめた本を出しているが、そちらは未読。どうやらMINORIシステムの開発過程を高く評価するスタンスだったようで、障害が発生してから手のひら返しかよと批判もあるようだけど、ひとまずそれは脇に置いて、本書に絞った感想を書いてみようと思う。

本家の報告書を読んでいないのであくまで印象だが、基本的には公になってる事実以上の障害の「真因」には直接的に踏み込んでいないように読める。
一応日経コンピュータ編集部の「考察」は所々で散見されるし、実はよく読むと言外に見えてくるものもあったりするんだけど、今回のシステム障害の事象に限っていえば、報告書の整理整頓にとどまっている印象だ。
もちろんそれは報道の正確さを求められる新聞社の系列雑誌の態度としては正しい。
であれば一般に公開されている報告書を読めばいいじゃん、となるところだが、さすがにそこはプラスアルファがあって、MINORIシステムの統合の歴史を振り返ったり（各ベンダーの覇権争いの話とかがあって、個人的にはここが一番面白かった）とか、他のメガバンクや海外での障害事例などが出てきたりしているところが本書のオリジナリティであろうかと思う。

先に「報告書の整理整頓」と書いたが、実はその点に関してはあまりうまくいっていないようにも思える。
一番気になったのは同じ内容の繰り返しが多い点で、例えばインデックスファイルの更新上限が64万件の話なんかは、正直分かったからもういいよという感じがした。
報告書ではない一般向けの書籍なのだから、内容の水増し感を出さないよう、もう少し構成を工夫すべきだったのではないだろうか。

本書はBtoCのシステムを発注する側、特に情報システム部の責任者は読んでおいたほうがいいと思う。
一応自分もシステム開発に携わっている人間なので、言い訳に聞こえたら申し訳ないのだが、テスト等による信頼性向上の取り組みに開発側が全力を挙げることを前提にしても、残念ながらこの規模のシステムであれば、バグを完全に無くすことはまず不可能である。
なので、もし障害が発生した場合に備えてシミュレーションを数多くしておく必要もあるだろうし、それでも事前に全ての問題発生を予見してマニュアル化するのは不可能なのだから、重要なのは有事の際にリスクを最小化する判断を責任者がスピード感をもって下せるか、結局ここに尽きるのかなと思う。
そのあたりの危機意識がみずほの関係者に不足していた、というのが本書から導き出された私なりの考えである。

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

20220519-0604　多発するみずほのシステムトラブルを、日経コンピュータ社員も被害にあった当日のドキュメンタリーが生々しい。こういう記憶は(事故や災害でも)日々薄れていくものだから、アーカイブとして残していく必要性を痛感した（だからこそ「動かないコンピュータ」の連載は続くのだろう。）糾弾・告発からは一歩引いて冷静に分析している。報告書って感じ。

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

システム開発・運用に関わった経験があれば、読み進めるごとにキリキリとした不安な気持ちを感じるリアリティに溢れる良書。

「経営の責任」が伏線となって障害の増幅要因としてヒットする様は出来のいい小説のようでもあり、類似の伏線が実は今の日本に多数転がっているという示唆はホラーのようでもあります。

プロジェクトに関わる方は、一度手に取られると良いと思います。