品質改善活動①計画を立案し、予実を管理する
予算執行や開発などの進捗管理では、計画値を決め、その計画値と実績値の比較で予実を管理します。品質も同じように、計画値を決め、その計画値と実績値の比較で予実を管理します。
このページでは、計画値としてどのような指標を使うかを説明します。
１）検出バグ数
各工程で作り込んだバグ（作り込みバグ）を、どの検出工程（レビュー工程やテスト工程）で、どれだけ検出して、最終的に検出できなかったバグ（残存バグ）を０にする計画を立てます。
ａ）中央値を決める
バグは作り込んだ工程に分けて考えます。
例えば、上の表の場合、外部設計工程での作り込みバグを、外部設計工程中の８０件、内部設計工程以降、システムテストまでで２0件、ユーザテストで検出なし、最終的に、残存バグを０にする計画になります。
最初は、それぞれのバグ数の値を決めるのが難しいかもしれませんが、まずは、概算で決めて、実績値を見ながら、工程が進むに従って修正していくことも可能です。
その際に注意すべきなのは、実績値にそのまま合わせるのではなく、検出されたバグの内容や、計画時の想定と異なった点を確認した上で、適切な計画値に修正することです。
また、計画値を求める際には、次の情報などを参考にすると良いでしょう。
・品質が良好だった過去のプロジェクト（リリース後バグ0件など）の実績値
・社内品質部門が定義した標準値
・ＩＰＡ等が公表している標準値
ｂ）許容範囲を決める
計画値と実績値が完全に一致することは少ないため、ａ）で決めた中央値からの上下の許容範囲を決めます。
ａ）と同様に、過去のプロジェクトの実績値などを参考にします。
理想的には、品質良好な過去のプロジェクトの平均値μ、標準偏差σを求めて、μ±σの範囲（正規分布で全体の68%が分布する範囲）とするのですが、現実には難しい場合が多いでしょう。実績データが十分でない場合は、まず中央値±20%～50%程度を目安として設定し、実績を見ながら調整する方法もあります。
ｃ）バグ密度（規模あたりのバグ数）を決める
個別の機能（管理するプログラムの単位）や担当者ごとに予実管理をする場合、規模によってバグ数は変わります。このため、規模あたりの検出バグ数である「バグ密度」（検出バグ数／規模）を求め、予実管理の際の指標とします。
バグ密度＝検出バグ数／規模
規模は、要件定義書や設計書の場合はページ数など、ソースコードの場合は行数などを使います。
２）検証（レビュー、テスト）の網羅度
レビューやテストの充足度を管理するため、レビュー時間やテスト項目数の計画値を決めます。これについても、規模あたりの数値であるレビュー密度やテスト密度で管理します。
レビュー密度＝レビュー時間／規模
テスト密度＝テスト項目数／規模
レビュー密度やテスト密度は、検証の状態を見るものなので、作り込み工程では分けません。検証工程ごとに計画値を決めます。
レビュー密度は、下限値のみを決め、上限値はなくて良いでしょう。上限値は、レビュー時間が多すぎる（無駄なレビューをしている）ことの検出に使いますが、検出バグ数に依存するので、後述の「レビュー効率」で管理するのが良いです。
レビュー密度の下限値については、一律でも良いと思います。
３）レビューの品質
レビューは人間が実施するものなので、レビューの品質にはブレが出ます。これをレビュー効率で管理します。
レビュー効率＝検出バグ数／レビュー工数
レビューアが時間あたりで検出するバグ数です。レビュー密度やテスト密度と同様に、作り込み工程では分けず、検証工程毎に計画値を決めます。私の経験上、一律で、3.0件/H～6.0件/Hでよいと思います。
４）レビューア毎のレビューの品質のブレ
レビュー毎に、担当レビューア本来の実力を出しているかを管理します。
レビューア毎のレビュー効率の平均値μ、標準偏差値σより、下記にて算出します。
レビュー効率偏差値＝（(レビュー効率ーμ)/σ）×10 ＋50
全工程一律で、40～60※1で良いでしょう。
※1）正規分布で、μ±σの範囲（母数の68.3%）外のものを異常値として、レビューアの実力が出ていない場合や実力以上にバグ検出をしている場合を検出します。
＜各指標のまとめ＞
以上の品質状況を把握するために使用する各指標を、下表にまとめます。
※対象とする機能
すべての機能を品質管理の対象とすることはもちろんですが、対象から除外されがちなのが、移行（データ移行）のために開発する機能です。
「（移行時に）１回動かすだけだから」などの理由で、品質管理の対象外とされがちです。移行時に１回しか使用しない機能であっても、その移行結果を使った本番運用時にバグが発生すれば、リリース後バグです。
移行に関する機能も、他の機能と同じ開発プロセスをとり、品質管理をしましょう。