プロジェクトマネジメント計画書：構成要素、手順、例

プロジェクトマネジメント計画書とは何ですか？

A プロジェクトマネジメント計画書 とは、プロジェクトをどのように実行、監視・コントロール、終結するかを定める、正式に承認された文書です。スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーに関する補助的なマネジメント計画書と、パフォーマンスの測定に使うベースラインを統合したものです。

この表現はPMIの*PMBOKガイド*に由来しており、同ガイドはプロジェクトマネジメント計画書を、プロジェクトをどのように実行、監視・コントロール、終結するかを記述する文書と定義しています。実際には、プロジェクトのルールブックです。チーム、スポンサー、ステークホルダーが、意思決定の方法、進捗の報告方法、変更が生じたときの対応を確認するための拠り所になります。

優れた計画書は、いくつかの実務的な問いに答えます：

• 何を 何を提供し、何がスコープ外なのか？
• 時期 主要な成果物とマイルストーンはいつ完成するのか？
• いくら かかり、支出をどのようにコントロールするのか？
• 参加者 誰が作業を行い、誰がどの意思決定をするのか？
• 方法 品質、リスク、課題、サプライヤー、コミュニケーションをどのように管理するのか？
• 行うこと 誰かが変更を求めたときにどうなるのか？

通常はプロジェクトマネージャーが、チーム、主題専門家、主要なステークホルダーの意見を取り入れて作成し、スポンサーまたはプロジェクト委員会が承認します。その作成は次の中核的な活動です： プロジェクト統合マネジメント。他のすべての知識エリアを結び付けるものだからです。

プロジェクトマネジメント計画書と他のプロジェクト文書の違い

「プロジェクト計画」「プロジェクトマネジメント計画書」「スケジュール」は同じ意味で使われがちです。重なる部分はありますが、同じものではありません。下表は、立ち上げ時の主な文書の関係を示しています。

重要な違いは、 憲章はプロジェクトが存在することとその理由を示すのに対し、 プロジェクトマネジメント計画書はそれをどのように提供するかを示すという点です。スケジュールは計画書の一部にすぎません。PRINCE2の環境で働いている場合、PIDはプロジェクトマネジメント計画書と似た役割を果たしますが、ビジネスケースとプロジェクトマネジメントチームの構成も含んでいます。

プロジェクトマネジメント計画書が重要な理由

計画書の作成には時間がかかるため、何が得られるのかと考えるのは当然です。当サイトの経験では、そのメリットは文書そのものより、早い段階で否応なく行う検討と合意から生まれます。

• 共通の理解： お金を使う前に、スポンサー、チーム、ステークホルダーがスコープ、優先順位、仕事の進め方について合意します。
• 進捗を測定する基準： スコープ、スケジュール、コストについて承認された ベースライン がなければ、プロジェクトが進んでいるのか、遅れているのか、予算を超過しているのかを判断できません。
• 意思決定の迅速化： 役割、承認限度、エスカレーションの経路が事前に合意されているため、誰が決めるのかを探っている間に課題が停滞することがありません。
• 変更のコントロール： 明確に定められた 変更管理 のプロセスが、プロジェクトをスコープクリープから守ります。
• 想定外の事態の減少： リスク、品質、調達を最初に計画することで、修正コストがまだ低いうちに問題が明らかになります。
• オンボーディングの容易さ： 新しいチームメンバーやサプライヤーは、メールや議事録をつなぎ合わせる代わりに、1つの文書を読むだけで済みます。

プロジェクトマネジメント計画書の構成要素

構成要素のチェックリストとして最も広く使われているのは*PMBOKガイド*第6版のもので、補助的なマネジメント計画書、ベースライン、追加の構成要素の3つのグループで説明されています。その後の版は原則とパフォーマンス領域の構成に移行し、調整をより重視するようになりましたが、計画書で何を扱うべきかを決めるうえで、第6版の一覧は今でも実用的な参考資料です。

補助的なマネジメント計画書

各補助計画書は、プロジェクトの1つの領域をどのように管理するかを説明します。小規模なプロジェクトなら数個をそれぞれ1段落で済ませられますが、大規模なプロジェクトではそれぞれが主計画書から参照される別の文書になることもあります。

ベースライン

ベースラインは、スコープ、スケジュール、コストの承認済みのバージョンです。正式な変更管理を通じてのみ変更され、実際のパフォーマンスはこれと比較されます。

3つを合わせたものが パフォーマンス測定ベースラインであり、アーンドバリューマネジメントの比較対象となるものです。

追加の構成要素

*PMBOKガイド*第6版では、プロジェクト全体の運営方法を説明する構成要素も挙げています：

• 変更マネジメント計画書： 変更をどのように要求、評価、承認、記録するか。
• 構成マネジメント計画書： 成果物と文書のバージョンをどのように識別し、管理するか。
• プロジェクトライフサイクルの記述： プロジェクトが経るフェーズ。
• 開発アプローチ： 予測型、適応型（アジャイル）、ハイブリッド型のいずれか、およびその理由。
• マネジメントレビュー： スポンサーやステアリンググループがいつ進捗をレビューし、継続か中止かを判断するか。

