プロジェクト計画書とは？記載項目・書き方・失敗と対策を図解で解説

プロジェクト計画書とは、プロジェクトの目的・スコープ・体制・スケジュール・予算・リスクなどの計画情報を1つにまとめた文書。

プロジェクトを「いつ・誰が・何を・どうやって」進めるかを関係者で合意し、進行中の判断基準にするために作ります。

この記事では、プロジェクト計画書の意味と役割、プロジェクト憲章やマネジメント計画書との違い、記載すべき項目8つと書き方の手順、そしてよくある失敗までを図解で整理します。

プロジェクト計画書とは？意味と役割をわかりやすく解説

プロジェクト計画書とは、プロジェクトを完遂するために必要な計画情報を1本にまとめ、関係者の共通認識と判断基準をつくる文書です。

プロジェクトをスムーズに進めるカギとなるのが「プロジェクト計画書」。まずは定義と役割を確認しておきましょう。

これがあると関係者の足並みがそろい、進捗や予算の管理もラクになります。

逆にないと、「何をもって成功とするか」がバラバラのまま進み、あとで大きな手戻りに苦しむことに。

プロジェクト計画書の定義

プロジェクト計画書とは、目的・成果物・スケジュール・体制・予算・品質・リスクといった、プロジェクトを進めるうえで決めておくべき事柄を体系的にまとめた文書です。

国際的なプロジェクトマネジメントの知識体系であるPMI日本支部の『PMBOKガイド』では、これに近い文書を「プロジェクトマネジメント計画書（Project Management Plan）」と呼びます。

日本の実務では、これらを含む計画文書を広く「プロジェクト計画書」と呼ぶのが一般的です。

プロジェクトマネジメントの国際規格である『日本産業標準調査会（JISC）／JIS Q 21500』でも、計画は各プロセスの中心に位置づけられています。

つまりプロジェクト計画書は、思いつきで作る書式ではなく、標準化された考え方に沿って組み立てる文書だといえます。

プロジェクト計画書の3つの役割

プロジェクト計画書が果たす役割は、大きく次の3つに整理できます。

→ 表は横にスクロールできます

特に重要なのは①の合意形成です。

成功の定義が人によって違ったまま走り出したプロジェクトは、後半で必ずもめます。

計画書は、その「成功とは何か」を一つに固定し、全員が同じ方向に向かって進むための土台になります。

発注者は品質を、経営層はコストを、現場は納期を重視するといったように、立場が違えば優先するものも変わります。

計画書づくりの過程でこうした違いを表に出し、合意しておくことが、後戻りの少ない進行につながります。

計画書がないプロジェクトで起きやすいこと

計画書を作らずに走り出すと、次のような問題が起こりがちです。

• 範囲の膨張（スコープクリープ）：合意した範囲がないため、依頼が少しずつ増えて破綻する
• 判断の停滞：優先順位や承認者が決まっておらず、判断待ちで作業が止まる
• 手戻りの多発：品質基準が曖昧で、完成間際に「これでは受け取れない」となる
• 期限遅れ：全体日程と重要な節目が見えず、遅れに気づくのが遅れる

計画書がないと、判断基準が人任せになり、範囲の膨張・手戻り・期限遅れが起こりやすくなります。

計画書は「縛るための書類」ではなく、迷ったときに立ち返る“共通の合意”です。
地図がないまま人数が増えるほど、方向のずれは大きくなります。

プロジェクト憲章との違い

混同されやすいのがプロジェクト憲章（Project Charter）との違いです。

プロジェクト憲章は、プロジェクトを正式に立ち上げる前に、オーナーやスポンサーが作成する文書で、「なぜやるのか」「何を目指すのか」「誰をPMに任命し、どんな権限を与えるか」を示します。

この憲章によってPMに権限が与えられ、計画書を作る正当性が生まれます。

つまり順番としては、まず憲章があり、その承認を受けてからプロジェクト計画書を作る、という流れになります。

プロジェクト計画書の8つの記載項目

