プロジェクト憲章の書き方｜テンプレート全文とシステム開発の記入例

プロジェクト憲章とは、プロジェクトの開始を正式に認め、目的・成功基準・責任者と権限を1〜2ページにまとめて、スポンサーが承認する文書です。

この記事では、そのまま貼って使えるMarkdownテンプレートの全文、架空の「備品管理システム刷新」を題材にした記入例の全文、A4半分の短縮版を載せています。あわせて、あいまいな書き方を直す対比表、成功基準を測れる形に直す例10組、似た文書との違い、記入漏れを検出するPythonスクリプトと出力もまとめました。

確認環境：Ubuntu 24.04／Python 3.11.15（スクリプトは標準ライブラリのみで動作）。

プロジェクト憲章の早見表

プロジェクト憲章は「詳しい計画」ではなく「始めてよいという合意」です。細かな作業や日程はプロジェクト計画書に書くので、憲章は1〜2ページに収めます。PMBOKガイド第7版でも、プロジェクト憲章は「モデル・方法・作成物」のうち作成物の1つとして扱われています。

プロジェクト憲章のテンプレート全文（Markdown）

下のブロックをそのままコピーして、{ } の部分を書き換えてください。10項目すべてを埋めるとA4で1〜2ページになります。

# プロジェクト憲章：{プロジェクト名}

- 文書番号：{PC-YYYY-NNN}
- 版：{0.1}　作成日：{YYYY-MM-DD}
- 作成者：{氏名（役割）}
- スポンサー：{氏名（役職）}
- プロジェクトマネージャー：{氏名}

## 1. 目的

{このプロジェクトで何を実現するかを1〜2文で。「誰の」「何が」「どうなる」を入れる}

## 2. 背景

{なぜ今やるのか。現状の数字と、放置した場合に起きることを2〜4行で}

## 3. 成功基準

| No | 指標 | 現状 | 目標 | 測定方法と時期 |
|---|---|---|---|---|
| 1 | {指標名} | {数値} | {数値} | {どのデータで・いつ測るか} |
| 2 | {指標名} | {数値} | {数値} | {どのデータで・いつ測るか} |
| 3 | {指標名} | {数値} | {数値} | {どのデータで・いつ測るか} |

## 4. 概要スコープ

**含むもの**

- {対象の業務・機能・拠点}

**含まないもの**

- {今回は対象外とするもの。理由も一言}

## 5. 主要マイルストーン

| No | マイルストーン | 予定日 | 完了の判定 |
|---|---|---|---|
| 1 | {例：要件定義の完了} | {YYYY-MM-DD} | {誰が何を承認したら完了か} |
| 2 | {例：受入テストの完了} | {YYYY-MM-DD} | {誰が何を承認したら完了か} |
| 3 | {例：本番稼働} | {YYYY-MM-DD} | {誰が何を承認したら完了か} |

## 6. 概算予算

| 区分 | 金額（税抜） | 根拠 |
|---|---|---|
| 初期費用 | {金額} | {見積りの前提} |
| 運用費用（年額） | {金額} | {見積りの前提} |
| 予備費 | {金額} | {初期費用の何%か} |

- 見積りの精度：{例：−10%〜+25%}

## 7. 主なリスク

| No | リスク | 影響 | 最初の対応 |
|---|---|---|---|
| 1 | {起きるかもしれないこと} | {大・中・小と内容} | {誰が何をするか} |
| 2 | {起きるかもしれないこと} | {大・中・小と内容} | {誰が何をするか} |
| 3 | {起きるかもしれないこと} | {大・中・小と内容} | {誰が何をするか} |

## 8. 前提と制約

**前提（正しいと仮定して計画すること）**

- {例：利用部門から担当者2名が週8時間参加できる}

**制約（変えられない条件）**

- {例：期末処理の期間は切り替え作業を行わない}

## 9. 責任者と権限

| 役割 | 氏名 | 決められること |
|---|---|---|
| スポンサー | {氏名} | {予算・期間・スコープの変更承認、中止の判断} |
| プロジェクトマネージャー | {氏名} | {予算内の発注、体制内の作業割り当て、変更の起票} |
| 業務責任者 | {氏名} | {業務要件の優先順位、受入の合否} |