プロジェクトマネジメント計画書の作り方：10の手順

以下の順序は、ほとんどの実務家が用いる論理に沿っています。まず何を提供するかに合意し、次にいつ、いくらで提供するか、そしてそれを取り巻くすべてをどのように管理するかを決めます。実際には、後の手順で前の手順の問題が明らかになって戻ることもありますが、それは普通のことです。

1. 承認済みの憲章とビジネスケースから始める

次を読む： プロジェクト憲章 とビジネスケースをよく読みましょう。目標、上位レベルのスコープ、固定された日付、予算の範囲、既知のリスク、制約条件を書き留めます。計画書の内容はすべてこれらと整合していなければなりません。憲章に非現実的な点があれば、計画書の中に埋もれさせるのではなく、今のうちにスポンサーに提起しましょう。

2. ステークホルダーを特定し、要求事項を収集する

プロジェクトの影響を受ける人、またはプロジェクトに影響を与えうる人をすべて挙げ、その要求事項を収集して優先順位を付けます。インタビュー、ワークショップ、既存プロセスのレビューがいずれも役立ちます。後で各要求事項を成果物までトレースできるよう記録しておきましょう。

3. スコープを定義し、WBSを作成する

対象、除外事項、成果物、受入基準を明確にしたスコープ記述書を作成します。次に、成果物を WBS（ワーク・ブレークダウン・ストラクチャー） に分解し、各ワークパッケージを見積もりと割り当てができる大きさにします。当サイトの無料の WBSテンプレート を使えば、最初の構成をすぐに用意できます。

4. ライフサイクルを選び、アプローチを調整する

プロジェクトを予測型、アジャイル型、ハイブリッド型のどれで進めるか、どのフェーズを設けるか、各領域にどの程度の正式さが必要かを決めます。2か月の社内プロジェクトと2年間の規制対象プログラムで、同じレベルの文書化を行うべきではありません。

5. スケジュールを作成する

ワークパッケージをアクティビティに変換し、依存関係に基づいて順序を付け、所要期間を見積もり、次を特定します： クリティカルパス。主要な意思決定と引き渡しのマイルストーンを追加します。当サイトの プロジェクトのスケジューリング のガイドで各手順を解説しています。

6. コストを見積もり、予算を設定する

類推見積り、パラメトリック見積り、ボトムアップ見積りなどの技法を使って各ワークパッケージのコストを見積もり、特定されたリスクに対する予備費を加えます。見積りを集計して期間別の プロジェクト予算 にまとめ、マネジメント予備についてスポンサーと合意します。

7. 資源、役割、責任を計画する

誰が作業を行うか、いつ対応可能か、どのような設備や資材が必要かを確認します。 RACIマトリクス を使って、主要な成果物と意思決定ごとに、実行責任者、説明責任者、相談先、報告先を示します。

8. 品質、リスク、コミュニケーション、調達、ステークホルダーエンゲージメントを計画する

補助的な計画書を作成します。品質基準と受入確認を設定し、リスクワークショップを開いて次を作成し始め、 リスク登録簿、報告のリズムとチャネルについて合意し、何をどのように購入するかを決め、各ステークホルダーグループの関与の方法を計画します。

9. 変更管理、ベースライン、報告を定義する

変更をどのように要求・承認するか、誰が何を承認できるか（たとえば、一定のコストまではプロジェクトマネージャー、それを超える場合はスポンサー）、意思決定をどのように記録するかを記述します。スコープ、スケジュール、コストのベースラインを設定し、週次の状況報告書などで進捗をどのように報告するかについて合意します。

10. レビュー、承認、キックオフ

スポンサーと主要なステークホルダーに計画書を説明し、意見に対応して正式な承認を得ます。その後キックオフミーティングを開き、チーム全員が目標、計画、その中での自分の役割を理解できるようにします。プロジェクトマネージャーしか読んでいない計画書は、誰の指針にもなりません。

プロジェクトマネジメント計画書の例

以下の例は説明用に簡略化したものです。120人のチームを新しいオフィスに移転させるという中規模の社内プロジェクトで、計画書の各部がどのような記述になるかを示しています。

各項目が具体的で測定可能である点に注目してください。「支障を最小限にする」は「各チーム1営業日以内」に、「関係者に情報を伝える」は具体的なチャネルと頻度になっています。

プロジェクトマネジメント計画書のアウトライン

このアウトラインを文書の目次として使いましょう。該当しないセクションは削除または統合し、既存の文書がある場合はリンクします。

