https://logmi.jp/tech/articles/326679

ソウゾウの組織図

広木大地氏(以下、広木):(スライドを示して)次に、それぞれの組織の図があって、ソウゾウさんの組織図がこんな感じになっています。これはさっぱりした図ですが、名村さん、説明してもらってもいいですか。

名村卓氏(以下、名村):メルカリに比べるとソウゾウはまだ小規模なエンジニア組織です。Product Termsというチームと、Enabling Teamsというチームがあります。

最初の組織編成の時にチームトポロジーズの本の影響を色濃く受けて、1つのあるサービスやコンポーネントを作っていくにあたり、できるだけそのチームが独立して動けるようにしたいという、ストリーム・アライン・チームをきちんと作っていくべきだということがあります。

そのチームができるだけドメインに所属せずに、可能な限り幅広い領域にアクセスしながら開発ができるところを目指したので、そういう意味ではProduct Teamsがエンジニアの中には存在して、スクラムごとにチームが分かれている感じになっています。

広木:たぶん聞いている中でわからない方がいると思うのですが、ソウゾウさんはメルカリのグループの中で今何を作っている会社ですか?

名村:メルカリの子会社で2021年にできました。メルカリは実際の消費者同士、コンシューマーtoコンシューマーのサービスです。メルカリが実際に事業者に対して販売する機会を与えるということで、BtoCのサービスである「メルカリShops」というものがあるのですが、ソウゾウでは今それを作っています。

広木:テックブログなどに「こんな感じのマイクロサービスアーキテクチャをやっていますよ」とか、「依存モデルをこんな感じでやっていますよ」と上がっていたかと思うのですが、そのサービスですよね?

名村:そうです。メルカリのテックブログに、技術スタックの2人がいろいろ中で作っている内情をたびたび載せたりしているので、もしかすると知っている方は知っているかもしれません。

システムとしての分離を意識して構成

広木:その時の記憶をたどってしゃべると、細かくマイクロサービスっぽく分かれている設計になっていたと思います。チームとして今は3チームあって、これをどんどん増やしていく想定になった時に、マイクロサービスなんだけど今はある程度複数のサービスをみんなが見られる状況になっていて、これから増やしていくようなことを想定している感じですか?

名村:そうですね。でももはやエンジニアの数よりマイクロサービスのほうが圧倒的に多いので、チームとマイクロサービスのオーナーシップ的な関係性は実はあまり考えてなくて、システムとして分離されるべきか否かしか、たぶん今は見ていないと思っています。全体としてのアーキテクチャがわりとサーバーレスに寄っていたりするので、そのマイクロサービスが1つの……。

広木:ファンクションぐらい?

名村:そうですね。サービスというか、サーバーなどのそういう大きなアプリケーションの単位ではなくて、わりとファンクションぐらいの単位。「こういう機能」「こういう機能」という感じで組んでいます。

みんなの頭の中では恐らく「そういうコンポーネントのソースコードがたくさんあるよね」ぐらいの感じに見えているとは思います。

広木:これは全部1つのリポジトリですか。それともリポジトリを分けているのですか?

名村:記事に書きましたが、モノレポで、今のソースコードは全部1つのレポジトリに統合されている感じ。

広木:エンジニアとしては見通しは立つけど、アイソレーションがきいているとか、技術的姿勢が入れやすいとか、そういう感じなんですか。