- プロジェクトマネージャーが単独で決められる範囲：{例：1件50万円までの支出、5営業日までの日程調整}
- 上記を超える場合の相談先と期限：{例：スポンサーへ3営業日以内に報告}

## 10. 承認欄

| 役割 | 氏名 | 承認日 | 署名 |
|---|---|---|---|
| スポンサー | {氏名} | {YYYY-MM-DD} | {署名} |
| プロジェクトマネージャー | {氏名} | {YYYY-MM-DD} | {署名} |
| 業務責任者 | {氏名} | {YYYY-MM-DD} | {署名} |

テンプレートの使い方

最初から完成形を目指さず、空欄が残った版0.1をスポンサーに見せると、認識の違いが早く見つかります。

システム開発の記入例（全文）

架空の社内システム刷新「備品管理システム刷新」を題材にした記入例です。数字・日付・氏名はすべて架空です。自分のプロジェクトに合わせて書き換えてください。

# プロジェクト憲章：備品管理システム刷新

- 文書番号：PC-2026-014
- 版：1.0　作成日：2026-10-07
- 作成者：佐藤 花子（プロジェクトマネージャー）
- スポンサー：田中 一郎（管理本部長）
- プロジェクトマネージャー：佐藤 花子

## 1. 目的

総務部と各拠点の担当者が、備品の貸出・返却・棚卸しを1つのWebシステムで行えるようにし、棚卸しにかかる時間と台帳の食い違いを減らす。

## 2. 背景

- 備品台帳は拠点ごとの表計算ファイル（5拠点・計約3,200件）で管理しており、年2回の棚卸しに合計約120時間かかっている。
- 2026年3月の棚卸しでは、台帳と現物の食い違いが96件（3.0%）あった。
- 現行の貸出申請はメールで、申請から貸出までの平均日数は2.4営業日である。
- 2027年4月に拠点が1つ増える予定で、現在の方法のままでは棚卸し時間がさらに増える。

## 3. 成功基準

| No | 指標 | 現状 | 目標 | 測定方法と時期 |
|---|---|---|---|---|
| 1 | 棚卸しの合計作業時間 | 約120時間／回 | 40時間以下／回 | 2027年9月の棚卸しで各拠点の作業記録を集計 |
| 2 | 台帳と現物の食い違い率 | 3.0%（96件） | 0.5%以下 | 2027年9月の棚卸し結果をシステムから出力 |
| 3 | 貸出申請から貸出までの平均日数 | 2.4営業日 | 1.0営業日以下 | 稼働後3か月（2027年5〜7月）の申請データを集計 |
| 4 | 稼働後3か月の利用率 | ― | 貸出申請の95%以上がシステム経由 | 申請件数とメール申請件数を月次で比較 |

## 4. 概要スコープ

**含むもの**

- 備品台帳（PC・モニター・什器・貸出用機材）の登録・検索・履歴管理
- 貸出・返却の申請と承認（Webとスマートフォンのブラウザ）
- バーコードを使った棚卸し機能
- 既存5拠点の台帳データ（約3,200件）の移行
- 利用者向けの操作説明会（拠点ごとに1回）

**含まないもの**

- 固定資産の会計処理（会計システム側で継続。連携は次期の検討事項とする）
- 消耗品（文具など）の在庫管理
- 購買申請のワークフロー

## 5. 主要マイルストーン

| No | マイルストーン | 予定日 | 完了の判定 |
|---|---|---|---|
| 1 | プロジェクト憲章の承認 | 2026-10-16 | スポンサーが承認欄に署名 |
| 2 | 要件定義の完了 | 2026-11-27 | 業務責任者が要件定義書を承認 |
| 3 | 設計の完了 | 2026-12-25 | プロジェクトマネージャーが設計レビューの指摘ゼロを確認 |
| 4 | 受入テストの完了 | 2027-03-12 | 業務責任者が受入テスト結果を承認 |
| 5 | 本番稼働 | 2027-04-05 | スポンサーが稼働判定会議で承認 |
| 6 | 効果測定と終了報告 | 2027-09-30 | スポンサーが終了報告書を承認 |

## 6. 概算予算

