プロジェクト憲章とは？目的・範囲・権限を定める「出発点」の文書
プロジェクト憲章とは
プロジェクト憲章（Project Charter）は、プロジェクトを正式に立ち上げ、その目的・範囲・責任者などを定めて、関係者で合意するための文書です。PMBOKでは、プロジェクトの存在を正式に認可し、プロジェクトマネージャーに組織の資源を使う権限を与える文書と位置づけられています。
プロジェクトの「出発点」であり、途中で判断に迷ったときに立ち返る「よりどころ」になります。
なぜプロジェクト憲章が必要なのか
目的をそろえる：「何のためのプロジェクトか」を明文化し、関係者の認識のズレを防ぎます。組織の3要素でいう「共通目的」をつくる文書です。
権限を明確にする：PMが誰から、どの範囲の権限を与えられているかを示します。
スコープの膨張を防ぐ：何をやり、何をやらないかを最初に決めておくことで、後からの要求追加に対応しやすくなります。
判断の基準になる：優先順位の対立や変更要求が起きたときに、目的と成功基準に照らして判断できます。
プロジェクト憲章に書く主な項目
項目 | 内容 |
|---|---|
プロジェクト名 | 関係者が共通で呼ぶ名称 |
背景と目的 | なぜこのプロジェクトを行うのか。解決したい課題と、達成したいこと |
成功基準 | 何をもって成功とするか。測定可能な目標（KPIなど） |
スコープ（範囲） | 対象とする業務・システム・組織。対象外も明記する |
主要な成果物 | プロジェクトが生み出すもの |
マイルストーン | 主要な節目と目標時期 |
概算予算 | プロジェクトに投じる費用の枠 |
体制と役割 | スポンサー、PM、主要メンバーとその責任・権限 |
主要なステークホルダー | 影響を与える、または影響を受ける人・組織 |
前提条件と制約条件 | 計画の前提となる事柄と、守らなければならない制約 |
主なリスク | 現時点で想定される大きなリスク |
承認 | スポンサーなど、プロジェクトを承認する人の署名 |
SCQで「背景と目的」を書く
憲章の冒頭にある「背景と目的」は、SCQ（SCQA）の形で書くと、説得力が高まります。
S（状況）：当社は10年前から、販売管理システムを自社開発で運用してきた。
C（問題）：しかし、保守担当者の退職と法改正への対応遅れにより、業務継続のリスクが高まっている。
Q（問い）：今後、販売管理業務をどのように安定して支えるか。
A（答え＝目的）：2年以内にクラウド型パッケージへ移行し、保守リスクを解消するとともに、受注処理の工数を30%削減する。
作成から承認までの流れ
情報を集める：企画書、ビジネスケース、契約書、スポンサーへのヒアリングなどから、背景や目的を把握します。
草案を作る：PM（またはスポンサー）が上記の項目に沿って草案を作成します。
関係者とすり合わせる：スポンサーや主要なステークホルダーと内容を確認し、特にスコープと成功基準について合意します。
承認を得る：スポンサーの承認を得て、プロジェクトを正式に開始します。
キックオフで共有する：プロジェクトメンバー全員に内容を説明し、目的を共有します。
よくある失敗と注意点
作らずに始める：「急いでいるから」と憲章なしで始めると、後で目的やスコープをめぐって揉める原因になります。
目的が曖昧：「システムを刷新する」は手段であり、目的ではありません。「何を実現するために刷新するのか」まで書きます。
成功基準が測れない：「業務を効率化する」ではなく、「受注処理の工数を30%削減する」のように測定可能にします。
対象外を書かない：「やらないこと」を明記しないと、スコープが際限なく広がります。
詳細を書きすぎる：憲章は概要レベルの文書です。詳細な計画は、プロジェクト計画書やWBSで定めます。
作って終わり：大きな方針転換があれば、スポンサーの承認を得て見直します。
PMの実務での活用
判断に迷ったとき：変更要求や優先順位の対立が起きたら、憲章の目的と成功基準に照らして判断します。
新メンバーの受け入れ：派遣社員や途中参画のメンバーへのオリエンテーション資料として使えます。
ステアリングコミッティ：報告のたびに、目的と成功基準に対する達成状況を示すと、議論の軸がぶれません。
まとめ
プロジェクト憲章は、プロジェクトを正式に立ち上げ、目的・スコープ・体制・権限を定めて合意する文書
目的と成功基準を明確にし、「やらないこと」も含めてスコープを定めることが重要
プロジェクトの出発点であり、迷ったときに立ち返るよりどころとして活用する