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

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

発売直後から読んでみたいと思いつつ時間が経過していた。 もう忘れかけていた時に図書館で見つけて借りてみた。 星を5個つけたけど、読んだ人すべてが5個つけるとは思わない。 システム開発・運用の現場の経験がない人が読んだら理解できないこともたくさん書かれていると思う。 それでも自分が興味深く読んだのは、2002年と2011年の大規模障害の原因についてかなり丁寧に言及されているから。 2011年の大規模障害は東日本大震災の義援金受付がきっかけだった。 「一括処理」と表現されているいわゆる「バッチ処理」の何が原因で大規模障害が起きたのか、この本を読むと理解できる。 大規模オンラインシステムの開発・運用をしている人に勧めたい本。

2021年のシステム障害が起こる前に書かれた19年史。当時はうまく新システムへの移行がいったと思っていたのだが。

上層部と現場の間の連携が大事。 進捗報告、課題やゴールの共有など、上層部の意見を踏まえつつ現場からも意見を出して、協力して進めるべに。 システムは完成したら終わりではなく、稼働した瞬間から陳腐化する。 いつまで使えるのかを見極める。 時代の流れや業務内容の変遷に柔軟に対応して改修していく必要がある。 目先のリスクを見極める力が重要。 どんなトラブルが起こりうるかを予測し、トラブルを最短で打ち取るためのプランを検討しなければいけない。 トラブルをなくすことはできないので、リスク対策を念入りに行う。コンチプラン。 社名や登場人物が多くて理解するの大変。 1章、2章、3章と時間を遡るので、同じくだりが何度も出てくるのでややこしい。 読んでいて眠たくなったので、理解は浅め。

もう少し知ってる組織なら興味深く読めたかも 知らない組織の話ばかりで読むのがだんだん辛くなってきた 合併した組織にはいろいろあるね

みずほ銀行のシステム障害は利用者として経験？してきましたが、この本を読んでその原因の一端が分かったような気がします。 特に第三部は……登場人物が多すぎて、誰が何を考えていたのかを理解するだけでも大変でした。これでは上手く行かないなと思いました。

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

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

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

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

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

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

障害発生とその対応の話は学ぶべきことが非常に多い。規模も業界も違うが頷ける話が多かった。 大規模障害の原因を突き詰めると個々のプログラムの品質よりも組織の風土や統制、経営層の理解といった部分へ通じてくる。 システムは人が作って運用している以上、 どの企業でも本書のようなことが起こりうることは知っておかなければならないと感じた

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

2022年11月22日読了。2002年の三行合併時、2011年の震災義援金受付時の大規模障害を受け進めていた「MINORI」の2019年の改修完了を受け、みずほ経営陣・システムの問題点・歩み・今後への展望などをまとめた本。誇らしげに成果を語る頭取の姿からは、2021年にまたも複数の大規模障害を起こすことになる未来は読み取れない…人間てのはどれだけ過ちを繰り返せば学ぶものなのだろうねまったく。とにかく銀行のITシステムについては安易に考えないこと、経営層の責任・コミットを明確にし、全体のアーキテクチャ統括・プロジェクト進捗管理に責任を持つマネージャーを置き、コードレビューやテストに十分な時間と工数をかける、運用の自動化・効率化を図る、などなどどれも当たり前の取り組みなのだが、規模が巨大化すると細かい手抜きが目立ってくるもの、そこは「声を上げる・手を抜かない」という文化が必要になるのだろうけど…それがない組織は衰退するしかないやな。

2021年のシステム障害前に、日経によって書かれた本書。プロジェクトとしては、壮大で大変ではあったと思うが、引き継ぎ障害を起こしている今読むと、その雄弁な苦労話も虚しく響く。 しかも、肩書などが冗長に感じ、あまり引き込まれなかった。

2021年一連のみずほ銀行が起こしたシステム障害「前」に書かれた「力作」 今になってはあまりに虚しい内容となってしまった。 2002年、2011年の障害を乗り越えた巨大かつ、しなやかな（障害の極小化）システム、MINORIの完成を日経コンピュータが書いた（書いてもらった？）本。 とはいえ、この本が嘘を言っているかというと、そうでもないと思う。それなりにMINORIはベンダーを横断する中で旧行のしがらみを乗り越えてはいる。過去の障害を乗り越える訓練は行っている。 では何が問題であったか。 2022年の今この本を読み返すと、「完璧なシステムができた、次に何をしようか、コスト削減に新たなシステム開発、デジタル化、IT企業との連携」と、MINORI完成後のシステムの運用について述べていない。そして、まさに2021年2月のATM障害は、システム維持のための人材を減らして、デジタル化するための通帳レス口座への移行作業で発生した。経営陣がシステム維持運用に興味がなく、「完璧」なシステムさえできればもうシステムは忘れたいという姿勢が如実に現れている。 「完璧」なシステムはない。「安定」したシステムは何年もさまざまな特殊日、繁閑を経て、カレンダーマジックを乗り越え運用されてはじめて実現する。 日経コンピュータはこの辺わかって敢えて書いたのか、わからなかったのか。本の中身はMINORI礼賛的内容であることが皮肉に聞こえる。