| 区分 | 金額（税抜） | 根拠 |
|---|---|---|
| 初期費用 | 1,800万円 | 開発18人月×90万円＋バーコードリーダー20台180万円 |
| 運用費用（年額） | 240万円 | クラウド利用料月12万円＋保守月8万円 |
| 予備費 | 180万円 | 初期費用の10% |

- 見積りの精度：−10%〜+25%（要件定義の完了時に再見積りする）

## 7. 主なリスク

| No | リスク | 影響 | 最初の対応 |
|---|---|---|---|
| 1 | 拠点ごとに台帳の項目が異なり、データ移行の手直しが増える | 大：稼働が1か月遅れる | 10月中に佐藤が5拠点の台帳を集め、項目の差を一覧にする |
| 2 | 利用部門の担当者が繁忙期（12月・3月）に参加できない | 中：要件確認と受入テストが遅れる | 業務責任者が11月初めに参加日を確定し、代理者を決める |
| 3 | バーコードラベルの貼り付けが稼働日までに終わらない | 中：棚卸し機能が一部拠点で使えない | 2月から拠点ごとに貼り付け日を決め、週次で進み具合を確認する |
| 4 | 稼働後に従来のメール申請が残り、利用率が上がらない | 中：成功基準4に届かない | 稼働日にメール申請の受付を終了すると10月中に周知する |

## 8. 前提と制約

**前提（正しいと仮定して計画すること）**

- 総務部から担当者2名が週8時間、プロジェクトの作業に参加できる。
- 既存の社内認証基盤（シングルサインオン）と連携できる。
- 各拠点にバーコードラベルを貼る作業は、拠点の担当者が行う。

**制約（変えられない条件）**

- 本番稼働は2027年4月の拠点追加より前に終える。
- 期末（3月16日〜31日）は切り替え作業を行わない。
- 初期費用は予備費を含めて1,980万円以内とする。
- 個人名を含むデータは社内の情報管理規程に従い、国内のクラウド環境に保存する。

## 9. 責任者と権限

| 役割 | 氏名 | 決められること |
|---|---|---|
| スポンサー | 田中 一郎 | 予算・期間・スコープの変更承認、稼働判定、中止の判断 |
| プロジェクトマネージャー | 佐藤 花子 | 予算内の発注、体制内の作業割り当て、変更要求の起票 |
| 業務責任者 | 鈴木 次郎（総務部長） | 業務要件の優先順位、受入テストの合否 |

- プロジェクトマネージャーが単独で決められる範囲：1件50万円までの支出、5営業日までの日程調整
- 上記を超える場合の相談先と期限：スポンサーへ3営業日以内に報告し、判断を受ける

## 10. 承認欄

| 役割 | 氏名 | 承認日 | 署名 |
|---|---|---|---|
| スポンサー | 田中 一郎 | 2026-10-16 | （署名） |
| プロジェクトマネージャー | 佐藤 花子 | 2026-10-16 | （署名） |
| 業務責任者 | 鈴木 次郎 | 2026-10-16 | （署名） |

記入例のポイント

• 目的は1文：「システムを作る」ではなく、「棚卸しの時間と台帳の食い違いを減らす」という得たい状態を書いています。
• 成功基準は4項目とも数字と測定時期つき：稼働の半年後に誰が見ても同じ判定になります。
• 含まないものを3行：会計処理・消耗品・購買申請を対象外と明記し、後から範囲が広がることを防いでいます。
• 予算は根拠つき：「18人月×90万円」のように計算の前提を書くと、要件が変わったときの再見積りが速くなります。
• 権限は金額と日数：「1件50万円まで」「5営業日まで」と書くことで、プロジェクトマネージャーが自分で決められる範囲がはっきりします。

短縮版（A4半分）のテンプレートと記入例

小規模な取り組みや、まず口頭の合意を文章に残したい場合は、同じ10項目を1〜2行ずつにした短縮版が使えます。

# プロジェクト憲章（短縮版）：{プロジェクト名}

