【感想・ネタバレ】システム障害はなぜ二度起きたか みずほ、12年の教訓（日経BP Next ICT選書）のレビュー

日経コンピュータ

2011年3月11日の東日本大震災の直後に起きたみずほ銀行のシステム障害。2002年の経営統合直後に続く二度目の大規模システム障害は何故起きたのか?

20年以上にわたって「動かないコンピュータ」を追い続けてきた日経コンピュータ編集部が関係者に徹底取材。義援金の振り込み集中が大規模障害につながるプロセスを平易に解き明かすとともに、失敗が繰り返される真因に迫ります。

金融分野のみならず、障害が深刻な信用失墜/損失につながるミッションクリティカルシステムに携わるすべてのビジネスパーソン必読の一冊です。

[ブクログ · ★★★★★]

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

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

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

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

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

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

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

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

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

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

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

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

目次は以下の通りです。

はじめに

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

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

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

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

おわりに

[ブクログ · ★★★★★]

管理者として実感した運用の難しさと、ドメ大企業ならではの派閥争いを交えたプロジェクトの遅延、後退が、身につまされる。

[ブクログ · ★★★★☆]

読んでて突き刺さる点が多く、自分の行動を振り返りたくなる。
ITがどれだけ経営の重要な要素か改めて感じる。

[ブクログ · ★★★★☆]

安定稼働しているシステムほど忘れられ、障害を頻発するシステムの担当者ほど目をかけられる、ということもある。

[ブクログ · ★★★★☆]

システム統合は技術じゃなく経営の問題というのは含蓄に富む
ITシステムとは言っても、結局は人の問題になるんだなぁと思った
とくに大銀行の合併となるとしがらみも多いし、単純にシステム部門と事業部門の軋轢もあって、トップの決断が重要なのはうなずける
絶対上には立ちたくない。
システムは最重要なのに効果が見えにくいという厄介な問題があることが分かった
そのためにITに疎い経営者は投資をコストとしかとらえられず沈没していく。
人間は可視化してないものは見過ごすという好例だ。

[ブクログ · ★★★★☆]

2011年３月におきたみずほ銀行のシステム障害。
みずほ銀行としては二度目の大規模な障害。
後半の教訓は前のシステム障害はなぜ起きたかと同じ。

[ブクログ · ★★★★☆]

懲りない会社やで。
みずほの二回目の障害自体は割りに簡単に過ぎ、二度も起した莫迦な経営陣の問題と、他の事例にも触れ、何が必要かを説明する。

[ブクログ · ★★★★☆]

2度起きたみずほのシステム大規模障害やその他のシステム障害についての解説があり、さらにはこうした障害を防ぐための指針が示されている。
特に経営層のIT軽視がシステム障害の大きな要因であると強調されていた。
いまはCIOを置く企業も増え、さらには東日本大震災の影響からBCP（事業継続計画）を策定している企業も多く、ITへの関心は高まってきているとは思われるが、今後も経営戦略とシステム化戦略をマッチングしていくことが肝要であると思った。
本書に掲載されていた事例を通じて、ITが社会に与える影響はとても大きいということを改めて感じた。

[ブクログ · ★★★★☆]

読むのは2度目ですが、想像しながら読み進めると息が詰まる思いです。。教訓が多く含まれており参考になります。

[ブクログ · ★★★★☆]

会社後輩に勧められ読む。結構裏話知ってると思っていたけど知らなかったこともあり。ふむふむと。組織論というか日経コンピュータ論というか。まあバッチはこえーと。

[ブクログ · ★★★★☆]

大規模システムの問題点を経営的視点から解説。

古いシステムを使い続けてしまっている問題があるが、メガバングの新システムへの入れ替えには２０００億から３０００億円かかる。経営陣トップは、積極的な入れ替えよりも、現システムの維持という先延ばしする選択を選んでしまう。
CIO、情報責任者を執行役員ではなく、将来のトップとすべく取締役に入れる必要がある。現場まかせで、トップがシステムの重要性を理解していないことが根本的な問題と捉える。

