【初心者向け】はじめてのプロジェクト計画書作成（テンプレートあり)

初心者PM

プロジェクト計画書って、何を書けばいいのかわからない・・・

こんな悩みに答えます！

この記事を読めば、プロジェクト計画書で何を書くべきか悩まずに、実績のあるテンプレートを使ったプロジェクト計画書を作成できます。プロジェクト計画書を作ることで、プロジェクトメンバーの認識もそろい、プロジェクト成功率は格段にアップすること間違いなしです！

プロジェクト計画書の重要性

プロジェクト計画書は、プロジェクトの成功への道筋を示す重要なドキュメントです。

プロジェクト計画書ができればプロジェクトの7割が終わったといっても過言ではないくらいです。プロジェクトマネージャーにとって、プロジェクト計画書の作成はプロジェクトの方向性を明確にし、関係者とのコミュニケーションを円滑にするためにも欠かせないスキルとなります。

なぜプロジェクト計画書が必要なのか

プロジェクト計画書が必要な理由は以下の通りです。

プロジェクト計画書は、プロジェクトの「地図」のようなもので、目的地への道のりを示し、迷わずに進むための指針となります。企画職のみなさんがプロジェクトマネジメント初心者であっても、計画書を作成することで、プロジェクトを効率的に進めることができます

プロジェクト計画書がもたらす効果

プロジェクト計画書は、単なる書類ではありません。それはプロジェクトの成功への鍵となる多くの効果をもたらします。その主な効果について詳しく解説します。

プロジェクト計画書は、プロジェクトを成功に導くための強力なツールです。企画職のみなさんがプロジェクトマネジメント初心者であっても、この計画書を活用することで、プロジェクトを効果的に推進する力が身につきます。

プロジェクト計画書と企画書の違い

プロジェクト計画書と企画書は、プロジェクトマネジメントにおいて重要なドキュメントですが、それぞれの目的と内容が異なります。ここでは、その違いについて詳しく解説します。

 プロジェクト計画書はプロジェクト全体の進め方を記載したものであるのに対して、企画書は、プロジェクトの中で作成される成果物の一つです。多くの場合、プロジェクトの企画フェーズの成果物が企画書となります。

言い換えるとプロジェクトのアウトラインを示すのが計画書で、企画書はアウトラインに沿ってプロジェクトが進む中で作られるドキュメントです。

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

ここからはプロジェクト計画書の作成方法を説明していきます。

PM初心者だとプロジェクト計画書に何を書くべきか悩むと思います。でも、実はプロジェクト計画書に書くべきことは決まっています。どんなプロジェクトであろうと計画書に書くべきことは変わりません。

ということで、実際にプロジェクト計画書のテンプレートをベースに作成手順を解説していきます。まず、以下のリンクから計画書のテンプレートをダウンロードしておいてください。

なお、説明で使用しているサンプルPJTの計画書（はじめから内容が記載されているもの）はこちらからダウンロードできます。

背景・目的・目標

プロジェクト計画書で最も重要なページです。ここには、プロジェクトの背景、目的、目標が記載されます。それぞれの要素について説明します。

背景

背景には、プロジェクトが始まることになった理由を記載します。多くの場合、プロジェクト実施の背後にある課題を要約したものを書きます。いわゆるWhyに当たる部分です。

この例では、法改正に伴い、業務やシステムを変更する必要があることについて記載されています。このように、法改正によって業務とシステムについて課題が発生してしまい、それがプロジェクト実施の理由であり背景です。こういった課題を簡潔にまとめたものを、背景として記載します。

目的

目的には、プロジェクトで達成したいゴールを記載します。多くの場合、背景に書かれた課題が解決された状態を書きます。いわゆるWhatに当たる部分です。

この例では、背景に書かれた課題（＝法改正によって、業務とシステムを改修する必要があること）が解決された状態を目的に設定しています。

気を付けたいポイントは、目的に手段（＝HOW）を書かないことです。この例だとXXシステムの改修や、XX業務プロセスの変更などは目的には適しません。あくまでそれらの手段を行った結果、どういった状態になっていたいのか？を目的に設定します。

目標

目標には、目的を達成するための条件を記載します。多くの場合、KPIやスケジュール的な目標を書きます。

