はじめに
普段業務を進める上で、以下のような不満をもったことはないでしょうか？
- サービス運営やプロジェクト進行について指示する人が複数いて現場が混乱する
- メンバー間で支持する設計手法や開発手法がバラバラで統率が取れない
- プロダクトオーナーがタスクを抱え込み過ぎて、ボトルネックになってしまっている
こういった問題は、適切な権限委譲と責任分担である程度解決できます。そして、権限委譲と責任分担を行う際に役立つのがRACIです。
RACIとは
RACIは、各業務内容における役割毎の責任分界点を可視化する思考フレームワークの一つです。責任範囲を、Responsble、Accountable、Consulted、Informedで定義することから、RACIと呼ばれています。
Responsble、Accountable、Consulted、Informedのそれぞれの意味は以下の通りです。
- Responsble (実行責任者): 実際にタスクをこなす人
- Accountable (説明責任者): 成果に対して責任を取る人
- Consulted (協業先): 報・連・相の相を行う対象
- Informed (報告先): 報・連・相の報・連を行う対象
RACIでは、業務内容と役割からなる表にR・A・C・Iを埋めることで、どの役割がどういった権限と責任を持っているのかを可視化します。以下は、RACIマトリクスの例です。
| 業務内容 | エンジニア | アーキテクト | スクラムマスター | プロダクトオーナー | マネージャー |
|---|---|---|---|---|---|
| プロダクトのKGI/KPI設定 | I | C | I | R/A | C |
| プロダクトのアーキテクチャ設計 | I | R/A | C | ||
| タスクチケットの管理 | I | R | A | I | |
| コーディング | R/A | C | I | ||
| ... |
| 役割 | 担当者 |
|---|---|
| エンジニア | Aさん、Bさん、Cさん |
| アーキテクト | Bさん |
| スクラムマスター | Dさん |
| プロダクトオーナー | Eさん |
| マネージャー | Fさん |
RACIの運用ノウハウ
RACIの詳細は他のブログでも丁寧に紹介されていますが、実際に運用した際によく起こる問題の解説はあまりありません。以下では、RACIを初めて運用する人が陥りやすい問題と簡単な解決アプローチをまとめています。
Aを複数の役割に割り当てない
1行にAが2つ以上でてきた場合、組織構成に問題があると思ってください。目標設定に関する業務でマネージャーとプロダクトオーナーの両方にAがついていたり、技術選定に関する業務でプロダクトオーナーとアーキテクトの両方にAがついていたりするのは起こりがちです。
1行にAが複数あるということは、いい成果が得られた際には成果の奪いあいに、問題が起こった際には責任のなすりつけあいになるということです。
特定の役割にAを集中させない
権限委譲や責任分担に頓着しない組織では、Aがプロダクトオーナーやマネージャーに集中しがちです。「メンバーにAを割り当てるなんて怖くてできない！」というのも尤もではあるのですが、Aが集中しすぎると、その人がボトルネックになって業務の停滞を招きます。
例えば、稟議の最終承認者が、全部社長になっていたりすると稟議が中々通らずヤキモキしますよね？そういった場合、組織を細かく分割し、プロダクトやプロジェクトの規模によって最終承認者をわけるわけですが、RACIでも同じことを行えばいいわけです。RACIマトリクスで定義された業務内容を怖いと思わなくなるまで細分化し、できる範囲から権限委譲していきましょう。
特定の役割・人にRを集中させない
特定の役割や人に、Rが集中している場合、その役割や人に過負荷がかかっている可能性があります。
Rは実際にタスクをこなす人なので、その役割や人ができる範囲でしかRをつけてはいけません。業務内容や役割を見直すか、人を増やすなどして、実働部隊の負荷が集中しないようにしましょう。
Cが多すぎないかを確認する
相談先が多いということは悪いことではないですが、Cが多いということは、それだけコミュニケーションコストがかかるということです。MTGばかりしているなと思った場合は、Cが多すぎないか確認してみましょう。
プロダクトやプロジェクトの内容によっては仕方ない部分もありますが、必要以上にプロダクトやプロジェクトのスコープが大きい可能性があります。
by nameで権限を割り当てない
RACIマトリクスを作る際には、名前でなく役割を使ってください。by nameで権限を割り振ると、「自分自身が偉くなった」と勘違いする可能性が高まります。アジャイルソフトウェア開発でも述べられていますが、ソフトウェア開発において誰が上・下ということはありません。お互いに割り当てられた役割（ロール）があり、それに則って、職務を遂行するというだけです。
役割に権限と責任が紐付いていて、その責任の重さなどによって給与に差が生まれます。by nameにすると、それが見えにくくなり、人事マネジメントが、難しくなるという問題があります。
役割と人が1対1であっても、役割を使い。役割に権限と責任、求められるスキルセットを定義するようにしましょう。
RACIマトリクスに書いてある以上のことが行われていないかを監督する
I（報告を受けた人）が口を出すとか、C（相談先）が作業に加わってしまうとか、R（タスクをこなした人）が責任をなすりつけられるということは、よく起こることです。常にRACIマトリクス通りにすることを強制することは、息苦しさを感じさせるのですべきではないですが、徐々に侵食され定常化してしまうとRACIマトリクスの意味がありません。
RACIマトリクスの実効性が薄れてきたと思ったタイミングで、関係者と相談して情報をアップデートし、あらためて権限委譲と責任分担を行う必要があります。RACIマトリクスは一度作ったら終わりというものではなく、逐次アップデートする必要があります。
おわりに
RACIは、非常に優秀な思考フレームワークですが、こういった思考フレームワークの導入になれていない組織からすると、運用する上で様々な問題が起こります。今回は、私が現時点で発見した運用ノウハウをまとめましたが、これからも運用していく中でなにか気づきがあった場合は更新していきたいと思います。
「はじめに」で書いた問題に不満を抱えた人の参考になれば幸いです。