プロジェクト計画書は、次の8項目を押さえると実務で使える形になります。
プロジェクトやチームの規模に応じて、必要な項目を取捨選択しましょう。

記載項目に唯一の正解はありませんが、多くの計画書はPMBOKの考え方を土台にしています。

すべてを分厚く書く必要はなく、プロジェクトの規模やリスクの大きさに応じて、必要な項目に力を入れて記述するのが実務的です。

まずは全体像を一覧で押さえてから、ひとつずつ見ていきましょう。

→ 表は横にスクロールできます

目的・背景とゴール（QCD目標）（Purpose & Goal）とは？

そのプロジェクトを「なぜ・何のために行い、どうなれば成功か」を言葉と数値で定義する項目です。

背景・目的、そしてゴールを品質・コスト・納期のQCDで具体化します。

ゴールが数値で書かれていないと、後工程の判断基準がぶれてプロジェクトが迷走します。

たとえば「業務を効率化する」では曖昧で、「受注処理のリードタイムを平均5営業日から3営業日に短縮する（品質基準を満たしたまま／予算300万円以内／3月末まで）」まで落とすと、スコープや優先順位を判断する物差しになります。

関係者ごとに成功の定義がずれていることは非常に多いため、ここで合意を取ることが計画書の最大の価値です。

目的があいまいなまま作業を始めると、途中で「そもそも何のためだったか」が失われ、手段が目的化してしまいます。

逆に目的が数値で共有できていれば、想定外の事態が起きても「目的に照らして何を優先すべきか」を全員が自分で判断できるようになります。

誤解されやすい点：「目的」と「手段」を混同しがちです。
ツール導入やシステム開発は手段であって目的ではありません。
目的は“それによって得たい成果”をもとに書きます。

スコープ（作業範囲と成果物）（Scope）とは？

プロジェクトで「やること」と「やらないこと」、および最終的に出す成果物を線引きする項目です。

対象範囲（インスコープ）と対象外（アウトオブスコープ）を明記し、成果物（deliverables）を具体的に列挙します。

スコープが曖昧だと、依頼が少しずつ増えて計画が破綻する「スコープクリープ」が起きやすくなります。

スコープは「成果物ベース」で書くと精度が上がります。

『◯◯機能を作る』だけでなく『納品する成果物＝要件定義書・設計書・稼働するシステム・操作マニュアル』のように、完成の証拠となるものを列挙しましょう。

あわせて「今回はやらない」ことを明記するのがコツで、これがないと関係者の期待値が膨らみ、後から「これも入っていると思っていた」というトラブルになります。

特に、善意の追加依頼が積み重なってスコープが少しずつ広がるスコープクリープは、悪気がないぶん気づきにくく、気づいたときには納期も予算も破綻していることが少なくありません。

線引きを文書にしておくことで、追加依頼が出たときに「それは今回の範囲か、別途相談か」を落ち着いて判断できます。

誤解されやすい点：スコープ＝作業一覧、ではありません。
まず“成果物と範囲の線引き”を決め、その範囲を作業に分解したものがWBSです。

体制・役割分担（実施体制図）（Team & Roles）とは？

プロジェクトに関わる人と組織、そして誰が何に責任を持つかを図と表で示す項目です。

発注者・PM・各担当・協力会社などをツリー状の体制図で示し、意思決定者や承認ルートを明確にします。

役割の重複や空白（誰の担当でもないタスク）を防ぐため、RACIのような責任分担表を添えることもあります。

体制を書く目的は「困ったときに誰に聞けば決まるか」を先に決めておくこと。

特に承認者（意思決定権を持つ人）が曖昧なプロジェクトは、判断待ちで止まりがちです。

中小企業では一人が複数の役割を兼ねることも多いため、肩書きではなく“このプロジェクトにおける役割”で書き、外部パートナーも含めて連絡窓口を一本化しておくと、コミュニケーションの混線を防げます。

あわせて、担当が決まっていない“抜け落ちた作業”がないかを確認しておくと、着手の遅れを防げます。

