「誰が決めるか」を設計する — RAPID・DACIで意思決定を組織に埋め込む
意思決定の遅さは個人の問題ではなく、役割設計の欠如です。BainのRAPIDとIntuitで生まれたDACIを使い、決定権・推奨権・承認権を案件ごとに整理し、組織の判断速度を構造的に高める方法を解説します。
多くの経営者が「うちの会社は決まらない」と感じています。しかしその解決策が「もっと早く決断してほしい」という人への働きかけに終わるとき、問題は解消しません。意思決定の遅さは、意志や能力の問題ではなく、「誰が何を決めるか」という役割設計の欠如から生まれます。この構造を整えないまま会議を減らしたり権限移譲を宣言したりしても、決定は止まり続けます。
この問題を解くための実践的な道具として、BainのRAPIDフレームワークがあります。RAPIDは5つの役割——Recommend(提案)・Agree(承認)・Perform(実行)・Input(情報提供)・Decide(決定)——の頭文字です。提案を構築するのがR、法令・規制上の制約に限定された拒否権を持つのがA、決定後の実行を担うのがP、専門知識や現場情報を提供するのがI、そして最終的な意思決定を下すのがDです。各役割を担う人物を案件ごとに明示することで、「誰が何をする組織か」が一目で見えるようになります。
RAPIDの核心は、Dを一人に絞ることです。複数人が「承認者」として並ぶ組織では、全員の同意が取れるまで案件が宙に浮きます。Dが一人であれば、賛否が割れても決断は出ます。Bainは導入の最初に「現行の意思決定でDが何人いるか」を可視化することを推奨しています。多くの組織で、Dに相当する人物が複数存在するか、そもそも誰もDとして指定されていないことが明らかになります。Aについても同様で、法令・ブランド・財務統制といった明確な根拠のない「なんとなくの拒否権」は排除することが原則です。
もうひとつの有力な道具がDACIです。1980年代にIntuitで生まれたこのフレームワークは、Driver(プロセス責任者)・Approver(最終決定者)・Contributors(情報提供者)・Informed(共有先)の4役割で構成されます。RAPIDとの主な違いは、Approverが「限定的な拒否権を持つ存在」ではなく「最終意思決定者」として機能する点と、プロセス全体を推進するDriverを独立して設ける点にあります。DACIはとくにプロダクト開発やプロジェクト単位の判断に向いており、Approver1人・Driver1人という二軸で役割を明確にします。
RAPIDとDACIの使い分けは、判断の性質によって決まります。クロスファンクショナルな戦略的意思決定で多くのステークホルダーが関与する場面ではRAPIDが適しています。製品・プロジェクト単位の判断でプロセス管理と意思決定の軸を明確にしたい場面ではDACIが適しています。しかしどちらを選ぶかより重要なのは、「最終決定者は1人」「実行担当者を最初から巻き込む」という原則を守ることです。この原則を崩すと、どのフレームワークも形骸化します。
実装は全案件への一括適用ではなく、「止まりやすい意思決定」から始めることを当研究所では推奨しています。まず経営会議で頻繁に差し戻される案件を10〜20件抽出し、それぞれにRAPIDまたはDACIの役割を割り当てます。この作業を通じて、同一の人物がD・A・Iを兼務している構造、あるいはAが無制限に広がっている構造が浮かびます。その重複と空白を整理するだけで、多くの組織は同じ案件の滞留時間を大幅に短縮できます。
当研究所は、ヘルスケア経営の現場で医師・看護・経営管理という多職種連携の意思決定複雑さと向き合ってきました。そこで学んだのは、役割を設計しても、各自が「私がそのDだ」「私はIで十分だ」と納得していなければ運用は続かないということです。役割の割り当ては一覧表を作って終わりではなく、最初の数件を実際に走らせて修正するサイクルが不可欠です。この現場検証の積み重ねを、私たちは企業変革の支援に持ち込んでいます。
意思決定の速度は、個人のリーダーシップだけでは変えられません。RAPIDやDACIは、どの役割が何をするかを可視化し、議論を「誰が決めるか論争」から「何を決めるか議論」へと切り替える設計ツールです。自社の意思決定構造を体系的に見直したいとお考えの経営層の方は、ぜひ経営層ブリーフィング( https://fujii-consulting.jp/contact )からご相談ください。
出典
FREE MEMO
経営層向けの実務メモを、メールで受け取る
本文では書ききれなかった実装手順、意思決定の観点、AI活用のチェックポイントを短く届けます。
無料メールを受け取る