私は当事者ではないけど、下衆なドタバタ劇を期待してしまって手に取った。コンサルの人が書くようなキレイなまとめに感じた。まあ、そんなに生々しくは書けないのかな。 関わった方に、おつかれさまでしたと申し上げたくなる。 仕事って辛いよなあ。

システム開発・運用に関わった経験があれば、読み進めるごとにキリキリとした不安な気持ちを感じるリアリティに溢れる良書。 「経営の責任」が伏線となって障害の増幅要因としてヒットする様は出来のいい小説のようでもあり、類似の伏線が実は今の日本に多数転がっているという示唆はホラーのようでもあります。 プロジェクトに関わる方は、一度手に取られると良いと思います。

エンジニア、ITに関わるものとして読むべきと思っていまさら読みました。4000億円とも言われる（スカイツリー7本分）予算を投じて行われた歴史上最大級の開発プロジェクトにおいて、日経コンピュータという第三者の視点から失敗や苦難が描かれています。技術的な問題はもちろんありますが、その背景にあるソフトウェア開発の本質的な複雑性や体制、経営層の意識について課題が提示されています。細かい話は読み飛ばしました。不確実性の高い中で意思設定を積み上げること、用件定義やシンプルなアーキテクチャを志向すること（リスクを的確に捉えること）が重要と感じました。

みずほフィナンシャルグループは、メガバンク史上初めてシステムを新たに再構築した。MINORIと呼ばれるシステムは、事務作業を大きく削減し、新しい機能を付加させるための開発費用を減らし、オープンイノベーションを促進する事が期待され、システムが寿命を迎える2025年の崖から転落しないよう各企業が見習うべき良いケースである。と思われていた。しかし結果は今の通りである笑 不具合続きの今から振り返ると、第1部の成功ケースよりも第2部・第3部の失敗学の方が遥かに有益であるように感じる。そもそも、失敗の原因として「システムのブラックボックス化」「風通しが悪く、責任者への報告が遅れ、対応が後手に回る」「経営陣のIT軽視」が述べられていたが、今回のシステム障害の再発防止報告書にも同様の内容が列挙されており、みずほ自体が過去の失敗から何も学んでいない事がよく分かる。トップが失敗を反省し、リーダーシップを持って再発防止に努めなければ、同様の問題が必ず再発するであろう。「再発防止チーム」みたいな組織をその場凌ぎで作り、放任しているようでは先は無い。 成功を収める企業から学べる事は多いが、再現性に乏しい事が多い。一方で失敗した企業から学べる事は、再現性が強いため、こうしたら失敗するという良い学びを得る事が出来る。多くのケースを吸収し、経営判断を迫られた際に失敗しない様にしたいと感じた。

"東京スカイツリー建設費650億円　7本分かかった →4000億なかば →35万人月 →ベンダー千社（日本のITベンダの1割） 一次委託先70-80社 ■勘定系システムとは →銀行における預金や融資、振込などの業務を支える情報システム メガバンクの勘定系システムは 計1億ステップほど →★絶句、、、 1人のエンジニアが1ヶ月で5-8行 →1000人のエンジニアが10年間開発を続けないといけない量 ■合併や企業統合は100日勝負　と言われる →統合を発表して100日以内に、統合の方針を固め、関係者一同がその方針に沿って進んでいくように、意思の統一を図る必要がある →★ITプロジェクトも一緒かもしれない、最初にその方向に向かっていくことを何度も伝えることが肝心"

良著。読んでて胸が苦しくなるし、色々な案件がフラッシュバックする。 システム部門がなんとかするのだ、専門家の責務だ。と言って上は歩み寄らず理解しようとしないが、システムの重要さは肥大化する一方。肥大化すれば、作っている最中から腐り始める。進歩の早いITシステムではなおさらだ。 銀行以外の巨大システムでは、さまざまな手法が提案され採用され、そして棄てられていく。そのように新陳代謝させられる仕組みを模索し続けれられるシステムと、組織風土は銀行に限らず、システムを中心に据えているどんな企業も必要だろう。これは銀行に限らず、基幹システムを軽視している企業に対する警鐘を鳴らす本である。

金融は情報システム産業といっても過言ではない。 自分自身金融機関に勤めているが、初めの頃は「システムは常に正確に、滞りなく動くもの」と誤認していた。 先日まで新会社立上げ・新規事業立上げを行い、システムの開発・運用を横目に見ながら思ったのは、システムには人の手がかかり、緻密かということ。そして、いくつものシステムが複雑に連動して稼働しているかということ。 みずほFGはシステムに苦心し続けてきた。その末にシステムを全面更改して「MINORI」を開発した。しかし2021年、再び度重なる障害を起こした。 この度重なる障害は、システムの全面更改が失敗したということではない。全面更改したからこそ、これまでとは違った苦難に直面している。 システムは要件定義から運用に至るまで繊細な管理が必要ということ、そしてMETIが提言する「2025年の崖」に対するヒントを、本書は圧巻の取材力で、丁寧に教えてくれる。

