DACI意思決定フレームワーク

英語名 DACI Decision Framework
読み方 ダチ ディシジョン フレームワーク
難易度
所要時間 役割設定10分 / 意思決定会議30〜60分
提唱者 Intuit社の意思決定プロセス / RACIの派生モデル
目次

ひとことで言うと
#

意思決定に関わる人を**Driver(推進者)・Approver(承認者)・Contributor(助言者)・Informed(報告先)**の4役割に分け、「誰が決めるか」を事前に明確にすることで、合議の迷走や決定の先送りを防ぐ手法。

押さえておきたい用語
#

押さえておきたい用語
Driver(ドライバー)
意思決定プロセスを推進する責任者。情報を集め、選択肢を整理し、会議をファシリテートする。決定権そのものは持たない。
Approver(アプルーバー)
最終的にYes/Noを判断する唯一の人。意見が割れた場合にこの人の判断が最終決定となる。原則1名に限定する。
Contributor(コントリビューター)
専門知識や現場の視点から助言・意見を提供する人。Approverの判断材料を豊かにする役割で、決定権は持たない。
Informed(インフォームド)
決定結果を事後に通知される関係者。決定プロセスには参加しないが、結果の影響を受けるため知らされる必要がある。

DACI意思決定フレームワークの全体像
#

DACI意思決定フレームワーク:4つの役割が意思決定を構造化する
D ─ Driver(推進者)情報収集・選択肢整理・会議運営プロセスを前に進める責任者A ─ Approver(承認者)最終のYes/Noを判断する原則1名のみ提案C ─ Contributor(助言者)専門知識や現場感で助言する決定権は持たないが意見は尊重I ─ Informed(報告先)決定結果を事後に共有されるプロセスには参加しない助言通知明確な意思決定誰が決め、誰が知るべきかが明確になる
DACI意思決定の実践フロー
1
役割アサイン
決定事項ごとにD・A・C・Iを明示的に割り当てる
2
情報収集
DriverがContributorから意見と情報を集める
3
提案と承認
DriverがApproverに選択肢と推薦を提示し判断を仰ぐ
共有と実行
決定結果をInformedに通知し実行に移す

こんな悩みに効く
#

  • 会議で議論はするが誰も決めずに持ち帰りになる
  • 関係者全員の合意を取ろうとして決定が遅れる
  • 「あの件、誰が決めるんでしたっけ?」が頻発する
  • 決まった後に「聞いてない」と言われる人が出てくる

基本の使い方
#

決定事項を明文化する
「何を決めるのか」を1文で書き出す。「新機能の技術選定」「来期のマーケティング予算配分」のように、具体的に範囲を限定する。曖昧だと役割を割り当てられない。
4つの役割を割り当てる
Driver(1名)・Approver(原則1名)・Contributor(2〜5名)・Informed(必要な人数)を決定事項ごとにアサインする。Approverを2名以上にすると合議で詰まるため、1名に限定するのが原則。
DriverがContributorから情報を集める
Driverは期限を設け、Contributorに意見や情報提供を依頼する。非同期(ドキュメント・Slack)で集めると効率的。Contributorは自分の専門領域から意見を出すが、最終判断はしない。
Approverに提案し判断をもらう
Driverが選択肢を整理し、メリット・デメリット・推薦案をまとめてApproverに提示する。Approverはその場で判断するか、追加情報を要求する。最終的にYes/Noを明確に出す。
決定結果をInformedに共有する
決定内容・理由・今後のアクションを文書化し、Informedに共有する。「なぜその決定になったか」を添えることで、後から「聞いてない」「なぜそうなった」という反発を防ぐ。

具体例
#

例1:スタートアップが新機能のAPIプラットフォームを選定する

エンジニア15名のSaaSスタートアップ。新機能で外部API連携が必要になったが、候補が3つあり、2週間議論しても決まらなかった。

DACIを導入し、以下の通り役割を割り当てた。

