役割分担があいまいなプロジェクトは止まる。RACIの使い方

プロジェクトが止まる理由はいくつもありますが、意外に多いのが、役割分担があいまいなことです。誰が決めるのかが分からず判断が先送りになる。やる人が決まっていない作業が、誰の手にも渡らないまま残る。知らされるはずの人に情報が届かず、あとから「聞いていない」と言われる。どれも、役割をはっきりさせておけば防げることです。

役割を整理するための道具として広く使われているのが、RACIと呼ばれる表です。この記事では、RACIの4つの役割の意味と、表のつくり方、使うときの判断の基準、会議での決め方、よくある失敗を紹介します。

RACIの4つの役割

RACIは、作業や決めごとごとに、関わる人の役割を4つに分けて表す方法です。4つの役割の頭文字をとって、RACIと呼ばれます。

• R（Responsible）実行する人：その作業を実際に行う人。複数人いてもよい
• A（Accountable）責任を持って決める人：その作業の結果に最終的な責任を持ち、承認する人。一つの作業に一人だけ
• C（Consulted）相談される人：作業を進める前や途中で、意見を求められる人。やりとりは双方向
• I（Informed）知らされる人：進み具合や結果を知らされる人。やりとりは一方向

いちばん大事な決まりは、Aを一つの作業に一人だけにすることです。決める人が二人いると、意見が分かれたときにどちらに従えばよいのかが分からず、判断が止まります。反対に、決める人が一人もいない作業は、誰も責任を持たないまま宙に浮きます。

CとIの違い

CとIは混同されやすい役割です。Cは、意見を聞いてから進める相手で、Cの意見によって作業の中身が変わることがあります。Iは、決まったことや進み具合を伝える相手で、意見を求めることはありません。Cが多すぎると、相談に時間がかかって進みが遅くなります。Iにすればよい人までCにしていないか、確かめます。

RACI表のつくり方

1. 作業と決めごとを書き出す

表の縦に、プロジェクトの主な作業と決めごとを並べます。作業の洗い出しには、WBSを使うと抜けが減ります。WBSのつくり方はWBSの作り方を紹介した記事を参考にしてください。すべての細かな作業を並べる必要はなく、役割があいまいになりやすい作業や、大事な決めごとを中心に並べます。

2. 関わる人を並べる

表の横に、関わる人を並べます。人の名前でも、役割の名前でもかまいません。社内の人だけでなく、外部の協力会社や、決める立場の経営陣も入れておきます。

3. 役割を書き込む

作業ごとに、R・A・C・Iを書き込みます。最初にAを決めると、ほかの役割が決めやすくなります。書き込むときは、次のような作業を例に考えるとイメージしやすくなります。

• 要件を決める：Aはプロジェクトオーナー、RはPM、Cは使う部署の代表、Iは関わる全員
• デザインをつくる：Aはデザインの責任者、Rはデザイナー、CはPMと使う部署、Iは開発の担当
• 公開の判断：Aはプロジェクトオーナー、RはPM、Cは品質を確かめる担当、Iは社内の関係部署

あくまで例なので、実際の役割はプロジェクトに合わせて決めます。

4. 表を見直す

書き込んだら、表を縦と横から見直します。

• Aが一人もいない作業、Aが二人以上いる作業はないか
• Rがいない作業はないか
• 一人の人にRやAが集中しすぎていないか
• どの作業にも関わっていない人はいないか。その人は本当に関わる必要があるか
• Cが多すぎる作業はないか

一人の人にAとRが集中している場合は、その人が忙しくなったときにプロジェクト全体が止まるおそれがあります。分担を見直すか、その人の時間を確保する手当てをします。

RACIに似た表し方

RACIには、目的に合わせて役割を足した形もあります。たとえば、実行する人を手伝う「支える人（Support）」を加えたRASCIと呼ばれる形があります。はじめは4つの役割で十分です。足りないと感じたときに、役割を足すかどうかを考えます。役割を増やすほど表は細かくなりますが、そのぶん読み取りにくくもなります。

会議で決めるときの進め方

RACI表は、PMが一人でつくって配るより、関わる人を集めて一緒に決めたほうが、あとで「聞いていない」が起きにくくなります。キックオフや、プロジェクトの初めの打ち合わせで、次のように進めます。

