2-2. プロジェクトの公認:プロジェクト憲章の作成
プロジェクトの存在が組織内で正式に認められ、必要な経営資源(予算や人員)を動かすためには、口約束や曖昧な合意では不十分です。プロジェクトマネジメントにおいて、正式な活動開始を宣言する公式文書が「プロジェクト憲章(Project Charter)」です。
プロジェクト憲章の役割
プロジェクト憲章には、主に3つの重要な役割があります。
プロジェクト憲章の3大役割
- プロジェクトの公式な発足: 組織の正式な活動として認可され、予算コードの発行など公式な登録が行われます。
- プロジェクトマネジャー(PM)の任命と権限付与: PMが誰であるかを公式に宣言し、PMが組織のリソース(予算や社内メンバー)をプロジェクト活動のために使用する権限を与えます。
- 主要なステークホルダー間の共通理解: プロジェクトの全体目標、前提条件、制約条件について、発注者(スポンサー)と実行チームの認識を一致させます。
プロジェクト憲章の主な記載内容
プロジェクト憲章は「計画書」ではないため、詳細なスケジュールや作業手順は含みません。その代わりに、プロジェクトの「枠組み」を大まかに(ハイレベルに)定義します。
| 主要項目 | 概要 | 記載の具体例 | なぜ必要か |
|---|---|---|---|
| プロジェクトの目的・背景 | なぜこのプロジェクトを行うのか、ビジネス上の目的。 | 「競合他社に対抗し、若年層向けの新規顧客開拓を行うための新システム開発」 | メンバー全員が迷ったときに立ち返る原点とするため。 |
| 測定可能な目標と成功基準 | プロジェクトが成功したと見なすための明確な指標。 | 「2026年12月までにリリースし、初年度にユーザー登録数10万人を獲得する」 | 成功の評価基準が曖昧だと、終了時の検収や評価で揉めるため。 |
| ハイレベル(初期)スコープ | プロジェクトに含まれるもの、含まれないものの境界。 | 「モバイルアプリ開発(iOS/Android)のみとし、PCブラウザ版は対象外とする」 | スコープの過度な膨張(スコープクリープ)を防ぐため。 |
| マイルストーンスケジュール | 重要な節目となる日付のリスト。 | 「要件定義完了:3月末、開発完了:9月末、テスト完了:11月末、リリース:12月中旬」 | 全体のペースを合わせ、納期に対する意識と期待値を関係者間で共有するため。 |
| プロジェクトマネジャーの権限 | PMが決定できる範囲や資源の限界。 | 「PM:山田太郎。メンバーの選定および1,000万円以内の予算執行権限を付与する」 | PMに実質的な権限がない状態を防ぐため。 |
プロジェクト憲章の承認フロー
プロジェクト憲章はPM自身が起草することが多いですが、発行・署名するのはPMではありません。プロジェクトに資金を提供する「プロジェクト・スポンサー(または発注元責任者)」です。
図 2-2:プロジェクト憲章の承認と権限付与の関係
憲章作成を省略した場合の課題
憲章を作らずにスタートしてしまったプロジェクトでは、以下のような問題が発生する可能性があります。
- 他部門の管理者からプロジェクトへの協力を得られず、必要なリソースが確保できなくなる。
- プロジェクトの終盤に、経営層から成果物の方向性や予算について指摘を受け、進行が滞る。
このような社内調整や意思決定のトラブルを予防し、スポンサーの支援を得てスムーズに進めるために、プロジェクト憲章は立ち上げ期の重要なアウトプットとして発行する必要があります。