RACI チャートの作り方｜役割分担を明確化する5ステップと責任分担表テンプレート

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

「これ、誰がやるんでしたっけ？」——プロジェクトの現場で最も多く交わされ、最も多くの手戻りを生む一言です。タスクの担当が曖昧なまま進むと、全員が「他の誰かがやっている」と思い込んで誰もやらない、あるいは逆に複数人が同じ作業をして衝突する。この「役割の空白と重複」を1枚の表で解消するのが RACI チャート（責任分担表） です。

結論から言えば、RACI チャートとは「タスク × 関係者」のマトリクスの交点に、R（実行）・A（説明責任）・C（相談）・I（報告） の4記号を割り当て、“誰が何にどう関わるか”を一目で分かるようにする道具です。作り方はシンプルで、①タスクを洗い出す → ②関係者を並べる → ③各交点に R/A/C/I を割り当てる → ④縦横のルールで検証する → ⑤全員で合意して共有する の5ステップ。この記事では、各ステップと記入例、そして最も重要な「Accountable は1タスク1人」という鉄則まで、初めて役割分担表を作る方が今日から使えるように解説します。

なぜ RACI が効くのか。理由は、プロジェクトの混乱の多くが「作業の難しさ」ではなく「責任の所在の曖昧さ」から生まれるからです。担当を口頭やメールで都度決めていると、認識がずれ、抜けが生まれ、最後は「言った・言わない」になります。RACI は、その暗黙の役割分担を明文化して見える化することで、着手前に空白と重複を潰します。

そもそも RACI チャートとは？4つの役割の定義

RACI チャートは 責任分担マトリクス（RAM: Responsibility Assignment Matrix） の代表的な一形式で、各タスクに対する関係者の関わり方を4種類の記号で表します。名前は4つの役割の頭文字に由来します。

記号	役割（日本語）	意味	人数の目安
R	Responsible（実行責任者）	実際に手を動かして作業を行う人	1人以上（複数可）
A	Accountable（説明責任者）	成果物を承認し、最終的な責任を負う人	必ず1人
C	Consulted（相談先）	作業前・作業中に意見や専門知識を求める相手。双方向のやり取りが発生	0人以上
I	Informed（報告先）	進捗や完了を一方的に共有される相手。やり取りは一方向	0人以上

この4つのうち、初学者が最もつまずくのが R と A の違い です。

C と I の違いも押さえておきましょう。C（相談）は双方向——こちらから意見を求め、相手も返してくる関係です。I（報告）は一方向——決まったことや進捗を知らせるだけで、相手の合意は必要ありません。「レビューして意見をもらう部門」は C、「決まった結果だけ共有すればいい部門」は I、と切り分けます。

RACI チャートの作り方【5ステップ】

ステップ1｜タスクを洗い出して縦軸に並べる

まず、プロジェクトを構成するタスクをすべて洗い出し、表の左端（縦軸）に作業順で並べます。ここで重要なのは粒度です。細かすぎると表が巨大になり運用できず、粗すぎると役割が曖昧なまま。「1タスク＝1つの成果物または明確な作業単位」を目安にします。

すでに WBS（作業分解構成図） を作っている場合は、そのワークパッケージをそのまま RACI の縦軸に転記するのが最短です。WBS が「何をやるか（What）」を決め、RACI が「誰がやるか（Who）」を決める——この2つはセットで機能します。

ステップ2｜関係者・役割を洗い出して横軸に並べる

次に、プロジェクトに関わる人・役割を表の上端（横軸）に並べます。ここでは個人名ではなく「役割（ロール）」で並べるのが定石です。人事異動や増員があっても表を作り直さずに済むからです。プロジェクトマネージャー・開発リーダー・担当エンジニア・品質管理・発注元担当・スポンサーなど、ステークホルダーを漏れなく拾います。

ステップ3｜各交点に R / A / C / I を割り当てる

タスク（縦）と役割（横）の交点に、その役割がそのタスクにどう関わるかを R/A/C/I で記入します。下は Web システム導入プロジェクトの記入例です。

タスク ＼ 役割	PM	開発リーダー	エンジニア	品質管理	発注元
要件定義	A	C	R	I	C
基本設計	I	A	R	C	I
実装	I	A	R	I	—
テスト	I	C	R	A	I
受入・リリース	A	R	R	C	C

各行（タスク）を横に見ると、必ず R が1つ以上、A がちょうど1つあることを確認してください。これが RACI の背骨です。

ステップ4｜縦横のルールで検証する

割り当てが終わったら、行（横方向）と列（縦方向）の両方から見直して整合性をチェックします。ここを飛ばすと、せっかくの表が「作っただけ」になります。

行（タスク）ごとのチェック：

• A がちょうど1つあるか：0個なら責任者不在、2個以上なら責任の押し付け合いの原因
• R が1つ以上あるか：R がなければ「誰も手を動かさない」タスク
• C・I が多すぎないか：相談・報告先が多すぎると調整コストで動きが鈍る

列（役割）ごとのチェック：

