システム開発のテストで見つけた不良を対策する際に、修正方法を誤って作りこんでしまった別の不良のことをデグレード不良といいます。

プログラマも人間ですからミスは止むを得ないのですが、それがあまりに多い場合、開発手順に問題があるのでプロセスの改善が必要になります。

デグレード不良が止まらない

ベトナムのオフショア開発先に、WEBシステムの詳細設計から組合せテストを発注し、納品後に日本側で受入テストを実施していたときのことです。

不良は基準値の2倍程度でお世辞にも良いとはいえないものでしたが、事前の想定の範囲内で、受入テストの体制を厚くし、テスト期間にも余裕を持たせていたので問題はありませんでした。

問題は、日本側が指摘した不良を直すと、別の不良が作りこまれてくることでした。
指摘に対して短期間で対策が完了するのは良いのですが、今まで正常に動いていた箇所が動かなくなるのです。

そうすると再度指摘をして、プログラムを修正してもらって、再テストとなるので、いつまで経ってもテストが終わりません。しかも、修正の都度、再テストが必要になるので、日本側のテスト工数が膨れ上がっていました。

これ以上遅れると回復不能になってしまう恐れがあると判断し、急遽ベトナムのオフショア開発先に行って不良修正プロセスの改善を行うことになりました。

現状プロセスのヒアリング

不良の修正プロセスをオフショア開発側のPMに確認しました。

私 「プログラムを修正する際に、修正内容をまとめた文書(P票)を作っているはずですが、見せてください。」
PM「作っていません。」
私 「それでは修正内容を誰も確認していないのですか?」
PM「そうです。」
私 「不良を修正した後に実施するテストのテスト仕様書を見せてください。」
PM「ありません。」
私 「どうやって確認しているのですか?」
PM「テスト技術者が実機確認しています。」
私 「テスト仕様書なしで確認しているのですか?」
PM「そうです。」
私 「テスト仕様書なしでは、テスト漏れが発生しても仕方がないですよね。テスト仕様書を作ってください。」
PM「しかし、テスト仕様書を作ると時間が掛かってしまいます。」
私 「デグレード不良を作ると却って時間が掛かりますよ。」
PM「・・・」

詳しく手順を聞いてみると、プログラマはプログラムを修正するのみで、問題の事象が解決していることだけ確認した後、すぐにテスト技術者に渡していました。
しかも、テスト技術者に引き継がれるのは不良の内容のみで、どのプログラムをどのように修正したかについての情報は渡されていませんでした。
そのため、テスト技術者はどの範囲を修正すれば良いのか判断できず、日本側が指摘した不良が直っていることだけを確認することしかできない状況になっていました。

対策

以上の状況を踏まえて以下の2つの対策を行うことにしました。

  • プログラム修正前にプログラム修正内容をまとめた文書(P票)を作成し、日本側とレビューする
  • P票をテスト技術者に引き継ぎ、テスト技術者はP票からテスト仕様書を作成する

対策を行った結果、デグレード不良が発生する確率は40%台から約3%に改善しました。
日本国内での基準からすると1%未満を達成しなければならないのですが、今回は期間が短いこともあり、この値で満足することにしました。

契約条件の変更

実は、組合せテスト工程ではP票は納品物になっており、きちんと作っていたのです。
ところが、受入テストに関しては、契約書に対策を行うことのみを記述していたので、P票を作らなかったようです。

契約書に書いていなくても組合せテストと同じプロセスを行ってくれるだろうと考えていたのは甘かったと痛感しました。
オフショア開発においては、甘い思い込みは木っ端微塵に打ち砕かれます。

次の契約から、受入テストにおける成果物にP票と修正確認のテスト仕様書を追加しました。