エンジニアリングマネージャーの自己紹介
株式会社10Xのソフトウェア エンジニアのふたがわです。
この10X.fmは、10Xをつくるおミッションに、 クオリティウェア向けECプラットフォーム
Stellaを提供している株式会社10Xのメンバーが、 キャリアや日々の出来事、学び、
プロダクトに対する思いを包み隠さず、 リアルにお届けしていくポッドキャスト
番組です。本日は、エンジニアリング マネージャーの3名をお迎えして、
お話ししていこうと思います。 最初に、こさこさんから簡単に
自己紹介をお願いします。
こさこ はい。10Xでエンジニアリング マネージャーをしております。
こさこと申します。10Xでは、 エンジニアリングマネージャーとして
エンジニアリング本部という、 エンジニアが所属している大きな
組織があるんですけれども、そこの 組織運営ですとか、制度設計とか
採用みたいなところを中心に働いて おります。よろしくお願いいたします。
おだしょー お願いします。次、かずさんお願いします。
かず はい。かずと申します。僕は10Xに 入社したのが大体3年前で、最初の
1年半ぐらいはソフトウェアエンジニア として開発をしていたんですけど、
ここ1年半ぐらいはマネージャー という立場になって、今は
アプリケーション開発という、 アプリケーションの開発を行う
ソフトウェアエンジニアがいる 務所全体のマネージメントを
しているという感じです。よろしくお願いします。
ドメインベースの開発体制の変更の背景
おだしょー お願いします。では最後、 ひさいちさんお願いします。
ひさいち はい。10Xのエンジニアリング マネージャーのひさいちと申します。
入社は2018年の6月と結構前で、 直近の4月ぐらいまではソフトウェア
エンジニアとして働いていたんですが、 この4月からエンジニアリング
マネージャーになりまして、お届け チームというチームのエンジニアリング
マネージャーをやっております。 以上です。
おだしょー ありがとうございます。では早速なんですけども、
今回エンジニアリングマネージャー の3名にお集まりいただいて、
どんな話したかったかというところを 自分からちょっと紹介したいな
と思ってまして、2ヶ月前ぐらいですかね、 会社のテックブログのほうで
ドメインベースの開発体制の移行 っていうタイトルでCTOの石川さんが
ブログ公開してたかと思うんですけど、 そこの開発チームの体制の変更
みたいなところをちょっと皆さんに お聞きしていきたいなと思ってまして、
そもそも2ヶ月前にその体制を変更 しましたみたいになった前に、
どういう体制だったのかとか、 そのときはどんな課題感があって
体制を変更しようと思ったのか みたいなところを最初に聞いて
みたいなと思ってまして、ここら辺、 カズさんから最初お聞きできますかね。
はい。もともとの体制っていうところで 言うと、TenXの開発組織はもともとは
パートナーごとに開発チームを 組成するっていう形で開発を
させていました。この開発チームは、 例えばパートナーAさん、パートナーBさんを
対応します。この開発チームはパートナーCさん、 Dさんを対応しますみたいに
チームごとに担うパートナーさんがいる みたいな形で開発を進めてました。
結構僕らが作ってるStaylerって たくさんのドメインを扱っていて、
例えば売り上げの連携をどうするか みたいなところから、
一番わかりやすいお客様に対して 売り場とかアプリケーションを
見せるみたいなところから、 注文が入った後の商品の
ピッキング・パッキングどうしますかとか 配達どうしますかみたいなのもあるし、
またまた小売りのパートナー様から データをどうやってStaylerって
アプリケーションに取り込みますかみたいな かなりいろんなドメインを扱っている
プロダクトなんですね。 当初はそれでも最初の
駆け引きに関わっていたメンバーが 多くいたので、パートナーさんごとの
開発をすべて一人の人とか一つのチームが 担うことができていたんですけど、
でもどんどん担うパートナーとか 機能が増えていく中で、
朝はピッキング・パッキングのところを 考えたけど、昼はお客様と
どうコミュニケーションを取るか みたいなことを考えるみたいなので、
頭の使い方もシステムの構造も違うので、 かなり認知負荷がかかってしまうような
というのが課題になっていたというのが 1個ありました。
あともう1個は、やっぱり向き合っている パートナーさんが決まっているので、
そのパートナーさんの要求に早く答えてあげたい という気持ちがかなり強くなる
体制だったなと思っています。 それはすごい正しいことなんですけど、
それと、この機能の未来が どうあるべきなんだっけっていうのの
両方に頭を使うっていうのがすごく難しいし、 使っている機能自体がすごく多いので、
それぞれの機能がどう動いている、 どうあるべきかっていうのを
全部を頭の中で持つのって、結構超人じゃないと できないみたいな状態になっちゃってました。
そこで、やっぱりこのチームが担う機能とか ドメインっていうのをある程度決めて、
この特定のパートナーさんじゃなくて、 このチームはこの機能を持ちますって形で
分けた方がいいんじゃないのかっていうので、 始まったのが今回の体制変更の議論です。
開発体制の課題と変更の詳細
今は、このさっき言った久市さんの お届けチームであれば、
このピッキング、パッキングとか配送とかの お届けに関するところの機能になってますみたいな形で
チームごとに担う機能っていうのが 分かれたっていうのが今っていう感じですかね。
ちなみに、このドメインベースの 体制に移ろうってなる前で、
半年、もうちょっと前ぐらいですかね、 になるんですかね。
いつぐらいですかね、移そうってなったの。
本格的に話を始めたのは12月、 去年の12月ぐらいなんで、
そうですね、半年ぐらい前ですね。
やっぱり、それでステーラー開発していたのが 多分2年ぐらいですよね。
2年ぐらいで結構規模がでかくなっていって、
その認知負荷みたいなところって めっちゃやっぱりつらかったみたいな感じですか。
そうですね、初期からいたメンバーとかは広く、
それでもやっぱりこの人はここが得意みたいなのが かなり分かれてたりとかして、
結局、これは得意そうな人に聞きに行く みたいなのが頻繁にあったりとか、
自信ないけど触るみたいなことに ならざるを得ないシチュエーションが
結構あったよなって思いますね。
割かし僕もそうで、結構昔からいるんですけど、
あんまり深いドメインのところに 触る機会がなくて、
例えばサイトコントローラーと呼ばれる、
既存のネットスーパーのコントロールをする部分とか、
ウェブのフラッターでウェブを作る みたいなところをやってたので、
あんまりお会計がどうなっているかとか、
決済の部分がどうなっているかみたいな、 結構深くは知らないことが多くて、
そこに詳しい人に聞きに行って、 ああ、そうなんだみたいな、
になってることが結構多かったっていうのが 前回の前の体制ではそうでした。
詳しい人がいて聞けば分かるんだったらまだいいけど、
それを続けていくと、本当にそのドメインに詳しい人っていうのが
誰もいなくなるみたいな可能性はあって、
このまま何年も進めたらきわどいよな っていうのを思ったっていうのはありますね。
それが去年の年末ぐらいで、
割と今年から移行のテストみたいなプロジェクトを やってたと思うんですけれども、
この移行のプロジェクトをやる上で大変だったとか、
今までこうだったんだけどこう変えてくれとか、
うまくいくのかみたいな課題もあったと思うんですけど、
その辺で苦労したとか、意外とここはすんなりいったとか、
そういうところってどうでしたっけ?
苦労したところで言うと、やっぱりどのチームがどの機能とか
どのように受け持つかみたいなのは、
もともとシステム自体すごい巨大なモノリフのシステムで
見つけ都合になってるので、どう分けますかっていうのはめちゃくちゃ難しくて、
こうかなっていう決めで一回分けて検証してみたけど、
やってみるとやっぱ違うよなってところがチラフラ出てきて、
それも踏まえてホーム移行したけど、
やっぱりこの機能ってどこに属してるのかみたいなのが
パキッとまだ決まりきってないみたいな状態ではあるかなとは思ってます。
まさにお届けチームとしても、
ここのピックパックっていう文脈でも、
例えば商品を追加したときに金額が変わるけど、
そのときにお会計チームとの領域ってどう分けるんだっけ?
みたいな話とかをまさに再現していて、
今後お会計チームとかお買い物チームを巻き込みつつ、
この領域とかを離して合意していくみたいなのが
今後必要になっていくのかなという気はしますね。
ちなみにドメインチーム、今ドメインチームというか開発チームですね。
開発チームはいくつかありますけど、
いくつぐらいに言われるといいなって実際と思います。
今大きなドメインっていう区切りだと3つ、
チームとしては5つぐらいあるわけですけど、
現実、今いるメンバーでチームを作ると、
1人チームとか2人チームを作っても仕方ないので、
今の数になったみたいな事情はあるかなと思っていて、
もう逆を言うと、あと2チームとか3チームぐらいはあった方がいい、
将来的にできるんじゃないかなって感覚はありますね。
逆に言うと1個のチームが分けたけど、
まだたくさんの機能を受け持ちすぎてる状態ではあるんじゃないかなとは思っています。
このドメインをうまく切るのって結構難易度が高いと思っていて、
今言ったようにこのドメインを持ちすぎているから割ろうとすると、
今度は割るとそこの境目って正しいんだっけとか、
コミュニケーションとチームの境界
結局コミュニケーションが増えちゃって大変だなとかいうこともあると思うんですけど、
この辺って実際どうです?
僕から話すと、
実際大変かと言われると、
大変になったかで言えば、
大変になったかで言えばって言うとちょっと変な感じがします。
増えたか増えてないかで言えば増えたと思ってて、他のチームと話すことが。
そういう意味では増えたんですけど、
それですごい大変になっているかというと別にそんな大変ではないのかなと個人的には思っているという感じですね。
めちゃくちゃたまにしか声が上がらないんだけど、
どこのチームが受け持つか決まってないものみたいなのが定期的にやってきて、
これどのチームにするんだっけみたいなのはそこは悩ましいところだなって思うと、
あとまだ半年、この新しい大戦って2ヶ月ぐらいなんで、
めちゃくちゃでかいプロジェクトの開発みたいのは走ってないので、
これから3チームがでかい機能をみんなで開発しますみたいになったときに、
どう開発進めるのかみたいなところは考えないといけないし、最初大変だろうなって感覚はありますね。
そうですね。うまくチーム間が連携しないといけないけど、
大きいプロジェクトになると特にリリースが決まっていたりすると、
ちゃんとやらないといけないんですけど、まだそこは試せてないというか機会が、
これから来るとは思うんですけど、っていうところですね。
やっぱりそういうチーム間のコミュニケーションみたいなのを円滑にやるとすると、
チーム間の依存関係みたいなのがきれいに整理されてないと難しいなって思ってて、
最近見積もりのときとかも上流側のチームから見積もりするかみたいなのとかをやってるんですけど、
そういうのをうまくちゃんとみんなが認識できてるみたいな状態にしなきゃダメで、
最近そういう活動を久井木さんがやってたりしてくれてるので、
久井木さんにその辺の話を聞いてください。
そうですね。まさに上流というかアップストリーム、ダウンストリームみたいなのがチーム間にあると思ってて、
今あるチームはいつつあって、僕がいるお届けチームとか、お買い物チーム、お会計チームとか、
あとセットアップチーム、入口チームみたいなふうにあるんですけど、
それぞれがお届けチームがお会計チームに依存してるとか、そういう関係性があると思っています。
先に見積もりの話だと、一斉にみんながチームごとに見積もりましょうみたいになったとしたら、
でもそうやって結局お会計チームの実装がお届けチームとしては影響あるから見積もりないよねみたいなふうになって見積もりにくいので、
お会計チームが見積もった後にダウンストリームであるお届けチームが見積もるみたいなふうに最近はしていきましょうかみたいな感じで試しているという状態です。
元々このドメインチームの開発体制に移行していく上で、こういう効果を狙っているみたいなところはあったと思うんですけども、
もともと先ほどあったパートナーごとの開発だとコンフリクトするとか、どうしても短期目線になるとかがあって、長期目線のプロダクト開発ができるようになっていきたいという課題もあるし、
そうじゃないとプラットフォームとして成長しないというところもあるので、すごい大事なところだと思うんですけど、
実際に2ヶ月やってみて、これはなかなかできたって言えるのはなかなか難しいと思うんですけど、できていきそうな気配とか感じます?
ドメインチームの開発体制
気配はあるなと思っているけど、まだ難しいなと思っているところはあって、
結構このドメインとか機能で見たとき、どこが課題かっていうのを考えるっていうのはちゃんと腰据えてできるようになってきたなと思っています。
元々結構ボールが浮いてたから放っておかれた課題とか、ちゃんと僕らが受け持ってるんだから直さなきゃダメだっていう圧力を働くし、
直していこうみたいなのが動いて実際に直したりはできています。
ただ、この機能とかこのチームが受け持つものがどうあるべきなんだっけっていう未来から逆算するっていうところまでは、
まだ考える時間とかもなくてたどり着けてないのかなっていう感覚はありますね。
そうですね。自分も全く同じ感覚で、結構前までは広く浅くみたいな感じだったので、
何でもやらなきゃみたいな感じで結構大変だったんですけど、
このお届けチームっていう開発チームになってピックパックとかに集中できるようになってきたので、
そこは非常に良かったなと思う反面、長期的な目線の開発ができているかっていうと、
多分まだできてなくて、そのためには小さい余裕とかを作っていく必要があるよねみたいな感じで、
すごく時間をかけているような運用の作業とかを改善していって、
できるだけ開発チームが関わらずでも改善できるようなことっていうのを徐々にやっていっているというような感じです。
そうですね。今後割と体制としてはひとまずうまくいっているところはできているのかなと思うんですけど、
今後こういうところを直していきたいというか、こういうことができるようになっていきたいとか、
こうしていくともっと良くなりそうだみたいなところって皆さん思っているところあります?
自分が思っているのは、さっきちらっと話したんですけど、まだやっぱり境界が曖昧なところがあるのかなと思っていて、
そこをチーム間で認識を合わせてコラボレーションか、もしくはコラボレーションじゃなく、
このインターフェースでよろしくみたいな感じでAPIで用意するのかちょっと分からないんですけど、
そんなふうにチーム間での認識の揃えるっていうのが必要になってくるのかなとぼんやり思っていたりします。
そうですね、さっき話したこととちょっとかぶっちゃうんですけど、
やっぱり最終的にはこのチームはこういうものを実現したいからこの順番でこれをやりますとか、
またこういう新しい改善とか機能を作りますみたいなのを強くスタンスを取ってコミュニケーションできるようになるといいなと思っていて、
ただ、さっき被災地にされてくれたように完全にドメインの境界もまだ定まりきっていないし、
ドメインに関する知識っていうのはまだ2ヶ月で蓄えている状態だと思うんで、
まだそこまではなかなかいけないかなけど、将来は目指せるかなっていう。
基盤チームの必要性
そうですね、あとは基盤チームの話とかも中ではしていまして、
今ってドメインベースの開発再生で開発チームはそのドメインの開発をしているんですけれども、
その横断的なところっていうのも開発をするっていうチームがまだそんなに成立していなくて、
ここが横断的な課題というのを解決したというか、基盤を作るみたいなところが必要性があるなとは思っていまして、
そこのチームを今後作っていきたいなというのは結構思っているところではあったりしますね。
ちなみに今までは基盤チームみたいなものはなかったんですけど、
そういう役割って過去には結構あったりしたんですか?個人だったらかもしれないですけど。
そうですね、個人でチームみたいなのはなかったような気がしてて、個人で手を挙げてやるみたいなことはあったんですけど、
やっぱりチームで活動していくみたいなのはなかったのかなという気がします。
そういう意味だと、以前は割と個人でやっていることが多くて、だんだんチームとして動くようになってきて、
そこのところっていうのは結構TenXとしてもエンジニア組織としては結構変わってきているところなのかなと思うんですけど。
そうですね、定期リリースとかまさにそうだなと思ってて、定期リリースって今リリース担当とかを決めてたりとかするんですけど、
その決める実装とかって僕が個人的にやっていて、チームが持っているタスクではないんですけど、
それって僕にすごい依存していて、スケールもしないし、チームメンバーの皆さんも自分ごとがすごいしづらいので、
チームに移情していく形はどうだろうかみたいな話とかを最近進めていて、
それも個人からチームに移情していくというか、そういう話に近いのかなと今聞いてて思ったりしました。
そうですね、ちょっと最近始まった技術的意思決定会とかもそういうところありますね。
個人で今まで決めて、えいってやってたものが割と組織として全体としてディスカッションしたりとか、
決めるフローとかそういうプロセスでちゃんと決めていこうというところには結構なってきている気がします。
そうですね、前は個人のときに大変だったのは、本当にこれ僕が決めていいんだろうかみたいな、
決めていいのかなって思いながらちょっと不安になりながら進めてたところがあったりとかしたんですけど、
その技術的な意思決定会とかチームに移情していくというので、そういうのが解消されて、
チームメンバーが力を発揮できる形になるといいなと個人的には思っております。
10人ぐらいだと決めて、なんとなくこれでってなって、
みんな見てくれてるから合意取れてるかなみたいなのがギリギリ成り立ってたけど、
さすがに今の規模になると逆に決める場がないと決めていいかどうかわかんないから浮いちゃうみたいなのはあるよなって思ってて、
技術意思決定会みたいな試みはすごい決められるようになっていいなって思ってます。
そうですね。
技術的意思決定会の中で話されてる内容とかはどういうのがあったりとかするんですか?
時々サマリーとかが流してるのを僕は見てるんですけど、
リバーポッドの標準的な使い方決めましょうみたいな話をしてたりとか、
あとはちょっと細かい話もあれば結構大きめのパッケージ分割どうしましょうかみたいな話とかもしてるのかなという印象があります。
データパイプラインのアーキテクチャー、こうしたいんだけどいいんだっけとか、もっとこうしたいんだけどみたいな話とか、
割と大きな話も結構ありますよね。
ドメインベースの開発体制のメリット
僕はあれ結構出るのが好きで、今こういう構造になっていてこういう課題があるんだっていうのを知れるのが非常に面白いなと思っていますし、
質問してなんでこんなになってるんですかって聞くと、こういう理由があってっていうのを知れるのも非常に面白いって思ってます。
最終的に技術的意思決定下に何か持ち込まれたアジェンダを決めるのは誰が決めるとかっていうのも決まってるんですかね。
基本的には最終決定権はCTOにあるということで、CTOがこれでもう行きますってなればそれで決定っていう感じですが、
基本的には割と合議性じゃないですけど、これで問題がないよねってなればそれでGOになるとほとんどの場合は。
よっぽどAとBとCとどれを取るといいのかわからん、悩む、どれもありだしなしだしみたいな中になると腹を決めるしかないみたいなのはあると思います。
個人とかチームの中で実はひっそり進めてて、Riverbottomとかもそうですけど、導入してプラクティスが止まってるんだけど、どうやって前者的に展開しましょうかみたいなところで止まってたのがちゃんと出てくるようになっててすごいいいなって思いました。
確かに、開発チームになって自分たちの領域みたいなのが結構はっきりするようになったので、挑戦的な変更を加えやすくなったというか、最終的に責任は我々にあるっていう意識があるので、
大きめの変更とかも入れてみて、これがどうだったねとかそういう話とかもしやすいなと思っていて、そういう挑戦をしてきて、じゃあ前者的に展開するにはどうしたらいいかというときに技術的な意思決定会の活用していくみたいなのがあるのかなと聞いてて思ったりしました。
大きい会社は、もともと誰もオーナーじゃない状態だと、自分がやってこの影響とかの責任を取れないしどうするかなみたいなのはあって、自分のチームが引き受けるからってので進めやすくなったところがありそうですね。
これはでも、ドメインベースの開発体制に移行したことが結構大きなメリットな気はしますね。パートナーっていう軸がすごい大事なんだけど、そこから見ると技術的な意思決定ってどうしてもプライオリティが低くなっちゃいますけど、この領域のドメインに責務を持つってなると、パートナーも大事だし、そういうものも大事っていう、割と両立するというか、
ちゃんと並べて比較ができるようになったっていう意味ではすごく良かったんじゃないかなと思います。
長期目線と改善サイクル
このパートナーの声に応えてあげることはできるんだけど、ただすごい今日を生きる行動になってしまうみたいなところがあったなと思ってて、
でも今日を生きる行動を変えてメンテナンスし続けるのはもう自分たちの責任なんだっていうのを思うようになったのは変化ですね。
色々お話ししていただいて、ブログ公開された時の中で、ドメインチームに分けることによって期待することみたいな3つ書かれていて、
長期目線に立ったプロダクト開発ができるとか、チームごとの継続的な改善サイクルが回るとか、ドメインに立ち入った開発が加速するみたいなところが書かれていて、
色々お話し聞いた中で、ここら辺は少しずつ進んでそうだなっていうのを自分としては聞きながら感じたんですけども、皆さんはどんな感想でしょうか、この辺りは。
カズさんからいきますか。
そうですね。まだ考えることはたくさんあるんだけど、でもやっぱり長期的な観点とか認知負荷の減らすのみたいなのは、
既に効果が出始めているところもあるなっていうのを感じることができていて、まだ決めなきゃダメなことはあるけど、それを決めたり整理して、うまくこの方向で進みたいなって思いを強くしているっていう感じですかね。
僕も全く同じで、色々決めることはあるけど、効果は感じているなというところが、お届けチームとしての初感ですね。
そうですね。自分も直接チームに入っているわけではないんですけれども、各チームからのやってることとか、いろんなドキュメントとかを見ていると、
割と目の前のこともまだ全然ありますし、すごく大変なんですけれども、一方でちゃんと長期的な目線を持とうとか、この課題にちゃんと取り扱っていこうみたいな意識っていうのは結構見え隠れしてきていて、
だんだんとそれが仕組みにも還元されて、ちょっとずつ良くなっているなという実感は持っています。
ありがとうございます。いい時間になってきたので、今日はこの辺りでお閉めさせていただければなと思います。
今日はエンジニアリングマネージャーの3名に来ていただいて、メインチームの開発体制の移行っていうところをお話ししていただきました。
10XFMではリスナーさんからのお便りを募集しています。
エピソードの感想や10Xのメンバーに聞いてみたい質問など、どんなことでも構いません。
番組概要欄にあるお便りフォームからの投稿、またはTwitterでハッシュタグ10XFMでツイートお願いいたします。
今日のお相手はソフトウェアエンジニアの双川でした。
それではまた次回。バイバイ。
