Team Topologies in Souzoh

こんにちは。ソウゾウの Software Engineer / Engineering Manager の@motokieeです。連載:「メルカリShops」プレオープンまでの開発の裏側の4日目を担当します。

4日目は、ソウゾウがどのような体制でメルカリShopsを開発しているかについて、Team Topologiesの解説を交えてお送りします。

はじめに

チームの在り方には様々な形がありたくさんの議論が交わされていると思います。自分自身も以前いた会社はもちろん、メルカリに入ってからも旧ソウゾウ、JP(日本事業)、メルペイとの関わり合いなど様々なチーム構成を見てきました。

タイトルにあるTeam Topologiesですが、https://teamtopologies.com/ では以下のように定義されています。

​​Team Topologies is the leading approach to organizing business and technology teams for fast flow, providing a practical, step-by‑step, adaptive model for organizational design and team interaction. https://teamtopologies.com/より引用

要約すると、ビジネス・エンジニアチームをのどのように組成するかの実践的かつ段階的に適応可能な組織デザイン及びチームの相互作用へのアプローチ方法である、と書かれています。

書籍も出ており読んでみたのですが、基礎となる4つのチーム、それぞれのチームの関わり方(モード)などが書かれており、ソウゾウでもこのTeam Topologiesを参考にして現在チームを構成しています。

本記事では、チーム構成と各チームの役割について解説していきます。

もしこの記事を読んで「このチームなら自分にフィットするかもしれない」と感じた方はぜひ仲間になって一緒にプロダクト開発に取り組んでくれることを心待ちにしています。

メルカリShopsのプロダクト開発チーム構成

現在、プロダクト開発チームは大きく以下の3つに分かれて活動しています。

Product Team and Enabling Team

  • Product Team A
  • Product Team B
  • Enabling Team

このチーム構成は、Team Topologiesの4つのチームを参考にしています。

Team Topologies

  • Stream-aligned team
  • Enabling team
  • Complicated Subsystem team
  • Platform team

このセクションでは、これらの役割について解説していきます。

Product Team A/B as Stream-aligned team

Product Team A/B(以下、Team A および Team B)はお客さまの課題を解決するチームで、Team TopologiesではStream-aligned teamと定義されているものです。

Product Teams

  • Stream-aligned team: “Stream”とは、ビジネスドメインまたは組織の能力に合わせた継続的な作業の流れを意味し、単一のサービスあるいは機能郡などの一連の流れにアラインして動くチーム。顧客への価値提供を可能な限り素早く、安全に、独立してお客さまへの価値提供を行うチームとされている

Team A/Bは技術領域(Frontend, Backend, Mobile)などでは分かれておらず、メインとなる領域はTeam AがBuyerのお客さまへの機能開発、Team BがSellerのお客さまへの機能開発としています。

技術領域で分かれていない理由は、CTO suguruさんのメルカリShops の技術スタックと、その選定理由でも紹介されていますが、monorepoで各レイヤー(Frontend, BFF, Backend)の開発をシームレスに行えていることが大きな要因ではないかと思います。

自分自身も もともとiOS Engineerとして入社しているのですが、メルカリShopsの開発ではFrontend, BFF, Microservicesなどシステム全体を一つのリポジトリ内で俯瞰してみることができるため、コンテキストスイッチの少ない状態で容易に開発に入っていくことができました。

また、クロスファンクショナルなチームとして動くStream-aligned team と monorepo の相性が良いと感じ、チームのポテンシャルを引き出すことができるのではないかと感じて現在のチーム構成に至っています。

Enabling Team as Enhancer of Stream-aligned team

Team A/Bがお客さまの課題を解決するチームであるのに対して、Enabling TeamはTeam A/Bの技術を強化していく役割と責任を持ったチームです。現在はこのチームにPlatform, SRE, Frontend Specialist, MLなど複数の異なる役割を持ったエンジニアが所属しています。

Enabling Team

