RACIチャートとは？読み方と作り方｜記入例と顧客との役割分担の書き方
RACI（レイシー）とは、作業や決定ごとに、実行する人（Responsible）、最終的に責任を持つ人（Accountable）、相談を受ける人（Consulted）、報告を受ける人（Informed）の4つの役割を割り当てる考え方である。これを行と列の表にしたものをRACIチャート、RACIマトリクス、責任分担表と呼ぶ。
「誰かがやると思っていた」「それは聞いていない」「担当者はOKと言ったのに、後から部長に差し戻された」。プロジェクトで起きるこうした行き違いの多くは、作業の難しさではなく、誰が何を担うのかがあいまいなことから生まれます。RACIチャートは、それを1枚の表で先に決めておく道具です。
RACIの解説の多くは、社内のチームを前提にしています。けれども受託や制作の仕事では、承認する人が顧客側にいて、範囲や費用の変更のように顧客と自社の両方に決める人がいる場面が普通にあります。この記事では、基本と作り方に加えて、そうした顧客と進める案件での書き方を、記入例つきで説明します。
この記事のポイント（TL;DR）
- RACIは、R（実行する人）、A（最終的に責任を持つ人）、C（相談を受ける人）、I（報告を受ける人）の頭文字です。読み方は「レイシー」です。
- 最も大事な決まりは、1つの行にAは1人だけ、ということです。PMI（米国のプロジェクトマネジメント協会）も、これをRACIの中心の決まりとしています。
- 作り方は、行を書き出す → 列に役割を並べる → Aを先に決める → R・C・Iを埋める → 関係者と合意する、の5段階です。
- 行は細かくしすぎず、担当や決める人が変わるところで分けます。すべての作業を載せる必要はありません。
- 顧客と自社の両方の承認が要る決定は、Aを2つ書かずに行を2つに分けます。「自社が案を固める行」と「顧客が受け入れる行」にすれば、どの行もAは1人のままです。
- 顧客のAは、仕様の確定や成果物の受け入れに置きます。作業のやり方や割り振りの行に顧客のAを置くと、偽装請負と判断されるおそれのある形に近づきます。
どこから読むか
| 当てはまる状況 | 先に読むところ |
|---|---|
| RACIの意味と読み方を知りたい | RACIとは｜読み方と4つの役割 |
| すぐに表と記入例がほしい | RACIチャートのテンプレートと記入例 |
| 手順に沿って作りたい | RACIチャートの作り方（5つの手順） |
| 顧客と自社の役割分担を書きたい | 顧客と進める案件でのRACIの書き方 |
| 作ったのに機能していない | RACIチャートがうまくいかない形と直し方 |
| RASICとの違いを知りたい | RASIC・DACIなど似た型との違い |
RACIとは｜読み方と4つの役割
RACIとは、1つの作業や決定に関わる人を、4つの役割に分けて書く考え方です。読み方は「レイシー」で、「ラシ」ではありません（通訳翻訳ジャーナル「RACI／読み方は『ラシ』ではありません」）。
PMIの解説は、RACIを、作業や決定に4つの役割を割り当てる表と説明しています。それぞれの役割の意味は次のとおりです（PMI Blog "Stakeholder Management and RACI"（2026年7月29日））。
| 記号 | 英語 | 日本語でよく使う言い方 | この記事での呼び方 | 1行に何人か |
|---|---|---|---|---|
| R | Responsible | 実行責任者 | 実行する人 | 1人以上。複数でもよい |
| A | Accountable | 説明責任者、最終責任者 | 最終的に責任を持つ人 | 必ず1人 |
| C | Consulted | 協議先、相談先 | 相談を受ける人 | 必要な人だけ。いなくてもよい |
| I | Informed | 報告先 | 報告を受ける人 | 必要な人だけ。いなくてもよい |
日本語の呼び方は資料によって揺れています。そのため、表を見せる相手には、英語や記号だけでなく「やる人」「決める人」「相談する人」「知らせる人」のように言葉を添えると伝わりやすくなります。
RとAの違い
Rは手を動かす人、Aは結果に答える人です。Atlassianの解説は、Rの人はAの人から仕事を任され、合意した条件と期限の中でやり遂げる人だとし、Aは任せることをせず1人に割り当てるのがよいとしています（Atlassian「RACI chart」）。
たとえばデザイン案の作成なら、案を作るデザイナーがRで、その案を顧客に出してよいと判断するディレクターがAです。デザイナーが2人いれば、Rは2人になります。一方で、Aが2人いると、どちらがよしと言えば先へ進めるのかが分からなくなります。PMIは、Aの欄に2つの名前があれば次の揉めごとの種になり、1つもなければ仕事が落ちる原因になる、という趣旨で書いています。
小さな作業では、同じ人がAとRを兼ねてもかまいません。自分で原稿を取りまとめ、自分で完成とする場合です。表には「A・R」と書きます。
CとIの違い
Cは決める前に話を聞く相手で、Iは決まった後に知らせる相手です。PMIの解説でも、Cは作業が終わる前に意見を求める人、Iは決定や進み具合の後に知らせを受ける人とされています。
違いは、やり取りの向きにあります。Cとは行って戻る両方向のやり取りをし、Iへは一方向に知らせます。Cの人が増えるほど、返事を待つ時間が増えます。「知っておいてもらえば足りる人」をCにせず、Iにしておくと、作業は止まりにくくなります。
RACIと体制図・WBS・ステークホルダーマップの違い
RACIは、作業や決定の1つずつについて、誰がどの役割を担うかを見る表です。似た資料は案件の中にいくつもあるので、何を見るものかで使い分けます。
| 資料 | 分かること | 分からないこと | 作る時期の目安 |
|---|---|---|---|
| RACIチャート | 作業や決定ごとに、誰がやり、誰が決め、誰に聞き、誰に知らせるか | 日程、作業の量 | キックオフの前後 |
| 体制図 | 関わる人の役割と連絡の経路 | 作業ごとの細かな分担 | 提案からキックオフ |
| WBS | やるべき作業の一覧と階層 | 誰が決めるか | 計画を立てるとき |
| ステークホルダーマップ | 相手の会社で、誰が判断に影響するか | 契約後の作業の分担 | 契約の前 |
順番としては、体制図で関わる人を決め、WBSで作業を洗い出し、そのうち責任があいまいになりやすいところをRACIで詰める、という流れが自然です。体制図の書き方はプロジェクト体制図の書き方とテンプレート、作業の分け方はWBSの作り方とテンプレート、契約前に相手の会社の判断の流れを整理する方法はステークホルダーマップの作り方で解説しています。
RACIチャートが役立つ場面と、要らない場面
RACIチャートが役立つのは、関わる人が多く、誰が決めるのかが顔ぶれだけでは分からない案件です。逆に、全員が同じ部屋で毎日話している2〜3人の仕事に表を作っても、更新の手間が増えるだけです。
| 状況 | 作るか | 理由 |
|---|---|---|
| 顧客と自社の両方に承認する人がいる | 作る | 承認の場面で止まりやすく、誰の返事を待つかを先に決めておける |
| 再委託先や複数の部署が関わる | 作る | 会社や部署の境目で、作業が落ちたり重なったりしやすい |
| 「聞いていない」「誰の担当か」で揉めたことがある | 作る | 揉めた作業だけでも表にすれば、同じ行き違いを防げる |
| 担当者の交代や追加があった | 作る | 引き継ぐ人が自分の役割を表で確かめられる |
| 2〜3人の短い仕事で、決める人も明らか | 作らない | 体制図や依頼の一覧で足りる |
| 毎回同じ手順の定型の作業 | 作らない | 手順書に担当を書いておけば足りる |
作らないと決めた場合でも、「最後に誰が決めるのか」だけは確かめておきます。RACIの表そのものよりも、Aを1人に決めるという話し合いの方に価値があるからです。
RACIにも限界はあります。表で分かるのは役割だけで、作業の量や日程、優先順位は分かりません。また、役割を固定する表なので、やってみないと分からない仕事では、細かく作っても実態に追いつかないことがあります。そうした仕事では、行を「方針の決定」「成果の受け入れ」のような大きな決定だけに絞ると、無理なく使えます。
RACIチャートの作り方（5つの手順）
RACIチャートは、行に作業や決定、列に関わる人の役割を並べ、Aから先に埋めていきます。Rから埋めると「とりあえず担当者」が増え、最後までAが決まらない行が残りやすいからです。
- 行を書き出す: 作業や決定を並べます。WBSがあれば、そこから責任があいまいになりやすいものを選びます。「デザイン」ではなく「デザイン案の作成」「デザインの承認」のように、動詞まで書きます。
- 列に役割を並べる: 体制図の役割を左から並べます。受託の案件なら、顧客側と自社側を分けます。人が交代しても使えるように、列の見出しは役割名を先に、氏名を後に書きます。
- Aを先に決める: 行ごとに、最後に「これでよい」と言う人を1人決めます。決まらない行は、それ自体が今のうちに話し合うべき論点です。
- R・C・Iを埋める: Rを入れ、次に、決める前に話を聞く必要がある人をCに、決まった後に知らせれば足りる人をIにします。関わらない人の欄は「—」にして空けます。
- 関係者に見せて合意する: 表を自分たちだけで完成させず、列に名前がある人に見せます。自分の欄が思っていた役割と違えば、その場で分かります。合意した版に番号と日付を付けます。
できあがったら、縦と横に読み直します。横に見て、Aが1つだけあり、Rが1つ以上あるか。縦に見て、1人にAが集中していないか、全部の行に関わっている人がいないか。Aが集中している人は、案件の中で判断が詰まる場所です。
行の細かさの目安
行は、担当や決める人が変わるところで分けます。細かさに正解はありませんが、次の目安で迷いが減ります。
- 分ける: 作る人と承認する人が違う（作成と承認を別の行にする）。顧客側と自社側で決める人が違う。過去に揉めたことがある。
- まとめる: 担当も決める人も同じ作業が続く。誰が見ても迷わない定型の作業。
- 載せない: 1人で始めて1人で終わる作業。WBSの担当欄で足りるもの。
行の名前の付け方でも、読みやすさは変わります。
| 避ける書き方 | 直した書き方 | 理由 |
|---|---|---|
| デザイン | デザイン案の作成／デザインの承認 | 作る人と決める人が分かれる |
| 確認 | 原稿の内容確認（誤字と事実） | 何を確かめるのかが分かる |
| 調整 | 聞き取りの日程の調整 | 終わったかどうかを判断できる |
| 対応 | 問い合わせへの一次回答 | 誰が何をすれば終わりかが分かる |
案件全体なら、10〜20行ほどに収まると全員が読み通せます（行数は編集部の目安で、決まりがあるわけではありません）。何十行もある表は、更新されなくなり、次第に誰も見なくなります。WBSの全行にRACIを付ける必要はありません。
RACIチャートのテンプレートと記入例
ここでは、そのままコピーして使える表と、Web制作・システム開発・コンサルの記入例を載せます。記入例はいずれも架空の案件で、実在の企業のものではありません。
コピーして使えるRACIの表
エクセルやスプレッドシートに貼り付け、列と行を案件に合わせて書き換えてください。
| 作業・決定 | 顧客 責任者 | 顧客 窓口 | 自社 責任者 | 自社 窓口 | 自社 担当者 |
|---|---|---|---|---|---|
| 要件・構成案の作成 | |||||
| 要件・構成案の承認 | |||||
| 素材・原稿の用意 | |||||
| 制作・開発 | |||||
| 途中の成果物の承認 | |||||
| 範囲の変更の案（費用・日程）を固める | |||||
| 範囲の変更を受け入れる | |||||
| 検収 |
表の下には、「R: 実行する人 / A: 最終的に責任を持つ人（1行に1人）/ C: 相談を受ける人 / I: 報告を受ける人」と凡例を入れておきます。
エクセルで間違いを見つける式
エクセルやGoogleスプレッドシートなら、式でAの数を数えられます。表が大きくなるほど、目で確かめるより確実です。
- 表の右に「Aの数」の列を作ります。役割の欄がB列からF列なら、2行目に
=COUNTIF(B2:F2,"*A*")と入れ、下の行へコピーします。*は前後に何かあってもよいという意味なので、「A・R」のセルも数えられます。 - さらに右に「Rの数」の列を作り、
=COUNTIF(B2:F2,"*R*")と入れます。 - 「Aの数」が1でない行と、「Rの数」が0の行を、直す行として見ていきます。
- セルの入力規則で「R, A, C, I, A・R, —」の選択肢を作っておくと、表記が揃います。
列の見出しに名前を入れている場合は、表の最下行にも同じ式を縦方向に入れると、その人のAの数が分かります。表が10行目までなら、11行目のB列に =COUNTIF(B2:B10,"*A*") と入れ、右へコピーします。範囲には、見出しの行と式を入れた行を含めないでください。Aが特定の人に集中していないかを確かめるのに使えます。
記入例（Web制作の案件）
顧客の広報部と進めるコーポレートサイト制作の例です。木村様は先方の責任者、佐藤様は先方の窓口、中村は自社の責任者、田中は自社の窓口（ディレクター）、山田はデザイン、鈴木は実装の担当です。
| 作業・決定 | 木村様（先方 責任者） | 佐藤様（先方 窓口） | 中村（自社 責任者） | 田中（自社 窓口） | 山田（デザイン） | 鈴木（実装） |
|---|---|---|---|---|---|---|
| サイト構成案の作成 | — | C | I | A・R | C | C |
| サイト構成案の承認 | A | C | I | R | I | I |
| デザイン案の作成 | — | C | I | A | R | C |
| デザインの承認 | A | C | I | R | C | I |
| 原稿・写真の取りまとめ | I | A・R | — | C | — | — |
| ページの組み込み | — | — | I | A | C | R |
| 範囲の変更の案（費用・日程）を固める | — | C | A | R | C | C |
| 範囲の変更を受け入れる | A | C | I | R | I | I |
| 検収 | A | R | I | C | — | — |
作成の行と承認の行を分けていることに注目してください。「デザイン案の作成」のAは自社の田中で、顧客に出してよいかを判断します。「デザインの承認」のAは顧客の木村様で、この案で進めてよいかを判断します。1行にまとめると、Aが2人必要になってしまいます。
「デザインの承認」のRが田中なのは、承認を得るための作業、つまり案を説明し、返事を受け取るところまでを田中が担うからです。「原稿・写真の取りまとめ」は顧客の作業なので、AもRも佐藤様です。顧客の作業も行に入れておくと、誰の作業が止まっているのかが見えます。
記入例（システム開発の案件）
顧客の業務部が使うシステムの開発の例です。要件定義書と外部設計書の確定を顧客の責任者（業務部長）が担う形は、IPAのモデル契約のひな型が第9条で顧客側の責任者の権限として挙げている内容に合わせています（IPA「情報システム・モデル取引・契約書」第二版）。
| 作業・決定 | 業務部長（先方 責任者） | 情報システム部 担当者（先方 窓口） | 業務部 担当者 | 開発部長（自社 責任者） | 小林（自社 PM） | 高橋・伊藤（開発） |
|---|---|---|---|---|---|---|
| 業務の要望の取りまとめ | A | R | R | — | C | — |
| 要件定義書の確定 | A | R | C | I | C | I |
| 外部設計書の作成 | I | C | C | I | A | R |
| 外部設計書の確定 | A | R | C | I | C | I |
| 開発の作業の割り振り | — | — | — | I | A・R | C |
| 受け入れテスト | I | A | R | — | C | C |
| 範囲の変更の案（費用・日程）を固める | — | C | C | A | R | C |
| 範囲の変更を受け入れる | A | C | I | I | R | I |
| 検収 | A | R | C | I | C | — |
「業務の要望の取りまとめ」は、Rが2人の行です。Rは複数でもかまいません。「開発の作業の割り振り」は、顧客の欄がすべて「—」です。理由は後の章で説明します。
記入例（業務改善のコンサルティング）
顧客の役員の依頼で、業務の改善案を出す案件の例です。
| 作業・決定 | 役員（先方 責任者） | 企画部 担当者（先方 窓口） | 現場の部門長 | 自社 責任者 | 自社 マネージャー（窓口） | 自社 分析担当 |
|---|---|---|---|---|---|---|
| 調査の範囲を決める | A | R | C | C | C | I |
| 聞き取りの日程の調整 | I | A・R | C | — | C | I |
| 聞き取りと分析 | — | C | C | I | A | R |
| 報告書の案の作成 | I | C | C | A | R | R |
| 改善案を採用するかの判断 | A | R | C | I | C | — |
| 報告書の受け入れ | A | R | I | I | C | — |
コンサルティングで特に書いておきたいのは、「報告書の案の作成」と「改善案を採用するかの判断」の線引きです。提案の中身に責任を持つのは自社で、採用するかどうかを決めるのは顧客です。これを行で分けておくと、提案を受けた後に「決めてくれると思っていた」と言われることを防げます。現場の部門長をCにしているのは、改善案の実行を担うことになる人の意見を、決める前に聞くためです。
顧客と進める案件でのRACIの書き方
顧客と進める案件のRACIは、1つの表の中に2つの会社が入ります。通訳翻訳ジャーナルのコラムも、数社で協働する仕事で各社の役割を分ける言葉としてRACIを紹介しています。社内の表とは、次の4点が違います。
承認者が顧客側にあるとき
受託の案件では、承認のAが顧客側にある行が必ず出てきます。ここで大切なのは、Aに書くのが窓口の担当者ではなく、本当に決められる人だということです。
窓口の佐藤様をAにした表を作ると、佐藤様がよいと言った後で、木村様に差し戻される事態が起きます。誰が決めるのかが分からないうちは、Aの欄を空けたまま表を顧客に見せ、「デザインの最終判断はどなたがされますか」と聞きます。空欄のある表は、質問の道具になります。
モデル契約のひな型では、中間の資料について受注側が顧客の承認を書面で求められる定めも置いています（第35条）。契約書を交わさない小さな案件でも、顧客のAを名前で書いておき、そのAの人から返事をもらうという考え方は同じです。
両社の合意が要る決定は行を分ける
範囲や費用の変更のように、顧客と自社の両方が決める必要がある作業は、行を2つに分けて、それぞれにAを1人置きます。「Aは1行に1人」の決まりと、「両社に決める人がいる」という実務は、これで矛盾しなくなります。
PMIは、2つの部門がAの席を取り合うときに必要なのは表の手直しではなく決定だ、という趣旨で書いています。ただ、顧客と自社は別の会社なので、片方を外して1つに決めることはできません。範囲の変更で言えば、自社には「この費用と日程で受けられるか」を決める人がいて、顧客には「その条件で受け入れるか」を決める人がいます。決めていることが別なのですから、行も別にするのが素直です。
この分け方は、モデル契約の手続きとも合っています。ひな型の第37条は、変更の提案を受けた側が、変更の内容や費用、スケジュールを書いた変更管理書を相手に渡して協議し、変更を可とする場合は双方の責任者が承認して記名押印し、この承認をもって変更が確定するとしています。自社の行と顧客の行が両方済んだ時点で確定する、と表の下に一言書いておけば同じ意味になります。変更の依頼の受け付け方や返し方は、スコープクリープの防ぎ方で解説しています。
同じ考え方は、ほかの場面にも使えます。
| 決定 | 自社の行（Aの例） | 顧客の行（Aの例） |
|---|---|---|
| 納期の変更 | 新しい納期を出せるかを固める（自社 責任者） | 新しい納期を受け入れる（顧客 責任者） |
| 再委託先の追加 | 再委託先を選ぶ（自社 責任者） | 再委託を承諾する（顧客 責任者） |
| 公開の判断 | 公開できる状態かを確かめる（自社 窓口） | 公開してよいと判断する（顧客 責任者） |
顧客と共有する表と社内の表を分ける
顧客に見せる表には、自社の列を責任者と窓口だけにする方法もあります。自社の担当者の割り振りは社内の表で管理し、顧客との表には載せません。
記入例では読みやすいように担当者の列も載せましたが、人数が多い案件では、顧客との表と社内の表を分けた方が更新も楽になります。自社の担当者が交代しても、顧客との表を直さずに済みます。分ける場合は、顧客との表の行を親とし、社内の表はその行を作業に分けたものにしておくと、2つがずれません。
作業のやり方や割り振りの行に、顧客のAを置かない
請負や準委任の案件では、顧客のAやRを、作業のやり方や作業者の割り振りの行に置かないようにします。顧客が自社の作業者を直接指示している形を、表で認めてしまうことになるからです。偽装請負とは、契約は請負などの形なのに、実態は発注者が受注者の作業者に直接指示して働かせている状態のことで、労働者派遣法に違反します。
厚生労働省の疑義応答集（第3集）は、発注者側の責任者や担当者が受注者側の担当者に直接、業務の遂行方法や労働時間等を指示するなど、指揮命令があると認められる場合は偽装請負と判断されるとしています。一方で、情報の共有や技術的な助言・提案を密に行っていても、対等な関係で協働し、受注者側の担当者が自律的に判断して開発を進めていれば偽装請負とは判断されないとしています。そして、双方の役割や権限、業務の進め方を予め明確にして合意しておくことが重要だとしています。この考え方は、アジャイル型開発以外のシステム開発を請負業務とする場合にも当てはまるとされています（厚生労働省「37号告示に関する疑義応答集（第3集）」）。
RACIに置き換えると、次のように書き分けられます。
| 行の種類 | 顧客のA | 例 |
|---|---|---|
| 何を作るかの決定 | 置く | 要件定義書の確定、デザインの承認 |
| 成果物の受け入れ | 置く | 受け入れテスト、検収 |
| 誰がどの順番で作業するか | 置かない | 開発の作業の割り振り、日々の作業の順番 |
| 作業の進め方 | 置かない | 実装の手順、作業者の勤務時間 |
また、CやIの欄があることは、顧客と作業者が直接やり取りしてよいという意味ではありません。依頼の経路は体制図で決めた窓口を通します。システム開発の記入例で「開発の作業の割り振り」の顧客の欄が「—」なのは、この理由からです。個別の案件が偽装請負にあたるかは実態に即して判断されるので、迷う場合は都道府県労働局や専門家に相談してください。線の引き方の詳細は、プロジェクト体制図の書き方の「指示の線をどう引くか」の章で扱っています。
キックオフで合意し、版を付けて残す
顧客との表は、キックオフの前に案を作り、キックオフの場で顧客の責任者と窓口に見てもらいます。PMIが発行する雑誌の実務家の助言にも、キックオフの前にRACIで役割と責任をはっきりさせるとよいというものがあります（PM Network「Holding on to the reins」（2014年9月号））。
全行を読み上げる必要はありません。顧客のAとRが入っている行だけを見てもらい、「この承認は木村様にお願いしてよいですか」「この作業は佐藤様にお願いできますか」と聞きます。顧客にとっては、自社がどの作業を担い、どれくらい時間を取られるのかが事前に分かります。
モデル契約のひな型は、第8条で双方の共同作業と分担作業を定め、その詳細を個別の契約で決めるとし、解説つきの版には作業責任分担表のサンプルも載せています。分担を文書にしておくことは、ひな型でも重視されています。合意した表は議事録に添えるか、顧客と同じ場所に置き、体制が変わったら版と日付を更新します。
顧客に役割を確かめるときの言い方
RACIという言葉を知らない顧客も多くいます。その場合は、記号の説明から始めず、行ごとに質問の形で確かめます。
- Aを確かめる: 「デザインの最終判断はどなたがされますか。その方に直接ご覧いただく場を設けた方がよいでしょうか」
- Rをお願いする: 「原稿の取りまとめは佐藤様にお願いしてよいでしょうか。全ページ分を7月10日までにいただけると、公開日に間に合います」
- Cを確かめる: 「デザインを決める前に、ご意見を伺っておくべき部署はありますか」
- Iを確かめる: 「決まった内容をお知らせしておくべき方はいらっしゃいますか」
メールで聞くなら、表を添付するだけで終わらせず、「顧客側のお名前が入っていない行」だけを本文に書き出します。全行の確認を頼むより返事をもらいやすくなります。文中の日付は説明のための例です。
再委託先や、途中から入る人の書き方
協力会社に一部を再委託している場合は、協力会社の列を分けて、窓口になる管理責任者を1列置きます。協力会社の作業者を1人ずつ列にする必要はありません。顧客の列から協力会社の作業者へ直接つながる行を作らないのは、自社の作業者の場合と同じです。
案件の途中でRACIを作るときは、全部の行を埋めようとせず、今止まっている作業と、次の1か月で承認が要る決定だけから始めます。途中から作る表は、これまでの経緯の説明よりも「これから誰が決めるか」を確かめるためのものです。「今後はこの形で進めさせてください」と定例で見てもらえば、顧客にも受け入れてもらいやすくなります。
顧客側の決める人が案件の途中で変わったときは、その人のAの行をすべて確かめ直します。前の担当の方が承認した内容を、新しい方が知らないまま進むと、後から差し戻しになります。交代の直後に、承認済みの内容を一覧にして見てもらう場を取ると安全です。
決めた役割分担を、顧客と同じ場所で動かす
Terasuは、顧客と進める案件の共有ワークスペースです。タスクに担当者と期限を入れて顧客と進捗を共有でき、役割分担の表や議事録も案件ごとに同じ場所へ置けます。まずは1つの案件から無料でお試しください。
無料で案件の共有スペースを作るRACIチャートがうまくいかない形と直し方
表を作ったのに役に立たないときは、表の形を見れば原因が分かることが多くあります。多いのは次の形です。
| 表の形 | 起きていること | 直し方 |
|---|---|---|
| 1行にAが2つ以上ある | どちらの返事で進めてよいか分からない | 決めていることが別なら行を分ける。同じなら1人に決める |
| Aがない行がある | 誰も完了と言わず、仕事が落ちる | 決まるまで論点として残し、責任者に決めてもらう |
| Rがない行がある | 決める人はいるのに、作業する人がいない | 担当を決める。誰もやらないなら行が要らないか確かめる |
| Rが5人も6人もいる | 全員が「ほかの人がやる」と思う | 作業を分けて行を増やす |
| Cが多すぎる | 返事待ちで止まる | 決める前に本当に必要な人だけ残し、ほかはIへ移す |
| 全員の欄が埋まっている | 誰にとっても他人事になる | 関わらない人は「—」にする |
| 1人にAが集中している | その人が判断の詰まる場所になる | 任せられる行のAを別の人に渡す |
| 顧客のAが窓口の担当者 | 後から上の人に差し戻される | 本当に決められる人をAにし、窓口はRかCにする |
| 細かすぎて何十行もある | 更新されず、誰も見なくなる | 担当や決める人が変わるところだけを残す |
| 最初に作ったきり | 体制が変わり、実態と合わなくなる | 体制やフェーズが変わるときに見直す |
RとAを同じ人にしすぎない
小さな作業でA・Rを兼ねるのは問題ありません。ただ、重要な行でAとRが同じ人だと、確認する人がいなくなります。顧客へ出す成果物の作成や、費用に関わる判断は、作る人と確かめる人を分けておくと、誤りに気づける機会が増えます。
表だけで人は動かない
RACIは、決めたことを見えるようにする道具で、それだけで人が動くわけではありません。PMIの解説も、難しいのは表を作ることではなく、動いている案件の中で役割を実態どおりに保つことだという趣旨で書いています。定例で進み具合を確かめるときに表を開く、Aの人に承認を頼むときに表の行を示す、というように、普段の進行の中で使うと形だけの表になりません。
RASIC・DACIなど似た型との違い
RASICはRACIに支援する人（S）を足した型で、DACIは決定のための型です。RACIで足りないと感じたときの選択肢として、違いを押さえておきます。
| 型 | 中身 | 向いている場面 |
|---|---|---|
| RACI | R 実行する人、A 最終的に責任を持つ人、C 相談を受ける人、I 報告を受ける人 | 作業と決定の分担を決めたい。多くの案件はこれで足りる |
| RASIC（RASCI） | RACIに S（Support: Rを支援する人）を足したもの | 実行する人を手伝う人やチームが多く、Rと分けて示したい |
| DACI | D 決定を進める人、A 承認する人、C 助言する人、I 知らされる人 | 1つの重要な決定について、誰が進めて誰が決めるかを決めたい |
RASICのSについて、Lucidは、責任者を補助する役割を担うチームや個人で、ITサポートのように仕事の遂行を支えるものも含むと説明しています（Lucid「RASICチャートとは？RACIチャートとの違い」）。支援する人がはっきり分かれる案件では便利ですが、記号が増えるほど読む人の負担も増えます。迷ったらRACIのままにして、支援する人はRに含めるか、補足を書き添えれば足ります。
DACIとRACIの違いについて、Atlassianは、DACIやRAPIDは行動の前の意思決定を導くための型で、RACIはプロジェクトの役割を明確にするための型だと整理しています（Atlassian「RACI chart」）。DACIのAは「決める人1人」です（Atlassian「DACI」）。DACIのAはApprover（承認者）で、RACIのAはAccountableなので、同じ文字でも言葉が違います。普段の案件ではRACIを使い、「サービスの方針を変えるか」のような大きな決定だけDACIで整理する、という使い分けができます。
よくある質問（FAQ）
RACIは何と読みますか？
「レイシー」と読みます。「ラシ」ではありません。Responsible、Accountable、Consulted、Informedの頭文字で、RACIチャート、RACIマトリクス、RACI図、責任分担表などと呼ばれます。
RとAの違いは何ですか？
Rは実際に作業をする人で、1行に複数いてもかまいません。Aは結果に責任を持ち、最後に「これでよい」と言う人で、1行に1人だけです。作業者がR、それを確かめて承認する人がAと考えると分かりやすくなります。
AとRは同じ人が兼ねてもよいですか？
兼ねてもかまいません。小さな作業では、自分で作業して自分で完了とすることが普通で、表には「A・R」と書きます。ただし顧客へ出す成果物や費用に関わる行は、作る人と確かめる人を分けた方が誤りに気づきやすくなります。
Aを2人にしてはいけないのですか？
1行に2人は避けます。どちらの返事で進めてよいか分からなくなるためです。顧客と自社の両方の承認が要る決定は、自社が案を固める行と顧客が受け入れる行に分ければ、各行のAは1人のまま、両社の合意を表せます。
RACIチャートはいつ作り、いつ見直しますか？
体制が決まった後、キックオフの前後に作るのが目安です。関係者に見せて合意し、版と日付を付けて残します。担当者の交代、再委託先の追加、フェーズの切り替わりなど、体制や作業が変わるときに見直します。
RACIとRASICの違いは何ですか？
RASICは、RACIに支援する人を表すS（Support）を足した型です。実行する人を手伝う人やチームが多いときに使います。RASCIとも書きます。多くの案件はRACIで足り、記号が増えるほど読む人の負担も増えます。
RACIチャートはエクセルで作れますか？
作れます。行に作業や決定、列に役割を並べ、セルにR・A・C・Iを入れるだけです。入力の選択肢を作っておき、COUNTIF関数で行ごとのAの数を数えると、Aが0個や2個の行をすぐに見つけられます。
RACIが分かりづらいと言われたらどうすればよいですか？
列の見出しや凡例に「やる人」「決める人」「相談する人」「知らせる人」と言葉を添えます。記号の説明から始めず、「この承認はどなたがされますか」のように行ごとに聞けば、RACIを知らない顧客にも伝わります。
まとめ
- RACIは「レイシー」と読み、4つの役割を割り当てる表：実行する人、最終的に責任を持つ人、相談を受ける人、報告を受ける人です
- 1つの行にAは1人：Rは複数でもかまいませんが、Aは1人に決めます
- Aから先に埋める：Aが決まらない行は、今のうちに話し合うべき論点です
- 行は責任が変わるところで分ける：作成と承認は別の行にし、すべての作業を載せる必要はありません
- 両社の合意が要る決定は行を分ける：自社が案を固める行と、顧客が受け入れる行にします
- 顧客のAは決定と受け入れに置く：作業のやり方や割り振りの行には置きません
- 作りっぱなしにしない：キックオフで合意し、体制が変わったら版を上げます
まずは今の案件で、顧客側の承認が要る行を3つ書き出し、それぞれのAの欄に名前が入るかを確かめてください。入らなければ、次の定例で聞くところから始めましょう。
本記事の情報について: RACIの定義と「Aは1人」の考え方はPMIの解説とAtlassianの解説、読み方は通訳翻訳ジャーナル、モデル契約の内容はIPA「情報システム・モデル取引・契約書」第二版のひな型、請負と派遣の区分は厚生労働省の「37号告示に関する疑義応答集（第3集）」で、2026年11月3日に確認しています。本記事は一般的な考え方の解説で、個別の案件の法的な判断を示すものではありません。記入例は Terasu 編集部が作成した架空のもので、実在の企業や案件のものではありません。
