フレームワーク活用ガイドひとことで言うと#
「誰が決めるのか」が曖昧だと、会議は永遠に終わらない。状況に応じて適切な意思決定モデルを選び、役割を明確にすることで、スピードと納得感を両立させる。
押さえておきたい用語#
- DACI（ダシー）
- Driver（推進者）・Approver（承認者）・Contributor（貢献者）・Informed（報告先）の頭文字で意思決定の役割を明確にするフレームワークを指す。
- RAPID（ラピッド）
- Recommend・Agree・Perform・Input・Decideの頭文字で、特に大規模組織での意思決定プロセスを整理するモデルを指す。
- コンセンサス（Consensus）
- 全員の合意を得て意思決定する方式のこと。納得感は高いが時間がかかるため、使いどころを選ぶ。
- Decision Record
- 何を・なぜ・誰が決めたかを記録として残す文書のこと。「言った言わない」を防ぎ、後から経緯を追える。
意思決定モデルの全体像#
こんな悩みに効く#
- 会議で議論はするが、結局何も決まらない
- 「みんなで決めよう」が口癖で、責任の所在が曖昧
- 決めたはずなのに、後から「聞いてない」とひっくり返される
基本の使い方#
主要な4つのモデルを把握する。
1. 独断型（Autocratic）
- 1人（通常はリーダー）が決定する
- メリット: 最速。緊急時に有効
- デメリット: 納得感が低い、情報が偏る
2. DACI（Driver-Approver-Contributor-Informed）
- D（推進者）: プロセスを進める人
- A（承認者）: 最終決定権を持つ人（1人）
- C（貢献者）: 意見やデータを提供する人
- I（報告先）: 結果を知らされる人
3. RAPID（Recommend-Agree-Perform-Input-Decide）
- R（推薦）: 提案を作る人
- A（同意）: 拒否権を持つ人
- P（実行）: 決定を実行する人
- I（インプット）: 情報提供する人
- D（決定）: 最終決定者
4. コンセンサス型
- 全員の合意を得て決定する
- メリット: 高い納得感とコミットメント
- デメリット: 時間がかかる、妥協案になりがち
すべての意思決定に同じモデルを使う必要はない。状況によって使い分ける。
| 状況 | 推奨モデル |
|---|---|
| 緊急で即断が必要 | 独断型 |
| 影響範囲が広い戦略的決定 | RAPID / DACI |
| チーム内の運用ルール変更 | コンセンサス |
| 日常的な業務判断 | 独断型（担当者に委任） |
| 複数部門にまたがる決定 | DACI |
判断基準: (1)緊急度 (2)影響範囲 (3)必要な専門知識 (4)メンバーの納得感の重要度
モデルを選んだら、具体的に誰がどの役割を担うかを決め、全員に共有する。
DACIの場合の例:
- 「この件のDriverは山田さん。Approverは部長の鈴木さん。ContributorはAチームの全員。InformedはBチームと経営会議」
ポイント:
- Approver（最終決定者）は必ず1人にする。2人以上いると責任が曖昧になる
- 役割は議論の前に決める。議論してから「で、誰が決めるの？」では遅い
- 役割をドキュメントに残す（議事録、チケット、Slackなど）
意思決定の結果をDecision Recordとして記録する。
記録すべき項目:
- 何を決めたか（決定事項）
- なぜそう決めたか（根拠と検討した選択肢）
- 誰が決めたか（役割と責任者）
- いつまでに何をするか（次のアクション）
「言った言わない」を防ぎ、後から経緯を振り返れるようにする。 特に重要な決定は、全体への共有も忘れない。
具体例#
状況: 従業員150名のSaaS企業。大型の新機能をリリースするかどうかの判断が必要。品質・営業・顧客の観点から意見が割れている。
モデル選択: 影響範囲が広く複数部門にまたがる → DACIモデルを採用
役割割り当て:
- D（Driver）: プロダクトマネージャーの高橋さん → 情報を集め、提案を作成
- A（Approver）: VP of Productの渡辺さん → 最終GO/NO-GOを判断
- C（Contributor）: QAリード（品質観点）、セールスリード（顧客観点）、テックリード（技術観点）
- I（Informed）: カスタマーサクセスチーム、マーケティングチーム
プロセス:
- 高橋さんがContributorから意見を収集（2日間）
- 品質: 「重大バグは0件。軽微な既知バグ3件は次スプリントで修正予定」
- 営業: 「大口顧客2社がこの機能をリリース待ち。遅延すると失注リスクあり」
- 技術: 「ロールバック手順は準備済み。段階リリースなら安全」
- 高橋さんが提案書を作成:「段階リリース（先行10%→50%→100%）でGO」
- 渡辺さんが承認。Decision Recordに記録し、Informed群に共有
| 指標 | 役割曖昧なまま（過去の実績） | DACI適用後 |
|---|---|---|
| 意思決定にかかった時間 | 平均2週間 | 3日 |
| 決定後の「聞いてない」クレーム | 毎回3〜4件 | 0件 |
| リリース後の障害 | — | ゼロ |
「誰が何を決めるか」を事前に明確にしただけで、意思決定スピードが5倍になり、関係者の不満もなくなった。
状況: 従業員200名の中堅建設会社。現場で安全上の判断が必要な場面で「誰が止める権限を持つか」が曖昧なため、判断が遅れてヒヤリハットが月平均5件発生していた。
モデル選択: 安全に関わる緊急判断 → 独断型を明文化
意思決定ルール:
- 現場監督: 安全リスクを感知した場合、即座に作業停止を命じる権限を持つ（独断型レベル1）
- 作業員全員: 危険を感じた場合、自分の判断で作業を中断する権限を持つ
- 安全停止後の再開判断 → DACI（Driver: 安全管理者、Approver: 現場所長）
| 指標 | ルール明文化前 | 明文化6ヶ月後 |
|---|---|---|
| ヒヤリハット件数 | 月平均5件 | 月平均1.2件 |
| 安全停止から再開までの平均時間 | 45分（判断迷い含む） | 18分 |
| 作業員の「安心して働ける」スコア | 10点中5.8 | 10点中8.3 |
「誰でも止められる」という独断型の権限を全員に明文化したことで、判断の迷いがなくなり、安全性と作業効率の両方が向上した。
状況: 職員15名のNPO法人。リモートワークの導入に際して、出勤日数やコアタイムについて意見が割れていた。理事長が一方的に決めると現場の不満が大きくなるリスクがあった。
モデル選択: 全員の働き方に直接影響するルール変更 → コンセンサス型
プロセス:
- 事前に全員にアンケート（希望する出勤日数、コアタイム、懸念事項）
- 結果をもとに3つの選択肢を作成し、全体会議で90分間議論
- 各選択肢のメリット・デメリットを全員で検討
- 修正を重ね、全員が「これなら納得できる」案に到達
決定内容: 週2日出勤（全員揃う日を火曜に固定）+ コアタイム10:00〜15:00 + 3ヶ月後に見直し
| 指標 | 決定プロセス | 結果 |
|---|---|---|
| 決定にかかった時間 | 2週間（アンケート含む） | — |
| 決定への納得度 | — | 10点中8.7 |
| 3ヶ月後の運用遵守率 | — | 95% |
時間はかかったが、全員が納得して決めたルールは遵守率が極めて高い。働き方のように「全員が当事者」のテーマにはコンセンサス型が最適。
やりがちな失敗パターン#
- 全員の合意を常に求める — コンセンサスは時間がかかる。日常的な判断には独断型やDACIを使い、本当に全員の納得が必要な場面だけコンセンサスを使う
- Approverを複数人にする — 「部長と本部長の両方の承認が必要」にすると、どちらかが不在だけで止まる。最終決定者は必ず1人にする
- 決定の記録を残さない — 「あの時の会議で決めたよね？」が通じない。Decision Recordを残す習慣をつけないと、同じ議論を何度も繰り返す
- モデルを決めずに会議を始める — 「今日の議題の意思決定モデルは何か」を冒頭で確認しないと、議論が発散して何も決まらない。アジェンダに意思決定モデルを明記する
まとめ#
意思決定モデルは、「誰が、どのプロセスで、何を決めるか」を明確にするフレームワーク。独断型・DACI・RAPID・コンセンサスを状況に応じて使い分け、役割を事前に明確にすることで、意思決定のスピードと質が格段に上がる。次の重要な会議の前に、「この件の意思決定モデルは何か」を決めてから臨もう。