目次
プロジェクトマネジメント計画書とは何か（定義と役割）
プロジェクトマネジメント計画書の意味とは？
プロジェクトマネジメント計画書とは、プロジェクトを円滑に進めるために必要な内容をまとめた公式な文書のことです。例えて言えば、新築の家を建てる際の設計図のようなものです。この計画書には、プロジェクトの目的や範囲、誰がどんな役割を担うのか、どんな成果物を目指すのか、予算やスケジュール、関係者同士の連絡体制、品質をどう保つか、予想されるリスクとその対応方法など、実務を進める上で欠かせない基本情報が幅広く記されています。
公式な定義（PMBOKの視点）
プロジェクトマネジメントの世界で広く使われている「PMBOK（Project Management Body of Knowledge）」というガイドでは、計画書を「プロジェクトの実行と管理の両方を行うための、正式に承認された文書」と位置付けています。これにより、思いつきや口約束で進めるのではなく、誰もが同じ方向性を理解しながら行動できる枠組みが整います。
計画書の役割と必要性
プロジェクトマネジメント計画書が果たす役割は非常に大きいです。具体的には、関係者の認識を揃え、意思疎通のずれやトラブルを未然に防ぐことができます。例えば、進め方や納品時期、作るべきもののイメージがバラバラだと、後から「話が違う」という事態になりがちです。しかし、計画書があれば、関係者全員が同じ“設計図”をもとに進行できるため、プロジェクトのゴールまで迷わず進みやすくなります。また、計画書は進捗の管理や、途中で予期しない変更があった際にも基本となる道しるべとして機能します。
適用範囲と規模による違い
計画書のボリュームや細かさは、会社の規模やプロジェクトの大小によって異なります。大きなプロジェクトであればあるほど、記載する内容や関係者も増え、計画書の厳密さや正確さが必要です。逆に、小規模な案件やチームでも、最低限のポイントだけを押さえたシンプルな計画書を作成することが大切です。
次の章に記載するタイトル：計画書に含めるべき必須項目（PMBOKに沿った全体像）
計画書に含めるべき必須項目（PMBOKに沿った全体像）
プロジェクト計画書に盛り込むべき主な項目
プロジェクトマネジメント計画書を作成する際は、抜け漏れを防ぐために情報の全体像を把握しましょう。世界的な標準であるPMBOK（ピンボック）では、プロジェクト計画書に次のような項目を含めることを推奨しています。以下、各項目の内容と具体例をご説明します。
1. 目的・ゴールと成功基準
まず、プロジェクトの目的とゴールを明確に書きます。たとえば「新しいWebサイトを開発し、3ヶ月以内に公開する」「社内の業務効率化を達成する」などです。また、プロジェクトが成功したといえる基準（KPIなど）も設定します。例えば「公開1ヵ月後のユーザーアクセス数○○件を達成」などが挙げられます。
2. スコープ（範囲）
スコープでは、「やること（対象範囲）」と「やらないこと（除外範囲）」をはっきりと区別します。たとえば「社外向けサイトのみ作る。社内システムは対象外」などです。加えて、成果物（例：新システムのリリース）、納期、考慮すべき制約条件や前提条件も記載します。
3. 体制・役割・責任
プロジェクトチームの体制や、各メンバーの役割分担も計画書に必要です。具体例として、「プロジェクトマネージャー：全体進行管理」「開発担当：システム構築」「テスト担当：検証作業」のように書きます。責任範囲を明確にするためにRACI図や簡単な組織図を添付すると分かりやすくなります。
4. スケジュール
作業内容とタイミングをまとめたスケジュール（例：ガントチャート）は必須です。作業一覧（WBS：作業分解構成図）や、重要な締め切り（マイルストーン）、遅れると全体に影響する重要な工程（クリティカルパス）にも目を配りましょう。
5. コスト・予算
プロジェクトにかかる費用を見積もり、その根拠を記載します。「人件費、開発ツール費、外注費」など、すべての費用を洗い出し、コストベースライン（目安となる予算線）も明示します。
6. 品質計画
完成品に求められる品質水準や、品質を確かめる検証・妥当性確認の方法も計画します。具体例：「Webサイトのレスポンスタイムは2秒以内」「開発後ユーザーテストを2回実施して評価」などです。
7. リスク管理
プロジェクトで予想されるリスクを書き出し（例：開発遅延、予算超過）、その重要度や対応方法を計画しましょう。リスク登録簿に整理して一覧化すると便利です。
8. コミュニケーション計画
会議や報告の頻度・連絡方法（メール、チャット、資料フォーマット）を定めます。「週次進捗ミーティング」や「成果物報告書の提出」など、関係者間で情報をどう共有・伝達するか決めておきましょう。
9. 変更管理・課題管理・調達/外部委託方針
状況が変わった場合の手続き（変更管理）や発生した問題の記録・対応ルール（課題管理）、必要に応じて外部業者への依頼（調達方針）も盛り込みます。
10. ツール/ガバナンス（レビュー/承認・エスカレーション）
どのようなツールや仕組みでプロジェクトを管理し、承認・レビュー・トラブル時のエスカレーションを行うかを明記しておきます。
これらの項目をバランスよく盛り込むことで、全体を見通した実践的な計画書を作成できます。
次の章では、「作成手順（5ステップで進める）」について詳しくご紹介します。
作成手順（5ステップで進める）
ステップ1: 目的・要件の明確化
プロジェクトマネジメント計画書を作る最初のステップは、「何のために計画書をつくるのか」「どこまでが今回の目標か」をはっきりさせることです。たとえば、新しいホームページを作る場合、「現状よりも使いやすく、アクセス数を増やす」といった具体的な目的や要件を書き出します。これにより、関係者全員の認識をそろえる土台になります。
ステップ2: スコープ定義とWBS分解
次は、プロジェクトの“スコープ”、つまりやること・やらないことを整理します。そしてWBS（Work Breakdown Structure）という手法を使い、プロジェクト全体を小さい作業に細分化します。例えば「デザイン作成」「ページ作成」「テスト」など具体的なタスクに分けて抜け漏れを防ぎます。
ステップ3: リソース割当と体制設計
細分化したタスクごとに「誰が担当するのか」「どんなスキルが必要か」を考えます。プロジェクトチームの組織図や各メンバーの役割表を作り、作業分担が一目で分かるようにすると、混乱が少なくなります。たとえば「Aさんがデザイン」「Bさんがテスト」など、役割を具体的に割り当てます。
ステップ4: スケジュールとコストの策定
計画したタスクを、いつまでに、どのくらいの予算で進めるかを決めます。目安になるマイルストーン（例：「デザイン完了日」など）を設定し、作業の進捗を管理しやすくします。また、全体の費用見積もりを行い、途中で予算が足りなくならないように気を付けます。
ステップ5: リスク想定と対応計画
最後は、想定されるトラブルや課題（リスク）をリストアップし、それぞれに対する対応策を考えます。たとえば「メンバーの急な休みが発生した場合はほかのスタッフがカバーする」など、具体的な対応方法を決めておくと安心です。リスク管理の担当者も明確にしましょう。
次の章に記載するタイトル: システム開発プロジェクトに特有の観点
システム開発プロジェクトに特有の観点
システム開発ならではの注意点とは？
システム開発プロジェクトのプロジェクトマネジメント計画書を作成する際には、他の分野と比べて特有の観点がいくつか存在します。特に「スコープの厳密化」が重要です。システム開発では、何を作るのか（機能）、どのくらいの性能が必要か、安全性や可用性がどうか、といった要求を最初から明確にする必要があります。たとえば、Webシステムで「同時ログイン数500名以上」「毎日24時間稼働」「個人情報は暗号化」などの非機能要件をきちんと具体的に盛り込みます。また、外部システムやデバイスとの「インターフェース仕様」や「納品時の受け入れ条件」も明記が欠かせません。
人的リソースの見積りポイント
システム開発では、プロジェクトマネージャー（PM）、リーダー（PL）、設計・開発担当（SE）、品質管理（QA）、システム運用（Ops）など、役割ごとに必要なスキルや人数が異なります。開発工程（設計・プログラミング・テストなど）ごとに、誰がどれだけ必要かを、具体的に見積もりましょう。たとえば、「要件定義フェーズはPM1名とSE2名」「テストではQAが3名」のように分けて計算します。
要件定義と変更管理の強化がカギ
システム開発プロジェクトでは、いったん決めた内容にあいまいさがあると、後からの「手戻り」（やり直し）が多発しがちです。そのため、最初の要件定義を丁寧に、関係者全員で確認しながら進めます。また、途中で「やっぱりここを変えたい」という要望が出た場合のために、変更管理のルールをあらかじめ計画書に盛り込んでおきましょう。たとえば、「変更申請は書面で提出」「影響範囲を検証後に承認」などのプロセスを定めておくことで、無駄な手戻りや混乱を防げます。
次の章に記載するタイトル：実務で使える書き方のコツと初心者向けポイント
実務で使える書き方のコツと初心者向けポイント
プロジェクトマネジメント計画書を実務で活かすためには、誰が読んでも理解できる内容を心掛けることが大切です。特に初心者の方には、以下のポイントを意識して作成するのがおすすめです。
1. 「要件定義」と「実行計画」に分けて構成する
計画書は大まかに「何をやるか（要件定義）」と「どうやってやるか（実行計画）」の2つに分けると分かりやすくなります。まずは目的やゴール、達成基準を明確にし、続いて具体的な手順や割り当て、スケジュールを整理しましょう。
2. 具体例・箇条書きを活用する
抽象的な表現は避け、実際の作業や成果物を明記しましょう。たとえば、
- "ユーザー管理の機能を実装する"
- "4月中にテスト環境の構築を完了する"
など、誰が見てもイメージしやすい記載がポイントです。
また、箇条書きを使うと情報が整理され、読みやすくなります。
3. 図や表を使って可視化する
WBS（作業分解図）、RACI（役割分担表）、ガントチャート（工程表）などの図や表を入れると、ステークホルダー同士の認識ズレを防ぎやすくなります。シンプルな手書き図やパワーポイントでも構いませんが、フリーツールも活用できます。
4. テンプレートとサンプルを活用する
いちからすべて作る必要はありません。インターネットには無料のテンプレートやサンプルも豊富にあります。これらをカスタマイズすれば、過不足なく漏れ防止にもつながります。
5. ワークマネジメントツールで一貫管理
進捗状況やToDo管理、コミュニケーションも一つのツールでまとめて行うと、計画から実行・振り返りまで一貫した管理ができます。初心者には操作が簡単なツールから始めてみるとよいでしょう。
次の章に記載するタイトル：失敗を防ぐ注意点（よくある落とし穴）
失敗を防ぐ注意点（よくある落とし穴）
プロジェクトマネジメント計画書を作成する際には、よくある落とし穴に注意することが重要です。ここでは、失敗を防ぐための主要なポイントを具体例とともにご紹介します。
スコープの曖昧さ・「やらないこと」の未定義
プロジェクトのスコープ（やること）の範囲がはっきりせず、「やらないこと」が決められていないと、後から作業が増えてしまう危険があります。たとえば、最初は「顧客管理システム」のみ開発予定だったのに、途中で「売上管理も対応してください」と追加される、といった事態が起こりやすいです。「やること・やらないこと」をリストにして明確に線を引きましょう。
体制や責任の不明確さ
誰がどの責任を持つのかがあいまいだと、迷いが生じたり決定が遅れたりします。たとえば、「障害が起きたとき、誰が一次対応するのか」が不明だとすぐに動けません。こうした場合、RACIチャート（責任の分担表）で「誰が何をするか」「誰に相談するか」を文書化すると安心です。
リスク管理の不足
予測できるリスクを最初に書き出さないと、想定外のトラブルが起きたとき後手に回ることになります。リスク一覧表を用意し「どんなリスクがありそうか」「誰が対応するか」を割り当てましょう。また、定期的にリスクを見直す仕組みを計画書に盛り込むと、変化にも柔軟に対応できます。
スケジュール・コストの根拠不明
スケジュールやコストを「なんとなく」で決めてしまうと、現実と合わないことが多いです。たとえば「2か月でできる」と見積もったが、根拠がなく結局長引く、といったケースです。見積もりには「どんな方法を使ったか」「どの前提で計算したか」を具体的に記載し、説明できるようにしましょう。
コミュニケーションのルール不統一
報告や相談の頻度・方法が決まっていないと、「話が伝わっていなかった」「別のルートから同じ内容を聞いた」など、混乱が発生します。たとえば毎週の進捗会議、チャットやメールの使い分け、報告書のフォーマットなどを明記しておくことで、関係者全員が安心してやり取りできます。
次の章：計画書の運用と更新（リビングドキュメントとして）
計画書の運用と更新（リビングドキュメントとして）
プロジェクトマネジメント計画書を生きた文書として活用する
プロジェクトマネジメント計画書は、一度作成して終わりではなく、プロジェクトの進行に合わせて常に見直し・更新していくべき大切な文書です。たとえば、計画の内容に変更があった場合や、実施中に新たな課題が判明したときには、その都度必ず計画書に反映することが重要です。
更新手順と変更管理のポイント
実際に計画書を更新する際は、チームで決めた変更管理プロセスに沿って進めます。たとえば、「どの部分を」「なぜ」「いつ」「誰が」変更したのか履歴を残します。これにより後から見返したときに、どんな経緯で計画が修正されたのか明確になります。また、もとの計画（ベースライン）と現在の内容の差分も分かる状態にしておくと良いでしょう。
ステークホルダーとの連携と認識合わせ
計画書は、プロジェクト関係者全員が同じ方針や状況を共有するための共通の拠り所です。そのため、主要なステークホルダーと定期的に計画書を確認し、必要に応じてアップデート内容を説明します。新しくチームに加わったメンバーには、計画書自体がオンボーディング資料として活躍します。
ワークマネジメントシステムとレビューサイクル
近年では、進捗や課題、リスクの可視化のために、ワークマネジメントシステム（例: タスク管理ツールなど）を導入するケースが増えています。これらのシステムと計画書を連携させることで、誰でも最新の状況を手軽に確認できるようになります。プロジェクトの一定期間ごとに計画書をレビューし、必要に応じて更新するルールを設けておくことも有効です。
次の章に記載するタイトル：例示的アウトライン（章立てテンプレート）
例示的アウトライン（章立てテンプレート）
プロジェクトマネジメント計画書を作成する際には、明確で実践的なアウトライン（章立て）を持つことが重要です。ここでは、多くのプロジェクトで汎用的に使える章構成を例示し、それぞれの章にどのような内容を記載するか、わかりやすくご紹介します。
1. 概要
この章では、プロジェクトの目的や背景、スコープ（対象範囲）、そしてどのような基準で成功とみなすかを記載します。たとえば、「新しい顧客管理システムの導入」という目的に対し、「2024年12月までに全営業所へ展開し、既存業務を効率化する」などの具体的な目標設定を書くイメージです。
2. 体制とガバナンス
ここには、プロジェクトメンバーの役割分担や組織図、責任と権限（RACIなど）、何か問題が起きた際のエスカレーション（報告・相談）ルートを整理します。図や表を使うと分かりやすくなります。例として、リーダーや課題管理担当、ステークホルダーなどの一覧を加えると良いでしょう。
3. 計画ベースライン
「計画ベースライン」には、作業スケジュール、予算（コスト）、品質基準を示します。利用するガントチャートや、達成すべき納期、予算上限、品質に求める基準値（例えば「障害発生率は1%未満」など）もここに含めます。
4. 実行計画
どのような手順と方法でプロジェクトを進めるかを書きます。ウォーターフォールやアジャイルといった開発プロセス、レビューを実施するタイミング、システムの受け入れ基準など、実際の流れが分かるように整理しましょう。
5. リスク・課題・変更管理
リスク（想定される問題）、課題（既に発生している問題）、変更管理（要件などに変更が発生した際のフロー）について触れます。それぞれ登録簿や手順書を用意し、関係者がいつでも参照できる形にすると効果的です。
6. コミュニケーション計画
定例会議の日程や会議体の構成、進捗報告書のフォーマット、関係者への報告頻度などをまとめます。情報共有のルールがはっきりしていることで、認識違いや情報の遅れを防げます。
7. 調達/外部委託・契約
外部会社に一部業務を依頼する場合、どの範囲を委託するのか、どんな基準（サービスレベルアグリーメント：SLA）で評価するかを書きます。たとえば「システム保守は外部に委託し、24時間以内の一次対応を求める」などが具体例です。
8. 付録
最後に、ワークブレークダウンストラクチャ（WBS）、ガントチャート、見積りの根拠、用語集などの補足資料をまとめます。必要に応じ、参考資料や定義集もここに含めると、全体の理解が深まります。
次の章に記載するタイトル：具体的な作成例（書き出しサンプル）
具体的な作成例（書き出しサンプル）
本章では、プロジェクトマネジメント計画書の書き出し例を提示します。実際の現場でよく出会う「システム開発プロジェクト」をモデルケースに、必要な要素を簡潔にまとめます。初めて作成する方や、分かりやすく伝えたい方に参考となるよう配慮しています。
【書き出しサンプル】
1. 目的
本プロジェクトは新規〇〇機能を6ヶ月以内に本番リリースすることを目的とします。成功基準は、リリース後にNPS（顧客満足度）を10ポイント向上させ、直帰率を5ポイント減少させることとします。
2. スコープ（対象範囲と除外事項）
・開発対象：A機能、B機能、C機能
・対象外：D機能、E機能
・成果物：要件定義書、基本設計書、テスト仕様書、運用手順書
3. 体制
・プロジェクトマネージャー：1名
・プロジェクトリーダー：1名
・アプリケーションエンジニア：3名
・品質保証担当：2名
・運用担当：1名
（役割分担はRACIチャートを付録Aに記載）
4. スケジュール
マイルストーン例：
- M1：要件凍結
- M3：結合テスト完了
- M6：本番環境切替
クリティカルパス：X→Y→Z
5. コスト
- 人件費：○○円（人月単価×工数で三点見積の中央値を採用）
- ツール費：○○円
6. リスク
- 要件増加リスク（高）：変更管理ゲートを強化
- 外部API変更リスク（中）：フェイルセーフ設計を追加
7. コミュニケーション
- 週次：ステアリング会議で進捗共有
- 日次：スタンドアップミーティングでタスク確認
- 月次：関係者向けレポート発行
8. テンプレート・フォーマット
- 今回はテンプレートBを採用し、主要情報を分かりやすく整理しています。
このサンプルをもとに、自分のプロジェクトの事情に合わせて項目や表現を調整してください。
次の章では、テンプレート・ツール・AIの活用について説明します。
テンプレート・ツール・AIの活用
テンプレート・サンプルの効果的な活用
プロジェクトマネジメント計画書を作成する際、ゼロから考え始めると抜け漏れが発生しやすいものです。そこで、あらかじめ用意されたテンプレートや過去事例のサンプルを参考にすることで、全体の骨組みをしっかりと整えられます。インターネット上には初心者向けの無償テンプレートも多く提供されていますので、まずはそれらをダウンロードして、自分のプロジェクトに合わせて調整してみましょう。具体的には「計画書_テンプレート.xlsx」「プロジェクト管理_サンプル.docx」など形式も豊富です。
ワークマネジメントツールの活用
計画書を作成した後は、実際の業務の進行とともに内容もアップデートする必要があります。その際に便利なのが、AsanaやTrelloなどのワークマネジメントツールです。これらを使うと「計画策定→実行→進捗可視化→更新」の流れを一元管理でき、タスクの抜けや情報の更新漏れを減らせます。また、複数メンバーでの共同編集やコメント機能を活用すれば、コミュニケーションもスムーズです。ExcelやWord単体で管理するより効率が上がることが多いでしょう。
生成AIの活用ポイント
最近はChatGPTのような生成AIも計画書作成のサポートに利用できます。たとえば「何のための計画書か」「どんな人が読むか」といった目的やトーンを事前にAIに伝えることで、ドラフト作成がとても早くなります。たとえば「初心者向けにやさしい言葉で、IT開発プロジェクトの計画書のたたき台を作成してください」とAIに依頼すると、すぐにベースとなる文章が提示されます。この案をもとにチームで調整すれば、作業の時短と品質向上の両方が期待できます。
次の章に記載するタイトル：まとめの実務チェックリスト（抜粋）
まとめの実務チェックリスト（抜粋）
プロジェクトマネジメント計画書を実務で活用するために、必ず押さえるべきチェックポイントをまとめました。このリストを活用すると、計画書の抜け漏れ防止や関係者との認識合わせに役立ちます。ぜひ、ご自身のプロジェクトで確認してください。
1. 目的と成功基準が「測定できる」か
計画書には、プロジェクトの目的やゴールを数値や条件で明確に書きましょう。例えば「納品期日厳守」や「障害発生率1%未満」など、具体的なKPIや受入基準になっているか確認します。
2. スコープの包含・除外を記載しているか
どこまでがプロジェクトの範囲か、反対に「やらないこと」は何かを明記します。これによって後から手戻りやトラブルが起きにくくなります。
3. 役割・責任・承認フローが明確か
誰が何を担当し、最終承認者が誰かを整理しておきます。例えば「設計レビューはAさん、最終承認はB部長」のように、関係者に一目で分かる記載をしましょう。
4. スケジュール・コストの見積もり根拠を書いているか
なぜこの日程・金額なのか、その根拠や計算方法を書き添えると納得を得やすくなります。根拠が曖昧だとスケジュールや予算が崩れるもとになります。
5. リスク対応に「責任者」と「期限」を設定しているか
リスクごとに誰がどう対応し、いつまでに対策するかを明確に記載しましょう。例：「テスト不具合発生時はXさん、○日以内に再検証」。
6. コミュニケーションの頻度・形式が決まっているか
プロジェクト関係者が「会議は毎週月曜」「議事録はメールで全員に送付」など、やるべきことを分かりやすくまとめておきましょう。
7. 計画書の更新手順（変更管理）を明示
状況が変わったとき、誰がどうやって計画を見直すかも大切なポイントです。例：「変更案はPMが収集し、月1回レビュー会議で承認を得る」
[このチェックリストで、あなたの計画書も実践的なものになります。ぜひ活用してください。]