RACI フレームワーク
各タスクに実行担当・最終責任・相談先・報告先の4役割を割り当て、責任の空白と重複をなくす分担整理の枠組み。
タスク×担当者の表に、実行R・最終責任A・相談先C・報告先Iを置く。Aは1タスクにつき必ず1人だけ。
Aがゼロなら決裁者不在、複数なら押し付け合い。Rは複数可。縦（1タスク）と横（1人）の両方向で、Aの集中やCの過多、空白タスクを点検する。図は例。
用途
戦略を実行に移すアクションプラン工程では、「誰が何をやるのか」が曖昧なままだとタスクが宙に浮き、決裁が滞り、後になって「聞いていない」という手戻りが噴出する。 RACIは、タスク×担当者のマトリクスを作り、各セルに4つの役割記号を置くことで、この曖昧さを構造的に潰すために使う。 目的は3つに整理できる。 第一に、各タスクの「最終責任者(A)を必ず1人に絞る」ことで、決められない・止まる状態を防ぐ。 第二に、実行担当(R)・相談先(C)・報告先(I)を明示し、巻き込むべき人と巻き込みすぎている人を可視化する。 第三に、会議・承認・情報共有の負荷を事前に見える化し、特定の人にAが集中する過負荷や、逆にどの役割も割り当たっていない放置タスクを設計段階で発見する。 担当を「決めた気になる」段階から、実務で回る精度まで落とし込むための道具である。
使い方
- アクションプラン工程で洗い出したタスク（WBSの末端やマイルストーンにひもづく作業）を縦軸に、関与しうる人・役職・部署を横軸に置いたマトリクスを作る。 粒度は「誰かが着手できる」単位まで割ること。
- 各タスク行について4役割を割り当てる。 R(Responsible=手を動かす実行担当)、A(Accountable=可否を最終判断し結果に責任を負う承認者)、C(Consulted=着手前に意見を聞く双方向の相談先)、I(Informed=完了後に結果を伝える一方向の報告先)。
- 「1タスクにつきAは必ず1人だけ」を最優先で点検する。 Aがゼロなら決裁者不在、Aが複数なら責任の押し付け合いが起きる。 Rは複数可、CとIも複数可。
- 縦（1タスク内）と横（1人あたり）の両方向で偏りを点検する。 Aが特定個人に集中していないか、Cが多すぎて意思決定が重くなっていないか、どの役割もない空白タスクや逆に全員Iの形骸化がないかを確認する。
- 関係者全員でレビューして合意を取り、プロジェクト計画に添付する。 体制やスコープが変わったタイミング（担当の異動、フェーズ移行）で必ず更新し、実態と乖離した表を放置しない。
適用例
従業員45名のBtoB向けSaaS（勤怠管理システム、月額サブスク）を提供する企業が、解約率低下を狙う「オンボーディング改善プロジェクト」のアクションプランをRACIで整理した例。 四半期の解約率3.2%を2.0%へ下げる目標に対し、主要4タスクを分担した。 ①「新規契約企業への初期設定支援フロー設計」はR=カスタマーサクセス(CS)担当2名、A=CSマネージャー、C=開発リード（設定機能の制約確認）、I=営業部長。 ②「管理者向け操作ガイド動画5本の制作」はR=CS担当1名＋外注デザイナー、A=CSマネージャー、C=プロダクトマネージャー、I=CEO。 ③「利用状況ダッシュボードのアラート機能開発」はR=エンジニア2名、A=開発リード、C=CSマネージャー、I=CSチーム全員。 ④「導入後30日面談の実施ルール策定」はR=CS担当2名、A=CSマネージャー、C=営業、I=経営会議。 作成過程で、当初は4タスクすべてのAがCSマネージャー1人に集中し週あたり承認8件・面談同席6件の過負荷が判明したため、③のAを開発リードへ移譲。 結果、承認の滞留（平均リードタイム4日→1.5日）が解消し、プロジェクトは予定どおり進行、翌四半期の解約率は2.4%まで低下した。
よくある誤解・つまずき
- 「RとAは同じ人でよい」という誤解。 実行担当(R)が自分の成果物を自分で承認(A)する形は、品質チェックが機能せず身内評価になりやすい。 小規模組織では兼任もあり得るが、その場合も『Aは判断・責任、Rは実行』という役割の違いを意識し、承認だけは別の視点を通すのが望ましい。
- 「CもIも“関係者に伝える”ことだから同じ」という混同。 Cは着手前に意見を求める双方向の相談で、その人の反対や指摘が計画を変え得る。 Iは完了後に結果を知らせる一方向の通知で、内容を左右しない。 ここを取り違えると、本来相談すべき人をIに置いて後から『聞いていない』ともめる、または通知で済む人をCに置いて意思決定を無用に重くする。
- 「表を作れば運用まで回る」という思い込み。 RACIは合意形成と更新の運用があって初めて効く。 作って共有しただけで実態と乖離したまま放置すると、飾りの資料になり、現場は結局『いつもの人』に聞いて動く形に戻る。
使うタイミング
戦略を実行タスクへ分解し終えたアクションプラン工程、特に複数の部署・役割が絡むプロジェクトで、担当と承認の曖昧さが実行のボトルネックになると見込まれるときに使う。 早すぎる失敗は、ビジョンや戦略方針がまだ固まっていない段階で作ってしまうケースで、目的が動くたびにタスクごと崩れ、手戻りになる。 遅すぎる失敗は、プロジェクトが走り出し混乱が起きてから慌てて作るケースで、既に決まった非公式な分担を追認するだけの後付け資料になりやすい。 逆に、担当が1〜2名で完結する小規模タスクや、役割が自明な定型業務に持ち込むと、マトリクス作成の手間だけがかさんで割に合わない。 関係者が多くタスク間の依存が複雑なときほど価値が出る。