1. 文書管理：バージョン、日付、作成者、承認者、変更履歴。
2. プロジェクトの概要：憲章に記載された背景、目標、成功基準。
3. スコープ：スコープ記述書、除外事項、成果物、受入基準、WBS。
4. 開発アプローチとライフサイクル：フェーズ、手法、調整に関する決定。
5. スケジュール：マイルストーン一覧、要約ガントチャート、スケジュール管理のルール。
6. 予算：コストベースライン、予備費、資金、コストコントロールのルール。
7. 組織：役割、責任、RACI、意思決定権。
8. 資源マネジメント：人員配置、設備、資材。
9. 品質マネジメント：基準、レビュー、受入。
10. リスクマネジメント：アプローチ、尺度、責任者、レビューサイクル。リスク登録簿へのリンク。
11. コミュニケーション：ステークホルダー、メッセージ、チャネル、頻度。
12. 調達：何を購入するか、サプライヤーをどのように管理するか。
13. ステークホルダーエンゲージメント：主要なグループごとのアプローチ。
14. 変更管理と構成管理：プロセス、しきい値、記録。
15. 監視と報告：状況報告書、レビュー、主要な指標。
16. 終結：受入、引き渡し、教訓。
17. 付録：詳細なスケジュール、見積り、登録簿、テンプレート。

当サイトの無料の プロジェクト計画書テンプレート なら、Sheets、Excel、PDFですぐに使える構成が手に入ります。補助的なセクションには次と組み合わせましょう： リスク登録簿テンプレート, コミュニケーション計画テンプレート と RACIマトリクステンプレート 。

計画書はどこまで詳細にすべきか？

決まった長さはありません。適切な詳細さとは、チームが進め方をいちいち尋ねずに作業でき、スポンサーが何を承認しようとしているのかを把握できる程度です。大まかな目安は次のとおりです：

各セクションについて2つの問いを立てましょう。それがなかったら誰かが気付くか、それによって誰かが異なる判断をするか。どちらの答えも「いいえ」なら、削除します。

アジャイルとハイブリッドのプロジェクトにおけるプロジェクトマネジメント計画書

アジャイルチームも計画は立てますが、その方法が異なります。詳細なスコープを最初に固定する代わりに、ビジョン、時間と予算の枠、仕事の進め方を固定し、詳細な計画は1リリースまたは1スプリントずつ立てます。これはローリングウェーブ計画法と呼ばれることもあります。

• 固定するもの： 目標、ガバナンス、予算の上限、リリースのマイルストーン、役割、完成の定義、ステークホルダーの関与の方法。
• 柔軟にするもの： 詳細なスコープ。固定されたスコープベースラインではなく、優先順位付きのプロダクトバックログで管理します。
• 置き換えるもの： 詳細なガントチャートはプロダクトロードマップとリリース計画に、スコープに関する正式な変更要求はプロダクトオーナーによるバックログの優先順位付けに置き換えます。

ハイブリッドのプロジェクトでは両方を組み合わせることがよくあります。ハードウェア、契約、規制上のマイルストーンには予測型の計画を、ソフトウェアやコンテンツにはアジャイルな提供を使います。

計画書を最新の状態に保つ

承認された計画書はベースラインであり、最終的な答えではありません。プロジェクトは変化するものであり、計画書もそれに合わせてコントロールされた方法で変わるべきです。

• 変更管理を使う： 各変更を承認する前に、スコープ、時間、コスト、品質、リスクへの影響を評価し、該当するセクションを更新します。
• ベースラインの再設定は変更が承認された場合のみ： 遅れを隠すためにこっそりベースラインを動かしてはいけません。差異は有用な情報です。
• 決まった時点でレビューする： 各フェーズゲート、大きな変更の後、長期のプロジェクトでは少なくとも毎月レビューします。
• バージョン管理を行う： 何を、いつ、なぜ変更し、誰が承認したかを文書管理のセクションに記録します。
• 関係者に伝える： 誰も知らない変更後の計画は、計画がないのと同じくらい多くの問題を引き起こします。

プロジェクトマネジメント計画書でよくある間違い

計画書の作成と維持に使うツール

多くのチームは、計画書の記述部分を文書で作成し、スケジュール、タスク、リスク、予算をプロジェクト管理ソフトウェアで管理しています。ソフトウェアを使うと計画を最新の状態に保ちやすくなります。依存関係は自動で更新され、ダッシュボードにはベースラインに対する進捗が表示され、全員が同じバージョンを見られます。

作業計画のためのツールを比較する際は、依存関係とベースラインを備えたガントチャート、リソースやワークロードのビュー、リスクや課題のためのカスタムフィールド、レポートダッシュボードがあるかを確認しましょう。 Wrike（当サイトのランキング第1位のツール）は、依存関係付きのインタラクティブなガントチャートと、Teamプラン以上で共有可能なダッシュボードを備えており、複数のプロジェクトを同時に運営するチームに適しています。一方、よりシンプルな計画には軽量なツールが向いています。当サイトの ガントチャートソフトウェア のガイドと、完全版の プロジェクト管理ツールランキング が選択の助けになります。

計画書が承認されたら、次はそれをチームが従えるスケジュールに落とし込みます。

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問