名実ともに日本最大となったIT開発プロジェクト「MINORI」について、その全容を記した一冊。 総開発費4,000億円超、1,000社以上が開発に携わった（少なくとも国内全IT開発ベンダーの10%以上が参画した）「IT業界のサグラダ・ファミリア」が、どのように推し進められたのかを知ることができる点で、とても貴重。 2021年現在もトラブルが頻発している現状を鑑みても、成功譚と呼ぶにはあまりにも複雑で、「苦闘の19年史」という副題が言い得て妙だと感じる。歳月をかけて肥大化したモンスターは簡単には御し難く、これから長い年月をかけて付き合っていかなければいけない問題として残り続けるんだろう。 この苦闘史から得られる最大の教訓は、リファクタリングを後回しにし続けたら、後で大きなツケを払うことになる、ということだろうか。魔物は、生み出してからではとうに遅いのだと…

以前から本の存在は知っていた。システムエンジニアとしてこの本は読んでおかなければならないのではないかと思い、読んだ。トラブルの様子が目に浮かび、途中で読むのがつらくなるくらいだった。自分はこのような大人数が使うシステムではないが、みずほ銀行の勘定系システムのようなブラックボックス化したシステムの開発・運用に関わっていた。仕様書はなく、ソースコードを読んでプログラムが何をしているか理解するような…。今はこのシステムから離れているが、あのシステムも刷新しないと大きなトラブルを起こしそうだ…。読んでいてお腹が痛くなる本であった。

みずほをこき下ろすだけではなく、システム統合の難しさと統合によって目指していた事も描かれており、公平なドキュメンタリー本だった。

システム開発に携わっているので読んでいて面白かった。 古いシステムの仕様が分からなくなるのは、ほんとあるあるだと思った

SEの立場から見て読み物として面白い。 特に障害原因の部分が為になる。 ただ、もっとエンジニア視点の みずほ公表原因に対する考察など 踏み込んだ記載が欲しかった。 著者の見える範囲の推測にとどまっている印象。 2021年に何度も障害発生しており 障害報告の内容を見ると 2011年の是正が未完である印象を受ける。 　・負荷テスト不足 　・テストのシナリオ不足 　・運用員の知識・教育不足 ■目次 ①2019年の大規模システム更改 　・更改の背景、難易度 　・新旧のシステム構成の違い ②2011年の障害と原因 ③2002年の3社合併時の問題

銀行の既存の疎結合なシステムをどう新規開発していったかがメインな話 ニュースにもなったみずほのトラブルの裏側など読み応えがあった

なぜ失敗していたのか、について主に銀行やベンダー同士の関係性まわりの事情を書いた本。ざっくり概要はわかるが、SEとしてはもうちょっとシステムに踏み込んだ内容があると面白かった。しかし割と短めに何が起こってたかをまとめてあるのはよかった。 書いてあるのは、おそらくちゃんと失敗を分析した結果ではなく著者から見えてる範囲のことな気はする。

・マネジメント層の現場理解 ・報連相を速く ・大きな組織ほど共通理解を徹底させる この３つの大切さを感じました。システムのことは専門外で私自身読み終えた今も深く理解出来ていないですが、上記３つは取り組む内容関わらず大切な項目だと思います。 私もシステム部門へ就職するわけではありませんが、現代社会でシステムは切っても切り離せない存在です。ITパスポート等を利用して基礎知識は付けておきたいと思いました。

現在も障害が起きていた中で、とても気になったので手に取りました。 マネジメントになるのであれば、 必ず以下は教訓としていきたいと思います。 ・ドキュメント化（標準化）させる事の大事さ。 ・悪い事ほど早く共有と報告、方針を打ち出す。 ・現場任せの組織は壊滅する。 色々と奥深い。

IT関係者として読ませていただきました。友人を自殺で、あるプロジェクトで失いました。みずほには、現場任せという表現がありましたが、要は、業務要件をドキュメント化して、可視化する能力が不足していたとの認識です。人の継承もなく、更新が途絶えたシステムについて、仕様、ドキュメントの振り返りなしに統合すれば失敗するにきまっている。その原因は要件定義ができる行員がいない。が結論かとおもいます。

初めに、何らかシステム開発に関わった方でないと本書の内容はチンプンカンプンだと思います。ただ、よくここまで取材したなというくらい、みずほ銀行側からすれば赤裸々な内容になっています。 システム開発における組織体制の重要さがわかります。ITのことはどうも…という経営層にこそオススメします。

有名なみずほシステムに関して、大規模障害発生時に何が起き、何が問題で、新システムはどう違うのか非常にわかりやすい本。 障害対応に当たった現場の人々の思いを想像すると震えた。 本書では新システムはかなり称賛していたように感じたが、先日もまた障害が発生していた。 新システムにも問題点があるはずなのでそれについても知りたいと思った

難しい話題。 銀行のシステムについて詳しく書かれていて興味深い それと同時にシステム障害の仔細がよくわかる

システム開発は、依頼者とベンダーが異なる組織にいるため、非常に難しいプロジェクトだと思います。みずほはこの大失敗を通して、ベンダーを管理する強い体制を組んだことが印象的です。