1. PMが、作業と決めごとの一覧と、表のたたき台を用意する
2. Aの欄から順に、全員で確かめる。異論があればその場で話し合う
3. 次にRを確かめ、それぞれが引き受けられるかを本人に聞く
4. CとIは、多すぎないか、足りない人はいないかを確かめる
5. 決まった表を、全員が見られる場所に置く

本人に「引き受けられるか」を聞くことが大切です。表に名前を書くだけでは、本人が知らないうちに役割を押しつけることになり、実際には動いてもらえません。

途中で見直すタイミング

RACI表は、一度つくったら終わりではありません。プロジェクトの途中で、次のようなことが起きたら見直します。

• メンバーが入れ替わった、または新しい人が加わった
• 新しい作業や決めごとが増えた
• 計画の区切りで、次の段階に進む
• 「誰が決めるのか」で迷う場面が出てきた
• 一人の人に作業が集中して、進みが遅れ始めた

見直したら、変わった部分を関わる人に伝えます。特にAが変わったときは、新しくAになった人と、もとのAだった人の両方に、どこからが新しい人の判断になるのかをはっきり伝えます。ここがあいまいだと、二人が同じことを決めようとしたり、どちらも決めなかったりします。

定例の会議で、月に一度ほど表を画面に映して「この表のとおりに動けているか」を確かめるだけでも、ずれに早く気づけます。

使うかどうかの判断の基準

RACI表は便利ですが、すべてのプロジェクトに必要なわけではありません。次のようなときに特に役立ちます。

• 部署をまたいで、多くの人が関わるプロジェクト
• 外部の協力会社が入り、社内と社外で役割を分ける必要があるプロジェクト
• 過去に「誰が決めるのか」で揉めたことがあるチーム
• 兼務の人が多く、それぞれがどこまで関わるのかがあいまいなプロジェクト

反対に、数人で、毎日顔を合わせて進める小さなプロジェクトでは、表をつくるより、誰が決めるかだけを口頭で確かめておけば足りることもあります。大事なのは表をつくることではなく、役割があいまいなままにしないことです。

場面の例：部署をまたぐプロジェクトの場合

たとえば、営業部と開発部とサポート部が関わって、顧客向けの新しい案内の仕組みをつくるとします。進めているうちに、案内の文面を誰が最終的に決めるのかで意見が分かれ、作業が止まってしまいました。営業部は自分たちが決めるものだと思い、サポート部も自分たちが決めるものだと思っていたのです。

この場合、RACI表で、案内の文面を決める作業のAを一人に決めます。たとえば、顧客との接点に責任を持つ営業部の責任者をAにし、サポート部の担当をCにして、文面を決める前に必ず意見を聞く形にします。こうすると、両方の部署の意見を生かしながら、決める人が一人にしぼられ、判断が止まらなくなります。

よくある失敗

表をつくって終わる

最初に表をつくっても、途中で見返さなければ、実際の動きとずれていきます。人が入れ替わったときや、作業が増えたときに、表も直します。

全員をCにする

「念のため」と多くの人をCにすると、相談に時間がかかり、何も決まらなくなります。意見を聞く必要がある人だけをCにし、ほかはIにします。

Aを役職だけで決める

役職が上の人を機械的にAにすると、その人が作業の中身を知らないまま承認することになります。結果に責任を持てる人、判断に必要な情報を持っている人をAにします。

本人に伝えていない

表に名前を書いても、本人がそれを知らなければ役割は果たされません。決めた役割は、本人と確かめます。

役割をはっきりさせると、プロジェクトは止まりにくくなる

RACI表は、誰が決め、誰がやり、誰に相談し、誰に知らせるのかを、一枚で見えるようにする道具です。完ぺきな表をつくることより、決める人を一人にしぼり、関わる人と役割を確かめ合うことに価値があります。PMの役割そのものはプロジェクトマネージャー（PM）の役割とは？仕事内容を場面で解説で紹介しています。まずは、いま進めているプロジェクトで、いちばん大事な決めごとのAが誰かを確かめるところから始めてみてください。

おまかせPMは、社内に進める人がいないプロジェクトを、進める役割ごとお引き受けするサービスです。役割分担の整理から相談したいときは、どこから手をつけるかの整理から、ご相談ください。