実績値が、計画した許容範囲内に入っているかを見ます。

＜予実差を見るタイミング＞

予実差を見て、対策を立てるタイミングは、開発スケジュールの立て方により、次の2つに分かれます。

Ａ）個々の機能（○○画面、○○アプリ、○○バッチ・・・などの開発の単位）毎に期間の調整が可能な場合。

週次程度の間隔で、予実差を見ます。必要に応じて対策を実施します。

参考文献）
　　クリティカルチェーン ～なぜ、プロジェクトは予定どおりに進まないのか?
　　エリヤフ・ゴールドラット／著　三本木亮／訳　ダイヤモンド社

Ｂ）個々の機能の期間が固定であり、品質対策が必要な場合は、皇帝完了時に実施する場合

工程完了時に予実差を見ます。
この場合でも、週次程度の間隔での定量値の確認をし、大きな異常値がないことを確認します。

＜予実差を分析し、対策を立てる＞

Ａ）検証の網羅度、検証の品質

ａ）レビュー密度（規模あたりのレビュー時間）
分析）
レビュー密度が計画値より低い場合、レビュー時間が不足している可能性があります。
対策）
レビュー対象の機能の難易度が低いなどの場合を除き、再レビューを実施します。

ｂ）テスト密度（規模あたりのテスト項目数）
分析１）
テスト密度が計画値より低い場合、テスト項目数が不足している可能性があります。
対策１）
テスト仕様書（テスト項目）をレビューし、不足があれば追加テストをします。
分析２）
テスト密度が計画値より大きい場合、テストが冗長になっている可能性があります。
　　例）必要以上のパターンの組み合わせでテストしている。
対策２）
テスト項目数が多くなっている部分を中心に再レビューをし、冗長になっている項目を削除します。

ｃ）レビュー効率（下限のみ）（レビュー時間あたりの検出バグ数）
分析）
レビュー効率が計画値より低い場合、レビューアの検出状態が悪化している可能性があります。
対策）
レビュー時間がかかっている理由、バグ検出が低い理由がない限り、レビュー観点を見直した上での再レビュー、または、別のレビューアによる再レビューをします。

ｄ）レビュー効率偏差値（下限のみ）（機能毎）
　　（そのレビューアのれゆーの中での検出状態の良否）
分析）レビュー効率偏差値が計画値より低い場合、対象のレビューアが、その機能に限り検出状態が悪い可能性があります。
　　例）苦手な機能だった。体調が悪かった。
対策）
レビュー時間がかかっている理由、バグ検出が低い理由がない限り、レビュー観点を見直した上での再レビュー、または、別のレビューアによる再レビューをします。