RACI図の作り方｜コンサルタントが使う役割分担の整理術

RACI図とは、プロジェクトに関わる人や部署の役割を「実行責任・説明責任・相談対応・情報共有」の4区分で整理し、誰が何に責任を持つのかを一枚の表で可視化する管理ツールです。本記事では、RACI図の基本的な考え方と4区分の意味、実践的に作成する4つのステップ、システム導入プロジェクトでの具体的な記入例、運用で起きやすい失敗とその対策を解説します。あわせて、短期常駐が多い独立系PMOコンサルタントがRACI図を使って早期に信頼を得るための視点も紹介します。

RACI図とは｜4つの役割区分の基本

RACI図とは、プロジェクトの各タスクに関わる人や部署の役割を、実行責任・説明責任・相談対応・情報共有の4区分で整理した責任分担表のことです。

「責任分担表」や「役割分担表」と呼ばれることもあり、誰がタスクを実行し、誰が最終的な説明責任を負い、誰に相談し、誰に結果を共有するのかを一覧化します。表の行にタスクや成果物、列に関係者の役職や部署名を並べ、交差するマス目にそれぞれの区分を記入して作成します。

Responsible/Accountable/Consulted/Informedの意味

4区分はResponsible（実行責任）・Accountable（説明責任）・Consulted（相談対応）・Informed（情報共有）を指し、それぞれタスクへの関わり方が異なります。

RACIは責任分担マトリクス（RAM）の一種と位置づけられており、実行責任・相談対応・情報共有は複数人が兼ねても機能しますが、説明責任（A）だけは原則として1タスクにつき1人に限定します。説明責任を複数人に分散させると、誰も最終的な決定を下さない状態に陥りやすいためです。こうした責任分担の整理手法は、プロジェクトマネジメントの国際的な知識体系であるPMBOKでも、資源マネジメントの主要な技法の一つとしてRACIチャートが取り上げられています。

RACI図が必要とされるプロジェクトの特徴

RACI図が特に効果を発揮するのは、複数の部署や外部ベンダーが関わり、誰が最終的に意思決定するのかが曖昧になりやすいプロジェクトです。

とりわけ複数のベンダーや事業部門が同時並行で動くシステム導入プロジェクトでは、誰が最終判断者かが曖昧なまま進み、意思決定のたびに関係者間で確認が発生しがちです。こうした体制整理を専門に担うPMOの需要は年々高まっており、PMO市場の将来性を見るとその背景がうかがえます。

RACI図の作り方｜実践ステップ

RACI図は、「タスクの洗い出し→関係者の整理→役割の割り当て→重複や空白の確認」という4つのステップで作成します。

Step1 プロジェクトのタスク・成果物を洗い出す

最初のステップは、プロジェクトで発生するタスクと成果物を漏れなく洗い出すことです。

洗い出す粒度は、後で関係者を割り当てやすい単位にそろえます。細かすぎると表が肥大化して形骸化しやすく、粗すぎると1つのタスクに複数の役割が混在し、説明責任者が定まりにくくなります。タスクの分解には、WBS（作業分解構成図）で成果物を階層的に分解した一覧をそのまま使うと、洗い出しの粒度と網羅性を両立しやすくなります。WBSとの関係を見ると、タスク分解の具体的な進め方が分かります。

Step2 関係者・ステークホルダーを整理する

次に、プロジェクトに関わる人や部署を、実際に意思決定や作業に関与する単位で整理します。

システム導入プロジェクトであれば、プロジェクトマネージャー、PMO、発注部門の責任者、ベンダー側のプロジェクトマネージャーやシステムエンジニア、実際にシステムを使うエンドユーザー代表などが対象になります。個人名ではなく役職や役割の単位で整理しておくと、体制変更が起きてもRACI図自体を作り直さずに済みます。

Step3 タスクごとに4区分を割り当てる

洗い出したタスクと関係者を掛け合わせた表を作り、それぞれのマス目にR・A・C・Iを割り当てていきます。

割り当ての順序に迷う場合は、まず各タスクの説明責任者（A）から決めていく進め方がすすめられています。Aが先に決まれば、その人を軸に実行責任者や相談すべき相手が自然と絞り込めるためです。

Step4 A（説明責任者）の重複・空白をチェックする

表が完成したら、Aが2人以上に重複しているタスクと、誰にもAが割り当てられていないタスクがないかを必ず確認します。

Aの重複は意思決定の停滞を招き、Aの空白は誰も責任を持たないタスクとして放置されるリスクにつながります。この確認作業は表を作った本人だけで行うのではなく、関係者を集めた場で読み合わせながら進めると、認識のずれを早期に発見できます。

RACI図の具体例｜システム導入プロジェクトでの活用

ここでは要件定義フェーズを例に、RACI図を具体的にどう記入するかを示します。

要件定義フェーズでのRACI図の記入例

注記

以下は、システム導入プロジェクトの要件定義フェーズを想定した架空のサンプルです。

この例では、要件定義書の作成そのものはPMが説明責任（A）を持ちますが、最終承認だけは発注部門責任者にAを移しています。フェーズの後半になるほどAの所在が実行側から発注側に移っていく設計にしておくと、承認プロセスの実態と表の内容がずれにくくなります。

