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

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

MINORIの開発を扱った前作の続編としてとても面白い。

開発→完成したら人員削減→システムがブラックボックス化→障害発生＆大規模化

という流れがみずほの障害発生パターンです。

最近も「AIを導入して人員削減！」と言っているので、
これからもみずほのシステム障害の物語は続きそうです。

続編がたのしみです。

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

この本の出版は2020年で、その後結局2021年にシステム障害が発生したということまで含めて物語としての完成度の高さに感動する。

・日本で類をみない超大規模なシステムの構築に成功！
・「サービス指向アーキテクチャ」という耐障害性の高いモダンなアーキテクチャを採用することで、これまでの「みずほはシステム障害が多い」という汚名を返上！

ということが書かれています。この本でシステム障害の根本的な原因が経営層のシステムに対する無関心さにあると書いていますが、結局この部分は変わらなかったことが2021年のシステム障害についてまとめた続編「ポストモーテム」で明らかになります。

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

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

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

大手銀行3社の合併によるシステム統合と障害の軌跡。
地銀しか使わないのでみずほに馴染みはないが、全国規模でこれだけの障害があった事は恐ろしい事だったと感じた。
色々問題点はあったが、間違いないのは頭取達のITに関する知識不足。うまくやるはず、とか技術は進歩している、とかトップが曖昧なまま進めたものだから、現場は思うように進めず大混乱。典型的なダメの例だと思う。いかにして現場を見て、正しい道を示せるか。マネジメントは終わりがないなと思う。
紆余曲折でシステム統合したが、これからも障害は続くと言う…。

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

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

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

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

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

ITインフラの保守、運用に関わる者としてゾッとする話でしたが、非常にためになりました。
前に読んだ「みずほ銀行システム統合　苦闘の19年史」よりも、障害内容に対する考察（なぜなぜ）が深い。

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

2021/2-2022/2の11回にわたるシステム障害について書かれている。

面白かったのは2・4・5章（≒障害発生回数）。

事実が書かれていることと、内部精通者がいるのか？というくらいに詳しく書かれていて面白い。

銀行システムを担当するエンジニアは全員読んだほうが良い良書。逆に、銀行システムを担当していても、システムを触ったことがない担当者だと、描いてある内容でわからない部分は多いような気がする。

システム障害はなぜ二度起きたか みずほ、12年の教訓（日経BP Next ICT選書）

問題提起の書。結果論として、みずほのたどった道は間違っていたのかもしれません。

護送船団方式で、ＭＯＦに横並びの経営を続けていたメガについて、みずほだけが、劣ったＣＩＯ，であり、ＩＴシステムに昏かった頭取だったとはどうもおもえません。

バブル崩壊で、３次オンラインの継続開発が途絶えたことも、銀行業界にとっては大きな痛手となりました。

業務の継承とともに、システムを業務の思想にそって再構築できるエンジニアがそこで途絶えています。
一旦、エンジニアをリリースしてしまうと、もとのようにシステムを熟知した開発体制を構築することは難しく、教育や、仕様の振り返りに余分な費用がかかってしまいます。

銀行側も業務継承、仕様の継承と時代に合わせて更改するという旗振り役が少なくなっていたことも原因だとおもいます。

振り返ってわかることですが、３行の同時合併で、かつ企業用と個人用の２つの銀行に振り分けるというだれもやったことがないシステム統合は、非常に難易度の高い業務システムの再構築でした。

そこでこの合併のためのＩＴ投資は単純にシステムをあわせるよりもはるかに高価なものになることを気がつかなければならなかったと思います。

しかもＩＴシステムは、富士通、日立、ＩＢＭとメインフレーマーがしのぎを削る生き残りの中で、かってあったＩＴシステムの継承のためのノウハウの共有は不十分でした。

業務が複雑　⇒　ＩＴシステムも複雑　⇒　業務整理が進まないまま、基幹システムである、勘定系システムを途中でリリースしなければなりませんでした。

コンピュータプログラムが、１億行あるとか、何千人が開発に必要かという尺度だけでは本質に迫れないと思います。

業務の仕様について、どれだけの量であったとか、３行の現状はこうで、あるべき姿はどうであるか。各システムの数値や処理がなぜそうなっているのか。そうならざるをえなかったのか、振り返って確認すべきメモやドキュメントがあったのか。

