「システム障害はなぜ二度起きたか みずほ、12年の教訓」を読んでみた

少し古い本だが、「そういえばみずほ銀行の開発プロジェクトってどうなってるんだろう」と思いながら2chの某スレを読んでいて、この本の話題が出てきたのでKindle版を読んでみた。

システム障害はなぜ二度起きたか みずほ、12年の教訓

本書の構成は大きく、

• 2011年3月の東日本大震災の義援金処理で発生したシステム障害の解説。
• 2002年の合併直後の新システム稼働時の大規模障害の解説。
• 東証や東京消防庁などの他の大規模システム障害事例の概観
• システム障害を発生させないための提言

の4つにわけられる。

本書の主張は一貫して、ITはいまや企業の根幹を担う中枢であるので、IT部門に丸投げするのではなく経営陣が積極的にITにかかわっていくべき、ということだ。

ややIT部門目線のポジショントークが強い論調が気になったが、ビジネス寄りの人向けにITの重要性を説くのが主旨の本であるから、このくらい偏っている方がゆくゆくバランスが取れるのかもしれない。

大規模開発の成功事例

本書では、みずほ銀行の失敗事例が中心に取り上げれられているものの、それと対比していくつかの成功事例も扱っている。

こういう業務系の大規模開発の事例は、だいたいにおいて失敗事例が面白おかしく自嘲的に業界内部の人から大きく紹介される傾向が強いので、成功事例の詳細は珍しい印象がある。

本書の「経営がITに積極的にかかわるべき」という主題に対して、CIOを外部から招聘した東証のarrowheadと、CIOを代々頭取候補が就任する東京三菱UFJ銀行の2つの事例が紹介されている。

いずれの事例も、いかにトップの決断が大規模システム開発プロジェクトの成功に欠かせないか、という視点で語られていて興味深い。

特に東証arrowheadのCIO招致に対しての政治劇が、まるで「不毛地帯」あたりの山崎豊子作品さながらで面白かった。

この2事例についてはさらに詳述されている書籍が出版されているので、こちらも読んでみたい。

システム改革の正攻法

システム統合の「正攻法」

失敗事例はひたすら背筋が寒くなる

みずほ銀行の失敗事例については、2011年3月の東日本大震災の義援金処理に関するシステム障害と、2002年の統合直後のシステム障害について、経緯が詳細に解説されている。僕もSI時代にはいくつかの大規模開発に携わっていたし、実際にカットオーバー前にプロジェクトが中断してお蔵入りになったシステムの開発も経験しているので、あるあるネタ満載で読んでいて背筋が凍りつく思いだった。

システム障害防止についての提言

最後に、本書ではシステム障害防止についての提言が十か条でまとめられている。いずれも「当たり前のこと」であるのだが、そういう当たり前ができていないプロジェクトが世の中にはたくさんある。

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

言うは易く行うは難しであるが、これこそが「大規模システム開発」の難しさをあらわしている気がする。