はじめに
プロジェクトのキックオフ時に「プロジェクト計画書」を作成する会社は多いですが、その多くは体制図とスケジュールだけが並んだ、形だけの資料になっています。発注側が最低限知っておくべきプロジェクト管理の「型」で紹介した管理の型は、実はこのプロジェクト計画書の中に、方針として明記しておくべきものです。
SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、プロジェクト計画書を形骸化させないためのポイントを解説します。
プロジェクト計画書は「メンバー間の約束事」を記録する文書
プロジェクト計画書の本来の役割は、プロジェクトに関わる全員が同じ前提で動けるようにする「約束事」を記録することです。スコープ、体制、予算、品質基準、リスク対応方針、コミュニケーションのルール——これらをキックオフの段階で明文化し、合意しておくことで、後から「それは聞いていない」「誰がそれを決める権限を持っているのか」といった混乱を防げます。
逆に言えば、体制図とスケジュールだけの計画書では、こうした約束事が何も記録されていません。プロジェクトが進む中でトラブルが起きたときに、計画書に立ち返っても何の判断材料も得られない、という状態に陥ります。
「目的」だけでは、成功したかどうかを判断できない
プロジェクト計画書の冒頭には、たいてい「目的」が書かれています。ただ、目的だけが書かれていて、「目標」が書かれていない計画書を数多く見てきました。
目的は「なぜこのプロジェクトをやるのか」という方向性を示すものです。一方で目標は、「達成できたかどうかをどう判断するか」という具体的な到達点です。「顧客満足度の向上」という目的だけでは、プロジェクトが終わったときに、本当に満足度が上がったのかを誰も判断できません。
ここで重要なのが、目標を定性・定量の両方で書くことです。
- **定量目標**：「受注〜出荷のリードタイムを現状比50%短縮する」のように、数値で測定できる目標です。達成・未達成を客観的に判断できる一方、数値化しにくい価値（使いやすさ、現場の納得感など）が抜け落ちやすいという弱点があります。
- **定性目標**：「現場の心理的な業務負荷を軽減する」のように、数値化しにくいが重要な到達点です。定量目標だけでは拾いきれない、プロジェクトの本質的な狙いを言語化できます。
定量目標だけだと数字至上主義になり、定性的な価値がないがしろにされます。逆に定性目標だけだと、達成したかどうかの判断が主観的になり、プロジェクトの成否を客観的に説明できません。両方を書いて初めて、プロジェクトの成功を多面的に判断できるようになります。
スコープの「対象外」を書かないと、要求はなし崩しに拡大する
計画書の中で特に重要なのが、スコープの明記です。「何をやるか」だけでなく、「何をやらないか」を明記することが、プロジェクトの進行を安定させます。
対象外が書かれていないと、プロジェクトが進む中で現場から出てくる「ついでにこれもやってほしい」という要求に対して、断る根拠がなくなります。結果としてスコープが少しずつ広がり、当初の予算・スケジュールでは収まらなくなる、というのはよくあるパターンです。
品質・リスク・コミュニケーションの「方針」まで書く
体制やスケジュールは多くの計画書に記載されていますが、品質管理の方針、リスク・課題管理の方針、コミュニケーションのルールまで明記している計画書は意外と少ないです。
これらは「当たり前だから書かなくてもいい」と思われがちですが、実際にはメンバーごとに暗黙の前提が異なります。「品質チェックのタイミングをいつにするか」「重大なリスクが見つかったら誰にいつまでに報告するか」——こうした運用ルールを事前に文書化し、キックオフの場で全員に共有しておくことが、後々のトラブルを防ぎます。
計画書は「配布」ではなく「キックオフで合意」して初めて機能する
ここまで、計画書に書くべき内容を解説してきましたが、どれだけ内容を練り込んでも、キックオフの場で丁寧に説明し、合意を取るプロセスを省略すると、計画書はただの配布資料で終わってしまいます。
キックオフは、発注側・ベンダー側を含めたプロジェクト関係者が一堂に会する、プロジェクトを通じてもほぼ唯一の機会です。この場を「計画書を配って終わり」にしてしまうと、後から個別に説明して回ることになり、説明の濃淡や解釈のズレが生まれます。質問や懸念もその場で拾いきれず、プロジェクトが始まってから「実はよく分かっていなかった」というメンバーが出てくる原因になります。
キックオフで一つひとつの項目を読み上げ、その場で質問を受け付け、合意を得るというプロセスを踏んで初めて、計画書に書かれた内容は「全員が同意した約束事」になります。さらに、キックオフでどれだけ丁寧に説明したかは、その後のプロジェクト全体の緊張感や当事者意識にも影響します。「最初が肝心」というのは精神論ではなく、計画書を機能させるための実務上のポイントです。
まとめ
プロジェクト計画書は、体制図とスケジュールを並べるだけの儀礼的な資料ではなく、プロジェクトに関わる全員の「約束事」を記録する文書です。目的だけでなく定性・定量の目標まで明記し、スコープの対象外を書き、品質・リスク・コミュニケーションの方針まで書き込む。そして、それをキックオフの場で丁寧に説明し、合意を得る。ここまで行って初めて、プロジェクトが進む中での判断の拠り所になります。
実際に使っているプロジェクト計画書のテンプレートは、noteで配布しています。
執筆者プロフィール：SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。
コメント