プロジェクト憲章とは：記載項目とプロジェクト計画書との違い、システム開発での作り方

プロジェクト憲章は、プロジェクトの存在を正式に認め、プロジェクトマネージャーに組織の予算や人員を使う権限を渡すための文書です。この記事では、PMBOK第8版の定義と、総務省が2026年3月に公開した実践ガイドを下敷きに、プロジェクト憲章に書く項目、プロジェクト計画書との違い、システム開発で発注者が作る手順と記入例を示します。小規模案件で憲章を省いてよい条件と、署名だけで終わる失敗パターンもあわせて整理しました。

まとめ：プロジェクト憲章は着手の承認と目的・権限をA4数枚で確定する文書

プロジェクト憲章が決めるのは「なぜやるのか」「何をもって成功とするか」「誰にどこまで任せるか」の3点です。スケジュールの細部や会議体の運営ルールは書きません。それらは憲章の承認後に作るプロジェクト計画書の役割です。

書き手はスポンサー、つまり予算を出して着手を決める側です。システム開発を外注するなら、憲章は発注者が書き、受託側は内容が見積と工程に落とせるかを確認する立場になります。分量はA4で1〜2枚が目安です。

関係者が1部門と受託側1社だけの短期案件なら、独立した憲章は作らず、計画書の冒頭1章に吸収して構いません。反対に、複数部門が使う業務システムや予算の承認者と現場の責任者が別人の案件では、憲章を省くと権限の空白が残ります。

プロジェクト憲章とは：PMBOK第8版の定義と総務省ガイドが示す2つの役割

PMBOK第8版の定義：プロジェクトを正式に認可し権限を渡す文書

プロジェクトマネジメントの知識体系であるPMBOKガイドは、2025年刊行の第8版でもプロジェクト憲章を立ち上げ時の中核文書としています。総務省の実践ガイド「プロジェクト憲章の作成」によると、第8版は憲章を、プロジェクトの発起者またはスポンサーが発行し、プロジェクトの存在を正式に認可したうえで、プロジェクトマネージャーに組織のリソースを使う権限を付与する文書と定義しています。

要点は「認可」と「権限」の2語です。憲章が承認されるまで、プロジェクトは組織の正式な活動ではありません。予算を使う、他部署の担当者に作業を依頼する、外部ベンダーに見積を取るといった行為の根拠が、ここで初めてできます。

総務省の実践ガイドが加えた見方：関係者で目的と期待をすり合わせる場

総務省のユーザー向けガイド（2026年3月）は、行政運営の変革に関する調査研究事業の一環で作られた資料です。PMBOKの考え方を前提にしつつ、憲章を「なぜそのプロジェクトに取り組むのか」「なぜ私たちが関わるのか」という＜Why＞を共有するものとして位置づけています。

同ガイドは、スケジュールや数値目標を決める前にゴールと役割をすり合わせる手順として、ゴール・プロジェクトストーリー・お互いへの期待・価値観の4つのワークを示しています。時間が限られる場合は、ゴールと期待の2つだけでも実施するよう優先度を付けている点が実務的です。

システム開発に当てはめると、PMBOK型は「決裁の記録」、総務省型は「関係者の合意形成」に重心があります。発注者の社内では前者、受託側を交えた立ち上げでは後者の要素が効きます。

プロジェクト憲章の記載項目：目的・成功基準・権限・制約を書く8つの欄

総務省ガイドは、PMBOKにおけるプロジェクト憲章の内容として次の8項目を挙げています。システム開発で書くときの読み替えを右列に添えました。

このうち実務で効くのは、成功基準・権限・終了基準の3欄です。残りは計画書で詳しく書くため、憲章では1〜2行の要約で足ります。

目的と成功基準：業務の数値と終了の条件を1行ずつ決める書き方

目的欄に「基幹システムを刷新する」と書いても判断の基準になりません。刷新によって解消したい業務上の問題を書きます。成功基準は数値と時期をセットにし、「請求書の発行作業を月20時間から5時間にする（稼働後6か月時点）」のように書いてください。

終了基準は成功基準と別物です。成功基準は効果の目標、終了基準は「受入テストの完了と旧システムの停止をもってプロジェクトを閉じる」といったプロジェクトの区切りを指します。終了基準がないと、稼働後の改修要望が同じ予算枠で延々と続きます。

プロジェクトマネージャーの権限：単独で決めてよい金額と範囲の書き方

権限欄は、憲章でしか決められない欄です。誰をプロジェクトマネージャーに任命し、何を単独で決めてよいかを書きます。「仕様変更は1件50万円未満なら単独で承認、それ以上はスポンサーの承認」「利用部門の担当者に週4時間までの作業を依頼できる」のように、金額と工数で線を引くと運用できます。