詳細な19年の振り返りがされているが、どうしても2021年に起きたシステム事案のせいで再発防止策が霞んでしまう。「人が育った」というのを読むとどうしても笑ってしまう。 という冗談はさておき、全く他人事では無いので読んでいて苦しかった。一番はリスク管理として全体像の把握と迅速な対応ができなかったところにあると思うが、BCPが細部まで整理できていないことはあるし、システムが大きくなりすぎると全体の把握は難しい。E2Eのフロー図を作成したとのことだが、それ自体が膨大になって結局調査に使えないとかアップデートは大変難しいという問題から逃れられない。調査対象がどうしても全量になってしまうので、それはスタートラインで、その後のユーザビリティの改善が再発防止には必須なのだと思う。 キャパシティテストがされていなかったことは結果論で見るとお話にならないように見えるが、コスト削減でテストを省力化していることはあるし、過去のテストの蓄積を確認する余裕もないのが実態なので、こうしたまさかのテスト漏れはいつ起きてもおかしく無いと思う。 話は逸れるが、遠因は邦銀（というか日系企業）の行き過ぎた顧客志向もあると思う。声の強い顧客の声に応えようとするあまりシステム設計が複雑になり管理しきれなくなることが、積もり積もってこうした障害の原因になっていると思う。業務をシステムに合わせる発想を持つべきというが、どれだけ顧客の要望に応えるかはもう少し見直されて然るべき。営業店もそうした観点で自行のシステム開発と運用に理解を深めるべきだろう。 きっと2021年の障害もまとめられるので、是非読みたい。

19年に渡るみずほ銀行のシステム統合の歴史書。MINORIは上澄みの成功譚が描かれているが、末端の現場の苦労は相当なものだったと推し測られる。

他人事ではない職のため、教訓として読んだ。 同時に良い事例でもあるので、各会社、業界で様々話し合う場が持たれると……良いなと……思った。話し合う場など今の日本社会にはないかもしれないが……。

2021/4/15読了。　 第一部:IT業界のサグラダファミリア、ついに完成す 第二部:震災直後、「またか」の大規模障害 第三部:合併直後、「まさか」の大規模障害 歴史的に振り返ると、1990年後半から2000年初頭にかけての日本経済は厳しい低迷期間が続き失われた10年とも揶揄された。その象徴として… ・記録的な低金利政策とデフレ ・不良債権の先送り ・企業投資の歴史的停滞　 そんな時代を背景に、巨大メガバンクの統合が実現して行くのだが、本書を読んでいくと苦闘の末に史上最大のITプロジェクトが大きな障害を乗り越えて 優れたリーダーの下組織が一つになり所期の目的が達成されたと思ったが、反対に日本的風土の弱点や 今日的に抱える日本的な組織の根本の弱点がわかって来た。このコロナ禍で優秀であるべき政治や官僚組織の共通項が反対に想像出来た。今後のグローバル世界に果たして日本が生き残れるか不安になって来た。せいぜい統合は早く、安く、確実にやればそれでよい！日本型経営者の質は、せいぜいその程度か。

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

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

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

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

勘定系システム 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日間の異常事態

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

4月から金融機関に就職予定なので、同業の本を読んでおこうと思い、購入。 新システム「MINORI」ができる前の銀行員、めちゃめちゃ大変だっただろうなぁという感想が正直な所。人々の信頼を得ていなければならない銀行の中でも3メガの１つが、こんなに杜撰な管理体制だったことに少し驚いた。 大学の文系同期が春から某金融機関に勤めることになっているが、届いた辞令はシステム部門。 この本を読んで〈システムの重要さ〉を感じていた私は、「ゴリゴリの文系をシステム部に配属させて大丈夫なんか？」と感じた。 彼には頑張って欲しいものです。

大変だったと良く聞くみずほの勘定系統合。 ブラックボックス化、コンティンジェンシープランの不備、トップのIT理解不足、なんとかやれますという、などとそれぞれは大なり小なりどこでもありえること。 これを機に、問題発生時の対応の自戒としたい。 また、今回の問題の根本原因を経営判断であるとしていること、当時のメディア報道で的外れな報道の指摘は、当時のニュース等だけからではわからないところでよかった。

二度の大規模障害を引き起こしたみずほ銀行のシステム開発・統合について、トラブルの内容とその原因を綴った本。 本書で得られた知見は大きく2つ。 まず、大規模システムの構成要素とその繋がりを感覚的に掴むことができた。システム関連の職種ではないが企業戦略には携わる我が身にとって、システムに関して程よい粒度感で解説されている本書は、システムというものを自分の中で一歩深めて理解するのに好適であった。 2点目として、大規模企業の統合は何が原因となって失敗し、その背景には何があるのかを、こちらもまた具体的に知ることができた。うまくいった話は数多あれど、失敗談が出回ることは少ないため、大変貴重なものとして読むことができた。 総じて、今後ITシステムを刷新していく大企業にとって示唆深い一冊だったように思う。

・システムへの過度な期待 ・問題の後回しによる負債の肥大化 ・経営とシステム担当とのコミニケーションが取れないのは両方の問題 みずほ銀行の過去の経緯からなぜこのようなシステム問題が大手銀行で起きたのか。 詳しい技術情報はありませんが、システムの劣化やレガシー化に手が打てないのが書いてあります。

システム統合なので難しさは当然あるし、コストもかかる物であるけども みずほ銀行だからこその分析があまりなくて、 物足りなさを感じる。

19年にも亘る三行のシステム統合。 技術的な記述が多く、何故こんな問題が発生したのかの本質的な部分が少々薄い印象。 これば、システムの問題ではなく、経営の問題である！ リーダーシップ論の観点から論じている部分は興味深いね。