- 作成日：{YYYY-MM-DD}　作成者：{氏名}　スポンサー：{氏名}
- 目的：{誰の何がどうなるか}
- 背景：{現状の数字と、今やる理由}
- 成功基準：{指標 現状→目標（測定時期）} ／ {指標 現状→目標（測定時期）}
- 概要スコープ：含む＝{…} ／ 含まない＝{…}
- 主要マイルストーン：{節目 日付} → {節目 日付} → {節目 日付}
- 概算予算：初期{金額}／運用 年{金額}／予備費{金額}
- 主なリスク：{リスクと最初の対応} ／ {リスクと最初の対応}
- 前提と制約：前提＝{…} ／ 制約＝{…}
- 責任者と権限：PM＝{氏名}（{金額}まで・{日数}まで単独で決定）／それ以上はスポンサーへ
- 承認：スポンサー {氏名} {YYYY-MM-DD}

記入例（上の全文と同じ内容を短くしたもの）：

# プロジェクト憲章（短縮版）：備品管理システム刷新

- 作成日：2026-10-07　作成者：佐藤 花子　スポンサー：田中 一郎（管理本部長）
- 目的：総務部と各拠点が備品の貸出・返却・棚卸しを1つのWebシステムで行い、棚卸しの時間と台帳の食い違いを減らす
- 背景：5拠点・約3,200件を表計算ファイルで管理し、棚卸しに年2回・各約120時間。2027年4月に拠点が1つ増える
- 成功基準：棚卸し時間 120時間→40時間以下（2027年9月）／食い違い率 3.0%→0.5%以下（2027年9月）／貸出までの日数 2.4→1.0営業日以下（2027年5〜7月）
- 概要スコープ：含む＝台帳管理、貸出・返却の申請と承認、バーコード棚卸し、5拠点のデータ移行 ／ 含まない＝会計処理、消耗品、購買申請
- 主要マイルストーン：要件定義完了 2026-11-27 → 受入テスト完了 2027-03-12 → 本番稼働 2027-04-05
- 概算予算：初期1,800万円／運用 年240万円／予備費180万円（精度 −10%〜+25%）
- 主なリスク：拠点ごとに台帳の項目が違う→10月中に差を一覧化 ／ 繁忙期に担当者が参加できない→11月初めに参加日と代理者を確定
- 前提と制約：前提＝総務部2名が週8時間参加 ／ 制約＝2027年4月の拠点追加より前に稼働、期末（3/16〜3/31）は切り替えを行わない
- 責任者と権限：PM＝佐藤 花子（1件50万円まで・5営業日まで単独で決定）／それ以上はスポンサーへ3営業日以内に報告
- 承認：スポンサー 田中 一郎 2026-10-16

項目ごとの「あいまいな書き方」と「直した書き方」

成功基準を測れる形に直す例10組

成功基準は、指標・現状の値・目標の値・測定方法・測定時期の5つがそろうと、誰が見ても同じ判定になります。システム開発でよく出てくる言い方を、測れる形に直しました。

「現状の値」が分からないときは、最初のマイルストーンを「現状の測定」にすると、目標の妥当性も一緒に確認できます。

似た文書との違いを比べる

プロジェクト憲章は、企画書とプロジェクト計画書の間に位置します。「誰が」「いつ」「何を決めるか」で比べると役割が分かります。

書く順番と、内容の受け渡し

flowchart LR
  A["企画書<br>やるかどうか"] --> B["プロジェクト憲章<br>始めてよいという合意"]
  B --> C["スコープ記述書<br>作るもの・作らないもの"]
  B --> D["プロジェクト計画書<br>どう進めるか"]
  C --> D
  D --> E["キックオフ資料<br>全員で共有"]

スコープ記述書の項目と対象外の書き方、プロジェクト計画書の目次と項目別の記入例、キックオフのアジェンダは、それぞれ別の記事で詳しく扱っています。憲章では概要にとどめ、詳しい内容はそれぞれの文書に任せるのが、1〜2ページに収めるコツです。

承認前の確認チェックリスト

スポンサーに署名をもらう前に、次の項目を確認します。コピーして使えるようMarkdownのチェックボックスにしています。

## プロジェクト憲章 承認前チェックリスト

