プロジェクト遅延の報告例｜事実・影響・回復案・判断依頼を分ける
遅れが見えたとき、「原因が全部分かってから報告しよう」と待つと、上司が対応を選べる時間を失うことがあります。事実と未確認を分ければ、原因が確定する前でも相談できます。
この記事は、定期の週次報告ではなく、納期への影響が見えた際の追加報告に絞ります。文例の日程や状態は説明用で、著者の実案件を再現したものではありません。
最初に、何の判断が必要なのかを伝える
「進捗が悪いです」だけでは、受け手は何を決めればよいか分かりません。どの成果物が、どの計画からずれ、どこへ影響する見込みかを伝えます。そのうえで、相談するのが追加調査、優先順位変更、日程調整のどれかを明示します。
遅延の実績と将来の見込みも分けます。「昨日の完了予定を超えた」は事実、「公開予定に二日影響する可能性」は見込みです。まだ計算できない影響を、確定した日数として書かないことが重要です。
事実・影響・原因・対応案を切り分ける
| 区分 | 説明用の記入例 |
|---|---|
| 事実 | 予定時点までに権限条件が確定せず、該当テストを開始できていない |
| 影響 | 権限テストが受入確認の前提。完了見込みは再計算中 |
| 原因 | 判断者の確認待ち。追加確認の必要項目はまだ整理中 |
| 既に行ったこと | 確定済み部分のテストと、未決項目一覧の作成を進めている |
| 対応案 | 判断を前倒しする／対象を分離する／受入予定を調整する |
| 判断依頼 | 対象分離を検討してよいか。利用部門への相談窓口を確認したい |
| 次の報告 | 回答予定と残作業を確認した時点で更新する |
責任追及の言葉より、止まっている条件を説明します。「担当が遅い」ではなく「どの回答がいつ必要で、現在どういう状態か」と書く方が、対応先と必要な支援を決められます。
回復案には、成立条件と失うものを書く
人を追加するなら、分担できる作業と権限付与・説明の時間を確認します。作業を並行するなら、先に決まっていない条件が変わった場合の手戻りを見ます。範囲を減らすなら、利用者への影響と残る運用を示します。
「テストを短縮すれば間に合う」は、それだけでは回復案になりません。削る内容、残るリスク、判断者の承認、代替の確認方法が必要です。PMOが品質条件を独断で緩めないようにしてください。
日程変更案も失敗の宣言ではありません。元の条件を守った場合の現実的な終了見込みとして、他の案と比較します。外部への約束を変更する場合は、責任者が連絡する順序も確認します。
報告の第一報は短く、未確認を隠さない
権限条件の未確定により、予定していたテストを開始できていません。
受入確認の前提に当たるため、日程への影響を調べています。
現時点で影響日数は確定していません。
確定済み部分は継続し、未決条件と判断者を整理しています。
対象分離の案を利用部門と相談してよいか、確認をお願いします。
回答予定を確認でき次第、終了見込みと比較案を更新します。この文例に「順調です」といった安心させるだけの表現を足す必要はありません。逆に、すべてを危機として強く表現すると、優先順位がつきにくくなります。業務影響と判断が必要な時間で緊急度を説明します。
判断後は、計画と関係者への連絡へ落とす
上司から方針が出ても、担当の作業が自動的に変わるわけではありません。判断内容・対象版・条件を記録し、WBS、課題表、関係チームの予定を更新します。外部説明が必要なら、誰がどの情報を伝えるかを決めます。
遅れが解消したときは、作業が完了したのか、日程を変更して合意したのか、範囲を分離したのかを区別します。「解決」とだけ書くと、何が残ったか分からなくなります。
最終的な振り返りでは、報告の遅さ、見積条件、判断待ち、作業量の増加を分けます。第一報を早くする仕組みと、原因の再発を減らす仕組みは別々に改善できます。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
計画基準との差分を捉える考え方の確認に使用。報告文と判断期限は説明用です。 Atlassian：Project Baseline（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
週次報告書の書き方も必要な作業に合わせて参照してください。
アイキャッチ写真：2H Media / Unsplash。職場の実写ではなくイメージ写真です。
