品質の大家が語るソフトウェア品質指標 - Capers Jones氏の基調講演 -

タイトルは「Software Quality in 2008」。1/30, 31に東京で開催されたソフトウェアテストシンポジウム（JaSST'08 Tokyo）の初日にCapers Jones氏の基調講演があった。JaSSTについてはこちらを。いろいろなところで記事になっている（nikkeibp, gihyo.jp, kumikomi.net）。

Capers Jones氏はメトリクス、計測の分野では超有名人であり国内で話が聞ける機会は稀だと思う。講演が終わると演歌歌手が歌い終わったときのように聴講者に頭を下げていたりして日本向けのサービスも十分だったように思う。去年のICSE(International Conference on Software Engineering)のパネルセッションでのしゃべり方と比較すると、今回の基調講演では、ゆっくりしゃべっていらしたように思う。これも日本人向けのサービスなのかもしれない。当日夕方に1対1で立ち話をしたときにはもう少し速かった。

本題だが、講演の多くはFP（Function Point）あたりの不具合検出密度による品質測定の話だった。古くからある話ではあるがこのようなメトリクスを継続して収集し、分類、分析しているところが大事だと思う。Jones氏もこのメトリクスだけで十分というわけではないが、参考値の1つとしては有力であるという発言をされていたように思う。

私が覚えている範囲では。。

• 対象データは650社から集めた約12,500プロジェクト（ただし、項目によってはより少ないプロジェクトが対象となっている場合がありそうだ。）
• 1FPあたりの発見不具合数を工程別、深刻度別にわけて収集した結果を紹介
• 不具合密度を様々な観点から分類した結果を紹介（CMMIレベル、ソフトウェア分類（パッケージ、軍用、システム等）等にわけて収集した結果）
  たとえば、パッケージソフトウェアの出荷後の不具合密度は0.5件/FP、軍用のソフトウェアの出荷後の不具合密度は0.3件/FPというようなデータが紹介されていた。
• 「Defect removal efficiency」を「開発中にみつけ（修正した）不具合の数とリリース後に顧客がみつけた不具合の割合」と定義し、例を紹介していた。
  たとえば、CMMのL1では80%、L2では90%、L5では99%等。個人的には「米国平均」として出されていたデータに「Bad fixes」（デグレード）のRemoval efficiencyが70%というのが気になった。
  （一般に使われる「Defect removal efficiency」はレビュー/インスペクション、テストの効率をはかるためにそれらの活動の1回目でみつかった不具合と全活動でみつかった不具合との比をさしていることが多いように思う。）

他にも紹介したいセッションがあるが別のエントリにしたいと思う。最後に、国内でこのような講演を聞く機会を提供くださったJaSST'08 Tokyo 実行委員会の方へのお礼で締めくくりたい。ありがとうございます。