発注者側のプロジェクトマネージャーが課長級で、予算の決裁権は部長にある、という組織は珍しくありません。この差を憲章で埋めておかないと、受託側から変更の判断を求められるたびに社内の稟議待ちが発生し、工程が止まります。

制約・前提・全体リスク：憲章では要約に留める欄の具体的な書き方

制約は動かせない条件です。「稼働日は2027年4月1日」「既存の会計システムは改修しない」「個人情報は国内のサーバーに置く」のように、交渉の余地がないものだけを書きます。前提は見積が成り立つ条件で、崩れたら憲章を見直す合図になります。

リスクは、着手前から見えている大きなものを2〜4件に絞ります。影響度と対応策まで書き込むのは計画書の仕事です。憲章の段階で細かいリスク表を作ると、承認者が読まずに署名する原因になります。

プロジェクト憲章とプロジェクト計画書の違い：決める人・粒度・作る順番の比較

憲章と計画書を5つの観点で比べた比較表と記載内容の書き分けの目安

総務省ガイドは、憲章を＜Why＞と価値観を共有するもの、計画を＜How＞を明確にするもの（スケジュール・WBS・会議体の設計・ツールやルール）と分けています。システム開発の文書として並べると、違いは次のとおりです。

計画書は憲章の内容を前提に詳細を書き足す文書です。章立てと記入例はプロジェクト計画書の書き方と発注者・受託側の分担で扱っています。投資の可否そのものを検討する段階なら、憲章より前にシステム企画書で構想と計画の範囲を決めます。

憲章を飛ばして計画書から書き始めたときに起きる手戻りの具体例

多いのは、受託側がひな形で計画書を作り、発注者が目的欄を「業務効率化」のまま承認するケースです。成功基準が空白なので、要件定義で利用部門の要望がすべて「必要」と判断され、見積が当初の1.5倍に膨らみます。

次に多いのが、権限が書かれないまま開発に入るケースです。仕様変更のたびに部長決裁を待ち、2週間単位で工程が止まります。どちらも計画書の出来ではなく、その前の憲章で決めるべきことが決まっていないのが原因です。

システム開発でプロジェクト憲章を作る手順：発注者が書く範囲と受託側に渡す時期

作成の6ステップ：素案から役員の署名、キックオフでの共有まで

発注者の社内で憲章を作る場合、次の順で進めると承認まで1〜2週間で収まります。

1. スポンサーを決める（予算を承認できる役員）
2. 目的・成功基準・終了基準の素案を担当者が書く
3. 利用部門の代表と、目的と範囲の認識をすり合わせる
4. プロジェクトマネージャーを任命し、権限の線を決める
5. 予算の上限と制約を書き、スポンサーが署名する
6. 受託側を含めた立ち上げの場で全員に共有する

3の工程は、総務省ガイドの「お互いの役割への期待をすり合わせるワーク」が参考になります。各自がこのプロジェクトに関われる時間（週の業務時間に占める割合）、自分の役割、支援してほしいこと、他の人への期待を書き出して共有する方法です。お互いの人となりを知るワークと合わせた進行例が示されており、各段の時間を足すと60分になります。

6の共有の場は、受託側と初めて顔を合わせるキックオフミーティングの議題と事前準備に組み込むのが自然です。ベンダー選定前であれば、憲章の目的と成功基準をそのままRFPの記載項目に転記できます。

記入例：受発注システム刷新の憲章をA4一枚にまとめた欄と内容

従業員80名の卸売業が、FAXと表計算で回している受発注業務をシステム化する場合の記入例です。

これだけで、追加要望が出たときに「目的に合うか」「上限内か」「誰が決めるか」の3つを即座に判定できます。工程の詳細や会議体は、この憲章の承認後に計画書で書き足します。

発注者が書く欄と受託側が確認する欄の分担、外部のPMO支援を入れる場面

憲章は発注者の文書です。目的・成功基準・予算の上限・権限・認可者は、受託側が推測で埋めてはいけない欄にあたります。受託側の役割は、成功基準が測定できるか、稼働希望日と予算で実現できるかを確認し、無理があれば憲章の段階で指摘することです。

発注者の社内に、こうした文書をまとめた経験者がいない場合もあります。その場合は、受託ベンダーとは別の立場で発注者側の文書づくりを支える外部支援を入れることも選択肢の一つです。一創の要件定義・RFP作成・PMO支援では、憲章や計画書の目的・範囲・体制の欄を発注者と一緒に整理し、ベンダーの提案や工程案の妥当性を確認する形で関わります。

