RACIマトリックス

RACIという名前は、4つの役割の頭文字から来ています。この4つを一つの作業に対して正しく割り当てることが、この表の核心です。

• R（Responsible・実行者）
  実際に手を動かして作業を完遂する担当者です。設計書を書く、テストを実施する、といった具体的な作業の担い手を指します。一つの作業に複数人のRがいても構いません。
• A（Accountable・説明責任者）
  その作業の成否について最終的に説明責任を負う人です。成果物を承認し、関係者に対して「この作業は完了した」と言い切る立場で、原則として一つの作業につき一人に絞ります。ここが複数いると、誰が決めるのか曖昧になります。
• C（Consulted・相談先）
  作業を進めるうえで意見を求める相手です。双方向のやり取りが前提で、要件定義なら業務部門、設計なら有識者のエンジニアなどが当たります。
• I（Informed・報告先）
  結果を知らせておく相手です。意思決定には加わりませんが、進捗や完了を共有しておく必要がある関係者で、上位のステークホルダーや周辺チームが入ることが多いです。

CとIの違いは、意見を聞いて反映するか、結果を伝えるだけかという点にあります。この線引きが曖昧だと、本来は相談すべき相手に事後報告だけで済ませてしまい、手戻りの火種になります。

RACIマトリックスは、軸を「作業項目」と「関係者」に固定してから埋めていきます。思いつきで記号を振るのではなく、順番を踏むと破綻しにくくなります。

• 縦軸に作業項目を並べる
  WBSやプロジェクト計画書から、主要な作業やマイルストーンを行として書き出します。粒度が細かすぎると表が巨大になるため、承認や引き継ぎが発生する単位でまとめるのが扱いやすいです。
• 横軸に関係者を並べる
  個人名ではなく役割やチーム名（PM、開発リーダー、業務部門、ベンダー担当など）を列に置くと、担当者交代があっても表が生き続けます。
• 各セルにR・A・C・Iを入れる
  行ごとに、まずAを一人決めてから、R・C・Iを割り当てていきます。Aを先に決めると、責任の中心がぶれにくくなります。

完成した表は、キックオフや計画段階で関係者に共有し、合意を取る成果物になります。ステークホルダーが「自分はこの作業ではCのはずだ」と指摘できる状態にしておくことで、認識のずれをプロジェクトの早い段階で潰せます。更新を前提に、変更管理の対象として扱うのが現実的です。

RACIマトリックスは作ること自体は難しくありませんが、実運用に乗せる段階で崩れることがあります。典型的なつまずき方を知っておくと予防しやすくなります。

• Aが複数ついてしまう
  説明責任者を一人に絞れず、各部門が「うちもA」と主張する状態です。いざ問題が起きたときに誰が判断するのかが決まらず、意思決定が止まります。行ごとにAは一つ、を徹底する必要があります。
• AもRも不在の行がある
  横一列を見たときに実行者も説明責任者もいない作業が残っていると、その作業は宙に浮きます。全行にAとRが最低一つずつあるかを確認するのが基本的な点検です。
• 記号を振っただけで共有されない
  PMの手元で表は完成しているのに、当の関係者が自分の役割を知らないケースです。表は合意形成の道具なので、読み合わせて初めて機能します。
• 一度作って放置する
  体制変更や作業の追加があっても更新されず、実態と食い違ったまま形骸化します。節目ごとに見直す運用とセットにしておくことが欠かせません。

RACIマトリックスは責任分担の整理手法のひとつで、似た役割を持つ道具と組み合わせて使われます。軸を「何を整理するものか」に置いて比べると、役割分担が見えてきます。

• WBSとの関係
  WBSは作業を分解して構造化するもので、RACIはその作業に人を割り当てるものです。WBSで洗い出した作業項目を、そのままRACIの縦軸に持ち込むと整合が取りやすくなります。
• ステークホルダー整理との関係
  ステークホルダー分析は関係者の影響度や関心を把握するものです。RACIはそこで洗い出した関係者を、具体的な作業ごとの役割に落とし込む段階で使えます。
• 派生形の存在
  RACIにS（支援者）を加えたRASCIや、承認者を分けた拡張版もあります。現場によって必要な役割が異なるため、記号を無理に増やさず、関係者が迷わない範囲に収めるのが扱いやすい形です。

いずれの道具とも、目的は責任の所在を透明にすることにあります。RACI単体で完結させようとせず、計画書やWBSと紐づけて運用すると、表が実態から離れにくくなります。

RACIマトリックスを使いこなせることは、PMが責任分担を設計する力を持っている証しになります。作業を洗い出し、関係者を役割に割り当て、合意を取るという一連の流れは、規模の大きいプロジェクトや複数ベンダーが絡む体制ほど効いてきます。面接や職務経歴の場面でも、どの作業の説明責任を自分が引き受け、どう役割分担を整理してきたかを具体的に語れると、進行管理の実務経験が伝わりやすくなります。単に表を作れるだけでなく、Aを一人に絞る調整や、形骸化させずに更新し続ける運用までを語れると、体制設計を任せられるPMとして評価されやすい領域です。

RACIのAとRは何が違うのですか。

Rは実際に作業を進める実行者で、Aはその作業の成否について最終的な説明責任を負う人です。手を動かすのがR、承認して結果を引き受けるのがAと分けて考えます。RとAが同一人物になる場合もありますが、Aは原則として一つの作業に一人に絞ります。

Aは一つの作業に必ず一人にすべきですか。

原則として一人に絞ることが推奨されます。説明責任者が複数いると、問題発生時に誰が判断するのかが曖昧になり、意思決定が滞りやすくなります。関係者が多い場合は、一人をAに据えたうえで、意見が必要な相手をCとして割り当てると整理しやすくなります。

RACIマトリックスはいつ作ればよいですか。

プロジェクトの計画段階やキックオフの前後に作成し、関係者と読み合わせて合意を取るのが一般的です。体制変更や作業の追加があれば随時更新し、節目ごとに見直す運用にしておくと、表が実態と食い違って形骸化するのを防ぎやすくなります。