フレームワーク活用ガイドひとことで言うと#
プロジェクトで発生する決定事項のカテゴリ（技術選定・予算変更・スコープ変更など）ごとに、誰が決定権を持ち、誰が承認し、誰に報告するかを一覧表にするガバナンスツール。
押さえておきたい用語#
- 決定権限（Decision Authority）
- 特定のカテゴリの決定について最終判断を下す権限。金額や影響範囲に応じて権限者が変わることが多い。
- 承認（Approval）
- 決定者が出した判断を上位者が確認し正式に有効にするプロセス。すべての決定に承認が必要なわけではなく、閾値で分ける。
- 閾値（Threshold）
- 権限を分ける金額や影響度の境界線。「100万円未満はPMが決定、100万円以上は部長承認」のように設定する。
- エスカレーションパス
- 権限者が判断できない場合に上位の権限者へ引き上げる経路。事前にパスを決めておくことで迷わず上申できる。
意思決定権限マトリクスの全体像#
こんな悩みに効く#
- 「これは誰が決める案件？」という確認だけで1日消える
- 小さな変更も全部部長承認が必要で現場が止まる
- 権限が明文化されておらず属人的な判断になっている
- 新任のPMが権限の範囲がわからず動けない
基本の使い方#
具体例#
従業員200名のIT企業。基幹システム刷新プロジェクト（予算3億円）で、新任PMが「どこまで自分で決めてよいか」がわからず、すべてを部長に確認していた。結果、部長がボトルネックになり週に 5件 の決定待ちが常態化。
意思決定権限マトリクスを作成し、以下の閾値を設定。
| 決定カテゴリ | PMが決定 | 部長承認 | 役員承認 |
|---|---|---|---|
| 予算変更 | 50万未満 | 50〜300万 | 300万超 |
| スケジュール変更 | 1週間未満 | 1〜4週間 | 1か月超 |
| 技術選定 | すべて | 報告のみ | ─ |
| ベンダー変更 | ─ | すべて | ─ |
導入後、PMが即断できる案件が全体の 65% に達し、部長の決定待ちは週5件→1件に減少。プロジェクトの意思決定速度が大幅に改善した。
大手製薬企業。臨床試験フェーズIIのプロジェクトで、規制当局への報告内容の判断が医師・薬事部・品質管理部の3部門で重複しており、毎回「誰が最終判断するのか」で紛糾していた。
マトリクスで決定カテゴリを「安全性情報の報告判断」「プロトコル変更」「試験中止判断」の3つに絞り、それぞれの権限者を明確化。
安全性情報は治験責任医師が決定、プロトコル変更は薬事部長が承認、試験中止は役員会議が決定という構造にした結果、報告判断にかかる期間が 平均12日→3日 に短縮。規制当局からの評価も「迅速な報告体制」として高評価を得た。
年間参加者5,000名の教育系NPO。年次カンファレンスの運営プロジェクトで、実行委員15名が「自分の担当範囲でどこまで使えるか」がわからず、すべてを代表理事に確認していた。
マトリクスをGoogleスプレッドシートで作成し、「会場手配」「登壇者招聘」「広報活動」「予算執行」の4カテゴリで権限を整理。各担当は 10万円未満 の支出を自己判断で実行可能とした。
代表理事への確認回数は月 30件→8件 に減少。実行委員からは「動きやすくなった」という声が上がり、イベント準備期間が前年比 3週間短縮 された。
やりがちな失敗パターン#
- 閾値を設けず全案件で同じ承認フローにする ─ 10万円の変更も1億円の変更も同じフローでは現場が止まる。金額と影響度で権限を段階化する
- マトリクスを作るが共有しない ─ PMOだけが知っているマトリクスは意味がない。プロジェクト憲章やWikiに掲載し全員がアクセスできるようにする
- プロジェクト中に一度も見直さない ─ 状況は変わる。四半期に1回は「このマトリクスで運用に問題はないか」を確認する
- 「決定」を複数の人に割り当てる ─ 1カテゴリ×1閾値に対して決定者は必ず1名。複数にすると責任の押し付け合いになる
まとめ#
意思決定権限マトリクスは、プロジェクトの決定カテゴリ×役割で「誰がどの範囲を決められるか」を一覧化するガバナンスツール。閾値で権限者を段階化することで、小さな判断は現場で即断、大きな判断だけ上位に上げる仕組みを作れる。作成後はステークホルダー全員で合意し、四半期ごとに見直すことで形骸化を防ぐ。