プロジェクト憲章の書き方｜目的・前提・制約・PM 権限を1枚にまとめる記載項目とテンプレート

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

「このプロジェクト、そもそも何のためにやるんでしたっけ？」——走り出してしばらく経ってからこの問いが出てくるプロジェクトは、たいてい迷走します。目的がぶれ、スコープが膨らみ、「誰の承認で始まったのか」すら曖昧になる。この事態を着手前に防ぐための最初の1枚が プロジェクト憲章（プロジェクトチャーター） です。

結論から言えば、プロジェクト憲章とは「このプロジェクトを正式に始めてよい」という組織の承認を得て、同時に「このプロジェクトは何を・なぜ・どこまでやるのか」と「プロジェクトマネージャーに組織の資源を使う権限を与える」ことを1枚にまとめた公式文書です。書くべき項目は、目的・目標・スコープ（範囲）・主要成果物・前提条件・制約条件・主要ステークホルダー・PM の権限の8つが軸。この記事では、各項目の書き方と作成5ステップ、記入サンプル、そして最も混同しやすい「前提条件と制約条件の違い」まで、初めて憲章を書く方が今日からドラフトできるように解説します。

なぜ憲章が効くのか。理由は、プロジェクトの失敗の多くが「実行の失敗」ではなく「立ち上げの合意不足」から生まれるからです。目的・範囲・権限を口頭やメールで曖昧に始めると、後から「そんな話は聞いていない」「それはスコープ外だ」という綱引きが延々と続きます。憲章は、その暗黙の前提を着手前に文書化して承認をもらうことで、後戻りできない合意の土台を作ります。

そもそもプロジェクト憲章とは？2つの役割

プロジェクト憲章は、PMBOK® ガイドで「プロジェクトの存在を正式に認可（authorize）し、プロジェクトマネージャーに組織の資源を投入する権限を付与する文書」と位置づけられています。作成タイミングは立ち上げ（Initiating）プロセス群——つまりプロジェクトの一番最初です。この憲章には、大きく2つの役割があります。

1. 正式な始動の承認：スポンサー（発注元・上位者）が承認することで、プロジェクトは初めて「公式」になる
2. PM への権限付与：憲章にサインされることで、PM は人・予算・設備といった組織資源を動かす権限を得る

裏を返すと、憲章がないままメンバーだけで走り始めたプロジェクトは、「誰が始めると決めたのか」「PM にどこまでの裁量があるのか」が宙に浮いたまま。だからこそ憲章は、PM が自分の立場と裁量を確保するための最初の武器でもあります。

プロジェクト憲章とプロジェクト計画書の違い

初学者が最も混同するのが、憲章とプロジェクト計画書の違いです。両者は作るタイミングも粒度もまったく異なります。

観点	プロジェクト憲章	プロジェクト計画書
作成タイミング	立ち上げ時（最初）	計画時（憲章の承認後）
目的	始動の承認と PM への権限付与	実行のやり方を具体化
粒度	ハイレベル（分かっていることだけ）	詳細（WBS・スケジュール・予算等）
分量	1〜数ページ	数十ページになることも
誰が承認するか	スポンサー	PM が作成しチームで合意

プロジェクト憲章に書く記載項目【8つの軸】

憲章に決まった様式はありませんが、PMBOK と各社テンプレートで共通して挙がる要素を整理すると、次の8項目に集約できます。これがそのままテンプレートの見出しになります。

#	記載項目	何を書くか
1	プロジェクトの目的・背景	なぜこのプロジェクトをやるのか（ビジネス上の理由・解決したい課題）
2	目標（成功基準）	何をもって成功とするか。測定可能な指標で書く（例：問い合わせ工数を30%削減）
3	スコープ（範囲）	やること／やらないこと。特に「やらないこと」を明記してスコープクリープを防ぐ
4	主要成果物・マイルストーン	最終的に何を納めるか、大きな節目はいつか（概算）
5	前提条件（Assumptions）	「〜が満たされている前提で進める」という成立条件
6	制約条件（Constraints）	予算・納期・法規制など、変えられない枠
7	主要ステークホルダー	スポンサー・PM・主要関係者と、その役割
8	PM の任命と権限	PM は誰か、どこまでの裁量（予算執行・要員調整等）を持つか