動かないコンピュータ撲滅の１０箇条（メモ）
・経営トップが先頭に立ち、社員を巻き込む
・複数のシステム会社を比較し、強みを持つ会社を選ぶ
・システム会社を下請け扱いしない。むやみに値切らない
・自社の力を見極め、無理のない計画を立てる
・社内の責任体制を明確に決める
・上流工程に時間をかけ、要件確定後はむやみに変更しない
・進捗を把握し、テストに時間をかける
・あきらめない
・システム開発会社と保守契約を結ぶ
・うっかりミスを軽視せず、抜本的な対策をとる

[ブクログ · ★★★★☆]

2002年に続き2011年3月の震災後、2度目となったみずほ銀行システム障害事件のドキュメント。

みずほFGの経営幹部へ注目すると、原発事故の東電と重なる企業体質の様な気がする。問題意識を持った行員やベンダー等関係者はいたはずだが、その意見が取り上げられない組織が問題。

金融は当然のことながら装置産業の側面を持っている。
大手金融機関ともなれば、勘定系システムで処理されるトランザクションは、平均で毎秒500件なんて規模になる。その1トランザクションの処理に必要なステップ数は数万になったりするので、勘定系に求められる能力というのはとてつもなく高い。

ところが第三次オンライン（1988年頃）からメインの勘定系は変わっていなかったらしいというのは、怖いことだ。
現代の銀行システムは、その三オン時代に構築されたシステムが土台となっていて、現行システムはこの改良または発展した姿である。しかし、その発展の形というのは、それぞれの金融機関によって異なっているわけで標準化はされていない。しかもブラックボックスのまま。システム屋側から見たら「中身のわからんプログラム・システムは触れない」という別の恐怖となる訳だ。


『臭い物に蓋をする』この企業体質文化が、東電やみずほを生んだといっても過言ではない気がする。

[ブクログ · ★★★★☆]

大規模システム障害の構造を把握するために購入。マスコミ等で話題となった事件の事実詳細を確認することができた。やはりシステム障害や開発遅延の理由には上位への情報伝達遅延があり、その背景には組織におけるシステムへの関心度合いがあるのであろう。

[ブクログ · ★★★☆☆]

今日動いているものが、明日動くとは限らない。
トップマネジメント層が全社戦略としてシステム化を推進することが何よりも重要である。
言うは易し、行うは・・・・

以下、引用
「動かないコンピュータ」撲滅のための10ヶ条
一、経営トップが先頭に立ってシステム導入の指揮を執り、前者の理解を得ながら社員をプロジェクトに巻き込む
一、複数のシステム開発会社を比較し、最も自社業務に精通している業者を選ぶ
一、システム開発会社を下請け扱いしたり、開発費をむやみに値切ったりしない
一、自社のシステム構築に関する力を見極め、無理のない計画を立てる
一、社内の責任体制を明確に決める
一、要件定義や設計など上流工程に時間をかけ、要件の確定後はみだりに変更しない
一、進捗は自社で把握、テストと研修に時間絵を描ける
一、システムが稼働するまであきらめず、あらゆる手段を講じる
一、システム開発会社と優勝のアフター・サービス契約を結び、保守体制を整える
一、「うっかり」ミスを軽視せず、抜本的ン対策を取る

[ブクログ · ★★★☆☆]

みずほ銀行が2011年3月に引き起こした大規模障害(振込の遅れ、店舗でのサービス停止、ATM利用不可)の原因を探り、次に起こさないための教訓を探る書籍。
前半部分は、実際の障害の経緯や原因、そしてそこに至るまでの背景等が詳しく書かれていて、色々と参考になる。ただし、後半の「動かないコンピュータ」撲滅のための10ヶ条については、正論で誰もが反論は無いんだろうが(例えば、「社内の責任体制は明確に決める」とか)、"何故"それが実施されていないのか、され続けていないのかという部分に踏み込まないと、根本的な解決にはならないんじゃないかと思う。

[ブクログ · ★★★☆☆]

2011年3月、震災後に起きたみずほ銀行のシステムトラブルをきっかけに書かれた「システム障害はなぜ起きたか」の続編。重複する部分もかなりあります。経営陣のシステムに対する意識の薄さに警鐘を鳴らす立場は変わってません。

