不具合の原因は「カタカナでなく漢字だったから」――三菱東京UFJのシステム障害
三菱東京UFJ銀行のキャッシュカードがセブン銀行のATMで使えなくなるシステム障害が5月12日に発生した。三菱東京UFJ銀行によると原因は「カタカナで転送すべきデータを漢字で処理していたから」であった。
システムでは、旧東京三菱銀行のキャッシュカードを持つ利用者がセブン銀行で預金を引き出す際、10件以上の未記帳の記録がある場合にはそれを知らせる案内文を提示する仕組みにしている。ここで、三菱東京UFJ銀行とセブン銀行の間でデータの受け渡しはカタカナで処理する仕様になっていた。
今回は、これをカタカナではなく誤って漢字で処理したことが不具合の原因になった。三菱東京UFJ銀行のシステム担当者が対応し、11時55分ごろに復旧したが、成立しなかった取引は合計で2万件に上った。
同行では旧東京三菱銀と旧UFJ銀行のシステムの完全統合を進めている。同日は旧東京三菱銀の全店舗約250店で一斉に新システムに移行した。10日午後9時からATMを一時休止して作業し、12日午前7時から新システムが稼働し始めたばかりだった。
まあ、原因は不正入力に対する処理の抜けということでありがちといえばありがちなんだけれども、聞かされたほうはどっちらけだろう。ただ、人間が設計して人間がコードを書き人間がテストする以上どこかにこういうミスは発生してしかるべきだと思う。
でも、だからしょうがないですよで済ませていい話ではなくてであるならばどれだけ人間のぶれというものが介入する余地を少なくするかというものがエンジニアのあるべき姿だと思う。んでどうするかって話なんだけれどもこれは一人のエンジニアだけで出来る話ではない。仕様からテストまでをひとつのプランに基づいて行うべきだと考えているのだが、具体的にどうとかというのはまだ頭の中にしかない。一ついえることは仕様書の一つの項目に対し必ず二つ以上のテスト項目が作成され、実施結果が存在しなければならず、またそれが誰にでも参照できる形でなければならないと考えている。
まあ、頭の中だったら何でも好きなようにいえるのだが。１０万人月というプロジェクトをどのように動かすかというノウハウは今のところおいらの中には存在しない。
最初聞いたときは、
「なんでこんなミスを？つうか異なるシステムの通信のテストは基本だろ？」
だった。でもこの調子じゃ負荷試験も十分にできてない可能性もあるので
２５日ごろこの通信がダウンする可能性もありますね。
しかしいくら１１人/月の巨大プロジェクトで１００万件のテストしたと
言ってもこれではテスト項目増やしてこなしただけの自己満足でしかなかった
としか言いようがないですね。
>人間が設計して人間がコードを書き人間がテストする以上どこかにこういう
>ミスは発生してしかるべきだと思う。
それを言っては見も蓋もないのだが、これはテスト項目について十分なレビュー
がされていない典型的な例ではないのかと。異なるシステムの通信試験は試験項目
を課題ばらしで出し尽くしてマトリクス方式で漏れがないかチェックしなければ
いけないのだがおそらく時間的な制約で十分に行われていなかったのではないかと。
>仕様からテストまでをひとつのプランに基づいて行うべきだと考えているのだが、
いえあくまで仕様としての単体テストまではうまくいっているはずなんですよ。
しかし、あくまで他社との接続というと同じ社内の人と打ち合わせするようには
いかないはずだし他社さんが実際に機材や環境を貸してくれればいいが同じ社内
でない場合というのは制約が多すぎるということもあります。実際、みずほの
トラブルは旧３銀行のシステムインテグレータの足の引っ張り合いというのが
元凶ですしね。
ですからある試験できるところをターゲットにして通信の負荷試験、異常試験
をおこなうべきではなかったかと。でもこれひとつ間違えるとチェルノブイリ
のようなこと起こす可能性もある諸刃の剣なのですがね。
>１０万人月というプロジェクトをどのように動かすかというノウハウは
>今のところおいらの中には存在しない。
つ「アポロ計画」
確認すべき立場の人が作業を怠ったに一票!
カタカナと漢字を間違えたというミスは銀行データとして痛すぎると思う。
まあデータの種類が多くなりすぎて、裏方は溺れてたのかもしれんが...。
となると、見積もりが甘かったということにもなる...んーでか過ぎでイメージ沸かず（笑）
＞ブラックボックステスターさん
＞異なるシステムの通信のテスト
たぶん正常系しかやってないｗ 不具合の原因を見るとこんなの単体テストで検出するべき問題だよなあとか思います。んで、単体テストを満足に行えない原因というのはプログラムの構造化が適切になされていないとか、開発者に仕様が正しく伝わっていないとかそんなレベルかも。
テスト項目のレビューというけど、設計がきちんとなされていれば、仕様の項目にしたがって機械的に試験項目を割り振ればいい話であって、それは出来ると思うんだよね。ただ、仕様を煮詰める段階で「この項目の試験はどう検証する？」という観点で考えられる人間は必要だと思う。チームとしてどう運営していくかという話になっちゃうけどね。
他社システムとの結合試験は難しいといったって、それはやらなければいけないんだからそんなんお前ら管理者がきちんと話をつけてこいよというｗ まあ、試験できる範囲での試験は万全を尽くすべきだという考えには賛成しますし、今回はそれが出来ていなかったと思います。
アポロ計画かあ。あれもすごかったんだろうな。
＞Sadaさん
おいらはこの部分は当初の仕様からは漏れていて、ゴールデンウィーク明けに急遽追加したに一票入れたいなｗ 仕様書を改定するときにどっかに行っちゃったとか、そんなレベルの話だと思う。
ただ、この規模のシステムというのはおいらも想像も出来ないです。
＃ちなみにOSが新しくなると旧ハードがうごかなくなるLinuxもそうとかJitohがのたまっていたのでオイラI810チップのマシンでPuppy Linuxの最新版いれてるよん、と突っ込みいれたけど・・載るかな？
Sada様＞
>新聞に出る規模のミス、しかも銀行系の大手ときたら、ああ恐ろしい...。
異なるシステムを統合する場合お互いのシステムインテグレータが自分の有利な方向へ足の引っ張り合いやりますからね、結構えぐいですね。
ある意味でかい会社同士だと逆に悲惨かも。
>見積もりが甘かったということにもなる
金の見積があまいと言うことはない・・・と信じたいが外注まかせで削ったとすれば同情の余地ないですな。時間的な見積ミスはありそうですがそれよりデッドラインありきの作業だったのかもしれませんね。
>単体テストを満足に行えない原因というのはプログラムの構造化が適切になされていないとか
>開発者に仕様が正しく伝わっていないとかそんなレベルかも。
ありがちですな。他社さんのプロトコル仕様書を設計者が理解してなかったとか。
でもそれならテスト部隊ががんばってバグ出しすべきだと思うが。
＃ちなみにおいらなら最悪シュミュレータ使ってでも試験しますね。思いついただけでもタイムアウトぎりぎりにレスポンス方針とかレスポンス多発とかレスポンス中にごみ入れるとか・・・。
余談ですが電撃ネットワーク（東京ショックボーイズ）ってまず花火なんかの注意書きで「人に向けてうたないでください」とあれば「じゃあ人に向けて打ったらどうなるだろう？」と考えてネタにするそうであるがテスト屋っていうのはそうゆう思考しないとやっていけんですな。
>アポロ計画かあ。あれもすごかったんだろうな。
まともに成功する確率が１パーセント切ってたちうえげつない計画だったらしい。でも情報処理試験なんかででてくるスケジュール管理手法（でいいんだっけ？クリティカルパスとかね）とかはここらへんで開発されたのではなかったっけ？
ただ今新人研修の真っ最中でして、テストと設計を先日やりました。やっとこさこのエントリーで話されている内容がちょこっとだけわかってうれしい今日この頃です。
追伸：「ブラックボックステスト」っていう手法内も教えていただきました。ブラックボックステスターさんのハンドルネームってそういう意味だったのですね。
＞なんかここのメンバーで沖縄行ってJitohのコードレビューやったら楽しいことになりそうだｗ
おいらきっと死ねとか言うよ。
＞でもそれならテスト部隊ががんばってバグ出しすべきだと思うが。
いや、テスト項目を書く人間がだめだったら何が障害で何が仕様どおりの動作なのか誰にもわからない状態になってしまう。常に思うのですがテストというのは実際に行う以上にテスト項目を書く工数というのが非常に大切で、かつ非常に削られやすいと認識しています。
今回テスト部隊がどの程度プロジェクトにかかわったのか知らないけれども、少なくともテストエンジニアは仕様作成工程から参加させるべき。
テスト部隊ががんばるだけではどうにもならないということがあるよと。そしてそれはプロジェクトマネージャの責任範囲だと思います。
＞ちなみにおいらなら最悪シュミュレータ使ってでも試験しますね。
うん。で、そうするとそのシミュレータの仕様が正しいのかという確認も必要で。それだったら開発段階でユニットテストをもっとするべき。まあ、ブラックボックステスターさんのいうのは「最悪の場合」なんでしょうが。
そう考えると本当に「どういう試験をして品質を保証するのか」という視点と言うのは仕様策定と同じレベルと言い切ってもいい大事さかもしれないな。今回この話して今考えたことなんだけれども。
＞ A.Kirishimaさん
乙です。試験は本当に大事です。物を作ることと同じくらい大事です。テストと設計ということはxUnitとか使ってみました？
がんばってくださいね。楽しいから。
いいえ。まだ概要だけ。といいますか、現段階では概要ばかりが多くて、実際にさわるものってかなり少ないですね。
技術研修が本格的に始まってきましたから、そろそろCでプログラミング研修に入ると思います。基本だめな子ですが何か作るのは大好きなんで、がんばります。
本日の追伸：SODECに会社の手伝い兼情報収集でいきました。いやぁ、面白いです、ほんと。無論、とても良い意味で「よくもまぁ、こんな製品よく考えるなー」っと。コーディングしないでアプリケーション作るとか、ブラックボックスのテストを全自動でやらせるものとか（もちろん結果全て記録させる）、新ブラウザとか。あと、LinuxみたいにEclipseを自社で改造したりツールやプラグインを作って販売しているところもあるんだなーって知りました。
おまけ、やっぱ自社製品と似たものってかなりあるんだなーっと。
まー、そのかわり技術者への道はまだまだ険しいってことがわかりました。
さて、Jitohの反応みましたが・・・・想像を絶する斜め上の反応でした・・・。
つーか「そんなんだからソフト屋クビになるんだよ！」と書いてきたんでそろそろ出入り禁止になりそうですｗｗｗｗ
管理人様＞
>テストというのは実際に行う以上にテスト項目を書く工数と
>いうのが非常に大切で、かつ非常に削られやすいと認識しています。
そうですね、オイラは強引な見積を計画書で出して強引に開発責任者にごり押ししますｗ
>少なくともテストエンジニアは仕様作成工程から参加させるべき。
そうですね、オイラも参加してるんだけどもともとシステム屋だったせいかまだ組み込み系の文化に慣れてないので突っ込むべきとこにまだ突っ込めません。要修行です。
>まあ、ブラックボックステスターさんのいうのは「最悪の場合」なんでしょうが。
前いた部署がその最悪な開発が続く部署だったので・・・・いつか書きます。
>どういう試験をして品質を保証するのか」という視点と言うのは仕様策定と同じレベルと言い切ってもいい大事さかもしれないな。
そうなんですよね、ただ品質責任者がうるさい人だと試験計画の段階でおもいっきり赤はいるのでそれはそれで苦しい部分はあるのですがね。
営業よりも出世が遅く、給料も低い割には重労働の開発の世界へようこそ！
>ブラックボックステスターさんのハンドルネームってそういう意味だったのですね。
うんそう、でも厳密な意味では普通のブラックボックステスターとは違うかもしれません。厳密にいうと製品を世の中に出していいかの判断をする部署のぺーぺーですんで。
>そろそろCでプログラミング研修に入ると思います。基本だめな子ですが何か作るのは大好きなんで、がんばります。
がんばれー！！でも普通のCなの？C++とかC#とかじゃなくて？
まあCは文字列処理がわかれば一気に道が開けるので研修の段階でメモリーリークとかコアダンプとかメモリー領域破壊を体感してものにしていってください。（あ、これを現場で出しちゃだめよｗ）
>技術者への道はまだまだ険しいってことがわかりました。
というより日々是勉強ですよ。年齢制限はないけど学ぶことをやめたらIT土方のまま終わりますしね。
あと技術よりも大切なことは文書力と国語力
これは一番大事。
あんまり概要ばかり詰め込むのもあまりよくないのではないのかなと思ったりなんだり。皆ものが作りたくて入ってるんだからなんかやって見せればいいのに。
んで、好き放題できる環境で思う存分トラブル起こすよろし。
VMでLinux環境簡単に出来るから、なにかやってみればいいかもね。お題はどうかく.orgあたりからｗ
SODECはVIP券もらったんだけど、めんどくさかったから行かなかった。今週は諸事面倒でだめね。
＞ブラックボックステスターさん
魚拓は？ｗ
まあ、LinuxなんてXwindow環境使わなければ何でも動くんですけどね。あれば便利なのは疑いないけど、そんなのある環境で触ったことはない。
組み込み系の文化には自分もなれてません。とはいえ自分のいい加減な部分を許容してくれない文化があるので、まあ面白いです。
試験計画はきちんと立てないと後ではまるんですよね。品質責任者の首が回らなくなると思うんだけどなあ。そこでおいらはユニットテストを用いていつでも簡単に誰でも再現できる試験を行うわけですがね。
＞でも普通のCなの？C++とかC#とかじゃなくて？
いやー、Cはなんだかんだいって大事よ。基礎は重要。おいらみたいにPHPとかPerlとかJavaから入るとどうもついていけないところがある。
＞あと技術よりも大切なことは文書力と国語力
誰かみたいに「基本５文型」とか言い出さないでよかったｗ
>魚拓は？ｗ
えーと最初のが載ったあとどうもコメントが承認されてないようです。どうしようもないヘタレですねｗ、わかってたけど。
>あれば便利なのは疑いないけど、そんなのある環境で触ったことはない。
漢はやっぱりviですか？おいらは昔Xtでごりごりのプログラム書かされたことあるので一応、X使えないといかんとこの環境じゃないと怖いですね。
>いい加減な部分を許容してくれない文化があるので、まあ面白いです。
組み込みのソースは見たことないけどかなりROMの容量食わないように苦労しているようです。
>試験計画はきちんと立てないと後ではまるんですよね。
ある程度フォーマットというのがあるからあとは仕様書とのにらめっこ、あとは開発でやるテストとこちらでやるテストとのすり合わせですね。
試験環境は最大構成でバリバリにラックに組み付けるので障害再現はすぐにできるようにしてますね。
>基礎は重要。おいらみたいにPHPとかPerlとかJavaから入るとどうもついていけないところがある。
オイラにはPerlとかJavaとかのほうがというかいまだにオブジェクト指向というのがよくわからん。UMLにもいまいち慣れんし・・・。
>誰かみたいに「基本５文型」とか言い出さないでよかったｗ
学士様でしたっけ？＜基本５文型
でも今でも時たま試験計画書とか障害処理表（バグレポート）書いてると「てにおは」がおかしいことあるしやっぱり人に説明する文章というのはむずかしい。
＃もっともJitohのエスパーでないと理解できない文章力に比べればましでしょうが。
＞漢はやっぱりviですか？
そうだ！ viだ！ viサイコー！
つーかおいらvi以外でコード書く気になれないんですよ。Windowsでもgvim使ってますし。
おいらに最初に教えてくれたリーダーがかなり偏った人なんですが、どんな環境でも作業できるように鍛えてくれたそのリーダーさんには今でも感謝しています。
＞あとは開発でやるテストとこちらでやるテストとのすり合わせですね。
ここはちょっと異論ありかな。おそらく開発で行う（動作確認）テストとテストチーム主体のテストで項目がかぶらないようにということなんだと思うけど、おいらに言わせれば別に項目はかぶってもいいと思う。
開発はあくまでもモジュール単体の動作確認はするべきだけれども、テストチームは使用にのっとった機能が実装されているかという観点で項目を作成しなければならず、それが相互に関連性をもたなくてもいいじゃないかなと。テストを実施する目的が違うのですから。
＞とかのほうがというかいまだにオブジェクト指向というのがよくわからん。
これは馴れですねえ。デザインパターンとかとっつきにくいところはあると思います。
http://www.seshop.com/detail.asp?pid=4115
これが比較的とっつきやすい本です。
＞学士様でしたっけ？
そそ。
http://blog.goo.ne.jp/kaetzchen/e/e0f5cbd9cd9aa179a5902a7a4b423076
のコメント
＞あとは言語ですか。プログラミング言語はすべて英語なので，高校の最初に習った基本５文型をしっかり復習しておいて下さい。
これ見たときの衝撃は計り知れない。
確かに報告書と書くのに国語の知識は必要だけれども、プログラム書くのには必要ないだろと。
Jitohみたいに後出しで居丈高に言われてもなあｗ
miracleさんSODECいかなかったんですかー
（´・ω・｀）
僕はSODECに行きましたよ・・・会社の手伝い兼集客要員だけど。情報収集も、まぁ、できる範囲でやってきました。
見てきたのは帳票、内部統制システム、開発環境、プリンタです。なんかこれだけで会社が絞られそうだ・・・。
面白かったですよー。「こんなん作ったのかー」みたいな感じで。例えばコーディングしない開発環境とか。
ちなみに、研修でやる言語はただのCですよ。ちなみに僕が一番使える言語はFortran77（笑
＞miracleさんSODECいかなかったんですかー
すみません。当日の朝に人が沢山いるところに行くのが嫌になってサボっちゃいましたorz.
こんなんじゃダメだあ。
＞面白かったですよー。「こんなん作ったのかー」みたいな感じで。
ええ。沢山のプロダクトをみて自分の中で「こんなことが出来るのか」という引出しを沢山作ることはためになります。どうやるかはさておき「出来る」というメタ情報は貯めておきましょう。いつかきっと役に立ちます。人がやった事は絶対にあなたにも出来ます。魔法ではなく単に技術に過ぎません。
Ｃはしっかりやるといいですよ。やっぱり基本ですからね。