誤解されやすい点：組織図（会社の常設の組織）と体制図（そのプロジェクト限定の編成）は別物です。
計画書に載せるのは後者です。

スケジュール・WBS・マイルストーン（Schedule / WBS）とは？

作業をWBSで洗い出し、時間軸に並べて全体日程と重要な節目（マイルストーン）を示す項目です。

スコープをWBS（作業分解構成図）で管理可能な粒度まで分解し、各作業の順序・所要期間・依存関係を踏まえてスケジュール化します。

ガントチャートで可視化し、納品やレビューなどの節目をマイルストーンとして置くのが一般的。

スケジュールは「WBS→日程化」の順で作るのが基本です。

いきなりカレンダーに線を引くのではなく、まず作業を漏れなく洗い出し（WBS）、1作業が数日〜2週間で終わる粒度に整えてから日程に落としましょう。

遅れると全体が遅れる作業の連なり（クリティカルパス）を意識し、その経路を重点管理すると納期を守りやすくなります。

誤解されやすい点：WBSとガントチャートは別物です。
WBSは作業の分解リスト、ガントはそれを時間軸に横棒で並べた図で、WBS→ガントの順で使います。

予算・コスト計画（Cost）とは？

プロジェクトに必要な費用を見積もり、何にいくら使うかを配分・管理する項目です。

人件費・外注費・ツール費・設備費などを積み上げて総予算を算出し、フェーズや費目ごとに配分します。

実行中は予算と実績を比較し、超過の兆候を早めに捉えて手を打つための基準になります。

コスト計画で見落とされがちなのが「人の時間もコスト」という視点。

社内メンバーの工数は現金支出がないため軽視されやすいですが、生産性の観点では最も大きなコストになり得ます。

予算は一点の数字ではなく、想定外に備えた予備費を含めて考えると、変更が発生しても計画が破綻しにくくなります。

中小企業ほど限られた原資を最大化する必要があり、費用対効果の説明が承認の鍵になります。

誤解されやすい点：コスト＝外部に払うお金だけではありません。
社内工数（人×時間）も重要なコストとして見積もります。

品質計画（Quality）とは？

成果物が「どの状態なら合格か」という品質基準と、それを確認する方法を定める項目です。

求める品質水準（受け入れ基準）と、それを保つためのレビュー・テスト・チェックの進め方を定義します。

品質基準が曖昧だと、完成間際に「これでは受け取れない」という手戻りが発生し、コストと納期を圧迫します。

品質は「作り終えてから確認する」より「途中の節目で確認する」ほうが安く済みます。

計画段階でレビューやテストのタイミングを工程に組み込んでおくと、手戻りが小さいうちに問題を発見できます。

受け入れ基準は発注者と合意しておくことが重要で、主観的な『いい感じ』ではなく、チェックリストや数値で客観的に判定できる形にしておくと、完了時の認識ずれを防げます。

求める品質水準は高ければよいわけではなく、目的に見合わない過剰な品質はコストと納期を圧迫するだけになるため、「このプロジェクトに必要十分な水準」を見極めて定義することが大切です。

誤解されやすい点：品質を上げる＝時間とコストを無限にかける、ではありません。
目的に必要な品質水準を定義し、過剰品質も避けるのが計画です。

リスク管理計画（Risk）とは？

計画どおり進まない要因を事前に洗い出し、備えと対応をあらかじめ決めておく項目です。

起こりうるリスクを列挙し、発生確率と影響度で評価して優先順位を付けます。

優先度の高いリスクには回避・軽減・受容などの対応方針と、発生した場合の対応を決めておきましょう。

リスク管理は「起きてから慌てない」ための保険です。

人員の離脱、仕様変更、外部要因の遅延など、経験的に起きやすいものは先に想定し、確率×影響で評価して重いものから対策を用意します。

すべてに備えるとコストがかかるため、影響の大きいリスクに絞って対応方針を決めるのがポイント。

過去の似たプロジェクトで実際に起きたトラブルを洗い出すと、精度の高いリスク一覧になります。