このほか、概算予算・全体リスク・承認者のサイン欄を加えると、より実務的な憲章になります。

プロジェクト憲章の書き方【5ステップ】

ステップ1｜目的とビジネス上の理由を固める

まず「なぜやるのか」を1〜2文で言い切ります。ここが曖昧だと、以降のすべてがぶれます。「業務効率化のため」ではなく「問い合わせ対応が月200時間を超え本業を圧迫しているため、その工数を削減する」というように、背景の痛みとセットで書くのがコツです。目的が明確なら、後で「これはやるべきか」の判断基準になります。

ステップ2｜目標を測定可能な成功基準にする

目的を、達成したかどうかを判定できる目標に落とし込みます。「使いやすいシステムを作る」では成功を判定できません。「問い合わせ対応工数を6か月で30%削減する」「受注リードタイムを5営業日→2営業日にする」のように、数値と期限を入れます。ここで決めた成功基準が、プロジェクト終結時の評価軸になります。

ステップ3｜スコープと前提・制約を洗い出す

「やること」と同じくらい「やらないこと」を明記します。範囲の外側を憲章で釘刺ししておくことが、後の「これもついでにお願い」というスコープの膨張を止める最大の防波堤です。あわせて、成立の前提（前提条件）と動かせない枠（制約条件）を書き出します（両者の違いは後述）。この段階ではリスクも”想定される大きなもの”だけハイレベルに拾えば十分です。

ステップ4｜ステークホルダーと PM の権限を明記する

スポンサーは誰か、PM は誰か、主要関係者は誰か——ステークホルダーを役割ベースで並べます。そして最も忘れられがちで最も重要なのが PM の権限の明記です。「PM は◯◯万円までの予算執行権を持つ」「要員のアサイン変更を決定できる」と書いておくことで、PM は毎回上位者にお伺いを立てずに動けます。

ステップ5｜スポンサーの承認を得て共有・ベースライン化する

ドラフトができたら、スポンサー（承認者）のレビューとサインをもらいます。ここで承認されて初めて憲章は効力を持ちます。承認後は関係者全員がアクセスできる場所に置き、以降の判断（スコープ変更・優先順位づけ）の基準文書として参照します。憲章は原則として頻繁に書き換えるものではなく、大きな前提が覆ったときにだけ正式な変更手続きで更新します。

前提条件と制約条件の違い

8項目の中で特につまずきやすいのが、**前提条件（Assumptions）と制約条件（Constraints）**の書き分けです。

• 前提条件＝「〜が成り立っている前提で計画を立てる」という、真偽が未確定だが正しいと仮定して進める事項。例：「発注元から必要データが4月末までに提供される前提」「専任メンバーを3名確保できる前提」。前提が崩れると計画が狂うため、リスクの発生源でもあります。
• 制約条件＝「チームの努力では変えられない、守るべき枠」。例：「予算は500万円以内」「本番稼働は9月末まで（法改正対応のため延期不可）」「使用言語は既存システムに合わせる」。

見分け方はシンプルで、「自分たちで決められない外枠」なら制約、「そうであってほしい・そうだと見込んでいる仮定」なら前提です。前提条件は明文化しておくと、後で崩れたときに「前提が変わったのでスコープを見直す」と正当に交渉できます。

記入サンプル（Web システム導入プロジェクト）

イメージをつかむために、ミニマムな記入例を示します。実務では各項目をもう少し肉付けします。

