RACIって何？わかりやすく解説

プロジェクトやチーム作業をしていて「誰が何をする人なのか、よくわからない」「報告は誰にするの？」って困ったことありませんか？そういう時に役立つのが、今から説明するRACIという考え方です。これは仕事を進める時に「このタスクについて、Aさんはこの役割、Bさんはこの役割」って決めておくもので、チームの中での役割を明確にするんです。この記事を読めば、RACI表を見た時に「あ、この人はこういう役割なんだ」ってすぐにわかるようになりますよ。

いい質問だね。RACIっていうのは、四つの英語の頭文字を取った言葉なんだ。Respondible（責任を持ってやる人）、Accountable（最終的に責任を取る人）、Consulted（意見を聞く人）、Informed（報告を受ける人）の4つだよ。つまり、プロジェクトのそれぞれのタスクについて「誰がどの役割か」を決めておく枠組みなんだ。

例えば、学校で文化祭の出し物を企画するとしよう。「出し物の企画を決める」というタスクがあったとする。その時に、Aさんが企画案を出すのが「Responsible」（実行する人）。Bさんがその企画案で本当にいいかどうか最終判断して、何か問題があった時に「これはうちの責任です」って言う人が「Accountable」（責任を取る人）。Cさんやその他の子たちに「この企画、どう思う？」って意見を聞くのが「Consulted」（相談する人）。そして先生に「こういう企画に決まりました」って報告するのが「Informed」（報告を受ける人）。こんな感じで、一つのタスクに対して4つの役割が決まるんだ。

いいところに気づいたね。実は一つのタスクに4つの人が必ずいるわけじゃないんだ。例えば「Responsible」と「Accountable」は同じ人が担当することもあるし、「Consulted」が複数人いることもあれば、誰も意見を聞かないこともある。ただ、大事なのは「Accountable（責任を取る人）は必ず一人に決める」ということ。そうしないと、何か問題が起きた時に「あの人の責任でしょ」「いや、俺の責任じゃない」みたいなことになってしまうからね。

もうちょっと詳しく

RACIというのは、昔から使われているラシ・マトリックス（つまり、誰がどんな役割かを表にまとめたもの）と呼ばれる管理方法の基本になっています。大きな会社のプロジェクトだけじゃなくて、学校の委員会活動や友だち同士で何かを企画する時でも使える考え方です。特に「複数の人が関わるタスク」で大事になってきます。一人でできる作業だったら「自分がやる」で終わりますけど、複数の人が関わる時には「あの人は何をする人？」という疑問が生まれやすいんです。その時にRACIを決めておくと、みんなが「あ、こういう時は俺がやればいいんだ」「ここは報告の対象か」みたいに素早く判断できるようになるんですよ。

⚠️ よくある勘違い

[toc]

RACIってそもそも何なの？

RACIは4つの役割の頭文字

RACIという言葉を初めて聞くと、何か難しいイメージを持つかもしれませんね。でも実は、シンプルな考え方なんです。RACIっていうのは、4つの英語の頭文字を集めたもので、それぞれ違う役割を表しています。R、A、C、I。この4文字を見ると「何の役割を表しているんだろう」って思うかもしれませんが、中身を知ると「あ、この人たちの関係性をまとめたものなんだ」って理解できますよ。

まず、R（Responsible＝実行責任者）というのは、実際にそのタスクをやる人のことです。例えば、プレゼンテーション資料を作るというタスクがあったら、その資料を実際に作るのがResponsibleです。手を動かす人、といえばわかりやすいですね。次にA（Accountable＝説明責任者）というのは、そのタスクについて最終的に責任を取る人です。「このプロジェクトがうまくいきました」「失敗しました」「納期が遅れました」という時に「それは俺の責任だ」って言える人のことですね。

C（Consulted＝相談相手）というのは、タスクを進める時に「ちょっと意見をください」「これでいいですか？」って聞く人たちのことです。つまり、実行する前に相談を受ける人。最後にI（Informed＝報告対象者）というのは、そのタスクがどうなったかという報告を受ける人たちです。やり方は聞かれないけど、結果は知りたいっていう人たちですね。

この4つの役割をそれぞれのタスクで決めておくと、チーム全体が「あ、このタスクについてはこの人がやるんだ」「報告はこの人にするんだ」みたいにすぐに判断できるようになるんです。

日本語では「ラシ表」とも呼ばれる

RACIのことを「ラシ表」とか「ラシ・マトリックス」と呼ぶこともあります。「ラシ」というのは、RACIの発音から来ているんですね。つまり「RACI表」も「ラシ表」も同じもの、という理解で大丈夫です。仕事の現場では「ラシ表を作りましょう」みたいに使われることが多いので、この言い方も覚えておくといいですよ。

