プロジェクト管理計画書の書き方｜盛り込む項目と記載例

プロジェクト管理計画書とは、プロジェクトの目的・範囲・体制・スケジュール・リスクなどを1つの文書にまとめ、関係者と合意するための文書です。項目を6つ程度に絞り、範囲とリスクを具体例つきで書くと、読まれて更新され続ける計画書になります。

この記事では、プロジェクト管理計画書に盛り込む項目、範囲とリスクの記載例、関係者から合意を取る進め方、運用中の更新のしかた、計画書が形骸化する原因を整理します。初めてプロジェクトの計画をまとめるPM・PMOの方が、そのまま自分の案件に当てはめられるよう、架空のプロジェクトを題材にした記載例を本文の中に示します（2026年10月時点の情報です）。

プロジェクト管理計画書とは

プロジェクト管理計画書は、何のために、何を、いつまでに、誰がやるのかを関係者全員が同じ前提で理解するための文書です。作業指示書ではなく、判断に迷ったときに立ち戻る基準として使います。

呼び名は組織によって「プロジェクト計画書」「プロジェクト憲章」「計画書」などとばらつきがあります。名称よりも、目的・範囲・体制・スケジュール・リスクといった中身がそろっているかを見るほうが実務では重要です。

目的

計画書の目的は、プロジェクトの目指す姿と進め方について、関係者の認識をそろえて合意することです。後から「そんな話は聞いていない」という食い違いが起きるのを防ぐ役割があります。

公的な標準の例として、デジタル庁が公開している政府情報システム向けの標準ガイドラインでは、プロジェクトを始める前にプロジェクト計画書とプロジェクト管理要領を作成することとされています。計画書には政策目的、対象業務の範囲、目標とモニタリング、前提条件・制約条件とリスク、実施計画、予算、体制などを少なくとも記載する、という整理です（デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第2章）。政府情報システムの決まりですが、民間のプロジェクトでも「何を書いておけば後で揉めないか」を考える際の目安になります。

あわせて、このガイドラインでは、計画書とは別に、進め方のルールを定める文書として管理要領が置かれています。管理要領にはステークホルダー管理、コミュニケーション管理、工程管理、リスク管理、課題管理、変更管理、品質管理などが並びます。計画書は「何をいつまでにやるか」、管理要領は「どう管理するか」を書く、と役割を分けて考えると整理しやすくなります。小さなプロジェクトでは、この2つを1冊にまとめても問題ありません。

誰が読むか

計画書の読み手は、発注側の責任者、プロジェクトのメンバー、そして途中から参加する人の3者です。それぞれが知りたいことが違うため、冒頭に要点をまとめる構成が向いています。

• 発注側の責任者：目的、範囲、スケジュール、費用の大枠。承認の判断材料として読みます
• プロジェクトのメンバー：自分の役割、担当する成果物、期限、連絡の経路。日々の判断の基準として読みます
• 途中参加の人：これまでの経緯、決まっていること、決まっていないこと。引き継ぎ資料として読みます

編集部の実務観点では、計画書がもっとも読まれるのは、プロジェクトの開始時ではなく、途中参加の人が来たときと、トラブルが起きたときです。途中参加の人が計画書を読んで全体像をつかめるかどうかを、書き上げた後の確認基準にすると、読みやすさの水準がそろいます。

盛り込む項目

盛り込む項目は、目的と背景、範囲と成果物、体制と役割、スケジュール、リスク、品質と変更のルールの6つが基本です。この6つがあれば、小規模から中規模のプロジェクトでは十分に機能します。

範囲と成果物

範囲と成果物の項目には、プロジェクトでやることとやらないこと、納品する成果物の一覧を書きます。もっとも揉めやすい項目なので、計画書の中でいちばん丁寧に書く価値があります。

やることだけを書いても、範囲は固まりません。「やらないこと」を明示して初めて、後から追加の依頼が来たときに計画書を根拠に話し合えます。成果物は、名称だけでなく、形式（文書、システム、データなど）と受け入れの基準を添えます。「業務フロー図」と書くだけでなく、「現行業務の主要5業務を対象とした業務フロー図（発注側の担当者が内容を確認済みであること）」のように、誰が何をもって完了とするかまで書くと、解釈の違いが起きにくくなります。

体制・スケジュール

体制には役割と承認者を、スケジュールにはマイルストーンと期限、依存関係を書きます。人の名前よりも「役割」を軸にして書くと、メンバーが入れ替わっても計画書が使えます。

体制では、責任者、実務の担当、承認者、窓口の4つの役割を最低限そろえます。とくに承認者は、「誰の承認があれば次に進めるか」を一人に特定しておくことが大切です。複数の部門にまたがる場合は、部門ごとの承認者を並べ、意見が割れたときに最終判断をする人も明記します。

