技術的負債を組織課題として解く-増えすぎたマイクロサービスとの戦い-

by reimaru

Embed

Start on current slide

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

マイクロサービス・アーキテクチャは好きですか? 好き 1

Slide 3

Slide 3 text

マイクロサービス・アーキテクチャは好きですか? 好き嫌い 2

Slide 4

Slide 4 text

マイクロサービス・アーキテクチャは好きですか? 好き嫌い好きだった 3

Slide 5

Slide 5 text

19 コンポーネント 15 正社員エンジニア 4

Slide 6

Slide 6 text

今日話すこと 1. なぜ増えたのか 2. 何に困ったか 3. どのように向き合ってきたか 4. どうすべきだったか・教訓 5

Slide 7

Slide 7 text

1. なぜ増えたのか 6

Slide 8

Slide 8 text

自己紹介・会社紹介 7

Slide 9

Slide 9 text

自己紹介 reimaru（丸山礼）文系学部卒 2018年~ クラウド系SIerに入社。BtoB SaaS開発 2022年~ HERPでHERP Hireの開発、マネジメントなど最近息子が生まれました 8

Slide 10

Slide 10 text

株式会社HERP Mission 採用を変え、日本を強く。 2017年設立従業員数102名（正社員）※2026年6月時点事業内容: HR Techプロダクトの開発・提供 9

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

当時のシステム構成 12

Slide 14

Slide 14 text

各チームに設計や技術選定が任されていた開発する機能やテーマごとに複数のチームに分かれていたチームごとに技術選定や設計の権限が移譲されていたマイクロサービスにしていくと良さそう、という雰囲気は共有されていたまさにコンウェイの法則 13

Slide 15

Slide 15 text

コンポーネント数が増えた要因 BE/FEの強い分離チーム、コードベース、デプロイを分離していた関数型言語で新規開発しがちだったモノリスで採用されていたのは TypeScriptだった ※現在はTypeScript が社内標準言語になっています最初から抽象的な基盤を作ろうとした「将来他のプロダクトからも使われるかもしれないから、抽象的なサービスとしてつくろう」（結局使われなかった） 14

Slide 16

Slide 16 text

2. なぜ困ったか 15

Slide 17

Slide 17 text

1. そもそも複雑性が高かった 2. 状況の変化により複雑性に耐えられなくなった 16

Slide 18

Slide 18 text

1. そもそも複雑性が高かったマイクロサービスというより「分散モノリス」のようになってしまっていた機能開発時に全てのコンポーネントに変更・デプロイ必要インターフェース定義がオーバーヘッドになりがちに 1.そもそも複雑性が高かった 17

Slide 19

Slide 19 text

2.状況の変化により複雑性に耐えられなくなったマルチプロダクト化 2024年始ごろ、HERP Hireに加えて、複数の新規事業の立ち上げにチャレンジすることに多くのメンバーが新規事業のチームに異動残った2チーム(計10人弱)でHERP Hire（＝たくさんのコンポーネント群）を開発・運用することに 2.状況の変化により複雑性に耐えられなくなった 18

Slide 20

Slide 20 text

マイクロサービスのメリットを活かせなくなった強力なモジュール境界 git repoも分かれていて都度CI/CDを設定、ライブラリ更新が重複開発環境で複数プロセス立ち上げが必要 2.状況の変化により複雑性に耐えられなくなった独立デプロイそんなに頻繁にデプロイしなくなった少数のチームでたくさんのコンポーネントのデプロイが必要技術的多様性少数チームでたくさんの技術スタックを把握しないといけない 19

Slide 21

Slide 21 text

3. どう向き合ってきたか 20

Slide 22

Slide 22 text

個人的な改善活動の発生と失敗（2023~2024年）「新機能からモノリスに追加していく! 既存機能は後でモノリスに統合する」既存機能がなかなか統合されず同じ機能なのにモノリス版と分散版ができてしまい、余計に認知負荷が高まる似たような個人レベルの取り組みの失敗が多数 21

Slide 23

Slide 23 text

リアーキテクチャは認知負荷が高く長期のコミットが必要認知負荷が高く属人化しやすいインフラ含め土台から変更するため認知負荷が大きい仕様に対する理解も必要多様な技術スタックを把握する必要がある長期間コミットが必要でやり切るハードルが高い繊細なリリース制御や事前準備が必要組織的な目標にして、一定のリソースを長期間投下し切る必要があったが…… 22

Slide 24

Slide 24 text

ビジネスサイドはむしろ負債解消に前向きだった PdM陣も元々理解があった HERP Hire にも引き続き爆発的成長が求められた新規事業からHERP Hireの機能やデータを利用していた HERP Hireの開発スピードの遅さが他の新規事業のスピードを制約してしまう 23

Slide 25

Slide 25 text

エンジニアが組織だって動けていなかった技術的課題についての責任主体が曖昧エンジニア組織横断の責任主体が曖昧個人の自律性が高い一方で組織的な動きは個人の働きかけに依存 24

Slide 26

Slide 26 text