[ブクログ · ★★★☆☆]

同じ業界、近い現場を経験したものとして障害の詳細、三行統合時の問題について内容が把握出来たのが収穫です。
システムとしてどうあるべきでどうしたいのかという大きなビジョン、ロードマップを描いた上でのシステム統合ではないという意味では今現在も少しも変わってないのではと思ってしまう。

最後の方はちょっとくどいかな。

[ブクログ · ★★★☆☆]

過去2回のみずほの大規模システム障害を、経営側のIT軽視の姿勢、「わからない・苦手」だからとシステム担当者・業者に丸投げして理解しようとせず責任を放棄していることが、真の原因と述べている点は納得・共感した。こういったことが遠からずユーザー企業システム担当者の丸投げ、責任放棄、消極的な関与に繋がり、間接的にSI業界の多重階層・工程分業による閉塞感、エンジニアの成長阻害、失敗の連鎖などの弊害を招いていると感じている。

経営とITはもはや切っても切れない経営課題と捉えて、ITをどう活用して他社との差別化を図っていくかが、今後のユーザー企業の生命線となるはず。
そのことを追求していくことは、引いてはSI業界を変えることにも繋がると思う。

そういった意味で、ユーザー企業の経営層、システム部門の担当者、SI企業の経営層、マネージャ・リーダー層は一度目を通しておくべき。

ただ、最後の第4部の提言は、概ね同意できる内容だが、細部で現場の技術者からすると違和感がある内容も含まれていると感じた。（記者からの視点なので仕方が無いのかもしれないが）
例を挙げると…
　・プロトタイピングやアジャイル開発を採用するとしても、どこかで要件は凍結すべき　→　常にビジネス環境は変化する、それに素早く追随できるようにするのがアジャイルの本質なので、凍結するのではなく優先順位と取捨選択を頻繁に回す、ということが誤解して伝わる気がする。
　・昔に比べてシステムの安定性は退化している　→　そうだとすると Google や Facebook など先端Web企業の安定性は説明がつかない。システムの複雑さ・進化の速度に、日本のSI業界の設計・運用する側の人間のスキルが追いついていないだけでは？ことSI業界に限っては、昔の技術者よりも現在の技術者のスキルのほうが退化している、というのは納得できる。（設計と実装の分離が進み、上流の人間の実装スキル・仕組みを理解した運用スキル、下流の人間の設計スキルが退化しているのが実態。）
　・計画偏重、プロジェクトマネジメント偏重　→　大規模なシステムの構築に計画が欠かせないのは事実だが、計画に時間をかけ過ぎたり、承認の多重階層化により実効性が皆無になっている現場は山ほどある。大規模なプロジェクトにおいて完璧なウォーターフォールを行うのは不可能とまでは言わないが、相当な難易度だと思う。むしろ問題をより小さく分割していき、解決しやすくしながらそれを何度も見なおしていくことを積み重ねることが、現場の肌感として成功に近いと感じる。もちろんそれを成功させるためにユーザー側の深い関与とコミットが不可欠。

[ブクログ · ★★★☆☆]

2011年3月のみずほのシステム障害の詳細をまとめた一冊。加えて、2002年のシステム障害も取り上げています。経営者など、システムに詳しくない人をターゲットというので、IT業界に片足をつっこんでいた私としてはまどろっこしい気もしましたが、途中からは逆にこれでは経営者は分からないでしょ…という記述が増えてやや中途半端。経営トップが情報システムに積極的に関わるべきという主張は分かるものの、最後の章はややくどい印象。
ともあれ、2011年のシステム障害で何があったのかを知りたかったので、それがまとまっていただけでとりあえずは目的達成。それにしても、あのときの現場は悪夢だっただろうなぁと。そして、そんな現場ので状況が、どこか別なところで起きていても全くおかしくないくらい心当たりがあるようなことばかりで怖くなったのでした。

[ブクログ · ★★★☆☆]

みずほ銀行のCIOは、過去もそして今も、取締役ではないという指摘あり。三菱UFJ銀行は、次期頭取候補には必ずCIOを経験させている由。システム経験は、銀行経営の必修科目？、このあたりの指摘は、実に興味深い。

