不具合摘出工数 - SEA関西プロセス分科会 -

ソフトウェア工学やプロセス改善に大きくかかわるのが、不具合摘出工数です。先日のSEA関西プロセス分科会の秋山先生のTSP/PSPの講演でも話題になりました。

コードレビューなら1欠陥を修正するのに2分ですむが、単体テストなら32分、システムテストなら1405分かかると言うものです。これは、バグを修正する時間だけでなく摘出する、つまりテストの時間を含めてバグ数で割ったものだそうです。

メアリー・ポッメンディーク他,リーンソフトウェア開発,p.82-84, 日経BP社, 2004.のよると、スパイラルモデルやアジャイルと規律で有名なベーム先生が言いだしっぺのようで、リリース後は開発中の100倍だとか5倍だとかの工数がかかると言われているようです。

秋山先生によれば、バグを見つける工数も含むと言われるのですから、テストが進むにつれて、すなわち品質が向上するにつれてバグが見つかる確率が下がる、見つける工数が増えるのは当たり前ですよね。しかも、一度に結合してしまう(ことが多い)ウォータフォール開発では、バグを見つけてから除去するために、問題箇所を突き止めるのも難しくなるのは当然です。

アジャイル開発は、段階的に開発・テストをしますから、バグの入っていそうなところを中心(というか古いところは自動テストされるので発見工数が不要)にテストされるので、常にほぼ同じ確率で発見できるでしょうし、バグが見つかっても追加したコードがおそらく原因でしょうから、バグの除去にかかる時間も安定しているのでしょうね(まあ、アジャイル開発でも、規模が大きくなればそれなりに工数は増えますし、品質保証部門のテストがあれば工数もかかり、デバッグも難しいでしょうけど)。

さて、この後の工程ほどバグの修正にコストがかかるというのは、プロセス改善の基礎になっています。「フロントローディング」などと言う言葉がありますが、後の工程で発覚しないように、前の工程でバグをつぶすような活動です。後工程ほど工数がかかるのだから、早めに見つけるのは当然だし、途中の作業を飛ばすなんて言語道断と言うわけです。実際にテスト工程のどれかを飛ばしてみると、その意味が良くわかります(良い子はまねをしないでね)。

リリース後の品質が悪くて工数がかかって仕方がないなら、プロセス改善のチャンスです。改善結果が利益に直結するので、きっと楽しい活動になると思います。