本書は、その責任は、銀行側にのみあって、３社のベンダーにはなかったといっていますが、そうはおもえません。
１枚の大きな青写真を用意すること、開発側でも納得のいく計画立案とその検証、これまでの業務からの運用の見直し、などその責任は、ベンダーにもあると思います。

目次は以下の通りです。

はじめに

第１部　震災直後、「またか」の大規模障害
　　第１章　検証、混迷の十日間
　　第２章　重なった三十の不手際
　　第３章　このままでは「三度目」が起こる

第２部　合併直後、「まさか」の大規模障害
　　第４章　現場任せが諸悪の根源
　　第５章　無理なシステム統合計画を立案
　　第６章　大混乱の２００２年４月

第３部　トラブルはどこにでも
　　第７章　金融機関で相次ぐ大規模障害
　　第８章　あわや人命にかかわる事態に

第４部　システム障害と闘う
　　第９章　基幹系システムに危機迫る
　　第１０章　経営トップがすべてを左右する
　　第１１章　計画作りがなにより重要
　　第１２章　今こそプロジェクトマネージメント
　　第１３章　稼働後も油断は禁物

おわりに

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

前作でシリーズ完結っぽかったところ、新展開でまた新作が読めた。「気付かなかった」「見落とした」が何回出てくるのか、という所が個人的には今回ツボった。MINORIの各部の健康状態をリアルタイムでインフォグラフィクス化して公開、とかすると良いんじゃないかと思った。HDDの弾が死んで黄色になって、4時間後には交換して緑に戻って、みたいなの、インフラ屋はやるけど、世間の人、知らんだろうし。僕は、割と大きいシステムをベンダから引き継いだ時、それまで引き渡す立場だったので、これはブラックボックスで掌握感がないって感じて、それが後にLC4RIに繋がったりしてる。そこを運用現場がどう感じてたのか気になるかな。これは所与で改善できませんとかだったら、まあ仕事楽しくないよね。

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

最近の仕事で、みずほ総研（MHIR）の方と一緒に働いているのですが。
有名なみずほFGの各障害が詳細に記載されていて
その原因追及や、根本原因などの分析が秀逸
SEとして読んでいて、よく理解できて、
身につまされる内容。
さらに、今の関連しているPJTと悪い部分が非常に
よく似ている。
今回のPJTでも、なんなりの障害は発生しそうである。
関連者に読んでほしいと思われます。

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

ー　金融庁はこうしたシステム上やガバナンス上の問題点が発生する「真因」として、「①システムに係るリスクと専門性の軽視」「② IT現場の実態軽視」「③顧客影響に対する感度の欠如、営業現場の実態軽視」「④言うべきことを言わない、言われたことだけしかしない姿勢」があると指摘する。

この中でひときわ目を引くのは「④言うべきことを言わない、言われたことだけしかしない姿勢」だ。金融庁は具体的な例を2つ挙げている。1つはみずほ銀行でシステム障害が発生した際、経営トップが障害の第一報を受けても、具体的な指示を出さなかったことが問題だとした。もう1つはみずほFGの取締役会でシステム障害について提言や意見が述べられても、執行部門がそうした提言や意見に基づいて具体的な行動をとらなかったことが問題だとした。　ー

なぜ、12ヶ月で11回のシステム障害が発生したのか。原因、背景、真因を徹底的に検証した作品。

15個の「なぜ」とか、読んでいて止まらない面白さ。知的興奮を呼び起こす作品。

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

[さとかず]

今回も面白かった

企業が起こした障害とその復旧対応そして再発防止の話は非常に面白く参考になります。本にしてくれて有り難いです

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

ポストモーテム みずほ銀行システム障害 事後検証報告
著：日経コンピュータ
出版社：日経BP

良書。読み終えたとき、銀行の勘定系システムを知るには、うってつけのテキストと感じました。情報システムの関係者へ向けたメッセージです。

表題のポストモーテムとは、事後検証報告書（直訳は、検視、死体解剖）、要は事後の振り返りです。

