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

2024/12/24 に開催された「【アーキテクチャと組織の変遷】スピードとスケーラビリティの両立-基盤刷新・モジュラモノリスの行先-」の登壇資料です。
https://findy-tools.connpass.com/event/338716/

# スライド内に記載したURL
組織の立ち上げ期から取り入れるチートポTIPS
https://tech.timee.co.jp/entry/tips-on-teamtopologies-in-early-stage

『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2
https://www.youtube.com/watch?v=ydQ2xoc49Lc

チームトポロジーを成功させる実践方法の探求 - Team Topologies Study #ちいとぽStudy #ちいとぽ
https://www.youtube.com/watch?v=uJL3M7R8MLc

Transcript

1. 2024/12/24 【アーキテクチャと組織の変遷】スピードとスケーラビリティの両立 　　　　　　 -基盤刷新・モジュラモノリスの行先- 株式会社タイミー　新谷哲平 3年でバックエンドエンジニアが5倍に 増えても破綻しなかったアーキテクチャ そして、これから @euglena1215
2. 自己紹介 Shintani Teppei（@euglena1215） • 株式会社タイミー（2023年1月入社） • バックエンド テックリード ◦ プロダクト開発に直接携わらない形 ◦ バックエンド領域における開発プロセス・ 仕組み作り含めたアーキテクトのような役割
3. この発表での注意書き • バックエンドの話が中心です ◦ モバイルアプリ、Webフロントエンドの話は基本出てきません • ソフトウェアアーキテクチャをアーキテクチャと略します ◦ インフラアーキテクチャの話は出てきません • 組織構造ではプロダクト開発チームを主眼において話します ◦ タイミーには様々なプロダクト開発チームを支えるチームが存在しますが今回は出てきません ◦ ここについて知りたい方は 組織の立ち上げ期から取り入れるチートポTIPS をご覧ください ▪ ref. https://tech.timee.co.jp/entry/tips-on-teamtopologies-in-early-stage
4. 2024/12/24 【アーキテクチャと組織の変遷】スピードとスケーラビリティの両立 　　　　　　 -基盤刷新・モジュラモノリスの行先- 株式会社タイミー　新谷哲平 3年でバックエンドエンジニアが5倍に 増えても破綻しなかったアーキテクチャ そして、これから @euglena1215
5. 3年間のタイミーの変化 年間売上 バックエンドエンジニア数
6. 3年間のタイミーの変化 1,299 百万円 年間売上 バックエンドエンジニア数 6 名 FY21/10
7. 3年間のタイミーの変化 1,299 百万円 年間売上 26,880 百万円 20.7x バックエンドエンジニア数 6 名 32 名 5.3x FY21/10 FY24/10
8. 3年間のタイミーの変化 1,299 百万円 年間売上 26,880 百万円 20.7x バックエンドエンジニア数 6 名 32 名 5.3x FY21/10 FY24/10 3年前時点でこれからエンジニアを増やしていくことは決めていた
9. どんな話をするか 過去編 現在編 未来編 2021年に何を考え、どんな準備をしていたのか 2024年の今、振り返ってどうだったのか これからのこと ※ 自分が入社したのは2023年1月 過去編は社内外の情報や直接当時の CTO から聞いた話。歴史家の気持ちで話します。 現在編・未来編は当事者として話します。
10. 1 急拡大が予想できた 2021年に何を考え、 どんな準備をしていたのか 過去編
11. 急拡大が予想できた2021年に何を考えていたか kameike / CTO(当時)
12. 急拡大が予想できた2021年に何を考えていたか 「今までの少人数での開発スタイルでは 問題が起きそう。そのために変化して いかないと...！」 kameike / CTO(当時)
13. 急拡大が予想できた2021年に何を考えていたか 「今までの少人数での開発スタイルでは 問題が起きそう。そのために変化して いかないと...！」 kameike / CTO(当時) 組織をスケールさせるための準備をしていく
14. 前提：2021年時点でのアーキテクチャと組織構造
15. 前提の前提：提供しているインターフェース 対象 プラットフォーム iOS/Android ワーカー クライアント （店舗） クライアント （企業） 社内全般 Web モノリス Ruby on Rails アプリケーション
16. 2021年時点の構造：アーキテクチャ 対象 プラットフォーム iOS/Android ワーカー クライアント （店舗） クライアント （企業） 社内全般 Web モノリス Ruby on Rails アプリケーション モノリスの Ruby on Rails アプリケーション1つで運用
17. 2021年時点の構造：組織構造 対象 プラットフォーム iOS/Android ワーカー クライアント （店舗） クライアント （企業） 社内全般 Web モノリス Ruby on Rails アプリケーション ワーカーチーム / クライアントチーム の2チームを編成 一気通貫の開発を行うために 職能横断のチームにしていた 社内管理画面は みんなで共有
18. 前提：2021年時点でのアーキテクチャと組織構造 • アーキテクチャ： ◦ モノリス Ruby on Rails アプリケーション • 組織構造： ◦ ワーカー（toC）チーム / クライアント（toB）チームが存在 ◦ 一気通貫の開発を行うために職能横断のチーム → バックエンドエンジニア目線だと、 2チームで1つのモノリスを 開発・運用している状態
19. アーキテクチャ：モノリスからモジュラモノリスへ チームの独立性を保ちスケールする組織を目指すため、 単一のモノリスではなく独立したモジュールから構成されたモノリスへ
20. 組織構造：ステークホルダーを軸としたチームからの変化 ワーカーチーム・クライアントチームは職能横断のチームになっていた。 そのため、それぞれのチームが独立して機能開発を行えることもあった。 しかし、そうでないケースも発生していた。
21. タイミーを利用する際の流れ
22. タイミーを利用する際の流れ ここ！
23. タイミーを利用する際の流れ ワーカー・クライアント双方に関わる機能の改善 はチーム間のコミュニケーションが必要
24. タイミーを利用する際の流れ マッチングプラットフォームである タイミーにとってとても重要な機能 重要 = 変更頻度が高い & スピード感が大事
25. タイミーを利用する際の流れ 独立して開発できる体制を目指すため チームの境界を変更する
26. Before：チームの境界 クライアントチーム ワーカーチーム ✂
27. After：チームの境界 マッチング領域 ワーカーとクライアントの 出会いを最適化 ✂ スポットワークシステム領域 スポットワークにまつわる手続きを なめらかにする
28. 準備：組織構造 Before： • ワーカーチーム ◦ ワーカーの体験を高めていく • クライアントチーム ◦ クライアントの体験を高めていく After： • マッチング領域 ◦ ワーカーとクライアントの出会いを最適化し、ビジネスをスケールさせる • スポットワークシステム領域 ◦ 出退勤や労務管理など、スポットワークにまつわる手続きをなめらかにする
29. 過去編まとめ：目指す開発スタイルの変化 少人数でなんとかする 組織的なものづくり
30. 過去編まとめ 組織的なものづくりを行い、スケールに耐えられるような構造を作るため ソフトウェアアーキテクチャ・組織構造の両面から変化を促した。 • モノリス から モジュラモノリス へ • ワーカー/クライアント から マッチング/スポットワークシステム へ
31. 2 2024年の今、 振り返ってどうだったのか 現在編
32. 2024年の今、振り返ってどうだったのか 以下の2点について振り返ってみる 1. 狙い通りのアーキテクチャ・組織構造になったのか 2. 組織はうまくスケールできたのか
33. 振り返り：ソフトウェアアーキテクチャ 目指していたのはモジュラモノリス
34. 振り返り：ソフトウェアアーキテクチャ 結果：ある程度ディレクトリとして分けられているものの、自由かつ相互に参照可能で 独立していないものが多数
35. 振り返り：組織構造 目指していたのはマッチング領域 / スポットワークシステム領域をベースとした チーム編成 マッチング領域 ✂ スポットワークシステム領域
36. 振り返り：組織構造 結果：それぞれの領域にチームが紐付き、8名前後のプロダクト開発チームが 合計10チームほど存在する それぞれがプロダクトゴールを持ち、独立して動けている状態
37. 狙い通りのアーキテクチャ・組織構造になったのか？ • アーキテクチャ：モノリスのまま ☔ • 組織構造：マッチング/スポットワークシステム領域 に対して 　　　　　プロダクト開発チームが合計10チーム存在 ☀ → プロダクト開発をしているチームが10チームあって 　 バックエンドはみんな同じモノリスの中で開発をしている状態
38. 組織はうまくスケールできたのか？
39. できた！ ...と言って差し支えないはず 組織はうまくスケールできたのか？
40. うまくスケールできたと考える理由 1. 2. 3. 組織はうまくスケールできたのか？
41. うまくスケールできたと考える理由 1. 開発の並列度が上がり、顧客への新たな価値提供は加速している（主観） 2. 3. 組織はうまくスケールできたのか？
42. うまくスケールできたと考える理由 1. 開発の並列度が上がり、顧客への新たな価値提供は加速している（主観） 2. d/d/d は3年間で0.5→0.4に減少傾向ではあるものの バックエンドエンジニア数が5倍になってこの減少幅なら十分だろう 3. 組織はうまくスケールできたのか？
43. うまくスケールできたと考える理由 1. 開発の並列度が上がり、顧客への新たな価値提供は加速している（主観） 2. d/d/d は3年間で0.5→0.4に減少傾向ではあるものの バックエンドエンジニア数が5倍になってこの減少幅なら十分だろう 3. バックエンドエンジニアの入社後の早期離職はなし 組織はうまくスケールできたのか？
44. モジュラモノリスにはなっていないものの、必要に応じて改善は行われてきた • バックエンドとフロントエンドの密結合解消 ◦ クライアント側画面のSPA化 • 他と取り扱いが異なる領域の分離 ◦ 銀行周りのモノリスからの切り出し なぜスケールできたのか？：アーキテクチャ面
45. モジュラモノリスにはなっていないものの、必要に応じて改善は行われてきた • バックエンドとフロントエンドの密結合解消 ◦ クライアント側画面のSPA化 • 他と取り扱いが異なる領域の分離 ◦ 銀行周りのモノリスからの切り出し なぜスケールできたのか？：アーキテクチャ面 チームで独立した開発を行えることを目的とするのではなく 目の前の問題に1つずつ取り組んでいた
46. プロダクト開発チームが独立して開発できる状態になっていた なぜスケールできたのか？：組織面
47. プロダクト開発チームが独立して開発できる状態になっていた Q. モノリスなのになぜ独立して開発できたのか？ → チームの責務が安定していて変更範囲が限られていたから なぜスケールできたのか？：組織面
48. プロダクト開発チームが独立して開発できる状態になっていた Q. モノリスなのになぜ独立して開発できたのか？ → チームの責務が安定していて変更範囲が限られていたから なぜスケールできたのか？：組織面 学び：チームの責務がある程度安定していれば、 　　　機械的な境界がなくとも独立した開発は可能 チームが普段変更しない機能はそもそも普段の会話に登場してこないので認知負荷が高まることもない
49. 現在編まとめ：2024年の今、振り返ってどうだったのか 1. 狙い通りのアーキテクチャ・組織構造になったのか → アーキテクチャはモノリスのまま、組織構造は狙い通りに 2. 組織はうまくスケールできたのか → できた！
50. 3 そしてこれから 未来編
51. これまでのあらすじ 組織をスケールさせるためにチームの独立性を高める活動をした その結果、独立して開発が行えるチームをいくつも作ることができた
52. プロダクト開発チームが増えたことによる弊害
53. プロダクト開発チームが増えたことによる弊害 コードベース中に知らないコードが 増えるようになった 自チームが見ている以上の範囲に対して オーナーシップを感じることが難しくなりつつある 「この機能は自分たちが見る”べき”なのか」 出典：畑村 洋太郎 著,技術の創造と設計,岩波書店,P17 引用
54. プロダクト開発チームが増えたことによる弊害 コードベース中に知らないコードが 増えるようになった 自チームが見ている以上の範囲に対して オーナーシップを感じることが難しくなりつつある 「この機能は自分たちが見る”べき”なのか」 出典：畑村 洋太郎 著,技術の創造と設計,岩波書店,P17 引用 オーナーシップを感じるには “認知していること ”が重要
55. プロダクト開発チームが増えたことによる弊害 コードベース中に知らないコードが 増えるようになった 自チームが見ている以上の範囲に対して オーナーシップを感じることが難しくなりつつある 「この機能は自分たちが見る”べき”なのか」 出典：畑村 洋太郎 著,技術の創造と設計,岩波書店,P17 引用 知らないことには オーナーシップを感じられない
56. プロダクト開発チームが増えたことによる弊害 コードベース中に知らないコードが 増えるようになった 自チームが見ている以上の範囲に対して オーナーシップを感じることが難しくなりつつある 「この機能は自分たちが見る”べき”なのか」 出典：畑村 洋太郎 著,技術の創造と設計,岩波書店,P17 引用 でも認知する範囲を広げると認知負荷が ...
57. 認知可能な範囲は広げたいが、認知負荷は高めたくない エンジニアリングと組織の両面からアプローチ可能。やっていくしかない アプローチの一例 - エンジニアリング - 適切な抽象化、問題解決の為のモジュール分割、型による開発支援、etc… - 組織 - チーム間のコミュニケーションの敷居を下げる、チーム境界の見直し・統合、etc…
58. 最後に
59. 技術の螺旋 技術トレンドの変化には螺旋が存在する 振り子のように行ったり来たりしているように見えながらも実は変化している • 動的型付け言語と静的型付け言語 ◦ C, Java → Ruby, Python → Go, Rust • システムの分散と集中 ◦ モノリス → マイクロサービス → モジュラモノリス
60. 組織にも螺旋が存在する 元々関心ごとの広い2チームで開発していたところから、チームが分かれて 関心ごとが狭いチームがいくつもできた。 今はまた必要に応じて関心ごとを広げるような動きが出てきつつある。 振り子のように戻ったように見えるが、 これらを通して顧客への価値提供は加速している。
61. さいごのまとめ 1. 組織の課題にはソフトウェアアーキテクチャと組織構造の両面から アプローチが可能。選択肢を広く持つ 2. 組織の課題の螺旋を意識する。課題を構造的に捉えよう 課題を立体的に捉えながら 目の前の課題を1つずつ対処をしていきましょう
62. 参考文献 • 『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 https://www.youtube.com/watch?v=ydQ2xoc49Lc • チームトポロジーを成功させる実践方法の探求 - Team Topologies Study # ちいとぽStudy #ちいとぽ https://www.youtube.com/watch?v=uJL3M7R8MLc