日経なんとかが書いていたみずほ銀行のシステム障害に関するレポート。後半はありきたりの内容だが、前半のみずほの動きと、成功した銀行の事例集がおもしろい。
トップが情報システムについて理解がなかった、現場任せだったとあるが、おそらくほとんどの会社はそうなのではないか。逆にいえば東京三菱のような銀行は非常にまれだと思う。
この失敗の大きな引き金になったのが、みずほコーポレート銀行のシステムにある一部の機能を安易に請け負ったことである。これにより作業がオーバーフローになってしまった。そして、みんながコーポレート銀行に危機感をつのらせるなかで、旧富士のシステムが対外接続が不能に。さらに振り替えが停止してしまった。
原因は、電文が一定以上になった場合に電文がある順序で来るとおかしくなるというもの。一見、テストが難しいように思うが、実はそれほど難しくはない。
電文が一定以上ということは、通常の範囲検査をやっていれば問題ない。
問題は電文がある順序というところだ。これは、おそらく例外による障害（つまりエラーによる障害）だと思う。というのは、停止するということはなんらかのエラーが捌けなくなったということによるものと考えるのが普通だからだ。
テストケースを作る上で重要なことは正常ケースよりも例外ケース（エラーになるケース）だといわれる。これは、通常のテストケースで含めなければならない内容である。特別なものでも何でもない。ようするにエラーになった場合の回復についてのテストができていなかったか、あるいはテストの結果の定義（つまりエラーが起こってシステムを停止するのが正常である。とテスト上で定義されてしまっていた）がおかしかったのかのいずれかであろう。
もしかすると、設計が不完全だったのかもしれない。かなりの突貫工事で設計者とプログラマが疎遠になってしまって、プログラマが例外事項をどのように処理すればいいのかわからなかったのではないか？と思う。