コンピュータの仕組みを知らない方は、読み進むのは、難しいかもしれないが、かじったことのある方であれば、IT用語のほうは、苦にはならないのではないか。むしろ、金融関連の用語を知らないと進みずらいではと感じました。
流れは、第３章で１５の疑問、第４章でなぜ重大障害が頻発したかの結論に至ります。振り返りとはここまで。また再発防止策について、７章にまとめられています。

金融庁からの指摘・原因
①システムを開発したのはいいが、品質を確保するために十分なテストをしなかった。
②稼働させた後に保守体制を十分に整備しなかった。（保守要員を１／３にカットした）
③障害に備えて、十分に訓練しなかった。

筆者は上記に加えて、他行が１社に片寄せした勘定系システムを、いがみあう４社に分散した結果、十分なコミュニケーションがとられないままに、システムがリリースされて障害が多発したと指摘しています．２度のシステム合併は各ベンダーに禍根を残したとも指摘しています。IBM 日立 富士通 NTTデータ

三菱ＵＦＪ　3300億円
三井住友　　1000億円
みずほ　　　8000憶円（4000億はDKB,FKBの片寄せ、4000億は3みずほの再構築）

上記がメガバンクの、合併にともなうシステム統合の費用です。
みずほは、多額の投資を取り戻そうと、運用費用をけずって、好決算をたたき出したのに、障害を引き起こして信用を失うという結果につながっています

また、三菱ＵＦＪとほぼ同規模だったみずほですが、４つのベンダーをたばねるために倍以上のコストがかかっています。「みえる化」というか、わかりやすさが、情報システムの構築コストにいかに大切かがうかがいしれます。

筆者のおもいというか結論は、以下です。

「ポストモーテム」は、失敗からの学びを大切にする文化の代表例だ。本書が多くの読者にとって、みずほ銀行の失敗を学び、より良い情報システムを築き上げるための教訓とする過程の一助になることを願っている

貴重な資料

P48　銀行システムの主な要素と勘定系システムの位置づけ
P50 勘定系システム「MINORI」の全体像とシステム障害が発生した箇所
P51 MINORIの主要機能と担当ベンダー
P129 MINORIの監視体制
P158 データベース冗長化対策の手法
P163 MINORI関連システム概要（インフラ基盤構成）
P185 大手銀行の勘定系システムの変遷
P195 銀行オンラインシステムの歴史
P212 みずほ情報総研の委託先体制
P217 メガバンクのシステム統合プロジェクトの比較
P233 MINORI稼働後に開発を始めたＡＰＩゲートウェイ
他　第7章　各再発防止策が集約されています

目次は以下です。

はじめに
第１章　前代未聞、１２か月で１１回のシステム障害
第２章　行内で何が起きたのか、システム障害の真相
第３章　なぜ障害は拡大した、１５個の疑問
第４章　金融庁が分析する「原因」「背景」「真因」
第５章　障害を繰り返すみずほ銀行のシステム、その歴史を紐解く
第６章　なぜみずほ銀行でだけ、何度も障害が起きるのか
第７章　みずほ銀行は立ち直れるのか
おわりに

ISBN：9784296110919
判型：4-6
ページ数：312ページ
定価：1800円（本体）
2022年03月22日　第１版第１刷発行

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

良書。前作よりも専門的な説明に踏み込んでおり、詳しい人によりわかりやすくなっている。慣れない人でも、うまくその後の説明で補足を入れてるので、たいへん気を使って書かれた本だなという印象である。
現場のエンジニア、特に運用寄りのエンジニアは読むのが良いと思う。ただ、夜寝る前に読むのはお勧めしないけれど。

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

システム開発に携わる立場から見ると、要件定義やプロジェクト進行のみならず、リリース後の監視・運用保守体制がいかに重要であるか痛いほど伝わる事例集となっていた。

システム障害の事後検証報告ということもあり、IT業界の人間でなければ文中に出てくる用語や仕組みの理解を深めるのは難しいものと思われる。

しかしながら、本書では障害発生時における顧客対応・危機管理面において、みずほ銀行の組織態勢不備が大きな課題として挙げられている点にも注目したい。

「積極的に声を上げることでかえって責任問題となるリスクをとるよりも、自らの持ち場でやれることをやっていたといえるための行動をとる方が、組織内の行動として合理的な選択になってしまう」（システム障害特別調査委員会の調査報告書より）