### 内容
- [ ] 目的が1〜2文で、手段ではなく得たい状態を書いている
- [ ] 背景に現状の数字が1つ以上ある
- [ ] 成功基準が3〜5項目で、すべてに現状・目標・測定方法と時期がある
- [ ] 「含まないもの」が1行以上あり、理由が分かる
- [ ] マイルストーンごとに、完了を判定する人が書いてある
- [ ] 予算に根拠と精度の幅、予備費がある
- [ ] リスクごとに、最初の対応と担当が書いてある
- [ ] 前提と制約を分けて書いている
- [ ] PMが単独で決められる範囲が、金額と日数で書いてある
- [ ] その範囲を超えたときの相談先と期限が書いてある

### 形式
- [ ] A4で1〜2ページに収まっている
- [ ] 文書番号・版・作成日がある
- [ ] {記入} の括弧が残っていない（スクリプトで確認）
- [ ] 専門用語に、利用部門が読んで分かる言い換えを添えている

### 合意
- [ ] スポンサーと対面またはオンラインで読み合わせた
- [ ] 業務責任者が成功基準とスコープに同意している
- [ ] 承認後の保管場所と、関係者への共有方法を決めている
- [ ] 見直すきっかけ（予算・期間・スコープの大きな変更）を決めている

記入漏れを検出するPythonスクリプト

テンプレートの10項目について、見出しがあるか、本文が空でないか、{ } の括弧が残っていないかを調べるスクリプトです。標準ライブラリだけで動きます。

"""プロジェクト憲章（Markdown）の必須項目の記入漏れを調べる。
使い方: python3 check_charter.py charter.md
"""
import re
import sys

REQUIRED = [
    "目的", "背景", "成功基準", "概要スコープ", "主要マイルストーン",
    "概算予算", "主なリスク", "前提と制約", "責任者と権限", "承認欄",
]
PLACEHOLDER = re.compile(r"\{[^{}\n]+\}")   # {記入} が残っている箇所
TABLE_RULE = re.compile(r"^|[\s:|-]+|$")  # 表の区切り行


def split_sections(text):
    """「## 見出し」ごとに本文を分ける。見出しの番号（1. など）は取り除く。"""
    sections, name = {}, None
    for line in text.splitlines():
        m = re.match(r"^##\s+(?:\d+[.．]\s*)?(.+?)\s*$", line)
        if m:
            name = m.group(1)
            sections[name] = []
        elif name is not None:
            sections[name].append(line)
    return sections


def check(path):
    with open(path, encoding="utf-8") as f:
        sections = split_sections(f.read())
    problems = 0
    for item in REQUIRED:
        if item not in sections:
            print(f"NG  {item}: 見出しがありません")
            problems += 1
            continue
        body = [l for l in sections[item] if l.strip() and not TABLE_RULE.match(l.strip())]
        rest = PLACEHOLDER.findall("\n".join(body))
        if not body:
            print(f"NG  {item}: 本文が空です")
            problems += 1
        elif rest:
            print(f"NG  {item}: 未記入が{len(rest)}か所（例 {rest[0]}）")
            problems += 1
        else:
            print(f"OK  {item}")
    print(f"--- {path}: 必須{len(REQUIRED)}項目のうち要対応 {problems} 件")
    return problems


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit(__doc__)
    sys.exit(1 if check(sys.argv[1]) else 0)

実行結果1：テンプレートのまま（10項目すべて要対応）

$ python3 check_charter.py charter_template.md
NG  目的: 未記入が1か所（例 {このプロジェクトで何を実現するかを1〜2文で。「誰の」「何が」「どうなる」を入れる}）
NG  背景: 未記入が1か所（例 {なぜ今やるのか。現状の数字と、放置した場合に起きることを2〜4行で}）
NG  成功基準: 未記入が12か所（例 {指標名}）
NG  概要スコープ: 未記入が2か所（例 {対象の業務・機能・拠点}）
NG  主要マイルストーン: 未記入が9か所（例 {例：要件定義の完了}）
NG  概算予算: 未記入が7か所（例 {金額}）
NG  主なリスク: 未記入が9か所（例 {起きるかもしれないこと}）
NG  前提と制約: 未記入が2か所（例 {例：利用部門から担当者2名が週8時間参加できる}）
NG  責任者と権限: 未記入が8か所（例 {氏名}）
NG  承認欄: 未記入が9か所（例 {氏名}）
--- charter_template.md: 必須10項目のうち要対応 10 件

