各事例の表中にタスクとレビューという言葉がでてきますが、それぞれを以下のように定義します。

• タスク： 成果物を作成する段階
• レビュー： 成果物をレビューし、指摘や課題を解決する段階

また、ポイントを分かりやすくするため、表中には、以下の数値だけを記載しております。

• SV：スケジュール差異
• CV：コスト差異

＜事例1＞　 レビュー完了までが責任範囲です

タスク側のCVからは、4.5Hの余力を残して完了しているということがわかります。
しかし、レビューの段階になると、一変して、進捗も遅れだしています。
CVが-7.0Ｈということは、タスク側で余らせていた時間も使い切ってしまっています。

考えられる原因としては、

指摘が多く、成果物の完成度が低くいのではないかということが予想されます。
この状況は、生産性が高いとは言えません。レビューでは、複数の人の時間を拘束することになりますので、そこに時間をかけると生産性は上がりにくいです。
また、単純ミスの指摘が多い状況では、見つけておかないといけないバグを見落とすリスクも高まり、品質を落としている場合が多いです。
生産性が高いことを示したかったのかもしれませんが、品質を犠牲にしてしまっては意味がありません。
タスク側の完了までが自分の責任範囲という認識をしている場合は、レビュー完了までが責任範囲と、認識を改めたほうがよさそうです。

＜事例2＞　〆切間近に追い込みをかけてないですか

タスク自体は予定工数、予定期間内で終わっています。
レビューの状況は、事例1と数値的には同じです。

本質は、事例1と変わっていません。問題は、いずれにしても成果物の完成度が低いということだと思います。
この場合は、〆切間近に追い込みをかけているかもしれないため、自己レビューの時間が十分に確保できていない可能性があります。
もし、タスク側を「予定工数の範囲内でできる限りの物を作ることである」と認識している場合は、100%完成するまでがタスク側の作業範囲と認識したほうがよさそうです。

＜事例3＞　マイナスは絶対悪ではない

極端な例ではありますが、CVが-4.5Hとなっていますので、事例1や事例2とは違いタスク自体は、予定工数を超過しての完了になっています。
しかし、レビューの段階では指摘がなかったのか、予定を大幅にショートしています。（タスク側の工数オーバーをレビュー時間の短縮で取り戻しています。）
一時的にマイナスにはなったものの、最終的には、事例1や事例2よりも生産性が高いという結果になっています。

ちょっとしたことでもクリアにしないと、先に進まないタイプなのかもしれませんが、結果からすると、タスク側で発生したマイナスは、作業を効率よく進めるために必要な時間だったのだと思われます。
事例3で気をつけることとしては、余計な作業をしていないかです。別作業者が同じことを検討していては時間がもったいないため、課題などは情報共有しておくことが重要です。
目の前の担当作業だけを意識しがちですが、後の工程で効率が上がるように、考えられれば、さらに有利となります。

紹介事例まとめ

事例1や事例２については、作業者が考え方を改める必要があるのですが、感情的に判断する人に指摘をすると、感情のぶつかり合いになることがあります。それでは話が先に進みませんので、そのあたりはAIに指摘させることにしましょう。

対人間だと感情の戦いに発展するかもしれませんが、対AIでは戦いようがないですよね。
（半分冗談、半分本気です。）