こんにちは。２０７株式会社の福富（@fukutomy）です。
前回は「TODOCUサポーターのつくりかた」と題して現在のプロダクト開発フローについて書いたのですが、当然ながら、はじめからこのような進め方をしていたわけではありませんでした。
本記事では個人的な棚卸しと社内に向けた言語化も兼ねて、２０７のチーム体制とアーキテクチャのこれまでの変遷と、直近で取り組んでいるこれからに向けたアップデートについてまとめてみようと思います。
入社当時のスナップショット
僕が入った当時（２０２０年の初め頃）は配達員向け業務効率化アプリ「TODOCUサポーター」と受取人向けアプリ「TODOCU」という２つのプロダクトを、かなり少数のメンバーで開発していました。
入社当時のチーム体制
当時はメンバーが集まる定例会議も存在しておらず、PMが適時作りたい機能について各Software Engineerに直接共有していました。(当時の僕はSoftware Engineerの１人でした。)
入社当時のアーキテクチャ
２０２１年１月のスナップショット
そこから約１年が経過して、受取人向けアプリ「TODOCU」はクローズし、代わりに法人向けサービス「TODOCUクラウド」の開発が始まりました。
２０２１年１月当時のアーキテクチャ
「TODOCUクラウド」のMVPは開発速度を優先してレンダリングには Rails の Action View を使い、リッチな動作が必要となる画面のみ適時 React の Component を埋め込むという素朴な実装でした。この頃にはGoogle Analytics、Redashといった分析環境が整備され、データ駆動で施策の優先度を決定するための素地が整ってきていました。
２０２１年１月当時のチーム体制
代表の高柳以外のBiz側メンバーが増えて(このあたりから Biz側／Engineer側という呼び分けが始まった気がする。)、プロダクトの要件と優先順位はBiz側メンバーが参加する定例で決定されるようになりました。
Software Engineerの数が増えたことによってプロダクト毎に開発チームが組成され、イテレーションをまわすようになりました。当時の僕はTL(テックリード)兼SM(スクラムマスタ)として、それぞれのプロダクトを効率的に開発するための開発フローと開発基盤の整備にコミットしていました(「CTO」という肩書きになったのもこの頃)。
現在の組織とアーキテクチャ
先述のチーム体制でプロダクトを開発していくうち、次第に以下のような課題が出てきました。
- プロダクト要件を決める会議の参加者が多くて、要件に関する議論が深めづらい
- 開発していくうちに新しく見つかった知見や課題を臨機応変に要件に反映するのが難しい
- Biz側からは見ることのできない、非機能要件が優先度として考慮されづらい
- タスクベースなUI設計による、データ構造の複雑化と開発工数の増大
２０２１年８月現在のチーム体制
これらの問題への対処として、開発のことがある程度わかる人間（僕）がTODOCUサポーターのPMを兼務することになったのが２０２１年の４月頃でした((図中TS TeamのPMとTC TeamのTL/SMを兼任している状態。))。まず取り組んだのが会議に参加するメンバーの断捨離で、当時は１０人を超えるメンバーが参加する会議体もありましたが、今では最大でも定例に参加するメンバーは４人程度となりました。これにより、各所での意思決定の精度とスピード感はかなり高まったように感じています((この結果として出来上がったのが、前記事「TODOCUサポーターのつくりかた」でご紹介した開発フローでした。))。（少なくともTODOCUサポーター側では）「Biz側」「Engineer側」という呼び分けが減ったのも、個人的には嬉しい変化でした。
２０２１年８月現在のアーキテクチャ
この頃には開発の本格化を見据えてTODOCUクラウドのSPA化を検討するようになり、これをきっかけに GraphQL + Apollo が導入されました。Terraformでインフラのコード化が実現され、環境変数の更新作業など、細かな設定作業を各プロダクトを担当するSoftware Engineerに委譲できるようになったのも大きな変化でした。
これからの組織とアーキテクチャ
チーム体制を再構築したことによりTODOCUサポーターの開発速度が上がった一方で、TODOCUクラウド側の開発も本格化し、今度は別の課題が目立つようになってきました。
- TODOCUサポーターとTODOCUクラウドの間で要件のコンフリクトがちらほら起きるようになってきた（詳細仕様や優先度調整のためのコミュニケーションコスト増大）
- 一方のプロダクトの実装がもう一方のプロダクトの障害を引き起こすケースが増えてきた
- 稼働時間の限られているメンバーが両プロダクトの詳細仕様を把握するのが困難
- @fukutomy のリソースの逼迫（TODOCUサポーターのPMとTODOCUクラウドのTL/SMを兼務するのが難しくなってきた）
これらの問題を解決に導くため、現在は以下の課題に取り組んでいます。
- 両チームのアジリティを確保するため、プロダクト毎にシステムを分離
- 両チームの生産性を担保する開発基盤チームの組成
これからのチーム体制
これからのアーキテクチャ（暫定版）
実際にシステムの分離をどこまで進めるかはやりながら方針を固めていくことを前提として、まずはテーブル構造とビジネスロジックの切り離しから着手しているところです。 プロダクトリリースの影響範囲が限定的になることで、弊社バリューのひとつである 「Speed With Quality 」なデリバリーの体現につながるのではと期待しています。
おわりに
本記事では、僕が２０７株式会社に入社してから現在にいたるまでのチーム体制とアーキテクチャの変遷についてまとめてみました。
このようにチーム体制やアーキテクチャ的な視点からの問題解決に早期から取り組んでいる背景としては、顧客とリリースサイクルが異なる２つのプロダクトを所有しているということもさることながら、フルコミットで全体を俯瞰できるメンバーの割合が少ないがゆえに、「知らなくても大丈夫なこと」を巧く設計しないとコミュニケーションコストが爆発するという弊社特有の事情もあったりします。例えば文中にちょくちょく登場したチーム体制図などをみるとSoftware Engineerがたくさん在籍しているように見えるのですが、実際にフルコミットで手を動かしているのはまだ僕を含めても３人だけという状況です((中でも、Backendを触っているのは僕だけ・・。))。
We're Hiring
というわけで、２０７株式会社では物流を変革するプロダクトを一緒に開発する仲間を絶賛募集しています。
副業からの関わりも大歓迎なので、
少しでもこの記事が琴線に触れた方はぜひお気軽にお声掛けいただけると嬉しいです！
Discussion