• A が特定の1人に集中していないか：ボトルネックとバーンアウトの兆候
• R だらけの人がいないか：作業過多。負荷分散を検討する
• C・I しか付いていない役割：本当に関与が必要か、逆に外せないかを再考

ステップ5｜全員で合意し、共有・更新する

完成した RACI を関係者全員でレビューし、「自分の役割はこれで合っているか」を本人に確認します。ここで初めて「え、それ私がやるんですか？」という認識ずれが表面化します。着手前にこのズレを潰すことが、RACI 最大の効果です。合意後は誰もがアクセスできる場所（共有ドライブ・ステータスレポートの付録など）に置き、フェーズの節目ごとに見直します。

RACI チャートのメリット・デメリット

RACI の派生モデル｜RASCI・DACI との違い

RACI は基本形で、現場のニーズに応じた派生形があります。自チームに合うものを選びましょう。

モデル	追加・変更される役割	使いどころ
RACI	基本の4役割	汎用。まずはここから
RASCI（RASIC）	S=Support（実行を手伝う支援者）を追加	R を補助する人が多い大規模作業
RACI-VS	V=Verify（検証）・S=Sign-off（最終承認）を追加	品質検証と承認を明確に分けたい開発現場
DACI	D=Driver・A=Approver・C=Contributor・I=Informed	意思決定そのものにフォーカスしたいとき
CARS	Communicate・Approve・Responsible・Support	よりシンプルに整理したいとき

まずは基本の RACI で運用を始め、「支援者の存在を明示したい」「承認と検証を分けたい」といった具体的な不足を感じてから派生形に広げるのが実務的です。最初から複雑なモデルを選ぶと、運用が続きません。

RACI チャートでよくある失敗5選

1. A（説明責任者）を複数人にする：最頻出かつ最悪の失敗。責任者が2人いると「相手がやると思った」で全員が動かない。A は必ず1タスク1人。
2. R が付いていないタスクがある：承認者（A）だけ決めて実行者（R）を決め忘れる。手を動かす人がいなければタスクは進みません。
3. C と I を混同する：本当は合意が必要な相手（C）を「報告だけ（I）」にしてしまい、後から「聞いてない」と紛糾する。双方向か一方向かで切り分ける。
4. 粒度がバラバラ：「要件定義」と「ボタンの色を決める」が同じ行に並ぶと表が機能しない。タスクの粒度を揃える。
5. 作りっぱなしで更新しない：体制変更後も古い RACI が残り、誰も見なくなる。フェーズの節目で必ず見直す。

よくある質問（FAQ）

Q. RACI チャートは何で作ればいいですか？ A. 小〜中規模なら Excel／スプレッドシートで十分です。縦にタスク、横に役割を並べ、交点に R/A/C/I を入力するだけです。タスク管理ツール（Backlog・Jira・Asana 等）と連携させたい場合は、各ツールの担当者フィールドやカスタム項目で代替できます。

Q. Responsible と Accountable が同じ人になってもいいですか？ A. 問題ありません。小規模プロジェクトでは、実際に作業する人（R）が承認まで行う人（A）を兼ねるケースは珍しくありません。その場合は交点に「R/A」と併記します。ただし A は兼務者を含めてもタスクごとに1人である点は変わりません。

Q. RACI と WBS はどちらを先に作りますか？ A. WBS が先です。WBS でタスク（What）を洗い出してから、その各ワークパッケージを RACI の縦軸に転記し、担当（Who）を割り当てる流れが自然です。詳しくは WBS の作り方 を参照してください。

Q. 1人に A（承認）が集中してしまいます。問題ですか？ A. 要注意のサインです。承認がすべて1人に集まると、その人が休むだけでプロジェクトが止まります。承認権限を一部委譲する、タスクによって A を分散するなど、ボトルネック解消を検討しましょう。

まとめ｜RACI は「着手前に空白と重複を潰す」道具

RACI チャートの作り方は、次の5ステップに集約されます。

1. タスクを洗い出す：WBS のワークパッケージを縦軸に、粒度を揃えて並べる
2. 関係者を並べる：役割（ロール）ベースで横軸に並べる
3. R/A/C/I を割り当てる：各交点に、その役割の関わり方を記号で記入する
4. 縦横で検証する：各タスクに R が1つ以上・A がちょうど1人、特定の人に負荷が偏っていないかを確認
5. 合意し共有・更新する：本人確認で認識ずれを潰し、節目ごとに見直す

RACI の本質は、プロジェクトが動き出す前に「誰も担当しないタスク」と「担当が重複するタスク」を機械的に炙り出すことにあります。そして最大の勘所は、Accountable（説明責任者）を1タスク1人に絞ること。まずは今日、直近フェーズのタスクを5〜10個ピックアップし、上の記入例のように小さな RACI を1枚作ってみてください。「これ誰がやるんでしたっけ？」が会議から消えていくはずです。

役割分担の前提となる関係者の洗い出しは「ステークホルダーマネジメント完全ガイド」で、タスクそのものの分解は「WBS の作り方」で詳しく解説しています。あわせてどうぞ。