プロジェクト憲章は「許可証」である
プロジェクト憲章（Project Charter）を「作らなければいけない書類」として捉えていませんか？実は、プロジェクト憲章はPMにとって最強の武器です。正式に承認された憲章があることで、あなたはリソースを動かし、予算を使い、チームを組成する公式な権限を手に入れられます。
本記事では、「形式を満たすだけの憲章」ではなく、ステークホルダーに即承認され、プロジェクト全体を守り続ける憲章の書き方を解説します。
プロジェクト憲章に盛り込む5つの核心要素
① ビジネス上の正当性（Why）
最初に答えるべき問いは「なぜこのプロジェクトが必要なのか」です。感覚的な説明ではなく、ビジネスの文脈で定量的に示しましょう。
- ❌ 「顧客満足度を高めるため」
- ✅ 「顧客満足度スコアが業界平均を12ポイント下回っており、年間約3,000万円の解約損失が発生しているため」
Tip：スポンサーが経営層であれば、数字と経営課題を必ずリンクさせてください。「なんとなく承認する」ではなく「承認しない理由がない」状態を作るのがポイントです。
② 目標とスコープの明確な境界線
プロジェクトの目標はSMART基準（Specific・Measurable・Achievable・Relevant・Time-bound）で記述します。しかし多くの憲章が見落とすのが「スコープ外の明示」です。
例えばECサイト刷新プロジェクトであれば：
- ✅ スコープ内：決済機能改修、スマートフォン対応、カート機能最適化
- 🚫 スコープ外：在庫管理システムとの連携（次フェーズ）、海外対応
Tip：「やらないこと」を書くのは手を抜いているように見えますが、実際はスコープクリープ（後からの仕様拡大）を防ぐ最も効果的な手段です。後々のトラブル回避に直結します。
③ 主要な成果物とマイルストーン
憲章の段階では詳細スケジュールは不要ですが、プロジェクトの「骨格となるマイルストーン」は必須です。
記述例：
- Phase 1 完了：要件定義書の承認（第4週）
- Phase 2 完了：プロトタイプのステークホルダーレビュー（第12週）
- プロジェクト完了：本番リリースと運用引き渡し（第24週）
Tip：日付は確定的に書くより「プロジェクト開始から○週目」と相対的に表記すると、開始日が変動しても書き直しが不要です。
④ 予算と主要リソースの概算
憲章に書く予算は精緻な積算ではなく、オーダーマグニチュード（大まかな規模感）で構いません。「数百万円規模」なのか「数億円規模」なのかを明示するだけで、承認者は意思決定しやすくなります。
また、専任PMが必要か、他部門から何名のアサインが必要かも記載します。リソース確保の根拠として憲章が機能するからです。
⑤ リスクと制約条件の初期評価
「リスクを書くと承認されにくくなる」と考えてリスクを隠すPMがいますが、これは逆効果です。リスクを認識した上で対策を示せるPMこそ信頼されるのです。
記述のコツは「リスク → 影響 → 対応方針」の3点セットで書くことです。
例：主要ベンダーの人員不足リスク（高）→ スケジュール遅延の可能性 → 早期発注と代替ベンダーのリスト化により対処
承認率を高める「書き方」の3つのコツ
- A4で2〜3枚に収める：経営層は長文を読みません。要点を絞り、補足情報は別添付にしましょう。
- スポンサーと事前すり合わせをする：憲章を提出する前に、スポンサーとドラフトを口頭で確認する場を設けるだけで承認率は大幅に上がります。
- 承認欄を明記する：「誰が、いつ、どの権限で承認するか」を憲章内に記載し、署名欄を設けることで文書に法的・組織的な重みが生まれます。
まとめ：憲章は「書くもの」ではなく「使うもの」
プロジェクト憲章は承認を得た瞬間に役割を終えるわけではありません。プロジェクトが迷走し始めたとき、スコープ変更の要求が来たとき、チームの目線がずれてきたとき——そのたびに憲章に立ち返ることで、プロジェクトの軸を取り戻せます。
「なぜこのプロジェクトを始めたのか」を全員が確認できる憲章こそ、優れたPMが作る文書です。ぜひ今日から、権限の根拠として、チームの羅針盤として機能するプロジェクト憲章を作成してみてください。
