RACI図とは 作り方とテンプレート 体制図・役割分担表の記入例

RACI図（RACIチャート）とは、作業ごとに「誰が実行し、誰が最終的に責任を持ち、誰に相談し、誰に知らせるか」をR・A・C・Iの4文字で書き込む役割分担表です。 行に作業、列に役割を並べ、交わるマスに1文字を入れるだけなので、表計算ソフトがあればすぐに作れます。

この記事では、システム開発の工程を題材にした記入済みのRACI表をMarkdownとタブ区切りの両方で載せ、表計算ソフトの数式で抜けや偏りを点検する方法までを扱います。体制図からRACI表へ落とす手順、発注側と受注側の役割分担表、RASCI・DACI・RAPIDとの違いも表で整理しました。

確認環境：点検用の数式は LibreOffice Calc 24.2（ヘッドレス実行）で xlsx ファイルを再計算して結果を確かめました。Mermaid のコードは @mermaid-js/mermaid-cli 11.14.0 で描画できることを確かめています。

RACIの早見表

RとA、CとIの見分け方

RACIで迷いやすいのは、RとA、CとIの線引きです。次の問いに当てはめると決めやすくなります。

1人がRとAを兼ねる場合は、マスに「A/R」と書きます。 小さなチームではよくある形で、たとえばリーダーが自分でコードレビューを行い、その結果にも責任を持つ場合が当てはまります。

システム開発のRACI表テンプレート（記入済み）

架空の題材として、社内の備品予約システムを新しく作る場合を想定しました。行は工程、列は役割です。役割は個人名ではなく役割名で書いておくと、担当者が替わっても表を直さずに済みます。

表計算ソフトに貼る場合は、次のタブ区切りをコピーしてA1セルに貼り付けます。

作業  発注側 PM  リーダー    開発  テスト 運用
要件定義    A   R   C   I   I   C
基本設計    C   A   R   C   I   C
詳細設計    I   I   A   R   C   
実装      I   A   R       
コードレビュー         A/R C   I   
単体テスト           A   R   C   
結合テスト   I   A   C   C   R   
総合テスト   I   A   C   I   R   C
受入テスト   A/R C   I   I   C   I
移行・リリース A   R   R   C   I   R
運用手順書の作成    C   A   C   I       R
運用引き継ぎ  I   A   R           R

この表の読み方

この配置は一例です。契約の形や体制によってAの位置は変わるので、自分たちの体制で「この作業の完了を承認するのは誰か」を1行ずつ確かめながら書き換えてください。

RACI図の作り方（6つの手順）

Aを先に埋めるのがポイントです。 Rから書き始めると、作業に関わる人を次々に入れてしまい、誰が承認するのかがあいまいなまま表が埋まりやすくなります。

COUNTIFで点検する（Aの数・Rの有無・CとIの多さ）

RACI表は、書いたあとの点検で価値が決まります。目で数える代わりに、表計算ソフトのCOUNTIF関数で各行の文字数を数えると、12行でも100行でも同じ手間で確かめられます。

行ごとの点検式

先ほどのタブ区切りをA1に貼ると、データはB2からG13に入ります。H列からL列に次の数式を入れ、13行目までコピーします。

=IF(H2=0,"Aがいない",IF(H2>1,"Aが複数",IF(I2=0,"Rがいない",IF(I2>=4,"Rが多い",IF(J2>=4,"Cが多い",IF(K2>=4,"Iが多い","OK"))))))

検索条件を "A" ではなく "*A*" と書いているのは、「A/R」と書いたマスもAとして数えるためです。Microsoft のサポートページでは、COUNTIFの検索条件でアスタリスクが任意の文字列、疑問符が任意の1文字を表すワイルドカードとして使えること、条件で大文字と小文字が区別されないことが説明されています。

「多い」と判定するしきい値（Rが4人以上、CとIが4人以上）は、6列の表に合わせた目安です。列の数が増えたら、列数の半分を超えたら見直す、といった基準に合わせて数字を変えてください。

点検結果：直す前の表

わざと6か所を崩した表に数式を入れた結果です（LibreOffice Calc 24.2 で再計算した値）。

判定が「OK」以外の行数は、次の数式で数えられます。この表では 6 になりました。

=COUNTIF(L2:L13,"<>OK")

判定ごとの直し方

直したあとの表（前の章のテンプレート）では、12行すべてが「OK」になり、判定がOK以外の行数は 0 になりました。

列ごとの点検式（役割の負荷を見る）

行の点検が済んだら、列方向にも数えます。14行目以降に次の数式を入れ、G列までコピーします。

テンプレートの表での結果は次のとおりです。

リーダーは12行すべてに関わり、Rが4つ、Aが4つあります。1つの役割にRとAが集まっている場合は、その役割を2人に分ける、Aの一部をPMへ移す、といった見直しの候補になります。 逆に、Rが1つもない役割は、その役割が本当に必要かを確かめるきっかけになります。

RACI表の点検項目一覧

数式で数えられる項目と、人が読んで確かめる項目をまとめました。

体制図からRACI表へ落とす手順

体制図とRACI図は、答える問いが違います。体制図は「誰が誰に報告するか」を、RACI図は「作業ごとに誰が何をするか」を示します。 体制図だけでは、たとえば「結合テストの完了を承認するのはPMかリーダーか」は読み取れません。両方をそろえると、指示の流れと作業の分担がつながります。

