はじめに
プロジェクトマネジメントの教科書には「プロジェクト憲章(プロジェクトチャーター)」という言葉がよく登場しますが、実務の現場では「プロジェクト計画書があれば十分では」と、作成が省略されてしまうことが少なくありません。プロジェクト憲章が本来果たすべき役割と、計画書との違いを整理します。
プロジェクト憲章と計画書の違い
プロジェクト憲章と計画書は、どちらもプロジェクトの初期に作成される文書ですが、役割がまったく異なります。
プロジェクト憲章は、「このプロジェクトを正式に立ち上げる」という経営層の意思決定そのものを文書化したものです。プロジェクトの目的、プロジェクトオーナー、大まかな予算・スケジュールの枠組み、プロジェクトマネージャーへの権限委譲を、簡潔に宣言する短い文書です。
一方プロジェクト計画書は「誰のための文書」なのかでも触れたとおり、計画書はプロジェクトを具体的にどう進めるかの詳細な実行計画です。体制、詳細スケジュール、リスク対応方針、品質管理方針などを、プロジェクトマネージャーが主導して作り込みます。
つまり、憲章は「やる」という意思決定の文書、計画書は「どうやるか」の実行文書という違いがあります。
なぜ憲章が省略されてしまうのか
実務でプロジェクト憲章が省略されがちな理由は、「経営層の承認は、稟議や予算承認のプロセスで既に取れているから、わざわざ別文書を作る必要はない」という感覚があるためです。
しかし、稟議や予算承認のプロセスは、多くの場合、金額や投資対効果の承認に主眼が置かれており、「誰がプロジェクトオーナーで、プロジェクトマネージャーにどこまでの権限が委譲されているのか」までは明文化されないことがほとんどです。この権限委譲の曖昧さが、後になってプロジェクトの停滞を招く原因になります。
憲章がないと、プロジェクト途中で起きること
プロジェクト憲章に相当する文書がないまま進めると、次のような問題が起きやすくなります。
- プロジェクトマネージャーがどこまで独自に判断してよいのか不明確で、些細な意思決定のたびに経営層にお伺いを立てることになる
- 部門間で意見が対立した際、「誰が最終判断者なのか」が明文化されていないため、調整に時間がかかる
- プロジェクトの目的が途中で曖昧になった際、立ち返るべき「原点」の文書が存在しない
「誰が決めるのか」が決まっていないプロジェクトは必ず迷走する|RACIという考え方で触れた迷走の構造は、プロジェクト憲章による権限の明文化が不足していることが根本原因になっているケースも多くあります。
憲章に最低限含めるべき項目
本格的な憲章文書を新たに作らなくても、既存のキックオフ資料や計画書の冒頭に、次の項目を明記しておくだけで、憲章としての役割を代替できます。
- プロジェクトの目的(なぜこのプロジェクトをやるのか)
- プロジェクトオーナー(最終意思決定者)は誰か
- プロジェクトマネージャーに委譲されている権限の範囲
- 大枠の予算・スケジュール
実際に使っているプロジェクト計画書のテンプレートは、noteで配布しています。憲章として最低限押さえるべき項目も、計画書の冒頭に組み込める構成にしています。
まとめ
プロジェクト憲章は、「プロジェクトをやる」という意思決定と権限委譲を明文化する文書であり、「どうやるか」を定める計画書とは役割が異なります。独立した文書として作らなくても、キックオフ資料や計画書の冒頭にこれらの項目を明記しておくことで、プロジェクト途中の意思決定の停滞や迷走を防ぐことができます。
執筆者プロフィール:SIer(元請け)とITコンサルファーム(発注側支援)、両方の立場でプロジェクトに従事(通算9年)。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。


コメント