プロジェクトが号令だけで始まってしまったときのプロジェクト憲章テンプレート：承認権限・スコープ概要・成功基準を1枚にする

プロジェクト憲章チェックリスト：10項目を1枚にまとめる

承認も、スコープも、成功の定義も合意されないまま、プロジェクトが号令だけで動き出すことがあります。プロジェクト憲章（プロジェクトチャーター）は、この状態を1枚の文書で終わらせるための立ち上げ文書です。下の10項目を順に埋めれば、着手前に合意しておくべきことが揃います。

空欄のまま配布しても機能しません。関係者を集めて1項目ずつ埋め、最後にスポンサーの署名をもらったところで初めて、この文書は「合意の証拠」になります。

この1枚が無いと、何がどこで崩れるか

承認も、スコープも、成功の定義も合意されないまま着手すると、崩れる場所は大体決まっています。スコープが合意されていないと、終盤に「それもやってもらえると思っていた」が出てきます。目的の共通理解がないと、途中で優先順位を聞かれたときの答えが人によって変わります。権限が確立していないと、PMは資源を動かす根拠を持たず、何かを決めるたびにその場で許可を取りにいくことになります。

いずれも、プロジェクトが半分進んだ段階で初めて表面化する問題です。着手前の1枚に時間をかける理由は、ここにあります。

この「着手前に固めておく」という考え方は、要件定義の段階でも同じ構造で現れます。IPA（情報処理推進機構）の分析では、信頼性が高いグループと低いグループに分けたとき、要件定義書密度（要件定義書のページ数をファンクションポイントで割った値）の中央値は、高いグループで約0.15ページ/FP、低いグループで約0.08ページ/FPと約2倍の差があります。同じ分析で、上流工程（基本設計〜製作）での不具合摘出比率の中央値は、信頼性が高いグループの約85%に対し、低いグループでは約66%でした。要件や前提を着手前にどれだけ具体的な文書として固めるかは、後工程で問題をどれだけ早く見つけられるかという差に表れています。

この10項目は、どうやって決めたか

PMBOK第8版は、プロジェクトマネジメントの知識体系を7つのパフォーマンス領域（ガバナンス、ステークホルダー、スコープ、スケジュール、資源、リスク、ファイナンス）に再編しています。その全体像と、各領域で最初に作る成果物の対応はPMBOK®第8版の7つのパフォーマンス領域を、実際の作業に落とすにまとめています。

block-1の10項目は、規格書の特定の章立てをそのまま転記したものではありません。承認・スコープ・成功基準・リスク・予算・権限という、着手前に関係者間で揺れやすい論点を、実務で1枚に書き切れる単位にまとめたものです。欄の数が規格と一致しているかどうかより、10項目が実際に埋まり、スポンサーの署名まで到達するかどうかのほうが重要になります。

目的・背景：『業務効率化のため』で止めない

最初の欄で最も形骸化しやすいのが、目的・背景です。「業務を効率化する」「顧客満足度を上げる」という書き方は、誰も反対できない代わりに、誰の判断にも使えません。書き方の実務的なコツは、目的を背景にある痛みとセットで固めることです。「月次決算の締めに5営業日かかり、経営判断が遅れている」という具体的な困りごとがあって、初めて「なぜこのプロジェクトか」が意味を持ちます。

痛みを具体化すると、副次的な効果もあります。プロジェクトの途中で優先順位を聞かれたとき、「この痛みを解決する方向か」という1つの軸で判断できるようになります。目的が抽象的なままだと、同じ質問への答えが会議ごとに変わります。

成功基準に書くこと・書かないこと：憲章とWBS・予算計画の境界

憲章にありがちな失敗が、成功基準を「期限内・予算内に完了する」だけで済ませることです。これはQCDの制約であって、プロジェクトが生み出すべき価値の基準ではありません。成功基準は、数値と期限を備え、プロジェクトが終わった時点で達成したかどうかを1文で判定できるレベルまで書きます。

ここで迷いやすいのが、どこまで詳しく書くかです。目安は、憲章とWBS・予算計画の境界で引きます。憲章に書くのは、プロジェクト全体で1〜3個に絞った、終了時点の到達目標だけで足ります。「顧客満足度スコアを60日以内に4.2以上にする」のように、数値と期限がある1文で十分です。

週次・月次で追いかける細かいKPI、測定方法の設計、ベースラインの取り方は、憲章の仕事ではありません。それらはWBSで作業を分解したあと、予算計画やモニタリング計画の中で決めます。憲章の段階で細部まで詰めようとすると、着手が遅れるだけでなく、後工程で変わる可能性がある数字に、着手前の合意が縛られることになります。