リスクは一度書いて終わりではなく、進行中に見直して更新し続けることで機能します。

誤解されやすい点：リスク＝すでに起きている問題（課題）ではありません。
リスクは“まだ起きていない不確実性”で、課題管理とは分けて扱います。

コミュニケーション・変更管理計画（Communication & Change）とは？

誰に・何を・いつ・どう伝えるかの連絡設計と、計画変更をどう承認・記録するかを定める項目です。

定例会議の頻度、報告フォーマット、使用する連絡ツール、報告先などを決めておきます。

あわせて、スコープや納期の変更を「誰がどう承認し記録するか」という変更管理の手順を定義し、なし崩しの変更を防ぎます。

プロジェクトが止まる原因の多くは、技術ではなく情報の分断。

「最新版がどれか分からない」「決めたはずのことが共有されていない」といった状態を防ぐため、報告の頻度・形式・置き場所を計画で先に決めておきましょう。

会議は増やせばよいものではなく、目的のない定例はかえって時間を奪います。

誰に何を伝えれば意思決定が進むかを起点に、最小限の連絡設計を組むのがコツ。

変更管理も重要で、依頼のたびに口頭で範囲が広がると計画は形骸化します。

変更は必ず記録し、影響（納期・コスト）を評価してから承認する流れにしておくと、計画書が“生きた基準”として機能し続けます。

誤解されやすい点：コミュニケーション計画＝会議を増やすこと、ではありません。
目的は“必要な情報が必要な人に届く状態”を最小の手間で作ることです。

プロジェクト計画書の書き方・作成手順

計画書は「目的→スコープ→WBS→スケジュール・体制→予算・品質・リスク→運用ルール」の順で組み立てると、抜け漏れなく作れます。

ここからは、プロジェクト計画書の具体的な作成方法を紹介します。

基本の作成ステップに沿って進めれば、ゼロからでもテンプレートからでも迷わず組み立てられます。

作成の基本ステップ

ゼロから作る場合も、テンプレートを使う場合も、考える順番は共通です。

上から順に固めていきましょう。

1. 目的とゴールを決める：背景・目的・成功の定義をQCD（品質・コスト・納期）で数値化する
2. スコープを線引きする：やること・やらないこと・成果物を明確にする
3. WBSで作業を分解する：成果物を管理できる粒度の作業まで洗い出す
4. スケジュールと体制を組む：作業を日程化し、担当・承認ルートを決める
5. 予算・品質・リスクを計画する：コスト、受け入れ基準、リスクへの備えを定める
6. 運用ルールを決める：会議体・報告・変更管理の進め方を明記する
7. 関係者でレビューし承認を得る：合意を取り、以降の基準として共有する

いきなり完璧を目指さず、まず全項目を“仮”で埋めて全体像を作り、関係者と対話しながら精度を上げるのが現実的です。

テンプレートを活用する

一から作るのが不安なら、公的機関が公開する資料が参考になります。

たとえば情報処理推進機構は、プロジェクトマネジメントに関するガイドや計画書のひな型を公開しており、記載項目の体系を学ぶ教材になります。

スケジュールを可視化するガントチャートは表計算ソフトでも作れ、作り方は『Microsoft サポート：Excelでガントチャートにデータを表示する』のページなどが参考になります。

テンプレートは便利ですが、項目を埋めること自体が目的化しないよう、自社のプロジェクトに不要な項目は削る勇気も必要です。

プロジェクト計画書でよくある失敗と対策

プロジェクト計画書でありがちな失敗の多くは、「作って終わり」にしてしまうこと。
形骸化を防ぐコツは、計画を日々のタスクに分解し、チームで見える化して更新し続けることです。

ここでは、プロジェクト計画書づくりでつまずきやすいポイントを整理し、そのうえで「作った計画をどう実行につなげるか」まで踏み込みます。

よくある失敗を避けつつ、日々の実行（タスク管理）でどうカバーしていくかを押さえていきましょう。

作成でよくある失敗と注意点