2019年7月にみずほ銀行の勘定系システムの刷新と統合のプロジェクトが終了した。2017年7月に新システムのMINORIの開発が完了したが、それから二年余りをかけて、システム移行を行ってきた。新システムはSOA(Service Oriented Architecture)の考えに基づいたものだという。最近ではSOAとはあまり聞かなくなった言葉だけど。2002年4月と2011年3月に大規模システム障害を起こしている。原因はそれぞれあるが、根本は勘定系システムの老朽化である。その老朽化したシステムを一から作り直したものがこのMINORIである。システム統合の苦闘の19年を日経コンピュータが追いかけた記録である。コンピュータ・システムに関わった者としては他人事には読めなかった。

20201120-1203　みずほ銀行発足から現在までの道のりは、巨大システムの統合の苦闘の歴史だったと痛感。大規模障害を2度も発生させ、その反省のもとに2019年7月に勘定系システムの刷新と統合を完了した。でもこれで終わりではないのだろうな。 　読み進めていくと、プログラミング等の細かい内容はわからなくても、プロジェクト管理がいかに重要か、リスク管理の重要性、銀行は巨大装置産業であり、IT投資は不可欠であることを首脳陣が全然わかっていなかったということ等を痛感する。半沢直樹なんてファンタジーもよいところだな、と。あれは銀行業の表舞台～華やかな現場だけなのだなあと思った。

IT関係の仕事、メインフレーム、いわゆる汎用コンピュータに携わっている者として非常に興味深くついつい手にとってしまった。ちょっと変わった構成になっていてみずほ銀行の新システムの概要や開発の経緯がまず最初の章で語られていてその後にみずほ銀行が過去に引き起こした大障害がどういうものだったか、が語られる内容。スカイツリー７本分、4,000億円以上かけたシステムがいかなるものなのか、また何故全面再構築に至ったのかなど極めて興味深い内容が前半で語られていてそれはそれで極めて興味深いのだけど後半の二章にはとりわけ惹きつけられた。ITベンダーぐるみで合併の主導権を争った結果、合併対応に失敗してしまう一度目のトラブル、3.11の義援金の振込処理に対応できずシステム全面停止を引き起こした二度目のトラブル、いずれもITに携わる者としてははっきり言って身の毛がよだつ内容。いずれの障害も突然のダウンではなく発生のかなり前から関係者には状況が見えていたはずで、これはまともに稼働できないな…と思いつつそれでもなんとかしようとして文字通り悪戦苦闘していたのであろうことを考えると本当に寒気がした。作者の主張は経営のITに対する無理解が二度の障害を引き起こした、ということなのだけど個人的にはそこではなくて国やマスコミなどにも問題があると思う。はっきり言って勘定系システムといわれる今回の刷新の主目的である銀行の根幹システムはその名の通り総勘定をきっちりつけることが目的であって利益を生み出すシステムではない。なのにそれが止まったりするとマスコミが騒ぎを煽って金融庁なども銀行に厳しい姿勢をとる..結果として大して利潤を生まないシステムに優秀な人材と予算が貼り付けられてしまう...というのが日本のシステムの問題点だと個人的には思っている。アメリカや中国のシステムが堅牢ではないと揶揄する人がいるが全体としてどちらがITにおいてイノベーティブか見れば一目瞭然。その意味では考えていたことが裏付けられたような気持ちがだが、一方でこんな大規模開発をよくやりきったなという尊敬の念も強く感じた。非常に興味深い内容だけどちょっと用語などが一般的ではなく誰にも勧められるものでもないかなとも思った。

結果からの勝手な物言いだけど、システムの作り方というより、プロジェクトの進め方、さらに言うなら戦略の立案から、やっちゃいけないことを悉く踏み抜いてきた感ある。 35万人月、四千億円強、そもそものスタートからは20年掛かりという膨大すぎるプロジェクト。ワシはシステムのことはとんと分からないので言語がどうとか結合の妥当性は分からないけど、意思決定とマネジメントの重要性を強く感じる一連の話だった。他山の石としたい。 余談だけど。ワシは、そこそこ大きなイベントの、立ち上げ時の現場責任者なんてのをやったことがあるが、その際「ここに投げれば判断する」という場所（即ち意思決定プロセス）を明確にすることの重要性を学んだ。詰まるところマネジメントとは、決定し責任を取ることなのだ。

開いた口が塞がらない。 とはいえ、他山の石としなければならない。 新システムの稼働から1ヶ月が過ぎた2019年8月に、 「今後10年、20年は当たり前に使える」 と担当役員が話したそうなのだが、 本書を読む限り、そんな感想は抱けない。 2019年にリリースしたシステムの基幹部分が COBOL で開発されているのだ。 COBOLって・・・。 これから10年、20年もCOBOLをメンテナンスし続ける、という判断を下したのは誰なのだろう。 少なくとも、優秀なエンジニアはCOBOLのメンテナンスなんて願い下げだ。 ブロックチェーンやAIという時代に、誰が好き好んでCOBOLのエンジニアになろうと思うだろうか。 高齢化社会に向けた施策の一つなのかもしれないが。 もちろん、設計思想の判断の難しさはよくわかる。 よくわかるが、現状維持の思想から抜け出せなかったのもわかる。 そして、10年、20年大丈夫だ、などと言わずに、早々に次期システムへの切り替えを検討すべきだ。 星が5つではないのは、 日経コンピュータの取材の丁寧さは伝わってきたが、やはり評論家だな、と思ってしまったからだ。 外野からは好きに言えるが、中にいるとそうそう簡単ではない。 大きなプロジェクトに取り組む際は、保身に走らないよう、自らの戒めとしたい。

