1 RACIの概要
RACIは、組織の業務やプロジェクトにおいて、活動ごとの責任関係を整理するための分担モデルである。成果物に向けた作業の「実行者」と、最終的な「説明責任者」を分けて定義し、協議者や通知先もあわせて明確化することで、役割の重複や抜け漏れを抑える。
RACIは、個人の業務経験に依存する属人的な調整を減らし、ガバナンスとコミュニケーションの両面を同時に整える実務手段として利用される。特に、複数部門や外部委託が関与する場面では、判断権と連絡範囲の食い違いが起きやすいため、事前に合意可能な形で関係を可視化する価値が高い。
1.1 RACIの目的
1.1.1 役割の明確化
RACIの第一の目的は、誰が実際の作業を担い、誰が最終的な決定に責任を持つのかを明確にする点にある。担当者が変わっても責任関係が維持されるように、タスク単位で割当を行う。
また、協議や通知に関する参加範囲も定義するため、「相談されるべき人が関与していない」「知らないまま決まってしまった」といった状態を減らせる。結果として、役割期待のズレが減り、業務遂行の安定性が高まる。
1.1.2 誤解・手戻りの低減
責任の所在が曖昧だと、作業の判断基準が定まらず、手戻りが発生しやすい。RACIでは、実行の責任者と最終決定者を分けるため、誤った方向で作業が進むリスクを抑えられる。
加えて、協議先と通知先の区別により、承認以前に情報共有すべき範囲と、判断に関与する範囲が切り分けられる。これにより、関係者の理解差に起因する手修正を減らす効果が期待できる。
1.1.3 意思決定の迅速化
RACIは、意思決定の遅延を生む要因である「誰が決めるのか不明」「確認待ちが終わらない」といった状況を抑える。Accountable（説明責任者／最終決定責任者）を明示することで、判断者が不在になる事態を防ぐ。
さらに、協議先の位置付けが明確になるため、必要な論点だけを集める設計が可能になる。結果として、会話の回数や調整コストを抑えつつ、合意形成を前に進めやすくなる。
1.2 RACIの4要素
1.2.1 Responsible（実行責任者）
Responsibleは、タスクを実際に進め、成果に到達させる責任を持つ役割である。作業の当事者として、必要な調査、作成、調整を行い、規定された完了条件を満たすことが求められる。
Responsibleは複数割当があり得る。実行の分担が自然に起きる業務では、責務の範囲を狭めすぎず、作業連携が成立する数に抑えることが運用上の要点となる。
1.2.2 Accountable（説明責任者／最終決定責任者）
Accountableは、成果の是非を最終的に判断し、説明責任を負う役割である。作業の成否に対して責任を持つため、判断基準や決定内容を関係者に説明できる立場が望ましい。
Accountableは通常、タスクごとに一意であることが多い。複数にすると責任の衝突や確認待ちが増える場合があるため、例外的な運用が必要な場合でも、決定権の優先順位や代行条件を整理する。
1.2.3 Consulted（協議先）
Consultedは、意思決定や実行の質を高めるために意見を求められる役割である。専門知識や現場情報を提供し、論点の抜けを防ぐことが主な役割になる。
協議先は「賛否の決定者」ではなく、助言者として位置付けられる。関与の深さを過度にすると、決定までの時間が伸びるため、回答期待の粒度や締切をあらかじめ合意しておくことが望ましい。
1.2.4 Informed（通知先）
Informedは、決定や進捗を把握するために情報を受け取る役割である。実行に直接関与しないことが前提となり、通知のタイミングと頻度が運用設計の中心になる。
通知が遅れると再確認の往復が増え、早すぎるとノイズが増える。したがって、重要マイルストンやリスク顕在化の節目に合わせて伝達ルールを定めると、情報の有効性が高まる。
2 RACIの作成手順
2.1 対象範囲の定義
2.1.1 業務・プロセスの分解
最初に、管理対象となる業務やプロセスを分解し、タスク単位で扱える粒度に落とし込む。分解の基準は、開始・完了が明確であり、責任を割り当てても状態の変化が追跡できることが目安となる。
細かくしすぎるとマトリクスが肥大化し、運用負担が増える。逆に粗すぎると責任の空白が残り、RACIの効果が弱まる。目的に応じた粒度でバランスを取ることが重要である。
1.2.2 成果物とタスクの対応付け
分解したタスクに対して、成果物や判断ポイントを対応付ける。成果物の有無が曖昧なまま割当を行うと、完了条件が揺れ、責任の境界が再び曖昧になる。
また、承認や検収のように「何をもって完了とするか」が明確な工程は、RACIにおいて特に重要になる。判断基準を成果物側に反映させることで、Accountableの説明責任が果たしやすくなる。
2.2 役割の洗い出し
2.2.1 部門・人の割当ルール
次に、関与する部門や担当者の割当ルールを定める。個人で指定する方法と、役職やロールで指定する方法があり、運用の柔軟性と責任の明確さの両立が焦点になる。
人が頻繁に入れ替わる環境では、役職ベースで定義し、更新時に個別名を差し込む運用が向く。逆に、特定人物の判断が必要な領域では、個人指定を優先するなど、現場の実態に合わせてルールを決める。
2.2.2 権限と責任の前提整理
RACIを機能させるには、組織が持つ権限体系との整合が必要である。Accountableが担う決定の範囲、Consultedが出せる助言の影響度、Informedの情報粒度などを前提として整理する。
また、例外時の取り扱いも決めておくと、運用開始後の混乱を抑えられる。たとえば、主要担当が不在のときの代行、緊急時の判断ルールなどを明確にしておくと、責任関係が保たれる。
2.3 タスクへのRACI割当
2.3.1 Responsibleの数の考え方
Responsibleは複数割当が可能だが、増やしすぎると「誰が最終的に仕上げるのか」が再び曖昧になる。作業の分担が実務上自然に成立し、成果の統合が明確な場合に限り複数にするのが一般的である。
運用面では、Responsible同士の受け渡し点や、成果物統合の責任者（場合によってはResponsible内の主担当の位置付け）も合わせて扱うと、連携が滞りにくい。
2.3.2 Accountableの一意性の扱い
Accountableの一意性は、意思決定の停滞を避けるための重要な設計要素である。基本方針としては一人に集約し、決定の責任境界を明確にする。
ただし組織構造の事情により複数にせざるを得ない場合もある。その場合は、共同責任に留めるのではなく、決定優先順位や合議後に誰が最終判断するのかを定義して、説明責任の所在が一方向になるよう調整する。
2.3.3 ConsultedとInformedの使い分け
ConsultedとInformedは、関与の性質で切り分ける。Consultedは判断や作業品質に影響する助言を期待する相手、Informedは決定や進捗を把握するための相手である。
たとえば、専門レビューを求める相手はConsultedになりやすい。一方で、結果を受け取って対応を調整する部門はInformedに適している。境界が曖昧なときは、「意見が決定に採用される可能性があるか」を基準に整理すると判断しやすい。
2.4 RACIマトリクスの作成と確認
2.4.1 表形式での可視化
RACIはマトリクス形式で整理すると理解しやすい。行にタスク、列に役割（部門や担当）を置き、4要素の記号やラベルで割当を示す方法が一般的である。
可視化の際は、記号のルールを統一し、表の読み順を決めると運用が安定する。さらに、例外や注記が必要な箇所は別枠で整理し、表を複雑にしすぎない工夫が有効である。
2.4.2 ステークホルダーとの整合確認
作成後は、関係者と照合し、割当が実務に合っているかを確認する。この段階では、特定の担当者の希望だけを反映するのではなく、権限体系と作業の実態に照らして整合を取る。
整合確認では、主に三点を見直す。第一に、Accountableが不足していないか。第二に、Responsibleが空白になっていないか。第三に、ConsultedとInformedが必要十分かである。ズレが見つかった場合は、理由を記録し、次回更新に反映することで改善サイクルを回せる。
3 運用と改善
3.1 変更管理
3.1.1 体制変更時の更新
組織の人事異動、役職の見直し、外部委託先の入替が起きた際には、RACIマトリクスを更新する必要がある。更新が遅れると、連絡先が古くなり、判断待ちや確認コストが発生する。
更新のタイミングはイベント起点が基本である。さらに、定期点検の運用を組み込むと、体制変更の見落としが減る。変更時には、差分と影響範囲を明示し、関係者が理解しやすい形で配布する。
3.1.2 タスク追加・削除時の整備
プロジェクトでは、要件の変化によりタスクが追加されたり、不要になって削除されたりする。RACIはタスクと責任関係を紐づける仕組みのため、変更に合わせて割当も追随させる。
追加時は、ResponsibleとAccountableの起点をまず確定させ、その後に協議先と通知先を調整する手順が有効である。削除時は、関連する通知や承認プロセスへの影響を確認し、空白が残らないようにする。
3.2 コミュニケーション設計への反映
3.2.1 会議体と相談フロー
RACIは会議体の設計と連動させると効果が高い。たとえば、Consultedが意見提供を行う場を用意し、Accountableが決定するタイミングを会議体に組み込むことで、意思決定の流れが滑らかになる。
相談フローについては、「誰に先に相談するか」「どの程度の情報をもって協議するか」を規定する。これにより、会話の品質が均一になり、未整理の論点が会議に持ち込まれる割合を下げられる。
3.2.2 通知タイミングのルール化
Informedへの通知は、情報の価値が高い時点に合わせて行う必要がある。例として、計画の確定、設計変更の発生、リリース準備の完了、重大なリスクの顕在化などが通知節目になりやすい。
通知頻度を一律にすると、変化の少ない領域でノイズが増える。したがって、タスクの重要度や影響範囲に応じて通知粒度を変える設計が望ましい。ルール化は、担当者の判断を属人的にしない効果もある。
3.3 よくある失敗と対策
3.3.1 Responsibleの曖昧化
Responsibleが複数であっても、作業の最終責任がどこにあるのかが不明確だと、実行が止まる。特に「誰が統合するのか」「いつ完了とみなすのか」が定義されていないと、成果物が形にならない。
対策として、タスクの成果物に対する完了条件を明確にし、作業の統合地点や受け渡しタイミングを追記する。必要に応じて、Responsible内の主担当的役割を運用手順として補う。
3.3.2 Accountableの分散
Accountableを複数にすると、決定が合意形成に置き換わり、待ち時間が増えることがある。責任が拡散すると、最終判断の軸が揺れ、説明責任の所在も曖昧になる。
対策は、意思決定の優先順位を再定義することにある。最終判断者を1名に寄せるのが基本だが、難しい場合は「誰がいつ決めるか」を明確化し、合意後の最終押印を担う役割を特定する。
3.3.3 Consultedが増え続ける問題
協議先が際限なく増えると、意思決定の前に情報提供が集約されず、会話が広がって収束しなくなる。各部署の不安に対応する形で追加されると、Consultedの役割が実質的に承認へ近づき、遅延が起きやすい。
対策として、Consultedは「必要性があるときに協議する相手」に限定し、追加基準を定める。加えて、意見の締切と、回答が決定に反映される範囲を明示することで、協議が過剰になりにくくなる。
4 RACIの活用事例
4.1 プロジェクト管理での利用
4.1.1 要件定義フェーズ
要件定義では、現場のニーズを集めるだけでなく、優先度や成立条件を決める必要がある。Responsibleには要件作成や整理を担うチームを置き、Accountableには要件の確定判断を行う責任者を配置する運用が多い。
Consultedは関係部門の専門家として配置し、技術・業務適合の観点から論点を補完する。Informedには影響を受ける周辺部門を割り当て、確定前後で必要な準備ができるよう情報を届ける。
4.1.2 進行中の承認・意思決定
進行中は、設計変更や方針転換などの判断が断続的に発生する。RACIによりAccountableが明示されていれば、判断待ちで停滞しにくい。
協議が必要な事項に対してはConsultedを適切に設定し、必要情報が揃った段階で助言を集約する。通知はInformedに対して定期または節目で行い、手順変更に伴う準備漏れを防ぐ。
4.1.3 受入・リリース
受入とリリースは、品質基準や運用影響を含めた最終判断が中心になる。Responsibleには試験準備や手順作成を担う担当を置き、Accountableにはリリース可否を決める責任者を割り当てると、判断が明確になる。
Consultedには品質や運用の視点を持つ関係者を配置し、重大な懸念がある場合に論点を提示してもらう。Informedには影響部門や問い合わせ窓口を通知し、運用開始直後の対応に備えられるようにする。
4.2 業務運用での利用
4.2.1 定常業務の責任分担
定常業務では、処理の繰り返しが多いため、責任関係の揺れが効率を下げる。RACIでタスクごとの役割を固定化すると、誰が何を進めるかが継続的に理解される。
Responsibleには作業担当を置き、Accountableには例外や判断が必要なときの決定者を配置する。協議先と通知先を設計しておくことで、運用の標準手順が整い、属人的な調整が減る。
4.2.2 インシデント対応時の役割
インシデント対応では、初動の判断と復旧の実行が時間的制約の下で行われる。RACIが機能していれば、初期調査のResponsible、復旧方針のAccountable、専門的観点のConsulted、関係者へのInformedが整理される。
これにより、問い合わせの集中や意思決定の遅れを抑える。通知の遅延が現場の混乱を生むため、Informedへの情報提供タイミングを事前に定めることが特に重要になる。
4.3 部門間連携への適用
4.3.1 営業・開発・運用の接点整理
部門間では、情報の持ち方や判断基準が異なり、連携の摩擦が生まれやすい。RACIを用いると、受注後から運用開始までの接点で、誰が入力し誰が判断し誰が受け取るのかが可視化される。
Responsibleには実作業を担う部門、Accountableには成果判断の責任者を置く。Consultedには各部門の専門家を配置し、Informedには影響を受ける領域を通知することで、誤った前提で動く割合を減らす。
4.3.2 ベンダーを含む体制設計
外部ベンダーが関与する場合、社内と契約条件の境界が問題になりやすい。RACIでは、ベンダーが担うResponsibleの範囲と、社内のAccountableが行う決定範囲を明確にする。
Consultedにはベンダーからの技術提案を評価する専門側を置き、Informedには社内の関連部門や契約管理に関わる担当を割り当てるとよい。結果として、手続きの取り違えや説明責任の空白を抑えられる。