システム障害は、経営層と業務部門の責任：情報マネージャとSEのための「今週の1冊」（54）

今やITシステムはビジネスの遂行に不可欠なもの。その要件をビジネスサイドの人間がしっかりと考えなければ、ビジネスに役立つシステムなど作れるわけがない。

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

・著=日経コンピュータ編集
・発行=日経BP社
・2011年8月
・ISBN-10：4822262596
・ISBN-13：978-4822262594
・1500円＋税
※注文ページへ

　「東日本大震災からわずか三日後の2011年3月14日、みずほ銀行はシステム障害を起こした。義援金の振り込みが集中したのをきっかけに、振り込みの遅れや店舗でのサービス停止、ATMの取引停止などを連発、影響は日を重ねるごとに広がり、収束までに10日間を要した。みずほ銀行が大規模なシステム障害を発生させたのは、9年前の2002年4月に続き2度目だ。なぜ失敗は繰り返されるのか。その理由はただ一つ。根本的な原因を究明し、対策を取っていないからだ」――

　本書「システム障害はなぜ二度起きたか」は、二度にわたるみずほ銀行のシステム障害事例を振り返った作品である。その詳細な分析を通じて、「根本的な原因」は、「歴代経営陣のIT軽視」だと喝破している。これは技術の詳細を理解していないという意味ではなく、「経営陣として、自社の情報システムとそれを支えるシステム部門の強みや弱み、課題などを把握していない」という意味だ。そして言うまでもなく、これはみずほ銀行だけに限った問題ではない。そこで本書では事例から数々の教訓を抽出し、真に役立つシステムを開発するためには、経営層、業務部門、システム部門の人間はそれぞれどう振る舞うべきなのか、あらためて再考しているのである。

　では、みずほ銀行の場合、「経営陣のIT軽視」は具体的にどのような問題を引き起こしたのか。本書は問題を大きく4つに整理している。1つはシステムのブラックボックス化だ。例えば「義援金口座の振り込み件数の上限値設定を誤った、上限値設定の存在をシステム担当者が知らなかった」といった不手際は、「稼働以来23年が経つ勘定系システムを、大幅に刷新をせずに使い続けてきた」ためと分析している。つまり、長年にわたって機能変更を繰り返した結果、容易に理解できないほどシステムの中身が複雑になっていたのである。

　2つ目は「操作ミスが多発した、必要なデータを誤って削除した」といった際の自動運用の仕組みを用意していなかったこと。つまり、「システム障害という緊急事態への対応力が決定的に足りなかった」。

　だが、「経営陣のIT軽視」をより強く象徴しているのは残る2つ、「リスク管理の不手際」と「危機対応能力の欠如」だ。何と、みずほ銀行とみずほフィナンシャルグループは、ITシステムが業務を支えるものであるにもかかわらず、「システム監査における『システム運用管理体制』のリスクを最高レベルとしていなかった」のだという。

　加えて、新サービス導入時に「テストが漏れなく実施されているかどうかをチェックするプロセスが抜け落ちて」おり、システム部門の担当チームがテストを実施していなくても、品質管理チームも、みずほ銀行みずほフィナンシャルグループの監査部門も、発見できない体制になっていたそうだ。障害対応が遅れに遅れたのも、多重障害時の対応方法がきちんと定められていなかったためだという。

　本書はこうした事態に陥った原因として、「費用とリスクを嫌い、システム刷新を先送り」してきたことなどを指摘する。中でも最大の要因として「システム部門との対話を怠った」ことを挙げている。つまり、日ごろから経営陣がシステム部門と密接に対話し、システム障害の「実態や状況をつかんだ上で、責任を持って判断を下す」体制があって然るべきだったのだが、これを怠ったがために、ブラックボックス化を招き、障害時の対応も遅れたというわけである。

　ただ、本書では「こうした体質は1999年の第一勧業銀行、富士銀行、日本興業銀行の合併時から垣間見えていた」として、さらに深く問題原因に切り込む。三行のシステム統合の核となったのは勘定系システムの統合だったが、勘定系システムは銀行業務の柱である以上、「その銀行の業務の仕方にそって作られている」。よって「どの銀行の融資の仕組みを残すのか、預金処理はどうするか」など、まず三行統合に伴う“業務の仕組み”を整理することがシステム統合の大前提となるはずだった。これは言うまでもなく「技術論ではなく、経営トップがさばくべき、経営判断」の問題だ。

　ところが1999年8月の記者会見時、システム統合について質問した日経の記者に対し、三行を代表して回答した富士銀行の山本頭取は、「システム部長を呼んで、早急にレビューを始めよと指示してきた」と回答したのだそうだ。これを聞いて、記者は嫌な予感がしたという。そして実際に、システム統合の落とし所について三頭取が相談した節がありながら、最終的には「三行の情報システム部門に統合計画を策定させた」。つまりは“丸投げ”である。本書はこれがブラックボックス化や障害対応の遅れなど、あらゆる問題を生み出す「諸悪の根源となった」と指摘している。

　さて、いかがだろう。これらの問題は決してみずほ銀行に限ったことではなく、 多くの企業に起こり得る、あるいは今起こっていることであり、決して他人事ではない。特に注目すべきは、システムは業務の遂行を支えるものである以上、その要件や仕組みなどは経営陣をはじめとするビジネスサイドの人間が責任を持って考えるべきという原則を、完全に見落としている点だろう。

　言ってみれば、ITシステムはビジネスそのものであり、テクノロジはビジネスを遂行するための手段に過ぎない。にもかかわらず、多くの場合、システムを使う側が考えるべきことを考えず、システム導入時には不毛な機能比較や価格比較に陥り、障害時には「開発した会社はどこか」といった犯人探しが始まる――本書を読めば、こうした丸投げ体質の異常さを客観的に理解できるのではないだろうか。

　なお、本書では事例の分析を基に、「動かないコンピュータ撲滅のための十カ条」と題し、「経営トップが先頭に立ってシステム導入の指揮を執る」「自社のシステム構築に関する力を見極め、無理のない計画を立てる」など、あるべきシステム開発のポイントを詳細にまとめている。事例と合わせて読めば、ビジネスサイドの人、システム関係者、双方にさまざまな気付きをもたらしてくれるはずである。ぜひ手に取ってみてはいかがだろうか。