プロジェクト進捗報告書の書き方でいちばん多い悩みは、「何を書けばいいかわからない」ではありません。書いたのに伝わらないことです。
きちんとまとめたつもりなのに、定例会で「で、結局間に合うんですか？」と聞き返される。あるいは、毎週きれいな資料を出しているのに、終盤になって突然スケジュールが崩れる。
この記事では、進捗報告書に載せる6つの項目と、その一つひとつを「詰められない書き方」にするコツをまとめます。筆者が20年以上、銀行・保険・製造・官公庁といった業界の導入プロジェクトで報告する側・される側の両方を経験してきたなかで、実際に効いたものだけを残しました。
進捗報告書とは｜誰に何を伝えるための資料か
進捗報告書とは、プロジェクトの現在地と、このまま進んだときの着地見込みを、関係者に共有するための資料です。
ここで大事なのは、進捗報告書は「作業した証明」ではないという点です。報告を受ける側が知りたいのは、突き詰めると次の3つだけです。
- 予定どおりか（予定とのズレはどれくらいか）
- このままいくとどうなるか（着地はいつ・どんな品質か）
- 判断してほしいことはあるか（意思決定・追加リソース・スコープ調整）
「今週これをやりました」の羅列は、このどれにも答えていません。作業量は伝わりますが、相手が次にとるべき行動が何も決まらないからです。詰められる報告書の大半は、ここが抜けています。
進捗報告書と似た資料に日報・週報がありますが、役割が違います。日報・週報が「担当者の作業記録」であるのに対し、進捗報告書は「プロジェクト全体の意思決定材料」です。読み手も、担当者の上長ではなく、プロジェクトオーナーや顧客側の責任者になります。
進捗報告書に書く6つの項目（構成フォーマット）
週次定例会で顧客に報告する場面を想定した、標準的な章立てです。この順番には意味があります。前回の宿題 → 全体 → 詳細 → 課題 → 打ち手と並べることで、読み手が「安心 → 理解 → 判断」の順にたどれるようにしています。
| # | 項目 | 目的 |
|---|---|---|
| 1 | 前回TODOの消化状況 | 約束を守っていることを最初に示す |
| 2 | 全体スケジュールに対する進捗 | 着地見込みを一目で伝える |
| 3 | 工程別の進捗 | どの工程が重いかを示す |
| 4 | WBSベースの定量進捗 | 主観を排して数字で裏づける |
| 5 | 課題・リスク | 判断してほしいことを明示する |
| 6 | 遅延時のリカバリー策 | 打ち手とセットで不安を消す |
① 前回TODOの消化状況
報告書の一番上に置きます。前回の定例会で「持ち帰ります」と言った項目が、今どうなっているかです。
ここを最初に置く理由は、信頼の回復コストが非常に高いからです。宿題を放置したまま新しい進捗を語ると、読み手は「都合の悪いことは飛ばす人だ」と学習します。一度そう思われると、以降の報告はすべて疑いの目で読まれます。
書き方は、項目ごとに「完了 / 対応中 / 未着手」と次のアクションの期限をセットで書くだけで十分です。未着手を隠す必要はありません。未着手で困るのは、理由と再設定した期限が書かれていないときです。
② 全体スケジュールに対する進捗
マスタスケジュール（プロジェクト全体の工程表）に対して、今どこにいるかを示します。
ここでは細かい数字より、「予定線」と「実績線」を並べて見せることを優先します。ガントチャート上に今日の日付を縦線で入れ、各工程のバーが線の左右どちらにはみ出しているかがわかれば、読み手は一目で状況を把握できます。
マスタスケジュールそのものの作り方は、別記事で工程の分け方から解説しています。
マスタスケジュールに対する進捗を報告するページの例です。
③ 工程別の進捗
要件定義・設計・開発・テストといった工程単位で、それぞれの進み具合を報告します。
全体では順調に見えても、特定の工程だけが遅れているケースは非常に多いです。とくに設計工程は、成果物ができあがるまで遅延が表面化しません。全体の平均値だけで報告すると、この「一部だけ重い」状態が見えなくなります。
工程ごとに、予定・実績・差異の3列で並べるのが最もシンプルです。差異がプラスの工程には、必ず後述の⑥（リカバリー策）を紐づけます。
工程ごとの状況をアイコンで一目で分かるようにしたページの例です。
④ WBSベースの定量進捗
WBS（作業分解構成図）のタスク単位で、完了数と全体数から進捗率を算出します。
ここが、報告書の信頼度を決める部分です。次の章で詳しく扱います。
WBSのタスクを工程別に集計し、グラフ化したページの例です。
⑤ 課題・リスク
課題（すでに起きている問題）とリスク（まだ起きていないが起こりうる問題）は、分けて書きます。
混ぜて書くと、読み手はどちらに反応すべきかわからなくなります。課題には「対応者と期限」を、リスクには「発生したときの影響度と、その予兆」を添えます。
⑥ 遅延時のリカバリー策
遅れが出ている項目には、必ず打ち手をセットで書きます。遅延の報告だけを単独で出さないのが鉄則です。
打ち手の型は、実務上ほぼ次の4つに収まります。
| 打ち手 | 内容 | 注意点 |
|---|---|---|
| 要員追加 | 人を増やす | 立ち上がり期間の分、短期的には遅くなる |
| 並行化 | 直列作業を並列に組み替える | 手戻りリスクが上がる |
| スコープ調整 | 今回の対象範囲を削る | 顧客判断が必要。最速で効く |
| 期限変更 | 納期そのものを動かす | 最終手段。早く相談するほど選びやすい |
このうちスコープ調整と期限変更は、報告する側が単独で決められません。だからこそ、判断材料を揃えて相談する場が定例会になります。「どうにかします」で持ち帰ってしまうと、この判断の機会そのものが失われます。
遅延に対する打ち手を示すページの例です。
進捗率「80%」が信用されない理由と、定量で示す方法
進捗報告でいちばん揉めるのが、この進捗率です。
「設計は80%完了しています」と報告して、翌週も80%、その翌週も85%——という経験は、多くの現場にあると思います。これは担当者がサボっているからではありません。80%の定義が人によって違うからです。
作業者の感覚では「頭の中では8割できている」が80%になります。しかし読み手は「残り2割の時間で終わる」と受け取ります。この2つは、まったく別のことを指しています。
主観を排する3つの方法
方法1：完了の定義を先に決める（Definition of Done）
タスクごとに「何をもって完了とするか」を先に決めておきます。設計書であれば「レビュー指摘の反映まで終わった状態」といった具合です。定義が1つに決まれば、進捗は「完了 / 未完了」の2値になり、感覚が入り込む余地がなくなります。
方法2：0-50-100ルールで刻む
とはいえ、すべてを2値にすると数週間ゼロが続く工程が出ます。そこで使うのが0-50-100ルールです。未着手を0%、着手したら一律50%、完了したら100%とし、それ以外の数字を使いません。「70%」「85%」という主観的な刻みを、ルールとして禁止してしまう方法です。
方法3：分母をタスク数で持つ
「全120タスク中、完了78タスク（65%）」という書き方にします。分母と分子が具体的な数で示されるため、読み手が自分で検算できます。検算できる数字は、それだけで信用されます。
やってはいけない書き方
- 工数比率と件数比率を混ぜる：「タスク数では65%だが工数では40%」という状態は普通に起こります。どちらの基準で語っているかを毎回明記します
- 完了率だけを見せて残件を隠す：残っているタスクの中身（難易度の高いものが後ろに固まっていないか）が、実は最も重要な情報です
報告相手で書き分ける（経営層／PMO／現場）
同じプロジェクトの進捗でも、読み手によって知りたいことがまったく違います。1つの資料を全員に配って済ませようとすると、誰にも刺さらない報告書になります。
| 読み手 | 知りたいこと | 載せる粒度 |
|---|---|---|
| 経営層・プロジェクトオーナー | 着地するのか。判断が必要か。いくらかかるか | 1ページ。信号の色と、判断してほしい1点 |
| PMO・管理部門 | 計画との差異。他プロジェクトとの比較 | 数値と差異の一覧。フォーマットの統一が最優先 |
| 現場リーダー・メンバー | 自分の担当がどこにどう影響するか | タスク単位の詳細。依存関係が見えること |
実務上おすすめなのは、詳細版を1本作り、そこから経営層向けのサマリー1ページを切り出す運用です。逆（サマリーから詳細を作る）は必ず破綻します。数字の出どころが揃わなくなるためです。
経営層向けの1ページに載せるのは、次の3つで足ります。
- 全体ステータス（順調 / 注意 / 遅延の3段階）
- 着地見込み（当初計画との差）
- 判断してほしいこと（1つに絞る）
3つ目が最も重要です。何も判断を求めない報告は、読み手にとって「読まなくてよい資料」になります。
報告頻度と粒度の決め方
「週次でやっているから週次」で続けている定例会は少なくありません。頻度は、プロジェクトのフェーズと、意思決定の必要な速度で決めます。
| フェーズ | 推奨頻度 | 理由 |
|---|---|---|
| 立ち上げ・要件定義 | 週次 | 決めることが多く、判断の遅れが直撃する |
| 設計・開発 | 週次〜隔週 | 変化が緩やか。日次の細かい報告は不要 |
| 結合テスト以降 | 日次または週2回 | 不具合の発生速度に報告が追いつかなくなる |
| 移行・カットオーバー直前 | 日次 | 判断が数時間単位で必要になる |
粒度についての原則は1つです。報告の頻度を上げるときは、必ず粒度を粗くします。
日次報告で週次と同じ粒度の資料を求めると、報告のための作業がプロジェクトを圧迫します。日次はステータスと課題だけ、週次で数値と分析、月次で計画との差異分析——というように、頻度と深さを反比例させるのが現実的です。
進捗報告が形骸化する3つのパターンと対処
長く続くプロジェクトほど、進捗報告は形だけになりがちです。典型的なパターンは3つです。
パターン1：「順調です」しか出てこない
問題が起きていないのではなく、問題を報告する場になっていない状態です。過去に遅延を報告した人が強く責められた現場では、ほぼ確実にこうなります。
対処としては、報告フォーマットに「懸念事項」の欄を必須項目として設けるのが効きます。空欄で出すことを許さないルールにすると、小さな違和感が言語化されて上がってくるようになります。
パターン2：資料を作ることが目的になる
きれいな資料が毎週出てくるのに、議論が起きない状態です。作成に何時間もかかっているのに、会議では読み上げるだけで終わります。
対処は、資料を事前配布して、会議では課題と判断事項だけを扱うことです。読み上げのために集まる時間をなくすと、資料の装飾に時間をかける動機も消えます。
パターン3：報告と実態がずれていく
報告上は順調なのに、終盤で急に崩れるパターンです。原因はほぼ、前述の進捗率の主観化にあります。
対処は、成果物ベースで確認することに尽きます。「設計80%」ではなく「設計書◯本中◯本がレビュー完了」で見ます。実物が存在するかどうかは、解釈の余地がありません。
AIに進捗報告の下書きを作らせる
ここ数年で現実的になった選択肢として、生成AIに報告書の下書きを作らせる方法があります。
進捗報告書の作成時間の大半は、情報を集めて整形する作業です。課題管理表、WBS、議事録、チャットのやりとり——これらはすでにテキストとして存在しているので、要約と整形はAIが得意とする領域です。
現実的なワークフローは次のようになります。
- 課題管理表とWBSの当週分をエクスポートする
- 前回の議事録とあわせてAIに渡し、6項目の章立てに沿って下書きを作らせる
- 出てきた下書きに対して、判断事項と着地見込みだけを人間が書き直す
ここで重要なのは、3番目を人に残すことです。事実の整形はAIで十分ですが、「このままいくとどうなるか」の見立てと「何を判断してほしいか」の設計は、プロジェクトの文脈を持っている人にしか書けません。
逆に言えば、1と2に費やしていた時間を、3に振り向けられるということです。報告書が形骸化する最大の原因が「作ることが目的化する」ことである以上、この時間配分の変化そのものが効きます。
なお、顧客の非公開情報を外部サービスへ渡すことになるため、利用可否は必ず契約と社内規程を先に確認してください。
そのまま使えるテンプレート（PPT）
ここまでの6項目の章立てをそのまま反映したPowerPointテンプレートを配布しています。表紙・サマリー・工程別進捗・課題管理まで、ページ構成ごとサンプルとして確認できます。
あわせて、進捗管理そのものに使うExcel系のテンプレートもご用意しています。
本記事で扱った①〜④に続く、工程別の詳細報告・品質状況・その他連絡事項の書き方は、続編で解説しています。
よくある質問
Q. 進捗報告書と日報・週報の違いは？
日報・週報は担当者の作業記録で、読み手は上長です。進捗報告書はプロジェクト全体の意思決定材料で、読み手はプロジェクトオーナーや顧客側の責任者になります。同じ内容を流用すると「作業報告」になり、判断につながりません。
Q. 遅延しているとき、どう報告すればいいですか？
遅延の事実・原因・影響範囲・リカバリー策の4点をセットで出します。最もまずいのは、遅延を小さく見せようとして表現を曖昧にすることです。打ち手のうちスコープ調整と期限変更は相手の判断が必要なため、早く出すほど選択肢が残ります。
Q. 進捗率は何を分母にすべきですか？
タスク数を基本とし、工数比率を併記するのが実務的です。どちらか一方だけだと実態を見誤ります。いずれの場合も、分母を毎回明示してください。
Q. 報告書は何ページが適切ですか？
経営層向けは1ページ、実務向けの詳細版は制限を設けなくて構いません。ページ数より、判断してほしいことが1ページ目に書かれているかが重要です。
Q. 定例会が形骸化しています。何から変えればいいですか？
資料の事前配布から始めてください。会議の時間を「読み上げ」から「課題と判断」に振り替えるだけで、資料の作り方も自然に変わります。
まとめ
- 進捗報告書が答えるべきは、予定どおりか／このままどうなるか／何を判断してほしいかの3つ
- 章立ては前回TODO → 全体 → 工程別 → 定量 → 課題 → リカバリー策の6項目。この順番が読み手の理解を助ける
- 進捗率は完了の定義を先に決め、検算できる形（◯件中◯件）で示す。「80%」は主観が入り込む
- 読み手ごとに書き分ける。 経営層向けは1ページ、判断してほしいことを1つに絞る
- 情報の収集と整形はAIに任せ、着地見込みと判断事項を人が書く時間配分に変える
進捗報告は、うまくいっているプロジェクトを飾るための作業ではありません。問題を早く見つけて、判断を早く仰ぐための仕組みです。報告のたびに詰められている状況は、多くの場合、書き手の努力不足ではなく構成の問題です。まずは章立てを揃えるところから始めてみてください。
大変ためになる記事をありがとうございます。
1点質問があります。
2.進捗状況（サマリー）ご報告
報告内容は以下のように基本的に1つの事項に対して1、2行程度でまとめて状況を記載します。重要な事項や補足は別のページで詳細を報告します。
ここでいう「以下のように」にあたる記載が見当たらなかったのですが、テンプレートスライド「進捗サマリー(全体)」の記入例があれば教えてください。
コメントありがとうございます。スパムが多くて気が付くのが遅くなり申し訳ございません。
確かに記入例が漏れておりましたので、記事の修正させていただきました。以下の内容を追記しております。
（参考）
本日時点で設計70%完了の計画となっているが仕様調整が難航しており達成率65%で遅延しているが、設計要員を0.5人月追加することで、今月中にリカバリー可能な見込み。マスタスケジュールへの影響はなし
Very interesting details you have mentioned, regards for putting up.Raise blog range