プロジェクト報告書のテンプレート｜進捗・課題・リスクを 1 枚で見せる RAG ステータス活用ガイド

「報告書を 8 ページ書いたのに、結局『で、順調なの？順調じゃないの？』と聞き返された」——プロジェクト報告書の典型的な失敗です。読み手（PM オーナー・事業部長・PMO）は 1 件あたり 3 分以内しか集中力を割けません。にもかかわらず、現場の生情報を全部詰め込んだ 10 ページの報告書を送りつけると、**「読まれない・伝わらない・意思決定が止まる」**の三重苦に陥ります。本記事では、現役コンサル（具体企業名は伏せる）が実際に使う 1 枚サマリ＋詳細 2 層構造のプロジェクト報告書テンプレ と、RAG ステータスの判定基準、週次と月次の書き分け、現場で評価される運営術を完全解説します。

1. プロジェクト報告書とは｜目的と位置づけ

プロジェクト報告書は、プロジェクトの 進捗状況・主要課題・リスク・次のアクション を、定められた頻度（週次・月次）で PM 配下から PM オーナー（事業部長・役員クラス）に提出する定期文書です。報告先によって粒度が大きく異なる点が最大の特徴で、現場メンバー向け週報と役員向け月次報告を同じテンプレで書くと、双方から評価が下がります。

観点	週次報告	月次報告	ステコミ資料
主目的	現場の調整・課題吸い上げ	経営層への進捗共有	重要事項の意思決定
読み手	PM・サブリーダー・PMO	事業部長・PMO・主要関係者	役員・オーナー
ページ数	1〜2 枚	3〜5 枚	10 枚前後
必須情報	今週・来週・課題	RAG・KPI 進捗・主要課題	意思決定事項・選択肢
提出頻度	毎週金曜	月末第 1 営業日	月 1（定例）
判断粒度	戦術レベル	戦術＋戦略の橋渡し	戦略レベル

週次が「現場の燃料」、月次が「経営の燃料」、ステコミが「意思決定の燃料」と覚えると役割が混ざりません。

2. プロジェクト報告書の基本構造｜1 枚サマリ＋詳細の 2 層

1 スライド 1 メッセージの法則と同じく、1 枚目で全てが見える設計が鉄則です。経験豊富な読み手ほど 1 枚目で判断を済ませ、詳細ページは 「気になった項目だけ深掘りする」 という読み方をします。逆に 1 枚目で順調かどうかが分からない報告書は、3 枚目以降を絶対に読みません。

2.1 第 1 層｜1 枚サマリに含める 5 要素

RAG ステータス（全体・スケジュール・コスト・品質・スコープの 5 軸）
主要 KPI の進捗率（数値で示す）
今週／今月のトピック 3 件（達成事項・課題・次のアクション）
要意思決定事項（明示しないと判断は降りてこない）
報告者・報告日・対象期間

このうち最も省略されがちなのが 「要意思決定事項」。これを書かない報告書は、読み手から「何を期待されているのか分からない」と感じられ、結局メールでの追加催促に発展します。

2.2 第 2 層｜詳細ページに含める 7 項目

#	項目	用途
1	WBS／マイルストーン進捗	スケジュール RAG の根拠
2	KPI トレンドグラフ	主要 KPI の推移と着地予測
3	課題管理表（Issue Log）	顕在化済み課題の棚卸し
4	リスク登録簿（Risk Register）	顕在化前のリスクと緩和策
5	予算消化状況	コスト RAG の根拠
6	主要成果物の品質チェック結果	品質 RAG の根拠
7	次期（次週／翌月）の計画	アクションの方向性

3. RAG ステータスの判定基準と運用ルール

RAG とは Red（赤）・Amber（黄）・Green（緑） の頭文字で、プロジェクトの状態を 3 段階で色分けするコンサル標準の運用手法です。視覚的に状態が一目で伝わるため、役員クラスの初期スキャンで最も効果を発揮します。

3.1 標準的な RAG 判定基準

ステータス	意味	一般的な判定基準（例）	求められるアクション
🟢 Green	計画通り	遅延 5% 未満／予算消化 ±5%／重大リスクなし	継続観察
🟡 Amber	要注意	遅延 5〜15%／予算超過懸念／中リスク顕在	緩和策の事前準備・週次注視
🔴 Red	要対応	遅延 15% 超／予算 10% 超過確実／重大リスク顕在	即時意思決定・体制／スコープ／予算の見直し

