プロジェクト憲章（Project Charter）の書き方：炎上を防ぐ合意文書の作り方

プロジェクトが始まって数週間後に「あれ、そういう話でしたっけ？」という会話が発生するのは、最初の合意が曖昧だったことが原因だ。プロジェクト憲章（Project Charter）は、そのズレを防ぐための「最初の一枚」である。

PMBOKでも定義されているこの文書は、プロジェクトの存在意義・スコープ・制約・権限を明文化し、ステークホルダー全員が共通認識を持つための土台となる。

プロジェクト憲章とは何か

プロジェクト憲章は、プロジェクトを正式に承認し、PMに権限を与える文書だ。「プロジェクトが何のために存在するか」を1〜2ページで定義する。

憲章が必要な理由

プロジェクトが失敗する原因の多くは技術的な問題ではなく、認識のズレだ。特に以下のような場面で問題が発生する。

• スポンサーが考えていた「完成像」とPMの理解が違っていた
• スコープ外の要求を「当然含まれる」と思っていたクライアントがいた
• PMが判断できる範囲が曖昧で、いちいちエスカレーションが必要だった

プロジェクト憲章はこれらを事前に合意する文書だ。後から「そんなことは言っていない」という議論を防ぐ効果がある。

プロジェクト憲章の7つの構成要素

1. プロジェクトの目的・背景

「なぜこのプロジェクトが必要か」を記述する。ビジネス課題や機会を明確にする。

記述例：

現在の受注管理システムは10年前に構築されたため、モバイル対応が不可能で営業担当者の現場での入力が困難になっている。本プロジェクトでは、営業効率を30%向上させることを目標にモバイル対応の受注管理システムを構築する。

2. スコープ（含まれるもの・含まれないもの）

「何をするか」だけでなく「何をしないか」を明記することが重要だ。

区分	内容
スコープ内	受注管理画面のモバイル対応、既存データの移行、社内利用者向けトレーニング
スコープ外	請求書発行機能、外部顧客向けポータル、ERP連携

スコープ外を明記しないと、後から「それも入れてほしい」という要求の口実を与えてしまう。

3. 成果物（Deliverables）

プロジェクトが完了した時点で何が存在するかを具体的に列挙する。

• モバイル対応受注管理システム（本番環境稼働）
• 操作マニュアル（PDF、日本語）
• テスト完了報告書
• 移行完了確認書

4. 前提条件・制約条件

前提条件は「これが成立していると仮定して進める」事項、制約条件は「変更できない条件」だ。

前提条件の例：

• 既存データの形式はCSVでエクスポート可能である
• クライアント側のIT担当者が環境構築に協力する

制約条件の例：

• 予算：3,000万円以内
• 期間：2026年9月末まで
• 使用技術：社内セキュリティポリシー上、クラウドはAWS東京リージョンのみ

5. マイルストーン

主要な完了基準と日付を記載する。詳細なスケジュールはWBSで管理するが、憲章には大きなマイルストーンを入れる。

マイルストーン	予定日
要件定義完了	2026-06-30
設計レビュー承認	2026-07-31
UAT開始	2026-09-01
本番リリース	2026-09-30

6. ステークホルダーと役割

誰が意思決定者で、誰が承認権限を持つかを明確にする。

氏名・組織	役割	権限
〇〇部長（発注元）	スポンサー	予算変更・スコープ変更の最終承認
△△課長（発注元）	プロダクトオーナー	要件優先度の決定
PM（受注側）	プロジェクトマネージャー	計画・進捗管理、300万円以下の調達

7. PMの権限と責任範囲

PMが何を自律的に判断できるかを明記する。これがないと、些細な判断でもスポンサーを巻き込む羽目になる。

• PM単独で判断できること：スケジュール変更（±1週間以内）、チームメンバーのアサイン変更、ベンダー選定（500万円以下）
• スポンサー承認が必要なこと：スコープ変更、予算の10%超過、2週間以上のスケジュール変更

テンプレートの使い方：段階的に詳細化する

プロジェクト憲章は一発で完璧に書こうとしなくてよい。次のステップで進めるとスムーズだ。

ステップ1：Kick-off前に初版を作る（PMが草案）

まずPMが知っている情報だけで草案を作る。不明点は「TBD（To Be Determined）」として空欄にしておく。

ステップ2：キックオフで関係者と合意する

キックオフミーティングで憲章の各項目を読み合わせ、認識のズレを発見する。特にスコープ内外の定義で議論が起きることが多い。

ステップ3：要件定義完了後に更新する

要件定義が完了したら、スコープ・成果物・マイルストーンを具体化して憲章を更新する。「要件定義書で決まったことは憲章のスコープを更新したことと同義」という扱いにすると管理がシンプルになる。

よくある失敗パターン

失敗1：スコープ外を書かない

「スコープ内」しか書かないと、記載がないものは全部「スコープ内」と解釈される。必ず「やらないこと」リストを作る。

失敗2：PMの権限を書かない

権限が不明確だと、PMは何でもスポンサーにお伺いを立てることになる。「300万円以下の調達はPMが承認」のような具体的な基準を入れる。

失敗3：サインをもらわない

憲章は口頭合意では意味がない。スポンサーとクライアントの責任者から署名（または電子承認）をもらうことで、後から「そんな話ではなかった」という議論を防げる。

まとめ

プロジェクト憲章は「お役所仕事」ではなく、PMが自分のプロジェクトを守るための盾だ。

• 目的・背景で「なぜやるか」を合意する
• スコープ内外で「何をやって何をやらないか」を合意する
• PMの権限で「誰が何を決めるか」を明確にする

この3点さえ押さえれば、プロジェクト中盤以降の不毛な議論を大幅に減らせる。最初の2〜3時間を憲章作成に使うことで、後の20〜30時間を節約できると考えると、コスパは極めて高い投資だ。