日経コンピュータ2011年6月9日号の緊急特集「みずほ銀障害の全貌 復活の鍵はCIO人事」はなかなか読み応えのある記事であった。筆者のキャリアの出発点は銀行担当のSEだったので、このメガバンクの大規模障害には強い関心を持ち、障害発生から一応の収束までインターネットや新聞の記事などを追いかけていた。
この緊急特集では、みずほ銀行が公開した報告資料を検証し、そこからあぶりだされた「30の不手際」という切り口で、障害の状況を生々しく記述している。ITエンジニアにとって必読の内容だと思うので、ぜひ当該記事を読んでいただきたい。
筆者は「30の不手際」の内容を分類してみた。(1)現場のオペレーションや判断のミス、(2)障害やイレギュラー処理に対する準備不足、(3)報告・連絡・相談（報連相）の不徹底、(4)想定外の処理時間、(5)人材不足―の五つである。それぞれ(1)10個、(2)10個、(3)5個、(4)3個、(5)2個という配分となった。複数の要因にまたがるものや、人によって分類の解釈が違うものがあるかもしれないが、大きな相違はないはずだ。
では、ITエンジニアがここから得られる教訓とは何であろうか。「現場」の視点で見ていこう。
(4)処理に想定外の時間かかるというのはよくあるトラブルだが、これは実際にやってみないと分からないのが実情であろう。現場を責めても時間が短くなるわけではない。(5)に関してはトップマネジメントの責任である。
(1)現場の人的ミスは、非難の的になりやすい。後から検証すれば、なんでこんなバカなことをしたのだ、ということになる。しかし人間はミスをするものであるし、属人性が強く、状況によって原因や対策が異なるので、実は参考になりにくい面がある。訓練やマニュアルの整備を徹底すればミスの発生率は下げられるかもしれないが、ミスをゼロにはできない。また、「正しいオペレーションや判断」も多くなされたはずだが、それは見えてこない。
やはりITエンジニアが他社の障害事例から学ぶべきは、(2)準備不足と(3)報連相であろう。みずほ銀行のケースだと(2)と(3)で15個、50％である。やや強引な言い方をすれば、50％は現場の努力で改善の余地があるということだ。
(2)の中身を見ると「並行処理は想定せず、準備もしていなかった」「処理の上限値を23年間1度も見直さなかった」「システム運用リスクを低く見積もっていた」といったような、記事として読めばお粗末としか言いようがないことばかりだ。
しかし、本当にお粗末と単純に批判できるのだろうか？自分がかかわっているシステムに当てはめて考えてみると、同じような準備不足の状態が実は多いのではないだろうか。例えばシステムの運用リスクに関して、仮にシステムが1日停止してしまった場合の対応計画の実効性を確認したことはあるだろうか。「絵に描いた餅」のプランでないかどうか、検証する必要がある。そういった視点をITエンジニアは持つべきであろう。
(3)の報連相に関しても同様のことがいえる。「担当役員が障害発生を知るまで17時間かかった」「営業店とシステム部門の連携不足で二重振り込み発生」といった不手際は、原発事故における東京電力や政府のコミュニケーショントラブルと酷似している。“バッドニュース”の伝達の遅さはみずほ銀行や東電といった大企業に共通の弊害である。大企業なら何も対策を打っていなければ、ほぼ同様のことが起こると考えるべきだ。中堅・中小企業であっても、経営者やマネジャーが「悪い話は聞きたくない」というタイプだったり、縦割り組織の社風であったりすれば同じだろう。
他社の障害事例を「他山の石」とし、万が一のときのシステムの備えや社内コミュニケーションについて見直してみることは、非常に大事である。
