Holacracy と Scrum は共存できるのか
LAPRAS株式会社では全社的にHolacracy(ホラクラシー)という組織体系を導入しています。一方で開発チームではアジャイル開発のフレームワークであるスクラムを導入して開発を進めています。ホラクラシーの思想は個々人が別々の役割を持って、各人が優先順位を決めて主体的に動いていくものである一方、スクラムはだれもがどんなバックログアイテムでもできるのが理想で、プロダクトオーナーが決めた優先順位に従って開発をしていきます。根本的に違う思想を持っているように見える2つのフレームワークが同居できるのか、運用して1年ぐらい経つのでまとめてみることにしました。
ホラクラシー組織のおさらい
ホラクラシー組織とはティール組織の一種です。より詳細な話は 代表の島田 がいくつか記事を書いているので、それを参考にしてもらうと良いです。参考になりそうなものをピックアップしてみました。
- ホラクラシー組織への誤解と本当の意味
- 純ホラクラシー組織 scoutyのホラクラシー運用法のすべて
- ホラクラシー憲法を5分で理解する
詳細は上の記事に譲るとして、今回の話に関わってくる部分に関してホラクラシーの特徴を列挙すると
- 役割(ロール)の目的や責務が明確に文書化されており、そこに人がアサインされる
- 自分の役割を全うしていく中で課題を検知し、各自が考える優先度に従って主体的に動く
- サークルのリードリンク (ヒエラルキー組織で敢えて例えるならマネージャー) はサークルメンバーに対して、強制力を持ってタスクを依頼することはできず、あくまでサークルとしての優先順位を示す役割を持っている
ということがあげられます。
スクラムとの衝突
冒頭でも書きましたが、ホラクラシーとスクラムでは考え方が異なる部分があり、どちらの思想を重視するのか判断が難しいことが多々あります。
最近社内で起きた問題だと、スクラム開発者の一人がスクラムチーム外で「データ分析」というロールにアサインされており、このデータ出して欲しい！という依頼が次々と飛んでくることで、スクラムの開発に割ける時間が減ってしまうということが発生しました。スクラム的解決であれば、外部からの邪魔から開発者を守るスクラムマスターが出ていって、「開発速度に影響が出るので依頼の頻度を下げて欲しい」だったり、開発者に対して「キミは業務時間の1割ぐらいをデータ分析に使って社内で困っている人を助けてあげて」というような解決方法を取ることができると思います。(#より適切な模範解答があれば教えて下さい！) つまり、スクラムマスターが開発者の時間をコントロール可能なわけです。
しかしホラクラシー的には、個人が優先順位を考えながら行動するので、スクラムの開発よりも依頼された分析をやる方が会社に貢献できると思えばそちらを優先するということが可能です。極端なことを言えばスクラム開発に関連しないロールに100%の時間を使って、スクラムの開発を全くしないこともルール(ホラクラシー憲法)の範囲内で合法でできてしまいます。
開発者のリソース配分について、他の企業はどうやっているのだろうと思い、海外の方がホラクラシー組織を導入している企業が多いので “Scrum with holacracy” とかでググってみたのですが、リソース配分に関しての記事はなく、参考になりませんでした。ホラクラシーのミーティングのプロセスはこうするとスクラムっぽくなるよ！というような記事は見つかったりしましたが。。
対処方法
スクラムを実施しているサークル内で問題が起きている場合
LAPRASではスクラムを実施しているWebAppサークルには これだけ多くのロール が存在しています。その一つのロールに「アプリケーション開発」ロールがあり、これがいわゆるスクラム開発者にあたるロールになっています。開発者は全員そのロールにアサインされて、それに加えてSREっぽいロールだったり、コード設計に責任をもつロールを持っています。
例えば、インフラが不安定なのでプロダクトオーナー(PO)が優先順位をつけたバックログの内容よりもインフラの整備を優先したい！という状況になったとします。ホラクラシー的な考えだと、本人が重要だと考える方のタスクに取り組むことが可能ですが、このような時にはスクラムに寄せて、課題(タスク)はすべてスクラムのバックログに載せてPOが優先順位を決めるのが良いです。チーム内の課題であればPOが容易に情報収集できる状態だと思うので、ビジネス的な優先度と開発的な優先度を適切に判断することは可能でしょう。
スクラムを実施しているサークル外で問題が起きている場合
先程上で説明したデータ分析のロールの例のように、スクラムチームの外にリソースが取られる場合です。この場合に上述のすべてをバックログアイテムにする解決方法を取ると、全然違うプロジェクトのバックログアイテムが入ってきたり、そもそも性質が違いすぎてまともに優先順位の比較ができなくなったり、カオスになります。この場合の解決方法はスクラムを実施しているサークルのリードリンク、あるいはスクラムマスターに該当する役割のロールに「スクラム開発者にアサインされているメンバーへのロールのアサイン権限」というドメインを付与するのが良さそうです。つまり従来のスクラムの思想と同じで、スクラムマスターが開発者のリソースの管理権限を持っている状態をホラクラシーのルール上で明記してあげるということになります。
ただ、この方法だとスクラム開発者はホラクラシーっぽく動くことができなくなるので、ホラクラシー組織のメリットを十分に享受できなくなりますし、「他の社員はホラクラシーっぽく主体的に動いているのに、なぜ開発者だけは上(PO)から降ってきたバックログアイテムをひたすら開発しないといけないのか…」 といった疎外感のようなものを感じてしまう可能性も少なからずあると思います。
ここまでくると、なぜ我々はそこまでしてスクラムをやりたいのかを考え直したり、会社のカルチャー的にはどっちに寄せるのが向いているのかを考えたりすべきで、必ずしもスクラムの思想でホラクラシーを上書きすることが正しくはないとも思います。
結論
タイトルの「Holacracy と Scrum は共存できるのか」の僕なりの答えは、共存可能だがその最適な線引きは組織によって違う です。今回の記事はだいぶスクラムに寄った解決方法を提案しています。
ホラクラシーに寄った解決方法だと、POがカンバンの優先順位をつけておいて、開発者はカンバンの優先順位が高いものを取るのか自分が重要だと感じている別のタスクを取るか自由に選んで良い。ということもできると思います。(この場合スクラムのVelocityのメリットを失うことになると思いますが)
うちの組織ではこうやっているよ！の事例がもっと出てくるとそれを参考にしてより良いTryができるので、もっと情報が増えるとよいなと思っています。