プロジェクト計画書でつまずくポイントは、経験的にいくつかに集約されます。

最も多いのが2つ目の「作って終わりになる」問題です。

計画書は一度作ったら完成ではなく、進行に合わせて更新し続けてこそ機能します。

計画（プロジェクト管理）と日々の実行（タスク管理）をつなぐ

立派な計画書を作っても、日々の実行に落ちなければ形骸化してしまいます。

ここで役立つのが、プロジェクト管理とタスク管理を分けて考える視点です。

プロジェクト管理は計画全体を俯瞰し、スコープや納期を統制する役割。

一方で、タスク管理は、その計画を「今日・今週、誰が何を終わらせるか」という具体的な行動にまで砕いて、日々まわしていく役割を担います。

プロジェクト管理が「計画全体を俯瞰する視点」だとすれば、タスク管理は「誰が・何を・いつまでにやるか」を日々まわす視点です。

この2つがつながって初めて、計画書に書いた内容が現場の動きになります。

つまり、計画書で決めた「誰が・何を・いつまでに」を、チーム全員が同じ最新の状態で見られるようにすることが、計画を実行に変える近道です。

よくある質問（FAQ）

プロジェクト計画書について、検索でよく調べられる疑問をまとめました。

プロジェクト計画書とプロジェクト憲章の違いは？

プロジェクト憲章は立ち上げ前にオーナーやスポンサーが作る「なぜやるか」を示す上位文書、プロジェクト計画書は承認後にプロジェクトマネージャーが作る「いつ・誰が・何を・どうやるか」の詳細な実行計画です。憲章が先、計画書が後という順番になります。

プロジェクト計画書とプロジェクトマネジメント計画書は同じ？

ほぼ同義で使われます。PMBOKの正式名称は「プロジェクトマネジメント計画書」で、スコープ・スケジュール・コストなど各領域の計画を束ねた文書を指します。実務ではこれを「プロジェクト計画書」と呼ぶことが一般的です。

プロジェクト計画書には最低限どの項目を書けばいい？

規模によりますが、最低限は「目的・ゴール」「スコープ（範囲と成果物）」「スケジュール」「体制・役割」の4つです。余裕があれば予算・品質・リスク・コミュニケーション計画を加えると、実務で使える計画書になります。

計画書は誰が作るのですか？

原則としてプロジェクトマネージャーが中心となって作成します。ただし内容は一人で決めるのではなく、発注者や各担当と対話しながらすり合わせ、最後に関係者のレビューと承認を経て確定させるのが基本です。

作った計画書はどう運用すればいい？

計画書は一度作ったら終わりではなく、進行に合わせて更新し続けることで機能します。計画で決めた「誰が・何を・いつまでに」を日々のタスクに落とし、チームで見える化して定期的に見直すのがコツです。

まとめ：プロジェクト計画書は「更新し続けること」に意味がある

プロジェクト計画書とは、目的・スコープ・体制・スケジュール・予算・品質・リスク・コミュニケーションといった計画情報を1本にまとめ、関係者の共通認識と判断基準をつくる文書です。

規模の大きさにかかわらず、まずは目的・スコープ・スケジュール・体制の4つを固めるだけでも、プロジェクトの見通しは大きく変わります。

プロジェクト憲章（なぜやるか）を受けて、プロジェクトマネージャーが「どうやるか」を具体化するのが計画書の役割でした。

そして何より大切なのは、計画書を作って終わりにせず、日々の実行に落として更新し続けることです。

計画（プロジェクト管理）と日々のタスク管理をつなぎ、チームで見える化することが、計画を成果に変える一番の近道です。

参考文献・出典

• 小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年、ISBN 978-4-408-65143-9
• PMI日本支部（PMBOKガイドの提供元）
• Project Management Institute（PMI）
• 情報処理推進機構（IPA）
• 日本産業標準調査会（JISC）／JIS Q 21500
• 公益財団法人 日本生産性本部
• 中小企業庁
• 総務省統計局『人口推計』
• Microsoft サポート：Excelでガントチャートにデータを表示する