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

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

2024/09/16

障害発生内容や経緯や対応読んでると、こんなの自分だったたえられない（たえたくない？）なと思いました。 恐ろしい過ぎる……。 また本プロジェクトを完了に導いたのはその手法共に凄いなと、素直に感心しました。

2024/08/16

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

2024/07/15

2004年の3銀行経営統合時と、2011年の東日本大震災義援金振込時に起きた計2度の大規模システム障害について、技術的な側面からみずほの人物的な側面まで幅広く原因が述べられている良本だった。
特に印象的だった部分について述べる。

・4章
▶︎ MINORIへのシステム移行に伴い、実際にシステムを使う営業店で働く人々へ教育する機会を設ける必要があった。そこで、特定職(一般職？)の女性170名が講師となり、1人4店舗ほど受け持って講師として活動した点
▶︎日頃自分の指定したエリアを出ることがない一般職の人達に協力をお願いして、エリア外の地域の支店をも受け持ってもらっていたという事実から、みずほのMINORIへの本気度をヒシヒシと感じ、感動した

・p206付近
▶︎3銀行経営統合時、勘定系をどの銀行のものを軸として統合すべきか話し合いが行われていた際、合理的に見れば富士銀行(IBM製)の勘定系に統合するのが良いことが分かっていたが、富士通のメインバンクであった第一勧業銀行が富士通製の勘定系を使っていたことから簡単に富士通を切ることができず、システムの追求とは別軸で不毛な争いが発生してしまっていた点
▶︎今まで3行のシステムをすんなりと1本化しなかっったなんてバカバカしいと思っていたが、特に取引先と密に関わっている銀行業のシステムを考えた時そうは言っていられないんだろうなと、銀行業故の人と人、企業と企業の繋がりの難しさに感服した。

2024/05/06

積読が続き３年越しで読了。改めてIT・システムは経営や人・組織の問題であることを意識させられる。大なり小なりどんなシステムでも当てはまることが多く、システム企画・導入・運用に関わる人は一度読んでおいたほうがよい。

2024/03/09

前半の概要説明は少しシステム的な知見のレベルが高め。
その後の過去の大きい失敗要因については、ヒューマンエラーの背景が説明されていて面白い。

次がまだあった、というのも面白い。

2024/02/18

・統合時と震災時の2度の大規模障害と、その再発を2度と起こすまいと意気込んで作られたMINORIの開発経緯がファクトベースで記載された一冊
・過去に当行との接点がある身としても、且つその後再度大規模障害を起こしているのを知りつつも、という2点から、興味深くかつ冷ややかな目線で読み進めた
・旧行の軋轢に起因する事象や、坂井社長の「人は育った」という言葉からも、システム周りも最後は人なんだと改めて感じた。だとしたらなぜまた21年の障害が、起こってしまったのか、ポストモーテム(いわゆる日経の言い訳本)も拝読したい

2023/10/25

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

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

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

2023/06/17

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

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

2023/03/21

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

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

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

2023/03/07

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