RACIチャートの作り方｜RとAの違い・役割分担の具体例

RACIチャートは、作業・成果物を行、関係者を列に並べ、実行するRと最終責任を持つAを先に決めると作成できます。各行のAを原則1人にしたうえで、決定前に意見を聞くC、進捗や結果を知らせるIを必要な範囲へ割り当てます。

RACIチャートとは、タスクや成果物ごとに関係者の実行・最終責任・相談・情報共有の役割を整理した責任分担表です。役職順に記号を埋めるのではなく、「この成果物を誰が作り、誰が引き受けるか」を合意するために使います。

RとA、CとIの違いをどう見分ける？

RACIは、Responsible・Accountable・Consulted・Informedの頭文字です。Asanaの公式解説では、作業を進める役割、成果を承認して最終結果を引き受ける役割、助言する役割、状況を把握する役割として説明しています。

RとAが分かれにくい場合は、「Rが提出したものを、Aがどの条件で受け入れるか」を1文にします。たとえば「営業担当が入力項目案を作り、営業責任者が現場で運用できるか確認して承認する」なら、RとAを分離できます。

CとIの違いは双方向の相談が必要かどうかです。決定前のレビューが必要な相手をIにすると、決定後の差し戻しを招きます。一方、結果を知ればよい全員をCにすると、回答待ちが増えます。空欄は関与しないという意味で使い、すべてのセルを埋める必要はありません。

営業システム導入の具体例

以下は、CRMへ商談情報を移行する架空のプロジェクトです。営業責任者に業務要件と運用開始の判断権限があり、情報システム担当が技術面の移行完了を引き受ける前提を置いています。自社で権限が異なる場合は、そのまま採用せず変更します。

この表は5行×4人＝20セルです。各行にAとRが1つずつあり、残りは必要な相談・共有先だけを入れています。Aの数を列ごとに数えると営業責任者が4件、情シス担当が1件です。これは工数の比率ではありませんが、営業責任者の判断待ちが重なりそうかを確認する材料になります。

「運用開始の可否を判断」のRは、判断材料をまとめて提出する営業担当です。最終判断そのものはAが行います。このように、行名が判断を表している場合も、Rが具体的に何を準備するかを補足します。

完了条件を一緒に残す

RACIの記号だけでは、成果の品質や締め切りは決まりません。たとえば「テストデータの移行を完了」の行には、別のタスク表で次のような条件を付けます。

架空のテストデータ100件について、合意した項目の件数・値を照合する。ベンダーが照合結果と不一致の一覧を提出し、情シス担当が合意済みの受入条件を満たしたか確認する。

100件は説明用の例で、移行テストの推奨件数ではありません。対象範囲と確認方法は要件定義に合わせます。行に対応する資料URL・期限・承認記録の場所も決めておくと、表から実際の作業へつなげられます。

RACIチャートを作る5つの手順

1. 今回の表で決める範囲を絞る。 「CRM導入全体」ではなく、まず入力項目決定から運用開始までなど、関係者と成果が分かる範囲にします。
2. 完了を確認できる行を作る。 WBSの作業を参考に、「システム導入」のような大きすぎる行を分けます。各行の成果物や判断が説明できれば次へ進めます。
3. 関係者を列に置き、AとRを決める。 Aの権限と引き受け範囲を確認し、実行担当も決めます。部門名で作る場合は、その部門の窓口となる個人を別途明記します。
4. CとIを必要な相手に限って割り当てる。 Cには何についていつまでに意見をもらうか、Iには何をどのタイミングで共有するかを確認します。
5. 行と列の両方から点検し、本人と合意する。 行ではAの不在・重複と実行担当の不在、列では承認や作業の集中を確認します。関係者が実行できない割り当てを残さず、版と更新日を付けて共有します。

日程や依存関係はガントチャートなどの別の管理表で扱います。RACIを作っただけで、期限や作業順序まで決まったことにはなりません。

Aが2人になる場合と、R/A兼任をどう扱う？

Aが2人なら、判断対象の違いを確かめる

「要件承認」に営業部長と情シス責任者の両方がAとなる場合、業務要件とセキュリティ要件の判断が一つの行へ混ざっている可能性があります。この場合は、業務要件の承認とセキュリティ要件の承認を別行にすると、それぞれの最終責任を示せます。

単に表の見た目を整えるため、一方の承認者をCへ落としてはいけません。組織の承認ルールに従い、判断対象を分けられない場合は、合議の条件と取りまとめる責任者を別途記録します。

RとAの兼任は、承認ルールに照らして決める

小さな作業で同じ人が実行と最終責任を担う場合は、R/Aと併記できます。Asanaの公式例にも、Web開発者が同じタスクでResponsibleとAccountableを担う例があります。ただし、支払い・アクセス権付与など自社で職務分離を求める業務まで、効率だけを理由に兼任にしません。

本サイトのツールは1セルにA・R・C・Iのいずれかを選ぶ仕様です。兼任が必要な表はExcelなどへコピーしてR/Aを追記し、その行に別のAがいないかを手動で確認してください。兼任を隠すために同じ人を別人のような2列へ分けると、責任の集中が読めなくなります。

実行に複数人が関わる場合も、各人の担当範囲と取りまとめ役を明確にします。表にRを増やすだけで作業の分担が決まるわけではありません。分担を説明できなければ、行を分けるところへ戻ります。

よくある失敗と、運用中に直すタイミング

ツールの警告がなくなることは、合意や権限が整った証明ではありません。表の検査は抜け・重複を探す補助として使い、実際に担当する人の確認を経て運用します。

作業の洗い出しがまだできていない場合はWBSの作り方から始め、意思決定に必要な資料を整理する場合は稟議書の書き方も参照してください。