他社のシステム現場について、ここまで深く描いた書籍を読んだ事はなかった。 生々しくて、SEとしては「怖い」「よくある」など自分の経験と照らし合わせて、読んだ。 いざ自分が当事者だったらと考えてしまうな。

2019年7月に完了した、みずほ銀行における「勘定系システム」の刷新と統合プロジェクトの全貌を解き明かす。当初の予定から3年遅れ、2011年6月の開始から8年、4000億円台半ばの巨費を費やした。みずほFGの発足から「19年越しの悲願」。 勘定系システムとは、預金や融資、振込などを司る最も重要な情報システムで、2002年4月と2011年3月に、二度の大規模障害を引き起こしていた。 情報システムは、業務手順、管理するデータの項目など、その定義が重要で、今回の場合、複数の銀行がそれらを統合することが、どれだけ難しいか、詳細に説明されている。また、処理するデータの数は、システムの運用、プログラムの詳細に大きく影響する。コンピューターのプログラムは、処理するデータ量が予想よりも多かったりすると、それまで見えなかった不具合が発生したりする。また、2度のシステム障害で明らかになったように、不具合が発生による業務への影響をリスクとして管理し、常に必要な対処が必要である。これらの基本的な点を、経営トップが正しく理解できていなかったことが、2度のシステム障害の根本的な原因だとされる。

ホラー小説より恐ろしい 。SE必読の快作！- 「みずほ銀行システム統合、苦闘の19年史」　★★★★☆ 恐ろしい。心底おそろしい。私もシステム開発を仕事として行っているので、こんなプロジェクトに配属されたらダウンする自信がある。 大きく3章で構成されており、1章は新システム「MINORI」の機能と開発秘話になります。大して面白くないです。SOA開発なんて普通じゃんか。 2章は「MINORI」の開発を始めるきっかけとなった東日本大震災直後のシステムトラブルの原因になります。恐ろしい。 3章は2章を引き起こすことになった真因である2002年の3行合併のいざこざと、合併直後のトラブルについて。まぢ恐ろしい。 お笑い芸人の「こんなシステムは嫌だ」に使えそうなネタ満載でたまりません。・3社合併だと思ってたら4社だった。 ・一番大きい会社のシステムが一番ゴミ ・ゴミだってわかっているけど、コンサルさんは引き分けって言うしかない ・偉い人の中では決まっているけどそれは部下に伝えない ・障害は手作業で復旧 ・障害が障害を呼ぶ（マドハンド状態） ・振込できてないのに残高が減る ・他支店の口座にアクセスするには成り代わりが必要 ・偉い人はシステムに無知 一番ダメなのは、「合併直前のみずほFGの経営会議のメンバー、旧三行の頭取、副社長6人、CFO、CSO、CRO、CCOであった。後ろ3つの役職は馴染みがない。最重要課題なのに、情報システム責任者のCIOがいない。」これよね。銀行なんてシステムがなきゃなんもできないんだから。 システム開発を行っている人は是非読んでください！統合を考えている経営者は必読でお願いします。

なんでそうなってしまうのかと思うことがおおく、途中から読み飛ばしてしまったが、プロジェクトマネジメントの反面教師の本。

この本もビジネス書ではなく、もはやシステムの歴史の教科書になってしまった。 10年後には本文も同じ分量の注釈が必要だろう。

業界にいては噂に聞く超大規模プロジェクト。新システムの取材先は上位層ばかりでうまくいったことになっているが開発現場レベルでの実態はどうだったのか。 過去障害振り返りの第2部、第3部の方がいちSE(と言えるのか微妙だけど)としては読み甲斐があった。

涙無くして読めんな。 本当に、日本全国に迷惑を掛けた一企業の話。 スネが折れるくらいの傷を負いまくって、IT界のサグラダファミリアとか、横浜駅とか言われて来た、みずほのシステム。 やっと稼働するまでの歴史。 勿論これで終わったわけでなく、ここから何をするかなのかなのだが、二度の障害を経て、何があったか、一覧できる。 言うとくが、迷惑食らったのはお客様だけでなく、営業店の最前線もなのだろうが、こんな話、全く知らされてない。 偉そうに、勉強した、先へ行ったとか言ってんじぇねえよ。

みずほ銀行発足前後からシステム統合完成まで苦闘の19年。 会社にとってシステムとは何か、システムが強い、弱いとは何か、を考えさせられながら読んだ。 システム開発手法という切り口でもう一冊出してほしい。

みずほの2度の大規模システム障害と新システム構築までの19年間を解説した本。 経営、現場、システム会社のどこに原因があったのかを分かりやすくまとめているので、古いシステムを有する会社の人間は誰もが一読しておくと良いです。 ただし、みずほの新システムは世界的に見ると 2、3周遅れと思います。例えば、アリババの決済を支えるアント・フィナンシャルのシステムの方が遥かに先を進んでいますし、巨額のシステム費用を利益で賄えるビジネスモデルを生み出したところも、日本のメガバンクは足元にも及びません。 間違っても、みずほの新システムを目標とすべきではないと思います。

