品質改善活動②予実差を分析し、対策を立てる
実績値が、計画した許容範囲内に入っているかを見ます。
＜予実差を見るタイミング＞
予実差を見て、対策を立てるタイミングは、開発スケジュールの立て方により、次の2つに分かれます。
Ａ）個々の機能（○○画面、○○アプリ、○○バッチ・・・などの開発の単位）ごとに期間の調整が可能な場合
週次程度の間隔で、予実差を見ます。必要に応じて対策を実施します。
参考文献）
クリティカルチェーン ～なぜ、プロジェクトは予定どおりに進まないのか?
エリヤフ・ゴールドラット／著 三本木亮／訳 ダイヤモンド社
Ｂ）個々の機能の開発期間が固定されており、必要な品質対策を工程完了時に実施する場合
工程完了時に予実差を見ます。
この場合でも、週次程度の間隔で定量値を確認し、大きな異常がないことを確認します。
＜予実差を分析し、対策を立てる＞
予実差の分析と対策立案は、次の観点で進めます。
Ａ）漏れバグ
テスト工程で、前のテスト工程までに検出を計画したバグが検出された場合、このサイトでは、このバグを「漏れバグ」と呼びます。
漏れバグは、計画外の検出バグですので、件数の多寡だけで判断せず、1件でも検出された場合は、その原因を分析し、再発防止につなげることが重要です。
Ｂ）検証の網羅度、検証の品質
レビューやテストが、検証対象をどれだけ網羅できているかなどを分析します。
ａ）レビューの網羅度、レビューの品質
レビューの網羅度が低い＝検出対象となるバグに漏れがある、ということですので、残存バグが増え、最終的な品質が悪くなる可能性があるのはもちろん、バグ密度などの品質データも真実を表していないことになります。このため、レビューの網羅度を高めることは、レビュー工程での品質分析の大前提になります。
同様に、レビューの品質が低い＝本来検出できるバグが検出できていない、ということになります。レビューの網羅度と同様に、品質が悪くなる可能性があるのはもちろん、バグ密度などの品質データも真実を表していないことになります。このため、レビューの品質を高めることも、レビュー工程での品質分析の大前提になります。
次の指標を使って、レビューの網羅度、レビューの品質を判断します。
１）レビュー密度（下限のみ）【機能ごと】
（規模あたりのレビュー時間）
分析）
レビュー密度が計画値より低い場合、レビュー時間が不足しており、レビューの網羅度や品質に問題がある可能性があります。
対策）
レビュー対象の機能の難易度が低いなど、レビュー時間が短くなる合理的な理由がある場合を除き、再レビューを実施します。
２）レビュー効率（下限のみ）【機能ごと、レビューアごと】
（レビュー時間あたりの検出バグ数）
分析）
レビュー効率が計画値より低い場合、レビューアの検出状態が悪化している（レビューの品質が悪い）可能性があります。
対策）
【機能ごとの場合】
レビュー時間が長くなった理由や、バグの検出数が少なくなった理由がない限り、レビュー観点を見直した上での再レビュー、または、別のレビューアによる再レビューをします。
【レビューアごとの場合】
そのレビューアのレビュー観点が不足しているなどのレビューア依存の問題がある可能性があります。レビュー時間が長くなった理由や、バグの検出数が少なくなった理由がない限り、他のレビューアによる再レビューを実施し、漏れていた観点を確認し、該当レビューアの観点追加を指導します。
３）レビュー効率偏差値（下限のみ）【機能ごと】
（そのレビューアのレビューの中での検出状態の良否）
分析）
レビュー効率偏差値が計画値より低い場合、対象のレビューアが、その機能に限り検出状態が悪い（レビューの品質が悪い）可能性があります。
例）苦手な機能だった。体調が悪かった。
対策）
レビュー時間が長くなった理由や、バグの検出数が少なくなった理由がない限り、レビュー観点を見直した上での再レビュー、または、別のレビューアによる再レビューをします。
ｂ）テストの網羅度
レビューと同様に、テストの網羅度が低い＝検出対象となるバグに漏れがある、ということですので、品質が悪くなる可能性があるのはもちろん、バグ密度などの品質データも真実を表していないことになります。このため、テストの網羅度を高めることは、テスト工程での品質分析の大前提になります。
（テストの場合、人間が実施するレビューと異なり、テスト仕様にてテストした内容に関しては、原則、漏れは発生しません。このため、このサイトでは、テストの品質については触れず、テストの網羅度についてのみ記載します。）
次の指標を使って、テストの網羅度を判断します。
１）テスト密度（規模あたりのテスト項目数）
分析１）
テスト密度が計画値より低い場合、テスト項目数が不足している可能性があります。
対策１）
テスト仕様書（テスト項目）が、「品質改善に必要な基礎知識の習得」の「テスト設計法」の基準を満たしているかをレビューし、不足があれば追加テストをします。
分析２）
テスト密度が計画値より高い場合、テストが冗長になっている可能性があります。
冗長なテスト項目は、テスト仕様書作成工数はもちろん、テスト実施工数と期間を増加させ、開発効率を下げます。
例）必要以上のパターンの組み合わせでテストしている。
対策２）
テスト項目数が多くなっている部分を中心にテスト仕様書（テスト項目）の再レビューを実施し、「品質改善に必要な基礎知識の習得」の「テスト設計法」の基準以上の冗長なテスト項目があれば削除します。
Ｃ）開発成果物の品質
検証の対象となる開発成果物（要件定義書、設計書、コード）の品質を分析します。通常言われる「品質」です。
「品質が悪い」とは、分析時点で、成果物に残存バグ（検出されていないバグ）が多いことです。
「Ｂ）検証の網羅度、検証の品質」でも説明していますが、レビューやテストの網羅度、レビューの品質が高いことが、品質分析の大前提です。これらが低い状態、すなわち検出漏れがあるような状態で品質分析をしても、バグ密度などの品質データが真実を表していないため、この品質データを使っても正しい品質分析はできません。まず、レビューやテストの網羅度、レビューの品質が高くすることに注力しましょう。
同様に、要件定義書や設計書、ソースコードが、一定以上の初期品質を持っていない場合も、品質が悪い可能性はもちろん、正しい品質分析もできません。例えば、次のような場合、バグ密度などの品質データが真実を表していないため、正しい品質分析はできません。セルフレビューを充実させると同時に、初回レビュー時に品質が悪いと判断した場合には、有識者の指導による文書、コード構造の見直しを含めた再作成をするなど、初期品質を一定以上にすることが必要です。
- 要件定義書の記載があいまいで、レビューアも思い込みの解釈で問題ないと判断した。
- 設計書の大きな記載間違いがあり、バグとしては1件だったため問題ないと判断して再レビューをしなかった。バグの修正としては問題なかったが、修正した後にその派生部分で多数のバグを作り込んだ。
- ソースコードにバグが多く、つぎはぎで修正したため、保守性が悪いコードとなった。一旦は品質が高いように見えたが、保守性が悪いために、テスト工程でのバグ修正時にデグレードのバグを作り込んだ。
ａ）レビュー工程での開発成果物の品質
次の指標を使って、レビュー工程での開発成果物の品質を判断します。
１）バグ密度【機能ごと、レビューイごと】
（規模あたりの検出バグ数）
分析１）【機能ごと】
バグ密度が計画値より低い場合、レビューの網羅度やレビューの品質が低く、十分にバグ検出ができていない可能性があります。
対策１）
レビュー対象の機能の難易度が低いなど、バグ検出が少なくなる理由がある場合を除き、再レビューを実施します。それまでのレビューの観点を確認し、不足している観点でのレビューをする、または、レビューアを替えるなどが必要です。
分析２）【機能ごと、レビューイごと】
バグ密度が計画値より高い場合、担当者が作り込んだバグ（作り込みバグ）が多い可能性があります。
対策２）
【機能ごとの場合】
検出されたバグの内容を確認し、担当者の弱点を把握します。弱点をレビューの観点として、再レビューをします。また、同種のバグが他の機能にも作り込まれていないか、横展開して確認します。
【レビューイごとの場合】
検出されたバグの内容を確認し、担当者の弱点を把握します。弱点について、同種のバグが他の機能にも作り込まれていないか、横展開して確認します。
２）レビュー効率（上限のみ）【機能ごと、レビューイごと】
（レビュー時間あたりの検出バグ数）
分析）
レビュー効率が計画値より高い場合、担当者が作り込んだバグ（作り込みバグ）が多い可能性があります。
対策）
【機能ごとの場合】
検出されたバグの内容を確認し、担当者の弱点を把握します。弱点を、レビューの観点として、再レビューをします。また、同種のバグが他の機能にも作り込まれていないか、横展開して確認します。
また、短時間で多くのバグを検出しているため、いくつかの観点での検出がおろそかになっている可能性があります。観点漏れがないことの確認も必要です。
【レビューイごとの場合】
検出されたバグの内容を確認し、担当者の弱点を把握します。弱点について、同種のバグが他の機能にも作り込まれていないか、横展開して確認します。
３）レビュー効率偏差値（上限のみ）【機能ごと】
（そのレビューアのレビューの中での検出状態の良否）（レビュー工程のみ）
分析）
レビュー効率偏差値が計画値より高い場合、担当者が作り込んだバグ（作り込みバグ）が多く、対象のレビューアの通常の検出水準を超えて、多くのバグを検出している状態と考えられます。このことにより、検出漏れが発生している可能性があります。
対策）
検出されたバグの内容を確認し、担当者の弱点を把握します。弱点を、レビューの観点として、再レビューをします。また、同種のバグが他の機能にも作り込まれていないか、横展開して確認します。
また、レビューアの実力以上のバグを検出しているため、いくつかの観点での検出がおろそかになっている可能性があります。観点漏れがないことの確認も必要です。
ｂ）テスト工程での開発成果物の品質
次の指標を使って、テスト工程での開発成果物の品質を判断します。
１）バグ密度（規模あたりの検出バグ数）
分析１）
バグ密度が計画値より低い場合、テストの網羅度が低く、十分にバグ検出ができていない可能性があります。
対策１）
テスト仕様書（テスト項目）が、「品質改善に必要な基礎知識の習得」の「テスト設計法」の基準を満たしているかをレビューし、不足があれば追加テストをします。
分析２）
バグ密度が計画値より高い場合、担当者が作り込んだバグ（作り込みバグ）が多い可能性があります。
対策２）
検出されたバグの内容を確認し、担当者の弱点を把握します。弱点を、レビューの観点として、再レビューをします。また、同種のバグが他の機能にも作り込まれていないか、横展開して確認します。
（注意）テストでバグが検出された場合であっても、必要に応じて上流成果物を再レビューします。テストで検出できているので、テスト自体に問題がある可能性は低く、レビュー観点の漏れが問題と考えられるからです。