プロジェクト計画書を作ることは、プロジェクトを成功に導くための第一歩です。
この記事にたどり着いた方は、上司から「そろそろPMやってみるか」「プロジェクト計画書を作ってみろ」と言われて、プロジェクトマネジメントやプロジェクト計画書について調べ始めた人ではないでしょうか？
プロジェクト計画書の重要性は分かっているが、
- より良いプロジェクト計画書を作るために基本を押えたい
- そもそもプロジェクト計画書の構成がよく分からない
- どのような記載をすれば良いのか分からない
このようなお悩みをお持ちでないですか？
この記事では、このような悩みから解放頂けるよう、ソフトウェア系若手PM向けに最低限作るべき簡易的なプロジェクト計画書をとにかく分かりやすく解説します。
また、本記事ではプロジェクト計画書のサンプル資料もございますので、記事と合わせてご利用いただければと思います。
目次
プロジェクト計画書とは
プロジェクト計画書とは、プロジェクトを進めるうえで必要な情報を一通りまとめた計画書のことを指します。
プロジェクト計画書を予め作成しておくと、プロジェクトの途中であっても計画と実績に乖離がないかなど、進捗を素早く詳細に把握することができます。また、プロジェクトの途中で参加したメンバーが状況を把握する際にも活用できます。
プロジェクトの立ち上げ段階から終了時までまとめられているため、その後の振り返りにも役立てられます。
プロジェクトを計画書を作成するためには、プロジェクトを構成する作業を分解し構造化したWBSを作成しなければなりません。WBSの詳しい作成方法はこちらの記事を参考にしてみてください。
WBSの基礎知識と作り方を徹底解説！無料Excelテンプレート付き！
プロジェクト計画の目的
プロジェクト計画を建てる目的は、プロジェクトを成功に導くためです。プロジェクトを成功に導くには、目標（品質・コスト・期限）を決め、これを実現するために必要な活動を計画するという、とてもシンプルなものです。
しかし、プロジェクト計画を建てるにはそれなりの労力が掛かります。そのため、プロジェクト計画を建てずにプロジェクトをスタートさせ、結果失敗してしまうケースがありがちなパターンです。
プロジェクト計画書の型に決まりはありません。多くのプロジェクト計画書はPMBOKのフレームワークが土台となり、その会社やPMの経験に応じてカスタマイズされています。次の章では、プロジェクト計画書の具体的な中身について解説していきます。
【無料資料】プロジェクト生産性を高めて利益を最大化するには？
プロジェクト計画書に記載する項目
プロジェクトの概要（目的・ゴール）
プロジェクトの概要のスライドには、目的とゴールの大きく２つを記載します。箇条書きでも良いです。
スライド数は1～3枚程度にまとめます。
〈目的〉
目的には、「何のためのプロジェクトなのか」を数行にまとめて書きます。ソフトウェア開発は、本来事業戦略に紐づいています。役員に見せるプロジェクト計画書であれば、事業戦略との紐付きが分かるように書くと良いでしょう。
〈ゴール〉
ゴールはQ（品質）、C（コスト）、D（納期）の目標です。なるべく定量的な数値でゴールを設定しましょう。プロジェクト終了後は、一般的にプロジェクトの振返り評価を行います。この際の評価基準にこのゴールを使います。
・Q（品質）
ソフトウェアの場合、品質はあらかじめ「サービスレベル」で細かく定義します。内容としては、ソフトウェア自体の品質（バグやレスポンスタイム）と稼動後の運用品質（稼働率、障害時の復旧時間、運用体制、稼動直後の問合せ件数など）の２つがメインです。定義するサービスレベルの中身はプロジェクトの内容によって異なります。
・C（コスト）
コスト目標は、原価率・利益の目標を設定する場合が多いです。コスト計画自体がコスト目標となります。
・D（納期）
納期目標は、重要なマイルストーンとローンチ日です。ここが守れないと結果的にコスト目標にも響きます。
スコープ
「スコープ」とは、範囲という意味です。スコープのスライドでは、対象システムの範囲、成果物を定義します。まずはシステムの範囲を明確にし、そしてWBSを作り必要な作業を洗い出します。WBSはマスタスケジュールの元ネタにもなります。WBSはプロジェクト計画書の添付資料とします。
プロジェクトでは、ステークホルダーが複数社になることも少なくありません。ステークホルダーによって作業範囲がことなる場合、どの作業をどのステークホルダーが担当なのか分かるように記述します。規模が大きいプロジェクトでは、「スコープ定義書」を別途作り、そのサマリをプロジェクト計画書に記述することもあります。
〈対象システムの範囲〉
本プロジェクトのシステム範囲は、下図のようにシステム構成図を使うと分かりやすくなります。
システム構成図だけだと情報が足りないので（システム間連携も対象なのか、インフラ系の調達も必要なのかなど分からない）、補足情報も必ず書きましょう。WBSからの抜粋でＯＫです。
〈成果物〉
コスト
コストのスライドでは、プロジェクトに掛かるコストの総額とその内訳を記載します。
内訳の粒度は、ソフトウェア（開発費・ライセンス費用）、ハードウェア（本体費用・ライセンス費用）、ネットワーク費用（必要に応じて）、人件費（内部人材・外部人材）、その他の外注費、備品費などのレベルで記載します。
見積レベルの詳細な内訳は添付ｂ資料で用意しておきましょう。全ステークホルダーが参加するキックオフ会では、コストのスライドは外します。内部向けの時のみ使います。
スケジュール
スケジュールのスライドには、パワーポイント1~3枚程度にサマリしたマスタスケジュールを作ります。マスタスケジュール内には、重要なマイルストーンやクリティカルパスも明記します。
詳細なスケジュールはWBSで管理しますが、経営層への説明などにはWBSは細かすぎて適しません。そのため、プロジェクト計画書では、マスタスケジュールを掲載しWBSを添付資料とします。
プロジェクト体制
プロジェクト体制のスライドでは、社内外を含めたプロジェクトの全登場人物、責任者の所在、各要員の役割を必ず明記します。
プロジェクト体制は、以下の２つの記述方式で書くと理解しやすくなります。
〈プロジェクト体制図〉
組織図形式のプロジェクト体制図は、視認性に優れており理解しやすいという特性を持っています。デメリットは、役割が書きづらいことです。
役割については、表形式で別スライドか、プロジェクト体制図の下に記載します。
〈役割表〉
役割表では、会社名、ポジション、役割を表形式に落として記載します。
このスライドを作ることで、プロジェクト体制と責任の所在が明確になります。
品質マネジメント
品質のスライドでは、システムおよび運用が達成すべき基準を具体的に定義します。プロジェクトの規模によっては、「サービスレベル定義書」というものを別途作り詳細な基準を定義します。
役員への説明には、サービスレベル定義書は細かすぎるため、特に重要な項目をピックアップして掲載します。
コミュニケーション
コミュニケーションのスライドでは、会議体とコミュニケーションルール（議事録、メール、プロジェクト管理ツール）について記載します。
コミュニケーションの質はプロジェクトの質に大きく影響します。コミュニケーション計画を忘れてしまうプロジェクトも多々見られますが、忘れずに必ず計画に入れましょう。
〈会議体〉
〈議事録作成のルール〉
議事録作成は、A社にて担当者をたて全会議の議事録を作成するものとする。
議事録は会議終了後３日以内に全ステークホルダーにメールにて送付する。
受領後、A社およびB社PMにて承認を行う。確認事項がある際は、随時PM間でやり取りをして調整する。
〈メールのルール〉
メールは以下のルールで運用するものとする。
- メールの送付先（TO）：コミュニケーションを取りたい人のみTo
- メールの送付先（CC）：全PMおよび分科会関係者
- 件名：【プロジェクト名】【分科会名】【メールの要件】
〈プロジェクト管理ツール〉
プロジェクト管理は、「Redmine」を使って行うものとする。プロジェクトに関するドキュメントは全てRedmine上に集約・管理する。Redmineの運用ルールは、別紙「Redmine運用ルール」で定義された運用とする。
リスクと対策
リスクと対策のスライドでは、プロジェクト中に発生する可能性のあるリスクを可能な限りすべて洗い出し、それぞれのリスクに対しての対策を記述します。
リスクの洗い出しと対策も、多くのプロジェクトで忘れられがちなものです。順調に行っている時は良いですが、問題が発生した時に対策があるかどうかで対応スピードに大きな差がでることもあります。
【無料資料】工数管理を軸にした生産性向上・業務改善の5つのステップ
プロジェクト計画書のつくり方
プロジェクト計画書は、次の手順にしたがって作成すると良いでしょう。
●ステップ1：スコープを定義する
●ステップ2：人的リソースを見積もる
●ステップ3：スケジュールを決定する
●ステップ4：コストを見積もる
●ステップ5：リスクアセスメントを行う
各ステップについて説明していきます。
ステップ1：プロジェクトスコープの定義
プロジェクト計画書におけるスコープは、タスク、時間、リソースなどの、プロジェクトの完遂に必要なモノやコトの範囲を指します。
したがって、スコープを定義しないことにはプロジェクトを動かすことはできません。そのためにはゴールを明確にして必要な作業を洗い出していきます。
ステップ2：人的リソースの見積もり
スコープが定義できると作業内容や作業量が確定するため、プロジェクトの遂行にどんな人が必要で、何名が必要なのかがみえてきます。
どの作業を誰に割り当てるのか、どの部分を外注や調達でまかなうのかを含めて必要な人的リソースを詳細に割り出しましょう。
また、プロジェクト計画書には、組織図や役割表を記載することで視覚的にもわかりやすく、それぞれのタスクを整理するのに役立ちます。
ステップ3：スケジュールの決定
全体の工期、着手時期、マイルストーン、ローンチの日程などを定めます。
スケジュールは、大枠をマスター・スケジュールとしてつくり、そのなかに小さな枠の詳細なスケジュールを組み込んでいきましょう。
ステップ4：コストの見積もり
プロジェクトの最終的なゴールは利益を出すことなので、利益の押し下げ要因になるコスト計算はプロジェクト計画書に盛り込まなければなりません。必要な作業量と作業期間を割り出して、最終的なコストを見積りましょう。
コストが確定すると、目標売上高の額や目標利益の額もみえてきます。またコストが確定することによって企業は資金繰りを実施することができます。
ステップ5：リスクアセスメント
リスクアセスメントとは、予想されるリスクを調査することを意味します。リスクアセスメントによってリスクが大きすぎることが判明したら、計画を見直したり、プロジェクトを中止したりすることもできます。
プロジェクトを進行させているときにトラブルが起きるのは仕方がないことですが、そのトラブルが想定外となることは避けなければなりません。リスクアセスメントをしっかり行い、トラブルを想定内に抑えるようにしましょう。
プロジェクト計画書を作成するときの注意点
ここまでプロジェクト計画書のフローを紹介してきましたが、実際にプロジェクト計画書を作成するときは、次の3点に注意する必要があります。
- フォーマットを決めておく
- 図やグラフで定量的に記載する
- 計画書の用途に沿った形で記載する
それぞれについて紹介していきます。
フォーマットを決めておく
プロジェクト計画はあくまで計画なため、実際にプロジェクトが動き始めた際に予定通り進まないことは珍しくありません。
計画書の内容と実際に齟齬が生じたとき、フォーマットがないと修正作業に手間がかかります。そのためプロジェクト計画書の作成段階から、フォーマットを決定しておくとよいでしょう。
フォーマットを用意しておけば、プロジェクト計画書の作成者とプロジェクト進行の責任者が異なった場合でも混乱や認識の食い違いが起きるリスクが低減します。
図やグラフで定量的に記載する
プロジェクト計画書は、プロジェクトチームのメンバーだけでなく、他部署の人たちや経営陣も理解できる内容である必要があります。そのため図やグラフといった定量情報を使って、プロジェクト計画書を視覚的にわかりやすくするとよいでしょう。
また、図やグラフを作成するために必要なデータは、エビデンスのベースとなります。そのため図やグラフを盛り込むことでプロジェクト計画書がより確実なものになるでしょう。
計画書の用途に沿った形で記載する
プロジェクト計画書が完成すると、プロジェクトに関係するさまざまな人がこれを使用します。そのため、プロジェクト計画書は、それらの関係者の用途に沿った形でつくることが望ましいとされています。
たとえば経営者は、プロジェクト計画書を経営戦略の資料にしたり、管理職はプロジェクト計画書をマネジメントに使ったりするでしょう。
プロジェクト計画書はこれらの用途に対応できるようにしなければなりません。
ただ、上記で紹介した、スコープや人的リソース、コストやリスク、図や表などがしっかり入っていれば、さまざまな人の用途に対応できるプロジェクト計画書になっているでしょう。
プロジェクト管理のおすすめツール
プロジェクト計画書が完成すると、リーダーや責任者はプロジェクトを管理することになります。そこでプロジェクト管理に使えるおすすめのツールを3つ紹介します。
Backlog
「Backlog」がユニークなのは、36種類のキャラクターアイコンが用意されているところです。こうしたユーモアがあることで、初めてチームを組むメンバーどうしでもコミュニケーションが取りやすくなります。
もちろん、プロジェクトの進捗状況を可視化する機能もあります。担当者や期限が明示されるため、ミスを防ぐことができたり、リスクを予知できたりします。
asana
「asana」は、プロジェクトの始まりから終わりまでの計画やタスクを整理、管理するツールです。プロジェクトチームのメンバー1人ひとりのタスクが見えるため、リーダーや管理者はメンバーのタスク量を調整することができます。
また、フィードバックやファイル、ステータスの更新を共有できるうえに、プロジェクトチームのメンバーも、ほかのメンバーが何をしているのかが見えるので、チーム内に助け合う関係が自然に生まれるでしょう。
asanaを使えばメンバー全員が適切なタイミングで適切にタスクをこなしていくことができます。
クラウドログ
「クラウドログ」の最大の特徴は、リアルタイムでプロジェクトの進捗状況を確認できることです。メンバーの高稼働を未然に防止できるほか、空きの工数情報をリアルタイムに把握することで、新規案件を受注し、アサインできるメンバーを素早く見つけることもできます。
また、汎用性が高い点もクラウドログの特徴です。企業独自の項目の追加や設定の変更を行えるため、あらゆる形式のプロジェクトに対応可能です。複雑な計算やリソースの割り振りなどを求められるプロジェクトであっても、自由度の高い設定を行えるクラウドログならば最適なプロジェクト管理を行えるでしょう。
まとめ
この記事では、初めてプロジェクト計画書を作るソフトウェア系若手PM向けに、最低限作るべき簡易的なプロジェクト計画書の書き方についてとにかく分かりやすく解説してきました。
プロジェクト計画書のフレームワークはPMBOKなどいろいろありますが、これが正解というものはありません。
PMBOKなどのフレームワークを土台に、会社やPMそれぞれの経験で最適なプロジェクト計画書を作りましょう。その積み重ねでプロジェクトマネージャーとしての腕が磨かれていきます。
今回はプロジェクト計画書のサンプルをご用意致しましたので、この記事を参考にプロジェクト計画書を作ってみましょう。
