会議で意見はたくさん出たのに、最後に誰が決めるのかわからず、結論が次回へ持ち越されることはないでしょうか。関係者が増えるほど、全員の同意を待つ、責任者へ情報が届かない、決定後に知らなかった人が現れるといった停滞が起こりやすくなります。
この問題は、参加者の熱意だけでは解決しにくいものです。意見を集める人、最終的に決める人、専門知識を提供する人、決定を知らせる人が曖昧だからです。ダシー（DACI）は、意思決定に関わる人を4つの役割へ分け、決めるまでの流れを明確にするフレームワークです。
ダシーを使う目的は、承認者へ判断を丸投げすることではありません。推進役が論点と期限を管理し、貢献者から必要な情報を集め、承認者が基準に沿って決め、報告先へ結果と影響を共有します。役割を先に合意しておけば、会議の人数を増やさずに関係者を適切に巻き込めます。
この記事では、ダシーの4役、RACIとの違い、60分で意思決定の土台を作る手順、業務ツール選定の実践例を解説します。役職名ではなく、今回の決定で果たす役割として割り当てる考え方をつかんでいきましょう。
この記事を読むと次のことがわかります
ダシーは意思決定に関わる人の役割を4つに分ける
ダシーでは、推進役、承認者、貢献者、報告先を区別します。これは組織の肩書を付け直す作業ではありません。特定の意思決定について、誰が情報を集め、誰が決定し、誰の知識が必要で、誰へ結果を知らせるかを定義するものです。
一人が複数の役割を兼ねることもありますが、最終決定者は原則として一人に絞ります。承認者が複数いると、意見が割れたときの決め方が再び曖昧になるからです。組織上どうしても複数承認が必要なら、承認順序と不一致時の扱いまで決めます。
ドライバーは決定までの進行を担う推進役
ドライバー（Driver）は、決定すべき問いを定義し、関係者を集め、必要な資料と期限を管理します。自分の案を通す人ではなく、承認者が判断できる状態を期限までに作る人です。会議設定、論点整理、未回答事項の追跡も担当します。
適任なのは、テーマを理解し、関係者へ連絡でき、進行に必要な時間を確保できる人です。役職が最も高い人とは限りません。実務担当者が推進役となり、部門長が承認者になる組み合わせも自然です。
推進役には決定権がなくても構いませんが、期限を守るために関係者へ確認を求められる後押しは必要です。任命時には、どこまで日程を調整できるか、情報が集まらないとき誰へ相談するかも合意しておくと、名前だけの役割になりにくくなります。
アプルーバーは最終判断を引き受ける承認者
アプルーバー（Approver）は、集まった情報と判断基準を踏まえて最終決定を行います。単に稟議へ印を押す役ではなく、情報が不十分なら追加確認を求め、トレードオフを引き受けて一つの方向を選びます。
承認者には、対象範囲の決定権と、結果へ責任を持てる立場が必要です。権限がない人を置くと、決定後に別の承認が必要になり、ダシーを使っても流れが短くなりません。開始時に決定可能な範囲と予算上限を確認しておきます。
承認者が忙しい場合も、最終会議だけ参加すればよいとは限りません。最初に問いと判断基準を確認しなければ、集めた情報が期待とずれるおそれがあります。開始時、重要な前提が変わった時、最終判断時の三つは確認機会として確保します。
コントリビューターとインフォームドを混同しない
コントリビューター（Contributors）は、判断前に専門知識や現場情報を提供する貢献者です。セキュリティ、法務、経理、利用部門など、決定の品質へ影響する知識を持つ人を選びます。全員を入れるのではなく、判断基準ごとに必要な人を絞ります。
インフォームド（Informed）は、決定後に結果を知らせる報告先です。影響は受けるものの、判断材料を提供する必要がない人まで会議へ招かず、決定内容と変更点を共有します。貢献者と報告先を分けることで、参加者を増やしすぎずに情報の抜けを防げます。
同じ人がテーマによって貢献者にも報告先にもなり得ます。たとえば利用部門の代表者は操作要件を出す貢献者ですが、ほかの利用者は決定後に変更を知る報告先です。部署単位で一括せず、今回必要な知識と影響の受け方から分けます。
ダシーを使う前に決定する問いと期限を一つに絞る
役割表を作る前に、何を決めるのかを一文で定義します。『業務を効率化する』では広すぎます。『次年度から営業部で使う顧客管理ツールをA・B・Cのどれにするか』のように、対象、選択範囲、利用開始時期がわかる問いへ変えます。
問いが曖昧なままでは、貢献者が別々の情報を持ち寄り、承認者も何を基準に決めるか迷います。決定期限と、決定後に始まる作業も確認しましょう。導入準備に2か月必要なら、その分を逆算して期限を置きます。
複数部門にまたがる重要な選択へ使う
ダシーは、ツール選定、予算配分、新サービスの方針、業務プロセス変更など、複数の関係者から情報を集めつつ、一人が最終判断するテーマに向いています。誰が決めるか曖昧で、会議が繰り返されている案件も候補です。
一方、日常の小さな判断へ毎回使うと管理の負担が増えます。担当者の裁量で決められること、緊急対応、手順が法令や規程で固定されていることには、既存の権限や手順を使う方が自然でしょう。
適用するか迷う場合は、『関係者が複数いるか』『判断材料を集める必要があるか』『最終決定者が曖昧か』『決定の遅れに影響があるか』を確認します。複数に当てはまるテーマほど、役割を明文化する価値があります。
RACIは実行責任、ダシーは意思決定を中心に置く
RACIは、業務を実行する責任者、最終責任者、相談先、報告先を整理する方法です。ダシーは、特定の意思決定を期限までに成立させる役割へ焦点を当てます。似た文字がありますが、何を明確にする表なのかが異なります。
たとえばツールを選ぶ場面ではダシーを使い、選定後の導入作業にはRACIを使うと分けられます。同じ表へ無理に統合せず、『決める段階』と『実行する段階』を分けると、役割の意味が伝わりやすくなります。
ダシーの推進役とRACIの実行責任者が同じ人になる場合もありますが、自動的に引き継ぐものではありません。選定を進める力と、導入作業を管理する力は別だからです。決定後に改めて実行体制を確認することで、選んだまま進まない状態を防ぎます。
判断基準と制約条件を会議前に共有する
候補を比べる前に、費用、使いやすさ、セキュリティ、導入期間、既存システムとの連携など、判断基準を決めます。すべてを同じ重要度で扱うのではなく、満たさなければ候補から外す必須条件と、比較に使う評価条件を分けます。
承認者が重視する基準は会議前に確認します。議論の最後に初めて『予算上限を超えている』とわかれば、それまでの比較が無駄になりかねません。推進役は、制約条件を早い段階で明文化し、貢献者が同じ前提で情報を出せるようにします。
判断基準には、誰がどの方法で確認するかも添えます。使いやすさなら試用参加者への同じ課題、費用なら同じ利用人数と期間、セキュリティなら社内基準への適合確認という具合です。評価方法が違えば、同じ基準名でも結果を公平に比べられません。
60分で役割と意思決定の進め方を合意する
最初のダシー会議では、結論まで出すことより、決定の問い、役割、判断基準、情報収集、期限を合意する方が重要な場合があります。複雑なテーマを情報不足のまま60分で決めると、後からやり直しになるためです。
ここでは、3～6人程度で意思決定の設計を行う進行例を紹介します。すでに情報がそろっている場合は後半で決定まで進められますが、不足があれば収集担当と期限を決め、次の判断日を設定します。
最初の15分で問いと4つの役割を確定する
推進役が決定したい問い、背景、期限、決定後に始まる作業を説明します。参加者は問いの範囲が広すぎないか、承認者に権限があるかを確認します。その後、推進役と承認者を一人ずつ定めます。
貢献者は、判断基準ごとに必要な知識から選びます。報告先は会議参加者に含めず、部署や担当者名を記録します。役割に迷った人がいれば、『決定前に情報が必要か、決定後の共有でよいか』で分けると整理しやすくなります。
役割を割り当てたら、本人が期待される動きを理解しているか確認します。名前が表に載っていても、資料を出す期限や判断範囲を知らなければ機能しません。欠席者を一方的に貢献者へ置かず、参加可否と担当内容を会議後に合意します。
次の25分で基準と不足情報を整理する
候補、判断基準、必須条件を一覧にし、現時点でわかっている事実を置きます。意見と事実を混ぜず、資料の出所や確認日も残します。わからない欄は推測で埋めず、誰がいつまでに調べるかを決めます。
貢献者同士の意見が異なる場合は、多数決で消さず、前提の違いを確認します。利用人数、想定期間、許容できるリスクが違えば評価も変わります。承認者が判断すべきトレードオフとして記録し、必要な追加情報を絞ります。
不足情報には重要度を付けます。すべてがそろうまで決めないのではなく、結論を変える可能性が高い情報と、あれば望ましい情報を分けます。承認者が許容できる不確実性を示せば、調査が際限なく続くことを防げます。
最後の20分で判断日と共有方法を決める
情報がそろっていれば、承認者が基準に沿って決定し、理由と条件を言葉にします。そろっていなければ、追加情報の締切と次の判断日時を確定します。『検討を続ける』だけで終えず、次に何が起きるかを予定へ落とします。
決定記録には、決定した内容、主な理由、採用しなかった案、前提条件、見直す条件を残します。報告先ごとに必要な情報量は異なるため、全員へ会議録をそのまま送るのではなく、影響する変更と開始日を中心に共有します。
決定していない項目も明記します。たとえば製品は決めたが、移行日は別途調整する場合、その境界を書かなければ受け手がすべて確定したと受け取るかもしれません。決定済み、未決定、次の担当を分けた記録は実行時の混乱を減らします。
新しい問い合わせ管理ツールの選定でダシーを使う
具体例として、サポート部門が問い合わせ管理ツールを選ぶ場面を考えます。メール共有では担当漏れが起きており、3か月後までに新しい仕組みを導入したい状況です。候補はA・B・Cの3製品で、予算上限も決まっています。
決定する問いは、『10月からサポート部門30名が利用する問い合わせ管理ツールをA・B・Cのどれにするか』です。機能を広く調べるのではなく、この利用条件で一つを選ぶことを明確にします。
役職ではなく必要な動きから担当を決める
推進役は導入を担当する業務改善メンバー、承認者は予算と運用責任を持つサポート部長とします。貢献者には、現場リーダー、情報システム担当、セキュリティ担当、経理担当を置きます。報告先は利用者、営業部、委託先です。
現場リーダーを承認者にすると予算決定ができず、部長だけで比較すると現場要件が抜けるかもしれません。ダシーでは、情報を持つ人と決定権を持つ人を同じにする必要はありません。それぞれが必要な役割を果たせる配置を選びます。
ベンダー担当者は仕様情報を提供しますが、通常は社内の意思決定役には置きません。外部から得た説明は貢献者が確認し、自社の条件へ照らして整理します。候補ごとに情報の詳しさが違う場合は、同じ質問票で追加確認すると比較しやすくなります。
評価表は点数だけで結論を自動化しない
必須条件は、社内の認証方式、データ保存条件、予算上限とします。比較条件には、担当割り当て、検索性、レポート、移行作業、操作習得の負担を置きます。各貢献者が担当する条件を調べ、根拠資料を添えます。
点数表は候補の違いを見つける道具ですが、合計点が最も高い案を自動的に採用するものではありません。重要な条件の差、点数に表れないリスク、導入期限との関係を承認者が確認し、最終判断の理由を残します。
評価者による点数差が大きい項目は、平均を取る前に認識を確認します。『操作しやすい』の基準が、初見で使えることなのか、研修後に速く処理できることなのかで評価は変わります。点数の根拠を短く書くと、差が論点として見えるようになります。
決定後は実行担当と見直し条件を別に定める
A製品に決めた後は、契約、初期設定、データ移行、研修などの実行計画へ移ります。ここではダシーの役割がそのまま作業責任になるとは限りません。必要に応じてRACIや通常のタスク表を使い、実行担当と期限を割り当てます。
決定記録には、『試用期間中に必須の連携機能が確認できない場合はB製品を再検討する』など見直し条件も書きます。前提が変わったときに、過去の決定を守ること自体が目的にならず、再判断を始める基準が明確になります。
見直し条件には確認日と担当者も必要です。『問題があれば再検討』だけでは、問題を誰が判定するか曖昧です。試用終了日の一週間前に推進役が確認し、条件に該当すれば承認者へ再判断を依頼する、と動きまで定めます。
役割表が形だけになる3つの状態を避ける
一つ目は、承認者が会議に参加せず、判断基準も示していない状態です。二つ目は、貢献者が多すぎて全員の同意を待つ状態です。三つ目は、決定しても報告先へ変更が伝わらない状態です。表を作っただけでは、これらの停滞は解消しません。
推進役は、承認者との確認時間を確保し、貢献者へ求める情報を具体化し、決定後の共有まで追跡します。ダシーの価値は役割名ではなく、判断に必要な動きを期限内に完了させることにあります。運用後に役割が過不足なく働いたか振り返りましょう。
誰が決めるかを先に合意して意思決定を止めない
ダシーは、意思決定に関わる人を推進役、承認者、貢献者、報告先の4つへ分けるフレームワークです。役職表を作るのではなく、特定の問いを期限までに決めるため、誰がどの動きを担うかを明確にします。
導入時は、決定する問い、期限、判断基準、制約条件を先に定義します。推進役が必要な情報を集め、承認者がトレードオフを引き受け、理由と条件を含めて決定します。貢献者と報告先を分けることで、会議を必要以上に大きくせず関係者を巻き込めます。
まずは、何度も持ち越されている一つの意思決定を選び、4役と決定期限を一枚に書いてみてはいかがでしょうか。表の完成度より、次に誰が何をするかが明確になることを重視すると実践しやすくなります。
今回のポイント