この例では、スケジュール的な目標を記載しています。目的を達成するために必要な業務プロセスとシステムの改修をスケジュール的な目標に落とし込んでいます。ここに書いた目標を達成することで、目的が達成される、というような関係性になっていることが重要です。

プロジェクト方針

プロジェクトの進め方について端的に記載するページです。プロジェクト方針は、プロジェクトの進め方の基本的なルールや価値観を記載します。後続ページのサマリーとしての役割も持ちます。

この例では、法改正への対応なので、スケジュールに間に合わせることが最優先であるという方針を明示しています。

このページはプロジェクトによって書く内容が異なり、作成難易度が高いページです。そのため、後続のページを作成した後に書くのもおすすめです。

プロジェクト方針には次の内容を書くことが多いです。

プロジェクト方針は、プロジェクトの「羅針盤」のようなもので、プロジェクトがどのような価値観で進められるべきか、どのようなルールで運営されるべきかを示します。

この方針を明確にすることで、プロジェクトメンバー全員が同じ価値観とルールで進めることができ、プロジェクトの成功につながります。

前提

プロジェクトを進める上での基本的な条件や制約を明示するページです。

ここに書くことは絶対に揺るがない事実であって、プロジェクトを進める間に覆ることがない制約事項です。ただし、こういったことがない場合、前提を記載しなくてもOKです。

この例では、法改正という絶対に揺るがない事実を前提に記載しています。

前提には次のようなことが書かれます。

スコープ

プロジェクトの範囲を定義するページです。

プロジェクトで対応するところ、対応しないところを可視化します。スコープを明確にすることで、プロジェクトの目標に対する取り組みが明確になり、無駄な作業を排除することができます。

この例では、業務プロセスを軸にプロジェクトで対応する業務・システム・担当部署について、対応する・しないを可視化しています。ポイントは、対応しない部分（＝スコープ外）もあえて記載しているところです。こうすることで、後から「ここは対応しなくていいの？」という問いが発生しないようにけん制できます。

次のような観点でスコープを定義します。

課題と対応方針

プロジェクトを通じて解決したい課題と、それらの対応方針を明示するページです。

プロジェクト計画の段階では、課題と対応方針が詳細に定まっていないことが多いので、書くとしても概要レベルでOKです。プロジェクトを進める中で詳細化することが一般的です。

この例では、提案活動とコンテンツという観点で課題と対応方針を整理しています。ただし、課題と対応方針の抽象度は高めで、システムの具体的な機能などは書かれていません。プロジェクト計画段階では、このくらいのレベル感で記載できていれば十分です。

ちなみに、ここに記載される課題は、プロジェクトの背景と関連している必要があります。プロジェクトを実施することになった背景には、何らかの課題が含まれています。その課題を具体化したものを、このページに記載します。

ゴールイメージ

プロジェクトで解決すべき課題が克服された、理想的な状態を描写するページです。

ゴールイメージを描くことでプロジェクトの方向性を明確にし、メンバー間で共通認識を作ることができます。ただし、プロジェクト計画書の段階では必ずしも具体化されている必要はありません。プロジェクトを進める中でゴールイメージを具体化するのが一般的です。

この例では、プロジェクト計画書の中ではゴールイメージを描かず、あえて後続STEPで決定することのみを記載しています。実際のプロジェクトでもこのように記載することがあります。

あくまでプロジェクト計画書はプロジェクトの進め方について記載するもので、どのようなゴールイメージを描くかは企画書に落とし込まれているべきです。

対応STEP

プロジェクトの開始から終了まで、大まかなタスクの全体像を示すページです。

この対応STEPは、後に作成するWBSのもとになります。そのため、プロジェクト計画段階で作業レベルまでタスクを詳細化する必要はありません。ここでは、あくまで全体感をプロジェクト関係者で共有することを目的としています。

この例では、プロジェクト全体が5 STEPで構成されていることを可視化しています。そして、それぞれのSTEPでやること、実施時期、担当をざっくり記載しています。ポイントはざっくりでもよいので、全体を示すことです。

ちなみに、プロジェクトの対応STEPは基本の型があります。そもそも、どんなSTEPをたどればよいかわからない、、、という人は以下を参考にSTEPを組むのがおすすめです。

   可能であれば、各STEPを詳細化します。

以下のようにSTEPごとにスライドを作り、対応内容や成果物を記載します。時期や担当者も具体的に記載します。

