オフショア開発失敗事例１５　デグレード不良が多発

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

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

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

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

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

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

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

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

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

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

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

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