RACIは1950年代にアメリカで開発された考え方で、それ以来、大企業から小さなプロジェクトまで、いろいろな場面で使われています。日本でも、特に大きなプロジェクトを動かす企業では「プロジェクト管理の基本」として学ぶことが多いです。でも、何も仕事の現場だけに限った話じゃなくて、学校の委員会活動や文化祭の準備、サークルの企画運営なんかでも役立つ考え方なんです。

RACIの4つの役割をくわしく知ろう

Responsible（実行責任者）の役割

Responsibleというのは、そのタスクを実際に進める人です。文章を書く、企画案を出す、データを分析する、資料を作る……こういった「実行」を担当する人ですね。ただ、注意しておきたいのは「実行する人」と「責任を取る人」は別だということです。Responsibleは「やる人」であって「責任を取る人」ではないんです。

例えば、新しいアイデアを考えるというタスクで、部下のAさんがResponsibleで、部長がAccountableだとしましょう。Aさんが良いアイデアを思いついた場合「Aさん、いいアイデアが出たね」って褒められます。でも、Aさんが思いついたアイデアが失敗してしまった場合、責任を取るのはAccountableの部長なんです。「部長のチーム全体の成果が悪かった」という感じで評価されるわけですね。これがResponsibleとAccountableの大きな違いです。

Responsibleは複数いることもあります。例えば「Webサイトのデザイン」というタスクで、グラフィックデザイナーとWebエンジニアの両方がResponsibleになることもあります。つまり「このタスクは複数の人で進める」という場合のことですね。

Accountable（説明責任者）の役割

Accountableは「最終的に責任を取る人」です。これがRACIの中でもっとも重要な役割だと言ってもいいですね。なぜなら「何か問題があった時に、誰に言えばいいのか」という疑問に答えるのがAccountableだからです。

イメージとしては「その仕事の親玉」という感じですね。例えば、学校で文化祭の出し物を企画するとしましょう。出し物の企画案を出すのはAさんかもしれません（Responsible）。でも「その企画が実現できるかどうか」「予算は大丈夫か」「安全上の問題はないか」という判断をして、最終的に「この企画で行きます」って決断するのはBさんだとします。その時のBさんがAccountableです。

そして大事なポイントがもう一つ。Accountableは必ず一人でなければなりません。複数の人がAccountableになると「あ、失敗した。誰の責任ですか？」って時に「あいつのせいだ」「いや、こっちのせいだ」みたいになってしまうんです。だから、RACIを決める時は「Accountableは誰か」を最初に決めるのが基本なんですよ。

Consulted（相談相手）の役割

Consultedっていうのは「相談される人」ですね。つまり、タスクを実行する前に「ちょっとあなたの意見をください」って聞かれる人のことです。専門知識がある人、経験が豊富な人、影響を受ける立場の人……こういった人たちがConsultedになることが多いです。

例えば「新しい営業戦略を決める」というタスクだったら、過去に営業をやっていた人、営業のデータをよく知ってる人、営業チームの一線で働いている人なんかにConsultedとして「この戦略、どう思いますか？」って相談することが多いですね。もちろん、その人たちの意見を聞いて「よし、じゃあこれで進もう」って決めるのはAccountableの人です。だから「Consultedの人たちの意見は聞くけど、最終判断はAccountableがする」という感じです。

Consultedは複数いることがほとんどです。一つのタスクについて、いろいろな角度から意見をもらいたいからですね。「営業の人、企画の人、管理職の人」みたいに、いろいろな立場の人にConsultedになってもらって、いろいろな視点から意見をもらう。そうすることで「あ、こんな問題があるんだ」「こういう見方もあるんだ」っていう気づきが生まれるんです。

Informed（報告対象者）の役割

Informedっていうのは「報告を受ける人」です。つまり「その仕事がどうなったのか」「完了しました」「こういう結果になりました」という報告をもらう人たちのことですね。意見を聞かれることはないし、意思決定にも関わらない。ただ「こういう結果になったよ」という報告をもらう立場です。

例えば、会社の経営陣がInformedになることがあります。細かい営業戦略には関わらないけど「こういう戦略を導入しました」「その結果、売上が20％上がりました」という報告は知りたいわけです。あるいは、顧客が関連する仕事だったら「お客さんに報告する」という感じでCustomerがInformedになることもあります。

Informedは最も関わりが浅い立場です。だから「こいつはConsultedか、Informedか」って迷ったら「相談を受ける必要があるか」「決定に影響を与えるべき人か」って考えればいいんですよ。「相談を受ける」なら Consulted、「報告だけ受ければいい」なら Informed という感じで決めます。

なぜRACIが必要なのか

役割が不明確だと混乱が生まれる

RACIを使わずにプロジェクトを進めると、どんなことが起きるか想像できますか？例えば「新商品の企画」というタスクがあったとしましょう。複数の人がこのタスクに関わっています。企画部のAさん、営業部のBさん、製造部のCさん、経営陣のD さん。

