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

技術的負債に向き合うConference 2026 で発表した資料です。
元ネタになったブログ記事: https://reimaru.hatenablog.com/entry/how_microservices_sprawled_in_a_small_team

Transcript

2. マイクロサービス・アーキテクチャは好きですか? 好き 1
3. マイクロサービス・アーキテクチャは好きですか? 好き 嫌い 2
4. マイクロサービス・アーキテクチャは好きですか? 好き 嫌い 好きだった 3
5. 19 コンポーネント 15 正社員エンジニア 4
6. 今日話すこと 1. なぜ増えたのか 2. 何に困ったか 3. どのように向き合ってきたか 4. どうすべきだったか・教訓 5
7. 1. なぜ増えたのか 6
8. 自己紹介・会社紹介 7
9. 自己紹介 reimaru（丸山礼） 文系学部卒 2018年~ クラウド系SIerに入社。BtoB SaaS開発 2022年~ HERPでHERP Hireの開発、マネジメントなど 最近息子が生まれました 8
10. 株式会社HERP Mission 採用を変え、日本を強く。 2017年設立 従業員数102名（正社員）※2026年6月時点 事業内容: HR Techプロダクトの開発・提供 9
13. 当時のシステム構成 12
14. 各チームに設計や技術選定が任されていた 開発する機能やテーマごとに複数のチームに分かれていた チームごとに技術選定や設計の権限が移譲されていた マイクロサービスにしていくと良さそう、という雰囲気は共有されていた まさにコンウェイの法則 13
15. コンポーネント数が増えた要因 BE/FEの強い分離 チーム、コードベース、 デプロイを分離していた 関数型言語で新規 開発しがちだった モノリスで採用 されていたのは TypeScriptだった ※現在はTypeScript が社内標準言語 になっています 最初から抽象的な 基盤を作ろうとした 「将来他のプロダクトか らも使われるかもしれ ないから、抽象的なサ ービスとしてつくろう」 （結局使われなかった） 14
16. 2. なぜ困ったか 15
17. 1. そもそも複雑性が高かった 2. 状況の変化により複雑性に耐えられなくなった 16
18. 1. そもそも複雑性が高かった マイクロサービスというより「分散モノリス」のようになってしまっていた 機能開発時に全てのコンポー ネントに変更・デプロイ必要 インターフェース定義がオ ーバーヘッドになりがちに 1.そもそも複雑性が高かった 17
19. 2.状況の変化により複雑性に耐えられなくなった マルチプロダクト化 2024年始ごろ、HERP Hireに加えて、複数の新規事業の立ち上げにチャレンジすることに 多くのメンバーが新規事業のチームに異動 残った2チーム(計10人弱)でHERP Hire（＝たくさんのコンポーネント群）を開発・運用することに 2.状況の変化により複雑性に耐えられなくなった 18
20. マイクロサービスのメリットを活かせなくなった 強力なモジュール境界 git repoも分かれてい て都度CI/CDを設定、 ライブラリ更新が重複 開発環境で複数プロ セス立ち上げが必要 2.状況の変化により複雑性に耐えられなくなった 独立デプロイ そんなに頻繁にデ プロイしなくなった 少数のチームでたく さんのコンポーネン トのデプロイが必要 技術的多様性 少数チームでたくさん の技術スタックを把 握しないといけない 19
21. 3. どう向き合ってきたか 20
22. 個人的な改善活動の発生と失敗（2023~2024年） 「新機能からモノリスに追加していく! 既存機能は後でモノリスに統合する」 既存機能がなかなか統合されず 同じ機能なのにモノリス版と分散版ができてしまい、余計に認知負荷が高まる 似たような個人レベルの取り組みの失敗が多数 21
23. リアーキテクチャは認知負荷が高く長期のコミットが必要 認知負荷が高く属人化しやすい インフラ含め土台から変更するため認知負荷が大きい 仕様に対する理解も必要 多様な技術スタックを把握する必要がある 長期間コミットが必要でやり切るハードルが高い 繊細なリリース制御や事前準備が必要 組織的な目標にして、一定のリソースを長期間投下し切る必要があったが…… 22
24. ビジネスサイドはむしろ負債解消に前向きだった PdM陣も元々理解があった HERP Hire にも引き続き爆発的成長が求められた 新規事業からHERP Hireの機能やデータを利用していた HERP Hireの開発スピードの遅さが他の新規事業のスピードを制約してしまう 23
25. エンジニアが組織だって動けていなかった 技術的課題についての責任主体が曖昧 エンジニア組織横断の責任主体が曖昧 個人の自律性が高い一方で組織的な動きは個人の働きかけに依存 24
26. 「決める人」を決めた エンジニア統括という ポジションが生まれた TypeScriptを正式な社内 標準言語として決定した チームにマネージャーを設定 1on1や評価なども行うようになった 負債解消などの意思決定・ 実行責任者が明確になった 25
27. 課題についての認識を合わせる 課題マップ 課題や困りを付箋で貼る 因果関係と依存 関係を矢印で結ぶ 課題マップの全体像 26
28. 課題についての認識を合わせる 矢印の根っこが分散モノリスに集まっている 27
29. 試しに小さく始めてみる 長期的に減らしていく想定で、試しに1つ消してみる 細かい計画を立てても実現可能性や工数の見積りが困難だった 達成確度が高く、インパクトが大きいものから取り組む 期限を切った目標にして、機能開発目標と同列で追っていく 28
30. OCaml製サービスの TypeScript リプレイス （2025年春~夏） 達成できそう 責務がシンプルで少ない サービス独自のDBを持たない インパクトもそこそこ大きそう 唯一のOCaml製 触れる人が少ない 逆に消せたらOCamlをスタックから消せる 29
31. OCaml製サービスの TypeScript リプレイス （2025年春~夏） 結果 実装2ヶ月、テスト・リリース・監視・修正など3ヶ月で完全にリプレイスできた 1人担当 + 1人レビュー 体制 10%→ 0%に切り戻すのを2回 AIエージェントを使える今ならもっと早くできるかも やればできる自信がついた OCaml製サービスの TypeScript リプレイス 30
32. モノリスの責務整理 （2025年春~夏） マイクロサービス想定だったため、必要以上に複雑なアーキテクチャだった 31
33. モノリスの責務整理 （2025年春~夏） 各種マイクロサービスをモノリスBEで隠蔽 インターフェースがREST APIのみになりシンプルに 今後マイクロサービスを廃止・統合するときにFEまで影響が波及しなくなった 32
34. git repo と デプロイも統合 （2025年冬） 開発時にFE/BEのリビジョン差異を気にする必要があり認知負荷が増大 FE/BE両方ともデプロイしないと機能提供できない デプロイやデプロイ前の動作確認も手間に 33
35. git repo と デプロイも統合 （2025年冬） 34
36. デプロイ作業の負荷が減ったことがデプロイ頻度改善のきっかけに モノリスの月間デプロイ数推移(2025/05 → 2026/07) ※平行してE2Eテスト整備やAI活用も行っている 35
37. 変更リードタイムも改善傾向 変更リードタイム 2025/05~2026/07 ※コミットからデプロイまでの期間 ※平行してE2Eテスト整備やAI活用も行っている 36
38. 現在 37
39. 4. 教訓 38
40. アーキテクチャの分離は慎重に プロセス・デプロイ・言語の分離はコストが大きい 後戻りしやすい分離にする モジュラーモノリス packageに切り出す 依存を単方向にする 39
41. プロセス・デプロイ・言語の分離はここぞというときに デプロイ頻度が明確に違う 可用性・スケーラビリティなど運用特性が違う 特定の言語でしかできないことがある HERPの場合 スクレイピングを行うコンポーネント 認証基盤 API Gateway 40
42. 全体最適なアーキテクチャになる仕組みを作る チームの視点だけで決定すると局所最適になる可能性がある 事業や組織の展望も考慮して設計する必要があった プロダクトの市場規模はどのくらい? 組織として継続的に投資できるリソースはどのくらい? HERPの場合: 俯瞰する責任主体を決める 41
43. We are hiring! HERP 採用サイト recruit.herp.co.jp @rei_maruyama_ 資料についてのお問い合わせはSNSでもお気軽にどうぞ! HERP 技術ブログ tech-hub.herp.co.jp 42
44. Appendix 43
45. 補足 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
46. 補足 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