去年の12月から今日までに7名のエンジニアが新たにジョインして開発チームはついに13名体制となりました。
開発チームの適切な人数を考える際、「ピザ2枚の法則」が有名です。
ピザ2枚でお腹いっぱいになる以上のメンバーがいると多すぎるという意味です。
ちなみに、ピザ2枚という表現だと人によって人数にばらつきが出そうですが4〜8名くらいらしいです。
開発チームはこの記事を執筆時点で13名ですが、10名を超えたあたりから下記の課題が出てきたのでチーム分割の検討を始めました。
- デイリースクラムでのツッコミコメントが減り、ただ発表する場となり形骸化してきた
- 1on1や目標・評価などマネジメントコストが高くなってきた
- チーム内で密に連携をとる人が限られてきたため、全員が全員の状況を日次で把握する必要がなくなってきた
- システムが成長し、全員がシステム全体を把握するのが難しくなってきた
チーム分割の検討
チーム分割を検討を始めましたが、タイトルの通りめちゃくちゃ悩みました。
悩みつつ、メンバーとも相談して検討を重ねて最終形に落ち着きました。
なお、開発しているプロダクトはWebプロダクトであり、フロントエンドはReact、バックエンドはRailsで作られており、リポジトリ含めて疎結合になっています。
案1 職能チーム
チームを分割する際、私が必ず守ろうと考えていた法則があります。
それが「コンウェイの法則」です。
コンウェイの法則に従うと、現状システムはフロントエンド / バックエンドで綺麗に分割できているので、そこで分けるのが良さそうです。
実際に1チームのときから内部的にはバックエンドを主に担当するメンバーとフロントエンドを主に担当するメンバーで暗に分かれていました。
ただし、この体制の場合は1つのチーム内で機能開発が完結しないという課題があります。
ほとんどの場合、機能開発をするとバックエンドとフロントエンド両方の対応が必要になります。
そのため、バックエンドとフロントエンドでチームを分けた場合、チーム間での密なコミュニケーションが必要になることを意味します。
チームを分けるときに達成したいことの一つとして「チーム間の適切なサイロ化」があります。
高頻度で連携が必要になる場合、チーム分割するメリットが薄れてしまいます。
そこで次の案を考えました。
案2 職能横断チーム
職能横断チームとは各チームにフロントエンドとバックエンドの役割を持ったメンバーを混在させたチームのことです。
チーム内に全ての職能が揃っているので、機能開発をチーム内のメンバーだけで完結させることができるようになり、チーム間の密な連携は減りますが、一方で2つのチームで同じシステムを触ることになります。
2つのチームで1つのシステムを触る場合、チーム間でコンフリクトしたり、共通部分のオーナーシップが不在になるなどの懸念ありました。
コンウェイの法則好きエンジニアの私としては1つのシステムを無策で触る状態を許容することはできないので、この案は不採用にしました。
案3 システムのドメインで分割
案2に似ているのですが、案2の場合はドメイン考慮せずに均等に分けたのに対して、案3ではプロダクトのドメインを考慮して分割を試みました。
ドメインで分ける場合、ドメインに対する開発がどれくらいあるか？によってチームの開発量が変わります。そのため、活発に開発されるドメインで分ける必要があります。
幸い、来期のロードマップを加味すると明確な注力領域が1つ見つかりました。
また、そのドメインは高い専門性が要求されることもわかりました。
そこでみんな大好き(?)チームトポロジーを参考に、この注力＆専門性が高いドメインを「コンプリケイテッド・サブシステムチーム」として切り出すことにしました。
チーム1: 専門性が高いドメインを担当(コンプリケイテッド・サブシステムチーム)
チーム2: 上記以外のドメインを担当
この案でも2つのチームで1つのシステムを触ることになるのですが、ドメインが明確に分かれていることでコンフリクトの懸念はかなり抑えられると判断しました。
また、しばらくこの体制で開発を進めてドメイン分割の妥当性が見えてきた段階で、システム自体の分割もありだと考えています(逆コンウェイ戦略)。
まとめ
チームトポロジーの受け売りですが、プロダクトやサービスの成長に合わせてチームの最適な形も変わっていくものです。
今回のチーム分割はただの通過点です。
今後、まだまだプロダクトも開発チームも成長させていくので、常に最適な形を模索し続けて、そのときそのときにあった形に変化させていきたいと思います。