3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャそして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years

by Shintani Teppei

Slide 1

Slide 1 text

2024/12/24 【アーキテクチャと組織の変遷】スピードとスケーラビリティの両立　　　　　　 -基盤刷新・モジュラモノリスの行先- 株式会社タイミー　新谷哲平 3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャそして、これから @euglena1215

Slide 2

Slide 2 text

自己紹介 Shintani Teppei（@euglena1215） ● 株式会社タイミー（2023年1月入社） ● バックエンドテックリード ○ プロダクト開発に直接携わらない形 ○ バックエンド領域における開発プロセス・仕組み作り含めたアーキテクトのような役割

Slide 3

Slide 3 text

この発表での注意書き ● バックエンドの話が中心です ○ モバイルアプリ、Webフロントエンドの話は基本出てきません ● ソフトウェアアーキテクチャをアーキテクチャと略します ○ インフラアーキテクチャの話は出てきません ● 組織構造ではプロダクト開発チームを主眼において話します ○ タイミーには様々なプロダクト開発チームを支えるチームが存在しますが今回は出てきません ○ ここについて知りたい方は組織の立ち上げ期から取り入れるチートポTIPS をご覧ください ■ ref. https://tech.timee.co.jp/entry/tips-on-teamtopologies-in-early-stage

Slide 4

Slide 4 text

Slide 5

Slide 5 text

3年間のタイミーの変化年間売上バックエンドエンジニア数

Slide 6

Slide 6 text

3年間のタイミーの変化 1,299 百万円年間売上バックエンドエンジニア数 6 名 FY21/10

Slide 7

Slide 7 text

3年間のタイミーの変化 1,299 百万円年間売上 26,880 百万円 20.7x バックエンドエンジニア数 6 名 32 名 5.3x FY21/10 FY24/10

Slide 8

Slide 8 text

3年間のタイミーの変化 1,299 百万円年間売上 26,880 百万円 20.7x バックエンドエンジニア数 6 名 32 名 5.3x FY21/10 FY24/10 3年前時点でこれからエンジニアを増やしていくことは決めていた

Slide 9

Slide 9 text

どんな話をするか過去編現在編未来編 2021年に何を考え、どんな準備をしていたのか 2024年の今、振り返ってどうだったのかこれからのこと ※ 自分が入社したのは2023年1月過去編は社内外の情報や直接当時の CTO から聞いた話。歴史家の気持ちで話します。現在編・未来編は当事者として話します。

Slide 10

Slide 10 text

1 急拡大が予想できた 2021年に何を考え、どんな準備をしていたのか過去編

Slide 11

Slide 11 text

急拡大が予想できた2021年に何を考えていたか kameike / CTO(当時)

Slide 12

Slide 12 text

急拡大が予想できた2021年に何を考えていたか「今までの少人数での開発スタイルでは問題が起きそう。そのために変化していかないと...！」 kameike / CTO(当時)

Slide 13

Slide 13 text

急拡大が予想できた2021年に何を考えていたか「今までの少人数での開発スタイルでは問題が起きそう。そのために変化していかないと...！」 kameike / CTO(当時) 組織をスケールさせるための準備をしていく

Slide 14

Slide 14 text

前提：2021年時点でのアーキテクチャと組織構造

Slide 15

Slide 15 text

前提の前提：提供しているインターフェース対象プラットフォーム iOS/Android ワーカークライアント（店舗）クライアント（企業）社内全般 Web モノリス Ruby on Rails アプリケーション

Slide 16

Slide 16 text

2021年時点の構造：アーキテクチャ対象プラットフォーム iOS/Android ワーカークライアント（店舗）クライアント（企業）社内全般 Web モノリス Ruby on Rails アプリケーションモノリスの Ruby on Rails アプリケーション1つで運用

Slide 17

Slide 17 text

2021年時点の構造：組織構造対象プラットフォーム iOS/Android ワーカークライアント（店舗）クライアント（企業）社内全般 Web モノリス Ruby on Rails アプリケーションワーカーチーム / クライアントチームの2チームを編成一気通貫の開発を行うために職能横断のチームにしていた社内管理画面はみんなで共有

Slide 18

Slide 18 text

前提：2021年時点でのアーキテクチャと組織構造 ● アーキテクチャ： ○ モノリス Ruby on Rails アプリケーション ● 組織構造： ○ ワーカー（toC）チーム / クライアント（toB）チームが存在 ○ 一気通貫の開発を行うために職能横断のチーム → バックエンドエンジニア目線だと、 2チームで1つのモノリスを開発・運用している状態

Slide 19

Slide 19 text

アーキテクチャ：モノリスからモジュラモノリスへチームの独立性を保ちスケールする組織を目指すため、単一のモノリスではなく独立したモジュールから構成されたモノリスへ

Slide 20

Slide 20 text

組織構造：ステークホルダーを軸としたチームからの変化ワーカーチーム・クライアントチームは職能横断のチームになっていた。そのため、それぞれのチームが独立して機能開発を行えることもあった。しかし、そうでないケースも発生していた。

Slide 21

Slide 21 text

