PMO

【無料DL】PMOテンプレート集|進捗報告書・週報・課題管理表のExcel雛形

2026.07.23PMO テンプレート進捗報告書課題管理表

【無料DL】PMOテンプレート集|進捗報告書・週報・課題管理表のExcel雛形

PMOや事務局を任されて最初に困るのは、たいてい「管理資料の雛形が社内にない」ことです。進捗報告書、週報、課題管理表。ベンダーから上がってくる報告をただ受け取るだけでは管理になりませんが、かといってゼロからExcelを設計する時間もない。この記事では、僕が受注側のPMとして、独立後はPMO支援の立場で使ってきた管理資料の構成を、記入例つきでそのまま公開します。本文の表をExcelに写せば今日から使えますし、記入例入りのExcel一式はこちらのダウンロードページから無料で受け取れます。ただし先に言っておくと、テンプレートは配った日から形骸化が始まります。だから書式だけでなく、形骸化させない運用のコツと、自社向けカスタマイズの注意点までセットでまとめました。

テンプレートは「埋める書類」ではなく「判断の道具」

具体的な書式に入る前に、前提を1つだけ共有させてください。PMO管理資料の目的は、記録を残すことではなく、判断を早くすることです。進捗報告書は「先週何をしたか」を残す日誌ではなく、「このまま行けるのか、手を打つのか」を決めるための材料。ここがズレたテンプレートは、どれだけ項目が立派でも、埋める作業だけが残ります。

僕は、プロジェクトマネジメントは牛角のマニュアルと同じだと思っています。牛角はマニュアルがあるから、バイト初日の店員でも美味しい焼肉を出せる。プロジェクト管理も体系化さえすれば、特別に優秀な人材でなくても70点の仕事ができるはずで、テンプレートはその体系のいちばん小さな部品です。逆に、書式を持たない我流の管理でうまく回っているように見える現場は、たいてい担当者の記憶力で持ちこたえているだけで、常にうっすら燃えています。

もう1つ。管理資料が拾うべきは、起きてしまった問題よりも問題の予兆です。事後対処のコストは事前対処の3〜5倍かかるというのが僕の実感で、週次の報告書や課題管理表は「前始末」を機能させるための仕掛けだと捉えてください。YouTubeでプロジェクト全体計画の書き方を解説したとき、僕はこう話しました。

プロジェクト全体の失敗率を下げる、そして効率を上げるという意味で、PMができる仕事の中で一番費用対効果が高い、価値が高いのがこのプロジェクト全体計画書の作成なんですよ

これから紹介するテンプレート群は、この計画の思想を週次の運用に落とすための道具です。それぞれの書式がPMOのどの業務に対応するのかを先に押さえておきたい方は、PMOの仕事内容をタスク一覧で整理した記事で全体像を俯瞰してから読み進めると、位置づけが掴みやすくなります。

そのまま使えるPMOテンプレート5点|列構成と記入例

以下の5点を、列構成・記入例・書き方のポイントの順で紹介します。表の項目をExcelの1行目に貼れば、そのまま雛形として機能します。

1. 進捗報告書(週次・プロジェクト単位)

発注側の定例会議に載せる週次サマリーです。

項目記入例
対象期間7/1〜7/4
全体ステータス注意(結合テストの消化が予定比▲12本)
今週完了した成果物会員登録画面の詳細設計書(レビュー指摘反映済み)
予定との差分帳票設計2本が3営業日遅延、残工数6人日
課題トップ3外部API仕様の回答待ちが5営業日継続(ID-023)ほか
判断・支援してほしいこと帳票2本の優先順位入れ替え可否を次回定例で決定したい

書き方のポイントは3つあります。まず、進捗率○%で書かせないこと。進捗率は計算根拠が人によって違うので、成果物の完了本数と残工数で書く。次に、全体ステータスは「順調・注意・危険」の3値に定義を添えること。僕は「注意=遅れはあるがリカバリ策を実行中」「危険=発注側の判断がないと戻らない」と定義しています。最後に、「判断・支援してほしいこと」を必須欄にすること。この欄が数週間ずっと空欄なら、報告が判断につながっていないサインです。

2. 週報(チーム・メンバー単位)

項目記入例
今週の完了物決済APIの単体テスト12本(全件消化)
来週の予定決済APIの結合テストに着手
担当タスクの完了予定日7/18 → 7/23(+3営業日)
止まっていること・困りごと検証環境のアカウント発行待ち(依頼から4営業日)

4項目だけ。5分で書ける分量に絞るのが肝です。仕掛けは「完了予定日」の欄で、毎週書かせて前週と比較すれば、「順調です」「対応中です」という言葉を数字の変化に置き換えられます。予定日が毎週すこしずつ後ろへ滑っていく状態は、口頭報告では絶対に見えません。困りごと欄は「なし」が続くほうをむしろ疑ってください。

