プロジェクト計画書

プロジェクト計画書の目的は、関係者の認識をそろえ、実行中の判断の拠りどころを作ることにあります。発注側・受注側・現場メンバー・経営層といった立場の異なる人たちが、同じ目的と範囲を見て動けるようにするための文書です。口頭合意だけで進めると、途中で「それは聞いていない」というずれが生じやすく、計画書はその予防線として働きます。

位置づけとしては、プロジェクト憲章などで承認された大枠を受け、より具体的な実行レベルに落とし込んだものにあたります。憲章が「このプロジェクトをやる」という権限と目的を定めるのに対し、計画書は「どう進めるか」を描きます。

軸として押さえたいのは、計画書が合意形成のための文書であると同時に、実行中の変更を判断する基準線にもなる点です。たとえば追加要望が出たとき、当初の範囲に照らして「これは範囲内か、変更管理にかけるべきか」を判断できます。基準線がないと、依頼が来るたびに場当たりで対応してしまい、スケジュールや工数が静かに膨らみます。つまずきやすいのは、承認を取ることだけが目的化して、作った後に誰も見返さない状態になることです。更新されない計画書は、早い段階で実態と乖離していきます。

計画書に盛り込む要素は、プロジェクトの性質によって調整しますが、軸は「目的・範囲・体制・進め方・制約」の五つで考えると整理しやすくなります。それぞれを具体的な成果物や決定事項として書き下していきます。

• 目的とスコープ：なぜやるのかと、どこまでをやる・やらないで線引きします。やらないこと（スコープ外）を明記しておくと、後の範囲のにじみを抑えやすくなります。
• 体制と役割：誰が意思決定し、誰が実作業を担うかを示します。RACIのような役割分担の表を添えると、承認者と実行者の区別が明確になります。
• スケジュールとマイルストーン：WBSで作業を分解し、ガントチャートや主要なマイルストーンで節目を示します。
• コスト・品質・リスク：予算の枠、品質の判定基準、想定されるリスクと対応方針をまとめます。

作り方としては、PMが単独で書き切るのではなく、要件や見積もりを持つメンバーから情報を集めて束ねる進め方が現実的です。スケジュールは現場の工数感を、リスクは技術担当の懸念を拾って反映させます。つまずきやすいのは、雛形の項目を埋めること自体が目的になり、プロジェクト固有の論点が薄い一般論の計画書になってしまうことです。

作成のタイミングは、立ち上げフェーズの、キックオフの前後が中心になります。大枠の承認が下りた後、実行に入る前に計画書をまとめ、関係者のレビューと承認を経るのが一般的な流れです。

進め方を順に見ると、まずPMが目的・範囲のたたき台を作り、次に体制とスケジュール、コスト、リスクへと広げていきます。各要素を埋める際は、担当者へのヒアリングや見積もりの収集が並行します。ドラフトができたら、発注側と受注側の双方でレビューし、認識のずれを潰してから承認に進みます。この承認が、実行フェーズのゴーサインになります。

重要なのは、計画書を作って終わりにしない点です。進捗管理や変更管理の中で、実態とずれが出たら計画書側も更新し、基準線を引き直します。変更が大きいときは、改めて関係者の合意を取り直すこともあります。つまずきやすいのは、初版を作った後に更新の運用を決めておらず、実態はスケジュールツールや議事録に散らばったまま、計画書だけが初版で止まってしまうことです。更新の責任者と頻度を、計画書の中で先に決めておくと運用が続きやすくなります。

計画書まわりで混乱しやすいのは、似た役割の文書との区別です。軸を「何を定める文書か」に置くと整理できます。

• プロジェクト憲章との違い：憲章はプロジェクトの発足を承認し、目的と権限を与える文書です。計画書はその枠内で、具体的な進め方を定めます。憲章が上位、計画書が実行レベルという関係です。
• 要件定義書との違い：要件定義書は「何を作るか」の中身を詳述します。計画書は作る中身そのものより、進め方・体制・制約を扱います。両者は補完関係で、計画書が要件定義書を参照することもあります。
• WBSやガントチャートとの違い：これらはスケジュールや作業分解という一側面を担う成果物で、計画書はそれらを含みつつ全体を束ねる上位の文書という位置づけになります。

典型的な失敗の形としては、分量を増やすこと自体が目的になり、読まれない大部の文書になってしまうケースがあります。関係者が実際に参照する部分（範囲・体制・マイルストーン）が埋もれると、合意の土台という本来の役割が果たせなくなります。プロジェクトの規模に見合う粒度に絞ることが、使われる計画書への近道になります。

計画書を作る力は、プロジェクトマネージャーとしての評価につながりやすい部分です。立場の違う関係者の前提をそろえ、合意の土台を一枚にまとめられることは、規模の大きい案件を任せる判断材料になります。職務経歴書や面接でも、どんな計画書を作り、途中でどう更新して基準線を保ったかを具体的に語れると、進行を管理した実感が伝わりやすくなります。

単に雛形を埋めた経験より、スコープ外をどう線引きしたか、リスクをどう事前に織り込んだかといった判断の跡を示せると、再現性のあるスキルとして受け取られます。計画書を実行中に活かしきった経験は、より上流の役割や大型案件への移行を考えるときの説得材料になります。

プロジェクト計画書とプロジェクト憲章はどう違いますか。

憲章はプロジェクトの発足を承認し、目的・権限・大枠を定める上位文書です。計画書はその枠内で、範囲・体制・スケジュール・リスク対応など「どう進めるか」を具体化します。憲章で合意した方向を、実行レベルに落とし込んだものが計画書だと捉えると整理しやすくなります。

計画書には最低限どんな項目を書けばよいですか。

目的とスコープ、体制と役割、スケジュールとマイルストーン、コスト・品質・リスクの方針が基本の軸になります。特にスコープ外の明記と役割分担は、後の認識ずれを抑えるうえで効きます。プロジェクトの規模に応じて、使われる粒度まで絞り込むとよいでしょう。

計画書は一度作ったら変えない方がよいですか。

固定する必要はありません。むしろ実行中に実態とずれが出たら、計画書側も更新して基準線を引き直す運用が一般的です。変更が大きいときは関係者の合意を取り直します。初版で止めず、更新の責任者と頻度を計画書内で決めておくと、基準線としての役割が保たれます。