平成の失敗学の3部作
『システム障害はなぜ起きたか みずほの教訓』日経コンピュータ
『システム障害はなぜ二度起きたか みずほ、12年の教訓』同上
『みずほ銀行システム統合、苦闘の19年史
史上最大のITプロジェクト「3度目の正直」』同上— 空飛ぶたこやき (@ohtakoyakipon) 2020年2月15日
・2002年→2014年→2020年
みずほ銀行のやつ、目次からして強さのオンパレードなので大変良い
— ynyn (@ynyn) 2020年2月16日
みずほ本読み始めたけど、はじめにの部分で「経営トップが無知で、ITを軽視し、すべて現場任せで、金も人材も出し渋ったのが根本原因」って書いてあって思わず読み終わったかと思った。
— べーやん。 (@84bko) 2020年2月14日
第一部は次期システムMINORIの開発にかかると苦闘の歴史をドラマティックに描いており希望が持てる。
しかし一転…
第二部震災直後、「またか」の大規模障害では、みずほのシステム障害が克明に記述され、当時の判断が挽回不可能なインシデントに発展していく様子が、残酷なまでに描写されている……
— 毛糸 (@keito_oz) 2020年2月14日
「みずほ本」の2章は読んでいて辛くなる……
報告が遅れた
当然確認すべきだった
こう判断すべきだった
確かめる機会はあった
実行しなかったなど、大規模なトラブルに繋がるミスや油断が、容赦なく並べ立てられている……
— 毛糸 (@keito_oz) 2020年2月14日
第一部と二部では、雰囲気がまるで違う。
一部では苦闘の歴史が希望に繋がるようなストーリーだが、
二部では一転、残酷な事実が淡々と述べられる。
「はじめに」で感じた不穏な空気は、二部から生じていたのか……
“経営陣のIT軽視、IT理解不足が、大規模システム障害の根本的な原因だった”
— 毛糸 (@keito_oz) 2020年2月14日
みずほという名の災害の原因は統合三行の内部対立が要因というわかったようなわからんような説明については、別にみずほ関係者でもないし、このプロジェクトにかかわったわけでもないのでよくわからないんだけど、外部から見て一番ヤバイと思うのはガバナンスの欠如だと思うんですよ
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
旧みずほ銀行は、誕生した2002年から2019年にMINORIへのシステム統合が完了するまでの間、リテールを主体とする大規模システムに対して有効な投資を行ってこなかったというのが問題の本質ではないかと思う。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
端的に言えば、STEPSはかなり後期になるまで、勘定系とその周辺系システムとの接続を疎結合化するハブシステムを持たない非常に古い構成だった。これは、2000年代初め頃から、まともな銀行では取り入れられていた設計で、投資効果も非常に高いのだが、この資金すら得られなかったのは異常に思える。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
※富士通製メインフレーム「STEPS」=みずほ銀行基幹系システム
これは、MHCBのシステム(IBJの勘定系ITISを魔改造してベースがなくなってしまったC-Base)で、MHCBのトランザクション量から考えるとかなりのオーバースペック設計でハブが導入されたのに、STEPSでは導入が進まなかった例でも現れている。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
※MHCB=みずほコーポレート銀行
※IBJ=日本興業銀行
STEPSでは、リテールから公共法人取引に至るまで、無数の個別要件と個別システムが存在しているBKのシステムを担当しているので、ハブ・アンド・スポークアーキテクチャを取り入れてシステム間を疎結合にして通信方式を標準化するだけでかなりのメリットがあったはずだ
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
BK=みずほ銀行
その金すら出せなかったというのは、みずほが企業形態として、マスリテールと中小企業に特化したBKと、大企業法人と公共法人に特化したCBという二つの組織に分断され、システム開発もそれぞれの銀行の収益が原資になっていた点にあると思う。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
※CB=みずほコーポレート銀行
BKは規模もポストも多いが、収益はカミソリの刃のように薄く、CBは小規模組織だが収益はBKに対して大きいが安定しない形態。システムに使える予算も制限されて、システム刷新どころか維持自体に窮したのではないか?
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
2006年から2011年の動向こそ知りたいと思うのはそこが理由だ。この時期、次期システムをめぐってBKとCBという組織形態を残したまま、単一基盤でシステム統合を行うという機運があったはずだ。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
そこに採用されるシステムこそ、勘定系システム自体がSOAアーキテクチャで構成されたオープンシステムで、個別の構成要素をマルチベンダーで構築したシステムだったと思う。これが、MINORIの原設計だったと思う。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
しかし、2011年の第二次みずほ災害以後、組織を単一化してシステム基盤も統合する方向に進んだ。システム基盤を単一化するが業務は統合しないという方向から、組織形態を統合して業務を統合しながらシステム基盤を統一するという方向に変わったのだ。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
これは非常にまずい手法だ。時間軸としてみれば、業務統合とシステム統合を同時に行うことになるから、時速250kmで移動する新幹線の屋根の上から、上空1万mを飛行するジェット機の翼を竹槍で狙撃するようなものだ。プロジェクトがちょっとでも遅延すれば、業務に与える影響は極大でクソ金を垂れ流す
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
多大な苦労を払ったかもしれないが、メガバンクの中で最新のシステムが完成したのだからいいのではないか、という意見もあるとは思うのですが、結果から考えるとダメだったんじゃないかと思いますね。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
考えてみてほしいのだけど、20年前都銀の中で真っ先に経営統合を発表し、その圧倒的な規模と質から公取に銀行分割を統合条件にされたみずほが、20年経ってみれば規模ではMUFJに、収益面ではSMBCに圧倒されて、「3メガバンク中万年4位」と揶揄される地位に墜ちてしまっている事実がある。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
勘定系システムの刷新が、本当に競争力と収益の元になっているのか、という点で考えてみても、昭和のガバナンスで平成の最新技術で差構築して、令和に通用しないシステムになっているわけで。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
みずほのシステム再構築が、我々に対して何の利益をもたらしたかといえば、強いていうならば「企業経営でやってはならないことを、上から下まで順番に踏みつぶしてくれた」という点ではないだろうか? もはや、失敗学以前にみずほ銀行学という領域を創設してもいいくらいの題材である。
— (๑╹◡╹๑) (@tsuchie88) 2020年2月12日
//platform.twitter.com/widgets.js
Source: 市況かぶ全力2階建