オルタナティブ・ブログ > シロクマ日報 >

決して最先端ではない、けれど日常生活で人びとの役に立っているIT技術を探していきます。

「テスト不足m9(^Д^)プギャー」でいいの?

»

ITの世界に身を置くものとして、他人事ではない三菱東京UFJ銀行のシステムトラブル。直接の原因は、「カタカナで転送すべきデータを漢字で処理していたから」だったそうです:

不具合の原因は「カタカナでなく漢字だったから」――三菱東京UFJのシステム障害 (ITmedia エンタープライズ)

ということで、ごくごく単純なミスが障害の引き金となってしまった訳ですが、「それくらいテストで見抜けなかったのか」という声も挙がっています:

三菱東京UFJ銀の一部障害、直接の原因は文字コードの設定誤り (ITpro)

確かに「それくらいテストしとけよ」という気持ちも分かりますし、業務に携った方々の責任が問われても当然でしょう。ただ、「初歩的なミスしやがって、バカだなぁ」で済ませてしまって良いものでしょうか?

ITpro の記事では、テストに関して以下のような記述があります:

切り替え作業に先駆け、三菱東京UFJ銀は100万件以上のテストを消化している。社外との接続テストも、100以上に及ぶすべての相手先との間で実施した。

と、テストは念入りに行われていた様子(もちろんどこまでが真実かは分かりませんが)。少なくとも「ちゃんとテストしたの?」というツッコミに対しては、担当者の方々は「したよ!」と言いたい気分ではないでしょうか。

そもそもこのシステム開発ですが、旧東京三菱銀と旧UFJ銀行のシステムを完全統合するというかなり規模の大きなものです(こちらの記事によれば、最盛期の開発要員6,000人、開発工数11万人月とのこと。またこのマンパワーの多くがテストに費やされたことが指摘されています)。作業は今年12月まで続く予定で、今回は旧東京三菱銀の全店舗約250店で一斉に新システムに切り替えるという、プロジェクト最大の山場だったとのこと。障害が起きたことを正当化するつもりは毛頭ありませんが、過去のケースから考えて、これだけの規模の開発でトラブルが起きない方が奇跡でしょう(実際マスメディアはプロジェクトを不安視していたようですし)。

確かにトラブルの直接の原因は、些細なところにありました。しかしこれほどの人手を必要とし、かつ誰もが「ミスが起きる確率が高い」と理解していながらミスを防ぎきれないという、肥大化したシステムやプロジェクトに責任はないのでしょうか。また優秀なシステム開発者が十分に確保できて、かつ彼らがストレスなく働ける仕事環境が用意できるように、社会や教育の制度を整備する必要なないのでしょうか。さらに、そもそもこれほど巨大で重要なシステムの開発・運用を、一企業の中だけで行うという発想は古くないのでしょうか。「担当者涙目m9(^Д^)プギャー」と言うのであれば、こういった要因にも目を向けるべきだと思います。

繰り返しになりますが、直接の作業担当者には責任はないと言うつもりはありません。しかし目に見える原因だけを責めていては何も変わらない、というのは過去の事例や、他業界での事例からも明らかなはずです。少なくとも、これでまたシステム業界のイメージが悪くなる(末端で働く人々にとっては「労多くして功少なし」という業界)ということだけは避けて欲しいのですが。

Comment(10)

コメント

oze

>100以上に及ぶすべての相手先との間で実施した。
今回はしたことを言っても仕方が無いですよね。
また、事前に懸念されていたにもかかわらず、足下を掬われるにしては、あまりにもお粗末なミスですよね。

この統合に対する是非は色々な意見や見方があるでしょうが、今回の件に対しては同情の余地は無いと思います。

ミスを責めても仕方がありませんが、同じ理由でIT関係者が同情の余地ありのニュアンスを醸し出す内容はあまり頂けません。

アキヒト

oze さん、コメントありがとうございます。

