はじめに
プロジェクト憲章（プロジェクトチャーター）はなぜ必要か｜計画書との違いと役割では、プロジェクトチャーターがなぜ必要なのかを解説しましたが、「必要性は分かったけれど、実際に何を書けばいいのか分からない」という声もよくいただきます。
今回は、プロジェクトチャーターに最低限盛り込むべき項目を、テンプレート形式で解説します。実際に手を動かしながら作成できるよう、項目ごとに「何を書くべきか」「よくある失敗」を合わせて整理しました。
プロジェクトチャーターに含めるべき項目
プロジェクトチャーターは、プロジェクトの「立ち上げを正式に承認する文書」です。以下の項目を押さえておくことで、関係者の認識を揃えた状態でプロジェクトを開始できます。
1. プロジェクトの目的・背景：なぜこのプロジェクトを行うのか、経営上の狙いは何か
2. プロジェクトのゴール（成功基準）：何をもって「成功」と判断するのか、できるだけ数値・具体的な状態で記述する
3. スコープの概要：何を対象とし、何を対象外とするか（詳細はプロジェクト計画書に譲ってよい）
4. プロジェクトオーナー・PM・主要ステークホルダー：誰が最終意思決定者で、誰がPMを担うか
5. PMに委ねる権限の範囲：PMが自分の判断で決めてよいこと（例：一定額までの予算の組み替え、スケジュールの小幅な調整）と、オーナーの承認が必要なこと
6. 概算の予算・スケジュール：この段階では精緻でなくてよいが、桁感が分かるレベルで記載する
7. 主要なリスク・前提条件：プロジェクト開始時点で認識している懸念事項
8. 承認者のサイン（または承認の記録）：経営層がこのプロジェクトを正式に承認したという証跡
「目的」と「ゴール」を混同しない
プロジェクトチャーターでよくある失敗が、「目的」と「ゴール（成功基準）」を混同してしまうことです。
- 目的：なぜこのプロジェクトをやるのか（例：基幹システムの老朽化によるリスクを解消するため）
- ゴール（成功基準）：何をもって成功と判断するか（例：2027年3月までに新システムへの移行を完了し、旧システムを廃止する）
目的だけを書いて満足してしまうと、プロジェクトが進むにつれて「結局、何がゴールだったのか」が曖昧になります。チャーターの段階で、できる限り具体的なゴールを言語化しておくことが重要です。
PMの権限範囲は「例」で書く
プロジェクト憲章（プロジェクトチャーター）はなぜ必要かでも触れたとおり、稟議や予算承認では、金額は承認されても「PMがどこまで自分で決めてよいか」は明文化されないことがほとんどです。ここが曖昧なままだと、PMは小さな判断のたびに経営層の確認を取ることになり、プロジェクトの動きが鈍くなります。
権限の範囲は、抽象的な表現ではなく、具体的な例で書くと運用しやすくなります。
- PMが判断してよい：承認済み予算の範囲内での費目の組み替え（例：1件あたり100万円まで）、マイルストーンに影響しない範囲のスケジュール調整
- オーナーの承認が必要：予算総額の増額、スコープの追加・削減、稼働時期（マイルストーン）の変更
「誰が決めるのか」が決まっていないプロジェクトは必ず迷走する｜RACIという考え方とあわせて整理しておくと、判断の流れがさらに明確になります。
スコープは「詳細」より「境界線」を意識する
プロジェクトチャーターの段階では、スコープの詳細（要件の一つひとつ）まで書き込む必要はありません。プロジェクト計画書は「誰のための文書」なのかで触れた通り、詳細な要件はその後の工程で詰めていくものです。
チャーターの段階で意識すべきは「境界線」です。たとえば「基幹システムの刷新」というプロジェクトであれば、以下のように書きます。
- 対象とする：販売管理・在庫管理・会計連携の刷新
- 対象外とする：人事給与システムの刷新（別プロジェクトとして扱う）
この境界線が曖昧なまま進むと、後から「これもプロジェクトの範囲内のはずだ」という認識齟齬が生まれ、「ついでにこれも」が積み重なってスコープが崩壊する前に｜変更管理表の作り方で触れたようなスコープの崩壊につながります。
チャーターの承認プロセスを形骸化させない
プロジェクトチャーターは、作成して終わりではなく、経営層・主要ステークホルダーの承認を得て初めて意味を持ちます。チャーターの承認をキックオフ会議の場で形式的に済ませてしまうと、「本当に経営層が内容を理解し、合意したのか」が曖昧なまま進んでしまいます。キックオフは承認済みの内容を関係者全員に共有する場と位置づけ、承認そのものはその前に済ませておくのが理想です（キックオフの進め方はキックオフ会議は「顔合わせ」で終わらせない｜プロジェクトの成否を決める最初の場を参照）。
承認プロセスでは、以下を意識すると形骸化を防げます。
- チャーターの内容を事前に承認者へ共有し、質問・懸念点を聞く時間を設ける
- 承認者からの質問・修正依頼があれば、チャーターに反映してから正式承認とする
- 承認の記録（署名、または承認メールなど）を残しておく
テンプレートをすぐに使いたい方へ
実務では、チャーターを独立した文書にせず、プロジェクト計画書の冒頭に組み込む形でも十分に役割を果たせます。実際に使っているプロジェクト計画書のテンプレートはnoteで配布しており、チャーターとして押さえるべき項目も計画書の冒頭に組み込める構成にしています。
まとめ
プロジェクトチャーターは、目的・ゴール・スコープの境界線・体制・PMの権限範囲・概算予算・リスク・承認の証跡という8項目を押さえることで、関係者の認識を揃えた状態でプロジェクトを開始できます。特に「目的とゴールの混同」「PMの権限範囲の曖昧さ」「スコープの境界線の曖昧さ」「承認プロセスの形骸化」は実務でよく起きる失敗なので、作成時に意識しておくことをお勧めします。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント