RACI対RASCI対DACI：責任分担マトリクスの違いを比較

RACIとRASCIの違いは、基本的なタスクリストを卒業したプロジェクトマネージャーが最もよく尋ねる質問の一つです。誤ったバリエーションを選ぶと、作業の重複や引き継ぎ漏れが起き、結局誰も意思決定の所有者が分からなくなってしまいます。

このガイドではRACI、RASCI、DACIを分解し、会議を重ねなくても数分でプロジェクトに合った正しいモデルを選べるようにします。

責任分担マトリクス（RAM）とは何ですか

責任分担マトリクス（RAM）は、プロジェクト内のすべてのタスクや意思決定を、名前の付いた役割に対応づけます。各項目について、誰が作業をするのか、誰が最終決定権を持つのかという2つの問いに答えます。これがなければ、チームは暗黙の前提に頼ることになり、スコープが拡大したり人員が変わったりした瞬間にその前提は崩れます。

最も広く使われているのはRACIマトリクスですが、大規模チームでの共同実行や、実務タスクと経営判断のより明確な切り分けといった特定のギャップに対応するため、RASCIやDACIといったバリエーションも登場しています。

重要な事実

• 役割と責任が明確に定義されている組織は、プロジェクトを期限どおりに完了できる可能性が53%高くなります（PMI、2023年Pulse of the Profession）。
• プロジェクトの失敗の25%は、所有者が不明確であることとコミュニケーション不足に起因しています（Wellingtone、2022年State of Project Management）。
• 意思決定の権限を文書化しているチームは、実行段階でのエスカレーションが20%少ないと報告しています（McKinsey Organizational Health Index、2022年）。

RACI対RASCI対DACIのひと目比較

CARSとRAPIDも知っておく価値はありますが、ここでは深く扱いません。実際に選ぶことになる可能性が最も高いのは、RACI、RASCI、DACIの3つです。

RACI

頭文字： Responsible、Accountable、Consulted、Informed

• Responsible（R）： 実際に作業を行う人。1つのタスクに複数のRが存在することもありますが、単一のRの方がすっきりします。
• Accountable（A）： 成果の責任を負う人。必ず1人だけ。Rが正しく成果を出したことを承認します。
• Consulted（C）： 作業が行われる前にインプットを提供する人。双方向のコミュニケーションです。
• Informed（I）： 事後に情報を受け取る人。一方向のコミュニケーションです。

RACIを使うべき場面： ソフトウェア展開、プロセス文書化、イベント企画など、作業がタスクベースで各成果物に対して誰かが責任を負う必要があるほとんどのプロジェクトマネジメントの場面において、これがデフォルトの選択肢です。構築方法、よくある落とし穴、無料テンプレートについてはRACIの詳細ガイドをご覧ください。

弱点： RACIは、「手伝っている」人と「所有している」人を区別しません。2人以上が実行を分担するプロジェクトでは、すべての行に複数のRが並び、すぐに分かりにくくなります。

RASCI

頭文字： Responsible、Accountable、Support、Consulted、Informed

RASCI（RASICと表記されることもあります）は、RとAの間に1つの役割を追加します。

• Support（S）： Responsibleの人を補助しますが、タスクを所有しません。依頼に応じてリソース、余力、専門的スキルを提供します。

Responsibleの人が一人でタスクを完了できないものの、複数人に対等なオーナーシップを与えたくない場合、この区別が重要になります。Support役割は、責任の所在をぼかすことなく「手伝い」を扱えます。

例： コンテンツマネージャー（R）が製品概要資料を作成します。法務レビュー担当者（S）がコンプライアンスのセクションを提供します。CMO（A）が承認します。Sの役割がなければ、法務担当者は第二のResponsible（本来持たないオーナーシップを暗示してしまう）として記載されるか、Consulted（インプットが任意であることを暗示してしまう）に格下げされるかのどちらかになってしまいます。