3.2 5 軸 RAG｜全体ではなく観点ごとに色を付ける

「全体 RAG = Green」とだけ書くのは情報量がゼロです。コンサル現場では 5 軸 RAG が標準で、観点ごとに色を分けます。

軸	評価対象	例（Amber 判定の理由）
総合（Overall）	プロジェクト全体の健全性	スケジュールが Amber のため
スケジュール	マイルストーン達成度	要件定義工程が 1 週間遅延
コスト	予算消化と着地予測	外部委託 1 ベンダー追加検討中
品質	成果物の品質状況	レビュー指摘密度が想定の 1.4 倍
スコープ	範囲変更・追加要求の状況	追加要望 2 件の取り扱い未定

5 軸の RAG を 1 行表で示すと、読み手は **「何が原因で総合が Amber なのか」**を 5 秒で特定できます。

3.3 Amber と Red の切り替え運用｜「黙って Red にしない」ルール

経験豊富な PMO ほど **「先週 Green が、今週いきなり Red」**という飛び方を嫌います。Green → Amber → Red の段階を必ず踏むこと、そして Amber に変えた瞬間に 緩和策と意思決定の選択肢を併記することが、信頼される報告書のコツです。

4. プロジェクト報告書の標準 8 セクション

報告書 1 枚サマリ＋詳細を構成する 標準 8 セクションは以下の通りです。

ヘッダー — プロジェクト名・報告日・対象期間・報告者・回数（第 12 回など）
エグゼクティブサマリー — RAG（5 軸）＋一文サマリ＋要意思決定事項
今期のハイライト — 達成事項 3 点・主要課題 3 点（PREP 法で簡潔に）
マイルストーン進捗 — 当初予定 vs 実績・着地見通し
KPI 進捗 — 主要 KPI 3〜5 件と推移グラフ
課題と対応 — 顕在化済み課題 Top 5＋オーナー＋期日
リスクと緩和策 — 未顕在リスク Top 5＋発生確率 × 影響度
次期計画と要支援事項 — 来週／翌月のアクション・支援依頼

4.1 エグゼクティブサマリーの書き方

エグゼクティブサマリーの作り方で詳説していますが、プロジェクト報告書のサマリーは **「総合 RAG → 一文サマリ → 要意思決定事項」**の 3 ブロックを定型化することが重要です。

【良い例】 総合：🟡 Amber（スケジュール遅延 1 週間／緩和策実施中）要件定義工程の追加レビュー要求により 1 週間の遅延が発生。並行作業による吸収を検討中。 要意思決定事項： 基本設計開始時期の 1 週間後ろ倒し（YES／NO）

【悪い例】各工程順調に進捗中ですが、要件定義で一部追加要望が発生しており検討中です。

悪い例は **「RAG なし・遅延幅なし・意思決定事項なし」**の三重苦。読み手は何を判断すべきか分かりません。

4.2 KPI 進捗｜トレンドを見せる

KPI は単月の数字ではなく **「直近 3 ヶ月のトレンド」と「期末着地予測」**を併記します。折れ線グラフの使い方の通り、時系列推移は折れ線で見せるのが鉄則です。「目標 vs 実績 vs 予測」の 3 系列を 1 グラフに重ねると、進捗の方向性が即座に伝わります。

4.3 課題と対応｜オーナーと期日を必ず書く

課題管理は「誰が・いつまでに」が空欄になった瞬間に放置されます。標準フォーマットは以下の通り。

#	課題内容	影響度	オーナー	期日	ステータス
1	要件追加 5 件の取り扱い未定	大	業務 PM	06-15	検討中
2	ベンダーリソース 0.5 人月不足	中	調達	06-20	増員調整中
3	UAT 環境構築の遅延	中	IT 担当	06-10	完了見込み

オーナー欄が「TBD（未定）」のまま 2 週間続いたら、それは課題ではなくリスクに格上げすべきです。

5. 週次報告と月次報告の書き分け

同じテンプレを 2 つの粒度で書き分けるのが現場の腕の見せどころです。

