フレームワーク活用ガイドひとことで言うと#
プロジェクトにおける意思決定の仕組み・権限の階層・報告ルート・監督体制を明確に定義する枠組み。「誰が何を決められるのか」「エスカレーションはどうするのか」を事前に設計し、プロジェクトが組織の戦略に沿って進むように統制する。
押さえておきたい用語#
- ステアリングコミッティ（Steering Committee）
- プロジェクトの最上位の意思決定機関のこと。経営層や事業部長で構成され、方向性や重要課題を審議・決定する。
- エスカレーション（Escalation）
- 現場の権限では判断できない問題を上位の意思決定者に引き上げて判断を仰ぐ行為である。
- RACI チャート
- 各タスクに対する**Responsible（実行者）・Accountable（説明責任者）・Consulted（相談先）・Informed（報告先）**を整理する表を指す。
- 権限委譲（Delegation）
- 上位者がPMやチームリーダーに一定範囲の判断権限を委ねること。適切な委譲がプロジェクトの速度を決める。
プロジェクトガバナンスの全体像#
こんな悩みに効く#
- 意思決定に時間がかかりすぎてプロジェクトが停滞する
- PMが抱えるべきでない判断まで背負わされている
- ステークホルダー間の利害対立で方向性がぶれる
基本の使い方#
意思決定の階層と役割を明確に定義する。
- ステアリングコミッティ（最上位の意思決定機関）のメンバーと権限を決める
- プロジェクトスポンサー、PM、チームリーダーの役割と権限範囲を明文化する
- 各階層で決定できる事項と、上位にエスカレーションすべき事項の基準を設定する
ポイント: 権限が重複したり空白になったりしないように、RACIチャートで整理するのが効果的。
意思決定の手順・基準・タイムラインを標準化する。
- 定例会議の頻度と議題フォーマットを決める
- 議決方法（全会一致・多数決・スポンサー最終決定）を明確にする
- 意思決定のデッドライン（例: エスカレーション後48時間以内に回答）を設ける
ポイント: 意思決定の速度はプロジェクトの速度に直結する。迅速に決定できる仕組みを優先して設計する。
プロジェクトの状況を適切な粒度で関係者に報告する仕組みを作る。
- 報告頻度と内容を階層ごとに定義する（週次→PM、月次→ステアリングコミッティ）
- KPIやしきい値を設定し、異常を早期に検知する仕組みを作る
- 監査やレビューのタイミングとチェック項目を決める
ポイント: 過剰な報告は負担、過少な報告は危険。「この人はこの情報が必要」を報告先ごとに整理する。
問題発生時の段階的な対応手順を事前に決めておく。
- レベル別のエスカレーション基準を設定する（予算超過10%以内→PM判断、10%超→スポンサー判断）
- エスカレーション時の情報提供フォーマットを統一する
- エスカレーション後のフォローアップルールを定める
ポイント: エスカレーション＝失敗ではない。適切なエスカレーションはプロジェクトを守る重要な行動であることをチーム全体に浸透させる。
具体例#
状況: 従業員2,500名の商社。基幹システム（ERP）の全面刷新プロジェクト。予算12億円、期間30ヶ月。5つの事業部が利害関係者。
ガバナンス構造:
| 階層 | 構成 | 権限範囲 | 開催頻度 |
|---|---|---|---|
| ステアリングコミッティ | CIO・事業部長5名 | 予算500万円超の変更、中止判断 | 月次 |
| スポンサー | CIO | 予算500万円以内の変更承認 | 隔週 |
| PM | IT部門リーダー | スケジュール2週間以内の調整、技術選定 | 週次 |
| チームリーダー | 各モジュール担当4名 | 担当範囲内の実装判断 | 日次 |
意思決定プロセス: ステアリングコミッティは多数決で意思決定。CIOが最終決裁権を持つ。諮問から48時間以内に回答するルール。
エスカレーション事例: 開発フェーズでEVMのCPI（コスト効率指数）が0.85に低下。PMがスポンサーにエスカレーション。分析の結果、外注ベンダーの生産性が想定の70%と判明。スポンサー判断でベンダー増員を決定し、2ヶ月後にCPIが0.95に回復。
権限の階層を明確にしていたことで、PMが「自分で判断すべきか、上に上げるべきか」で迷う時間がゼロになった。意思決定の速度がプロジェクトの速度を決める。
状況: シリーズAのFinTechスタートアップ（社員25名）。モバイル決済アプリの開発プロジェクト。投資家からの資金5億円をもとに、12ヶ月でローンチを目指す。
ガバナンス設計:
- 取締役会: 四半期ごとに予算執行状況と事業KPIを報告
- CEO: 月次でプロダクト方向性と予算200万円超の判断
- CTO兼PM: 週次で技術判断、予算200万円以内の外注判断
- 開発チーム: 日次でスプリント内の実装判断
報告・監視の仕組み:
- 週次: CTO→CEOにバーンレート・開発進捗・KPIダッシュボードを共有
- 月次: CEO→取締役会にマイルストーン達成状況・資金残高を報告
- しきい値: バーンレートが計画比120%を超えたら即座にCEOにアラート
| 指標 | しきい値 | 実際の発動 |
|---|---|---|
| バーンレート | 計画比120%超 | Month 5で125%→外注費見直し |
| スプリント完了率 | 70%未満が2スプリント連続 | 発動なし |
| クリティカルバグ | 5件以上/スプリント | Month 8で6件→品質強化週間を設定 |
この取り組みが示すように、少人数のスタートアップでも軽量なガバナンスを入れたことで、投資家への報告が体系化され、「燃え尽き型の開発」を防いで計画通り12ヶ月でローンチを実現した。
状況: 学生数1.2万人の私立大学。教務・学生・図書館・財務の4つの独立システムを統合するプロジェクト。予算4億円、期間24ヶ月。4つの部署の利害が対立しやすい構造。
ガバナンスの工夫: 各部署の部長がステアリングコミッティに参加し、副学長がチェアを務める。利害対立が起きた場合は副学長が最終判断するルールを事前に合意。
エスカレーション基準:
- レベル1（チーム内）: 技術課題 → 1営業日以内に解決
- レベル2（PM判断）: スケジュール1週間以内の変更 → 3営業日以内
- レベル3（スポンサー判断）: 予算100万円超の追加 → 5営業日以内
- レベル4（ステアリングコミッティ）: 部署間の利害対立 → 月次会議で審議
利害対立の解決例: 教務部と学生部でデータ項目の定義が異なり、統合仕様で対立。PMがレベル4にエスカレーション。ステアリングコミッティで「教務部の定義を基準とし、学生部には変換ロジックを提供」と決定。3週間の膠着を1回の会議で解消。
大学という合意形成が難しい組織でも、ガバナンス構造の中に「利害調整の場と最終判断者」を明確に組み込んだことで、プロジェクトが部署間の政治で止まることを防げた。
やりがちな失敗パターン#
- ガバナンスを形だけ作って運用しない — 立派な体制図を作っても会議が開かれなければ意味がない。定例会議と報告を確実に実行する仕組み（カレンダー予約・アジェンダ自動送信等）を作る
- 権限委譲が不十分 — すべての判断をステアリングコミッティに上げるとボトルネックになる。PMが自律的に判断できる範囲を十分に広く設定する
- ステークホルダーの利害調整を避ける — 対立を先送りにすると後半で爆発する。ガバナンス構造の中に利害調整の場を組み込む
- エスカレーションを「告げ口」と捉える文化 — チームが問題を隠すようになり、手遅れになってから発覚する。エスカレーションは組織を守る行動であると明確に伝える
まとめ#
プロジェクトガバナンスは、意思決定構造・権限委譲・報告体制・エスカレーションルートを事前に設計する枠組み。「誰が何を決めるか」を明確にすることで、意思決定の速度と質が向上し、プロジェクトの方向性がぶれなくなる。大規模プロジェクトほどガバナンスの重要性は高く、プロジェクト憲章やステークホルダー分析と合わせて初期段階で整備すべき基盤である。