RACI図を関係者合意のツールとして使うコツ

RACI図は作成して終わりではなく、キックオフや要件確定の場で関係者全員に読み合わせ、合意を得るところまでが1セットです。

読み合わせの場で「この役割分担には納得できない」といった異論が出ることもありますが、その場でRACI図自体を書き換えるのではなく、論点をいったん切り分けて記録しておくと、本来の役割分担の議論から逸れずに済みます。合意形成の過程で浮かんだ懸念や宿題は、課題管理表と合わせて使うと、RACI図を議論の場に保ったまま個別の論点を後日決着させられます。

RACI図運用でよくある失敗と対策

RACI図の運用で特に頻発するのは、説明責任（A）の重複による意思決定の停滞と、作成後に更新されず形骸化する問題です。

Aが複数人に重複し意思決定が滞るケース

最も多い失敗は、1つのタスクに説明責任（A）を持つ人が複数人存在し、誰も最終判断を下さないまま議論が長引くケースです。

複数人に説明責任が分散すると、誰も最終決断をしない状態に陥りやすいとされます。対策としては、タスクの粒度が大きすぎてAを一本化できない場合、タスク自体をさらに分割し、それぞれに1人ずつAを割り当て直す方法が有効です。

作成後に更新されず形骸化するケース

もう一つの失敗は、プロジェクト開始時に作成したRACI図が更新されず、体制変更後の実態と乖離していくケースです。

フェーズの切り替わりや担当者の異動があったタイミングで見直しのルールを決めておかないと、RACI図は初回作成時の状態のまま放置されがちです。更新を仕組みとして回すには、単体のExcelやスプレッドシートで管理するだけでなく、変更履歴が残るプロジェクト管理ツールと組み合わせる方法もあります。管理ツールを比較すると、案件規模に合った運用方法を検討しやすくなります。

RACI図を独立コンサルの立ち回りに活かす視点

独立系のPMO・ITコンサルタントにとって、RACI図は短期常駐の現場でも早期に信頼を得るための実務的な手段になります。

短期常駐でも早期に信頼を得るための使い方

コンサルタントの歩み編集部が複数の独立系PMOコンサルタントに取材したところ、参画から早い段階で自分からRACI図のたたき台を作成し、関係者に確認を仰ぐという動き方が共通して挙がりました。

常駐先の体制は、口頭の申し送りだけで役割が曖昧なまま運用されているケースが少なくありません。参画者自身がたたき台を作って持ち込むことで、既存メンバーとの役割の重なりや漏れが早期に表面化し、「何をする人か」を自分の言葉で説明する材料にもなります。

RACI図のような責任分担マトリクスは、プロジェクトマネジメントの知識体系であるPMBOKの中で紹介される代表的な様式の一つです。フリーランスのPM・PMOが取得を検討する資格の中では、知名度や案件要件への通りやすさの面でPMP（Project Management Professional）が第一候補に挙がりやすいとされており、RACI図を実務でどう運用したかを語れることは、こうした資格や実務経験を裏づける具体的なエピソードにもなります。

短期常駐先での信頼獲得は、次の案件へのつながりにも直結します。PMO案件の獲得方法を見ると、案件獲得における実務的な進め方が確認できます。

まとめ

RACI図は、プロジェクトの各タスクについて実行責任・説明責任・相談対応・情報共有の4区分で役割を整理し、責任の所在を一枚の表で可視化する管理ツールです。作成は「タスクの洗い出し→関係者の整理→役割の割り当て→重複や空白の確認」の4ステップで進め、特に説明責任（A）は原則1人に絞ることが、意思決定の停滞を防ぐ最大のポイントになります。

• 4区分（R・A・C・I）の意味を理解し、Aは原則1人に絞ること
• タスクの洗い出しにはWBSなど成果物ベースの一覧を活用すること
• 作成後は関係者全員で読み合わせ、合意を得るところまでを1セットにすること
• 体制変更のタイミングで見直しのルールを決め、形骸化を防ぐこと

実際の運用方法は、プロジェクトの契約形態や体制規模によって最適な粒度が異なります。判断に迷う場合は、PMOの実務経験者やプロジェクトマネジメントの専門家に相談しながら、自分のプロジェクトに合った形に調整することをおすすめします。

出典・参考情報

1. Promapedia（プロマペディア・SSAITS運営）「RACIチャートとは何か？責任と役割の整理の仕方を解説」（2026-08-30参照・最終更新日2025-08-14）
2. オーシャンコンサルティング「プロジェクト失敗の5つの原因と対策｜PMO視点で構造的に解説」（2026-08-30参照）
3. マーキャリメディア「RACIチャートを使ってプロジェクトの役割分担と責任の所在を明確にしよう」（2026-08-30参照）
4. Institute of Project Management「What Is a RACI Matrix? Responsibility Assignment Matrix Explained」（2026-08-30参照）
5. PMI日本支部（PMP認定資格・PMBOKに関する参考情報。2026-08-30参照）

本記事は2026年8月時点の情報に基づき、コンサルタントの歩み編集部が独立系PMOコンサルタントへの取材を交えて作成しています。プロジェクトの体制や契約形態によって最適な運用方法は異なるため、詳細はプロジェクトマネジメントの専門家にご確認ください。（最終更新日：2026年8月30日）