Team Topologiesでは、Stream-aligned teamの他に、Enabling Team, Complicated Subsystem team, Platform teamの3つのチームが定義されていますが、これら3つのチームはStream-aligned teamの負担を軽減することを目的にしています。

以下の図は、書籍「Team Topologies: Organizing Business and Technology Teams for Fast
Flow」を参考に作成したものです。詳細は書籍をご参照ください。

Team Topologies

それぞれの概要は以下のとおりです。

  • Enabling Team: 特定の技術/ビジネスドメインのスペシャリストで構成されるチーム。Stream-aligned teamのケイパビリティを埋める役割を持ち、Stream-aligned teamが自律的に活動して技術的解決法以外の課題にフォーカスできるようにすることをゴールとする
  • Complicated Subsystem team: MLなどの複雑で専門性を要求されるサブシステムの開発とメンテナンスに責任を持つチーム。複雑なシステムを含む、もしく利用する際の認知負荷を軽減させることをゴールとする
  • Platform team: Stream-aligned teamが必要とする、低レベルの詳細なナレッジへの認知負荷を軽減させるための内部サービスを提供するチーム。Stream-aligned teamがオーナーシップを持って自律的にプロダクトを開発、リリースしていくことを可能にすることを目的とする

大きな組織であれば、これら3つのチームをすべて独立したチームとして構築することも可能だと思うのですが、ソウゾウではまだエンジニアが19人と独立させられるほど大きな組織ではないこと、またProduct Team A/Bを技術面から強化していくという意味合いも込めて、Enabling Teamという名前にしています。

また、必要な機能を開発していくことがまだまだ多いため、Product Team A/Bだけにするという案もありました。しかし、チームでの議論の中で横断して技術を見るチームがあった方が良い、メンバーからのというフィードバックも踏まえ、このEnabling Teamを置くことになりました。

このチームに所属している各エンジニアが取り組む課題も異なるため、必要に応じてProduct Team A/Bのスプリントに参加したりすることもあります。

Team Topologiesではチーム同士の関わり合いについても解説されています。一緒に機能開発を行ったり、ブロッカーを取り除くためのサポートを行ったり、API提供したりと、大きく3つの関わり合い方について書かれています。

ソウゾウのEnabling Teamも技術領域によって関わり方に差異はあるものの、同じように Team A/Bと関わっています。人数がそこまで多くないこともあり近い距離でコミュニケーションを取ることができており、いまのところ明確なルールやガイドラインを定める段階ではないと考えています。

しかし今後組織が大きくなったときには何らかのプロトコルが必要になるかもしれません。

例えばMLエンジニアが増えてきたらComplicated Subsystem teamとして独立し、MLを使った機能をStream-aligned teamと一緒に開発、あるいはAPI提供を行うことでMLを使った機能の開発を簡単にすることをミッションとして持つようになるのかもしれません。

おわりに

お客さまへの価値提供をメインに活動するProduct Team A、Product Team B、そしてTeam A/Bを強化していく役割を持ったEnabling Teamについて解説しました。

Product Team and Enabling Team

ソウゾウではエンジニア、プロダクトチームみんながEmpoweredされた状態で課題を解決していけるような体制を目指してこのようなチーム構成にしています。

一方で解決したい課題もたくさんあります。

例えば、メルカリShopsはメルカリのiOS/AndroidアプリケーションからWebViewを介して利用されていますが、これらiOS/Androidアプリケーションは別リポジトリ内にあるため、monorepoから離れた開発をどのように行っていくかはまだ答えのない課題です。

他にもたくさん課題はあるのですが、エンジニアが楽しくプロダクト開発にチャレンジしていけるような仕組みを工夫しながら作っていきたいと考えています。

採用情報はこちらに掲載されていますが、チームの雰囲気をもっと聞きたいという方は、カジュアル面談でさらにリアルなチームの雰囲気をお話させていただけると嬉しいです。

繰り返しとなりますが「このチームなら自分にフィットするかもしれない」と感じた方はぜひ仲間になって一緒にプロダクト開発に取り組んでくれることを心待ちにしています。