プロジェクト憲章を作らなくてよい案件の条件と、署名だけで終わる失敗パターン

独立した憲章を省き計画書の冒頭1章に吸収してよい案件規模の目安

次の条件をすべて満たす案件では、独立した憲章は過剰です。関係者が社内の1部門と受託側1社だけ、期間が3か月以内、予算の承認者とプロジェクトマネージャーが同一人物。この場合は、計画書の第1章に目的・成功基準・終了基準を書けば十分で、別文書にすると承認の手間だけが増えます。

一方、複数部門が使う業務システム、予算の承認者と現場の責任者が別人の案件、複数ベンダーが関わる案件では、憲章を省いてはいけません。権限の線が文書にないと、判断が必要な場面で誰も決められない状態になります。

署名だけの憲章で終わる失敗パターンと、見直しを入れるタイミング

典型は、役員の署名を取った時点で役目を終えたとみなし、二度と開かれない憲章です。要件定義の後に予算が増えても憲章の上限が書き換えられず、どの金額が承認済みなのか誰も答えられなくなります。

総務省ガイドは、憲章の使いどころをプロジェクト開始時と推進時の2つに分け、推進時にも内容の確認や振り返り、更新に使うとしています。システム開発では、要件定義の完了時と稼働判定の前に、成功基準と予算の上限が現状と合っているかを確認する議題を定例に入れてください。変えた場合は版数を上げ、認可者の署名を取り直します。

もう1つの失敗は、項目を埋めることが目的化した厚い憲章です。リスク表や詳細日程まで書き込んだ10ページの憲章は、承認者に読まれません。計画書と重複する欄は削り、1〜2枚に収めてください。

プロジェクト憲章のよくある質問：テンプレート・書き手・PMBOKとの関係まで

プロジェクト憲章について、システム開発の発注担当者からよく寄せられる質問をまとめました。

プロジェクト憲章のテンプレートはどこで手に入りますか？

公的な資料では、総務省の実践ガイド「プロジェクト憲章の作成」がユーザー向けガイドとワークシートを公開しています。ゴール・役割・価値観のすり合わせに重心がある様式なので、システム開発で使う場合は、本記事の記載項目表から予算の上限・権限・終了基準・認可者の欄を足してください。社内に過去案件の起案書があれば、それを土台にするほうが承認は通りやすくなります。

プロジェクト憲章は誰が作成し、誰が承認するものですか？

PMBOKの定義では、発起者またはスポンサーが発行します。実務では、発注者側の担当者やプロジェクトマネージャーが素案を書き、予算を承認する役員がスポンサーとして署名する形が一般的です。受託側が書くものではありませんが、成功基準や稼働日の実現性については受託側の確認を経てから確定させると、後の見積とのずれを防げます。

プロジェクト憲章とプロジェクト計画書はどちらを先に作りますか？

憲章が先です。憲章で着手の承認と目的・成功基準・権限を確定し、その内容を前提に計画書で範囲・工程・体制・管理方法を書き足します。計画書から書き始めると、目的や権限が空白のまま詳細だけが決まり、要件定義で範囲が膨らむ原因になります。小規模案件で憲章を省く場合も、計画書の第1章に同じ内容を書いてください。

プロジェクト憲章の分量はどのくらいが適切ですか？

A4で1〜2枚が目安です。承認者が数分で読み切れ、追加要望の判断に使える分量に留めます。リスクの詳細、作業単位の日程、会議体の運営ルールは計画書に回します。分量が5ページを超えそうなら、計画書と重複している欄がないかを点検してください。

PMBOKの版が変わるとプロジェクト憲章の位置づけも変わりますか？

総務省の実践ガイドによると、2025年刊行の第8版でも、プロジェクト憲章は立ち上げフェーズの中核文書として、プロジェクトを正式に認可し権限を付与する文書と定義されています。社内の様式を版の改訂に合わせて作り直す必要はありません。改訂時は、PMBOKが挙げる記載項目と自社の様式を突き合わせ、欄の過不足だけを点検すれば足ります。

関連記事

• プロジェクト計画書の書き方：システム開発で書く項目とテンプレート、発注者と受託側の分担：憲章の承認後に作る計画書の章立てと記入例
• キックオフミーティングとは：システム開発の議題・資料・参加者と発注者が事前に決めること：憲章を受託側と共有する立ち上げの場
• システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】：憲章と計画書を作った後の管理の進め方
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：権限と管理を支える組織の置き方
• WBSとは？書き方・作り方の5ステップとシステム開発の例、ガントチャートとの違い：計画書の工程を作業単位に分解する方法