ソウゾウ・SmartHRの組織図から見るチームの分けかた　取締役が語る、現在の構成がつくられたそれぞれの背景と意図

ソウゾウの組織図

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

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

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

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

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

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

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

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

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

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

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

広木：ファンクションぐらい？

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

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

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

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

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

名村：そうですね。見た目的にはマイクロサービスのソースコードがバーッとあるので、1個のモノリスなサーバーにコンポーネントがきれいにバーッと分かれているのと似たような見え方だとは思います。

Enabling TeamとProduct Teamsの仕事

広木：なるほど。Enabling Teamは何をしているのですか。チームトポロジーのEnablingと同じような感じですか。

名村：チームトポロジーの場合、Enabling Teamはいろいろなチーム種類の中の1個だと思うのですが、ソウゾウの場合はまだ小規模なので、他のタイプのチームを作るには早いというのがありました。

単純にProduct Teamsになんらかの武器を提供するというか、Product Teamsが開発をするために何か手助けになる、もしくは必要になる。もしくは「これがあると開発チームがもっといろいろな機能が作れる」とか、基本的にはそういうものを提供しているチームです。

そういうプロダクティビティに関する開発もやっているし、マシンラーニングのチームもいる。あとはSRE的なチームも、DevOps系をやっているチームもいます。

Product Teamsがto Customerに対して。Enabling Teamsはto Developerのことをやっているチームなので一番説明しやすいかと思います。もちろんML（Machine Learning）のチームがto Customerの機能も作っているので、ちょっと例外的なところはあります。

SmartHRの組織図

広木：ありがとうございます。SmartHRさんの組織図を見せていただけるということで。お、たくさんある。

芹澤雅人氏（以下、芹澤）：これはカジュアル面談などで使っている図を拝借してきました。僕たちも発想としては似ています。今エンジニアが70〜80名ぐらいいて、プロダクト開発にかかわっている人でいうと、全部で140〜150人ぐらいいます。

そういった人たちを、1プロダクト1チームずつ形成するスタイルで、基本的にエンジニアは兼務はしないように、1つのプロダクトに集中するような体制の下にチームを作っていく感じでやっています。

これは創業初期というか、事業やプロダクト組織が発展していくうえでの痛みによるものもあって、やはり最初はモノリスで実施しました。SmartHRというサービス、プロダクトをどんどん大きくしていったのですが、チームのエンジニアの人数が10人を超えたあたりからどんどんスピードが出にくくなるとか、スクラムがやりにくくなるみたいなことが出てきて、何とか分割しようと模索を始めました。

いろいろやり方はありましたが、僕たちの場合はマイクロサービス、厳密にいうとぜんぜんマイクロサービスではないのですが、機能を分割していくようなことをやりました。

SmartHRを使っていただいた方はイメージできるかもしれないですが、ログインした後に、例えば「年末調整やるぞ」となったら年末調整ボタンをポチっと押して年末調整の画面に遷移します。内部的にはその遷移の時に、アプリケーションがもう切り替わっているんです。

認証を引き継いだり、あとはAPIでSmartHRの本体とやり取りをして年末調整を動かす仕組みになっていて、完全にリポジトリも別でチームも別になっています。

これをやることで、いわゆるコンウェイの法則がかなりきれいに当てはまり、SmartHR本体を作っているチームが1対1で紐づき、また、年末調整の機能を作っているチームがプロダクトに1対1で紐づく感じになります。

初期のチームが肥大化していくうえでの悩みが、これによってかなり解決されたという成功体験があって、それ以降ずっとこういったかたちで組織とプロダクトをスケールさせてきています。

1つのプロダクトに集中する体制がうまくいっているポイント

かなりうまくいっているポイントがいくつかあります。（まず）一つひとつのチームが必然的に小さい単位に保てます。そのため、前半で話したようなオーナーシップが持ちやすいとか、自分が知るべきドメインの知識が限定されて負荷が下がるとか、そういうものがかなり効いています。

かつ、マネジメントもこのチームの単位で実行されます。たまに「一緒にコードを書いていない人にエンジニアとして評価されるのは、あまり納得しない」みたいな体験をした方がいるかなと思うのですが、やはりそういうものが減らせたりもします。

一緒にコードを書いているメンバーの中にマネジメント、評価をする人がいて、その人の下にチームビルドが行われていくのも、今回のテーマであるメンバーの成長だったり自立を促しやすい（実感）みたいなのもあって。そのための仕組みとしては、強い基盤になっているのではないかと思います。

広木：ありがとうございます。これはたぶんURLが違うものの、認証系だけは一緒で、フロントエンドも分離するタイプのマイクロサービスなんですよね？　

芹澤：そうです。

広木：フロントエンドのコンポーネントの共有化もけっこうしていますか。

芹澤：していますね。これは「SmartHR デザインシステム」か「SmartHR UI」で調べるとけっこう出てくるかなと思います。

広木：Reactのデザインシステムみたいなものですよね。

芹澤：そうそう。社内で共有するだけではなくて、普通にパブリックに出しています。「パブリックに出したのはなぜか」みたいなところは諸説あるのですが、初期の頃からかなり力を入れていて。みんながそのデザインシステムとコンポーネントを使えばシームレスな体験を提供できるようなUI／UXが実現される。それの近道になるようなアイテムはかなり力を割いて整備しています。

広木：確かにBtoBのシステムでいろいろな機能が機能として求められてくるようになると、UIとして一つひとつ作り込んでいくよりも、同じコンポーネントが同じ価値になっているほうがわかりやすいとか、そういう感じですよね。

芹澤：そうですね。

広木：Railsの部分というか、バックエンドの部分でも共通化する何かはあったりするのですか。

芹澤：そうですね。アーキテクチャだけで見るとなんでもいいのですが、メンバーのポータビリティだったり、社内でのノウハウのレバレッジの効きやすさから、どうしても共通でRailsを使ったほうがいいと。Railsを使うことで、資産、アセットが多いので、自然とこうなってしまっている感じです。

ただ、先ほども言ったとおり仕組み的にはなんでもいいかなと思うので、今後作られるサービスの特性次第では、別の言語を使うこともゼロではないかなと思います。

コアとプラスの連携方法

広木：ちなみに単純な興味でうかがいたいのですが、（スライドを示して）コアの部分とプラスと書いてある部分の連携方法は、考えるとけっこうややこしくなりそうだなと思いますが、依存関係としてはそれぞれ独立しているのですか。

芹澤：これはかなりシンプルで、プラス側、僕たちはプラスアプリと呼んでいるのですが、これらは今のところ連携していません。

コアとプラスが1対nの感じになっていて、コアとプラス間はここに書いてあるとおりRESTのAPIでおしゃべりをするような、極めてシンプルな構造です。このあたりはそこまで複雑化されていないところです。

広木：最近のプラガブルなERP（Enterprise Resources Planning）系のものは、そういうものがちょっとずつ増えている感じなんですか。

芹澤：そうだと思います。

広木：GraphQLがちょっとだけ書いてあるのも興味深いです。

芹澤：そうですね。これはシンプルに届出書類というアプリケーションがかなりたくさんの従業員情報を使うので、RESTの限界を超えてしまったというか。GraphQLでいろいろな情報を柔軟に取れたほうが合っているというところで使われています。

今後もそういった特性に応じてインターフェースみたいなところをいろいろ作っていくと思うのですが、今のところはこのREST APIとGraphQLでユースケースは満たせている感じです。

（次回につづく）