5~8人のBackendチーム編成を目指そう
こんにちは。メルペイ Backendチーム Manager of Managersの @godricです。
この記事は、Merpay Advent Calendar 2021 の25日目の記事です。
メルペイは「信用を創造して、なめらかな社会を創る」をミッションとし、与信事業を中心に黒字戦略に取り組んでいます。また、メルカリグループの新たな成長軸を模索するためのメルコインの暗号資産投資の事業、ソウゾウのメルカリShopsなど様々な新規開発が並行に走っています。どちらもメルカリグループにとって重要な事業戦略で、高い品質を保ちながら最速スピードでサービスをローンチし進化させて、市場で優位性を確保しなければなりません。
メルペイBackendチームの全員がAll for Oneで今までメルカリ、メルペイの高速な成長を支えてきましたが、技術的負債、組織的負債が溜まったことによって様々な課題が出てきています。
次の課題を解消するために、2021年3月からメルペイのBackendチームでは技術的負債、組織的負債を分析した上で、一部のBackendチームを5〜8人に再編することに取り組みました。
- チームで管理しているドメインが狭すぎたり、広すぎたりして、適切ではない
- Engineering Manager（以下、EM）がピープルマネジメントする人数が適切ではない
- 技術的負債が他チーム要因で解消する目処が立っていない
一目で見ると、チームの人数はすべての課題と関わらないと思う方もいると思います。しかし人数を目標値としてチューニングすることによって、他の課題はセットで解決することも可能です。
本記事は次の内容を紹介させていただき、同じくエンジニアリングチーム編成、最適化の課題に向き合っている方々へ少しでもご参考になれば幸いです。
- 1つのBackendチームは5~8人が適切なサイズだと考える理由
- チームの再編案を決めるステップ
- 再編案の事例
1つのBackendチームは5~8人が適切なサイズだと考える理由
そもそもチームの設計に絡む要素は人数だけではありません。考えるべき要素はたくさんありますが、目的はコミュニケーションコストを最小限にすることによってチームのパフォーマンスを最大化させることです。コミュニケーションが多く発生する人たちを同じチームにして、限定的なコミュニケーションしか発生しないところを別チームの境界にします。システム設計の「Low Coupling, High Cohesion」と似たような原則です。
メルペイの開発チームの構造
メルペイは図で示したマトリックス組織になり、「ドメインチーム」はPM、Backendエンジニア、Clientエンジニア、QAエンジニアなどの職種のメンバーで組成しています。私たちBackend EMは、1つもしくは複数のドメインチームのBackendエンジニアをマネージしています。この文章で同じ「ドメインチーム」のBackendエンジニアたちは一つの「Backendチーム」を指します。
コンウェイの法則（Conway’s Law）
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
コンウェイの法則はおそらくみなさんは馴染んでいるコンセプトだと思います。メルペイは最初からマイクロサービスのアーキテクチャーを採用することを決めた以上、エンジニアリング組織、特にBackendの組織設計はコンウェイの法則を意識し、ドメインチームごとにいくつか固定のマイクロサービスに対して開発・運用責任を持つことにしました。
逆コンウェイの手法（The Inverse Conway Maneuver）
Conway’s Law asserts that organizations are constrained to produce application designs which are copies of their communication structures. This often leads to unintended friction points. The ‘Inverse Conway Maneuver’ recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.
https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver
「逆コンウェイの法則」という翻訳もありますが、この手法はコンウェイの法則と反するという意味ではありません。「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」なら、「理想のシステム構造に従って組織を設計する場合、理想のシステム構造へ自然に進化できる」という意味です。
チーム間ドメインの分担を調整する必要がある場合（この場合、システム設計の変更も時々伴います）、チームを先に設計して再編することによって、理想的なドメイン分担とシステム設計を推進しやすくなります。
チームが今担当しているドメインのスコープが適切かどうかを判断する基準は、人数だと思います。
Backendチーム人数のチューニング
まず、今回はBackendチームの人数に限定して考えます。その理由は3つあります。
- ドメインチームのPM、iOS、Android、Frontendなどの職種の人数はそこまで変わりません。職種当たり一人のチームが多いです。
- Backendエンジニアの人数は多いので、Backend EMは他の職種のEMと比べるとよりドメインチームに密接に関わっている場合が多いです。
- マイクロサービスを開発、運用しているのはBackendチームであり、担当しているマイクロサービス、ドメインの数と大きさやOnCallローテーションの人数はとても重要なチューニングポイントです。
Backendチームの人数が4人以下の場合は、運用負荷が高くプロジェクトの波が来ると吸収しづらい。
4人以下のBackendチームは、OnCallローテーションできる人数に十分な余裕がありません。各メンバーのOnCall対応の平均負荷は高く生活リズムも保ちにくくなります。チームメンバーが育休や長期休みに入る時に、他のチームメンバーの負荷がグッと上がります。
また、複数のプロジェクトが同時に起こり、ドメインチームに対応を求められる場合、人数が少ないことでリソースコンフリクトが発生し、プロジェクトが思い通りに進められなくなります。つまり波が来ると吸収しづらくなります。
そしてやや小さいチームだと捌けるドメインも限定的になり、エンジニアがより大きなインパクトを出すのは難しくなります。
EMの観点では、マネージしている人数が少ないので、プレイングマネージャーを担当するか、他のチームを同時にマネージするかになります。他チームをマネージする場合、ドメインへの集中は難しくなりますし、コミュニケーションコストは高くなります。そして、少人数なので退職や異動によるチームへのインパクトはかなり大きくリスク管理は難しいです。
Backendチームの人数が9人以上の場合は、コミュニケーションコストが高まり効率は下がる。
9人以上のBackendチームは、ドメインチームで14人以上もいることになります。このようなチームの朝会はどんな感じかを想像してみましょう。やはり非効率と感じますね。
Fred Brooksさんは『Mythical Man-Month』にて、コミュニケーションのオーバヘッドは、チームサイズがNの場合O(N²)になると書いています。つまり、コミュニケーションコストはチームの人数のべき指数のスピードで増加しています。
大きいチームは大きいドメインを捌く傾向があり、OnCallや開発を実行するために一人ひとりが把握し必要な知識は多くなり、基礎的な負荷は高まりますので一人ひとりのキャパシティが削られます。
EMの観点では、人数が多いのでピープルマネジメントに時間を取られすぎることによって、組織課題や戦略立案などの仕事へ投資する時間は十分に確保できなくなります。
人数によってそれぞれのチームパフォーマンス要素への影響は表にまとめました。
チームの再編案を決めるステップ
チームの実情も考慮しながら、まず5~8人を1つの目標にすることによって、他のパラメータ（コミュニケーションコスト、ドメイン、運用負荷、EMの役割）も一緒にチューニングできます。メルペイのBackend組織では人数とドメインの課題があるチームはいくつかありますので、人数を目安としたチーム再編案を一部のチームで実施しました。
Step 1. ドメイン一覧を作って適切ではないドメインを適切なチームに移行
チームが管理しているドメインのサイズが適切ではない状態の課題は冒頭にも述べました。適切な分担になっていない理由は以下となります。
- 当時のチームリソースの要因で、別のチームでドメインの機能を実装した
- そもそもどのチームでドメインを持つべきかという議論を適切に行っていなかった
- 状況が変わって、他のチームがそのドメインを持つほうがより適切である
より適切なドメイン分担ができると、新しいプロジェクトの企画段階でどのチームがどこを担当すべきかの議論の効率はより良くなりますし、一つのプロジェクトに対応するために必要なチームの数が減ってコミュニケーションコストを減らすことも期待できます。
メルペイBackendチームでまず実施したStep 1はドメインチームで管理しているドメインをリストアップし、不適切そうなドメインを洗い出しました。不適切そうなドメインは担当するドメインチームに閉じずに関係チームと議論した上で、他のチームへドメインを移行すべきか、いつ移行するかを決めました。
Step 2. 5~8人のチームを再編成し、チームサイズを最適に
Step 1で洗い出された課題と対応策を分析し、ドメインの移管案を作った上に、Backendチームが管理しているドメインはどれくらいの人数が本当は必要なのかを分析しました。見込みとして4人以下のチームと9人以上のチームも出ています。
4人以下のチームの場合、親和性が高いドメインを持つチームとの合併案を積極的に考えながら作りました。9人以上の場合、チームの分解を検討しました。
Step 3. チーム再編成案とシステム移行案を並行し、技術的負債の解決に
メルペイの高速成長を支えるために、敢えて技術的負債を許容しビジネススピードとトレードオフしたケースも見られます。負債の返済にチームを跨いてマイクロサービスのマイグレーションが必要な場合、ドメイン移行とセットで検討した上に、チーム再編成によって負債の返済をよりしやすいようにします。
ここで大事なのは、ドメイン、システムの移行案を移行先と握ってスケジュールを明確にすることです。もちろん優先順位によってスケジュール変更することはありますが、進められるようにするために重要です。
再編案の事例
事例A：決済履歴のDX、UX両方への課題に対してのアプローチ
対応策：決済履歴のドメインをPayment Coreチームへ移管
今まで決済履歴を生成するロジックは、merpay-apiというアグリゲーションAPIを管理するチームが所有していました。そのロジック自体はかなり複雑で、そもそも本来アグリゲーションAPIを管理するチームは決済の詳細を持つべきではありません。また、決済履歴をアグリゲーションAPI向けのアーキテクチャ構成で開発メンテナンスするのはとても辛いです。新しい残高種類や決済手段を追加する場合や、履歴のUXを更に改善したい場合は、改修のDX（開発者体験）も悪く、コミュニケーションコストも高いです。
Payment Coreチームと相談した上で、本来の決済履歴に関連する情報を持つべきPayment Coreチームで新しい決済履歴サービスを開発してそちらにマイグレーションしにいくことを決定しました。
効果：現在はPayment Coreチームで新しい履歴サービスを鋭意進めています。より適切なドメイン分担でコミュニケーションコストを減らし、大きなUX改善にも期待できます。
事例B：加盟店開発に関わる2チームにおいて、OnCall人員を確保しづらい課題に対してのアプローチ
対応策：2チームを1つに合併
加盟店基盤チームで今まではOperation UnitとConsole Unitという2つのドメインチームに分けていて、それぞれ3人と2人のBackendエンジニアがいました。しかし、それぞれのUnitが少人数であるためOnCall人員を確保するのが難しい状態でした。
何かプロジェクトがある場合、それぞれ担当しているマイクロサービスで一緒に開発することも多いため両チーム間で密に連携することが多く、コミュニケーションコストがかなりかかっていました。
そこでこれらのチームを合併することに決めました。
効果：一人ができることが増え、加盟店基盤全体の施策を統一して考えられるようになりました。そしてプロジェクトの波が来ても、合併したチームメンバーで吸収できるので、本来増員予定だったところを増員しなくても対応できるようになりました。
事例C：Backendエンジニアの人数が多い決済基盤チーム内でのコミュニケーションが非効率であるという課題に対してのアプローチ
対応策：決済基盤チームをPayment CoreとBalance両チームに分解
決済基盤チームのBackendエンジニアは12名もおり、そもそも2つのSub Teamに分けている状態でスプリントプランニングをしていました。共通会議なら参加人数も多いので個人個人の発言は少くなっていました。
今回のきっかけで2つのSub Teamを徹底的に分解し、担当EMも変えやすいようにしました。一部の共通に実施したい会議は保留にしましたが、分けて実施するのも検討中です。
効果：各チームでの意思決定はしやすくなりました。そしてミーティングの人数が半分になったことで発言はより活発になりました。
最後に
組織設計になかなか正解はないし、会社のフェーズ、組織や個人の今までの成長パス、システムのアーキテクチャーなどいろいろな要素に影響されています。その中で、今回は人数をチューニングした上にチームのパフォーマンスに影響する要素をセットでチューニングする取り組みを紹介させていただきました。とはいえ、メルペイのBackendチームは今でも小さいチームや大きいチームは存在しています。今の状態で何をやるなら最適なのを常に検討しながら、Go Bold且つBe a Proに取り込むことは大事だと思います。
参考資料
Will Larson, An Elegant Puzzle: Systems of Engineering Management
Chris Richardson, Microservices Patterns: With examples in Java
Frederick P. Brooks Jr., Mythical Man-Month