[ブクログ · ★★★☆☆]

システム障害は、現場のシステム担当やシステム開発会社だけの責任では無く、経営トップの責任である。
なるほど、確かに現場がどんなに頑張ってもトップが決めなくては先に進まない事項は良くある事に思える。
これからの時代は、システムは現場に任せれば良いという時代では無いとつくづく感じた一冊でした。

[ブクログ · ★★★☆☆]

システム屋としては読みたいなと思っていた一冊。経営陳がシステム部門の重要性を分かっていなければならないと主張されており、我が社の経営陳陳のも読んでほしいと思う。

[ブクログ · ★★★☆☆]

書いてることは当たり前のことばかり。でも歴史は繰り返されていることを考えると、なかなか守ることの難しさを感じてしまう。

[ブクログ · ★★★☆☆]

多分、社内でも問題意識を持った人はいたはず。その意見が取り上げられない組織が問題なんだよな。どこの会社でも起きてる事。こればかりはボトムアップでの改善が難しい。。。どうしたものか。悩ましいな。

[ブクログ · ★★★☆☆]

身につまされる。

システムは稼働したら動いて当たり前と考えられるけど、その当たり前を実現するには、日頃のメンテとどれだけ緊急時を想定できるか。現場だけの頑張りでは、大規模システムの日頃のメンテだけでも無理。経営陣の理解も必要。

経営陣に読んで欲しいな。

[ブクログ · ★★★☆☆]

みずほ銀行のシステム障害の詳細、他事例。体系化されたプロジェクトマネジメントの強化を強く提言。この辺りは非常に難しい...。体系化されたものを画一的に取り入れたら意味がないので。

[ブクログ · ★★★☆☆]

p58：みずほ銀行の二度のシステム障害は、どちらも経営陣のIT軽視、IT理解不足に原因がある。
→会社にとってITをどう活用するのか、経営陣がどうITを活用するのかが不明確なのだろう。

p178：情報システムの開発や運用のカギを握るのは、技術ではなく、人だからである。
→結局、開発は人である。

p204：プロジェクトを始める前に「プロジェクトを定義」することである。・・・そもそも何の目的でプロジェクトを推進するのか、その目的を達成するために必要な人材や資金を用意できているのかどうか、そのプロジェクトのリスクは何か、といった点を事前に考え抜いて、プロジェクトの計画を作ることである。
→研修でもたびたび習っているが、すべては計画が大事。
　計画段階で詰まっている案件は上手くいく。
　うちの会社はここをしっかり検討すべき。

p220：集めた要望を整理し、矛盾を排除したものが、情報システムの要件となる。
→要望と要件は異なる。要望を見極めるのもSEの仕事の一つ。

[ブクログ · ★★★☆☆]

システム障害の経緯が緊迫感があって興味深い。このトラブル対応を生き延びたエンジニアはどこでもやっていけるんじゃないか。
システムはそれを使ってビジネスする企業のものであり、システムの品質にも、トラブルにも責任を持つ必要がある。品質の高いシステムを作ることも、システムを安定的に運用することも難しい。システム屋任せで、速く、安く、確実に出来るシステムなんか存在しない。その事実に気付いているユーザーもまた少ない。だからこそ、その前提にたって、システム屋として品質を向上させる必要があるんだと思う。
以下、本のまとめ
2011年3月14日からのシステム障害詳細
銀行合併に伴うシステム障害詳細
他行等、みずほ銀行以外でのシステム障害について
動かないコンピューター撲滅のための十カ条について

[ブクログ · ★★★☆☆]

システム障害はシステム部門でなく、経営者の責任。

IT企業だけでなく、あらゆる業界がITシステムなくしては業務がままならない現代において、この認識は非常に重要だと思う。

[ブクログ · ★★★☆☆]

会社の情報システム部署以外の人にも読んでもらいたい。システムは常に障害リスクを孕んでおり、本業に大きなダメージを与える可能性がある。
現実を直視せず、専門用語を駆使し、相互理解から逃げようとする情報システム部署が存在する会社は、黄色信号。経営者はそれを正さなければならない。