RASCIを使うべき場面： 一つのチームが主導しつつ他のチームも作業に貢献する、部門横断的な協力を伴うあらゆるプロジェクトです。マーケティングキャンペーン、プロダクトローンチ、年次報告サイクルでよく見られます。S役割の貢献者がどのようにブリーフィングとデブリーフィングを受けるかを明記したコミュニケーション計画と組み合わせると効果的です。

弱点： 「Support」を正確に定義していないチームは、それが第二のResponsibleへと形骸化していくのを目にすることになります。「Sは依頼された特定のタスクを行うことを意味する」と「Rは成果物の提供責任を負うことを意味する」を区別するため、15分のキックオフを行いましょう。

DACI

頭文字： Driver、Approver、Contributor、Informed

DACIはタスクではなく、意思決定のために作られたものです。

• Driver（D）： 意思決定を前に進めます。インプットを集め、スケジュールを設定し、プロセスを回します。必ず1人だけです。
• Approver（A）： 最終決定権を持ちます。1人だけです。明確な単一のApproverがいない場合は、DACIを構築する前にエスカレーションしてください。
• Contributor（C）： 意思決定が行われる前にインプットを提供します。RACIのConsultedに似ていますが、「Contributor」というラベルは受動的な専門知識ではなく能動的な参加を示します。
• Informed（I）： 意思決定が下された後に通知を受けます。

DACIを使うべき場面： プロダクトロードマップの優先順位付け、予算配分、採用の意思決定、組織再編など、成果物の完成ではなくイエス／ノーや選択肢の決定がアウトプットになるあらゆる場面です。DACIはプロジェクト憲章とうまく補完し合います。憲章でスコープと目標を定義し、そのスコープの中で誰が何を決めるかをDACIで明確にします。

弱点： DACIは実行の追跡にはあまり向いていません。意思決定が下された後は、それに続く作業を管理するためにRACIやRASCIが必要になります。

RACI、RASCI、DACIの選び方

ステップ1：タスクをマッピングしているのか、意思決定をマッピングしているのかを見極める

「アウトプットは成果物（文書、機能、レポート）なのか、それとも結論（実行可否、予算額、方針）なのか」を自問してください。

• 成果物がアウトプットの場合：RACIから始めます。複数人が実行を分担するなら、Sレイヤーを追加してRASCIを使います。
• 結論がアウトプットの場合：DACIを使います。

ほとんどのプロジェクトでは両方が必要です。プロダクトローンチでは、価格決定にはDACI、実行計画にはRACI（またはRASCI）を使うといった具合です。それぞれ別のマトリクスとして保持するか、明確にラベル付けしたタブに分けましょう。

ステップ2：行ごとのRの数を数える

まずRACIの草案を作ります。タスクリストの中で3つ以上のRを持つ行が2つ以上あれば、そのプロジェクトには共同実行の複雑さがあるということです。それがRASCIに切り替えるべきサインです。主となるRを1つに保ち、それ以外は全員Sに移しましょう。

チーム規模に応じた簡易チェックです。

それでも迷う場合は、RACIが最も安全な出発点です。マトリクスを運用し始めてパターンに気づいた時点で、いつでもS列を追加できます。

事例

ソフトウェア製品のローンチ（RASCI）

最後の行がDACIに切り替わっているのは、「ローンチの実行可否」が成果物ではなく意思決定だからです。このハイブリッドなアプローチはよく使われ、マトリクスのヘッダーでラベルが明確に説明されている限り問題なく機能します。

年次予算配分（DACI）

*これがRASCIの実行タスクであれば、財務アナリストはSになるでしょう。DACIには公式なS役割がないため、注釈を付けるか、第二のContributorとして扱うことができます。

よくある間違い

1. 1つのタスクに複数のAccountableを置く。 1行につきAは常に1人だけです。2人が承認する必要がある場合、そのうち1人はConsulted（DACIならApprover）にすべきです。Aが2人いるということは、実質的に誰も責任を負っていないということです。