3. 課題管理表

1行1課題で、列構成は次の9列です。

  • ID/起票日/課題内容/放置した場合の影響/対応方針/担当/期限/ステータス/最終更新日

記入例:ID-023|7/2起票|外部API仕様の回答待ち|回答が7/11を過ぎると結合テスト開始が遅延|先方PM経由でエスカレーション|担当:人見|期限7/9|対応中|最終更新7/4

太字にした2列が肝です。「放置した場合の影響」がないと、すべての課題が同じ重さに見えて優先順位がつけられません。「最終更新日」は課題の中身より先に見る列で、更新が止まっている行は「解決済み」か「誰も見る余裕がない」かのどちらか。どちらなのかを確かめに行くのがPMOの仕事です。

4. リスク管理表

  • ID/リスク内容/発生可能性(高・中・低)/影響度(高・中・低)/対応方針(回避・軽減・転嫁・受容)/顕在化の予兆/担当

記入例:ID-R05|繁忙期と受入テストが重なり業務部門のテスト要員を確保できない|可能性:中|影響:高|軽減(テスト項目の優先度づけと一部前倒し)|予兆:テスト計画レビューへの業務部門の欠席|担当:PMO

一般的な様式との違いは「顕在化の予兆」列です。リスク管理表の典型的な死に方は、期初に書いたきり誰も開かなくなること。予兆を言語化しておけば、「この予兆、先週出ていないか」と週次で見る運用に載せられます。そしてリスクの洗い出しは、1人でやらないでください。

そもそも自分の経験にないこととかスキルにないことっていうのは、思いつきづらい。これは自分でやろうとするんじゃなくて、いろんな人を巻き込んでやるのがリスクマネジメントの方法としてはいいかなと自分は思ってます

なお、この表を実際に回すための、リスクの洗い出しから評価・対応までの運用方法は別記事で詳しく解説しているので、ここでは表の作りに絞ります。

5. 体制図+ワークロード表

体制図は「プロジェクト開始時に1枚作って終わり」が典型的な失敗です。工程によって必要なロールも人数も変わるので、僕は月ごとに作り、誰が誰にエスカレーションするのかの線まで入れることを勧めています。

セットで作ってほしいのがワークロード表です。行にメンバー、列に月を並べ、セルに各月のアサイン工数(人月)を書くだけの単純な表ですが、効果は絶大で、工程の谷間でアサインが切れる人、リーダー級が足りない月、外部調達が必要になる時期がひと目で見えます。たとえば開発とシステムテストの間に2ヶ月の谷があるなら、2人月を2ヶ月で貼って一度抜けてもらうのではなく、0.5人月×4ヶ月で貼ればテスト開始まで人を切らさず確保できる。こういう工夫は、表を作って眺めて初めて思いつけるものです。

逆にこれを作らないと、アサインについて「こういう人が足りない」とか「こういう貼り方をしちゃだめだ」とか、気づけない・整理できないことがたくさん絶対に出てくるので、絶対にあったほうがいいです

テンプレートを形骸化させない運用のコツ4つ

配ったテンプレートが生き続けるかどうかは、書式ではなく運用で決まります。僕が守っているルールは4つです。

  1. 埋めるのに15分以上かかる書式にしない。 項目を足すほど安心するのは管理する側だけで、書く側の負担は確実に鮮度を殺します。迷ったら列を減らす。
  2. すべての表に「最終更新日」を入れ、内容より先に鮮度を見る。 中身の巧拙を議論する前に、更新が止まった行へ声をかけるほうが早い。
  3. 書かせて終わりにしない。 報告書は会議の前に読まれ、会議の時間は判断に使う。集めた報告を定例で読み上げた瞬間、書く意味は消えます。進捗報告を判断の場につなげる具体的な進め方は、進捗会議を報告会で終わらせない運営の実践手順の記事にまとめています。
  4. 月に1度、使われていない列を消す。 誰も書かない列は監査の証跡ではなくノイズです。テンプレートにも棚卸しが要ります。

セルフチェックとして、「先月から一度も判断の材料に使われていない表はどれか」と問うてみてください。1つも思い当たらなければ、その現場のテンプレートは生きています。

自社向けカスタマイズの注意点

テンプレートは配布時点が完成形ではありません。ただし、削る場所を間違えると道具ごと壊れます。

消してはいけない列は4つ。「判断・支援してほしいこと」「放置した場合の影響」「期限」「最終更新日」です。これらは判断の材料そのものなので、どれだけ簡素化しても残してください。逆に、社内の管理コードや稟議番号のような自社固有の列は足して構いませんが、15分ルールの範囲内で。

