オルタナティブ・ブログ > 谷誠之の 「カラスは白いかもしれない」 >

人を動かすものは何でしょうか?様々な「座右の銘」から、それを探っていきたいと思っています

テストが甘いのよ

»

おそらく多くのブロガーさんが話題にしておられるであろう、三菱東京UFJ銀行のシステム障害。その原因は、「本来カタカナを使うべきとことに、漢字を使ってしまったから」だそうで。

そもそも、「三菱東京UFJ銀行でシステム障害」という第一報を見たときは、「ああ、案の定」と思ったんです。マタカ、という感じ。でも、あれだけ注意を払って、お金も時間もかけてやっていたのに。実際にシステム移行に携わった方には申し訳ないんですけどね。

次のこの記事を読んだときの最初の感想は、「テストが甘いなぁ」でした。

おそらく、要件定義とか、実際のプログラミングとかはものすごく計画をたててやっていたのではないでしょうか(想像)。また、「うまくいくパターンのテスト」とか「ネットワーク遮断とかシステムのダウンとか過負荷とか、想定される範囲での障害テスト」はさんざんやったんでしょうね(こっちも想像)。問題は、「ありそうもないヒューマンエラーのテストをどれだけやったか」ということだと思うんです。

私は、テスト計画はシステム構築に携わっていない人がすべきだ、と考えています。システム構築に携わっていない人はシステムのルールを知らないわけですから。システム構築に携わった方は、「システムはこういうつくりになっていてこう動く」ということを知っています。そういう方が考えるテスト計画は、無意識のうちに「想定された動き」をなぞってしまうんです。

昔勤めていた某外資系メーカーでは、取り扱い説明書を作成する専門のチームがいました。彼らには製品の仕様書をあえて渡さずに、製品開発担当者が行う説明だけで取り扱い説明書を書かせていました。確かに効率は悪いです。説明書作成チームは、開発担当者が想定していない使い方をして開発担当者をビックリさせます。また、開発担当者が想像もしていなかったような疑問が出てきてすったもんだします。時にはシッチャカメッチャカになることもあります。しかしそのおかげで、ものすごくわかりやすい取り扱い説明書ができていくのです。

不具合は絶対にある、という感覚でテストをすることが肝心なんですけどね。

私は普段、ITIL や COBIT といったIT運用の標準フレームワークを使った仕事をしています。テストプロセスにだってそれなりの標準フレームワークがあります。私が知っているのは TMap(Test Management approach for structured testing)と呼ばれるものです。「TMap テスト」というようなキーワードでググると色々出てきますので、興味のある方はお試しあれ。

Comment(4)

コメント

いつどこななしさん

大規模開発に関わった事のない人間の想像力ってそのぐらいなんでしょうか。
経歴を拝見しましたがやっぱりそうかって納得している自分がいますが。

谷 誠之

いつどこななしさん、コメントありがとうございます。
確かに私は数千人規模の開発にたずさわったことがありません。しかし少なくとも、相当に計画をたて、相当に責任をもってコトに臨んだことは理解できます。

今回のシステム移行は、シロウトが見ても評価できるところがたくさんあります。例えばビッグバン型の移行ではなく、段階を踏んで移行をしている点。中核部分の移行5月11日・12日という絶妙のタイミングで行った点。東京三菱側の移行とUFJ側の移行をずらして行っている点などです。

しかし残念ながら、不具合は起きてしまった。それは事実です。一般にシステムの不具合の7割は変更時に起きるといわれ、さらに変更の成否の8割は計画にかかっている、といわれます。これだけ大規模な開発ならアジャイルというわけにはいかないでしょう。

不具合そのものは無事に復旧した今、同様の不具合をいかに起こさないようにするかということが重要だと思っています。そしてそのためには、綿密なテスト計画、特にありえない事象に対するテスト計画は非常に重要だ、と申し上げているわけです。

いつどこななしさん

煽り口調に対する真っ正面からの返答ありがとうございます。
この膨大な量のテスト計画を立てたにもかかわらず起こってしまった不具合の要因は下働きの質やモラルの低下が考えられると思うのですがその事に対してインテグレータはどう対策を立てるべきだと思われますか。
8万件のテストを12万件にすれば良いという問題ではないと私は捉えます。

谷 誠之

いつどこななしさん、お返事ありがとうございます。

まず、今回の不具合の間接的な原因は、川上暁生さん(http://blogs.itmedia.co.jp/itconcierge/2008/05/post-4604.html)や栗原潔さん(http://blogs.itmedia.co.jp/kurikiyo/2008/05/ufj-68d0.html)も指摘しておられるように、テスト計画が不十分だったのではないかということが私の意見です。もちろんひとことで済ませられるものではないという認識はありますが、場所の関係であえてひとことで書けば計画の十分・不十分というのはどれだけ時間をかけたかとかどれだけの「量」のテストケースを考えたかということではなく、質の問題だと思っています。おっしゃるとおり、8万件を12万件にすることが重要なのではありません。例えば「他行のシステムが、もし仕様どおりに作られていなかったら?」というケースを盛り込むかどうか、という考え方の問題だと思っています。適切な言葉がみつかりませんが、テストは「性悪説」・・・つまり、プログラムが仕様どおりに作られていないことを前提に計画すべきだとさえ思っているのです。

一方でいつどこななしさんが指摘される「下働きの質やモラルの低下」は、計画そのものの質に影響を与えるものではなく、計画通りに作業を進められているかどうかとか、プログラムの品質そのものがどうかとか、縦横のコミュニケーションの質やスピードは適切かどうかとか、進捗の遅れや計画ミスが現場から上層部にきちんと報告されるかどうかとか、そんなことに影響するのでしょう。
(もっとも今回の問題に限って言えば、プログラムの品質が低いことが直接の原因だとは考えにくい、と思っています。少なくとも要求定義の段階とか、本番投入のリリース計画とかは非常によく考えられているなぁ、とさえ思います。不具合発覚からの復旧は非常に迅速に行われたと評価すべきでしょう。これも、あらかじめ綿密な復旧計画がたてられていたのだと想像します)

ここはどれだけ世の中やITが進んだって、しょせんは人間対人間の問題です。ピラミッドの上のほうに立つ人間が下のほうにいる人間をどれだけきちんとフォローするか、上の者がどれだけしっかりと旗振り役を務めているどうかにかかっているわけで、それこそこの場では語りつくせません。

ただ、モチベーションの低下やモラルの低下が進捗の遅れを生み、その結果8万件のテスト計画だったのが期日までに4万件しかテストできませんでしたというのであれば、それはゆゆしき問題だと思います。

コメントを投稿する