フレームワーク活用ガイドひとことで言うと#
組織内の意思決定について「誰が・何を・どのレベルで」決められるかを一覧表にまとめるフレームワーク。曖昧になりがちな権限の範囲を可視化し、意思決定のスピードと質を同時に高める。
押さえておきたい用語#
- Decision Rights（デシジョン ライツ）
- 特定の事項について最終的に決定を下す権限のこと。「誰が決めるか」を組織として公式に定めたもの。
- Authority Level（オーソリティ レベル）
- 意思決定における権限の段階を指す。単独決裁・上長承認・合議制など、決定に必要なプロセスの重さを表す。
- Escalation（エスカレーション）
- 自分の権限範囲を超える判断が必要なとき、上位の意思決定者に判断を引き上げる手続き。
- Decision Area（デシジョン エリア）
- 意思決定の対象となる業務領域。人事・予算・技術選定・顧客対応など、組織の活動を分類した単位である。
- Accountability（アカウンタビリティ）
- 意思決定の結果に対して説明責任を負う考え方。決定権を持つ者は、その結果についても責任を引き受ける。
意思決定権マトリクスの全体像#
こんな悩みに効く#
- 「これ、誰が決めるんでしたっけ？」が週に何度も発生する
- マネージャーに判断が集中して、本人も部下もボトルネックに苦しんでいる
- 組織が拡大して、以前は暗黙の了解で回っていた意思決定が混乱し始めた
- 権限委譲したいけど、どこまで任せていいのか基準がない
基本の使い方#
まず組織内で繰り返し発生する意思決定を書き出す。抜け漏れを防ぐために、過去3か月間で「誰が決めるか迷った場面」を関係者にヒアリングするとよい。
- 人事系: 採用・異動・評価・昇格
- 予算系: 投資判断・経費承認・ベンダー選定
- 業務系: 技術選定・プロセス変更・顧客対応方針
- 戦略系: 新規事業・パートナーシップ・撤退判断
縦軸に組織の役割（経営層・部門長・チームリーダー・メンバーなど）を並べ、権限レベルの選択肢を決める。
よく使われる権限レベルは以下の4段階。
| レベル | 意味 | 例 |
|---|---|---|
| 単独決裁 | 自分の判断だけで実行できる | TLが技術スタックを選ぶ |
| 起案 | 提案はできるが承認が必要 | 部門長が採用計画を起案 |
| 承認 | 他者の起案に対してGoを出す | 経営層が予算を承認 |
| 報告受領 | 決定後に結果を共有される | 経営層が顧客対応の報告を受ける |
役割×領域のすべてのセルに権限レベルを記入する。ここで大事なのは「1つの決定領域に単独決裁者は1人だけ」にすること。2人以上が単独決裁を持つと、結局どちらが決めるかで揉める。
記入が終わったら関係者全員でレビューし、認識のズレを潰す。特に「自分は決裁権を持っていると思っていたが、実は起案止まりだった」というギャップが頻出するので、丁寧にすり合わせる。
マトリクスは作って終わりではなく、以下の運用ルールをセットで整備する。
- エスカレーション基準: どういう条件で上位に判断を上げるか（例: 金額100万円超は部門長決裁）
- 見直し頻度: 四半期に1回、組織変更時は即時見直し
- 保管場所: 全員がアクセスできるドキュメントに公開する
具体例#
創業5年目のWeb制作会社。社長1人にすべての判断が集中し、1日あたり平均12件の承認待ちが発生していた。案件の見積り回答に平均3.2日かかり、顧客から「対応が遅い」とクレームが月4件入るようになった。
意思決定権マトリクスを導入し、以下のように権限を整理した。
| 領域 | 社長 | ディレクター | デザイナー/エンジニア |
|---|---|---|---|
| 50万円以下の見積り | 報告受領 | 単独決裁 | 起案 |
| 50万円超の見積り | 承認 | 起案 | ─ |
| 技術スタック選定 | ─ | 承認 | 単独決裁 |
| 採用（業務委託） | 承認 | 起案 | 推薦 |
導入から2か月後、社長の承認待ちは1日3件に減り、見積り回答は平均0.8日に短縮。顧客クレームもゼロになった。
従業員が40名から120名に急拡大したSaaS企業。以前は「Slackで聞けば誰かが答えてくれる」文化だったが、人数が増えるにつれて「誰に聞けばいいかわからない」「同じ案件に3人が別々の回答をした」といった混乱が頻発するようになった。
CTOが中心となり、プロダクト開発に絞った意思決定権マトリクスを作成した。
- 機能の優先順位: プロダクトマネージャーが単独決裁（以前はCTO・営業部長・CSマネージャーの3者が口を出していた）
- アーキテクチャ変更: テックリードが起案、CTOが承認
- リリース判定: QAリードが単独決裁（以前は「CTO確認待ち」で毎回2日遅れていた）
- 障害対応の初動: オンコール担当が単独決裁、事後にCTOへ報告
結果、機能リリースのリードタイムが平均14日から9日に短縮。「誰に聞けばいいかわからない」というエンゲージメントサーベイの不満項目が**47% → 12%**に下がった。
創業90年、客室数20室の温泉旅館。3代目の現女将（65歳）から4代目の娘（38歳）への世代交代を進めていたが、「どこまでが私の判断でいいのか」と娘が毎回確認するため、2人とも疲弊していた。
旅館の業務を8つの意思決定領域に分け、3段階で権限を移行するマトリクスを設計した。
第1段階（即日移行）: 仕入れ先の選定・SNS運用・スタッフのシフト管理 → 4代目が単独決裁 第2段階（半年後）: 宿泊プランの価格設定・設備投資（200万円以下） → 4代目が単独決裁に昇格 第3段階（1年後）: 大型投資・金融機関との交渉 → 4代目が起案、3代目は助言のみ
移行開始から8か月後、4代目は新しいワーケーションプランを自分の判断で企画・価格設定し、月の稼働率を**58% → 74%**に引き上げた。3代目は「聞かれなくなって寂しいけど、これが正しい姿」と笑う。
やりがちな失敗パターン#
- 全員が「承認」を持ちたがる — 関係者を増やしすぎると承認プロセスが肥大化し、結局何も決まらなくなる。1つの領域の単独決裁者は必ず1名に絞ること
- マトリクスを作ったまま引き出しにしまう — 作成時は盛り上がるが、日常業務で参照されなければ意味がない。判断に迷ったときに「マトリクスを見よう」が口癖になるまで繰り返し使う
- 粒度が粗すぎる — 「予算」と一括りにすると、10万円の備品購入と1,000万円の設備投資が同じ権限レベルになってしまう。金額や影響範囲で分けるのが実用的
まとめ#
意思決定権マトリクスは、組織内の「誰が・何を・どこまで決めるか」を一覧で見える化するツール。作成のコツは、領域の洗い出しを丁寧にやること、そして1つの決定に対して単独決裁者を1人に絞ること。組織が大きくなるほど暗黙の了解は通用しなくなるため、早い段階で明文化しておくと後の混乱を防げる。四半期ごとの見直しを忘れずに。