プロジェクトやチーム業務を進めていると、「結局これは誰がやるのか」「誰の承認が必要なのか」「誰に相談すべきなのか」が曖昧になることがあります。
最初は何となく進んでいても、途中で問題が起きると、「担当だと思っていなかった」「聞いていない」「承認したつもりはない」といった認識ズレが表面化します。特に、複数部署が関わるプロジェクトでは、作業内容だけでなく、責任の所在を明確にしておくことが非常に重要です。
そこで役立つのが、RACIです。
RACIは、仕事やタスクに対して、誰が実行し、誰が最終責任を持ち、誰に相談し、誰に情報共有するのかを整理するフレームワークです。
プロジェクト管理というと、スケジュールやタスク管理に目が向きがちですが、実務では「役割分担の曖昧さ」が大きなトラブル原因になります。RACIを使うことで、関係者の役割を見える化し、仕事の停滞や責任の押し付け合いを防ぎやすくなります。
この記事でわかること
・RACIとは何か
・RACIは何に使うのか
・RACIの基本的な考え方
・RACIの使い方
・RACIの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「RACIは仕事ごとの役割と責任を整理するための型だ」とつかめれば十分です。
RACIとは？
RACIとは、タスクや業務ごとに関係者の役割を整理するためのフレームワークです。
RACIは、次の4つの頭文字からできています。
・Responsible
・Accountable
・Consulted
・Informed
それぞれの意味は、次の通りです。
Responsibleは、実際に作業を行う人です。日本語では「実行責任者」や「担当者」と表現されます。
Accountableは、最終的な責任を持つ人です。日本語では「説明責任者」や「最終責任者」と表現されます。作業結果に対して最終的に承認し、責任を負う立場です。
Consultedは、作業前や作業中に相談すべき人です。専門知識を持っている人、判断に関わる人、事前確認が必要な人が該当します。
Informedは、進捗や結果を共有すべき人です。直接作業や承認には関わらないものの、情報を知っておく必要がある人です。
たとえば、「新商品の販促資料を作成する」というタスクがある場合、マーケティング担当者がResponsible、商品企画部長がAccountable、法務部門や知的財産部門がConsulted、営業部門がInformedになることがあります。
初心者向けに言い換えるなら、RACIは「この仕事について、誰がやる人で、誰が責任者で、誰に相談し、誰に知らせるのかを整理する表」です。
一言でいうと、RACIは仕事ごとの役割と責任を明確にするためのフレームワークです。
RACIは何に使うのか
RACIは、タスクやプロジェクトにおける役割分担を明確にするために使います。
仕事では、「担当者」と「責任者」が混同されることがあります。実際に作業する人と、最終的に判断・承認する人は必ずしも同じではありません。また、相談すべき人と、単に情報共有すべき人も違います。
RACIを使うと、こうした違いを整理できます。
RACIは次のような目的で使われます。
・タスクごとの担当者を明確にする
・最終責任者を明確にする
・相談すべき人を整理する
・情報共有すべき人を整理する
・承認プロセスを分かりやすくする
・責任の押し付け合いを防ぐ
・関係者の認識ズレを減らす
・プロジェクトの停滞を防ぐ
たとえば、資料作成の場面で「誰かが確認するだろう」と思って進めると、最後になって確認漏れが発覚することがあります。RACIでConsultedやAccountableを明確にしておけば、「誰に事前相談し、誰が最終承認するのか」が分かります。
また、情報共有の対象をInformedとして整理しておけば、「聞いていない」というトラブルも減らせます。
どんな人に向いているか
RACIは、複数人で仕事を進める人に向いています。
特に、次のような人におすすめです。
・プロジェクトを任された人
・チーム内の役割分担を整理したい人
・部署間調整が多い人
・承認者や相談先が曖昧になりやすい人
・会議で「誰がやるか」が決まらず困っている人
・タスク管理をしているが責任分担が不明確な人
・新商品開発やシステム導入など複数部署の仕事を担当する人
・マネージャーやリーダーとして業務を整理したい人
RACIは、プロジェクトマネージャーだけでなく、チームリーダー、係長、主任、業務改善担当、企画担当、人事担当、営業企画担当などにも役立ちます。
特に、「関係者が多い」「承認が必要」「相談先が多い」「誰が決めるのか曖昧」という仕事では、RACIを使う効果が大きくなります。
RACIの基本的な考え方
RACIの基本は、1つのタスクに対して4種類の役割を整理することです。
それぞれの役割をもう少し実務寄りに考えると、次のようになります。
Responsibleは、手を動かして作業する人です。資料を作る、調査する、顧客に連絡する、システム設定を行うなど、実際の実行を担います。1つのタスクに複数人がResponsibleになることもあります。
Accountableは、最終的にそのタスクの結果に責任を持つ人です。承認者、意思決定者、責任者に近い役割です。原則として、1つのタスクにAccountableは1人にするのが望ましいです。最終責任者が複数いると、判断が曖昧になりやすいからです。
Consultedは、作業前や意思決定前に相談する人です。専門知識を持つ人や、影響を受ける部門が該当します。法務、知的財産、品質保証、情報システム、経理などは、Consultedとして入ることが多い部門です。
Informedは、結果や進捗を共有する人です。直接作業や判断には関わりませんが、情報を知っておく必要があります。上司、関連部署、営業担当、現場担当などが該当します。
RACIで大切なのは、役割の違いを混同しないことです。
たとえば、「相談する人」と「承認する人」は違います。法務部門に相談する必要があっても、最終的な事業判断は事業部門が持つ場合があります。また、情報共有すべき人が多いからといって、その人たち全員に承認を求めると、プロジェクトは進みにくくなります。
RACIは、関係者を増やすための表ではありません。むしろ、役割を整理して、仕事を進めやすくするための道具です。
RACIの使い方
手順1 タスクや成果物を洗い出す
最初に、RACIで整理したいタスクや成果物を洗い出します。
RACIは、いきなり人の名前から考えるのではなく、「どの仕事について役割を決めるのか」から始めます。
たとえば、新商品発売プロジェクトなら、次のようなタスクがあります。
・市場調査を行う
・商品コンセプトを決める
・試作品を作成する
・品質確認を行う
・価格を設定する
・販促資料を作成する
・営業説明会を実施する
・発売後の問い合わせ対応を整理する
このように、まずはWBSのように作業を分解します。そのうえで、各タスクに対してRACIを設定していきます。
タスクが曖昧なままだと、役割分担も曖昧になります。「資料作成」ではなく、「営業向けの商品説明資料を作成する」のように、できるだけ具体的に書くことが重要です。
手順2 関係者を洗い出す
次に、各タスクに関係する人や部署を洗い出します。
この段階では、実行者だけでなく、承認者、相談先、情報共有先も含めて考えます。
関係者としては、次のような人や部署が考えられます。
・プロジェクト責任者
・プロジェクトマネージャー
・実務担当者
・上司
・関連部署
・法務部門
・知的財産部門
・品質保証部門
・情報システム部門
・営業部門
・マーケティング部門
・外部パートナー
関係者を洗い出すときは、OBSやステークホルダー分析と組み合わせると便利です。
OBSで関係部署を整理し、RACIで各タスクに対する役割を割り当てると、プロジェクト体制が分かりやすくなります。
手順3 各タスクにResponsibleを決める
次に、各タスクについてResponsibleを決めます。
Responsibleは、実際に作業を行う人です。「このタスクを前に進める人」と考えると分かりやすいです。
たとえば、販促資料を作成するタスクでは、マーケティング担当者や営業企画担当者がResponsibleになることがあります。品質確認では、品質保証部門がResponsibleになるかもしれません。市場調査では、商品企画担当者がResponsibleになることがあります。
Responsibleを決めるときは、次の点を確認します。
・実際に作業する人は誰か
・作業を進めるスキルや情報を持っているか
・担当者が複数いる場合、主担当は誰か
・作業量に無理はないか
・他のタスクとの兼務に問題はないか
Responsibleが曖昧だと、誰も手を付けない状態になりやすくなります。「みんなでやる」は、実務では「誰も責任を持たない」状態になりがちです。
手順4 Accountableを1人に決める
次に、Accountableを決めます。
Accountableは、タスクの最終責任を持つ人です。結果を承認する人、意思決定する人、最終的に説明する人です。
RACIで特に重要なのは、Accountableをできるだけ1人にすることです。
なぜなら、最終責任者が複数いると、判断が割れたときに決められなくなるからです。「A部門も責任者、B部門も責任者」という状態では、問題が起きたときに責任の所在が曖昧になります。
たとえば、営業資料の作成では、営業企画部長がAccountableになるかもしれません。商品仕様の決定では、商品企画部長がAccountableになる場合があります。システム仕様の決定では、プロジェクトオーナーや情報システム部門の責任者がAccountableになることがあります。
Accountableを決めるときは、次の点を確認します。
・最終的に承認する人は誰か
・結果に対して説明責任を持つ人は誰か
・判断が必要なときに決められる人は誰か
・組織上の責任と実務上の責任が合っているか
Accountableが明確になると、意思決定が速くなります。
手順5 ConsultedとInformedを整理する
最後に、ConsultedとInformedを整理します。
Consultedは、作業前や判断前に相談すべき人です。専門的な知識を持つ人、影響を受ける部門、確認が必要な部門が該当します。
たとえば、販促資料を作る場合、次のような相談先が考えられます。
・商品企画部門
・法務部門
・知的財産部門
・品質保証部門
・営業部門
一方、Informedは、作業結果や進捗を共有すべき人です。直接承認や相談には関わらないものの、情報を知っておく必要がある人です。
たとえば、発売開始日が決まった場合、営業部門、カスタマーサポート部門、物流部門、経営層などに情報共有する必要があるかもしれません。
ConsultedとInformedを区別することは非常に重要です。
Consultedは双方向のやり取りが必要です。意見を聞き、必要に応じて反映します。Informedは一方向の情報共有で足ります。全員をConsultedにしてしまうと、確認が増えすぎてプロジェクトが進みにくくなります。
RACIの具体例
例 社内研修プロジェクトの場合
社内研修を実施するプロジェクトでRACIを使う例を考えてみます。
タスクとして、次のようなものがあります。
・研修テーマを決める
・研修資料を作成する
・講師を手配する
・受講者を募集する
・当日運営を行う
・アンケートを集計する
・研修結果を報告する
たとえば、「研修資料を作成する」というタスクでは、研修担当者がResponsibleになります。人材育成部門の責任者がAccountableになります。現場部門の管理職や専門部署がConsultedになります。受講者の上司や関係部門がInformedになることがあります。
「当日運営を行う」というタスクでは、研修事務局がResponsibleになります。研修責任者がAccountableになります。講師や会場担当者がConsultedになります。受講者や関係部署がInformedになります。
「研修結果を報告する」というタスクでは、研修担当者がResponsibleになります。人材育成部門の責任者がAccountableになります。経営企画部門や対象部門長がConsultedになる場合があります。関係部署や参加者の上司がInformedになることもあります。
このようにRACIで整理すると、研修プロジェクトの中で誰が何を担うのかが明確になります。
特に、研修のように人事部門、現場部門、講師、受講者、上司など多くの関係者が関わる仕事では、役割分担を明確にしておくことが重要です。
別の例 新商品発売プロジェクトの場合
新商品発売プロジェクトでも、RACIは非常に役立ちます。
たとえば、「販促資料を作成する」というタスクを考えます。
Responsibleは、マーケティング担当者や営業企画担当者です。実際に資料を作成し、内容をまとめます。
Accountableは、マーケティング部門の責任者や商品企画責任者です。資料の最終的な内容に責任を持ちます。
Consultedは、商品企画部門、法務部門、知的財産部門、品質保証部門、営業部門などです。商品仕様、表現の妥当性、権利関係、品質表示、顧客への伝わり方などを確認します。
Informedは、営業担当者、カスタマーサポート部門、代理店担当者などです。完成した資料や使用開始日を共有します。
また、「価格を決定する」というタスクでは、Responsibleは商品企画担当者、Accountableは事業責任者、Consultedは営業部門、経理部門、マーケティング部門、Informedは営業現場や販売代理店になることがあります。
新商品発売では、関係部署が多いため、RACIを作らないと「誰が承認したのか」「どの部署に確認したのか」が曖昧になりやすくなります。
RACIで役割を整理しておけば、発売直前の手戻りや確認漏れを減らしやすくなります。
具体例でわかるポイント
RACIの具体例からわかるポイントは、次の通りです。
・実行する人と最終責任者は違う場合がある
・相談すべき人と情報共有だけでよい人は分けて考える
・Accountableを明確にすると意思決定が速くなる
・Consultedを整理すると確認漏れを防ぎやすい
・Informedを整理すると「聞いていない」を減らせる
・複数部署が関わる仕事ほどRACIが効果的
RACIは、単に担当者を決めるだけではなく、仕事の責任とコミュニケーションの流れを整理するためのフレームワークです。
RACIを使うメリット
RACIを使う最大のメリットは、役割分担の曖昧さを減らせることです。
仕事が止まる原因は、作業量の多さだけではありません。「誰が決めるのか分からない」「誰に確認すればよいのか分からない」「誰も自分の担当だと思っていない」という状態も、プロジェクトを遅らせる大きな原因です。
RACIを使うメリットは次の通りです。
・担当者が明確になる
・最終責任者が明確になる
・承認プロセスが分かりやすくなる
・相談先が整理される
・情報共有先が明確になる
・責任の押し付け合いを防げる
・意思決定が速くなる
・会議後のアクションが明確になる
・部署間の認識ズレを減らせる
・プロジェクトの停滞を防ぎやすい
特に実務で大きいのは、会議後の行動が明確になることです。
会議で多くの議論をしても、「誰がやるのか」「誰が承認するのか」が決まっていなければ、仕事は進みません。RACIを使うと、議論した内容を具体的な役割分担に落とし込めます。
また、RACIは上司や関係者への説明にも使えます。「このタスクはAさんが実行し、B部長が最終責任を持ち、法務に相談し、営業部門に共有します」と説明できれば、プロジェクトの信頼感が高まります。
RACIを使うときの注意点
RACIは便利なフレームワークですが、使い方を間違えると、かえって仕事が複雑になることがあります。
まず注意したいのは、全員を関係者に入れすぎないことです。関係者を多く入れるほど安心に見えますが、承認や相談が増えすぎると、仕事が進みにくくなります。
特に、Consultedを増やしすぎると、意見調整に時間がかかります。本当に相談が必要な人と、情報共有だけでよい人を分けることが大切です。
よくある失敗例は次の通りです。
・Accountableが複数いて最終責任者が曖昧になる
・Responsibleが決まっておらず誰も作業しない
・Consultedが多すぎて確認に時間がかかる
・Informedで十分な人まで承認者にしてしまう
・役職者ばかり入れて実務担当者が抜ける
・RACIを作っただけで関係者に共有しない
・実際の業務フローと合っていない
・途中で変更があっても更新しない
・タスクが大きすぎて役割分担が曖昧になる
・責任を押し付ける道具として使ってしまう
RACIは、人を責めるためのものではありません。仕事を進めやすくするために、役割と責任を見える化する道具です。
また、RACIを作るときは、関係者と合意しておくことが重要です。表の中で勝手に誰かをResponsibleやAccountableにしても、本人が認識していなければ意味がありません。
関連フレームワークとの違い
RACIと似た場面で使われるフレームワークはいくつかあります。それぞれの違いを理解しておくと、プロジェクト管理で使い分けしやすくなります。
WBSとの違い
WBSは、Work Breakdown Structureの略で、作業を分解するためのフレームワークです。
WBSが「何をやるか」を整理するものだとすれば、RACIは「誰がどの役割を担うか」を整理するものです。
実務では、まずWBSでタスクを洗い出し、その後にRACIで各タスクの役割分担を決める流れがよく使われます。
つまり、WBSは作業の整理、RACIは責任の整理に強いフレームワークです。
OBSとの違い
OBSは、Organization Breakdown Structureの略で、プロジェクトに関わる組織や担当部門を整理するフレームワークです。
OBSが「どの組織が関わるか」を整理するのに対して、RACIは「各タスクに対して、その組織や人がどの役割を持つか」を整理します。
たとえば、OBSでは「法務部門」「営業部門」「品質保証部門」と整理します。RACIでは、「販促資料作成において、法務部門はConsulted、営業部門はInformed、品質保証部門はConsulted」といった形で役割を割り当てます。
OBSは関係者の地図、RACIは役割分担表と考えると分かりやすいです。
ガントチャートとの違い
ガントチャートは、タスクを時系列で並べてスケジュールを管理するためのツールです。
RACIは「誰がどの役割を担うか」を整理しますが、ガントチャートは「いつ作業するか」を整理します。
たとえば、RACIで「資料作成のResponsibleはAさん」と決めても、いつ作業を始めていつ終えるかはガントチャートなどで管理する必要があります。
RACIは責任の見える化、ガントチャートは時間軸の見える化です。
ステークホルダー分析との違い
ステークホルダー分析は、関係者の影響力、関心度、期待、不安、利害関係などを整理するフレームワークです。
RACIはタスクに対する役割を整理します。一方、ステークホルダー分析は、関係者との向き合い方やコミュニケーション方針を考えるために使います。
たとえば、ある部門がプロジェクトに強い影響力を持っている場合、ステークホルダー分析ではその部門との関係性を詳しく考えます。RACIでは、その部門をConsultedやInformedとして位置づけることがあります。
ステークホルダー分析は関係者理解、RACIは役割分担に強いフレームワークです。
RAIDログとの違い
RAIDログは、リスク、前提、課題、依存関係を管理するためのフレームワークです。
RACIは、誰が何を担うかを整理します。一方、RAIDログは、プロジェクト進行上の不確実性や問題を管理します。
たとえば、RACIで「外部ベンダーがResponsible」と整理したタスクについて、納期遅延の可能性がある場合、そのリスクはRAIDログで管理します。
RACIは責任の整理、RAIDログはリスクや課題の整理に向いています。
RACIはどんな場面で使うと効果的か
RACIは、関係者が多く、役割分担が曖昧になりやすい場面で効果を発揮します。
逆に、一人で完結する小さな作業や、担当者が明確な定型業務では、わざわざRACIを作る必要はあまりありません。RACIは、複数人が関わる仕事でこそ価値があります。
RACIが効果的な場面は次の通りです。
・新商品開発
・新規事業の立ち上げ
・社内システム導入
・業務改善プロジェクト
・組織改革や制度変更
・社内研修の企画運営
・展示会やイベント運営
・営業キャンペーン
・Webサイト制作
・外部ベンダーとの共同プロジェクト
・品質改善活動
・コンプライアンス対応
・複数部署が関わる資料作成や承認業務
特に、「誰が決めるのか」「誰に相談するのか」「誰に共有するのか」が曖昧な仕事では、RACIを使う価値があります。
また、プロジェクト開始時だけでなく、途中で混乱が起きたときにもRACIは役立ちます。責任分担が曖昧になっているタスクを洗い出し、改めてRACIで整理すると、プロジェクトを立て直しやすくなります。
まとめ
RACIは、タスクごとの役割と責任を明確にするためのフレームワークです。
プロジェクトやチーム業務では、作業内容だけでなく、「誰が実行するのか」「誰が最終責任を持つのか」「誰に相談するのか」「誰に情報共有するのか」を明確にすることが重要です。ここが曖昧なままだと、確認漏れ、承認遅れ、責任の押し付け合い、情報共有不足が起こりやすくなります。
RACIを使えば、Responsible、Accountable、Consulted、Informedの4つの役割で関係者を整理できます。特に、Accountableを明確にすることで、意思決定が速くなり、プロジェクトの停滞を防ぎやすくなります。
最初からすべてのタスクに細かくRACIを作る必要はありません。まずは、重要なタスクやトラブルが起きやすいタスクだけを選び、誰が実行し、誰が責任を持ち、誰に相談し、誰に共有するのかを書き出してみましょう。
今日進めている仕事の中から重要なタスクを一つ選び、Responsible、Accountable、Consulted、Informedをそれぞれ書き出してみてください。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
WBSとは？初心者向けに意味・使い方・具体例をやさしく解説
OBSとは？初心者向けに意味・使い方・具体例をやさしく解説
ステークホルダー分析とは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
プロジェクト管理で使えるフレームワークまとめ｜初心者向けに種類・使い分け・活用例を解説
