約 21 分で読めます
編集部イチオシタスク・担当・期日をひとつのボードで見える化
- かんばん・ガントチャート・カレンダーなど複数ビューをワンクリックで切替
- 日本語UI・日本語サポート対応（東京オフィスあり）
- 通知・担当割り当て・期日リマインドを自動化
- ダッシュボードで複数プロジェクトの進捗を一括把握
プロジェクト憲章とは、プロジェクトの目的・範囲・権限を公式に定義し、プロジェクトの正式な開始を宣言する基本文書です。この記事では読み方や英語表記、混同されやすい文書との違い、必須10要素、作成5ステップ、業種別の記載例3選までを実務目線で整理します。
1. プロジェクト憲章とは ｜ 意味・読み方・英語表記を1分で理解
プロジェクト憲章とは、プロジェクトの目的・範囲・権限を公式に定義し、プロジェクトの正式な開始を宣言する基本文書です。読み方は「プロジェクトけんしょう」。英語では Project Charter と表記し、日本語でも「プロジェクトチャーター」と呼ばれることがあります。
この文書がもつ機能は、大きく3つに整理できます。
- 公式な承認：スポンサーの署名によって、プロジェクトが組織の正式な活動として認められる
- 権限の付与：プロジェクトマネージャー（PM）が人・予算・時間を動かせる範囲を明文化する
- 判断基準の固定：迷いが生じたとき、「憲章に書かれた目的に合うか」で意思決定できる
PMBOK ガイドの体系では、プロジェクト憲章は立ち上げフェーズの成果物として位置づけられます。第6版までは「プロジェクト統合マネジメント」の知識エリアにある「プロジェクト憲章作成」プロセスのアウトプットで、そのインプットはビジネス文書（ビジネスケース、ベネフィットマネジメント計画書）、合意書・契約書、組織体の環境要因、組織のプロセス資産です。「プロジェクト憲章 インプット」を調べている方は、この4点セットを覚えておけば十分です。第7版では原則とパフォーマンス領域を中心とした構成に変わりましたが、憲章が「開始を承認し、PMに権限を与える文書」である役割は変わっていません。
2. 似ている文書との違い ｜ 計画書・要旨・ビジネスケースを一枚で整理
「憲章と計画書は何が違うのか」は最も多い疑問です。結論は、憲章は “なぜ・何を・誰の権限で” を決める文書、計画書は “どうやって” を決める文書という役割分担です。
プロジェクト計画書との違い
憲章は A4 で1〜3枚、目的・スコープ・成功基準・体制を「ハイレベル」に記述します。一方のプロジェクト計画書は、憲章で承認された方向性を実行可能な単位まで分解した詳細文書で、作業分解の手順に沿ったタスク一覧、スケジュール、コスト計画、品質・リスク対応策まで含みます。順序としては、憲章が承認されて初めて計画書の作成に着手します。憲章がないまま計画書を書き始めると、後から「そもそもこのプロジェクトの目的は違う」と差し戻され、詳細計画がまるごと無駄になります。
プロジェクト要旨（Project Brief）との違い
プロジェクト要旨は、プロジェクトの背景・狙い・大まかな進め方をチーム内で共有するための要約資料です。憲章との最大の違いは公式な承認権限を伴うかどうか。要旨は「関係者の理解を揃える」ためのコミュニケーション文書で、署名がなくても成立します。対して憲章は承認者の署名によって効力をもち、PM の権限の根拠になります。社内の小規模施策なら要旨だけで走らせることもありますが、予算や人員を部門横断で動かすなら憲章が必要です。
ビジネスケース・スコープ記述書との違い
ビジネスケースは「この投資をする価値があるか」を、投資額・期待効果・ROI・代替案で示す投資判断のための文書で、憲章より前に作られます。スコープ記述書は憲章より後で、成果物と受け入れ基準、含まないもの（除外範囲）を細かく定義します。つまり4つの文書は時間軸に沿って並びます。
| 文書 | 主な目的 | 作成タイミング | 詳細度 | 承認者 |
|---|---|---|---|---|
| ビジネスケース | 投資の妥当性を判断する | 構想段階（憲章より前） | 中（効果と費用が中心） | 経営層・投資委員会 |
| プロジェクト憲章 | 開始を公式に承認しPMに権限を与える | 立ち上げ時 | 低〜中（1〜3枚） | スポンサー（経営層） |
| プロジェクト要旨 | 関係者に狙いと進め方を共有する | 立ち上げ〜計画初期 | 低（1枚） | 原則不要（PMが作成） |
| プロジェクト計画書 | 実行方法を詳細に定める | 計画フェーズ | 高（数十ページ） | スポンサー・PMO |
3. 記載すべき10の必須要素 ｜ PMBOK準拠チェックリスト
憲章のテンプレートを探している方は、まず次の10要素（下の表では前提条件と制約、PMの権限と承認者を分けて12行で示しています）を埋められるかを確認してください。逆に言えば、この10項目が入っていれば体裁は自由でかまいません。
①目的・成功基準に関する項目
ここが曖昧なままだと、後工程の判断がすべてブレます。成功基準は必ず数値で書き、SMARTな目標づくりの観点で「いつまでに・何が・どうなっていれば成功か」を1行で言い切れる状態にします。
| 要素 | 記載内容の要点 | 記入例（一行サンプル） |
|---|---|---|
| 目的・正当化理由 | なぜ今このプロジェクトが必要か | 受注処理の手作業を廃し、繁忙期の残業時間を削減するため |
| 目標・成功基準 | KGI/KPI を測定可能な数値で | 受注1件あたりの処理時間を12分から5分以内に短縮 |
| 主要成果物 | 完了時に手元に残るもの | 新受注管理システム、運用マニュアル、操作研修の実施 |
| スコープと境界 | 含む範囲と含まない範囲 | 対象は国内2拠点の受注業務。海外拠点と会計連携は対象外 |
②実行条件に関する項目
予算とスケジュールは、この時点では概算で問題ありません。重要なのは「前提条件」と「制約条件」を明示することです。前提が崩れたときに計画を見直す根拠になります。
| 要素 | 記載内容の要点 | 記入例（一行サンプル） |
|---|---|---|
| 予算の概算 | 総額と主な内訳 | 総額1,800万円（外部開発1,200万円／ライセンス400万円／予備200万円） |
| スケジュール | 主要フェーズと節目 | 要件定義は第1四半期、開発は第2四半期、本番稼働は第3四半期初 |
| 前提条件 | 成立を前提に置く事項 | 業務部門から専任担当1名が期間中フルタイムで参画する |
| 制約条件 | 変更できない枠 | 決算期の繁忙期間は業務部門のレビューを実施しない |
| ハイレベルリスク | 発生すれば計画が揺らぐ事象 | 既存データの品質不良により移行工数が想定の2倍になる可能性 |
節目の置き方に迷う場合は、主要マイルストーンの考え方を先に整理しておくと、憲章のスケジュール欄が数行で書けるようになります。
③体制・承認に関する項目
見落とされやすいのが「PM の権限」です。「いくらまでの支出をPMが決裁できるか」「誰に作業指示を出せるか」を書かないと、実行段階で毎回スポンサーに確認が必要になり、意思決定が滞ります。
| 要素 | 記載内容の要点 | 記入例（一行サンプル） |
|---|---|---|
| 主要ステークホルダー | 役割と関与度 | スポンサー：営業本部長／利用部門：受注課10名／IT部門：2名 |
| PMの権限 | 決裁範囲と指示権 | 50万円未満の支出、要員の作業優先順位の決定はPMが判断 |
| 承認要件・承認者 | 何をもって完了とし誰が承認するか | 受け入れテスト合格をもって完了、承認者は営業本部長 |
関係者の洗い出しが甘いと承認段階で反対が出ます。着手前にステークホルダーの種類を踏まえて一覧化しておきましょう。
4. 作成手順 ｜ 5ステップで承認まで持っていく
憲章の作成は、文章を書く作業より合意を取る作業が本質です。次の5ステップで進めると、承認の差し戻しが大幅に減ります。
Step1 スポンサー・主要ステークホルダーへのヒアリング
最初に聞くべきは「このプロジェクトが成功したと判断する条件は何か」です。スポンサーと利用部門の答えがずれている場合、そのずれを憲章で解消しないまま進めると必ず後工程で衝突します。ヒアリングは30分×3〜5人で十分です。
Step2 目的・スコープ・成功基準のドラフト作成
ヒアリング結果をもとに、前章の10要素を1〜3枚に収めます。この段階のコツは「含まないもの」を先に書くこと。除外範囲が明確な憲章は、レビューでの論点が絞られ、合意が速くなります。
Step3 ステークホルダーレビューと権限調整
ドラフトを回覧し、特に予算・要員・PM の権限について合意を取ります。もめやすいのは要員の稼働で、「専任」と書いたつもりが実際は兼任だった、という齟齬がよく起きます。稼働率まで書き込むか、工数管理の基本に沿って月あたりの人日で明記しておくと解釈のずれを防げます。
Step4 承認取得とキックオフミーティングでの共有
承認は口頭ではなく記録に残る形（署名、または承認履歴が残るツール上の承認）で取ります。そのうえでキックオフで全員に読み上げ、質問に答えます。ここで初めて憲章は「生きた文書」になります。
Step5 変更管理ルールの設定
多くの解説はStep4で終わりますが、実務で効くのはこのステップです。どういう場合に憲章を更新するのかを、憲章そのものに書いておきます。たとえば「スコープの追加で工数が10%以上増える場合」「成功基準の数値を変える場合」「予算が承認額を超える場合」はスポンサー承認による憲章改訂を必須とする、という具合です。これを決めておくと、実行中の「ちょっとした追加依頼」が積み上がってプロジェクトが破綻する事態を防げます。
5. 業種別の記載例3選 ｜ そのまま差し替えて使えるミニ文例
抽象的な項目説明よりも、近い状況の記載例を見るほうが速く書けます。3つの典型的なケースで、核となる「目的／成功基準／主要ステークホルダー」を示します。
IT開発プロジェクトの記載例（システム刷新・要件定義前）
| 項目 | 記載例 |
|---|---|
| 目的 | 保守期限切れの受注管理システムを刷新し、業務停止リスクと保守費を削減する |
| 成功基準 | 本番稼働後1か月の重大障害0件、月額保守費を30%削減、受注入力時間を半減 |
| 主要ステークホルダー | スポンサー：情報システム部長／利用部門：受注課（課長＋実務担当2名）／開発ベンダー：PM1名・開発4名 |
| スコープ外 | 会計システムの改修、海外拠点の業務、既存の紙帳票の電子化 |
IT 案件では、憲章の時点で要件を確定させる必要はありません。ただし「どこまでを今回の対象とするか」の境界線は必須です。境界が引けていれば、続く要件定義フェーズでの議論が発散しません。
マーケティングキャンペーンの記載例（新商品ローンチ・部門横断）
| 項目 | 記載例 |
|---|---|
| 目的 | 新商品の認知を短期間で獲得し、発売後3か月の初期販売目標を達成する |
| 成功基準 | 発売後3か月で新規リード3,000件、指名検索数を発売前比200%、CPA 8,000円以内 |
| 主要ステークホルダー | スポンサー：マーケティング本部長／広報・営業・製品開発・外部代理店の各リーダー |
| PMの権限 | 広告予算のうち月200万円までの配分変更、クリエイティブ差し替えの最終判断 |
部門横断の施策では、成功基準の指標の定義まで書き込むことが重要です。「リード」が名刺獲得なのか資料ダウンロードなのかを揃えていないと、終盤で成果の解釈が分かれます。
業務改善（DX）プロジェクトの記載例（既存フロー移行・承認が複雑）
| 項目 | 記載例 |
|---|---|
| 目的 | 4部門にまたがる稟議フローを電子化し、申請から決裁までの所要日数を短縮する |
| 成功基準 | 平均決裁日数を7.5日から3日以内、差し戻し率を20%以下、対象部門の利用率95% |
| 主要ステークホルダー | スポンサー：経営企画部長／承認者：各部門長4名／推進：業務改革チーム3名 |
| 前提・制約 | 現場担当は既存業務と兼任（週8時間）、決算期の2か月は移行作業を行わない |
社内承認が複雑なケースでは、承認ルートそのものを憲章に図示しておくと、実行中の停滞が減ります。移行の段取りは工程の組み立て方を参考に、憲章のマイルストーン欄と対応させておきましょう。
6. 誰が作り誰が承認するのか ｜ PMBOKとIPA準拠の実務の違い
原則はシンプルです。起草するのは PM（または立ち上げ担当者）、承認するのはスポンサー。PM が自分に権限を与えることはできないため、承認者は必ずプロジェクトの外側にいる決裁権者（事業責任者、部門長、経営層）になります。PMO がある組織では、PMO が体裁と整合性をレビューする役割を担うのが一般的です。
一方で、日本の官公庁案件や SIer が関わる大規模案件では、PMBOK の用語のままでは進まないことがあります。IPA（情報処理推進機構）が整備してきた「共通フレーム」やプロジェクト可視化の手法群が調達・開発の共通言語として使われており、そこでは憲章に相当する内容が「プロジェクト計画書」「作業範囲記述書」「企画・要件定義段階の承認資料」などに分散して収まっているケースが多いためです。
実務での対処法は次の2つです。
- 文書名を組織の標準に合わせる：「プロジェクト憲章」という名称にこだわらず、社内標準の「プロジェクト計画書（概要版）」や「企画承認書」として提出し、中身は第3章の10要素を満たす
- 不足している要素だけ補う：既存の社内フォーマットを見て、「PM の権限」「成功基準の数値」「変更管理ルール」が抜けていれば、その3つを追記する
つまり、国際標準と国内慣行の違いは文書の名前と分割の仕方にあり、押さえるべき情報の中身はほぼ同じです。名称論争に時間を使うより、10要素が埋まっているかを確認するほうが実利があります。
7. 憲章を「絵に描いた餅」にしない ｜ monday.comでの運用法
憲章の本当の難所は作成ではなく、承認後の運用です。よくある失敗は、承認された憲章が共有フォルダの奥に眠り、3か月後には誰も成功基準を覚えていない状態。実行がタスク管理ツール、憲章が別のドキュメントに分かれていることが原因です。
解決策は、憲章の中身をそのまま実行画面に載せること。プロジェクト管理ツールのmonday.comを使う場合、次の3つの実践が効果的です。
①憲章の目標をボードのマイルストーンに変換する
憲章のスケジュール欄に書いた節目を、そのままボードのグループまたはマイルストーン項目として登録します。ガント／タイムラインビュー（スタンダードプラン以上で利用可能）に切り替えれば、憲章で宣言した節目と実際の進捗が同じ画面に並びます。ここで重要なのは、各マイルストーンの説明欄に憲章の該当文（「本番稼働後1か月の重大障害0件」など）を貼り付けておくこと。判断に迷ったとき、担当者が憲章を探しに行かなくて済みます。タイムライン管理の考え方をそのまま持ち込めます。
②ステークホルダーの権限をパーミッション設定に反映する
憲章で定めた権限を、ツール上のアクセス権に対応させます。たとえば承認者はボードの閲覧＋承認ステータスの変更のみ、実務担当は自分の担当行のみ編集可、外部ベンダーはゲストとして特定ボードのみ参照。憲章の「PM の権限」が文字だけで終わらず、実際の操作権限として機能する状態になります。承認履歴が自動で残るため、「いつ誰が承認したか」を後から追えるのも利点です。
③成功基準をダッシュボードで可視化する
憲章の KPI をダッシュボードのウィジェットとして常設します。決裁日数の平均、リード件数の累計、予算消化率といった指標を1画面にまとめ、週次でスポンサーに共有する運用にすれば、憲章の成功基準が「毎週見る数字」に変わります。自動化ルールを併用し（スタンダードプラン以上で利用可能）、期限を2日超えた項目は担当者とPMへ自動通知する設定を入れておくと、週次会議まで遅延に気づかない状況を避けられます。こうした進捗共有の仕組みが動き出すと、憲章はレビューの土台として機能し続けます。
料金プランは無料プランから用意されており、有料機能も無料トライアルで試せます（トライアル期間は公式サイトでご確認ください）。最新の価格体系は公式サイトの料金ページで確認してください。
憲章運用に使うツールの比較
| ツール | 憲章の保管 | 目標・成功基準の運用 | 権限設定 | 向くチーム | はじめる |
|---|---|---|---|---|---|
| monday.com | ボード内ドキュメントに常設 | ダッシュボードでKPIを常時可視化、自動通知の設定も可能（スタンダードプラン以上） | ボード・列単位で細かく制御、ゲスト招待も可 | 5〜15人の部門横断プロジェクト | 無料トライアル → |
| Notion | ページとして自由に構造化 | データベースのプロパティで進捗を集計 | ページ単位で共有範囲を指定 | ドキュメント中心・小規模チーム | 無料プランで始める → |
| ClickUp | Docs機能でタスクと紐付け | ゴール機能で目標値の達成度を追跡 | スペース・リスト単位で設定 | スクラムで回す開発チーム | 無料プランで始める → |
| Confluence | Wikiページとして蓄積 | 進捗管理は別ツール（Jira等）と連携前提 | スペース権限で管理 | 文書資産を長期蓄積したい組織 | 公式サイト → |
あなたのチームはどのタイプ？
- 5人以下・まず文書として整えたい：Notion のフリープラン（US$0）から。有料はプラス US$10/ユーザー/月（年払い表示）で、ファイルアップロード上限やページ履歴の制限が外れます
- 5〜15人の部門横断プロジェクト：monday.com。憲章の権限定義をそのままアクセス権に落とせるため、承認ルートが複数ある案件に向きます
- スクラムで回す開発チーム：ClickUp。Free Forever（US$0）でタスク数の上限なし（詳細は公式サイトでご確認ください）、Unlimited は US$7/ユーザー/月（年払い）です
- 15人以上の大規模プロジェクト：monday.comの上位プラン。複数プロジェクトを横断して憲章の整合性を保てます
日々の運用では、憲章のスコープをタスクの粒度まで分解して担当者に紐付けるところまでやると、憲章と実務の断絶がなくなります。
まとめ
プロジェクト憲章は「体裁を整えるための書類」ではなく、プロジェクト全体の判断基準を固定する装置です。要点を再確認しましょう。
- プロジェクト憲章とは、目的・範囲・PM の権限を公式に定義し、開始を宣言する基本文書（読み方は「けんしょう」、英語は Project Charter）
- 計画書・要旨・ビジネスケースとは役割と作成タイミングが異なる。憲章は「なぜ・何を・誰の権限で」を決める
- 記載すべきは10要素。とくに「PM の権限」「数値化した成功基準」「変更管理ルール」の3つは抜けやすい
- 作成は5ステップ。文章を書く作業より、スポンサーと関係者の合意を取る作業が本質
- 国内実務では文書名が違っても中身は同じ。名称より10要素が埋まっているかを確認する
第3章の10要素を1枚に並べ、埋まらない項目をスポンサーへの質問リストに変えてください。そのうえで、承認後に憲章を眠らせないための置き場所を先に決めておきます。この記事の方法論をそのまま実践に移すなら、まず monday.com でテンプレートから新しいボードを作り、憲章の目的・成功基準・マイルストーンを項目として入力してみてください。プロジェクトの骨組みが10分で形になり、承認したその日から進捗と成功基準が同じ画面で追える状態になります。
よくある質問
プロジェクト憲章とプロジェクト計画書の違いは何ですか？
憲章は「なぜ・何を・誰の権限で行うか」をハイレベルに定義し、開始を公式に承認する文書です。計画書は承認された方向性を「どうやって実現するか」に分解した詳細文書で、タスク・スケジュール・コスト・リスク対応を含みます。作成順は憲章が先、計画書が後。詳しい比較は第2章の表を参照してください。
プロジェクト憲章の実例はありますか？
第5章に IT 開発（システム刷新）、マーケティングキャンペーン（新商品ローンチ）、業務改善（稟議フローの電子化）の3ケースで、目的・成功基準・主要ステークホルダーの記載例を掲載しています。自社の状況に近いものを選び、固有名詞と数値を差し替えるだけで下書きが完成します。
プロジェクト憲章は誰が作るのですか？
起草は PM または立ち上げ担当者、承認はスポンサー（事業責任者や部門長など決裁権者）が行います。PM が自分に権限を与えることはできないため、承認者は必ずプロジェクトの外側の決裁権者である必要があります。PMO がある組織では PMO が整合性をレビューします。
プロジェクト憲章とスコープの関係は？
憲章にはスコープを「境界線」のレベルで書きます。何を対象とし、何を対象外とするかを数行で示す形です。成果物ごとの受け入れ基準や細かい除外事項は、憲章の後に作るスコープ記述書で定義します。憲章の段階で細部を詰めすぎると承認が遅れるため、境界が引けていれば十分です。
アジャイル開発でもプロジェクト憲章は必要ですか？
必要です。アジャイルでは詳細な要件を固定しませんが、「何のためにこのプロダクトを作るのか」「成功をどう測るのか」「誰が意思決定するのか」は固定する必要があります。むしろ変化が多い進め方だからこそ、判断の軸となる憲章の価値は高まります。ただしスケジュールや成果物の記述は柔軟にし、リリース目標とプロダクトゴールで表現するのが実務的です。
プロジェクト憲章の読み方は？
「プロジェクトけんしょう」と読みます。憲章は「組織や活動の基本方針を定めた文書」を意味する言葉で、英語表記は Project Charter、カタカナで「プロジェクトチャーター」と呼ばれることもあります。社内で用語が統一されていない場合は、初出時に英語表記を併記すると誤解が減ります。
プロジェクト憲章とプロジェクト要旨の違いは？
要旨は関係者に狙いと進め方を共有するための要約資料で、承認権限を伴いません。憲章はスポンサーの承認によって効力をもち、PM に権限を与えます。社内の小さな施策なら要旨だけで進められますが、予算や部門横断の人員を動かすなら憲章が必要です。
IPAの資料にあるプロジェクト憲章とPMBOKのものは何が違いますか？
違いは主に文書の名称と分割の仕方です。PMBOK では独立した「プロジェクト憲章」として扱いますが、IPA の共通フレームを前提とする国内の開発・調達実務では、同じ内容が計画書や作業範囲記述書、企画段階の承認資料に分散して収まることが多くあります。押さえるべき情報の中身はほぼ同じなので、社内標準のフォーマットに10要素が含まれているかを点検するのが実務的な対応です。