・システムの専門用語の解説がない部分が多く、少し難しい(ストーリーとして読み通すのに支障はないですが)。 ・みずほ経営陣の大方針がダメだからどうしようもないけど、そんなヒドイ環境の中でやり切った現場の人は純粋にすごいし、実力もついたんだと思う。 ・巷では銀行間手数料を下げろとの話があるが、こんな堅牢なシステムなら相当維持コストもかかるよなあと妙に納得。

けちょんけちょんに書かれるのかと思ったら、3回目は妙に褒めていて気持ち悪い。その他二回失敗はダメだししてるけどね。会社の体質がそんなに変わるわけがないから、3回目なんとか無事だったのは、「はじめて必死にやったから」なんだろうね。

もちろん、どの分野でもそれぞれの苦労があるのだが、業務実施主体に隷属しつつ社会のインフラを実際に支えているシステム屋の苦労は格別。、同業者にしかわからないだろうな。

現場目線での話ではなく、経営・組織目線からソフトウェアを活かすためには何が必要なのかを、みずほ銀行システム統合の失敗を分析することで、説いている本。 世の経営者、課長以上の方々には是非読んで欲しいなぁ。

企業の合併とシステムの統合 今まさに、自分自身に降りかかっている 問題も全く同じ。 こういう変革期というか、問題が発生するときに 馬鹿なやつがいろいろ出てくるもんで・・ 規模も、立場も、まったくちがいますが 本質的には同じことかと

現行トップに初期の失敗に関する旧経営層の責任を問いかけてゴニョゴニョと擁護する言質をとった後に、失敗の検証で旧経営層をフルボッコにするスタイルは素敵だと思う。

エンジニアには胃が痛くなる内容でした（特に第二部）。勘定系システムで基本的な仕様を誰も知らないとか負荷テスト漏れとかあり得ないだろうとか思ったけど20年以上同じシステム使ってたらあるのかも。結果的に綺麗にまとまってるけど本に書けない現場のドロドロが垣間見えました。

ここに登場するみずほ銀行のIT史は、この本をもとに今後長く語り継がれることになると思います。 システムをどの立場で見るかで印象は変わるのだなぁと思いました。 元にした記事の筆者の視点の違いで第1部、第2部、第3部と楽しめます。 少しでもここに登場するシステムたちと関係した人には、懐かしい部分と、ちょっと深堀が足りないんじゃないという部分とあるかと思います。関係しないIT業界の人でも、思い当たるフレーズはあるはずです。他人の振り見てではないですが、いろいろ確認作業があったはずです。そういったものも思い出させてくれる本でした。 個人的には「老朽化」で切り捨てられている部分をもう少し丁寧に解説した方が良いのでは思いました。そういう部分も含めて、良くも悪くも「日経コンピュータ」の作品だと思います。

多くのIT系の読者が予想した（のではないかと思われる）「失敗した話」ではなく、副題「3度目の正直」の通り3度目にして「成功した」という話。2度目、1度目もさかのぼってあらましが書かれているけれど、順番が逆になっていることで若干読みにくい。基本的には現場のエンジニアや製造メーカーは養護するスタンスで、経営陣の責任や勢力争いを問題視する。3度目の正直でうまく言ったのならいいのだけれど、過去の延長線上の開発でこの先問題は起きないのだろうか。たとえば、iPodやiPhoneのような突然変異のようなブレークスルーがなくても将来的に生き残れるのだろうかと疑問に思う。

ITの現場を知らず社内政治に汲々とした人間しか経営層におらず意思決定が出来ないため、デスマーチになったという事。 現場レベルではもっと泥臭いものがあったんだろうな。 割と経営層に近いレベルの話しか書かれていないので、そういう意味では物足りない。

日本のIT業界のオピニオンリーダーを自負する日経コンピュータが2000年当時から追い続けたみずほシステム統合の取材の集大成と言える。 　なぜ、システム統合は失敗したのか、その後どのようにしてリカバリを図ったのかを記している。 IT業界に身を置くものとしては読んでおくべきであろう記録。 　成功記の部分はヨイショ臭がするものの、2002年の失敗時の記録は経営層の不見識を糾弾し、「ほれ見たことか」という視点（これは当時からこの論調だった）で描かれている。 専門誌の記事をベースにしているため、専門用語の多い部分もあるが、ITの重要性を語った一冊。

ただの説明文。whatばかり説明していて、whyやhowの掘り下げが全然ないからそれこそマニュアルみたいなものを読んでる気持ちになった。ドキュメンタリーみたいなものを期待してたから甚だ残念