項目	記入例
目的・背景	問い合わせ対応が月200時間を超え本業を圧迫。FAQ システム導入で対応工数を削減する
目標（成功基準）	稼働後6か月で問い合わせ対応工数を30%削減する
スコープ	◯ FAQ 構築・既存問い合わせ分析／✕ 電話対応フローの刷新は対象外
主要成果物	FAQ サイト、運用マニュアル、効果測定レポート
前提条件	過去問い合わせデータが5月末までに提供される
制約条件	予算300万円以内、本番稼働は10月末まで
主要ステークホルダー	スポンサー＝カスタマー部長／PM＝◯◯／協力＝情シス・CS チーム
PM の権限	100万円までの予算執行、協力メンバーのタスク割当を決定できる

プロジェクト憲章のメリット・デメリット

プロジェクト憲章でよくある失敗5選

1. 詳細を書き込みすぎる：憲章に WBS や詳細スケジュールまで書こうとして立ち上げが止まる。憲章は「今わかっていること」だけのハイレベルで十分。詳細は計画フェーズで。
2. スポンサーの承認を取らない：PM が一人で書いて満足し、正式承認がないまま走る。権限も正当性も生まれない。
3. 目標が測定不能：「使いやすくする」など判定できない目標にする。数値と期限を入れる。
4. 「やらないこと」を書かない：スコープの外側を明記せず、後から次々と依頼が乗って膨張する。
5. 作りっぱなしで参照されない：承認後に共有・活用されず、誰も見ないファイルになる。判断の基準文書として使い続ける。

よくある質問（FAQ）

Q. プロジェクト憲章は誰が作りますか？ A. 一般には PM（またはスポンサー）がドラフトを作成し、スポンサーが承認します。PMBOK の考え方では憲章はスポンサー（またはプロジェクト立ち上げ者）が発行する文書であり、実務では PM が原案を書いてスポンサーの承認を得る流れが多いです。

Q. 小規模なプロジェクトでも憲章は必要ですか？ A. 規模に応じて簡略化すればよく、A4 で半ページ程度でも構いません。重要なのは体裁より「目的・範囲・権限・承認」の4点が押さえられていること。小さくても「何のために・どこまで・誰の承認で」を1枚にする価値はあります。

Q. プロジェクト憲章とプロジェクト計画書はどちらを先に作りますか？ A. 憲章が先です。憲章で「やること」と「PM の権限」を承認してもらってから、その枠内で計画書（WBS・スケジュール・予算）を詳細化します。順番が逆になると、承認のない計画に工数を投じるリスクがあります。

Q. 前提条件と制約条件を間違えると何が問題ですか？ A. 前提条件は「崩れうる仮定」なのでリスク管理の対象になりますが、制約条件は「守るべき固定枠」です。両者を混同すると、本来監視すべき前提を見落としたり、動かせない制約を「調整できる」と誤解したりして、計画が破綻します。

まとめ｜憲章は「立ち上げの合意」を1枚に固める道具

プロジェクト憲章の書き方は、次の5ステップに集約されます。

1. 目的・背景を固める：なぜやるのかを、背景の痛みとセットで1〜2文で言い切る
2. 目標を測定可能にする：数値と期限を入れ、成功を判定できる成功基準にする
3. スコープ・前提・制約を洗い出す：特に「やらないこと」を明記して膨張を防ぐ
4. ステークホルダーと PM 権限を明記する：PM の裁量範囲を書いて動ける状態を作る
5. 承認を得て共有・ベースライン化する：スポンサーのサインで初めて憲章は効力を持つ

憲章の本質は、プロジェクトが動き出す前に「何を・なぜ・どこまで・誰の承認で」を1枚に固め、後戻りできない合意の土台を作ることにあります。そして最大の勘所は、詳細を書き込みすぎず、必ずスポンサーの承認を取ること。まずは今日、直近の案件について目的・目標・スコープの3項目だけでもドラフトしてみてください。「そもそも何のためにやるんでしたっけ？」が、プロジェクトの途中で出てこなくなります。

憲章で決めたスコープを実際のタスクに分解する手順は「WBS の作り方」で、関係者の洗い出しと巻き込みは「ステークホルダーマネジメント完全ガイド」で詳しく解説しています。あわせてどうぞ。