役割担当理由
Driverテックリード技術情報を最も集約できる
ApproverCTO技術戦略の最終決定者
Contributorバックエンド2名、インフラ1名各専門領域の知見
InformedPM、デザイナー、営業機能のスケジュールに影響する

Driverが3日でContributorからの意見を集め、比較表を作成してCTOに提示。CTOが翌日に判断し、合計 4日 で決定が完了した。それまで2週間かかっていた決定プロセスが大幅に短縮されている。

例2:メーカーの新製品パッケージデザインの最終決定に使う

食品メーカー(従業員400名)の新商品開発。パッケージデザインの最終候補3案に対し、マーケティング・営業・製造・経営企画の4部門から意見が出て収拾がつかなくなった。

DACIで役割を整理した。

Driverはブランドマネージャー、Approverはマーケティング部長(1名)に絞った。営業部長と製造部長はContributor、経営企画と広報はInformedに設定。

Contributorからの意見を「ブランド戦略との整合性」「店頭での視認性」「製造コスト」の3軸で整理し、Approverに提示。1週間で最終決定 に至り、発売スケジュールの2週間前倒しに成功した。

例3:自治体のDX推進チームがクラウドサービスを選定する

人口20万人の自治体。DX推進室(5名)がクラウドサービスの導入を検討していたが、情報システム課・総務課・財政課の間で意見が割れ、3か月間決定が保留されていた。

DX推進室長がDACIの説明資料を作り、副市長を交えた会議で役割を正式に決めた。

Driver:DX推進室の主任、Approver:副市長、Contributor:情報システム課長・総務課長・外部コンサルタント、Informed:各課の担当者・議会報告用の企画課。

Approverが副市長に一本化されたことで「どちらの課の意見を優先するか」の調整が不要になり、Driverの提案から 2週間で正式決定。3か月の停滞が嘘のように動き出したという。

やりがちな失敗パターン
#

  1. Approverを複数名にする ─ 2名以上のApproverは「誰が最終判断するか」で再び詰まる原因になる。原則1名に限定する
  2. Driverが情報を集めずにApproverに丸投げする ─ DriverはApproverが判断しやすい状態を作る責任がある。選択肢の整理・比較表の作成はDriverの仕事
  3. ContributorとApproverの区別が曖昧 ─ 「意見は聞くが決定権はない」ことを明示しないと、Contributorが事実上の拒否権を持ってしまう
  4. Informedへの共有を忘れる ─ 決定プロセスに参加しなかった人が結果を知らないと、実行段階で抵抗が生まれる。共有は決定翌日までに行う

企業での実践例 — Atlassian
#

DACIフレームワークを全社的に導入し、広く普及させたのがAtlassianである。Jira、Confluence、Trelloなどのコラボレーションツールを開発するAtlassianは、自社の急成長に伴い「関係者が増えるほど意思決定が遅くなる」問題に直面した。そこでDACIを全社の意思決定プロセスの標準として採用し、Confluenceのテンプレートとして組み込んだ。Atlassianの社内では、技術選定からマーケティング施策の決定まで、あらゆる重要な意思決定にDACIテーブルの記入が求められる。

Atlassianが公開している「Team Playbook」では、DACIの具体的な運用方法が無償で公開されている。特に強調されているのが「Approverは原則1名」というルールの徹底である。Atlassianの共同CEO(当時)のマイク・キャノン=ブルックスは「Approverを2人にした瞬間、意見が割れたときに誰も決められなくなる。1人のApproverが間違った判断をするリスクより、誰も決められないリスクのほうがはるかに大きい」と述べている。Atlassianの実践を通じて、DACIはソフトウェア業界を中心にグローバルに広まり、現在ではテック企業以外の製造業や行政機関でも採用されている。

まとめ
#

DACIは、意思決定に関わる人をDriver・Approver・Contributor・Informedの4役割に分け、「誰が推進し、誰が最終判断し、誰が助言し、誰に共有するか」を事前に明確にする手法。Approverを1名に限定することで合議の迷走を防ぎ、Driverが情報を整理して判断材料を揃えることで決定のスピードと質を両立させる。