RACIチャートとは？責任分担マトリクスの作り方と活用法を解説
RACIチャートはResponsible・Accountable・Consulted・Informedの4つの役割でタスクの責任分担を明確化するツールです。作成手順、活用場面、注意点を体系的に解説します。
RACIチャートとは
RACIチャートとは、プロジェクトの各タスクに対して「誰が何の責任を持つか」を4つの役割（Responsible、Accountable、Consulted、Informed）で定義する責任分担マトリクスです。RAM（Responsibility Assignment Matrix）とも呼ばれます。
PMBOKでは、RACIチャートはリソース・マネジメントの計画プロセスにおいて、チーム・メンバーの役割と責任を文書化するツールとして位置づけられています。タスクと人の対応関係を一覧表として可視化することで、「この作業は誰がやるのか」「誰に承認をもらうのか」「誰に相談すべきか」といった疑問を解消します。
プロジェクトの規模が大きくなるほど、関係者間の役割の曖昧さが問題を引き起こします。責任の空白（誰もやらない）や責任の重複（複数人が同じことをやる）は、プロジェクトの遅延や品質低下の原因になります。RACIチャートはこの問題を構造的に防ぐための仕組みです。
構成要素
RACIチャートは「タスク（行）× メンバー・役割（列）」のマトリクス形式で、各セルにR・A・C・Iのいずれかを記入します。
| 役割 | 英語名 | 意味 |
|---|---|---|
| R | Responsible | 実行責任者。タスクを実際に遂行する人。1タスクに複数名の割り当てが可能 |
| A | Accountable | 説明責任者。タスクの最終的な成否に責任を持ち、承認権限を持つ人。1タスクに必ず1名のみ |
| C | Consulted | 相談先。タスクの実行前に意見を求められる人。双方向のコミュニケーション |
| I | Informed | 報告先。タスクの結果や進捗を通知される人。一方向のコミュニケーション |
RACIの最も重要なルールは「各タスクにAは1名のみ」です。Accountableが複数いると、最終判断の責任が曖昧になります。「誰がOKを出せばこのタスクは完了か」が一意に定まっている状態を作ることがRACIの目的です。
RACIの派生モデル
RACIの4役割に加えて、追加の役割を定義した派生モデルも存在します。
RASCI（Support追加）は、Rの補佐として作業を手伝う役割を追加したものです。大規模プロジェクトで実務担当者が多い場合に使われます。
RACI-VS（Verify、Sign off追加）は、品質検証（Verify）と最終署名（Sign off）の役割を分離したものです。規制産業や承認プロセスが厳格な組織で採用されます。
基本のRACIで対応できない場面に限り、これらの派生モデルを検討します。不必要に複雑化させると、かえって運用が困難になります。
実践的な使い方
ステップ1: タスクを洗い出す
WBS（Work Breakdown Structure）で分解したタスクやワークパッケージをRACIの行に記入します。粒度はプロジェクトの規模に応じて調整しますが、「1つのタスクに対して責任者が明確に定まる」レベルが目安です。粒度が粗すぎると責任が曖昧になり、細かすぎると管理コストが増大します。
ステップ2: 関係者をリストアップする
プロジェクトに関わるメンバー、部門、外部ベンダーなどをRACIの列に記入します。個人名ではなく役割名（PM、設計リーダー、テスト担当など）で記載することで、メンバー交代時にもRACIを継続利用できます。
ステップ3: R・A・C・Iを割り当てる
各セルにR・A・C・Iを記入します。割り当て時の確認ポイントは以下です。
- すべてのタスクにRが少なくとも1名いること
- すべてのタスクにAが1名だけいること
- CとIが適切に設定され、コミュニケーション経路が明確であること
- 1人にRが集中しすぎていないこと（過負荷のリスク）
ステップ4: 関係者と合意する
作成したRACIチャートをプロジェクトキックオフやステアリングコミッティで共有し、全関係者の合意を得ます。「自分がAだとは思わなかった」「Cに入っていないが意見を言いたい」といった認識のズレは、この段階で解消しておくことが不可欠です。
ステップ5: 定期的に見直す
プロジェクトの進行とともに、タスクの追加やメンバーの変更が発生します。フェーズの切り替わりや大きなスコープ変更のタイミングでRACIを見直し、最新の状態に保ちます。
活用場面
- プロジェクトの立ち上げ: キックオフ時に作成し、関係者全員の役割認識を統一します
- 組織横断プロジェクト: 複数部門が関わる場合に、部門間の責任範囲を明確にします
- ベンダー管理: 外部委託先との責任分界点を定義し、契約上の役割を可視化します
- 業務プロセスの標準化: 定常業務の担当と承認フローを定義し、属人化を防ぎます
- ステークホルダー管理: 誰にどの情報を共有すべきかをIの割り当てで体系的に管理します
注意点
Aを複数人にしない
「共同責任」は事実上「誰も責任を取らない」状態を生みます。Accountableは各タスクに1名のみとし、最終判断の所在を一意にします。組織の意思決定構造とRACIのA割り当ては整合させる必要があります。
Rの過集中を避ける
特定の人にRが集中している場合、その人がボトルネックになるリスクがあります。RACIを俯瞰して、各メンバーの負荷バランスを確認します。過集中を発見したら、タスクの再分配やリソースの追加を検討します。
CとIの区別を明確にする
Cは「事前に意見を求める」、Iは「事後に結果を通知する」という違いがあります。本来Iで十分な人をCに設定すると、意思決定が遅くなります。反対に、Cが必要な人をIにしてしまうと、重要な知見が反映されずに品質が低下します。
作って終わりにしない
RACIを作成してプロジェクトルームの壁に貼ったまま更新しないケースが散見されます。RACIはプロジェクトとともに進化する「生きたドキュメント」です。実態と乖離したRACIは存在しないのと同じです。
まとめ
RACIチャートは、Responsible・Accountable・Consulted・Informedの4つの役割でプロジェクトの責任分担を可視化するツールです。Aを各タスクに1名のみ割り当てるルールを守り、関係者全員で合意したうえで定期的に更新することで、責任の空白や重複を防ぎ、プロジェクトの意思決定を加速させます。
参考資料
- Who Has the D?: How Clear Decision Roles Enhance Organizational Performance - Harvard Business Review（意思決定における役割の明確化が組織パフォーマンスに与える効果を解説）
- RACI Chart: What is it & How to Use - Atlassian（RACIチャートの定義、作成手順、実務での活用方法を解説）
- The Standard for Earned Value Management - PMI（PMBOKに基づくプロジェクトマネジメント標準。責任分担マトリクスの位置づけを含む）