RACIチャートとは？「誰が何に責任を持つか」を明確にする役割分担表
RACIチャートとは
RACI（レイシー）チャートは、プロジェクトの作業や成果物ごとに、誰がどのような役割と責任を持つのかを一覧にした表です。責任分担マトリックス（RAM）の代表的な形式で、役割の重複や空白を防ぎ、「誰が決めるのか」「誰に聞けばよいのか」を明確にします。
RACIの4つの役割
記号 | 役割 | 意味 |
|---|---|---|
R | Responsible（実行責任者） | 実際に作業を行う人。複数いてもよい |
A | Accountable（説明責任者・最終責任者） | 作業の結果に最終的な責任を持ち、承認する人。1つの作業に必ず1人だけ |
C | Consulted（相談先） | 作業の前や途中で意見を求める人。双方向のコミュニケーション |
I | Informed（報告先） | 進捗や結果を知らせる人。一方向のコミュニケーション |
RACIチャートの例
システム導入プロジェクトの一部を例にすると、次のようになります。
作業 ＼ 担当 | スポンサー | PM | 業務リーダー | 開発リーダー | 利用部門 |
|---|---|---|---|---|---|
プロジェクト憲章の作成 | A | R | C | C | I |
要件定義書の作成 | I | A | R | C | C |
基本設計 | A | C | R | I | |
受け入れテスト | I | A | R | C | R |
本番稼働の判定 | A | R | C | C | I |
RACIチャートの作り方
作業・成果物を洗い出す：WBSの主要な要素や、重要な意思決定を行（縦軸）に並べます。
関係者を並べる：役割や担当者を列（横軸）に並べます。個人名より役割名のほうが、人の入れ替わりに強くなります。
役割を割り当てる：各作業について、R・A・C・Iを記入します。
チェックする：次のルールに沿って、表を縦横に確認します。
関係者と合意する：作成した表を関係者と確認し、合意を得てから共有します。
チェックのポイント
行（作業）ごとに確認する
Aは必ず1人だけか：Aがいないと責任があいまいになり、複数いると意思決定が止まります。
Rが少なくとも1人いるか：誰も作業しない作業がないか確認します。
Cが多すぎないか：相談先が多すぎると、調整に時間がかかり作業が進みません。
Iが多すぎないか：不要な人にまで報告すると、情報過多になります。
列（担当者）ごとに確認する
特定の人にRやAが集中していないか：負荷が偏り、ボトルネックになります。
役割がまったくない人はいないか：本当にプロジェクトに必要な人かを見直します。
その人の権限に見合っているか：Aを担う人が、実際に承認する権限を持っているかを確認します。
RACIの派生形
RASCI：S（Support：支援者）を加え、作業を手伝う人を区別します。
DACI：D（Driver：推進者）、A（Approver：承認者）、C（Contributor：貢献者）、I（Informed：報告先）で、意思決定の役割に特化した形です。
PMの実務での活用
プロジェクトの立ち上げ時：プロジェクト憲章で定めた体制を、作業レベルの役割分担に落とし込みます。
ステークホルダー・マネジメント：CとIは、誰と、どの程度コミュニケーションを取るべきかを示し、コミュニケーション計画の土台になります。
外部要員の管理：派遣社員や協力会社の担当範囲を明確にし、契約範囲外の作業や指示系統の混乱を防ぎます。準委任契約の場合は、指示が受託会社の責任者を通じて行われるよう、役割を設計します。
トラブル時：問題が起きたときに、誰が判断し、誰が対応し、誰に報告するかがすぐに分かります。
よくある失敗と注意点
Aが複数いる：「共同責任」は「無責任」になりがちです。最終責任者は1人に絞ります。
RとAの混同：作業をする人と、結果に責任を持つ人は違うことがあります。区別して考えます。
作って終わり：体制の変更やメンバーの入れ替わりがあれば、更新します。
細かすぎる：すべての作業を網羅しようとすると、表が大きくなりすぎて使われなくなります。重要な作業や意思決定に絞ります。
まとめ
RACIチャートは、作業ごとに実行責任者（R）、最終責任者（A）、相談先（C）、報告先（I）を明確にする表
Aは必ず1人だけにし、行と列の両方から、役割の空白・重複・偏りをチェックする
体制づくり、コミュニケーション計画、外部要員の管理、トラブル対応など、PMの実務に幅広く活用できる