bon now

役割ってなんだっけなーと最近改めて考えた。個人的にはティール型組織やホラクラシー組織とかに興味があったのできっちりかっちりした役割って本来不要なんじゃないかっていう仮説は持っていたけど、どうもそうじゃないらしい。

実際にここ数年でこの概念が覆った事例みたいなのを僕の経験をまとめてみる。

生産性が良い≠プロダクトに良い作用がある

最初に僕の考える「プロダクト」について定義しておく。
僕の言う「プロダクト」には、エンジニアが作るソフトウェア・インフラも含まれているし、メンバー全員の仕事も含まれる。ユーザーの使い心地や機能性とかも含まれる。そしてチーム(組織)もプロダクトの1つのファンクション(機能)として含まれている。これ大事。

最近分かったこととしては、あたりまではあるがチーム(あるいは個人)の生産性が高くともプロダクトに良い作用してるよねっていう指標になるかどうかは別ということ。

例えば1週間でリリースできた課題数が10だったときと1だったときを考えてみる。
普通に考えると課題数=10のほうが遥かにプロダクト成長に寄与しているようにみえる。

しかし、課題を10個こなすために多くのメンバーが残業過多、やっつけ仕事からくるリファクタバグ修正、曖昧な要件に対する長時間議論など多くの犠牲を払っていた場合、減点方式だろうが加点方式だろうがプロダクトに良い作用はないに等しい。そう考えると、実はたった1つの課題数(しかもちょっとした文言の言い回し修正程度)のほうが実はプロダクトに良い作用を与えているといえる可能性がある。

プロダクトにおける役割とは

ということで生産性が良く、かつプロダクトに良い開発って一体なんだろうか。それを解決するために考えるものの1つが「役割」かなと思ってる。

よく「役割が被ってて誰がどういう権限を持ってるか分からん、誰に聞けばええねん」とか「役割が不明瞭でこぼれ落ちたタスク拾うのはいつも特定の人」とかいう問題が起きているのをTwitterでもみかける。

冒頭に述べたとおり、このあたりは「役割なんていらねぇ」と思ってたんだけど、それだとやっぱりツラいことのほうが多いなと感じることが多かった。そのもっともな理由が 「で、誰が決めるの？」 だ。

つまり、プロダクトにおける役割は最低限「俺が決める（どん！」というこれだけでOKなんじゃないだろうか。