実行結果2：記入例の全文（要対応0件）

$ python3 check_charter.py charter_example.md
OK  目的
OK  背景
OK  成功基準
OK  概要スコープ
OK  主要マイルストーン
OK  概算予算
OK  主なリスク
OK  前提と制約
OK  責任者と権限
OK  承認欄
--- charter_example.md: 必須10項目のうち要対応 0 件

実行結果3：書きかけの下書き（3種類の漏れを検出）

記入例から、成功基準の目標を1つ {数値} に戻し、主なリスクの本文を消し、承認欄の見出しごと削除したファイルで試した結果です。

$ python3 check_charter.py charter_draft.md
OK  目的
OK  背景
NG  成功基準: 未記入が1か所（例 {数値}）
OK  概要スコープ
OK  主要マイルストーン
OK  概算予算
NG  主なリスク: 本文が空です
OK  前提と制約
OK  責任者と権限
NG  承認欄: 見出しがありません
--- charter_draft.md: 必須10項目のうち要対応 3 件
$ echo $?
1

要対応が1件以上あると終了コードが1になるので、Gitのコミット前チェックやCIに組み込むこともできます。項目を増やしたい場合は、REQUIRED のリストに見出しの名前を足してください。スクリプトが確認するのは「書いてあるかどうか」までです。内容が妥当かどうかは、上のチェックリストで人が確認します。

つまずきやすい点と整え方

よくある質問

Q. プロジェクト憲章は誰が書きますか？ A. 多くの場合、プロジェクトマネージャーが下書きし、スポンサーが承認します。大切なのは、スポンサーが内容に同意して署名することです。下書きの段階からスポンサーと話しながら作ると、承認までが速くなります。

Q. プロジェクト憲章とプロジェクト計画書の違いは何ですか？ A. 憲章は「始めてよいという合意」を1〜2ページで示す文書、計画書は「どう進めるか」を詳しく書く文書です。憲章の承認を受けてから、計画書を作ります。

Q. アジャイル開発でもプロジェクト憲章は必要ですか？ A. 目的・成功基準・権限を合意する役割は、進め方に関係なく役立ちます。アジャイルでは、スコープを機能の一覧ではなく「解決したい課題と優先順位の考え方」として書き、短縮版を使うと進め方に合います。

Q. 承認後に内容を変えてもよいですか？ A. 変えられます。予算・期間・スコープ・責任者が大きく変わるときは、版を上げてスポンサーの承認を受け直します。細かな日程の変更は、プロジェクト計画書の更新で扱います。

まとめ

• プロジェクト憲章は、開始の承認・目的・成功基準・権限を1〜2ページにまとめた文書です。
• 10項目のテンプレート（目的・背景・成功基準・概要スコープ・主要マイルストーン・概算予算・主なリスク・前提と制約・責任者と権限・承認欄）を埋めれば形になります。
• 成功基準は、指標・現状・目標・測定方法・測定時期をそろえると、誰が見ても同じ判定になります。
• 「含まないもの」と「PMが単独で決められる範囲」を書くと、後からの認識の違いが減ります。
• 詳しい内容はスコープ記述書とプロジェクト計画書に任せ、憲章は概要にとどめます。
• 記入漏れはスクリプトで、内容の妥当性はチェックリストで確認してから、スポンサーの署名をもらいます。

参考・出典（確認日：2026年10月7日）

• PMI「PMBOK Guide」：PMBOKガイドの最新版（第8版、2025年11月発行）の案内 https://www.pmi.org/standards/pmbok
• PMI「PMBOK Guide – Seventh Edition FAQs」（PDF）：第7版の「モデル・方法・作成物」の章 https://www.pmi.org/-/media/pmi/documents/public/pdf/pmbok-standards/pmbok-guide-public-faqs-29-march-2021.pdf
• デジタル庁「デジタル社会推進標準ガイドライン」：DS-100「デジタル・ガバメント推進標準ガイドライン」（2026年6月12日改定）を含む、政府の標準ガイドライン群の一覧 https://www.digital.go.jp/resources/standard_guidelines

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。