障害発生が「当たり前」という銀行システム統合、本当にそれでいいの？
昨日、東京三菱UFJ銀行のシステム統合に絡む障害が発生し、セブン銀行（セブンイレブンのATM等） から東京三菱UFJ銀行への入出金、残高確認が一切行えなくなりました。
ITmediaの記事に拠れば、原因は「三菱東京UFJ銀行とセブン銀行の間でデータの受け渡しがカタカナではなく漢字であった」 からだそうです。
この件に関するmixiや世の中のブログを見回してみると、多くの人が「銀行のシステム統合だから仕方ないよね」 という論調で語っているように思えました。しかし、それって本当に正常な感覚なのでしょうか？
重要な社会インフラを担うシステムというのは、たった数秒の停止でも大変な影響を社会に及ぼします。 ATMというのもまさにその一つであり、今回、朝9時から11時55分頃まで復旧できなかったために、2万件以上の取引（預金・引き出し・ 自動振替等）が成立しなかったことが明らかになっています。
これが鉄道の管制システムであれば、たった数分間システムが止まっただけで、 衝突によって多くの人命を失うという事態も十分起こり得えます。これはあってはならないことであり、だからこそ、 些細なミスも見逃さないような鉄道各社は手厚い体制を敷いているのです。
これはIT業界にも十分当てはまることだと思います。ここ数年、 コスト削減の名の下にあらゆるIT投資の贅肉が削られて様々な問題を誘発しているように私は感じています。万全の体制というのは、 全体最適の観点からすれば、どうしてもムダがあるように見えてしまうわけですが、実はそのムダな部分が安全・ 安定というものを支えている存在なのではないでしょうか。
あなたの目の前に、幅10メートルで両端がガケになっている一本道があるとします。あなたの幅は0.5メートルもありませんから、
きっと全力で走り抜けることができるでしょう。
しかし、その道幅を体の幅と同じ0.5メートルまで狭めたらどうなりますか？ 全力で走った場合、 ちょっとバランスを崩しただけでガケに転落してしまうかもしれません。
今回の三菱東京UFJ銀行のシステム統合は、最盛期の開発要員6000人、開発工数11万人月、 投資額2500億円にも及ぶ壮大なプロジェクトでした。それこそ、みずほ銀行の前例を反面教師として、 絶対に失敗できない状況にあったものと推察します。
しかし、最も容易な部類に入る今回の（旧）東京三菱系→（新）東京三菱UFJへのシステム統合で、 電文文字列の内容が異なっていたという基本的な見落としが発覚した今となっては、そもそものテスト品質の甘さを追及されてもムリからぬこと。 テスト工程（誤字を修正：肯定）のスペシャリストが全てレビューしていたらなら、多分今回の障害は未然に防げた、 もしくは短時間で解決できたと思います。
オルタナブロガーの谷さんが「テストが甘いのよ」 で指摘している、「不具合は絶対にある、という感覚でテストをすること」という姿勢で臨む人材を揃えることは本当に重要なことです。ただし、 そういった人材をテスト工程で大量に投入してしまうとコストもかかるし、リソースが限られているなら開発部分が手薄になる可能性もあります。
プロジェクトメンバーのスキル偏差が気になった事件でした。
-（追記：5/15 0:30）-----------------
記述が十分ではなく誤解を招き申し訳ありません。そもそも私が意図していたのは、 トラブルが人命に関わるレベルの世界（医療、鉄道・航空管制、自動車制御系など） ではバグの発生を極限にまで減らすことに相当努力しているということは、 こういった巨大システム統合においてもなし得る事ができるのではないか、という点でした。
もちろんバグをゼロにすることが現実的な選択肢ではないことも理解していますし、 そのためにBCPが重要であることも強く認識しています。だから、三菱東京UFJさんの場合、 どれだけしっかりとしたBCPが立てられていたか、これが重要だと考えています。
今回のトラブルは対外インターフェースにおける疎通確認テストに含まれる内容だと思いますが、 インターフェースの仕様が誤っていたために起きた事件を想定したBCPが非常に事後対応的だったので、もう少し事前にリスクを世間 （一般消費者）に示すアプローチをとった方が良かったのではないかと思っておりました。
例えば、メガバンクのシステム統合規模であれば、 全国の金融機関に接続失敗時のオペレーションを何パターンか伝えておき、それを店頭や各種提携コンビニ、駅などに周知させるなど、 それだけでも世間から見た障害時の影響というのは変わってくるのではないでしょうか。
その他、思うところをコメント頂いた方々への返信という形でコメントしております。