プロジェクト憲章の作り方：開始前に決める10項目

読了時間：約7分

プロジェクトの多くは、始める前の合意が甘いまま動き出してしまいます。「目的は何となくわかっている」「スコープはふんわり決まっている」——この状態でスタートすると、必ず後半に「そういう意味ではなかった」というトラブルが発生します。プロジェクト憲章（Project Charter）は、プロジェクトを正式にスタートさせるための合意文書です。この記事では、PM初心者でも作れる10項目の書き方を解説します。

この記事の結論 プロジェクト憲章は「目的・スコープ・期間・予算・体制・制約・リスク・成功基準」など10項目を関係者全員で合意するための文書。特に「スコープ外を明記する」と「成功基準を数値で書く」の2点が最重要。ChatGPTに概要を渡せば叩き台が10分で完成する。

プロジェクト憲章が必要な理由

プロジェクト憲章を作ることで、3つの効果が得られます。

効果	具体的な影響
認識のずれを防ぐ	「こういうつもりだった」トラブルが減る
スコープを守る	「これもやってほしい」という追加要求に対して根拠を持って対応できる
承認の証跡を残す	後から「そんなこと決めていない」と言われても、サインがある文書を示せる

逆に言えば、プロジェクト憲章なしでプロジェクトを進めると、上記の問題がすべて「なんとなく」で処理されることになります。

プロジェクトキックオフの進め方と合わせて読むと、憲章の内容をキックオフで合意する流れが理解できます。

10の必須項目と書き方

1. プロジェクト名

例：社内勤怠管理システム リニューアルプロジェクト（2026年度）

長すぎず、プロジェクトの内容が一目でわかる名前をつけます。社内で複数のプロジェクトが走っている場合は、混同しないよう「年度」や「フェーズ」を付けると明確になります。

2. プロジェクトの目的・背景

なぜこのプロジェクトをやるのかを1〜3文で記載します。

例：
現行の勤怠管理システムは導入から8年が経過し、リモートワーク環境への対応が困難になっている。
また、月次集計作業に毎月20時間以上の手作業が発生しており、業務効率化が急務となっている。
本プロジェクトでは、クラウド型の勤怠管理ツールへの移行を通じて、これらの課題を解決する。

3. 成功基準（数値で書く）

プロジェクトが「成功した」と判断するための基準を、誰でも同じ解釈ができる形で書きます。

【NG例（曖昧）】
・業務効率が上がること
・メンバーが使いやすいと感じること

【OK例（数値で）】
・月次集計作業を20時間/月 → 3時間/月以下に削減
・システム稼働率99%以上（リリース後3ヶ月間）
・全社員（100名）のシステム移行完了（〇月〇日まで）

4. スコープ（対象範囲）

何をやるかを明記します。

【スコープ内】
・クラウド勤怠管理ツールの選定・導入
・現行データの移行（過去2年分）
・全社員へのシステム切り替え
・管理者向け・一般社員向けの操作マニュアル作成

【スコープ外】（※ここが特に重要）
・給与計算システムとの連携（次フェーズで検討）
・勤怠以外のHR機能の導入
・カスタム開発（標準機能の範囲で運用）

「スコープ外」を明記することが最重要です。スコープ外を書かないと、「これもやってほしい」という追加要求が際限なく来ます。

5. 期間・マイルストーン

プロジェクト期間：2026年6月1日 〜 2026年11月30日（6ヶ月）

主要マイルストーン：
・2026年7月31日：ツール選定・契約完了
・2026年9月30日：テスト環境での検証完了
・2026年10月31日：本番環境への切り替え
・2026年11月30日：全社員移行・運用安定化

6. 予算（概算）

予算上限：〇〇万円（ライセンス費・導入支援費・研修費を含む）

予算を明記することで、追加要求が来たときに「予算の範囲内でできるか」という判断基準になります。

7. プロジェクト体制

プロジェクトスポンサー：〇〇部長（最終意思決定）
PM：〇〇（進行管理・ステークホルダー調整）
担当者（業務）：〇〇（業務要件・マニュアル作成）
担当者（IT）：〇〇（技術検証・システム設定）
外部協力：ツールベンダー〔社名〕担当〇〇

8. ステークホルダー

・〇〇部長（スポンサー・最終承認者）
・人事部 全員（主要な利用者・意見収集対象）
・情報システム部 〇〇（セキュリティ確認・インフラ連携）
・外部ベンダー 〇〇社（ツール提供・導入支援）

9. 制約・前提条件

【制約】
・予算：〇〇万円以内
・期限：2026年11月末まで（年度末のタイミングに合わせる）
・ツール選定：クラウド型SaaSに限定（オンプレ不可）

【前提条件】
・情報システム部が導入ツールのセキュリティ審査を行う
・ベンダーからのサポート体制が確保されている

10. リスク（想定される懸念事項）

・リスク1：データ移行時のエラー（発生確率：中・影響：高）
  → 対策：テスト環境での移行リハーサルを2回実施

・リスク2：社員のシステム習熟に時間がかかる（発生確率：高・影響：中）
  → 対策：導入前研修の実施・FAQページの作成

・リスク3：ベンダーのサポート品質が想定以下（発生確率：低・影響：高）
  → 対策：契約前にサポート条件を文書で確認

承認者・ステークホルダーの明記方法

プロジェクト憲章は「作って終わり」ではなく、関係者全員のサインをもらって初めて機能します。

承認の形式：

【承認欄】

プロジェクトスポンサー：〔氏名〕　署名：_______　日付：
PM：〔氏名〕　署名：_______　日付：
顧客代表：〔氏名〕　署名：_______　日付：

電子承認（メールでの合意確認）でも法的・業務的に問題ない場合がほとんどです。「〇月〇日のミーティングで全員合意済み」という記録を残すだけでも効果があります。

ChatGPTで叩き台を生成するプロンプト例

プロジェクトの概要をChatGPTに渡すと、憲章の叩き台が10分で完成します。

プロンプト例

以下のプロジェクト概要から、プロジェクト憲章の叩き台を作成してください。

【含める項目】
1. プロジェクト名
2. 目的・背景
3. 成功基準（数値で）
4. スコープ内・スコープ外
5. 期間・主要マイルストーン
6. 予算（概算）
7. プロジェクト体制
8. ステークホルダー
9. 制約・前提条件
10. 想定リスク（3件程度）

【プロジェクト概要】
・社内の勤怠管理をExcelから、クラウドSaaSツールに移行する
・期間6ヶ月・予算200万円・チーム：PM1名・担当者2名・情シス部協力
・全社員100名が対象、年度末（11月末）までの切り替えが必要
・給与計算システムとの連携は今回のスコープ外

出力された叩き台に、担当者名・具体的な日付・社内固有の事情を加えれば、8割方完成します。

まとめ

プロジェクト憲章は「合意の記録」：作るだけでなく、関係者全員のサインを取ることで初めて機能する
10項目を網羅する：目的・成功基準・スコープ（内外）・期間・予算・体制・ステークホルダー・制約・リスク
「スコープ外」の明記が最重要：書かないと際限なく追加要求が来る根拠を作ってしまう
成功基準は数値で書く：「効率化」ではなく「〇〇時間を〇〇時間に削減」という形にする
ChatGPTで叩き台を10分で作る：プロジェクト概要を渡して叩き台を生成し、PMが実態に合わせて精査する