対応STEPはプロジェクトの成功に向けた重要なステップです。プロジェクトの全体像を明確にし、途中での停滞を防ぐ役割を果たします。プロジェクトの初期段階でしっかりと対応STEPを設定することで、スムーズなプロジェクトの進行が期待できます。

体制図

プロジェクトの登場人物とその役割を洗い出し、整理するページです。

体制図を作成することで、プロジェクトの関係者間のコミュニケーションを円滑にし、責任者や各役割の明確化を図ります。

この例では、システム開発を行うための体制を可視化しています。ポイントとして、プロジェクトにかかわる人を全員洗い出し記載します。また、Ｔシステムのところにあるように、担当者が未定の場合もTBD（To Be Determined）として枠だけ用意します。

また、要件最終決定者や取りまとめ担当者などを決めておくことで、誰が要件決定の責任を持つのか、誰が取りまとめの役割を担うのかをPJT全体で共有できます。こうすることで、誰が何をすべきなのかがはっきりして、プロジェクト全体で分業・協力をしやすくなります。

体制図はプロジェクトの進行をスムーズにする重要なツールです。プロジェクトの初期段階でしっかりと体制図を設定することで、関係者間の認識の共有とコミュニケーションの効率化が期待できます。

役割分担

プロジェクトに関与する各メンバーの役割と責任範囲を明確にするページです。

役割分担を明確にすることで、プロジェクトの作業を効率的に分業できるようになります。また、各役割が何をすべきなのかを全員が把握できるため、メンバーも安心してプロジェクトに参加できます。

この例では、POやPMなどの役割ごとに何をすべきなのかと、誰が担当なのかを一覧化しています。もちろん、前ページの体制図と連動しています。こうすることで、誰がどこまでの責任を持つのか？や誰がどこまでの作業をするのか？を全員で共有できるようになります。

POやPMOなどの言葉の解説は以下の記事も参考にしてみてください。

あわせて読みたい

プロジェクトマネジメント用語集：初心者向けにわかりやすく解説！

責任範囲があいまいになることは、大きいプロジェクトだとよく起こります。そうならないためにも、プロジェクトの初期段階でしっかりと役割分担を設定することが必要です。

スケジュール

プロジェクトの各STEPやタスク、重要なマイルストーンを時間軸に沿って可視化するページです。

スケジュールを明確にすることで、プロジェクトの全体像を一目で把握することができます。対応STEPのページで定めた各STEPや並行プロジェクトなども可視化します。

この例では、対応STEPで定めた内容に加え、並行プロジェクトや契約などマイルストーンも併せて可視化しています。こうすることで、プロジェクトが進んでいくと何が起こるのか？を想像しやすくなります。

プロジェクト計画書の段階では、あくまで全体把握ができればOKです。ただし、今後WBSを作るためのINPUTとしても利用することを想定し、無理のないスケジュールになっていることが大切です。

リスクと対応策

プロジェクト開始時点での潜在的なリスクと対応策を可視化するページです。

リスクの検討は忘れがちですが重要です。事前にリスクを想定し、適切な対応策を準備することでプロジェクトの失敗を未然に防ぐことができます。

この例では、遅延と品質という2つの観点からリスクと対応策を検討しています。こうすることで、そもそも遅延が起こらないようにプロジェクトを進められるし、仮に遅延が起こってもスムーズに受け身をとることができます。

プロジェクトの初期段階でしっかりとリスク管理を行うことで、未然に問題を防ぎ、プロジェクトの成功につなげることができます。

課題管理方法

プロジェクトで発生する課題管理についてのルールと手順を記載するページです。

プロジェクトを進めるうちに、必ず課題が発生します。その時にその課題を素早く可視化することが大切です。そのためにも、プロジェクト計画時点で課題管理の方法を決め、プロジェクト関係者間で合意します。

この例では、課題管理ツールであるBacklogのURLと、その使い方に関するルールを可視化しています。管理方法はプロジェクトによって異なってもよいのですが、何らかの方法で一元管理することが重要です。

ドキュメント管理方法

プロジェクトで作成・使用されるドキュメントの管理について、ルールと手順を可視化するページです。

