検出不具合数、欠陥数とうまく付き合えていますか？

レビュー、テストで指摘欠陥や指摘不具合を計数することで、妥当性を推測することが多い。この指標値については議論が多い。ないと頼りにするものがなくなって困るし、あると数値が一人歩きしてしまう。受託開発で、これに苦しめられている方は少なくないはずだ。ウォータフォールプロセスが生んだ弊害として捕らえられることもあるが、必ずしもプロセスと直接の関係があるわけではない。

この指標値が使われる理由は、以下の前提が成り立つとして、指摘数(指摘密度)によってレビューやテストが妥当なものであったかを推測することができるからだ。

• レビュー、テストの対象の品質はほとんどかわらない
• それぞれのレビュー、テスト対象のサイズが異なっていても一定規模あたりの不具合数、欠陥数はそれほどかわらない。
• レビュー、テストで検出できる欠陥、不具合数は対象に関わらずだいたい同じ。

また、全ての対象においてこの前提が成り立たない場合でも、開発難易度や実行のリスクに応じてクラス分けすることによって、クラス分けした中で成り立てば、使うことができる。

これらが成り立つことを前提として、対象成果物の規模で検出不具合数や指摘数を割り算することによって不具合検出密度や欠陥指摘密度を求め、過去のレビューやテストと比較することでレビューやテストによる品質向上施策が妥当であったかどうかを推測することができる。

ただし、これら指標値のみでレビューやテストの妥当性を推測するのは危険だ。あくまで気づきや確認のためのものであって、指標値が基準値内に収まっていればよいというものではない。

妥当と思えるレビューやテストを実施しても、これらの値が基準値に収まらない場合もあれば、問題が多いレビューやテストであっても、これらの値が基準値に収まる場合もある。

私のスタンスは「数値だけに頼るわけにはいかないが、何もない状態ではさらに困ってしまう。指標値の前提等を十分に理解した上でうまく付き合っていく必要がある」だ。このあたりの私の考えを詳しく説明した記事を@IT情報システムマネージメントに「レビューを「数」だけで管理しているからコストが膨らむ」というタイトルで掲載いただいた。今回も記事をより有益なものにするために@IT内野氏に多くのアドバイスいただいた。ここにお礼を申し上げたい。