東京三菱のシステム障害に思うこと

原因はカタカナで転送すべきだったデータを漢字で送っていたためだったそうです。

早速「テストが甘いかったんじゃないか」などという結果だけを見て偉そうなことを言うひとがちらほら出てきています。この手の原因と結果を転倒させる人は本当に始末に悪いですね。

確かにテストが甘かったのは事実でしょう。外部システムとの正常系テスト（記帳の回数オーバーのハンドリングはほとんど正常系です）をしていれば、事前に発見できたはずですから。しかし、部外者がそのレベルのことをしたり顔で言うのは、プロ野球の監督の采配に文句をつける酔っ払いオヤジとかわりません。

安易に時系列（原因⇒結果）を逆転させてはなりません。なぜなら、それは安直な分析につながるからです。今にしてみればあまりに自明だったことが、必ずしも現在自明であるとは限りません。むしろ原因と結果という図式を単純に信奉して「ああすればこうなる」式に（これも養老節ですな）手を打つ方が危険です。原因と結果という図式は、本来は不可能であるはずの未来の予測を、いとも容易に見せてしまうまやかしの図式でもあるからです。

送信データミスが原因で、結果として障害が発生した、という解釈は正しいです。それを逆転して「送信データミスがなければ障害は起こらなかったのに」と考えるのも、まあ妥当な感想でしょう。でも、そこから「テストが甘かった。私の成功体験では・・・」と断ずるのは早計です。

システム構築中は、取り返しのつかない意思決定の連続です。そして意思決定には常にリスクが伴う。人間ですからどこかで誤ることは十分ありえるからです。そのリスクをいかに取るかが大事なのです。

今回について言えば（結果を知っている部外者からは）明らかに必須と思えるテストの実施がなぜ漏れたのかが問題です。
外部システムとのインターフェースがある以上、結合テストはほとんど必然です。漏れようがない。それから今回の問題は正常系のテストでカバーできるはずです。異常系・障害系のテストなら時間との兼ね合いで割り切る判断もあるかもしれませんが、正常系のテストが行われなかった理由はほとんど謎です。

私には以下の要因が思い当たります（どれも当たり前のことですが・・・）。どちらも「ピーク６０００人を投入した」「失敗が絶対に許されない」と言われるからこそ、気になる点です。

１．作業に優先順位が定められていたか
２．現場レベルのエンジニアに無用なプレッシャーが掛かっていなかったか

人が多くても、適切にリソースが配分されていなければ意味がありません。その人員は、何の仕事をしていたのでしょうか。システムに無理解な上層部（残念ながら昨今はリーダークラスにも多いですね）の思いつきに対応するために使われたのではないでしょうか？本当に現場に必要とされるタスクに、回されたのでしょうか。そもそも、何が重要か、適切に判断されていたのでしょうか？

それから「失敗は許されない」というスローガンは、前にも書きましたが実に百害あって一利なしなのです。このスローガンによって引き起こされる副作用には、恐らくは瑣末事大主義と優先順位付けの不能でしょう。失敗をできるだけ起こさないためには、リスクをきちんと評価して、重要な作業を優先しなければなりません。しかし「失敗は許されない」無思考に陥ると、作業の割り切りやリスクテイクが出来なくなるのです。

今回発生した障害の裏に何があったのかは知りませんが、同じエンジニアとしてはこれ以上何事も起こらないことを祈っています。