スケジュールは、日々の作業まで細かく書く必要はありません。主要なマイルストーン（要件の確定、設計の完了、テストの開始、本番の切り替えなど）と期限を並べ、各マイルストーンの前提になる作業を添えます。作業の洗い出しと工数の見積もりは、WBSの作り方で作った成果物を土台にすると、計画書の中のスケジュールとの整合が取りやすくなります。日程の見せ方はガントチャートの作成のポイントも参考になります。発注側が行う作業（資料の提供、確認、承認）も必ず日程に入れておきます。発注側の作業が遅れて全体が遅れる、という事態は、計画書に載っていないことが原因で起きがちだからです。

リスクと品質

リスクの項目には、起こりうる問題と対応策、確認する担当を、品質の項目には完了の判断基準を書きます。「問題が起きたらどうするか」を事前に決めておくための項目です。

リスクは、すでに起きている問題（課題）とは区別して書きます。リスクは「まだ起きていないが、起きると影響が大きいこと」、課題は「すでに起きていて対処が必要なこと」です。計画書に載せるのは前者で、課題は進行中に別の一覧で管理します。

品質は、成果物ごとに「何ができていれば完了とするか」を決めます。たとえば、文書なら「発注側の担当者のレビューを経て、指摘事項がすべて対応済み」、システムなら「テスト項目の全件を実施し、重大な不具合が残っていない」といった形です。完了の基準が人によって違うと、納品の段階で「まだ終わっていない」という認識の差が表に出ます。

項目別の記載例

記載例は、範囲とリスクの2項目に絞って示します。この2つは書き方で出来栄えの差がもっとも大きく、後の揉めごとにも直結するからです。この記載例は、社内の経費精算システムを刷新するという架空のプロジェクトを題材にしています。

範囲の書き方

範囲は、「対象」「対象外」「成果物」「前提条件」の4つの見出しで書くと、読み手が迷いません。とくに対象外と前提条件は、トラブルを予防する働きがあります。

この例のポイントは、対象外に「法人カードの利用明細の取り込み」のような、関係者が期待しがちな機能を明示していることです。範囲の議論でもっとも多いのは、「当然やってもらえると思っていた」という認識のずれです。期待されそうなものを先回りして対象外に書き、必要なら別のプロジェクトとして扱うことを関係者と合意しておきます。

前提条件には、範囲が成り立つための条件を書きます。「製品はパッケージを採用する」という前提が崩れて個別開発になれば、工数も期間も変わります。前提が変わったときは、範囲、スケジュール、費用を見直す合図になります。

リスクの書き方

リスクは、「起きること」「影響」「兆候」「対応策」「担当」「確認の時期」の6つを1行にまとめた表で書きます。対応策と担当、確認の時期まで書くことで、書きっぱなしを防げます。

リスクの表を書くときは、兆候の欄を空欄にしないことが大切です。兆候がわかれば、リスクが現実になる前に動けます。「遅れる」という結果だけを書いても、いつ動けばよいのかがわかりません。兆候を「3営業日以上返信がない」のように、観察できる状態で書いておくと、定例会での確認が機械的にできます。

書くリスクの数は、多ければよいわけではありません。影響が大きいものを5〜10件程度に絞り、小さなリスクは別の一覧で管理するほうが、計画書が読まれ続けます。

合意の取り方

合意の取り方は、個別レビューで下地を作り、合意の場で確認し、承認を記録に残す、という順序が基本です。計画書は書き上げただけでは効力を持たず、関係者が合意して初めて拠り所になります。

レビューの進め方

レビューは、全員を集めた会議の前に、主要な関係者を個別に訪ねて内容を確認する形が効果的です。会議の場で初めて計画書を見せると、その場で異論が出て決まらなくなりがちです。

1. ドラフトを作る：範囲、体制、スケジュール、リスクの4項目を先に仕上げ、残りは骨子にとどめます。完成度は7割程度で構いません
2. 影響の大きい人から個別に見てもらう：承認者、発注側の実務責任者、他部門の窓口の順に、30分程度で要点を説明します。ここで出た意見を反映して、会議では確認に徹する状態をつくります
3. 論点を一覧にする：意見が割れた箇所を「論点」として整理し、誰がいつまでに決めるかを書き添えます
4. 合意の場で最終確認する：個別に確認済みの内容を全員で共有し、残った論点だけを議論します

この進め方では、各ステップの入力と出力がはっきりします。ドラフトを入力にして個別の意見が出力され、意見を反映した版を入力にして合意の場で承認が出力されます。レビューのたびに、版の番号と変更した箇所を残しておくと、後から経緯を追えます。

承認の記録

承認の記録は、誰が、いつ、どの版の計画書を承認したかを残すことです。口頭の了解だけにせず、メールや議事録、承認欄のある文書の形で証拠を残します。

記録には、承認者の名前、承認の日付、承認した版の番号、条件つきの承認だった場合はその条件を書きます。「範囲は承認するが、スケジュールは再確認する」といった留保があれば、それも明記しておきます。留保を曖昧にしたままだと、後で「承認したはずだ」「条件があると伝えた」という食い違いが起きます。

