正直なところ、プロジェクト計画書の作成って、めんどくさくないですか？
「プロジェクト計画書を書いてください」そう言われて、
- 何を書けばいいかわからない
- そもそも計画ってそんなに必要？
- とりあえずそれっぽい資料を出せばいいんじゃない？
と思ったこと、ありますよね。自分も昔はそう思ってました。
ただ、いくつか炎上プロジェクトを経験してから考えが変わりました。だいたいの失敗プロジェクトでは、計画書があるものの計画が適当だったり、そもそも計画書自体がないケースも多かったのです。
プロジェクト計画書は、ただの提出物ではなく、プロジェクトを成功に導くツールです。
この記事では、その理由と使い方をこれからPMを担う方向けに解説していきます。
この記事でわかること
- なぜプロジェクト計画書を作る必要があるのか
- プロジェクト計画書には何を書けばいいのか
- プロジェクト計画書をどうやって作ればいいのか
そもそも「プロジェクト」って何だっけ？
少々回りくどいですが、「そもそもプロジェクトとは？」から解説します。
プロジェクトはちょっと特殊な業務です。何が特殊かというと、次の2点です。
プロジェクトの特殊性
- 有期性：終わりがある
- 独自性：基本的に初めてやること
このように、普段の定常業務と違って、プロジェクトは「期限付きの不確実性の高い仕事」です。（不確実性＝将来起こる出来事やその結果を正確に予測することが困難な状態）
この「不確実性が高い」というところが厄介で、要は「こうすれば絶対成功できる」というものがなく、やりながら最適解を探っていく必要があります。
でも、行き当たりばったりではもちろん失敗してしまいます。その失敗確率を下げるために、あらかじめプロジェクト計画書を作って「不確実性」に備えるのです。
なぜプロジェクト計画書を作るのか？
プロジェクトのもつ「不確実性」に備えるためにプロジェクト計画書を作ればいいと言われても、ちょっと抽象度が高くてわかりにくいですよね。
ここでは、もう一段踏み込んで「プロジェクト計画書を作る理由＝目的」を解説していきます。
ズバリ、プロジェクト計画書を作る目的は次の2つです。
プロジェクト計画書を作る目的
- プロジェクト全体の見通しを立てるため
- プロジェクトに関わる人を動かすため
順番に解説します。
プロジェクト全体の見通しを立てるため
プロジェクトは「不確実性」が高いとお伝えしました。つまり、将来起こることが予測困難であるということです。
なので、その対策として「将来どんなことが起こりそうか？」「それをどうやって乗り越えていけばいいのか？」をあらかじめ考えて可視化します。
例えば、こんなことを考えて可視化します。
- 何のためにやるのか
- 何をやるのか
- 誰とやるのか
- どういう順番で進めるか
- リスクはどこにありそうか
これらをプロジェクトの最初期に考えて可視化します。別に完璧である必要はありません。あくまでプロジェクト全体の「見通し」が立てば良いのです。
こうすることで、少しでもプロジェクトのもつ「不確実性」を低減させます。
プロジェクトに関わる人を動かすため
プロジェクト全体の見通しが立てば、それだけで成功するのか？というと、残念ながらそうではありません。
プロジェクトを前に進めるには、計画だけでなく、人やカネといったリソースが必要です。そして、リソースを集めたり、集めたリソースを動かしたりするには、多くの人の協力が欠かせません。
例えば、プロジェクトには次のような人たちが関わります。
- プロジェクトメンバー
- マネジメント層
- 他部署
- 開発ベンダー
たとえば、計画を実行するためのメンバーをアサインしてもらうには、マネジメント層の合意が必要です。人事権を持っているのは彼らだからです。
このとき、ただ「プロジェクトやるので人をアサインしてください！」とお願いするのと、
「こういう目的でプロジェクトをやりたいです。計画はこれで、必要工数はこれくらいです。なのでこの期間、1名アサインしてください」
と説明した上でお願いするのとでは、成功率は雲泥の差でしょう。
このように、関係者を動かし、プロジェクトを前進させるためにも、計画書は非常に重要なツールになります。
プロジェクト計画書とは何か？
ここまででプロジェクト計画書の必要性をお伝えしてきましたが、では、そもそもプロジェクト計画書の実態は何なのか？を解説していきます。
ざっくり言うと、プロジェクト計画書とは「プロジェクトの段取りを書いたもの」です。
「プロジェクトをこんな感じで進めようと思っています」という段取りが書かれたドキュメントのことを、プロジェクト計画書と呼んでいます。
一般的には、以下のような項目を書きます。
プロジェクト計画の項目
- 背景・目的・目標
- 前提
- プロジェクト方針
- スコープ
- 課題と対応方針
- ゴールイメージ
- 対応STEP
- 体制
- スケジュール
- リスクと対応策
「こんなに書くのか…」と、すでにめんどくさくなったかもしれませんが、そんなに心配する必要はありません。プロジェクトの最初期に作るドキュメントなので、すべてが完璧に書かれている必要は実はないのです。
プロジェクトの不確実性を少しでも下げるために、「現時点で考えられる」計画を可視化できていれば十分です。後続に進んでみないとわからないこともあると思います。ただ、そのことが分かっただけでも、不確実性を下げられたと言えます。
そういったことは「後続で検討する」とタスクとして計画しておけば良いだけのことです。
ちなみに、似たようなドキュメントで「企画書」というものがあります。混同されがちなのですが、次のような違いがあります。
- 計画書：プロジェクトの段取りを書いたもの
- 企画書：計画に沿って作業をした結果、作られる成果物
計画書には「進め方」に関する内容が書かれており、企画書には「何をやるか」が書かれているイメージです。
プロジェクト計画書の作り方
ここからは、実際にプロジェクト計画書の作り方を解説します。といっても、ポイントを押さえればスムーズに作成できます。
プロジェクト計画書作成のポイント
- フォーマット通りに作る
- 決まってないことがあってもいい
まず、プロジェクト計画書には決まった型があります。なので、それに沿って作れば抜け漏れなく作れます。プロジェクト開始時に決めなければいけないことは、どのプロジェクトもそんなに変わりません。
よければ、こちらのフォーマットを活用してください！
また、プロジェクト計画書はプロジェクトの開始時点で作成します。なので、未決定事項があって当然です。まだ決まってないことは「後で決める」と書き、検討のタスクを計画しておけば問題ありません。完璧を求める必要はないのです。
では、順を追って解説していきます。
プロジェクト名を決める
まず最初に、プロジェクト名を決めます。
すでに仮称でプロジェクト名が付いているケースも多いと思います。ただ、「名は体を表す」という言葉の通り、プロジェクト名は思っている以上に重要です。プロジェクト名は、関係者全員が最初に触れる「共通言語」だからです。
もし、次のような名前が付いていたら、このタイミングで一度立ち止まって再検討することをおすすめします。
NGなプロジェクト名
- プロジェクトフェニックス
- 業務効率化プロジェクト
- AI導入プロジェクト
それぞれ理由を補足します。
「プロジェクトフェニックス」は、名前からプロジェクトの中身がまったく想像できません。「業務効率化」も、どの業務を対象にしているのかが分からず、非常に曖昧です。「AI導入」は、本来は手段であるはずの技術が目的になってしまっています。
このような名前だと、関係者ごとにプロジェクトの理解がズレやすくなります。そのズレが積み重なると、後々の認識齟齬や手戻りにつながります。
良いプロジェクト名を付けるためには、次のポイントを意識すると効果的です。
プロジェクト名を決めるポイント
- 誰が見ても、ある程度内容が想像できる
- 「名詞＋動詞」でプロジェクト名を作る
まず、名前を見ただけで内容が想像できることはとても重要です。プロジェクトは関係者が多くなりがちなので、名称だけで話が通じるかどうかで、日々のコミュニケーションコストが大きく変わります。
また、「名詞＋動詞」の形で名前を付けると、「何を」「どうしたいのか」が自然と表現されます。結果として、プロジェクトの目的が名前に埋め込まれる形になります。
先ほどの例を言い換えると、こんな感じです。
- 提案プロセス効率化プロジェクト（提案プロセスを効率化したい）
- ライティング生産性向上プロジェクト（ライティングの生産性を上げたい）
プロジェクト名を見るだけで、「このプロジェクトで何をやろうとしているのか」が伝わるようになったと思います。
プロジェクト名は、単なるラベルではありません。プロジェクトの方向性を揃えるための、最初の設計だと考えておくとよいでしょう。
背景・目的・目標を決める
次に、プロジェクトの背景・目的・目標を決めます。
プロジェクト計画の段階では、未決定事項があっても問題ありません。ただし、この「背景・目的・目標」だけは例外です。ここは必ず時間をかけて整理することをおすすめします。
なぜなら、この3つはプロジェクトの土台であり、プロジェクト全体の要約でもあるからです。背景・目的・目標には、それぞれ次の役割があります。
- 背景：なぜ、このプロジェクトをやる必要があるのか
- 目的：このプロジェクトで何を実現したいのか
- 目標：それをどうやって測るのか
この3点を押さえることで、「なぜこのプロジェクトを立ち上げたのか」「このプロジェクトを通じて、最終的に何を目指しているのか」を端的に説明できるようになります。
逆に言うと、これを言語化できないうちは、まだプロジェクトをスタートできる状態にありません。目的が曖昧なまま走り出すと、途中の判断軸がブレてしまい、「結局、何のためのプロジェクトだったんだっけ？」という事態に陥りがちです。
だからこそ、この背景・目的・目標の整理は、プロジェクト成功の最重要ポイントです。
多少時間がかかっても構いません。ここで考え抜いた内容が、後続のスコープ、対応STEP、リスク判断など、すべての基準になります。
背景・目的・目標の具体的な整理手順については、以下の記事で詳しく解説しています。あわせて参考にしてみてください。
前提を可視化する
次に、前提事項を可視化します。なお、すべてのプロジェクトに前提があるわけではありません。前提がないプロジェクトも、もちろん存在します。
ここで整理するのは、「このプロジェクトにおいて、必ず守らなければならない条件」です。背景や目的とは違い、前提は議論の余地がない制約条件だと考えるとわかりやすいです。
具体的には、次のような内容を前提として記載します。
前提として整理するもの
- 経営・事業からの要請事項（必達の方針や指示）
- 予算や期限などの制約条件
- 法令・規約・社内ルールなどの遵守事項
ここで重要なのは、「誰が見ても反論できない事実だけを書く」という点です。
また、無理に前提をひねり出す必要もありません。明確な制約条件が存在しない場合は、「前提なし」として記載しない、という判断で問題ありません。
前提を明確にしておくことで、後から
「そんな制約があるとは聞いていない」
「それは前提条件に反している」
といった認識のズレを防ぐことができます。
地味な項目に見えますが、のちのち効いてくる項目です。しっかり整理しておきましょう。
プロジェクト方針を決める
次にプロジェクト方針を可視化します。
ここで定めるべき方針は「進め方の方針」です。なので、「このプロジェクトはこういう方針で進めます」ということを可視化します。
ここはプロジェクトの特性によって様々ですが、例としていくつか挙げておきます。
プロジェクト方針の例
- 予算が少ない場合：最低限の機能のみを実装し、それ以外は後続開発に回す方針
- AI導入の場合：アジャイル開発を前提に、段階的に性能改善する方針
- 大規模の場合：3フェーズに分割し、段階的にリリースを行う方針
このように、プロジェクトの特性を鑑みて、どのような進め方をするかを言語化します。ここもプロジェクト全体の進め方に関わるので、可能な限り最初期に作ってしまうことをおすすめします。
スコープを決める
次にスコープを決めます。
スコープを決めることは、やること・やらないことを決めるのと同義です。特に「何をやらないか」を可視化していくことは、プロジェクトを進める上で非常に重要です。
要件定義に進んだときに現場からの要望が肥大化するのは、スコープとして「やらないこと」を決めていないから、ということがよくあります。
スコープを定めるのは少しコツがいります。ポイントは「どの観点でスコープを切るか」です。例えば、次のような観点でスコープを切ることが多いです。
- 業務プロセス
- ユーザー
- システム
それぞれ、例を挙げるとこのような感じです。
- 提案業務と受注業務はプロジェクトで対応するが、リード獲得業務は対象としない
- 営業担当者は対象とするが、営業サポートは対象としない
- 受注管理システムは対象とするが、提案支援システムは対象としない
スコープをどう切るかで、プロジェクトの進めやすさは大きく変わります。どの業務やシステムを対象にすればいいか、現場をどこまで巻き込めばいいか、あるいはどこは対象外として良いかが決まってくるからです。
ここが決まっていないと、プロジェクトの後半で「あの業務はやらなくていいんでしたっけ？」のような、めんどくさい問い合わせが発生してしまいます。
このように、ちゃぶ台返しをされないように、スコープは必ず定義しておきましょう。
（後日スコープの切り方の解説記事をアップ予定）
課題と対応方針を決める
次に、課題と対応方針を決めます。
ここでは、プロジェクトで解決すべき課題と、それに対する対応方針を可視化します。
この段階で重要なのは「完璧に書くこと」ではありません。プロジェクト初期では詳細まで決めきれないのが普通なので、現時点で見えている範囲を整理できていれば十分です。
まずは課題の整理から行います。
課題は、すでに整理した「背景」を具体化したものです。背景には「なぜこのプロジェクトをやるのか」という前提や問題意識が書かれているはずなので、そこに含まれている課題を抜き出し、より具体的な形に落としていきます。
次に、それぞれの課題に対して、どのような方向性で対応するのかを記載します。ここで書くのはあくまで「方針」です。具体的なツールや仕様など、細かいソリューションまで書く必要はありません。むしろ、ここで細かく書きすぎると、手段が先行してしまうので注意が必要です。
課題と対応方針は、プロジェクト計画段階ではざっくり整理しておき、詳細は後続で詰めていきます。計画書の目的は、あくまで「プロジェクト全体の見通しを立てること」だからです。
現時点では、「どんな課題があり、それにどう向き合うのか」が見える状態になっていればOKです。細かい検討は、この後の「対応STEP」でタスクとして落とし込めば、まったく問題ありません。
ゴールイメージを決める
次にゴールイメージを決めます。
ゴールイメージとは、プロジェクトが完了した状態を可視化したものです。先の「課題と対応方針」で記載した対応方針に従ってことを進め、それが完了した状態とも言えます。
ゴールイメージの書き方はプロジェクトによって様々ですが、次のようなパターンで表現することが多いです。
ゴールイメージの記載パターン
- 完了条件をテキストで記載する
- 業務・システム等の状態を図示する
ここも現時点でのゴールイメージを記載できればよく、必要に応じて詳細化のタスクを後続に入れ込むと良いでしょう。とはいえ、まっさらで何も書けないのは問題なので、少しでも完了状態をイメージしておくことが重要です。
ゴールイメージを作成する際は、以下の項目との整合性が取れているかも確認しましょう。
- 目的
- 目標
- 対応方針
これらとズレたゴールになっている場合、プロジェクトを完了させても目的・目標が達成できないので要注意です。
対応STEPを決める
次に、対応STEPを決めます。
対応STEPは、プロジェクト計画書の中でも特に重要なセクションです。
ここでは、「どんな作業を」「どの順番で」進めるのかを可視化します。言い換えると、プロジェクトの作業の段取りを決めるパートです。
プロジェクト計画書全体が「見通しを立てるための資料」だとすると、対応STEPはその中核にあたります。ここが曖昧だと、計画書があっても結局は行き当たりばったりになってしまいます。
まずは、プロジェクト全体として必要になりそうな作業を洗い出します。この段階で、できる限り作業をイメージし切れていると、プロジェクトが始まってからの手戻りを大きく減らすことができます。
対応STEPを考えるときの基本的な考え方はシンプルです。
「今どうなっていて」「最終的にどうなりたいのか」。
この2つが見えていれば、その間を埋めるために必要な作業が、対応STEPになります。
とはいえ、「差分はわかるけど、具体的に何をすればいいかわからない」という人も多いと思います。特に、初めてのプロジェクトではなおさらです。
その場合は、ゼロから考えようとせず、一般的な進め方を型として使うのがおすすめです。たとえば、システム開発であれば、次のような流れが一般的です。
一般的な開発の流れ
- 現状分析
- 課題分析
- 要件定義
- 設計
- 開発
- UAT
- リリース
- 現場展開
この型に、今回のプロジェクトに固有の作業を足したり、不要な工程を削ったりすることで、無理のない対応STEPを作ることができます。
大まかなタスクが出揃ったら、それぞれについて「いつ実施するのか」「誰が担当するのか」も合わせて整理します。ここまで整理できてはじめて、体制やスケジュールを具体的に検討できるようになります。
なお、この段階ではタスクを細かく分解しすぎる必要はありません。詳細なWBSを作るのは後続工程で問題ありません。対応STEPでは、あくまでプロジェクト全体の流れと作業のつながりが見える状態を目指しましょう。
体制を決める
次に、体制を決めます。
ここでは、プロジェクトを進めるための体制を整理します。具体的には、プロジェクトに必要な役割を定義し、その役割を誰が担うのかを可視化します。
体制は「とりあえず人を並べる」ものではありません。スコープ・ゴールイメージ・対応STEPを踏まえて、「このプロジェクトを成立させるために、どんな役割が必要か」を考えることが重要です。
基本的には、フォーマットに用意された役割や体制図をベースに作っていきます。その上で、関係しそうなチームや関係者を洗い出し、体制図に落とし込んでいきます。
「どの業務が対象なのか」「どこまでやるのか」「どんな作業が発生するのか」が見えていれば、それに関わる人や役割も自然と見えてきます。
関係者を洗い出せたら、あとは体制図に当てはめていきます。
ここで特に重要なのが、POとPMの役割です。
- PO（プロジェクトオーナー）：プロジェクト全体の最終責任を担う人
- PM（プロジェクトマネージャー）：プロジェクトのQCD（品質・コスト・納期）を管理する責任を担う人
この2つは、プロジェクトの意思決定と推進の中核となる役割です。そのため、計画段階のこのタイミングで、少なくともPOとPMだけは確定させておくことが望ましいです。
一方で、それ以外の役割については、すべてをこの時点で決めきる必要はありません。TBD（これから決める）でも問題ありません。ただし、その場合は「誰を、いつまでに、どうやって決めるのか」を明確にするため、体制構築のタスクを「対応STEP」に書いておくことが重要です。
体制を曖昧なまま進めると、「誰が決めるのか」「誰がやるのか」が不明確になり、プロジェクトは一気に停滞します。だからこそ、計画書の段階で体制を言語化し、合意の土台を作っておくことが重要です。
スケジュールを決める
次に、スケジュールを決めます。
ここでは、「対応STEP」で整理したタスクを、時系列で可視化していきます。基本的には、すでに洗い出したタスクを順番に並べていくだけなので、作業自体はそれほど難しくありません。
このときに意識したいのは、細かく書きすぎないことです。タスクを細分化しすぎるとWBSになってしまいますが、ここで作りたいのはWBSではありません。あくまで、プロジェクト全体の見通しを共有するためのマスタスケジュールです。
「何月ごろに、どんなフェーズを進めているのか」というような全体感が掴めることを優先しましょう。
スケジュールを引くうえでの最大のポイントは、タスクの前後関係・依存関係を意識することです。
たとえば、要件定義を行うには、その前に課題分析が終わっている必要があります。このように、あるタスクが別のタスクの完了を前提としている場合、それを無視してスケジュールを組むと、必ず破綻します。
「この作業は、何が終わっていれば着手できるのか？」を一つひとつ確認しながら並べていくと、無理のないスケジュールになります。
また、可能であれば、体制検討で洗い出した役割を縦軸に置いてスケジュールを整理するのがおすすめです。「誰が、どの期間、どのフェーズに関わるのか」が一目でわかるようになり、アサインや工数感の説明もしやすくなります。
さらに、フェーズの切れ目にはチェックポイントを置いておくと効果的です。フェーズごとに振り返りやレビューのタイミングを設けておくことで、方向性のズレや遅延に早めに気づくことができます。
スケジュールは「守るためのもの」であると同時に、「見直すためのもの」でもあります。最初から完璧な計画を作ろうとするよりも、調整や見直しがしやすい形で引いておくことを意識しましょう。
リスクと対応策を決める
次に、リスクと対応策を決めます。
これまでお伝えしてきた通り、プロジェクトは不確実性の高い仕事です。言い換えると、最初から何らかのリスクを抱えた状態でスタートするものだと言えます。
だからこそ、プロジェクトの初期段階から「どんなリスクがありそうか」「それにどう備えるか」を整理しておくことが重要です。
リスク対策の目的は、リスクをゼロにすることではありません。
起こりうるリスクをあらかじめ想定し、起きたときに慌てず対応できる状態を作ることにあります。そのために、リスクを言語化・可視化しておきます。
どのようなリスクがあるかはプロジェクトによって異なりますが、次の2つは多くのプロジェクトで共通して発生しやすいリスクです。まずはここから検討するのがおすすめです。
よくあるリスク
- 遅延リスク：プロジェクトが予定通り進まず、スケジュールが遅れるリスク
- 品質リスク：成果物が期待した品質に達しないリスク
リスクを洗い出したら、それぞれに対して「どう向き合うか」を決めていきます。考え方としては、次の4つの型をベースにすると整理しやすくなります。
リスク対応の型
- リスク回避：リスクが発生しないように進め方自体を変える
- リスク低減：発生確率や影響度を下げるための対策を打つ
- リスク受容：一定のリスクは許容したうえで進める
- リスク転嫁：契約や役割分担によって、リスクを他に移す
すべてのリスクに対して重い対策を打つ必要はありません。「このリスクは回避すべきか」「ある程度は受け入れるのか」といった判断を行い、その上で具体的な対応策を記載します。
リスク対策は重要である一方、多くのプロジェクトで後回しにされがちです。また、経験が少ないと、そもそもリスクを想定すること自体が難しい場合もあります。
そのため、このフェーズでは、システム部門や過去に似たプロジェクトを経験した有識者に入ってもらい、レビューを受けることを強くおすすめします。
リスクを事前に言語化しておくだけでも、プロジェクトが炎上する確率は大きく下がります。「想定外だった」で終わらせないためにも、計画段階でしっかり向き合っておきましょう。
POレビューを受ける
最後に、POレビューを受けます。
作成したプロジェクト計画書について、「この計画でプロジェクトを進めてよいか」をPOに確認し、承認をもらいます。形式的な手続きに見えるかもしれませんが、ここは非常に重要なステップです。
POレビューの本質は、プロジェクトの責任の所在を明確にすることにあります。この計画で進めるという判断を、POが正式に引き受けることで、PMやプロジェクトチームは安心して実行に集中できます。
もしPOの合意を取らずに進めてしまうと、後から
「そんなつもりじゃなかった」
「そこまでやるとは聞いていない」
といった話が出てきやすくなります。これが、プロジェクト後半での方針転換や、いわゆる“ちゃぶ台返し”につながります。
だからこそ、計画が固まったタイミングで必ずPOレビューを行い、
- 目的・ゴール
- スコープ
- 進め方やスケジュール
といった前提条件に合意してもらうことが重要です。
POの承認を得た計画書は、プロジェクト期間中の判断の拠り所になります。迷ったときや意見が割れたときに、「この計画で進めると決めた」という共通認識に立ち戻れるようにしておきましょう。
計画作成後の使い方
もちろん、プロジェクト計画書は作って終わりではありません。
むしろ本番はここからです。計画書は、プロジェクトをスムーズに進めるための実務ツールとして、さまざまな場面で使われます。
ここでは、特に使用頻度の高い使い方を3つ紹介します。
人のアサイン交渉で使う
プロジェクト計画書は、人をアサインしてもらうための交渉材料として使います。
プロジェクトを立ち上げたからといって、自然に人が集まってくることはほとんどありません。実際には、PMが主体となって関係各所と調整し、チームを作っていくことになります。
人のアサインが難しい理由はシンプルで、現場メンバーの工数はその上司が管理しているからです。プロジェクトに参加してもらうには、その上司の合意を取る必要があります。
その際、上司が気にするポイントはだいたい次の2つです。
- そのプロジェクトをやる意味・必要性は何か
- どれくらいの期間・工数が必要なのか
なので、
「本当にやる価値のあるプロジェクトなのか？」
「アサインしたら、どれだけ工数を使うのか？」
という問いが来たとしても、プロジェクト計画書があれば、具体的に説明することができます。
さらに、POの承認を得た計画であることが伝われば、「ちゃんと考えられた、現実的なプロジェクトだ」という安心感にもつながります。
結果として、アサイン交渉の成功率は大きく変わってきます。
メンバーへの協力依頼で使う
人が集まった後も、プロジェクト計画書は重要な役割を果たします。
プロジェクトでは、多くの人が同じ目的のもとで協業します。しかし、その「目的」や「進め方」が可視化されていない状態では、メンバーは不安を感じやすくなります。
- このプロジェクトは、何を目指しているのか
- 自分は何を期待されているのか
- いつまで、どんな作業をするのか
これらが見えないままアサインされれば、不安になるのは当然です。
計画書をもとにキックオフを行うだけで、プロジェクトの目的や全体像を共有することができます。また、計画書を共有フォルダなどに置いておけば、迷ったときに立ち戻る場所にもなります。
意見が割れたり、方向性がブレそうになったときでも、「最初にどう決めたか」を確認できる。それだけでも、チームの安定感は大きく変わります。
ベンダーへの説明で使う
プロジェクトの中盤以降でも、プロジェクト計画書を使う場面はあります。
たとえば、開発ベンダーに見積もりを依頼する場合です。このとき必要なのは、要件定義書だけではありません。「そもそも、このプロジェクトで何をやりたいのか」「どういう進め方を想定しているのか」といった全体像の説明が重要になります。
もし、プロジェクト計画が曖昧だったり、計画書自体が存在しなかったりすると、ベンダーは強い不安を感じます。その結果、
- 見積もりを断られる
- リスクを多めに積まれ、金額が高くなる
といった事態になりがちです。
プロジェクト計画書があれば、プロジェクトの背景・目的・進め方を一貫して説明できます。ベンダーにとっても状況が理解しやすくなり、適切な見積もりや提案を引き出しやすくなります。
計画書は「作って終わり」じゃない
プロジェクト計画書は、一度作って終わりのドキュメントではありません。プロジェクトの進行に合わせて、更新され続ける前提の資料です。
プロジェクトでは、計画通りに進まないことの方が普通です。だからこそ、次のようなタイミングでは、計画書を見直し、必ず更新します。
更新のタイミング
- 当初の計画から前提や進め方が変わったとき
- プロジェクトが進み、未確定だった事項が決まったとき
特に、「後続で検討する」としていた課題や対応方針については、決まった段階で忘れずに反映しましょう。ここを放置してしまうと、計画書が現実とズレていき、「立ち戻る場所」として機能しなくなってしまいます。
常にアップデートされている計画書があれば、関係者間での認識合わせがしやすくなり、無駄な説明や議論も減ります。
「計画が変わったから、計画書も変える」という当たり前の運用を続けることが、プロジェクトを安定して進めるための大きなポイントです。
おわりに
ここまで読んで、「やっぱりプロジェクト計画書って、めんどくさいな…」と思ったかもしれません。
確かに、フォーマットがあったとしても、考えて決めなければならないことはたくさんあります。ただ、これらを決めないままプロジェクトをスタートさせるからこそ、失敗や炎上が起きます。
「めんどくさいから後回し」にしている限り、同じようなトラブルは何度でも繰り返されます。
プロジェクトは、不確実性の塊のようなものです。だからこそ、最初に立ち止まって考え、計画として言語化しておくことに意味があります。完璧な計画である必要はありません。あくまでプロジェクトの段取りが可視化できれば良いのです。
少し遠回りに見えても、計画を立ててからスタートする。それが結果的に、プロジェクトを一番早く、そして安全に前に進める方法です。
おまけ：計画書を作らなかったプロジェクトの末路
① 行き当たりばったりの対応になり、いつになっても終わりが見えない
エピソード：
ある業務改善プロジェクトで、「とりあえず始めよう」というノリでスタートした案件がありました。背景やゴールは口頭でなんとなく共有されただけ。計画書はなく、スケジュールも未定。
最初は小さな改善のつもりだったのに、
- 「ここも直した方がよさそう」
- 「それなら、これも一緒にやろう」
と、その場その場の判断で対応を追加。気づけば半年経っても終わらず、誰も「いつ終わるのか」を説明できない状態に。
何が問題だったか：
- そもそもの背景や課題が不明
- 目的・ゴールが定義されていない
- タスクやスケジュールが不明
- 責任者がいない
② 常にタスクや関係者が増え続け、常に炎上状態が続く
エピソード：
別のシステム刷新プロジェクトでは、計画書なしで関係者ヒアリングからスタートしました。すると、
- 部署A「これも必要」
- 部署B「それなら自分たちも参加したい」
- 部署C「うちの要件も忘れないで」
要件が増えるたびにタスクも増え、関係者も増え、調整コストが爆増。誰が決める人なのかも曖昧で、会議は増えるのに決まることは少ない。結果、常にどこかが遅れていて、「今、何が一番まずいのか」すらわからない炎上状態に。
何が問題だったか：
- スコープが決まっていなかった
- 体制・意思決定構造が整理されていなかった
③ 目的を見失い、終わったものの当初やりたかったことが実現できない
エピソード：
ある新サービス立ち上げプロジェクト。開発自体はなんとか期限内に完了。ただ、リリース後に事業側から「あれ？これで何が良くなったんだっけ？」と言われてしまう。途中で、
- 技術的に楽な方向に寄せたり
- 声の大きい人の要望を優先したり
と、判断の軸が少しずつズレていき、最後まで「本来の目的」が振り返られることはありませんでした。
何が問題だったか：
- 目的・ゴールに立ち戻る場所がなかった
- 判断基準が共有されていなかった
- 事業側を体制に入れていなかった
この3つに共通していること
- 最初に「考えを揃える」時間を取っていない
- 判断の軸がドキュメントとして残っていない
- 立ち戻る場所がない
つまり、計画書がないプロジェクトは、失敗する。
関連記事