いつの間にか出来ているFeature Factory

先日のスクラム祭りでは懇親会には家庭事情で出られなかったのですが「廊下トーク」で面白い話をしました。

大きめのスタートアップの開発組織だと、ロードマップと呼ばれるガントチャート上に記述される横棒１本が表す「プロジェクト」によって駆動する、Feature Factoryになっちゃうよね、と言う話です。

じゃあなぜそうなってしまうのか？

まず先に結論となる

まずチームの数や規模がスケールしていく
→ チームはスケールするが、初期からPOとして振る舞っている人、あるいはプロジェクトなど「大きい玉」の見積を行っているCTOなどのコアの役割の人がスケールしない
→ コアの役割の人たちと各チームの接点が減ってFeature Factoryになってしまっている

こう言う流れになるという結論になりました。

まずFeature Factoryができる前の段階を見る

エンジニア組織が20人くらいでうまく回っている段階の話をしましょう。
おそらく以下のような役割の人がいると思います
・メインPdM（社長だったりその下のひとだったり）
・営業部長
・カスタマーサポート/カスタマーサクセスのリード
・メインデザイナー
・CTO（エンジニアのまとめ役）

おそらくプロダクトの方向性を決めるのはこう言う少数の役割の人だと思います。
メンバー１人１人がPdMやデザイナーと同じ権限を持って30人くらいの円卓会議で毎回プロダクトの方向性を決めるよ、と言う組織は少ないと思います。
プロダクトの方向性を決めるのは10人未満のコアな役割の人たちではないでしょうか？
そこに何の問題もありません。

ここで重要なのは「プロダクトの方向性を決めるのは10人未満のコアな役割の人々」。
この点です。

次に規模がスケールする準備を行った開発組織の話をする

しかしここで話の対象となるのは「大きめのスタートアップ」です。
ですがいきなり「大きめのスタートアップ」にはなりません。
大抵開発組織が20人になったらCTOは開発組織をスケールさせる準備を行います。

20人なら2〜4の開発チームくらいに分割した上で1チームをチームリーダーに統括させる。
その上にCTO(あるいはVPoE)がいる構造になります。

この2〜4の開発チームを統括する上でCTOは重要な役割を果たします。

• 「プロダクトの方向性を決めるのは10人未満のコアな役割の人々」の決定のインプットとなる開発プロジェクトの見積
• チーム単位に分担させるためのタスクの分割
• 開発遅延時のリソースのアロケーション（要するに他のチームから人を引き抜いて開発が遅れているチームに増員する）

開発チームとリーダーに大きな裁量はなく、ざっくり言ってしまうとCTO経由で上から降ってきたプロジェクトのスコープを納期までに完成させる社内受託となっています。
社内受託を担う開発チームに発注するのは「プロダクトの方向性を決めるのは10人未満のコアな役割の人々」であり、それをうまく分割する受託側のプロジェクトマネージャーがCTOの役割です。

この段階ではまだFeature Factory感はあまりありません。
20人の組織なら末端の開発メンバーが違和感を感じた際に、チームリーダー経由でPdMなど「プロダクトの方向性を決めるのは10人未満のコアな役割の人々」に問い合わせるのは容易です。
なぜならPdMやデザイナーはせいぜい1~3人なので、この規模なら末端のメンバーでも濃いコミュニケーションを取ることは可能です。

その次に規模がスケールした後の話をする

イメージとしてはエンジニア組織が先ほどの20人から100人に増えた後の段階です。
開発組織の人数が増えるために、20人の組織ではCTOの下に開発チームが付けられていましたが、100人の組織ならCTOの下に「部長」がいてその下に開発チームが入る形になるでしょう。

前回のCTOの下に開発チームがいた体制よりもレイヤーが増えています。
ここで問題となるのは「プロダクトの方向性を決めるのは10人未満のコアな役割の人々」から末端のメンバーや開発チームに降ってくるコミュニケーション量が減ってしまう問題です。

「2枚のピザ」を数人で分けるだけなら腹を満たすことはできるでしょう。
しかし100人となった開発チームで「2枚のピザ」を分けようとすればひとかけらしか食べられないでしょう。腹を満たすことはできません。

ではその「ひとかけら」しかないコミュニケーションで末端の開発チームを動かすにはどうすればいいでしょうか？
少ないインプットで開発チームを効率的にコントロールする方法を選ぶしかありません。
だんだんと細っていくインプットで開発チームのアウトプットをコントロールしようとすると、結果としてFeature Factoryになってしまいます。

ここまでの話をまとめる

当人たちは「うおー！俺たちはFeature Factoryを作るぞー！」と考えているチームはあまりなく、むしろ「スケールに応じて今まで成功してきたやり方をできるだけ変えずに臨機応変に少しずつカスタムしてきた」結果として「Feature Factoryができてしまった」のではないかという話でした。

かなり理解できる話だと思ったのでここでシェア