みずほ銀の障害から得る教訓

2011/06/11 – 18:35　

みずほ銀の障害から得る教訓

2011年3月14日、東日本大震災をうけて義援金の振込が殺到したみずほ銀行は、大規模なシステム障害を起こしました。その不手際を究明した記事が今週の日経コンピュータで特集されているのですが、これはシステム管理に携わる人達にとって多くの教訓となり得ます。というのも、今回の原因である「基幹システムのブラックボックス化」「運用ミスの多発」「経営陣のIT軽視」はみずほ銀行に限ったことではなく、多くの企業が抱えている問題だからです。

1.基幹システムのブラックボックス化

実は夜間バッチでも、一つの口座につき何件まで処理できるかを示す上限値の設定があった。口座aは、振込処理の前に明細を退避する準備処理で、この上限値をオーバーした。このとき、現場にいたシステム担当者は、このような上限値が勘定系システム「STEPS」に存在することを知らなかった。

サービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった。

システムの基本構造や処理方式などを熟知するシステム要員が決定的に不足していた

2.運用ミスの多発

夜間バッチを中断した後の自動運用手順を用意していなかった

障害対応手順の実効性を確認していなかった

作業の漏れや運用操作ミスが多発した

3.経営陣のIT軽視

みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかったため、こうした問題に気づくこともなかった。

「システム運用管理体制」のリスクを最高レベルとしていないなど、リスクの大きさを正しく把握することができていなかった。

【まとめ】

コストや効率ばかりを重視して無理にシステム要員を削減したり、システムへの投資をカットしたりする企業は実際に多いのですが、今回のみずほ銀の障害はそういった施策による弊害が一気に噴出した事例と言えます。コストばかりを考えたアウトソースで社内にノウハウが残らなくなってしまってもいいのか、効率ばかりを考えた人員削減でシステムの属人化が進んでもいいのか、再考しなければなりません。

無理なコストカットでシステムの柔軟性を奪い、今回のような障害を引き起こせば、社会からの信頼を失ってしまうのです。例えば運用をアウトソースするにしても、最低限の障害対応や変更管理・構成管理を自社で行うことでシステムのブラックボックス化を防ぎつつ、システム要員の技術力を維持できる体制を整備することは有効かもしれません。その際にアウトソーサーのノウハウを自社のシステム要員に還元できるよう、共通のサービスデスク基盤をクラウド環境で用意するのがよさそうです。