項目	週次（1〜2 枚）	月次（3〜5 枚）
RAG 軸	総合のみ or 3 軸	5 軸フル
KPI	当週実績のみ	トレンド + 着地予測
課題件数	当週オープン分のみ	クローズ／オープン累積
リスク	新規顕在分のみ	全 Top 5＋再評価
詳細ページ	なし（1 枚で完結）	あり（WBS・課題簿・リスク簿）
想定読了時間	3 分	10 分
提出経路	Teams／Slack	PPT 配布＋月次定例で読み合わせ

5.1 週次は「金曜 17 時固定」が鉄則

週次報告は 曜日と時刻を固定します。受け取り側が月曜朝に「先週の状況を一括で確認する」ルーチンを作れるようにするためです。提出時刻がバラバラだと、読み手側のレビュー時間も確保できません。

5.2 月次は「月初第 1 営業日まで」が標準

月末の数字が固まる 第 1 営業日にまとめて提出するのがコンサル標準です。月初第 2〜3 営業日にずれ込むと、月次定例での意思決定が翌月以降に流れます。

6. やってはいけない 5 つの NG パターン

6.1 NG① RAG なし／総合のみ

「全体的に順調です」とだけ書く報告書は、3 軸〜5 軸で観点別に分解しないと どの軸で破綻が始まっているかが見えません。必ず観点別 RAG を採用してください。

6.2 NG② 要意思決定事項なし

報告書の最大の目的は「読み手にアクションを取らせる」こと。意思決定事項を 明文化していない報告書は、結局メールで個別催促することになり、PM の運営工数を膨らませます。

6.3 NG③ 課題のオーナー空欄

オーナー欄が「全員」「PMO」「TBD」のいずれかになっている課題は 必ず放置されます。1 人の固有名詞を書くことが鉄則。

6.4 NG④ KPI が単月のみ

単月の数字だけ見せても、期末に間に合うのかどうかが判断できません。必ず「トレンド＋着地予測」の 3 系列折れ線にしてください。

6.5 NG⑤ Green が突然 Red に飛ぶ

Amber 段階で問題を上げず Green のまま隠していると、Red に飛んだ瞬間に **「なぜ早く言わなかった」**と信頼を失います。Amber は遅延 5% 段階で迷わず点灯するのが、信頼される PM の作法です。

7. 実践チェックリスト

報告書を提出する前に、以下を必ず満たしているか確認してください。

✅ 1 枚目（サマリ）が 30 秒で全体像が掴める設計か
✅ RAG が 5 軸（総合・スケジュール・コスト・品質・スコープ）で示されているか
✅ Amber 以上の項目に 緩和策と意思決定の選択肢が併記されているか
✅ **「要意思決定事項」**欄が明示されているか
✅ 主要 KPI が トレンド＋着地予測で示されているか
✅ 課題管理表に オーナー・期日が漏れなく入っているか
✅ 課題管理表で オーナーが固有名詞（チーム名や TBD でない）か
✅ リスクが 発生確率 × 影響度で評価されているか
✅ 文字サイズが 本文 18pt 以上、配色が3 色ルールに従っているか
✅ 提出期限（週次：金曜 17 時／月次：第 1 営業日）を 守れているか
✅ 次期計画と 要支援事項が分けて書かれているか

8. まとめ

プロジェクト報告書は、PM が **「現場の状況を経営の言語に翻訳する」**ための最重要文書です。翻訳の質が高い PM は、報告書 1 枚で経営層の信頼を勝ち取り、必要な支援を引き出せます。

構造は 1 枚サマリ＋詳細の 2 層——サマリ 30 秒・詳細 5 分の読了時間設計
RAG は 5 軸（総合・スケジュール・コスト・品質・スコープ）で観点別に分解
判定基準は 遅延率・予算超過率・課題件数の閾値を立ち上げ時に数値化
標準は 8 セクション（ヘッダー・サマリ・ハイライト・マイルストーン・KPI・課題・リスク・次期計画）
週次は 1〜2 枚／金曜 17 時固定、月次は 3〜5 枚／第 1 営業日
NG 5 大は 「RAG なし・意思決定事項なし・オーナー空欄・単月 KPI・突然 Red」
Amber は 早めに点灯——「黙って Red にしない」が信頼される PM の作法

報告書のテンプレが固まったら、次は月 1 のステコミ資料や、半期ごとの経営会議資料へと展開していきます。優秀な PM は、例外なく「報告書の様式」に異常な執着を持っています——様式が固まれば、現場の運営工数が劇的に減るからです。