皆さんは、レビューとインスペクション(検査)をどのように使いわけていますか?
まず、顧客の要求が高度で複雑な場合、その分野の専門家を呼んで、設計内容を要求に照らして詳細に点検する。この場合はレビューですが、欠陥の発見以上に設計内容の適切性を見ているので、設計行為の一部と考えて実施することになります。したがってレビューを実施するかしないかは、場合により柔軟に判断する必要があります。効率的に誤り(欠陥)を発見して、連鎖欠陥を食い止めることに焦点を絞って運用する見直しが検査(インスペクション)であす。あらかじめ用意されているチェックリストによってやや機械的に実施できるので、全開発プロジェクトに実施を義務付けることで効果を上げることができます。
ここでは、設計インスペクションのプロセスと、その結果として得られる欠陥率の両方を監視することで、設計の品質を評価します。

図は、あるプロジェクトの設計インスペクションによって得られた欠陥(エラー)検出密度を指標としてグラフ化したものです。グラフ内に示された上限値と下限値は、このプロセスにおける実績データから設定した期待値の範囲です。
このデータは、概ね欠陥は期待値の範囲内に収まっています。このことは、インスペクションごとの欠陥密度のばらつきは、現在定義されているインスペクションプロセスに内在する共通の原因に起因するもので、あらかじめ想定していたものであることを示しています。
この測定の枠組みを以下の通り設定します。
1.判断基準
(1)欠陥密度が管理限界を超過、もしくは下回っている場合は、調査と是正措置を要します。
2.計測手順
(1) まず、設計対象の機能的規模(FP、あるいはコード行数)を計測します。
(2) 次に、設計インスペクションで検出した欠陥を数えます。
(3) 欠陥検出密度を、検出した欠陥数を機能的規模で割ることで算出します。
欠陥検出密度の監視用に管理図を用います。管理限界値は蓄積データから求めます。通常より高い、または低い欠陥検出密度は、製品の品質もしくはプロセスに問題があることを示している可能性があります。
設計インスペクションで検出した欠陥を追跡することによって、製品の初期段階での品質指標が得られます。プロジェクト管理者は、製品の品質管理に管理図を用いることで、欠陥除去プロセスの「安定性」をチェックすることができます。「制御不能」や、不安定な状況に陥った場合は、その原因を調査し、ばらつきを説明できる原因を明らかにすべきです。
このような状況に目を向けないかぎり、プロジェクトは不安定で予測不可能な状態が続くことになり、当初の見込みよりも多くの欠陥を生み出したり、計画以上にリソースを費やすなどの弊害も発生してしまいます。
通常は、以下のようなエラーの事象と原因の傾向分析も併用して行うと効果的です。

本日はここまでにします。次回も更にPM定量化の実践技術をご紹介します。ご期待ください。お疲れ様でした。
参考資料:「実践的ソフトウェア測定、共立出版」