規模に応じて厚みを変えること。 僕は「3億円以下のプロジェクトなら、計画を立て切れば大コケしない」と考えていますが、これは小さな案件ほどガチガチに管理しろという意味ではありません。たとえばスコープの変更管理も、小規模案件なら「変更は必ず事前に相談」という合意1つで足りることが多い。5人のプロジェクトに20列の課題管理表は要らないんです。書式の厚みは、関係者の人数と金額に比例させてください。

発注側と受注側で同じ表を見ること。 プロジェクトの失敗原因は発注側にも受注側にもあります。だから管理資料を発注側用・ベンダー用に分けるほど、認識はズレていく。課題管理表とリスク管理表は1つのファイルを両者で共有し、報告書だけを視点別に分けるのが僕の推奨です。

ツールへの載せ替えは列構成が固まってから。 Excelで列構成と運用が回るようになってから載せ替えるほうが手戻りしません。移行を検討する段階になったら、PMO向け管理ツールのカテゴリ別選定基準の記事を参考にしてください。

テンプレートの土台にある「プロジェクト全体計画」

ここまでの5点はバラバラの書式に見えて、実はプロジェクト全体計画書の部品です。僕は全体計画を、スコープ・スケジュール・品質・リスク・リソース・ステークホルダー・コミュニケーション・コスト・調達の9領域で書き切るようにしていて、進捗報告書と週報はスケジュールの、課題管理表とリスク管理表はリスクの、体制図とワークロード表はリソースの計画を、それぞれ週次の運用に落としたものです。

計画を書かずにテンプレートだけ配ると、「報告は集まるのに基準がない」という状態になります。遅れているかどうかは、何と比べるかが決まって初めて言えるからです。開発プロジェクトの7割は上流で決まる、と僕が言い続けているのもこのためで、書式の整備と計画の整備は必ずセットで進めてください。

これ、書かなくてもプロジェクトは走り出そうと思えばなんとなく走り始めちゃうから、なぁなぁで書いていないという人が多いんですよね。でも非常にこれが良くない。絶対だめです。プログラマーがプログラムしないみたいなものです

全体計画の9領域それぞれで何をどこまで決めておくべきかは、1本の動画にまとめて解説しています。テンプレートの背景にある考え方まで押さえたい方は、以下もあわせてご覧ください。

「【PJ全体計画②】プロジェクト全体計画の書き方完全攻略」「【PJ全体計画②】プロジェクト全体計画の書き方完全攻略」

まとめ:テンプレートは「配る」より「回す」

  • PMO管理資料の目的は記録ではなく判断。「判断・支援してほしいこと」「放置した場合の影響」など、判断に直結する列を核に据える
  • 進捗は率ではなく、成果物の完了本数・残工数・完了予定日の前週比較で書く。「順調です」を数字に置き換える構造をテンプレート側に持たせる
  • 形骸化対策は、15分で書ける分量・最終更新日による鮮度管理・使われない列の月次棚卸しの3点
  • 書式の簡素化はしてよいが、判断の材料になる4列は消さない。厚みは案件の規模に比例させる
  • テンプレートは全体計画の部品。比べる物差しになる計画がないまま書式だけ配っても、報告は判断につながらない

テンプレートを探してこのページに辿り着いた方の本当の課題は、書式がないことではなく、プロジェクトの今の状態を自信を持って言い切れないことだと思います。書式はそのための足場にすぎません。まずは表を1つ、次の定例から回してみてください。埋まらない欄がどこにあるかが、あなたのプロジェクトの弱点を正確に教えてくれます。


Excelテンプレート一式の無料ダウンロードとPMO運用のご相談

本記事で紹介した5点のテンプレート(進捗報告書・週報・課題管理表・リスク管理表・体制図+ワークロード表)は、記入例入りのExcelファイルとして無料でお渡ししています。PMOテンプレート集ダウンロードページからフォームをご送信いただくと、その場でダウンロードできます。

あわせて、「テンプレートを配ったのに誰も更新してくれない」「報告は集まるが、判断につながっている実感がない」「そもそも自社の規模でどこまで管理すべきか自信がない」——そんなお悩みがあれば、無料相談からご相談いただけます。僕自身、受注側のPMと発注側の支援、両方の立場で管理資料を回してきたので、貴社の体制に合わせた運用の立ち上げ方から一緒に考えられます。支援メニューの詳細はPMO支援サービスをご覧ください。

もちろん、話を聞いた結果「外部支援より社内での内製が適している」と判断すれば、その旨も正直にお伝えします。まずは、いま一番困っている表を1つ教えてください。

人見悠大

この記事の執筆者

人見悠大

代表取締役

金融系SIerで社内最年少PMとしてQCD未達ゼロを達成後、株式会社クリエイティブテックスタジオを創業。PMO支援・DX推進を手がける。PMP・認定スクラムマスター。

プロフィールを見る →