> ミスを責めても仕方がありませんが、同じ理由でIT関係者が同情の余地ありのニュアンスを醸し出す内容はあまり頂けません。

そうですね、事故は仕方がないというニュアンスを感じさせてしまったのであれば申し訳ありません。本文でも書きましたが、決してミスの責任を問わないというわけではなく、もっと深い要因にも目を向けて欲しいというのが本意です。うまく表現できなくてお恥ずかしいのですが、そのように捉えていただければ幸いです。

ミスに関して言えば、これはもう弁解の余地がないイージーミスだと思います。しかしそのようなイージーミスを防げない体制に問題はなかったのか、そもそもミスを防ぎにくいシステムではなかったのか、などの点も議論する余地があるのではないでしょうか。同業者として、広い視点で考えなければならない問題だと感じています。

いつどこななしさん

一連の騒動に対する記事の中で根底にある問題を浮き彫りにしているのはこちらの記事だけでした。
本職のコンサルティングとコンサル(笑)と呼ばれるモドキ職との違いが判りますね。

アキヒト

いつどこななしさん、コメントありがとうございます。
僕もクマを抱いていたり、「m9(^Д^)プギャー」とか言ってる時点で「コンサル(笑)」なのですが。僕も大規模開発に身を置いていた者として、今回の一件は身につまされるものがあり、部外者ながらコメントしてしまった次第です。

ベル

いい内容だと思います。
私もいつどこななしさんと同意見です。

アキヒト

ベルさん、コメントありがとうございます。
少しでも末端のミスが追求されるだけでなく、より大きな議論へとつながっていってくれたら嬉しいのですが。

hiro

> しかしこれほどの人手を必要とし

そもそもここが問題。
どんなに大きなシステムでかつ重要なシステムであっても開発要員6000人というのは異常。
まぁ、大手さんが受注している限り普通の規模なんでしょうけど。
そこらへんに関して突込みがないのは、コンサル系の方々の儲けと開発会社の無能さを証明してしまうからでしょうか・・・。
そもそも、協力会社やらなんやから人を集めて6000人11万人月なんでしょうから、人をある程度本来の意味において「自社」で用意できないならやるべきではないんですよ。
テスターなんて方々から寄せ集めた素性の分からない質の悪い人たちでしょう。(中には優秀な方もいると思いますが。)
世の中に下請け会社が多いのも、下請けを買い叩ける要因になり、買い叩けるような会社が社員に教育コストなんて掛けられる訳ないのが分からないほど、開発会社の方たちは無能なんでしょうか?

そりゃー、優秀な人でもミスはあるんだから、そうじゃないかき集めでやったら結果はもっと悪いでしょうね。

ミスはなくならないと思うけど、減らすための努力・方法(≠人海戦術)を業界全体で考えて欲しいです。

アキヒト

hiro さん、コメントありがとうございます。
工数が異常とも思えるほど高いことについては、内部事情を知らない立場ですので、突っ込んだコメントは控えようかと思います(決して裏の意図があるわけではないので……)。実際の業務にあたった方々のスキルも分かりませんが、仰る通り、人海戦術以外にトラブルを避ける道がないのか模索することも必要だと思います。

ざりがに

> 不具合の原因は「カタカナでなく漢字だったから

データのフォーマットは決まっているのだから、当然その内容に即したチェック機能は開発すべきです。
お金をケチってこうなったとも思えないので、開発者の手抜きなのか設計者が無能なのか。
話にならないと思いますよ。

アキヒト

ざりがにさん、コメントありがとうございます。
その後時間も経って、徐々に問題の状況が明らかになってきていますが、「開発者の手抜きであった」のなら手抜きが生じた理由を、「設計者が無能だった」のなら他の有能な人々がフォローできなかった理由を追及すべきではと思います。「現場がバカだった、以上」ではなく、次につながるような考察がより多く行われて欲しいですね。

コメントを投稿する