プロジェクトを進めると、大量のドキュメントが作成されます。もし、保管場所やルールを定義していない場合、あるべきドキュメントが見つからなかったり、似たようなドキュメントがいくつも作成されたり、探す時間が余計にかかったりします。

この例では、ドキュメント保管場所をGoogle Driveに指定しています。そのうえで、管理ルールを決めています。

保管場所は会社やプロジェクトごとに決めればよいのですが、できるだけ関係者が全員アクセスできる使いやすい場所を選定しましょう。

保管場所は、以下のような場所から選定します。

ドキュメント管理がうまくできていないと、認識の齟齬が生まれたり、コミュニケーションコストが余計にかかったりします。そのため、プロジェクト計画時点で取り決め、関係者で合意しておくとスムーズに進みます。

コミュニケーション方法

プロジェクトメンバー間でのコミュニケーションルールを可視化するページです。

関係者が多い場合、チャットやメール、口頭など様々な方法でコミュニケーションがとられます。情報共有を行うためにも、個別のやり取りは避けて、みんなが見える場所に情報を集めることが大切です。

この例では、Teams（チャット）にコミュニケーションを集約する旨が記載されています。メールや個別チャットでのやり取りをNGにして、情報が埋もれないようにしています。また、ファイル共有もチャットに張り付けず、URLを共有することでドキュメントが散在しないようにしています。

効率的な作成のコツ

これまで説明してきた通り、プロジェクト計画書は多くのことを記載する必要があります。

このボリュームをゼロから作っていてはとても時間がかかります。そのため、ここでは効率的に計画書を作成する2つのコツをお伝えしていきます。

スライド作成のコツ

まずは、スライド作成のコツです。プロジェクト計画書にとどまらず汎用的に使えるコツなので、覚えておいて損はありません！

まず、スライド作成ですが単に早く作るだけならショートカットキーを覚えれば事足ります。しかし、それだけでは不十分です。そもそもスライドを作るには目的があるはずです。その目的を最短で達成するために必要なことを順番に説明します。

そもそも、スライドを作る目的は、読み手を動かすことです。プロジェクト計画書であれば、POやメンバーといった関係者を計画通りに動かして、プロジェクトをスムーズに完遂させることが目的です。

そんなスライドを作るには次の3つのテクニックを使うのがおすすめです。

スライド作成のコツを掴むことで、プロジェクト計画書の作成がスムーズになり、効率的に高品質な計画書を作成することができるようになります。

あわせて読みたい

【企画職向け】人を動かすスライドの作り方（パワポテンプレートあり）

テンプレートのカスタマイズ

このサイトでも提供しているテンプレートをカスタマイズするのも効率的な方法です。

プロジェクトにはある程度の型があります。そのため、毎回作り直すよりも実績があるものを使いまわすほうが効率的です。ただし、自社のフォーマットなどがあると思いますので、それに合わせてカスタマイズして使いましょう。

このサイトで提供しているテンプレートを自社のテンプレートに適用する際の注意点とカスタマイズのコツを以下に紹介します。

このサイトで提供しているテンプレートはすべて商用利用可能です。部分的にでも活用することで効率化を図れますので、ぜひ活用してみてください！

まとめ

プロジェクト計画書の作成は、プロジェクトの成功への第一歩です。プロジェクト計画書がいい感じに作れたら、そのプロジェクトはほぼ成功したといっても過言ではないくらいです。それくらいプロジェクト計画書は大事なのです。

というのも、プロジェクト計画書はボリューミーであるため、作る過程でプロジェクト全体を否が応でも考えることになります。その結果、プロジェクト開始時点で、プロジェクト終了までの見通しが立ちます。逆に見通しが立たないまま、プロジェクトをスタートさせたら必ず途中で詰んでしまいます。

そうならないためにも、プロジェクト計画を頑張ることが大事です。このサイトでは計画書などのテンプレートも無料で公開しています。（ダウンロードはこちら）それらも活用して、ぜひプロジェクト計画を頑張ってみてください！

あわせて読みたい

【企画職向け】プロジェクトマネジメントの基礎知識と必要スキル

大和田 淳

プロジェクトマネージャー / ITコンサルタント

XContact

プロジェクトマネジメント経験10年以上。システム開発系のPMだけでなく、企画・BPRなどのPMも多数経験。SIer、外資コンサル、自営業、事業会社といろいろな環境でのプロジェクト経験がある。