最初は良くても、進めていく中で「あれ、誰が最終判断するんだっけ？」「あ、Bさんに報告し忘れた」「Cさんはこの件について知ってたっけ？」みたいな問題が生まれるんです。特に「失敗した時」「やり直しになった時」「納期が遅れた時」というピンチの時に「あ、誰が責任を取るんですか？」みたいなことになってしまう。そんな時にRACIを最初に決めておくと「あ、このタスクはAさんがAccountableなんだ。だからAさんに報告しよう」「BさんはConsultedだから意見をもらおう」みたいに、すぐに判断できるわけです。

コミュニケーションがスムーズになる

RACIを決めておくと、報告書やメール、会議の時に「何を誰に言えばいいのか」が明確になります。例えば「プロジェクトが遅れそうです」という連絡をする時、RACIがなかったら「あ、誰に言えばいいんだろう」ってなってしまいます。でもRACIで「AさんはAccountable」って決まってたら「Aさんに報告しよう」って判断できるんです。

あるいは「このやり方で大丈夫ですか？」って相談したい時も「CさんはConsulted だから、Cさんに相談しよう」って判断できます。このように「何をどこに持っていくか」という判断の時間が短くなるので、全体的にコミュニケーションが効率よくなるんですね。

責任の所在が明確になる

プロジェクトが失敗した時、一番もめるのは「誰の責任ですか」という話です。何もなければ「チーム全体で頑張ろう」で済みますけど、失敗した時や誰かが評価を下げられそうになった時は「いや、俺のせいじゃない」みたいなことになりやすいんです。でも RACIで「このタスクはAさんがAccountable」って最初から決まってたら「失敗の責任はAさんにあります」って明確に決められるんです。

これは冷たいように聞こえるかもしれませんが、実は逆です。Accountableが決まっていることで「あ、こいつが最終的に責任を取るんだな。だから、このタスクについて納得のいく判断をしてくれるはずだ」って信頼が生まれるんです。つまり、責任を明確にすることで「チーム内の信頼」が深まるんですよ。

実際にRACIを使ってみよう

RACI表を作る時のポイント

では、実際にRACIを決める時は、どうすればいいのでしょうか。基本的には「ラシ表」を作ります。つまり、表の左側に「タスク」を書いて、上側に「人の名前」を書いて、その交わったところに「R」「A」「C」「I」を書き込む、という感じです。

最初に大事なのは「Accountableを最初に決める」ということですね。誰が責任を取るのか。これを最初に決めないと、後で「あ、誰が責任者ですか？」って話になってしまいます。次に「Responsibleを決める」。その Accountableの人の指示で実行する人は誰か、という感じです。

その後で「Consultedを決める」。このタスクについて意見をもらいたい人は誰か。最後に「Informedを決める」。完了の報告をする必要がある人は誰か、という感じで進めていきます。ただし、全員に「R」「A」「C」「I」が付くわけではないんです。例えば、小さなタスクだったら「Responsible と Accountable だけ」ということもあります。大事なのは「このタスクについては誰が何をするのか」が明確になることなんですよ。

例：学校の文化祭の企画で使ってみる

具体例で考えてみましょう。学校で文化祭の出し物を企画するとします。「出し物の企画案を決める」というタスクがあります。

まず、誰がAccountableか。これは「企画案を最終判断する人」ですね。文化祭の運営委員会の委員長とします。次に、誰がResponsibleか。実際に企画案を考えて出す人。これは企画に詳しいAさんやBさんとしましょう。

では、誰にConsultedするか。「この企画、実現できそうですか？」という意見をもらいたい人。例えば、学校の施設管理をしている先生、実際にやる生徒たちの中で人気の子とか。これらの人たちにConsultedにしておいて、企画案を相談します。

最後に、誰にInformedするか。「こういう企画に決まりました」という報告をする必要がある人。校長先生とか、PTA とか。これらの人たちがInformedです。こうしておくと「あ、Aさんが企画案を出す。でも最後の判断は委員長。これで大丈夫かは先生に相談。できたら校長先生に報告」みたいに、タスクの流れが明確になるんですよ。

よくあるミス「Accountableが複数いる」

RACIを決める時のよくあるミスが「Accountableを複数にしてしまう」ということです。「あ、この人の判断も大事だし、この人の判断も大事だから、2人ともAccountableにしよう」みたいな感じですね。でも、これはRACIの原則に反しています。

何か問題が起きた時に「あ、誰の責任ですか？」って言われて「Accountableが2人だから、2人とも責任です」って言ったら、絶対にもめるんです。「いや、こっちの判断が正しかった」「いや、あっちの判断がおかしかった」みたいにね。だから、Accountableは必ず一人。これはRACIを使う時の絶対ルールなんですよ。