このような悪しき企業風土は、一定の規模感をもった組織であれば、どこでも発生しうる可能性は多分にあるだろう。日頃から部署間の連携やコミュニケーションをスムーズに行える体制づくりをすべきだということを、改めて思い知らされた一冊である。

失敗から学ぶ文化の醸成は、もはやどの組織でも必要不可欠な要素となっている。本ポストモーテムの知見が広く共有されることで、自らシステムの課題発見や解決方法の模索ができる人材がひとりでも多く育成されることを願っている。

なぜデジタル政府は失敗し続けるのか 消えた年金からコロナ対策まで

読んでて嫌になる本かもしれません。日本のデジタル化の失敗の歴史が1冊にまとめられている本です。これを乗り越えていけるといいけど、厳しいだろうなあ…(´・ω・`)

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

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

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

金融は情報システム産業といっても過言ではない。

自分自身金融機関に勤めているが、初めの頃は「システムは常に正確に、滞りなく動くもの」と誤認していた。

先日まで新会社立上げ・新規事業立上げを行い、システムの開発・運用を横目に見ながら思ったのは、システムには人の手がかかり、緻密かということ。そして、いくつものシステムが複雑に連動して稼働しているかということ。

みずほFGはシステムに苦心し続けてきた。その末にシステムを全面更改して「MINORI」を開発した。しかし2021年、再び度重なる障害を起こした。

この度重なる障害は、システムの全面更改が失敗したということではない。全面更改したからこそ、これまでとは違った苦難に直面している。

システムは要件定義から運用に至るまで繊細な管理が必要ということ、そしてMETIが提言する「2025年の崖」に対するヒントを、本書は圧巻の取材力で、丁寧に教えてくれる。

なぜデジタル政府は失敗し続けるのか 消えた年金からコロナ対策まで

問題は発注側（政府）が発注側の責任を果たせていないことなのでしょう。何を作るべきかは自分たちで考えるところがおざなりになり、現行プロセスを単に電子化したものにとどまり、そこに加えてセキュリティの観点が加わるとまったくもって使えないシステムの出来上がり。ベンダーは言われたものを作るのでそこに変革はない。改善するのはHow。Whyを政府、自治体、役人があるべき論を外部リソース取り込んで考えて、障壁となる法律や組織を政治の力で考えていかないと、失敗し続けるね。
菅さん、平井さんのラインはそこが推進できそうな雰囲気でしたが、次の岸田さん、牧島さんはこれを進めるとこできるんだろうか。
1も2にも人材なんだけど、デジ庁に移った先輩に聞いたら週3勤務で収入半減、かつ単年契約なので兼業先探さないと、とのこと。それじゃあいい人集まらない。情熱だけでは家族を養えない。

なぜデジタル政府は失敗し続けるのか 消えた年金からコロナ対策まで

# 政府・自治体とデジタルの歴史とこれから

## 面白かったところ

- 新型コロナウイルスでによって対策された施策のうち政府のIT戦略はほぼ失敗したが、その原因や傾向などが事実ベースで分析されていたこと。特別給付金の給付が成功した自治体もあれば手こずった自治体も有り、その両者を分かつものが何だったのかや、根本的に問題だったマイナンバーへの提言などがあって面白かった。

- 国や地方自治体がシステムを開発してきた歴史があるが、失敗した理由や事由をもとに近年どのような対策が練られ、法整備のもと実施されている歌がわかること

## 微妙だったところ

連載記事の切り抜き・まとめみたいなものだったため特定の著者がおらず
、良くも悪くも著者独特の意見がないところ。

## 感想

「日本は海外と比べてITが下手くそ。これからうまくいく見込みがない」って、祖父が言ってた。たしかにそうだなーと思いつつ、当時の上司や先輩方を見ていた身からすると、全く貧弱だとは思わなかった。

祖父が想起した理由は度重なる日本政府・地方自治体の失敗イメージが強かったことだろう。ITとはかけ離れた祖父と、稀にBADニュースが流れる政府のIT投資。

当本では祖父が抱いていたような失敗の具体的なケースが割としっかり書かれていて、とても勉強になった。

特に作りたいものを全て他人任せにする姿勢が民間企業とは全く異なるものだと感じた。

失敗が許されるとは思えないが、同じ轍を踏まぬよう我々国民のUI・UX向上に務めてもらいたい。