チーム内の役割分担で悩んだって経験、皆さん一度や二度じゃないのではないでしょうか。個人的には、組織で働く上で永遠の課題の一つだと思ってます。案件終了後の振返りで「チーム内の役割分担を明確にしとくべきだった」を何度聞いたことか……。

少し前から社内で「RACI図」というフレームワークを聞くようになり、とっつきづらくてずっと食わず嫌いしてたのですが(すみません)、この前はじめて実案件で使ってみました。

結果、「学習&説明コストは高いけど、案件初期にこれが出来ると強い」と感じてます。まだ活用回数が少なかったり長期運用/改善していなかったりで本質理解までは至ってないですが、とりあえずのさるわか的コンテンツを作って初期学習コストを下げることに貢献できれば幸いです。

RACI(レイシー)図とは何か

一言でいうと、「あるタスクにおける役割を4種類に定義しよう」というフレームワークです。「このタスクは誰が担当」って定義することはよくありますが、その「担当」だけでは不十分で、報告対象など関与する人も含めるともう少し解像度を高める必要があります。

関わりが薄い人も含めて、誰がどれくらい関与するのかを可視化できるのがRACI図の良いところです。

「RACI」とは役割の頭文字で、以下4種類を指します。

R(Responsible)：実行責任者。手を動かす人
A(Accountable)：説明責任者。進捗報告する人
C(Consulted)：協業先。相談に乗る人
I(Informed)：報告先。進捗報告受ける人

R(Responsible)
実際に手を動かす人。事態が停滞していると、この人が主体的に原因を探りに行く。いわゆる主体者なので、責任分担上、各タスクに1人しか設定しない。エンジニア/デザイナー/ディレクターであることが多い。

A(Accountable)
進捗報告など説明する責任を持つ人。状況把握してないとIからキレられる傾向にある。Rを兼ねることも多い。ディレクター/プロジェクトマネジャーが多い

C(Consulted)
何か知見を持ってて、Rから相談を受けて一緒に考える人。基本的にCが原因では停滞しない。タスクによっては、割とどの職種でも該当しうる。

I(Informed)
Aから説明を受け、大局が問題ないかを判断する人。基本的には動かず、説明が無いとキレる人。受託でいうとお客さんの担当者、自社開発でいうと組織のマネジャーとかでしょうか。

それぞれのポジションが分かったところで、関係性を図式化します。

図にすると簡単で、「ある機能を開発する」とした時に…

1.エンジニアが実装する(R)
2.ディレクターが進捗報告する(A)
3.お客さんorマネジャーが報告を聞く(I)
4.実装に詰まったら社内のつよつよエンジニアが相談に乗る(C)

という流れになります。基本はR→A→Iで、たまにCが出現する構造です。

どう役立つか

案件を進めていて、どうしてもお見合い状況になったり、バッティングしちゃうことってあると思います。それによってチームメンバーに対して不要なヘイトを溜めてしまったり……ｳｯ頭が

そこでRACI図を使って、以下のような議題が出て来るので、メンバー各位で共通認識持つための話し合いが出来ます。

・誰がメイン(R)で、誰がサブ(C)か
・誰に状況共有しておかないといけないか(R→A)
・主体者と説明責任者同じか(R＝A,R≠A)
・知見者がアサインされてるが、どうすれば良いか(Cの定義)

これが案件初期に会話出来るだけでも、相当スムーズになると個人的には思います。

どうやって作り始めたら良いか

いざ作り始めるとなると、結構手が動かしづらかったりします。作り方の手順は諸説あるようなのですが、個人的にやりやすかったものを紹介します。

・想定されるタスクを洗い出す(1人じゃなくてもOK)
・R(実行者)を各タスクに1人設定する
・R→A(説明者)なのかR＝Aかを判断する。
・I(報告先)を配置する
・Cを配置する

使用例

そうして作ったものが以下のものです。ある事業会社のサービス運用保守案件をWeb制作会社が受託するシチュエーションです。
※R/Aとは、ある人物がRとAを兼ねることを意味します

ここで分かることは、

・お客さんは基本的に報告者(I)で、企画検討の蹴り出しが主務
・プロジェクトマネジャーは、何かあった時の火消し役として鎮座する
・チームの人数が少ないため、主体者が説明者を兼ねる(R=A)
・エンジニアリーダーの主務はコードレビュー
・こぼれタスクは、ディレクターが主体で各位に相談しつつ進める

といった感じです。
RACI図自体が目的というよりは、どちらかというとRACI図叩き台として結成直後のチーム(ここ重要)で役割分担の共通認識が持てることに大きな意味があります。

おわりに

参考になりましたでしょうか。

上記のケースでは小規模チームの運用保守がモデルでしたが、もっと大きなチーム/プロジェクトでこそ効果を発揮するものだと思います。お客さんとベンダーの役割分担をするにも使えそうですね。

個人的にも、こういった運用を初めてトライ＆エラーを繰り返している身なので、コメントで普段から運用されている方のお話など聞ければ、とても嬉しいです。

参考記事