タイミーを利用する際の流れ

Slide 22

Slide 22 text

タイミーを利用する際の流れここ！

Slide 23

Slide 23 text

タイミーを利用する際の流れワーカー・クライアント双方に関わる機能の改善はチーム間のコミュニケーションが必要

Slide 24

Slide 24 text

タイミーを利用する際の流れマッチングプラットフォームであるタイミーにとってとても重要な機能重要 = 変更頻度が高い & スピード感が大事

Slide 25

Slide 25 text

タイミーを利用する際の流れ独立して開発できる体制を目指すためチームの境界を変更する

Slide 26

Slide 26 text

Before：チームの境界クライアントチームワーカーチーム ✂

Slide 27

Slide 27 text

After：チームの境界マッチング領域ワーカーとクライアントの出会いを最適化 ✂ スポットワークシステム領域スポットワークにまつわる手続きをなめらかにする

Slide 28

Slide 28 text

準備：組織構造 Before： ● ワーカーチーム ○ ワーカーの体験を高めていく ● クライアントチーム ○ クライアントの体験を高めていく After： ● マッチング領域 ○ ワーカーとクライアントの出会いを最適化し、ビジネスをスケールさせる ● スポットワークシステム領域 ○ 出退勤や労務管理など、スポットワークにまつわる手続きをなめらかにする

Slide 29

Slide 29 text

過去編まとめ：目指す開発スタイルの変化少人数でなんとかする組織的なものづくり

Slide 30

Slide 30 text

過去編まとめ組織的なものづくりを行い、スケールに耐えられるような構造を作るためソフトウェアアーキテクチャ・組織構造の両面から変化を促した。 ● モノリスからモジュラモノリスへ ● ワーカー/クライアントからマッチング/スポットワークシステムへ

Slide 31

Slide 31 text

2 2024年の今、振り返ってどうだったのか現在編

Slide 32

Slide 32 text

2024年の今、振り返ってどうだったのか以下の2点について振り返ってみる 1. 狙い通りのアーキテクチャ・組織構造になったのか 2. 組織はうまくスケールできたのか

Slide 33

Slide 33 text

振り返り：ソフトウェアアーキテクチャ目指していたのはモジュラモノリス

Slide 34

Slide 34 text

振り返り：ソフトウェアアーキテクチャ結果：ある程度ディレクトリとして分けられているものの、自由かつ相互に参照可能で独立していないものが多数

Slide 35

Slide 35 text

振り返り：組織構造目指していたのはマッチング領域 / スポットワークシステム領域をベースとしたチーム編成マッチング領域 ✂ スポットワークシステム領域

Slide 36

Slide 36 text

振り返り：組織構造結果：それぞれの領域にチームが紐付き、8名前後のプロダクト開発チームが合計10チームほど存在するそれぞれがプロダクトゴールを持ち、独立して動けている状態

Slide 37

Slide 37 text

狙い通りのアーキテクチャ・組織構造になったのか？ ● アーキテクチャ：モノリスのまま ☔ ● 組織構造：マッチング/スポットワークシステム領域に対して　　　　　プロダクト開発チームが合計10チーム存在 ☀ → プロダクト開発をしているチームが10チームあって　バックエンドはみんな同じモノリスの中で開発をしている状態

Slide 38

Slide 38 text

組織はうまくスケールできたのか？

Slide 39

Slide 39 text

できた！ ...と言って差し支えないはず組織はうまくスケールできたのか？

Slide 40

Slide 40 text

うまくスケールできたと考える理由 1. 2. 3. 組織はうまくスケールできたのか？

Slide 41

Slide 41 text

うまくスケールできたと考える理由 1. 開発の並列度が上がり、顧客への新たな価値提供は加速している（主観） 2. 3. 組織はうまくスケールできたのか？

Slide 42

Slide 42 text

うまくスケールできたと考える理由 1. 開発の並列度が上がり、顧客への新たな価値提供は加速している（主観） 2. d/d/d は3年間で0.5→0.4に減少傾向ではあるもののバックエンドエンジニア数が5倍になってこの減少幅なら十分だろう 3. 組織はうまくスケールできたのか？

Slide 43

Slide 43 text

うまくスケールできたと考える理由 1. 開発の並列度が上がり、顧客への新たな価値提供は加速している（主観） 2. d/d/d は3年間で0.5→0.4に減少傾向ではあるもののバックエンドエンジニア数が5倍になってこの減少幅なら十分だろう 3. バックエンドエンジニアの入社後の早期離職はなし組織はうまくスケールできたのか？

Slide 44

Slide 44 text

モジュラモノリスにはなっていないものの、必要に応じて改善は行われてきた ● バックエンドとフロントエンドの密結合解消 ○ クライアント側画面のSPA化 ● 他と取り扱いが異なる領域の分離 ○ 銀行周りのモノリスからの切り出しなぜスケールできたのか？：アーキテクチャ面

Slide 45

Slide 45 text

