チーム分割の独自ガイドライン

独断と偏見の塊

前口上

ソフトウェアプロダクトをより成長させるために開発者の人数を増やす場合、とあるタイミングでチーム構成の再編が必要になります。やっていることの幅や深さの複雑度が上がると会議やレビューをする上で、ノイズだったり、キャッチアップの量が増えたりで生産性が落ちてしまうためです。

ベロシティーを最大化して開発するためにはどういう構成をとると良いでしょうか。

ダンバー数: 大枠から捉える

ソフトウェア開発に限らず、組織運営をする上でダンバー数が一つの指標としてよくあげられます。人類学者、進化生物学者のロビン・ダンバーが提唱した概念で、安定した関係を築ける人数の上限で150人(100〜200人)がよく指標として上げられます。

人間の脳の認知能力には限界があるとして、狩猟採集社会での集団形成を分析したものです。軍隊の構成を決める上でも参考にされていると聞きます。

ダンバーが提唱したものから色々な人が解釈を足していたりするのですが、ざっくりイメージを掴むならこんな感じでしょうか。

• 5人: 家族
• 15人: 親友
• 35(30～50)人: 団(band)。友達
• 150(100〜200)人: 村(village)。特別な知り合い
• 500人: 部族(tribe)。知り合い
• 1500人: 認識できる人数の限界

会社で使うなら例えば部が35人、部門が150人、会社が500人、ホールディングスが1500人といったように組織の人数は一定の目安を元に決めた方がよいということです。

ダンバーの研究は狩猟採集社会でも十分近代としている節があるので、ITツールが発展した近代においては多少人数調整があるかもしれません。

1チーム5〜10人を目指す

そういった大枠を頭の隅に置いて置いた上で、ひとまずチーム構成を考えている集団は150人以下であるとしましょう。1チーム何人にすると良いでしょうか？

Amazonではtwo pizza rule、2枚のピザを囲む人数を基準に5〜10人で1チームとしています。スクラムガイドでも最大10人です。

Span of Control、ひとりのマネージャーが見ることができる人数は諸説あるのですが5~9人と言われています。マネージャーも足すと6人〜10人で1チームです。ある程度整合性が取れていますね。

伝統的日本企業だと部下なし課長が存在していることもありますがコンテキスト共有コストが高く生産性が悪いです。逆に急成長チームでチーム分割を先伸ばして三十人で一チームになってしまうとノイズが増えて生産性が悪くなってしまうように感じます。

1チーム5〜10人はスイートスポットで的を得ていると思います。一方でこの幅が何由来かもしっかり考える必要があります。1チームの人数を増やせるかはメンバーの自走性も大きく関わって来るからです。

メンバーが新人だけのチームは自走性の低いチームです。おそらく5人がワークする限界だと思います。逆にメンバーが全員一流ならマネージャーのやることは減り、10人でもワークするでしょう。

経験の浅いメンバーだけのチームで10人以上はより崩壊する可能性が高く、ベテラン揃いだとマネージャーは持て余してしまう可能性があるということです。two pizza ruleの上澄みだけ真似ても生産性は上がりません。

チーム整理に伴いコードも整理する

チームを整理すると共にコードも整理しましょう。というのもソフトウェア開発ではインフラやコードの境界がコミュニケーションの境界になるコンウェイの法則がよく知られているからです。

コードを整理せずにチームだけ分割しても、共有部分の変更で結局他チームとコミュニケーションが必要になってしまい中途半端な状態になってしまいます。

コンウェイの法則は意志なく流れに身を任せているとコードの境界がチームの境界になり、two pizza ruleの最適点からずれたものなってしまうことを警鐘したものとも言えます。

一般に逆コンウェイ戦略とも呼ばれるものは、意志を持ってコードやインフラを整理していくことでtwo pizza ruleのルールを外れずに生産性高いまま開発者の人数を増やせるということだと思っています。

チームのメンバーはどういうロールで構成すればよいか

チームのメンバーはどういうロールで構成すればよいかは業態によるところも大きいのですが、一つ言えるのはチーム単体で独立したスタートアップに近ければ近いほど融通が効くということです。

創業期のスタートアップや社内新規事業でよく失敗するパターンはいくつかあるのですが、一人で起業や共同創業者が多すぎると失敗しやすいと言われています。創業者がワンマンでなんでもやりすぎると潰れやすいし、共同CXOが多すぎても潰れやすい。

創業メンバーはHacker、Hustler、Hipsterの三人が必要とされることもあるのですが、IT企業において最小は何かと言われればCXOとCTOの二人創業が一番よくあるパターンなようにも思います。ここでCTOはTechnologyもEngineeringもやるのでCTEOとでもしますか。

それをベースに持って来るならすべてのチームにmini CEOたるPMとmini CTEOたるTech Manager(Technology & Engineering Manager)を置けば本来完璧なようにも思います。

一方でmini CTOができる人は希少なんですよね。管理職をやりたいエンジニアは10%程度とも聞きます。どちらというとEngineering ManagerとTech Leadを分けた組織の方が多いようには思います。Tech Managerの業務を分けたら各チームにTech Leadがいて、2チームに一人EMが入ればワークする感じでしょうか。

PMでも業務を分解してPdMとPMMに分けている会社はあります。

ぼくの考えた最強のSpotify改変モデル

チーム構成のパターンを考える上でよく引き合いに出されるのはSpotifyモデルだと思います。チーム構成をTribe, Squad、Chapter, Guildという概念で整理しています。

ただ、Spotifyは現在このモデルを使用していないようで失敗したやり方だと言われることもあります。自分の理解だとベースの部分はいいのですが、おそらくダメだったのはEMの比率とChapterの制約の部分だと思います。

CTOとVPoEの構成の会社だとVPoEが採用面接に出ていることが多いので、どれだけ採用頑張っているかにもよるのですが、前述の通りCTEOをTech LeadとEMに分けたとすると2チームに1EMがいいところだと思うんですよね。Googleの論文でManagerが必要という話もありますしSpotifyモデルだと体感EMが少なすぎるようにも思います。

もう一つはChapterの制約の部分です。Spotifyモデルだと例えばChapterやGuildが無限にスケールすることになっているようにも見えるんですがそんなことないと思います。Span of Controlの5〜9人は横方向にも効くので、やり方次第ですがそちらも一定の人数を超えたら分割が必要なように思います。

Tech Manager(プレイイングマネージャー)は本当に不要か

一般的にモダンなキャリアパスでは技術者は一定のランクになるとプレイヤーかマネージャーかの2択を迫られます。大企業ほど選んだ側の能力で評価されそのキャリアパスは不可逆なことも多いです。

一方で単一事業が頭打ちになって、新規事業に取り組む企業も増えているんですが、そういった第二創業期を迎える企業の話を聞くと、任せられる人がいないと口を揃えて言います。

スタートアップが段々とフェーズが上がって、創業期からいたフルスタックエンジニアを低評価し、単一専門性へのコンバートを推奨する一方、一周回って新規事業をやろうとするとフルスタックエンジニアがいないと嘆いたりする。そんな事象も見かけます。おそらく一昔前より新規事業を錬成しなければいけないスパンが短くなっているんだと思います。

伝統的日本企業の技術者が昇進するためのキャリアパスが管理職だけというのは確かに息が詰まるんですが、EMの役割が企業によって違うというのも聞く話なんですよね。もしEngineering ManagerとTech Leadの2択でなくよりmini CTOに近いTech Managerというロールを含めた3択にすることで上手くいくならそういうやり方をとるのも一案だと思います。