まず体制図を用意します。次のコードはMermaidのフローチャートで書いた例です。

flowchart TB
    subgraph ORD["発注側"]
        O1["責任者（承認）"]
        O2["業務担当（要件・受入）"]
        O1 --- O2
    end
    subgraph DEV["受注側"]
        PM["PM"]
        L["リーダー"]
        D["開発"]
        T["テスト"]
        OP["運用"]
        PM --- L
        L --- D
        L --- T
        PM --- OP
    end
    O1 -.->|"定例・承認"| PM
    O2 -.->|"仕様の相談"| L

この体制図から、次の順でRACI表に落とします。

たとえば「リーダー―開発」は実線なので、開発がRの「実装」「単体テスト」ではリーダーがAになります。「発注側の業務担当―リーダー」は点線なので、「基本設計」で発注側がCになります。手順2で候補を置いたあと、「その人は本当にその成果物を承認できるか」を1行ずつ確かめると、形だけの表になりにくくなります。

発注側と受注側の役割分担表の例

RACI表は工程の粒度で書くことが多いため、発注側と受注側の境目にある細かな作業は別の表にしておくと、認識のずれを早めに見つけられます。こちらはRACIの4文字ではなく、「主担当」と「支援」の2種類で書くほうが読みやすくなります。

分類  作業  発注側 受注側 補足
要件  業務の流れの説明    主担当 支援  受注側は聞き取りと記録
要件  要件定義書の作成    支援  主担当 発注側は内容の確認
要件  要件定義書の承認    主担当 ―   承認日を記録する
設計  画面・帳票の確認    主担当 支援  受注側は説明と修正
設計  既存システムの仕様の提供    主担当 ―   連携先の資料を含む
環境  開発環境の用意 ―   主担当 
環境  本番環境の用意 主担当 支援  契約で変わるので明記する
テスト テスト用データの提供  主担当 支援  個人情報は加工して渡す
テスト 受入テストの項目作成と実施   主担当 支援  受注側は質問への回答
テスト 不具合の修正  ―   主担当 
移行  移行元データの抽出と整理    主担当 支援  不要なデータの判断は発注側
移行  移行ツールの作成と実行 支援  主担当 結果の確認は発注側
教育  利用者向け説明会    主担当 支援  資料の作成は受注側が支援
運用  利用者からの問い合わせ窓口   主担当 支援  受注側は調査の依頼を受ける

テスト用データ、本番環境、移行元データの3つは、どちらが用意するかで日程が大きく動く項目です。表にして早い段階で双方が確認しておくと、あとの工程が進めやすくなります。

RACI・RASCI・DACI・RAPIDの比較

RACIには、文字を足したものや、意思決定に絞ったものなど、似た名前の手法があります。

開発の工程表に合わせて使うなら、まずRACIで十分です。 Rが3人以上になる行が目立ってきたら、主担当だけをRに残してほかをSにするRASCIへ広げると、表を作り直さずに済みます。

うまく回すためのコツ

よくある質問

Q. RとAを同じ人にしてもよいですか？ A. かまいません。その場合はマスに「A/R」と書きます。この記事の点検式は "*A*" のようにワイルドカードで数えるので、「A/R」のマスもAとRの両方に数えられます。

Q. Aは必ず1人ですか？2人で承認する作業はどう書きますか？ A. 1つの行にAは1人が原則です。2人の承認が要る場合は、「設計書の内部承認」「設計書の発注側承認」のように作業を2行に分けると、それぞれのAが1人になります。

Q. 行はどのくらいの細かさにすればよいですか？ A. 1枚で見渡せる10〜20行が目安です。WBSの上位の階層や、工程ごとの主な成果物を行にすると、WBSや工程表と照らし合わせやすくなります。

Q. ExcelでもGoogleスプレッドシートでも同じ数式で動きますか？ A. この記事の計算結果は LibreOffice Calc 24.2 で確かめたものです。COUNTIFのワイルドカードは Microsoft のサポートページに記載があり、同じ書き方が使えます。使う前に、記入済みテンプレートを貼って判定が12行とも「OK」になるかを見ておくと確実です。

まとめ

• RACI図は、作業×役割の表にR（実行）・A（承認と責任）・C（相談）・I（報告）を書き込む役割分担表
• Aは1行に必ず1人、Rは1人以上。Aから先に決めると表がまとまりやすい
• 役割名で書くと、担当者が替わっても直しが少ない
• COUNTIFで行ごとのA・R・C・Iの数を数えると、抜けと偏りを数字で点検できる
• 列方向にも数えると、1つの役割に負荷が集まっていないかがわかる
• 体制図の箱を列に、線をA・C・Iの候補に読み替えるとRACI表に落とせる
• 支援役を分けたいときはRASCI、意思決定の進め方を決めたいときはDACIやRAPIDが選択肢になる

参考

• Atlassian「RACI チャート」https://www.atlassian.com/ja/work-management/project-management/raci-chart （RACI・DACI・RAPIDの各文字の意味）
• Asana「RACI チャートとは」https://asana.com/ja/resources/raci-chart （RASICのSの意味）
• Microsoft サポート「COUNTIF 関数」https://support.microsoft.com/ja-jp/office/countif-関数-e0de10c6-f885-4e71-abb4-1f464816df34 （ワイルドカードと大文字・小文字の扱い）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。