モジュラモノリスにはなっていないものの、必要に応じて改善は行われてきた ● バックエンドとフロントエンドの密結合解消 ○ クライアント側画面のSPA化 ● 他と取り扱いが異なる領域の分離 ○ 銀行周りのモノリスからの切り出しなぜスケールできたのか？：アーキテクチャ面チームで独立した開発を行えることを目的とするのではなく目の前の問題に1つずつ取り組んでいた

Slide 46

Slide 46 text

プロダクト開発チームが独立して開発できる状態になっていたなぜスケールできたのか？：組織面

Slide 47

Slide 47 text

プロダクト開発チームが独立して開発できる状態になっていた Q. モノリスなのになぜ独立して開発できたのか？ → チームの責務が安定していて変更範囲が限られていたからなぜスケールできたのか？：組織面

Slide 48

Slide 48 text

プロダクト開発チームが独立して開発できる状態になっていた Q. モノリスなのになぜ独立して開発できたのか？ → チームの責務が安定していて変更範囲が限られていたからなぜスケールできたのか？：組織面学び：チームの責務がある程度安定していれば、　　　機械的な境界がなくとも独立した開発は可能チームが普段変更しない機能はそもそも普段の会話に登場してこないので認知負荷が高まることもない

Slide 49

Slide 49 text

現在編まとめ：2024年の今、振り返ってどうだったのか 1. 狙い通りのアーキテクチャ・組織構造になったのか → アーキテクチャはモノリスのまま、組織構造は狙い通りに 2. 組織はうまくスケールできたのか → できた！

Slide 50

Slide 50 text

3 そしてこれから未来編

Slide 51

Slide 51 text

これまでのあらすじ組織をスケールさせるためにチームの独立性を高める活動をしたその結果、独立して開発が行えるチームをいくつも作ることができた

Slide 52

Slide 52 text

プロダクト開発チームが増えたことによる弊害

Slide 53

Slide 53 text

プロダクト開発チームが増えたことによる弊害コードベース中に知らないコードが増えるようになった自チームが見ている以上の範囲に対してオーナーシップを感じることが難しくなりつつある「この機能は自分たちが見る”べき”なのか」出典：畑村洋太郎著,技術の創造と設計,岩波書店,P17 引用

Slide 54

Slide 54 text

プロダクト開発チームが増えたことによる弊害コードベース中に知らないコードが増えるようになった自チームが見ている以上の範囲に対してオーナーシップを感じることが難しくなりつつある「この機能は自分たちが見る”べき”なのか」出典：畑村洋太郎著,技術の創造と設計,岩波書店,P17 引用オーナーシップを感じるには “認知していること ”が重要

Slide 55

Slide 55 text

プロダクト開発チームが増えたことによる弊害コードベース中に知らないコードが増えるようになった自チームが見ている以上の範囲に対してオーナーシップを感じることが難しくなりつつある「この機能は自分たちが見る”べき”なのか」出典：畑村洋太郎著,技術の創造と設計,岩波書店,P17 引用知らないことにはオーナーシップを感じられない

Slide 56

Slide 56 text

プロダクト開発チームが増えたことによる弊害コードベース中に知らないコードが増えるようになった自チームが見ている以上の範囲に対してオーナーシップを感じることが難しくなりつつある「この機能は自分たちが見る”べき”なのか」出典：畑村洋太郎著,技術の創造と設計,岩波書店,P17 引用でも認知する範囲を広げると認知負荷が ...

Slide 57

Slide 57 text

認知可能な範囲は広げたいが、認知負荷は高めたくないエンジニアリングと組織の両面からアプローチ可能。やっていくしかないアプローチの一例 - エンジニアリング - 適切な抽象化、問題解決の為のモジュール分割、型による開発支援、etc… - 組織 - チーム間のコミュニケーションの敷居を下げる、チーム境界の見直し・統合、etc…

Slide 58

Slide 58 text

最後に

Slide 59

Slide 59 text

技術の螺旋技術トレンドの変化には螺旋が存在する振り子のように行ったり来たりしているように見えながらも実は変化している ● 動的型付け言語と静的型付け言語 ○ C, Java → Ruby, Python → Go, Rust ● システムの分散と集中 ○ モノリス → マイクロサービス → モジュラモノリス

Slide 60

Slide 60 text

組織にも螺旋が存在する元々関心ごとの広い2チームで開発していたところから、チームが分かれて関心ごとが狭いチームがいくつもできた。今はまた必要に応じて関心ごとを広げるような動きが出てきつつある。振り子のように戻ったように見えるが、これらを通して顧客への価値提供は加速している。

Slide 61

Slide 61 text

さいごのまとめ 1. 組織の課題にはソフトウェアアーキテクチャと組織構造の両面からアプローチが可能。選択肢を広く持つ 2. 組織の課題の螺旋を意識する。課題を構造的に捉えよう課題を立体的に捉えながら目の前の課題を1つずつ対処をしていきましょう

Slide 62

Slide 62 text

参考文献 ● 『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 https://www.youtube.com/watch?v=ydQ2xoc49Lc ● チームトポロジーを成功させる実践方法の探求 - Team Topologies Study # ちいとぽStudy #ちいとぽ https://www.youtube.com/watch?v=uJL3M7R8MLc