オフショア開発失敗事例１３設計書をテスト仕様書に流用

ＩＴ技術者はテストが嫌い

システム開発ではいろいろなタスクを行わなければなりませんが、その中でもテストが嫌いというＩＴ技術者はたくさんいます。
設計やコーディングはクリエイティブな作業なのに対して、テストは地道な作業だからでしょうか。
ですからＩＴ技術者は、テストは少しでも楽をしたいと考えがちです。

それが生産性向上につながる改善であれば良いのですが、単なる手抜きになってしまうこともあります。

ある失敗プロジェクトの立て直しを命じられたときのことです。
そのプロジェクトは、中国の大連の会社に発注して開発したものでしたが、オフショア開発を適用したにも関わらず巨額の赤字を出しながら、3ヶ月遅れでサービス開始にどうにかこぎつけたところでした。

私が指示を受けた日がサービス開始の当日だったので、立て直しと言っても損益面も品質面も手の打ちようがありません。
私にできることは、品質向上を行ってトラブルを起こさないようにすることと、不良が起きた時に迅速に対応することくらいでした。

トラブル発生

私が着任してから1週間が経過した頃、トラブルが発生しました。
利用期限が来た利用者に対して出力する更新通知が出ていないというものでした。

早速、原因を調査したところ、旧システムの利用者のうち、ある条件を満たした人についての処理が漏れているのが原因だと判明しました。
幸いなことに通知書を発送する前だったので、プログラムを修正し、不足分を再出力することで利用者にはご迷惑をお掛けせずに済みました。

原因は設計書のテスト仕様書への安易な流用だった

そして、類似見直しを開始しました。
先ず、類似見直しの観点を設定するために原因の特定を実施しますが、それは２つに分けて実施しました。
ひとつは不良箇所のコーディングの内容を分析するもので「技術的原因」と呼んでいます。
２つ目は、不良を作り込むに至った人間の動作を分析するもので「動機的原因」と呼んでいます。

「技術的原因」の特定を終え、次に「動機的原因」を特定するために設計書、テスト仕様書、テスト結果を集めて確認しました。

まず、設計書の記述には問題はありませんでした。ちゃんと問題が発生した利用者の処理が書かれています。記述の内容にも不足はありません。

問題はテスト仕様書でした。なんと設計書がそのまま使われていました。しかも何の追記もありません。

設計書をテスト仕様書に流用すること自体は、よく行われていますが、設計書だけではどのようなパターンでテストしたのかが曖昧になるため、入力データを追記などを行わなければなりません。
しかし、このプロジェクトでは、一切追記がなかったので、どのようなテストを行ったのかはテスト結果をひとつひとつ確認しなければなりませんでした。
問題箇所についてテスト結果を確認したところ、やはりトラブルが発生したテストパターンが漏れていました。

「動機的原因」はテスト項目設定漏れであることは分かったので、早速オフショア開発の発注先である大連の会社に品質向上を依頼しました。

私　　「設計書をテスト仕様書に流用した結果、テスト項目の設定に漏れが見つかりました。同じような漏れがないか見直しをお願いします。」
発注先「見直しは難しいです。」
私　　「なぜですか？」
発注先「設計書をテスト仕様書に流用することは、前のＰＭから了解をもらっています。」
私　　「流用することとテスト漏れは別の話ですよね。テスト漏れはあなた方の責任ではないですか。」
発注先「すべてのテスト項目の見直しが必要になりますが、無償ではとても厳しいです。」

厳しいのは分かっていたのですが、日本側だけで見直しを実施することはできません。
最終的には、日本側とオフショア開発側で費用は折半することで了解してもらいました。

前任のＰＭが安易に設計書をテスト仕様書に流用することを認めたこと、設計書なら要求仕様と一致しているはずとレビューでの確認を怠ったことが問題であり、オフショア開発側に責任をかぶせることはできないことは分かっていたのですが、背に腹は変えられず発注先にかなりの負担をしいることになってしまいました。