役割分担表は、縦に作業や決めごと、横に人や部署を並べ、交わるマスにその人の役割を書く表です。担当者の名前を1列に書くだけの表とは違い、「作業をする人」と「最終的に責任を持って決める人」、「相談を受ける人」、「結果を知らされる人」を分けて書けるため、誰も持っていない作業や、決める人が2人いる作業が表の上で見つかります。この役割の書き分けの代表的な方法が、RACI（レイシー）という書き方です。この記事では、RACI の意味、見本の表と作り方の手順、作った表の点検のしかたを示したうえで、役割分担表が形だけになる理由と直し方を説明します。
担当者を書くだけの表と RACI で書く表の違い
| 担当者を1列に書く表 | RACI で書く表 | |
|---|---|---|
| 表の形 | 作業名の横に担当者の名前 | 作業×人のマスに役割の記号 |
| 分かること | 誰が作業をするか | 誰が作業し、誰が決め、誰に相談し、誰に知らせるか |
| 見つかる問題 | 担当の空欄 | 決める人の不在・重複、相談先の多すぎ、知らせ漏れ |
| 向いている場面 | 1つの部署で完結する作業 | 部署や会社をまたぐ作業、決めごとが多い案件 |
1つの部署の中で完結する作業なら、担当者を書くだけのタスク管理表で足ります。部署の境目や社外との受け渡しがある案件では、RACI で書く表が役に立ちます。
RACI とは
RACI は、役割を4つの記号で書き分ける方法です。
| 記号 | 英語 | 役割 | 1つの行に置く数 |
|---|---|---|---|
| R | Responsible | 実際に作業をする人（実行責任者） | 1人以上 |
| A | Accountable | 結果に最終的な責任を持ち、完了を認める人（説明責任者） | 必ず1人 |
| C | Consulted | 作業の途中で意見や知識を求められる人（協業先・相談先） | 必要な人だけ |
| I | Informed | 結果や決定を知らされる人（報告先） | 必要な人だけ |
プロジェクト管理の道具を提供する Asana の解説（2026年）は、説明責任者（A）は必ず1人に限定する必要があるとしています。A が2人いる行は、2人の意見が割れたときに決まらず、A がいない行は、作業が終わっても誰も完了を認めません。同じ解説では、RACI に S（サポート）を加えた RASIC などの派生形も紹介されています。
役割分担表の見本
社内で勤怠管理の仕組みを入れ替える案件を例にした見本です。
| 作業・決めごと | 社長 | 総務部長 | 総務担当 | 情報システム担当 | 各部門長 |
|---|---|---|---|---|---|
| 目的と範囲を決める | A | R | C | C | I |
| 導入する仕組みを選ぶ | A | R | C | R | C |
| 就業規則との食い違いを確かめる | I | A | R | C | I |
| 設定の作業をする | I | C | A/R | ||
| 部門ごとの勤務の決まりを集める | A | R | C | ||
| 社員向けの説明会を開く | I | A | R | C | C |
| 本番に切り替えるかを判断する | A | R | C | C | I |
表の下に、記号の意味と「A は1行に1人」という決まりを書いておくと、初めて見る人にも読めます。
役割分担表の作り方（6つの手順）
- 作業と決めごとを書き出す：案件の作業を階層に分けた一覧（WBS）の上の段や、案件の中で決めなければならない事柄を行に並べます。作業の分け方はWBSの作り方で扱っています。部署の境目にある「渡す」「確かめる」「承認する」も、独立した行にします
- 関係者を列に並べる：人の名前で書くか、役職や部署で書くかをそろえます。案件が長く続くなら、異動で書き直さずに済むよう役職で書き、表の欄外に今の担当者の名前を添えます
- A を先に決める：各行に A を1つだけ置きます。A を決めるときは、その結果について上から問われたときに説明する人は誰か、と考えると決めやすくなります
- R を決める：実際に手を動かす人を置きます。R が複数いる行は、とりまとめの R を1人決めておくと、作業の押し付け合いが起きません
- C と I を決める：作業の途中で意見を聞く必要がある人を C、結果だけ知ればよい人を I にします。念のため全員を C にするのは避けます
- 関係者に見せて合意する：案件の立ち上げの場などで表を見せ、「この行の A は自分でよいか」を本人に確かめます。立ち上げの進め方はプロジェクト立ち上げの手順で整理しています
作った表の点検のしかた
役割分担表は、行（横）と列（縦）の両方から点検します。
行ごとに見ること
- A が0人、または2人以上の行はないか
- R がいない行はないか（誰も作業しない）
- C が多すぎる行はないか（相談の往復で作業が進まない）
- 部署の境目の受け渡しが、独立した行になっているか
列ごとに見ること
- A が特定の人に集中していないか（その人の判断待ちで全体が止まる）
- R が特定の人に集中していないか（作業の負荷が偏る）
- 空の列はないか（関わらない人を表に入れていないか）
- 役職の高い人の列が、C と I だけになっていないか（決める権限がある人を、決める行に置けているか）
責任分界点は「受け渡しの行」で決める
部署と部署、自社と取引先の境目では、「そこまでは自分の仕事だと思っていた」「そこからは相手の仕事だと思っていた」という食い違いが起きやすくなります。境目の作業を独立した行にし、渡す側と受け取る側のどちらが A なのか、受け取った側が何を確かめたら受け渡しが終わるのかを書くと、責任の境目がはっきりします。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（2026年）も、設計・開発の実施計画に、発注側と事業者だけでなく関係するすべての人について、体制や関係者間の関係、役割分担・責務を記載するよう定めています。取引先との役割は、契約書や仕様書の内容と合っているかも確かめます。
役割分担表が形だけになる理由と直し方
表の A と、実際に決めている人が違う
表では総務部長が A なのに、実際には社長が後からひっくり返す、ということが続くと、表は誰にも信用されなくなります。表を作る段階で、上位の人が本当に任せられるのかを確かめ、任せられない行はその人を A にします。決める人と決め方をそろえる考え方は、稟議の責任の所在を RACI で明確にする方法でも扱っています。
行が粗すぎる、または細かすぎる
「システム導入」1行では誰の役割も決められず、反対に作業を細かくしすぎると表が数百行になって誰も読みません。行は「決めごと」と「部署をまたぐ作業」を中心にし、1つの部署の中の細かい作業は、その部署の中で決めてもらいます。
作った後に見直さない
案件の途中で人が替わったり、作業が増えたりしても表が古いままだと、新しく加わった人の役割が分かりません。案件の節目ごとに見直す日を決め、変更した日と内容を表の欄外に残します。
実行時の落とし穴
- 全員を I にして安心する：知らせる人を増やすほど、連絡の手間が増え、本当に知るべき人への連絡が埋もれます
- A を上位の人に寄せすぎる：すべての行の A を部長や社長にすると、判断待ちが1人に集まります。任せられる行は、現場に近い人を A にします。権限の定め方はマイクロマネジメントと放置を繰り返す組織に必要な権限定義が参考になります
- 表を配って終わりにする：会議のたびに「この件の A は誰か」を表で確かめる習慣がないと、表は使われなくなります。会議の役割の決め方は会議の役割分担の記事で扱っています
意思決定に関するほかの記事は意思決定・リーダーシップからご覧いただけます。
出典
- Asana「RACI チャートとは？役割・作り方・実例をわかりやすく解説」（2026年）：https://asana.com/ja/resources/raci-chart
- デジタル庁「デジタル・ガバメント推進標準ガイドライン（DS-100）」（2026年）：https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf
