監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
RACI図とは、プロジェクトのタスクや成果物ごとに、関係者の役割を四つの区分で表した分担表です。四つは実行担当（Responsible）、最終責任（Accountable）、相談先（Consulted）、報告先（Informed）を指します。縦軸にタスク、横軸に人や部署を並べ、交点に区分を記入して、誰が何に対してどう関わるかを一枚で見渡せるようにします。PMが責任の抜け漏れや重複を防ぐために使う道具です。
RACI図の狙いは、タスクに対する役割を言葉にして固定することです。会話の中で「それはそちらでお願いします」と曖昧に決まった分担は、後から解釈がずれやすくなります。RACI図は、その曖昧さを表の形に落として、関係者が同じ理解に立てるようにします。
縦に要件定義、基本設計、結合テストといった工程や具体的なタスクを並べ、横に登場人物を並べます。交点にRACIのいずれかを書き込むと、一人の列を縦に見れば担当範囲が、一つのタスクの行を横に見れば関与者の全体像がわかります。
作成はタスクの洗い出しから始めます。WBSやプロジェクト計画書からタスクを抜き出し、粒度をそろえて縦軸に並べます。粒度が粗すぎると役割が一人に集中して意味が薄れ、細かすぎると表が大きくなりすぎて使われなくなります。工程や成果物の単位を目安にするとまとまりやすいです。
次に横軸の登場人物を決めます。個人名だけでなく、役割名や部署名を使うと、担当者が交代しても表が生き続けます。ステークホルダーの一覧を作ってから横軸に置くと、関わるべき人の抜けに気づきやすくなります。
軸がそろったら、タスクごとにAccountableを先に決めるのが進めやすい順番です。最終責任を一人に定めてから、その周囲に実行担当や相談先を配置すると、責任の中心がぶれません。割り当ては机上で完結させず、各人に当事者として確認してもらう段階を挟みます。想定していた相手が実は別の役割だと考えていた、という食い違いは、この確認で表に出ます。合意できたらキックオフやステコミの資料に載せ、変更があれば変更管理の流れに沿って更新します。
RACI図は作ること自体が目的になりやすい道具です。きれいな表を一度作っても、プロジェクトが進むと担当が変わり、表と実態がずれていきます。更新されない表は、かえって誤解のもとになります。
いずれも、表の形式より運用の問題です。誰が更新を担うかをあらかじめ決めておくと、形骸化を防ぎやすくなります。
RACIにまつわる言葉は、指しているものがほぼ重なっているため、文脈で読み替える必要があります。軸を「呼び方の違い」と「拡張の有無」に分けると整理しやすくなります。
PMBOKでも責任分担の表現としてRACIが触れられており、プロジェクトマネジメントの基礎的な道具として位置づけられています。呼び名に迷ったら、関係者が同じ理解を共有できているかを優先して確認します。
RACI図を使いこなせることは、PMが関係者を整理して動かせる、という実務の証しになります。役割の抜け漏れや重複に気づき、最終責任を一人に定めて合意を取り付ける動きは、規模の大きいプロジェクトほど効いてきます。職務経歴書や面接で分担管理の経験を語るとき、RACIをどう運用し、形骸化をどう防いだかまで具体的に話せると、進め方への理解が伝わりやすくなります。表を作る技術そのものより、関係者と合意を作り、変化に合わせて更新し続けた経験が、ステークホルダー管理の力として評価されやすい部分です。日々のプロジェクトで小さくでも運用してみることが、説明できる経験の積み上げにつながります。
RACI図とRACIマトリックスは違うものですか。
ほぼ同じものを指します。RACIの役割分担を表にしたものを、RACI図、RACIマトリックス、RACIチャートなどと呼び分けているだけで、中身は共通です。資料や組織ごとに呼称が異なるため、文脈に合わせて読み替えれば問題ありません。
一つのタスクにAccountableを複数置いてもよいですか。
基本は一人に絞ることが勧められます。最終責任が複数いると、判断が必要な場面で互いに相手を待ち、意思決定が止まりやすくなるためです。どうしても複数部署が関わる場合は、タスク自体を分割して、それぞれに責任者を一人ずつ置く方法があります。
RACI図はいつ作ればよいですか。
体制がおおよそ固まる計画段階、キックオフの前後が一つの目安です。作って終わりにせず、工程の節目や体制変更のタイミングで見直すと、表と実態のずれを抑えられます。更新を担う人をあらかじめ決めておくと運用が続きやすくなります。