スコープ概要は『やらないこと』を書いたときに機能する

スコープ概要の欄で実施範囲だけを書き、非実施範囲を省略する憲章が多く見られます。しかし「やらないこと」の未記載は、プロジェクト憲章が機能不全を起こす典型例の一つです。範囲を書かないままプロジェクトが進むと、終盤に出てくる要望がすべて「当然やること」として扱われ、スコープクリープに直結します。

対処は単純で、スコープ概要の欄に「やらないこと」を最低1項目書くことです。「既存システムとの自動連携は本プロジェクトの範囲外とし、次期フェーズで検討する」のように、時期つきで書けば、拒否ではなく優先順位の話として受け止められます。

成果物を漏れとダブりなく分解する手順そのものは、憲章の役割ではありません。スコープ概要が決まったあとの分解手順はWBSの作り方にまとめています。憲章はこの分解に入る前に、何を分解の対象にするかの境界を決める文書です。

PMの権限は3段階で書く：単独決定・是正要求・上申

権限の欄を「PMに権限を委任する」という一文で済ませる憲章は、実務ではほとんど機能しません。この正式な許可がなければ、チームは時間・費用・人員をその作業に投じる根拠を持たないことになります。権限は行為の単位で、3段階に分けて書くのが実務的です。

第1段階は、PMが単独で決めてよいことです。担当の割り当て、週次会議の運営、作業手順の調整などが該当します。第2段階は、PMが是正を求められることです。遅延が見えている作業への対応要求、リスクが登録されていない項目の指摘などが入ります。第3段階は、PMが判断せずスポンサーに上げることです。この境界を具体的な事象で書いておくと、誰が見ても同じ判断になります。

どの事象を上申の対象にするかは、憲章そのものを立て直す必要があるかどうかで線引きすると判断しやすくなります。当初の境界を超えるスコープの拡大、新たな承認が要る規模の予算増加、責任の所在が変わるスポンサーの交代の3つは、どれも憲章に書いた前提そのものが崩れる変更であり、PMの判断だけで進めてよい範囲を超えます。この発想は、PMOの権限文書を書くときの考え方とも共通しています。詳しくはPMO立ち上げの実務ガイドの「権限の明文化」の章にまとめています。

終了基準と承認：いつ完了と言えるか、誰の署名で始まるか

終了（エグジット）基準の欄が抜けている憲章は珍しくありません。しかし「いつ完了と言えるか」を着手前に書いておかないと、終結の段になって「まだ完了していない」という主張が後から出てきます。成功基準が「何を達成するか」を定めるのに対し、終了基準は「どの状態になったら、このプロジェクトを終わらせてよいか」を定めるものです。両者は似ていますが、別の欄として書いてください。

承認の欄は、スポンサーの署名と日付で完結します。憲章が承認されることで、PMは人・予算・設備といった組織資源を動かす権限を得ます。署名のない憲章は、関係者間の合意の証拠として機能しません。口頭での「OK」で済ませず、署名と日付を残してください。

よくある機能不全：線引きをしないまま運用するとどうなるか

プロジェクト憲章そのものは作成されても、機能しなくなるパターンは大体同じ形をしています。多くは、本記事で挙げた2つの線引き--上申の基準、憲章とWBS・予算計画の境界--を決めずに運用したときに起きます。

明日、この1枚を関係者に見せるまでにやること

まず自分で、目的・背景、測定可能な目標・成功基準、スコープ概要（やること／やらないこと）の3欄だけを書いてみます。ここまでは1人で下書きできます。成功基準は、憲章とWBS・予算計画の境界を意識し、到達目標を1〜3個に絞ってください。

次に、決裁権を持つ相手を1人見つけ、前提条件・制約条件、概算予算、主要ステークホルダーの3欄を一緒に確認します。この段階で金額や範囲について相手の反応が変わるなら、それは着手前に分かってよかった情報です。

最後に、PMの権限を単独決定・是正要求・上申の3段階で書き、終了基準を添えて、スポンサーの署名をもらいます。署名が取れない場合は、権限文書の内容を実行する相手が見つかっていないということです。その状態で計画を先に進めるのは避けてください。

10項目すべてを完璧に埋めることよりも、この1枚を関係者が実際に開いて判断に使うかどうかのほうが重要です。作って配って終わりにせず、優先順位や権限の判断が必要になった場面で、この憲章を開く運用を最初の会議で決めておいてください。