2. RASCIでSupportとResponsibleを混同する。 凡例の横に一文で定義を書きましょう。「Rは成果物を所有する。Sは依頼に応じてリソースを提供する、または割り当てられたサブタスクを完了するが、成果を所有しない。」キックオフでこれを確認します。

3. RACIが必要な場面でDACIを構築する。 ステークホルダーがオーナーシップに神経質になっているプロジェクトでよく起こる間違いです。「Driver」は「Responsible」ほど重く聞こえないため、DACIの方が心理的な抵抗が少なく感じられます。しかし、意思決定ではなく作業の提供を追跡したいのであれば、DACIには抜け漏れが生じます。正しい道具を使いましょう。

4. 小規模プロジェクトでマトリクスを省略する。 3人だけのスプリントでも、軽量なRACIは役立ちます。それがなければ、「手が空いている人がやる」が事実上の割り当てモデルになり、規模が拡大するとうまく機能しなくなります。簡易なRACIをRAIDログと組み合わせ、リスクとオーナーシップを一つの視点で管理しましょう。

5. Informed列を軽視する。 Informedのステークホルダーが蚊帳の外に置かれると、終盤で驚きの原因になることがよくあります。I列のリストは常に最新に保ちましょう。ステークホルダー分析マトリクスは、誰をI列に含めるべきかを判断する直接のインプットになります。

よくある質問

RASCIはRACIより優れていますか。 一概にそうとは言えません。RASCIは、プロジェクトに複数の役割にまたがる意味のある共同実行がある場合に優れています。明確な単独オーナーがいるシンプルなプロジェクトでは、追加のS列は価値を伴わないノイズになります。RACIから始め、Rのセルが過密になるパターンが見えたときだけSを追加しましょう。

1つのプロジェクトでRACIとDACIを混在させてもよいですか。 はい、むしろそれが正解であることが多いです。意思決定（実行可否、リソース配分、スコープ変更）にはDACIを、実行タスクにはRACIまたはRASCIを使います。それぞれを別のマトリクスビューとして保持し、コミュニケーション計画の中でリンクさせておくことで、チームはどのフレームワークが何に適用されるかを把握できます。

DACIのDriverとRACIのResponsibleの違いは何ですか。 Driverは意思決定プロセスを回します。インプットを集め、スケジュールを設定し、合意形成を促進します。Responsibleは成果物を実行します。アウトプットを作り出します。Driverはものを作るのではなく、それを決める人々を調整します。Responsibleはものを作ります。

各役割には何人配置すべきですか。 A＝1行につき1人（これは譲れません）。R＝1行につき1〜2人（2人を超える場合はスコープが不明確なサインです）。SとCは必要な人数だけですが、通知疲れを避けるためInformedのリストは絞り込みましょう。D＝DACIの各行につき1人。

RAPIDやCARSはどうですか。 RAPID（Recommend、Agree、Perform、Input、Decide）は、Bainによって広められ、主に大企業の経営ガバナンスや戦略的意思決定に使われます。CARS（Communicate、Approve、Responsible、Support）は、アジャイルのプロダクトチームで時折使われる、より軽量なバリエーションです。どちらもニッチな存在です。組織がすでにどちらかを採用していない限り、RACI、RASCI、DACIでほとんどのユースケースをカバーできます。

モデルを選んで動き出す

重要な問いから始めましょう。タスクなのか、それとも意思決定なのか。タスクであればRACIがデフォルトで、共同実行が現実になったときにRASCIへとアップグレードします。意思決定であれば、誰が主導し、誰が決定し、誰が事後に知らされるのかについて、DACIが最も明確な構造を与えてくれます。

うまく作られたマトリクスがあっても対立がゼロになるわけではありませんが、「それが自分の担当だと知らなかった」という言い訳はなくなります。RACIをゼロから構築する実践的な手順については、RACIマトリクスの詳細ガイドから始めるのがおすすめです。そもそもプロジェクトのスコープに含まれるべき作業についてのみマトリクスを構築できるよう、MoSCoW優先順位付けと組み合わせて使いましょう。