目次
はじめに
本書の目的
本書はプロジェクトマネジメントにおける「プロジェクト憲章（Project Charter）」をわかりやすく説明します。憲章が何か、いつ作るか、何を書くか、他の文書とどう違うかを整理し、実務で使える知識を提供します。実際のプロジェクトで活用できる視点を重視します。
誰に向けた内容か
プロジェクトマネージャーやスポンサー、チームメンバーに加え、これからプロジェクトに関わる人や文書作成に不慣れな方にも役立ちます。専門用語は最小限にし、具体例で補足します。
本書の構成
全8章で構成します。定義、役割、記載項目、他文書との違い、作成タイミング、期待できる効果を順に解説します。まずは本章で全体像を把握してください。
プロジェクト憲章の定義
定義
プロジェクト憲章（Project Charter）は、プロジェクトの出発点を文書化する基本書類です。目的、範囲、目標、主要関係者、必要なリソース、および想定されるリスクなどを明確にします。これによりプロジェクトの存在を正式に認め、プロジェクトマネージャーに一定の権限を与えます。
主な役割（簡潔に）
- プロジェクトの承認根拠を示します。
- スポンサーとチームの合意を形成します。
- 初期の優先順位や制約を明確にします。
PMBOKガイドでの位置づけ
PMBOKガイドでは、プロジェクト憲章は立ち上げプロセスの成果物です。憲章があることでプロジェクトマネージャーは資源の要求やチームの構築などの初動を行えます。
なぜ重要か（実務観点）
曖昧な期待を防ぎます。たとえば新製品開発プロジェクトでは、憲章に目標や納期、主要な関係者を記載することで、後の仕様変更や責任範囲の争いを減らせます。リスクや前提条件を初期に共有すると、早期の対策が打てます。
簡単な例（イメージ）
目的：市場投入までの製品改良を完了する。範囲：既存機能の改良のみ。主要関係者：製品部長、開発リーダー、営業部。期間：6か月。予算：500万円（概算）。
このように、プロジェクト憲章はプロジェクトの基盤をつくる文書です。
プロジェクト憲章の主な役割
1. 正式な承認の証拠
プロジェクト憲章は組織や経営陣がプロジェクト開始を承認したことを示します。書類として残るため、予算や方針の根拠になります。例：新しい業務システム導入で、憲章があれば「開始の合意」が明確になります。
2. 目的・範囲の明確化
憲章に目的と範囲を記載すると、何を達成するか、何を含めないかがはっきりします。これにより不要な作業やスコープ・クリープを防げます。例：オンライン予約システムで「初期導入は予約機能まで、決済はフェーズ2」と明示するケース。
3. 関係者間の共通認識形成
憲章はプロジェクトの大まかな方向性や主要な関係者を示します。関係者が同じ前提で話を進められるため、打合せや意思決定が早くなります。例：関係者一覧と主要な期待値を共有して誤解を減らす方法。
4. プロジェクトマネージャーへの権限委譲
憲章は正式にマネージャーへ権限を与えます。これにより担当者は資源配分や外部業者との交渉を進められます。例：マネージャーが見積り承認やベンダー選定を進める根拠になります。
これらの役割がそろうことで、プロジェクトは組織内で安定してスタートできます。
プロジェクト憲章に記載すべき主な項目
プロジェクト目的・背景
プロジェクトの存在理由を簡潔に書きます。例：新規アプリ開発で顧客の問い合わせを半減するため、などです。背景には現状の問題や期待される効果を添えます。
プロジェクトの範囲（スコープ）
何を含め、何を含めないかを明確にします。例：機能AとBを作るが、機能Cは次フェーズに回す、などです。
目標・ゴール
達成基準を定めます。数値で示すと分かりやすいです（例：顧客満足度を10%向上、6か月でリリース）。
主要な関係者（ステークホルダー）
関係する部署や担当者、外部ベンダーを列挙します。意思決定者と実務担当者を区別すると運営が楽になります。
必要なリソース
人員、技術、設備などを挙げます。例：開発3名、デザイナー1名、サーバー環境など。
想定されるリスク
起こりうる問題と初期対応を記載します（例：要件変更、技術的障壁）。リスクの優先度を付けると有効です。
前提条件・制約条件
成功の前提となる条件や守るべき制約を明確にします。例：既存システムとの互換性が必要、など。
予算・スケジュールの概要
大まかな費用見込みと主要なマイルストーンを示します。詳細は計画書で詰めます。
プロジェクトマネージャーへの権限
意思決定や予算の執行範囲など、PMに与える権限を明記します。迅速な判断が必要な場面で役立ちます。
プロジェクト憲章と他文書（計画書等）の違い
定義と目的
プロジェクト憲章は、プロジェクトの存在と開始を公式に認める文書です。目的、主要な成果物、スポンサーの承認、プロジェクトマネージャーの権限を明記します。対してプロジェクト計画書は、実行と管理のための具体的手順を示します。目標を達成する道筋を詳しく書きます。
作成時期と承認
憲章はプロジェクト開始前に作ります。スポンサーが承認してプロジェクトを正式化します。計画書は憲章承認後に作成します。スケジュールや予算、作業分解図（WBS）を関係者と調整して固めます。
詳細度と内容の違い
憲章は大枠です（何を、なぜ、誰が）。例えば「新システムを導入して業務効率を上げる」「予算は500万円」などを示します。計画書は細部です（いつ、誰が何を、どの順で、リスク対策）。タスク、担当、期限、詳細なコスト見積りを載せます。
権限と運用面の違い
憲章はマネージャーの権限を与えます。契約や主要決定の承認基準を示します。計画書は日々の実行と管理に使います。進捗報告、変更管理、品質管理の手順が含まれます。
実務での使い分け（例）
建物を建てる例：憲章は「オフィスを建設、予算1億円、着工承認」。計画書は「基礎工事は4月から、施工会社Aが担当、品質チェック項目」などです。
プロジェクト憲章の作成タイミング
いつ作成するか
プロジェクト憲章は、プロジェクトを正式に始める直前、つまり立ち上げ段階で作成します。構想段階で承認が得られたら速やかに憲章を作り、これをもってプロジェクトが公式にスタートします。
作成のトリガーと関係者
トリガーは経営層やスポンサーの承認、あるいはビジネス上の必要性の発生です。作成はスポンサーが主導し、プロジェクトマネジャーや主要メンバーと協議して内容を決めます。権限や予算の確認を終えた段階で署名・配布します。
実務上のポイント
- 小規模プロジェクトは短く簡潔にまとめます。大規模なら要点を明記し別途詳細計画に委ねます。
- 早めに作ることで役割や範囲が明確になり、無駄な議論を防げます。
- 作成後に変更が生じた場合は、改訂履歴を残して周知します。チーム全員が参照できるようにします。
具体例
- 新製品開発：企画承認後すぐに憲章を作り、設計フェーズへ進みます。
- オフィス移転：要件確定後に憲章で責任者と予算を定めます。
このタイミングで憲章を作ると、計画策定や実行にスムーズに移れます。
プロジェクト憲章がもたらす効果
1. プロジェクトの方向性の統一
プロジェクト憲章は目標と期待成果を明確に示します。チーム全員が同じゴールを共有し、優先順位をぶれずに決めやすくなります。例：品質向上が目的なら、仕様やテスト基準がぶれません。
2. プロジェクトの境界線・目的の明確化
スコープと除外項目を定義して、何をやるか・やらないかを示します。これにより追加要求による混乱を防げます。例：追加機能は別フェーズで検討すると明記します。
3. 組織内外の関係者との合意形成
憲章に署名・承認を得ることで関係者の合意を確保します。利害が対立したときも参照点として機能します。例：予算や納期について経営層と合意しておく。
4. プロジェクト推進のための権限確保
責任者や権限範囲を明示して、決定を速やかに行えるようにします。これで現場の判断が滞りません。例：PMにベンダー選定の最終決定権を与える。
5. 後の計画立案や管理の基礎資料となる
スケジュールやコスト見積もり、リスク管理は憲章を基に作成します。計画段階での前提条件が明確になり、変更対応も早くなります。例：前提リソースを憲章に記載して見積り精度を上げる。
まとめ
プロジェクト憲章は、プロジェクト開始時に作成する「目的・範囲・目標・主要関係者・権限」をまとめた基本文書です。プロジェクトマネージャーが業務を進めるための権限の根拠になり、全関係者が同じ方向を向くための土台になります。
ポイントを絞ると実務で使いやすくなります。例えば新商品の開発なら、目標（発売日・売上目標）、範囲（対象顧客・対象機能）、主要関係者（担当部署・承認者）を明確にします。本文書は1〜2枚に収め、スポンサーの承認署名を得ると効果が高まります。
運用では、憲章を参照して意思決定を行い、重要な変更は関係者合意の上で追記します。作成はプロジェクト開始直後に行い、計画書やスケジュールと役割を分けて使うと混乱が減ります。短く分かりやすく作ることが、プロジェクト成功の第一歩になります。