フリーランスのコンサルタントが発注側と契約を結んで参画する場合、計画書の範囲と契約書の業務範囲は一致させておく必要があります。契約上の扱いに迷う場合は、弁護士などの専門家に相談してください。契約形態の違いは業務委託・準委任・請負の違いで整理しています。

運用の中での更新

計画書は、作って終わりではなく、変更が起きるたびに更新して使い続ける文書です。更新の手順と頻度をあらかじめ決めておけば、計画書は現実と食い違わずに済みます。

前提として、プロジェクトの開始時にすべてを決め切ることはできません。デジタル庁の標準ガイドラインにも、計画書は開始時にすべての内容を具体化・詳細化することが難しいため、進捗に合わせて段階的に改定する、という趣旨の記載があります。計画書を変えること自体は失敗ではなく、むしろ現実に合わせて直し続けることが想定されています。

変更の扱い

変更は、依頼を受けたらすぐ引き受けず、影響を確認し、承認を得てから計画書に反映する手順で扱います。この手順を決めておくと、範囲の膨張を防げます。

具体的には、変更の依頼を受けたら、次の4点を確認します。

1. 何が変わるのか：範囲、成果物、期限、体制のどれに影響するかを特定します
2. 影響の大きさ：追加の工数、費用、期間の見込みを出します
3. 誰が承認するのか：計画書に書いた承認者に、影響を添えて判断を仰ぎます
4. どう反映するのか：承認された内容を計画書の該当箇所に書き込み、版の番号を上げて関係者に共有します

小さな変更まですべてこの手順にかけると回らなくなるため、「期限や費用に影響しない軽微な変更は担当者の判断で進める」といった線引きも計画書に書いておきます。線引きの基準が曖昧だと、軽微と思って進めた変更が後で大きな問題になります。

進捗報告との整合

進捗報告は、計画書に書いたマイルストーンと同じ単位で行います。報告と計画書の物差しがそろっていれば、遅れや変更を計画書の更新にそのままつなげられます。

たとえば、計画書のマイルストーンが「要件の確定」「設計の完了」「テストの開始」なら、週次の報告でもこの単位ごとに「予定どおり」「遅れの兆候あり」「遅れている」を示します。報告の中で遅れが見えたら、リスクの表にある兆候と照らし合わせ、対応策を実行するか、計画書の期限を見直すかを判断します。

報告で使う言葉と、計画書の言葉が違うと、同じ話をしているのに食い違いが生じます。成果物の名称やマイルストーンの呼び名は、計画書の表記に統一しておくと、報告を読むだけで計画書のどの部分の話かがわかります。

計画書が形骸化する原因

計画書が形骸化する主な原因は、詳細にしすぎて誰も読まなくなることと、現実が変わっても更新されないことの2つです。どちらも、最初の設計と運用のルールで防げます。

詳細すぎる

計画書を詳細にしすぎると、更新の負担が増えて誰も直さなくなり、読まれなくなります。計画書に書くのは判断に必要な情報までにとどめ、日々の作業の詳細は別の管理表に任せます。

目安として、計画書には「合意しておかないと揉めること」だけを書きます。日ごとの作業予定、個人の細かなタスク、議事の詳細などは、計画書ではなくタスク管理や議事録の領域です。計画書の分量が増えてきたと感じたら、「これは合意が必要な内容か、それとも作業の記録か」と自問して、後者は別の文書に移します。プロジェクト管理全体の考え方はプロジェクト管理の基本にまとめています。

更新されない

計画書が更新されない原因は、更新の担当と頻度が決まっていないことです。誰が、どのタイミングで見直すのかを計画書の中に書き、定例会の議題に組み込めば、更新は習慣になります。

実務では、更新の担当にPMOを置き、毎週の定例会の最後に「計画書に反映すべき変更はあるか」を確認する運用が回しやすい形です。反映した内容は版の番号と変更履歴で見える状態にします。PMOの役割はPMOとは何かで整理しています。

計画書を整えて運用する経験は、フリーランスのPM・PMOとして案件に参画する際の実務の力としても評価されます。単価を決めるのは資格の有無よりも実務経験で、プロジェクトの規模、担当したフェーズ、体制の大きさが判断の軸になります。どんな規模のプロジェクトで、計画づくりのどこまでを担ったかを説明できるようにしておくと、スキルシートにも書きやすくなります。

出典・参考情報（最終更新日：2026年10月8日）

1. デジタル庁「デジタル・ガバメント推進標準ガイドライン」第3編第2章 プロジェクトの管理（2026-10-08参照）

本記事の記載例は、説明のために作成した架空のプロジェクトを題材にしたものです。実際の契約や社内規程にもとづく判断は、弁護士などの専門家や社内の担当部署にご相談ください。