プロジェクトX的な読み物というよりも淡々と事実を並べた報告書って感じ． みずほ銀行FGはこの期間システム5000億を数年かけて減価償却せず，19年3月期に減損損失計上しているみたい．IT戦略上優位に立って今後の減価償却もなし．投資家としてはポジティブかな． 銀行業務の根幹をなし従業員の業務フローがそれに大きく依存する基幹システムがあるべき姿に刷新されたことはいずれ数字に大きく出てくるんじゃないんだろうか． これだけの超大規模PJのキーマンは誰だったんだろうか． プロジェクトXが続いていたら確実にとりあげられているだろう． 広げた風呂敷が大きすぎて凄さが想像できない． 末端従業員がシステムをすんなり受け入れられるよう，研修を手配するのはもちろん，それを全国規模で，複数回，段階を経て展開し，さらに機関紙まで発行するということを考えるだけでパンクしそうだ しかし，巨大な情報処理システムほど脆弱なもの（ストレスに弱いもの）はないかもしれないなあ．ちょっとしたボヤが指数関数的に膨らんですぐに大火事になる．VUCAの時代，トライアンドエラーだ〜とよく言われるようになったけど緩められないものは緩められない 震災がきっかけになった10日の情報システム停止という超大規模インシデントは読んでて心が痛む．事後になって「あのときああすればよかったのに」と呑気な事後予測が書いてあってその背後にブラックスワンが笑っているのが目に浮かぶ． 安定であることが前提，つまり得られる利得の上限が見えているのに有事の際の損失は計り知れない脆弱なものにはヒステリックなくらいの臆病さや悲観的視点が必要だなあ．そもそもそんなことに怯えるポジションをとるなとタレブはいうけど，まあ取らざるを得ない場面はどこかであるから外期の教訓として インシデント原因としてあげられる経営者のIT軽視もしょうがない部分はあるんじゃないかな．全体として気になったのはそもそものリスク管理の考えかた，緊急対応の体制準備が不十分だったり，システムは安定稼働するという楽観 後インセンティブの問題，CIOがいたにもかかわらず，よくわからず投資効果を測れない基幹システム刷新に舵を切るのはできなかっただろう． 2000年台の戦略なき経営統合とIT活用の完全な失敗は現実を無視して理想に走ったこと．共通のあるべき姿を描くことなく，各々が自分のポジションを維持する不毛な社内政治戦争に展開してしまったこと，大本営発表でごまかし続けたこと　経営者のIT軽視とTHE日本企業っぽい 失敗の本質

読み物としては面白かったが、図表が多くあり読んだ媒体（電子書籍）が悪かったのか図表がきちんと表示されなく、本買ったらよかったと少し後悔。 内容としては、大規模システムにおける障害発生の原因やシステム的要因まで詳細に記述されており読みごたえはあった。ただわかってはいたが、現場レベルの話ではなく経営レベルでの記述になっているので自分の今自分に活かせることはあるか？と言われると微妙。

2011年の東日本大震災後から大規模障害に発展するまでは臨場感あって読んでて楽しかったけど、それ以外は辛いよなー大変だよなーって感想しか出てこなかった

200509.読みやすかった。華麗なる一族の後に読めたのも良かったと思う。 銀行統合の大変さ、システムに対しての見通しの甘さ、影響について描かれている。 当時の現場担当は地獄だっただろうな。対応時間がそもそも夜中だし、重過ぎるリミットが刻々と迫る。答えを持っている人間も周りにいないなか辛い。 後半の考察のような箇所が、後出しジャンケンのような感じで読んでて気分が悪かった。この発言をもってこう思っただとか、それならもっと具体的な記事なり意見で返すべきなのに、期待のような記事にしておいて叶えられなかったっていうのはずるいかと。

みずほのシステム統合プロジェクトについて詳しく纏まっており、プロジェクトマネジメントについて実例を通して学ぶことができる良書である。 なぜトラブルが続いたのか、そしてなぜ最後は完了させることができたのかを理解することができた。 結局はトップがその場しのぎや派閥争いをするのではなく、将来の青写真を描けているか、そしてプロジェクトを丸投げするのではなくコミットしていくことが重要であるという話であった。また、ITシステムは属人性を出来る限り落とし、保守しやすく設計することも意識しなければならないことを再認識。

本書の経緯を想像すると恐怖でしかない。。 いくつかの小さな歯車の狂いが、大きな問題へと波及していく顕著な事例だと思った。 予兆の段階で企業のリーダーがいかに早く、正しく、かつ勇気ある判断を行えることが重要である。 ということと、問題の先送りは更に大きな問題を生むということを改めて思い返す内容だった。

みずほ銀行のシステム障害から新システム発足までの歴史を綴ったものである。 1.なぜシステム障害に至ったのか 2.新システムMINORIがもたらす効果 3.システム統合の際の問題点 エンジニアや技術職の方は理解できる内容であるが、一般人には難しい内容である。金融機関に勤める方は歴史を知るという意味で読んでもいいかもしれないが、読んだからといって役立つ内容ではないと感じた。

みずほ銀行のシステム統合に関わるトラブル事例を基に一般の会社でもよく起こりえること、それに対する対応法を考えさせられる点でとてもためになる本であった。ＡＴＭの裏側ではこのように複雑なシステム、ソフトウェア、ハード、取引が絡んでいることで普段の入出金がいかに上手くできているのかよく分かった。システム構築は銀行にとってのコア設備だから時代ともに進化させなくてはならない。ＳＯＡ（Service Oriented Architecture)、外部環境の変化に合わせて情報システムを見直せ、後任者に正しく引き継げ、ブラックボックス化、危機対応能力の欠如、マネジメント人材の不足、銀行はリスク管理業、方針の決定が大切、ソフトだけは人間でないと作れない、等失敗から学ぶ経験はとてもためになると感じた。