ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

RACIマトリクスを使ってスクラムでの責任分担を見える化する

こんにちは。@ryuzeeです。

開発プロジェクトを進めるときには、ご存知の通り多くの人が関わります。一方で以前から何度か書いているようにいきなり人が集まっただけの段階だと、まだ組織やチームとしてはうまく機能せずさまざまな混乱が起こることになります。

たとえばスクラムを採用した場合で、かつスクラムに関する経験があまりない状況の場合、それぞれが持つロールを十分に果たせなかったり、そもそもどんな責任を持つべきなのかも分からずに声の大きい人の言いなりになったり、上司や外部からのコントロールを受けすぎてしまったりといった混乱も起こります。

そこで、初期の形成期や混乱期を早めに終わらせるために、それぞれの役割が持つ責任を見える化するのをお勧めします。(混乱した現場でこれをやると、想像以上に全員の認識が違うことがよく分かります

以下の表はRACI(レイシー)マトリクスと呼ばれるものです。縦軸にタスクを列挙し、横軸には登場人物(ロール)を入れます。セルの中のそれぞれのアルファベットは以下の意味を持ちます。

  • R: 実行責任者(Responsble): 実際にタスクを実行する人。複数人いるかもしれませんし、1つのロールに限定されないかもしれません
  • A: 説明責任者(Accountable): タスクの成果に対して責任を持つ人。承認者とも言えます。通常は1つのタスクに対して1人または1ロールになります
  • C: 協業先(Consulted): 作業に関する知識を持っていて要請に応じて意見やアドバイスを提供します
  • I: 報告先(Informed): 結果や進捗について報告を受ける立場です

この定義にさらに以下のような項目を追加することもあります。

  • F: ファシリテーター(Facilitator): 生産的であるように議論や行動をファシリテーションする
  • V: 検証者(Verifies): タスクの完了をなんらかの定義や基準にあわせて検証する
  • S: サポート(Supportive): タスクの実行において補助的な役割を果たす

あまり細かく定義しすぎると混乱するので、ここではスクラムの特性にあわせてFだけ追加した例になっています。

なお、プロジェクトの最初のうちに見える化しておくと良いと思いますが、一度作れば終わりではありません。 チームの成長度合いや能力によって、場合によってはどんどん権限を委譲していくことも普通にあります。 また組織の事情にあわせて異なる役割分担に変えざるを得ないケースや新たなタスクが増えたりもします。

また、このマトリクスは、「それ俺の仕事じゃないしー(It’s not my business…)」というための道具ではありません。 責任を持つべき人がタスクを進めないからといって、放置しておいて良いわけはないので念のため。

RACI(レイシー)マトリクスの例(スクラムの場合)

RACI(レイシー)マトリクスチームメンバープロダクトオーナースクラムマスターマネージャーアーキテクト
プロダクトのビジョンやゴールIR/AIIC
プロダクトに関する予算の算出CR/AICC
プロダクトに関する予算の確保IR/AIII
プロダクトに関するリスクの管理CR/AFIC
プロダクトの全体アーキテクチャの設計CAFCR
プロダクトに必要な人のアサインCIIR/AC
プロダクトバックログ優先順位付けと手入れCR/ACIC
プロダクトバックログアイテムの作成CR/AFIC
プロダクトバックログアイテムの受け入れ基準の策定CR/AFCC
プロダクトバックログアイテムの完了の承認/否認CR/AFCC
Readyの定義の作成と改善RCFCC
受け入れテストの作成と実行RAFIC
スクラムがうまくいくようにするCCRAI
スクラムチーム全体を改善するRRRAI
妨害の除去RCFR/AR
スプリントで実施するプロダクトバックログアイテムの選定CR/AFIC
スプリントで実施する量の決定R/ACFIC
スプリントで実施するタスクの洗い出しR/ACFIC
スプリントでの割り込みの受け入れ可否の決定R/ACCIC
デイリースクラムR/AIFII
スプリントレビューRAFII
スプリントレトロスペクティブR/ARFII
完成の定義の作成と改善RCFCC
コーディング規約の作成RIICR/A
ユニットテストの作成RIIIR/A
ツールの選択と運用RIICR/A
プロダクトの品質の保証RAFCC
プロダクトの実運用RAFCC
プロダクトの終了IR/AICI

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 【続編:64MB超え】AzureのBlobサービスにブラウザから直接ファイルをアップロードする
次の記事 採用とか退職とか評価に関するよもやま話

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World