ベント・フライヴビェルグ氏は、70年間にわたり20カ国で実施された258件のプロジェクトを調査しました。そのうちの10件中9件が予算超過となり、平均してコストは予測を28％上回りました。
原因は実行の不備ではなく、チームがプランをどのように扱ったかにありました。彼らは一度プランを作成し、承認を得た後は、それを使い続けませんでした。状況が変わっても、プランは変更されなかったのです。
多くのプランは、3週目までに放棄されてしまいます。それらは「承認されるため」に作成されたものであり、「実際に活用されるため」のものではないからです。また、プラン（やることと理由）とスケジュール（いつやるか）が混同されています。さらに、プランが破綻することなくスコープの変更に対応する明確な方法も示されていません。
このガイドでは、どのツールでも活用できる7つのステップでプロジェクトプランを作成する方法をご紹介します。また、ウォーターフォール、アジャイル、マーケティング、建設の各分野における例も掲載しています。さらに、プランが実際に保存される場所（スプレッドシート、共有ドキュメント、専用のPMツール）を並べて比較します。
要約
プロジェクト計画書とは、範囲、スケジュール、リソースを、チームが行動の指針として活用できるベースラインへと落とし込む文書です。優れたプランでは、計画策定とスケジューリングを明確に区別しています。あらゆる変更をそのベースラインに基づいて行い、各マイルストーンごとにレビューが行われます。
このガイドでは、スコープが変更されたり、依存関係が崩れたり、担当者が他の仕事に振り分けられたりしても、計画が崩れないように構築する方法をご紹介します。
プロジェクトプランとは？
プロジェクト計画書とは、プロジェクトの実施、進捗管理、および終了までの流れをまとめた正式な文書です。これには、範囲、スケジュール、リソース、リスク、およびコミュニケーション手順が盛り込まれており、実行開始後はチームが仕事を進める上での基準となります。
プロジェクトプランとは何か、その定義
プロジェクト計画書はプロジェクト憲章とは異なります。憲章はプロジェクトを承認し、プロジェクトマネージャーに権限を付与するものです。それは「このプロジェクトをやるべきか、誰が責任者か」という問いに答えるものです。一方、プランは憲章で扱われなかった部分を引き継ぎ、「どのように、いつ、誰が、どのくらいのコストで」という問いに答えるものです。
また、プロジェクトプランはスコープステートメントとは異なります。スコープステートメントは、プロジェクトが何を成果物として提供し、何を提供しないかを定義するものです。つまり、「完了」とはどのような状態かを示すものです。一方、プロジェクトプランは、スコープステートメントに加え、スケジュール、リソース、リスク、コミュニケーション、変更管理についても網羅しています。これは、チームがどのように目標を達成するか、誰が何を担当するか、そして何か変更が生じた場合にどう対応するかを示すものです。
プロジェクトプランの5つのフェーズ
プロジェクト計画には、プロジェクト管理協会（PMI）がプロジェクトライフサイクルとして定義する5つのフェーズ、すなわち「開始（イニシエーション）」「計画」「実行」「監視・管理」「終了」が含まれます。
- I. 立ち上げ： プロジェクトの目的を明確にし、ステークホルダーを特定し、プロジェクト憲章の承認を得ます。この段階ではプランはまだ存在しませんが、作成するための条件は整っています。
- 計画策定： スコープ、スケジュール、リソースプラン、リスク登録簿、およびコミュニケーションプランを策定します。このガイドの残りの部分では、このフェーズについて解説します。
- 実行： チームが実際に仕事をやります。プランは、誰が、何を、いつやるかについての指針となる文書となります。
- 進捗の監視と管理： ベースラインに対して進捗状況を追跡します。すべての変更依頼は、プランで定義した変更管理プロセスを通じて処理してください。
- 完了： 成果物が承認されたことを確認し、得られた教訓を文書化し、チームを解散させます。プランは削除せず、アーカイブします。次回の同様のプロジェクトでは、白紙の状態から始めるのではなく、このプランを基に開始します。
プランそのものは「計画」フェーズに属しますが、実行および監視のフェーズを通じて継続的に活用されます。「計画」フェーズの終了とともに閉じた状態になってしまうプランは、早期に放棄されてしまうものです。
プロジェクトプランはなぜ重要なのでしょうか？
プランを省略すると、同じ問題が繰り返し発生してしまいます。範囲の拡大（スコープクリープ）は、誰も境界線を明確に定義しなかったために起こり、リソースの競合は、2つのワークストリームが同じエンジニアを要求したために生じ、納期遅れは、隠れた依存関係が後になって明らかになったために発生します。
プロジェクトプランは、実行開始前に仕事の内容を可視化することで、そうした失敗を防ぎます。
- ステークホルダー間の認識の統一。スポンサー、チームリーダー、および貢献者は、仕事開始前に「成功とは何か」について合意を形成します。プランがなければ、各人が「完了」の定義をわずかに異なって解釈して仕事をすることになります。
- 依存関係の可視性。プランにより、どのタスクが他のタスクの進行を妨げているかが明らかになります。これにより、プロジェクトの途中で停滞を招く「あなたが私の作業を待っているとは知らなかった」といった問題を未然に防ぐことができます。
- 現実的な リソース配分。これにより、チームは利用可能な人員と予算を実際のスコープに合わせざるを得なくなります。修正に多額の費用がかかるプロジェクトの途中で、ギャップに気づくようなことはもうありません。
- 意思決定の質向上。新たな要望が寄せられた際、プランはトレードオフを評価するための基準となります。その基準がなければ、どの要望も同様に緊急に感じられてしまいます。
- マイクロマネジメントなしの責任体制。役割、所有者、期限を文書化しておけば、進捗状況を逐一確認しなくても進捗を追跡できます。
PMIのレポート『プロジェクトの成功を最大化するには』によると、成功基準を事前に定義し、確立された成果測定システムを導入しているプロジェクトは、成功率が約2倍高いことが明らかになりました。
プランは「ベースライン」であり、「青写真」ではない
多くのプロジェクト管理者は、プランを単なる成果物として扱っています。ステークホルダーに何を作るかを示すために作成し、やむを得ない場合のみ更新するのです。その結果、プランは「その時点の状況の写し」にとどまり、意思決定のツールとしては機能しません。
プロジェクト計画の真の役割は、将来が予想とは異なる展開になった際に、それに立ち向かうための具体的な指針を提供することにあります。スコープ変更の要請は、単なる「感覚」ではなく、ベースラインに基づいて評価されます。タイムラインの遅れは、記憶ではなく、プランに基づいて測定されます。成功するプランとは、各マイルストーンごとに更新されるプランなのです。
ここから2つのルールが導き出され、このガイドの残りの部分はそれらに基づいて構成されています：
- まずはプラン、その次にスケジュール。 プランとは、やることと、なぜやるかを決めることです。スケジュールとは、いつやるかを決めることです。これらを混同すると、タイムラインがスコープを左右するようになってしまいます。
- 各マイルストーンごとに見直しを行う。 1週目に作成して、8週目になっても手付かずのままのプランは、誤った自信を与えてしまいます。チームが正確な情報に基づいて仕事ができるよう、意図的にプランを更新しましょう。
このアプローチは、フライヴビェルグが楽観バイアスと呼んだ現象に対処するものです。これは、計画立案者がコスト、タイムライン、リスクを過小評価し、一方で便益を過大評価してしまうという体系的な傾向を指します。静的な予測として作成されたプランは、当初からそのバイアスを引き継ぎ、決してそれを是正することはありません。
プロジェクトプランの主要な構成要素
プロジェクトプランは、大まかなものであれ、極めて詳細なものであれ、すべて同じ中核となる構成要素に基づいています。以下のリストでは、それぞれの構成要素と、そこで扱うべき内容について解説します。
- プロジェクトの範囲定義書。 プロジェクトの範囲：対象となる内容、明示的に除外される内容、および完了する基準
- 目標と成功メトリクス。プロジェクトが達成すべき具体的かつ測定可能な成果（「顧客体験の向上」のような曖昧な目標ではない）
- 作業分解構成（WBS）。 すべての成果物を、管理しやすいタスクおよびサブタスクに構造化します。
- スケジュールとマイルストーン。主要な日程、フェーズゲート、および最も早い完了時期を決定するクリティカルパスを含むタイムライン
- リソースプラン。 誰がどの業務を担当し、どの程度のキャパシティで、どのようなツールや予算が必要か
- リスク登録簿。 特定されたリスク、その発生確率と影響、および各リスクに対する軽減策または緊急時対応策
- コミュニケーションプラン。 誰に、どのくらいの頻度で、どのようなチャネルを通じて情報を共有するか、またどのようなトリガーがエスカレーションをトリガーするか
- 変更管理プロセス。 ベースラインに対して、スコープの変更がどのように要求され、評価され、承認（または却下）されるか
ただし、すべてのプロジェクトにおいて、これら8つのセクションすべてを同じ詳細度で作成する必要があるわけではありません。2週間程度の社内プロジェクトであれば、いくつかのセクションを1ページにまとめることも可能です。一方、規制の厳しい業界のプロジェクト、例えば製薬業界のコンプライアンス対策などでは、各セクションを個別のサブドキュメントとして展開し、正式な承認プロセスを設ける必要がある場合もあります。
7つのステップでプロジェクトプランを作成する方法
これらの7つのステップは、ウォーターフォール、アジャイル、ハイブリッドなど、どの手法を採用していても有効です。各ステップは次のステップへとつながっているため、順序が重要です。手順を飛ばすと、最初から適切にプランするよりもコストのかかる手戻りが発生してしまいます。
ステップ1：目標を明確にし、ステークホルダーを特定する
まずは目標から始めましょう。プラン立案において最もよくある間違いは、「成功とはどのような状態か」という問いへの答えを出す前に、いきなり「何をやること」なのかという段階に飛びついてしまうことです。各目標を、測定可能な成果と期限に結びつけましょう。
例えば、「ウェブサイトの再設計」はタスクです。「第3四半期までに価格ページのコンバージョン率を15％向上させる」というのは、その後のあらゆる意思決定の形となる目標です。
次に、プロジェクトに対して権限や影響力を持つ人、あるいはプロジェクトに依存関係がある人をすべてリストアップします。それらを役割ごとに分類しましょう。スポンサーは予算や範囲の変更を承認し、貢献者は仕事を行い、情報提供を受ける当事者は最新情報の提供を必要としますが、意思決定は行いません。シンプルなステークホルダーマップを作成すれば、これらを整理しておくことができます。
| 名前 | 役割 | 権限レベル | 更新頻度 |
| プロダクト担当副社長 | スポンサー | スコープの変更や予算を承認する | 隔週 |
| 主任エンジニア | 貢献者 | スコープ内の技術的な決定事項 | 毎週 |
| 法務顧問 | 参照 | コンプライアンス要件を確認します | マイルストーンにおいて |
| 営業部長 | 情報に基づいた | 意思決定権限なし | 月次要約 |
ステップ2：プロジェクトの範囲と成果物を設定する
スコープとは境界線です。その範囲内にあるものはすべてリソースが割り当てられ、スケジュールが組まれます。範囲外にあるものは、明示的に先送りされるか、却下されます。2列構成の「スコープ内／スコープ外」リストを作成することで、後々スコープクリープを引き起こす曖昧さを防ぐことができます。
プロジェクトの成果物とタスクを区別しましょう。成果物とは、ステークホルダーが受け取る具体的な成果物のことで、「移行済みのデータベース」、「承認済みのデザインモックアップ」、「公開済みのAPIドキュメント」などが挙げられます。一方、タスクとは、成果物を生み出すために必要な仕事のことです。ステークホルダーは成果物を重視し、チームはタスクを重視するため、この区別は重要です。
スコープに関する最もよくある失敗とは？ 範囲をあまりにも広範囲に定義しすぎてしまい、追加要求に対して「ノー」と言えなくなってしまうことです。
「ユーザーエクスペリエンスを向上させる」という言葉は、何を意味するかわかりません。「タブレット向けのレイアウトや支払いプロバイダーの変更を除き、モバイルブラウザ向けのチェックアウトフローを再設計する」と明記しておけば、プロジェクトの途中でタブレットサポートを要求された際に、その理由を明確に示して断ることができます。
ステップ3：作業分解構成（WBS）を作成する
ステップ2で特定した各成果物を、個別に割り当て、工数を算定し、進捗を追跡できる最小単位のタスクに分解します。この「プロジェクト → 成果物 → 作業パッケージ → タスク」という階層構造が、作業分解構造（WBS）となります。
役立つ経験則として、タスクに数日以上かかる場合は、おそらくさらに細分化できる確率が高いです。
WBSは、スケジュールおよびリソースプランの基盤となります。これが不完全だと、その後のすべての工程の信頼性が損なわれます。仕事を見落としてしまうと、タイムラインが狂い、リソースプランにも穴が生じてしまいます。
例えば、ClickUpでは次のような感じになります：
ステップ4：プロジェクトのスケジュールとマイルストーンを作成する
WBSのタスクを取り上げ、その順序を整理しましょう。どのタスクが他のタスクの完了を待たなければならないか（依存関係）、どのタスクを並行して実行できるかを検討します。
プロジェクトのマイルストーンは、主要なフェーズや成果物の完了を示すものです。これらは「設計フェーズ完了」や「UATの承認取得」といったチェックポイントとなります。これらを活用して、ステークホルダーとの自然なレビューの機会を設けましょう。複雑なプロジェクトでは、スケジュールをガントチャートで可視化し、依存関係やクリティカルパスを明確にしましょう。
現実的な不確定要素に備えて、スケジュールに余裕を持たせておきましょう。そして、プレッシャーが高まった際に削減されがちな「最終段階の一括的な余裕」としてではなく、各フェーズ、特にテストやレビューの段階に余裕を設けておきましょう。
ステップ5：役割の割り当てとリソースの配分
WBSの各タスクを、特定の所有者に割り当ててください。所有者が複数いる場合は、実質的に所有者がいないのと同じです。リソースの割り当てとは、割り当てられた担当者が、予定された期間内にその業務を遂行できるキャパシティがあることを確認することを意味します。
ここで、プランと現実が衝突します。主任開発者が同時に3つのプロジェクトに割り当てられている可能性もあります。プランがあれば、納期遅延を引き起こす前に、そうした矛盾を表面化させることができます。
RACIフレームワーク（Responsible、Accountable、Consulted、Informed）を活用すれば、過剰な文書化をせずに、誰が何を担当するかを明確にすることができます。プロジェクトで新しいソフトウェアや外部業者が必要となる場合は、プランとともにその承認も得られます。
ステップ6：リスクを評価し、コミュニケーションプランを立てる
何が問題になり得るかを特定し、各リスクの発生確率と影響を評価した上で、それぞれに対する対応策を文書化します。
一般的なプロジェクトリスクをリスク登録簿に記録し、可視性を高め、責任の所在を明確にしてください。以下に例を示します。
| リスク | 可能性 | 効果 | リスク軽減戦略 | 所有者 |
| プロジェクトの途中でリード開発者が離脱した | Medium | 高 | 重要なモジュールについて、別のエンジニアにクロストレーニングを行う | エンジニアリングマネージャー |
| ベンダーによるAPIの納品が2週間遅れた | 高 | Medium | 統合フェーズには2週間の余裕を設けてください | プロジェクトマネージャー |
| 設計段階終了後にスコープの変更が要求された場合 | 高 | 高 | 変更依頼のプロセスを事前に定義しておく | スポンサー |
| 第3四半期の予算を15％削減 | 低 | 高 | 先送り可能な成果物を事前に特定する | プロジェクト管理マネージャー |
プロのヒント： ステータス報告の頻度や手段（例：毎週のStandUpミーティングや隔週の書面レポート作成など）を明確に定義しましょう。また、報告の受け手や、エスカレーションのトリガーとなる条件もリストアップしてください。プロジェクトのコミュニケーションプランを策定することで、「誰かが伝えてくれただろう」という誤解を防ぐことができます。
ステップ7：ステークホルダーの承認を得て、ベースラインを設定する
プランは、スポンサーおよび主要なステークホルダーが正式に承認するまで確定しません。この承認によって、プロジェクトのベースラインが確立されます。ベースラインとは、合意された範囲、スケジュール、予算のことであり、これに基づいて今後のすべての変更が評価されます。
ベースラインがなければ、正当な変更と当初の合意内容を区別する方法はありません。
一度策定された後は、範囲、タイムライン、予算に変更が生じた場合は、プランで定義した変更管理プロセスに従って対応します。承認されたプランは、すべてのステークホルダーと共有してください。常にアクセス可能な、バージョン管理された共有場所に保存し、3ヶ月前の電子メールのスレッドの中に埋もれてしまわないようにしてください。
ベースラインが設定されたからといって、プランが固定化されるわけではありません。それは、変更が意図的なものであり、文書化されていることを意味します。誰かが「この機能を追加できませんか？」といった変更依頼を提出した際には、それをベースラインと照らし合わせ、コスト、スケジュールへの影響、およびトレードオフの可視性を持って、関係者全員で協議して決定します。
プロジェクト計画がスプレッドシート、チャット、電子メールなどに散在している状態では、それは「システム」ではなく「障害」です。プロジェクト管理データベースを使えば、すべてを構造化され、検索可能な一箇所に集約できます。プロジェクトが1つであっても複数であっても、このガイドでは、仕事の整合性を保ち、進捗状況を可視化するデータベースの構築方法をご紹介します。
プロジェクトプランの例
以下の例では、同じ中核となる構成要素が、さまざまな状況に応じてどのように適応されるかを示しています。それぞれについて、その構造、特徴、および使用すべき場面を説明しています。
ウォーターフォール型プロジェクトプランの例
ウォーターフォール型プランでは、要件定義、設計、構築、テスト、導入という順序で進められます。各フェーズは正式なゲートで終了します。ステークホルダーが仕事をレビューし、次のフェーズを承認します。前のフェーズが承認されるまで、次のフェーズには進みません。
サンプル手順：
- 要件ドキュメント（スポンサーによる承認済み）
- 設計フェーズ、その後、設計レビューのゲート
- 構築フェーズ、その後コードレビューのゲート
- テストフェーズ（ユニットテスト、統合テスト、UAT）、その後QA承認ゲート
- 展開後、ローンチ後のレビューを実施する
特徴： 要件定義の段階でプロジェクトの全範囲が確定します。ガントチャートが主要な成果物であり、各フェーズが時系列で示されます。変更依頼は正式な手続きが必要で、コストもかかります。ウォーターフォール型は、柔軟性を犠牲にして予測可能性を重視します。
最適な対象： 要件、規則、規制が固定されているプロジェクト、または範囲が明確に定められている必要がある外部チーム。政府契約、コンプライアンス仕事、製造分野に適しています。
次のような場合は不向きです： キックオフの段階で「完了」の定義を高い確信を持って定められない場合。理解していない範囲を固定してしまうことは、反復作業を行うよりもコストがかかります。
アジャイルプロジェクトプランの例
アジャイルプランでは、プロダクトビジョン、優先順位付けされたバックログ、スプリントのペース（通常は2週間）、およびチームの役割を設定します。詳細なプランは、スプリントを重ねるごとに具体化されていきます。チームは各スプリントから学び、調整を重ねていきます。
サンプル手順：
- プロダクトビジョンと成功メトリクス（キックオフ時にドキュメントに確定）
- 優先順位付けされたバックログ（毎週精査）
- スプリント1のプラン：ストーリー、所有者、キャパシティチェック
- スプリント1のレトロスペクティブを行い、バックログの優先順位を見直します
- スプリント2のプラン…
このアプローチの特徴： プランは、次のスプリント以降のスコープを固定しません。ステークホルダーには、スプリントごとの成果物リストではなく、四半期ごとの「テーマ」のロードマップが提示されます。レトロスペクティブこそがフィードバックループです。これがなければ、アジャイルは余計なステップを伴うスコープクリープに陥ってしまいます。
適しているケース： 要件が変化したり、顧客のフィードバックが仕事の進め方を左右したり、チームが小規模なバッチ単位で成果物をリリースするプロジェクト。アジャイルは、ソフトウェア、プロダクトデザイン、社内ツールなどの分野で広く採用されています。
以下の場合はスキップしてください： ステークホルダーが、事前に固定されたスコープと納期を求めている場合。契約内容が厳格な場合、アジャイルの柔軟性はかえって足かせとなります。
マーケティングキャンペーンのプロジェクトプランの例
マルチチャネル・マーケティング・キャンペーンでは、コンテンツ、有料メディア、電子メール、イベントを統合します。レビューサイクルを経てクリエイティブな成果物を制作し、外部ベンダー（代理店、フリーランサー）との調整を行い、すべてのチャネルを1つのローンチ日に合わせて展開します。
サンプル手順：
- キャンペーン概要：目的、対象者、メッセージ、KPI（キックオフ時点で確定）
- 成果物、所有者、レビュー日程を記載したコンテンツカレンダー
- ローンチ日を起点として逆算した、各チャネル（コンテンツ、有料広告、電子メール、イベント）ごとのタイムライン
- アセットごとのクリエイティブ審査および承認プロセス
- ローンチ当日、そしてキャンペーン終了後の実績評価
この手法の特徴： マーケティングプランには、意思決定権を持つ人よりも、意見を持つステークホルダーの方が多く存在します。明確な承認ワークフローがなければ、すべての成果物が5回もの編集を繰り返すことになり、リリース日が遅れてしまいます。ここでは、RACIマトリックスは単なるオプションではありません。リリース日を守るための必須要素なのです。
もう一つの顕著なリスク： 各チャネルは同じ日付に集約されますが、リードタイムはそれぞれ異なります。印刷物には6週間、有料ソーシャルメディアには2週間、電子メールには1週間かかります。ローンチから逆算するのではなく、キックオフから順にプランを立てると、リードタイムの長いチャネルは初日からすでに遅れをとることになります。
最適な用途： 製品リリース、季節限定キャンペーン、ブランド刷新、または共有の日程で2つ以上のチャネルを通じて展開されるあらゆる仕事。
以下の場合はスキップしてください： 単一チャネルで常時稼働しているプログラム（ブログのみ、有料アカウントのみなど）を運営している場合。その場合は、コンテンツカレンダーと週次進捗確認で十分です。本格的なキャンペーンプランは、実際には活用されない無駄な負担になります。
建設プロジェクトプランの例
建設プロジェクトは、厳しい規則（許可、検査など）や、物理的な依存関係の下で進められます。骨組みが完成するまでは、電気工事を行うことはできません。
サンプル手順：
- プロジェクト憲章および許可取得のタイムライン（仕事開始前に確定済み）
- 現場の準備と基礎工事（天候次第）
- 骨組みの組み立て、そして骨組み検査のチェックポイント
- 機械、電気、配管を所定の順序で進める
- 石膏ボード工事、仕上げ工事、最終検査、引き渡し
このアプローチの特徴： 主なリスクはスコープではなく、スケジュールです。あるフェーズで遅延が生じると、その後のすべてのフェーズに影響が及びます。骨組み工事に1週間の遅れが出ると、電気工事、配管工事、空調設備工事のすべてがずれ込みます。施工プランでは、各フェーズの終了時ではなく、フェーズの途中でバッファを設けます。なぜでしょうか？ プロジェクト終了時のバッファは、常にそれ以前に遅延したステップによって食い尽くされてしまうからです。
特に適しているケース： 物理的な依存関係がある仕事、天候リスクを伴う仕事、あるいは複数の職種間の調整が必要な仕事。
以下の場合はスキップしてください： 知識労働を主に行っている場合。マーケティングキャンペーンに建設業界の分厚いゲートを流用しても、実質的な保護効果がない上に、余計な負担が増えるだけです。
次のプロジェクトを白紙の状態から始める必要はありません。ClickUpの「ハイレベルプロジェクトプランテンプレート」には、タスクのステータス、承認状況やチーム割り当てを追跡するためのカスタムフィールド、そしてタイムラインや成果物リストを含む5つの組み込みビューが備わっており、すぐに使える構造が用意されています。
プロジェクトプランはどこに保管すべきか？
手法によって仕事の順序が決まります。ツールによって、そのプランが3週目を過ぎても維持されるかどうかが決まります。選択肢は3つあります。
スプレッドシート（Google スプレッドシート、Excel）
これらは、これまでスプレッドシートを常時使用してきたチームにとって、デフォルトのツールです。タスク用、タイムライン用、リスク登録簿用と、それぞれ1枚ずつシートを用意します。誰でも編集可能です。誰かがオフラインになっても、作業が中断されることはありません。
効果的な方法
- 柔軟性。どんな構造でも数時間でモデル化できます
- フィルターとピボットは、一度設定すれば非常に強力です
- 学習曲線はほとんどありません
問題点
- 依存関係は手動で設定されます。タスクが遅延した場合は、その後のすべての期日を手作業で更新する必要があります。
- バージョン管理は、最後に保存した人が決定権を持つ
- チーム間の依存関係があるタスクが15～20件を超えると、その維持コストがプランの価値を上回ってしまいます。
最適なケース： タスク数が20未満で、所有者が1名に明確であり、ネストされた依存関係がない、単一チームによるプロジェクト。
以下の場合はスキップしてください： 2つ以上のチーム間の調整が必要な場合、またはタイムラインが週に1回以上変更される場合。
共有ドキュメント（Google ドキュメント、Notion、Confluence、ClickUp Docs）
ドキュメント形式のプランは、プランの大部分が文章で構成されている場合に有効です。具体的には、スコープステートメント、ステークホルダーマップ、成功基準、リスク登録簿などが挙げられます。タスクは、所有者や期日を明記した箇条書きのリストとして記載されます。
効果的な方法
- このプランは、データベースではなく、文書として読めるものです。ステークホルダーは実際にこのプランを開いて確認します。
- コメントやレビュー履歴はコンテンツの横に表示されます
- スコープステートメントとリスクレジスターを一箇所にまとめて管理
問題点
- リアルタイムのステータス表示はありません。誰かが手動で更新しない限り、ドキュメントには「API統合の構築：進行中」と永久に表示されたままになります。
- 依存関係の追跡やガントチャートビューがないため、プランと実際の仕事はすぐに乖離してしまいます。
最適な用途： 短期間のプロジェクト（1ヶ月未満）、説明文の多いプラン、またはタスク管理ツールの「前段階」として。範囲や関係者はドキュメント内にまとめ、タスクは別の場所に管理します。
以下の場合はスキップしてください： 今日、誰がどの作業でブロックされているかを確認する必要がある場合。
専用のPMツール（ClickUp、Asana、Jira、Monday）
タスク、依存関係、所有者、タイムラインが1つのデータモデルを共有する、専用に設計されたシステム。プランと仕事は同一のオブジェクトです。
効果的な方法
- 依存関係はリアルタイムで反映されます。タスクに遅れが生じると、後続のタスクが自動的に調整され、チームはダッシュボード上でその状況を確認できます。
- ガントチャートビューでは、手作業による修正を必要とせずにクリティカルパスを確認できます
- ステータスレポートは、チームが実際に仕事をしているデータに基づいて作成され、情報が古くなってしまうような別個のドキュメントから作成されるものではありません。
問題点
- セットアップには時間がかかります
- 2週間の社内プロジェクトであれば、カスタムステータスやフィールド、ガントチャートビューは必要ありません。
- また、リアルタイムデータのメリットを最大限に活かすためには、プランと仕事を同じツール上で管理する必要があります。
最適な対象： 複数のチームにまたがり、依存関係が変化しやすく、スコープの変更後も有効なベースラインが必要なプロジェクト。
以下の場合はスキップしてください： 所有者が1人、チームが1つ、範囲が固定されており、期間が3週間未満のシンプルなプロジェクトの場合。その場合は、ドキュメントを使った方が手っ取り早いです。
プロジェクトプランが 失敗する 6つの理由
多くのプロジェクトプランは、予想通りの理由で勢いを失ってしまいます。
1. 「ノー」と言えないほど広範なスコープを策定してしまう
スコープは、追加要求を断るための文書化された根拠となる場合にのみ有用です。スコープ文書を指して「これは範囲外です」と説明できないのであれば、そのスコープはプロジェクトを守るには曖昧すぎるのです。
すべてのスコープの境界を、検証可能な記述として明記してください。「タブレット向けのレイアウトおよび支払いプロバイダーの変更を除き、モバイルブラウザ向けのチェックアウトフローを再設計する」というのは境界の例です。「ユーザー体験を改善する」というのは境界ではありません。
2. マネージャーからの見積もりの取得
トップダウン方式による見積もりは、常に楽観的になりがちです。これは、前述の「楽観バイアス」が見積もりにも当てはまるためです。仕事を割り当てる側は、それを実行する側と比べて、ほぼ常にその仕事量を過小評価してしまいます。
実際に仕事を行う開発者こそが、どこにボトルネックがあるかを最もよく把握しています。WBSは協働で作成しましょう。そうしなければ、手戻りが発生する可能性があります。
3. すべてのバッファを最後にまとめて配置する
4か月のプロジェクトの最後に2週間の「予備期間」を設けたスケジュールは、実質的な予備期間のないスケジュールです。プレッシャーが高まると、その余裕は真っ先に削られてしまいます。
各フェーズ、特に通常は時間が消費されがちなテストやレビューの段階には、予備時間を確保しましょう。仕事の途中にあるバッファは最後まで残りますが、終了間際に設けられたバッファは、プロジェクトがそれを必要とする前に消えてしまいます。
4. 「完了」の定義を曖昧にしておく
完了基準が明確に定められていない場合、「完了」の意味はステークホルダーごとに異なってきます：
- 開発者は、コードがリリースされた時点で完了とみなします
- プロダクトマネージャーは、QAが承認した時点で完了とみなします
- クライアントは、満足したと感じた時点で完了したとみなします
各成果物について、「完了」とは何を意味するのかを明記してください。満たすべき基準、フォーマット、承認担当者を記載しましょう。基準が曖昧であることは、プロジェクトの終盤における手戻りの主な原因となります。
5. プランを電子メールの添付ファイルとして保存してしまう
誰も見つけられないプランは、実質的にプランがないのと同じです。
チームが「最新バージョンはどこにあるのか」と尋ねなければならないような状況では、意思決定の際にそれを参照したり、情報が古くなっていることに気づいたり、状況の変化に応じて更新したりすることはできなくなります。
プランはチームが仕事をする場所に保存し、バージョン管理を行い、対象となるタスクとリンクさせておきましょう。プランは、どのチームメンバーのワークスペースからも2クリックでアクセスできる場所に配置してください。
6. プランを「一度きりの成果物」として扱う
最も明らかな兆候は、プランの最終更新日が、追加した最新のタスクの日付よりも古いことです。仕事が動いているのにプランが追いついていない場合、プランはすでにしばらく前からプロジェクトを適切に管理できておらず、誰もそれに気づいていないということです。
各マイルストーンや、変更依頼が承認されるたびに、15分間のプラン見直し時間を確保しましょう。その目的は、プランをゼロから書き直すことではありません。ベースラインが依然として現状を反映しているかを確認し、そうでない場合はその点を記録することです。
ClickUpでのプロジェクトプランの作成と管理方法
私たちは、Google Docでプロジェクトプランを作成して、あとはうまくいくことを願うだけ、といったことはしません。私たちのプランは、ClickUp内に、そのプランで説明されている仕事のすぐ隣に保存されています。そうすることで、プランが古くなることはありません。
スコープに関するドキュメントとステークホルダーマップ（ステップ1および2）
ClickUp Docsには、スコープステートメント、成功メトリクス、ステークホルダーテーブルが保存されています。このドキュメントはタスクと同じワークスペース内に存在するため、「これはスコープ内か？」という質問にも簡単に答えられます。誰かが変更を提案した際には、3ヶ月前のGoogle Docではなく、スポンサーが承認した同じドキュメントを提示します。
WBSのタスクとサブタスク（ステップ3）
依存関係とクリティカルパスを確認するためのガントチャートビュー（ステップ4）
<14>ClickUpのガントチャートビューでタスク間に線を引いて、依存関係を設定します。クリティカルパスが可視化し、あるタスクが遅延すると、下流のタスクもそれに合わせて自動的に調整されます。手作業でスケジュールを再構築することなく、現実的なスケジュールを維持できます。これはスプレッドシートでは最も早く破綻してしまう部分であり、PMツールが重宝される理由でもあります。
ベースライン用ダッシュボード（ステップ7）
スポンサーがプランを承認すると、ClickUpのダッシュボードが、完了率、期限切れのタスク、作業負荷に関するリアルタイムデータを表示します。「現在のステータスは？」という疑問に対する答えは、チームが実際に作業しているデータそのものから得られ、別途作成された進捗報告書ではありません。ステークホルダーは、進捗ミーティングを要請する代わりに、ダッシュボードを確認するようになります。
ClickUpが適していない場合
ClickUpは、複数の人が関わり、タイムラインが変動し、部門横断的な引き継ぎが発生するプロジェクトにおいて、その真価を発揮します。仕事の連携が必要となる度合いが高ければ高いほど、より大きな価値を得ることができます。
以下の場合はスキップしてください： 少数の成果物を追跡するフリーランサーの方、あるいは複雑な財務モデルやピボットテーブルを必要とするチームの方。その場合は、シンプルなドキュメントやスプレッドシートの方が適しています。
RevPartnersがプラン策定時間を83%短縮した方法
リモートでのクライアント対応を管理するHubSpotソリューションエージェンシーであるRevPartnersは、成長中のサービスチームが直面する典型的な問題に遭遇しました。それは、5社のクライアントでは機能していたプロジェクト計画が、15社になると機能しなくなったというものです。チームはNotion、Trello、Asanaを併用していましたが、スコープ、担当責任者、そして「完了」の定義について、一元的に把握できる情報源がありませんでした。
彼らはデリバリー・プレイブックをClickUpテンプレートとして再構築したため、新規クライアントとの契約開始時には、白紙のドキュメントからではなく、ベースラインとなるプランから作業を開始できるようになりました。プロジェクト計画に要する時間は、1プロジェクトあたり30分から5分へと83％短縮され、サービス提供全体のスピードも64％向上しました。
RevPartnersの共同創業者であるマット・ボリアン氏は、この変化について次のように述べています：
「私はプロジェクト管理ツールが大好きです。それらは組織のライフサイクル全体にとって不可欠なものです。私がこれまで使用した3つのプラットフォームの中から1つを選ばなければならないとしたら、何度でもClickUpを選びます。」
「私はプロジェクト管理ツールが大好きです。それらは組織のライフサイクル全体にとって不可欠なものです。私がこれまで使用した3つのプラットフォームの中から1つを選ばなければならないとしたら、何度でもClickUpを選びます。」
チームが実際に活用できるプロジェクトプランを策定する
プロジェクトプランは、すべての成果物、所有者、依存関係、リスクを一か所にまとめて全体像を把握して初めて機能します。また、最初のマイルストーンに到達する頃には忘れ去られてしまうのではなく、仕事中に常に参照されるものでなければなりません。
数百件に及ぶプロジェクトを通じて、確実に成果を出し続けているチームは、プランを「生き物のような文書」として扱っています。彼らは各マイルストーンごとにプランを見直し、条件の変化に応じて前提条件を更新し、スコープの変更依頼はすべて、文書化された変更プロセスを通じて処理しています。これこそが、プロジェクトを順調に進める秘訣なのです。
チームの規模が拡大し、共有ドキュメントや基本的なスプレッドシートでは対応しきれなくなってきた場合は、ClickUpのようなツールを試してみる価値があります。スコープ、タスク、依存関係、所有者、ダッシュボードを1か所にまとめ、プランの進展に合わせてビューが自動的に同期されます。
今すぐClickUpに登録しましょう！
プロジェクトプランに関するよくある質問
プロジェクトプランとプロジェクト管理プランの違いは何ですか？
プロジェクトプランは、単一のプロジェクトにおける具体的な成果物、スケジュール、およびリソースに焦点を当てたものです。一方、プロジェクト管理プラン（PMIの用語）はより広範な概念であり、プロジェクトの管理方法を規定する変更管理、リスク管理、コミュニケーション、調達といった補助計画を含みます。正式なPMI環境外のほとんどのチームにとって、「プロジェクトプラン」という言葉はこれら両方を指します。
プロジェクト管理ソフトを使わずにプロジェクトプランを作成することは可能でしょうか？
はい、担当者が1人で、タスクが20件未満程度の短期プロジェクトであれば可能です。スコープステートメント、ステークホルダーリスト、所有者と期日をまとめた簡単なテーブルを記載した共有ドキュメントは、PMツールを設定するよりも手っ取り早く作成できます。分岐点は通常、チーム間の依存関係です。2つ以上のチームが連携する必要がある場合、スプレッドシートでは正確性が保てなくなってきます。
プロジェクトプランにおけるクリティカルパスとは何ですか？
クリティカルパスとは、スケジュールの中で相互に依存関係にあるタスクが連なる最も長い連鎖のことで、プロジェクトの最も早い完了日を決定づけるものです。クリティカルパス上のタスクに遅延が生じると、プロジェクト全体が遅延します。一方、クリティカルパス以外のタスクでの遅延は、フロートによって吸収される可能性があります。ガントチャートはクリティカルパスを可視化するため、プロジェクトマネージャーはどの遅延が実際に重要で、どれが重要でないかを把握することができます。
プロジェクト計画書の作成は誰の責任ですか？
プロジェクトマネージャーはプランの責任者ですが、それを一人で作成すべきではありません。各分野の専門家がタスクの見積もりを提供し、スポンサーが範囲と予算を承認し、貢献者が依存関係を検証します。実際に仕事を行う人々の意見を取り入れずに作成されたトップダウン型のプランでは、常に努力が過小評価されがちです。これは、ベント・フライヴビェルグ氏の研究が数千件のプロジェクトにわたって実証している傾向です。
プロジェクトプランとプロジェクトスケジュールの違いは何ですか？
プロジェクトプランでは、何をやるか、誰が担当するか、費用はいくらか、そしてリスクをどのように管理するかを定義します。プロジェクトスケジュールは、タスクがいつ、どのような順序で行われるかを示す、プランの一要素です。この2つを混同すると、本来あるべき「スコープがスケジュールを決定する」という関係が逆転し、タイムラインがスコープを左右することになってしまいます。これは、計画策定における最も一般的な失敗例の一つです。
プロジェクトプランはどのくらいの頻度で更新すべきでしょうか？
プロジェクト計画は、主要なマイルストーンのたびに、また変更依頼が承認されるたびに更新する必要があります。第3ヶ月時点で第1週の想定を反映したままのプランは、誤った安心感を与えてしまいます。PMIは、各フェーズゲートでの正式なプランレビューを推奨しており、リスクが顕在化した場合や、変更管理プロセスを通じてスコープの変更が承認された場合には、臨機応変に更新を行うことを推奨しています。