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

 2016/02/10

こんにちは。@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
 2016/02/10

サイト内検索


著作

寄稿

Latest post: