みずほ銀行システム統合、苦闘の19年史 の商品レビュー

日経コンピュータ(著者),山端宏実(著者),岡部一詩(著者),中田敦(著者),大和田尚孝(著者),谷島宣之(著者)

2021/04/13

奇しくもMINORI稼働後最大の障害(2021/2,3)発生直後に本書を読むことに。。
まず、本書の構成に違和感があった。合併後の障害→3.11後の障害→MINORI構築と、時系列順にした方が、物語としては読みやすい。そうしなかったのは、失敗からの成功譚として安直に受け取って欲しくなかったからか？
ただし、全編を通して良かったのは、ユーザ企業上層部の考え方と、その後の顛末が記されていることだ。
本書の想定読者としては、①担当者レベルのシステム部員、またはベンダー、②意思決定者レベルのユーザ企業上層部が考えられる。①の人は本書を読むだけで、(記載は少ないが)現場の苦労が透けて見えて、頷くことばかり、関係者を労いたくなる気持ちになる。ただし、本当に読んで欲しいのは②の人。経営側の思いなくしてシステム開発の方向性は見えないし、業務プロセスのTOBEをユーザ企業主体で描かない限り、新規開発は頓挫する。決断の先送り、人任せが、時間も人手(費用)も浪費することになることを肝に銘じた方が良い。
MINORI開発のくだりはキレイにまとまりすぎてる感があるが、システム面で人が育ったのは事実だと思う。興味を持った方は、一読の価値はあると思うのでお勧めしたい。

※2021/4にみずほから出た再発防止の中間報告も併せて読むと、興味深い。

2021/03/31

今回のは苦労の末他行に比べて新しいものになりましたよ、以前は外から見てもひどいものでうち（日経コンピュータ）は指摘してきたけど、指摘したとおり駄目な感じで2度も事故りましたよ。という感じの内容。
しかし今を美しく書いても2021年にまたも大規模障害を起こしてしまった事実はあり、今読むと下手な味わい深さが出てしまっているように思う。
その2021年に起きた結果の一つはどうあれ、あまり得るものはなかった。結局みずほは組織として外から見たシステム組織、言語化できない経験以外にどこが変わって良くなったのだろう。

2021/03/31

経営統合においてシステム統合がいかに大変か、その時におけるそれぞれの会社閥間の争い含めてよく分かる。みずほが経験した統合における苦悩、大規模なシステム障害は、日経コンピュータが統合前からずっと指摘してきたことだが、それをみずほ側は事あるごとに否定してきた。つまりこの書は日経コンピュータからの「ほれ見たことか」をまとめた歴史の書でもあり、システム統合を甘く見てはいけないという教訓が詰まっている。

2021/03/22

工数35万人月、4,000億円もの巨費による、新勘定系システムMINORIの開発。
その開発ストーリーだけでなく、過去２回の大規模システム障害についての発生要因等も分析、記載されている点が面白い。
2021.3月時点、ここ最近立て続けに障害が起きているが、果たして過去の経験は活かされているのだろうか。

2021/03/21

みずほ銀行の2回のシステムダウンの全貌が日経BPの雑誌の記事などを基に記録された本である。システムダウンの真相やその後の展望が克明に描写されている。先日もATMのシステムトラブルが起きたばかりなので、この本とニュースを中心にこれからのみずほ銀行の行く末を見守りたい。

2021/02/20

日経コンピュータ記者の視点でしかないので、各社経営層、各社現場の視点でも知りたいがまずは赤裸々な内容が
基幹システムに携わったことがないので腹落ちはないのだけれどITに関わる者にとって読んでおきたいかなと思う

2021/02/23

勘定系システム MINORI
SOAサービス指向アーキテクチャ　日本IBM製メインフレーム
「片寄せ」ではなく全面再構築　世界最大級
　2011年6月開始　2016年3月完了予定　2017年7月完成　2019年7月移行完了
　4000億円台半ば　35万人月（単価100～120万） 東京スカイツリーの7倍

1980年代　第三次オンライン 勧銀「STEPS」、興銀「C-base」、信託「BEST」
　ブラックボックス、バッチ処理、紙出力、

2000年　三行統合　戦略IT投資の教科
　STEP1 ハブシステム整備
　STEP2 周辺システム
　STEP3 勘定系システム

銀行　　預金　融資　為替
MINORI 3要素　業務アプリケーション　Customer Information File　取引メイン
サービス単位各コンポーネントの疎結合　耐障害性
旧システムの店番CIFから 顧客番号をキーに

ASISの要件定義を禁止
工程設計ツールXupper使用　　用語の統一
要件の対面での説得
研修　3年がかり　イメージ→体験→練習

効果
コスト削減
　アプリケーション開発費3割削減　1システム化による運用コスト削減
　事務フローのシステム化　店単位の処理からセンターへ集約
　Fintech　キャッシュレス決済の台頭
APIゲートウエイ
　オンライン融資が2日間で可能に

東日本大震災　義援金振り込みでシステム処理上限をオーバー
翌朝のオンラインに影響　2重振り込みも
1988年システム稼働から上限値設計を変更せず　費用と刷新リスクを嫌う？
自動運行異常時のシナリオなし
ATMオンラインを停止しバッチ処理実施　10日間の異常事態

2021/02/17

相当なプロジェクトだったらしいと噂には聞いていたが、35万人月、4000億円規模という数字を見て途方もないと感じた。金融系の基幹システムってやっぱやばいんだな…。
システムの老朽化やブラックボックス化、仕様の人依存、緊急事態発生時の対応フローの整備の甘さ、経営陣のシステムへの理解不足などの状況に直面しているは企業は結構多いのではないかと想像している。みずほ銀行は大規模な障害を数度起こし、ユーザーに多大な迷惑をかけてしまった事実はあるものの、SOAを採用して運用保守・障害発生時のことをあらかじめ見越した設計にするなど失敗から学習して落とし込んでいる姿勢は想像できた。
改めてシステムは生き物であると感じた。

2021/02/15

4月から金融機関に就職予定なので、同業の本を読んでおこうと思い、購入。

新システム「MINORI」ができる前の銀行員、めちゃめちゃ大変だっただろうなぁという感想が正直な所。人々の信頼を得ていなければならない銀行の中でも3メガの１つが、こんなに杜撰な管理体制だったことに少し驚いた。

大学の文系同期が春から某金融機関に勤めることになっているが、届いた辞令はシステム部門。
この本を読んで〈システムの重要さ〉を感じていた私は、「ゴリゴリの文系をシステム部に配属させて大丈夫なんか？」と感じた。
彼には頑張って欲しいものです。

2021/01/30

大変だったと良く聞くみずほの勘定系統合。

ブラックボックス化、コンティンジェンシープランの不備、トップのIT理解不足、なんとかやれますという、などとそれぞれは大なり小なりどこでもありえること。
これを機に、問題発生時の対応の自戒としたい。

また、今回の問題の根本原因を経営判断であるとしていること、当時のメディア報道で的外れな報道の指摘は、当時のニュース等だけからではわからないところでよかった。