「決める人」を決めたエンジニア統括というポジションが生まれた TypeScriptを正式な社内標準言語として決定したチームにマネージャーを設定 1on1や評価なども行うようになった負債解消などの意思決定・実行責任者が明確になった 25

Slide 27

Slide 27 text

課題についての認識を合わせる課題マップ課題や困りを付箋で貼る因果関係と依存関係を矢印で結ぶ課題マップの全体像 26

Slide 28

Slide 28 text

課題についての認識を合わせる矢印の根っこが分散モノリスに集まっている 27

Slide 29

Slide 29 text

試しに小さく始めてみる長期的に減らしていく想定で、試しに1つ消してみる細かい計画を立てても実現可能性や工数の見積りが困難だった達成確度が高く、インパクトが大きいものから取り組む期限を切った目標にして、機能開発目標と同列で追っていく 28

Slide 30

Slide 30 text

OCaml製サービスの TypeScript リプレイス（2025年春~夏）達成できそう責務がシンプルで少ないサービス独自のDBを持たないインパクトもそこそこ大きそう唯一のOCaml製触れる人が少ない逆に消せたらOCamlをスタックから消せる 29

Slide 31

Slide 31 text

OCaml製サービスの TypeScript リプレイス（2025年春~夏）結果実装2ヶ月、テスト・リリース・監視・修正など3ヶ月で完全にリプレイスできた 1人担当 + 1人レビュー体制 10%→ 0%に切り戻すのを2回 AIエージェントを使える今ならもっと早くできるかもやればできる自信がついた OCaml製サービスの TypeScript リプレイス 30

Slide 32

Slide 32 text

モノリスの責務整理（2025年春~夏）マイクロサービス想定だったため、必要以上に複雑なアーキテクチャだった 31

Slide 33

Slide 33 text

モノリスの責務整理（2025年春~夏）各種マイクロサービスをモノリスBEで隠蔽インターフェースがREST APIのみになりシンプルに今後マイクロサービスを廃止・統合するときにFEまで影響が波及しなくなった 32

Slide 34

Slide 34 text

git repo とデプロイも統合（2025年冬）開発時にFE/BEのリビジョン差異を気にする必要があり認知負荷が増大 FE/BE両方ともデプロイしないと機能提供できないデプロイやデプロイ前の動作確認も手間に 33

Slide 35

Slide 35 text

git repo とデプロイも統合（2025年冬） 34

Slide 36

Slide 36 text

デプロイ作業の負荷が減ったことがデプロイ頻度改善のきっかけにモノリスの月間デプロイ数推移(2025/05 → 2026/07) ※平行してE2Eテスト整備やAI活用も行っている 35

Slide 37

Slide 37 text

変更リードタイムも改善傾向変更リードタイム 2025/05~2026/07 ※コミットからデプロイまでの期間 ※平行してE2Eテスト整備やAI活用も行っている 36

Slide 38

Slide 38 text

現在 37

Slide 39

Slide 39 text

4. 教訓 38

Slide 40

Slide 40 text

アーキテクチャの分離は慎重にプロセス・デプロイ・言語の分離はコストが大きい後戻りしやすい分離にするモジュラーモノリス packageに切り出す依存を単方向にする 39

Slide 41

Slide 41 text

プロセス・デプロイ・言語の分離はここぞというときにデプロイ頻度が明確に違う可用性・スケーラビリティなど運用特性が違う特定の言語でしかできないことがある HERPの場合スクレイピングを行うコンポーネント認証基盤 API Gateway 40

Slide 42

Slide 42 text

全体最適なアーキテクチャになる仕組みを作るチームの視点だけで決定すると局所最適になる可能性がある事業や組織の展望も考慮して設計する必要があったプロダクトの市場規模はどのくらい? 組織として継続的に投資できるリソースはどのくらい? HERPの場合: 俯瞰する責任主体を決める 41

Slide 43

Slide 43 text

We are hiring! HERP 採用サイト recruit.herp.co.jp @rei_maruyama_ 資料についてのお問い合わせはSNSでもお気軽にどうぞ! HERP 技術ブログ tech-hub.herp.co.jp 42

Slide 44

Slide 44 text

Appendix 43

Slide 45

Slide 45 text

補足 P.28~29 カナリアリリースには以下を使った istio のHTTPRouteDestination の weight の設定 https://istio.io/latest/docs/reference/config/networking/virtualservice/#HTTPRouteDestination 他のプロジェクトではLaunchDarkly（Feature Toggleのためのサービス）の Percentage rollouts 機能を使うこともあった https://launchdarkly.com/docs/home/releases/percentage-rollouts 44

Slide 46

Slide 46 text

補足 P.28~29 テスト手法についてリプレイス先にhonoを使っていたので、hono app の fetch メソッドで開発中のサーバーにリクエストすることができた https://hono.dev/docs/api/hono#fetch そこで、既存の旧システムに対して通常の fetch 関数を使ってテストコードを記述したあと、fetch 部分だけ新システムのapp.fetch に切り替えて実行することで、同じテストコードで新旧システムの外形的な動作が変わらないか検証することができた。 OCaml は厳密には BuckleScript（現 ReScript）で JavaScriptにコンパイルされてNode.jsで動いていた 45