ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Technical Debt at Findy

© Findy Inc. 2024.12.03 ファインディの4年にわたる技術的負債の返済 1 技術的負債返済の意義を考える、あの時の"やる‧やらない"判断基準どうしてた？ Findy CTO
佐藤将⾼(@ma3tk)

© 2024 Findy Inc. 挑戦するエンジニアのプラットフォームをつくる。ビジョンつくる⼈がもっとかがやけば、世界はきっと豊かになる。経営理念
会社概要会社名ファインディ株式会社 / Findy Inc. 代表取締役⼭⽥裕⼀朗設⽴ 2014 年 2 ⽉ ※ 本格的な事業開始は2016年7⽉社員数 282 名 (2024年12⽉現在) 資本⾦ 18 億 5,043 万円 ※ 資本準備⾦含む住所東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー 5階事業許可番号 13-ユ-308478 サービス ‧ スカウト型リクルーティングサービス「Findy」 ‧ ハイスキルな業務委託エンジニア紹介サービス「Findy Freelance」 ‧ エンジニア組織⽀援SaaS「Findy Team+」 ‧ 開発ツールに特化したレビューサイト「Findy Tools」投資家グローバル‧ブレイン、ユナイテッド、SMBCベンチャーキャピタル、KDDI、JA三井リース、みずほキャピタル、博報堂ＤＹベンチャーズ、Carbide Ventures、等

© Findy Inc. • ファインディの2020年は⼤きな転換 ◦ 当時の状況と背景 ◦ 数年がかりの取り組み ◦
今の状況 • 現在でも減らし続ける仕組み • まとめアジェンダ 7

© Findy Inc. • ファインディの2020年は⼤きな転換 ◦ 当時の状況と背景 ◦ 数年がかりの取り組み ◦
今の状況 • 現在でも減らし続ける仕組み • まとめアジェンダ 8

© Findy Inc. • 組織体制 ◦ フルタイムエンジニア5-6名程度 ◦ 開発速度の遅さが全体で課題に 2020年のファインディの組織
12

© Findy Inc. • 組織体制 ◦ フルタイムエンジニア5-6名程度 ◦ 開発速度の遅さが全体で課題に ▪
メンバーは献⾝的にコミットしてくれているものの、組織で仕組みを変えないといけない部分が多々あった 2020年のファインディの組織 13

© Findy Inc. • 技術的課題 ◦ Backend/Frontendが同⼀サーバーで密結合 ◦ 古いライブラリバージョンとセキュリティも⼼配 ◦
不安定なコードベース ◦ テストコードの不⾜ ◦ 認知負荷の⾼いコード ◦ インフラの⽼朽化 2020年のファインディの課題 17

不安定なコードベース ◦ テストコードの不⾜ ◦ 認知負荷の⾼いコード ◦ インフラの⽼朽化 • 開発プロセスの課題 2020年のファインディの課題 18

不安定なコードベース ◦ テストコードの不⾜ ◦ 認知負荷の⾼いコード ◦ インフラの⽼朽化 • 開発プロセスの課題 ◦ リリースは週1回が限界 ◦ PR30件以上が常時滞留 ◦ ⾼い障害発⽣率 ◦ レビュー質の低下 ◦ コンフリクトの頻発 ◦ リリース作業に半⽇以上必要 2020年のファインディの課題 19

不安定なコードベース ◦ テストコードの不⾜ ◦ 認知負荷の⾼いコード ◦ インフラの⽼朽化 • 開発プロセスの課題 ◦ リリースは週1回が限界 ◦ PR30件以上が常時滞留 ◦ ⾼い障害発⽣率 ◦ レビュー質の低下 ◦ コンフリクトの頻発 ◦ リリース作業に半⽇以上必要 2020年のファインディの課題 20 ものすごい課題感が多かった

© Findy Inc. • システム構成の問題 ◦ Backend/Frontendが同⼀サーバー上で動作 ◦ サーバー負荷が画⾯表⽰に直結 ◦
APIと画⾯の密結合による開発の⾮効率 ◦ Backend/Frontendの同時リリースが必須過去の主な技術的負債 23

APIと画⾯の密結合による開発の⾮効率 ◦ Backend/Frontendの同時リリースが必須 • コードベースの課題過去の主な技術的負債 24

APIと画⾯の密結合による開発の⾮効率 ◦ Backend/Frontendの同時リリースが必須 • コードベースの課題 ◦ テストコードの圧倒的な不⾜ ◦ セキュリティアップデートができていない状態 ◦ ⼤規模なPRによるレビュー効率の低下 ◦ コンフリクト解消のための無駄なコミュニケーション過去の主な技術的負債 25

不安定なコードベース ◦ テストコードの不⾜ ◦ 認知負荷の⾼いコード ◦ インフラの⽼朽化 • 開発プロセスの課題 ◦ リリースは週1回が限界 ◦ PR30件以上が常時滞留 ◦ ⾼い障害発⽣率 ◦ レビュー質の低下 ◦ コンフリクトの頻発 ◦ リリース作業に半⽇以上必要 2020年のファインディの課題 26 伸びしろが多かった…

© Findy Inc. • 最初はお⾦がなかったので、1回⽬のリリースが⼤事だった ◦ 当時はそれでよかった ◦ 知⾒もなく、頼れる⼈もいなかったので最速で出せる⽅法を編み出した ▪
フロントエンドとバックエンドとインフラを1⼈で構築して多くの⼈に提供したことがなかった技術的負債が⽣まれた背景 31

フロントエンドとバックエンドとインフラを1⼈で構築して多くの⼈に提供したことがなかった ◦ DesignDocとしてコンテキストを残せなかった ▪ 僕のみぞ知り、他のメンバーは知らなかった ▪ 聞いてくれればいいじゃん、と思っていた • あんなに前職でドキュメント書いていたのに… 技術的負債が⽣まれた背景 32

フロントエンドとバックエンドとインフラを1⼈で構築して多くの⼈に提供したことがなかった ◦ DesignDocとしてコンテキストを残せなかった ▪ 僕のみぞ知り、他のメンバーは知らなかった ▪ 聞いてくれればいいじゃん、と思っていた • あんなに前職でドキュメント書いていたのに… • 新規開発が優先で、負債を解消するための採⽤ができなかった技術的負債が⽣まれた背景 33

フロントエンドとバックエンドとインフラを1⼈で構築して多くの⼈に提供したことがなかった ◦ DesignDocとしてコンテキストを残せなかった ▪ 僕のみぞ知り、他のメンバーは知らなかった ▪ 聞いてくれればいいじゃん、と思っていた • あんなに前職でドキュメント書いていたのに… • 新規開発が優先で、負債を解消するための採⽤ができなかった • 当初の仕様から⼤きく変わった時にそのまま機能を利⽤してしまった • … 技術的負債が⽣まれた背景 34

フロントエンドとバックエンドとインフラを1⼈で構築して多くの⼈に提供したことがなかった ◦ DesignDocとしてコンテキストを残せなかった ▪ 僕のみぞ知り、他のメンバーは知らなかった ▪ 聞いてくれればいいじゃん、と思っていた • あんなに前職でドキュメント書いていたのに… • 新規開発が優先で、負債を解消するための採⽤ができなかった • 当初の仕様から⼤きく変わった時にそのまま機能を利⽤してしまった • … 技術的負債が⽣まれた背景 35 どうやって改善に向けて⾛ったのか？

© Findy Inc. • 取り組み①：テスト⽂化の確⽴ • 取り組み②：デプロイ⾃動化 • 取り組み③：モノリス解体 •
取り組み④：フロントエンド刷新 • 取り組み⑤：インフラ刷新 • 取り組み⑥：GraphQL化変⾰への取り組み6つ 37

© Findy Inc. • 直⾯した障壁 ◦ テスト作成経験者の不⾜ ◦ テストの価値への理解不⾜ ◦
「新規開発をたくさん作ってほしい」というニーズ変⾰への取り組み①：テスト⽂化の確⽴ 40

「新規開発をたくさん作ってほしい」というニーズ • 実施したアプローチ変⾰への取り組み①：テスト⽂化の確⽴ 41

「新規開発をたくさん作ってほしい」というニーズ • 実施したアプローチ ◦ Findy Team+プロジェクトでの実証実験 ◦ バックエンドテストでの⾼カバレッジ実現 ◦ 効果の可視化と全社的な理解促進変⾰への取り組み①：テスト⽂化の確⽴ 42

「新規開発をたくさん作ってほしい」というニーズ • 実施したアプローチ ◦ Findy Team+プロジェクトでの実証実験 ◦ バックエンドテストでの⾼カバレッジ実現 ◦ 効果の可視化と全社的な理解促進 • 得られた成果変⾰への取り組み①：テスト⽂化の確⽴ 43

「新規開発をたくさん作ってほしい」というニーズ • 実施したアプローチ ◦ Findy Team+プロジェクトでの実証実験 ◦ バックエンドテストでの⾼カバレッジ実現 ◦ 効果の可視化と全社的な理解促進 • 得られた成果 ◦ テストカバレッジ95%超を達成 ◦ リリース後の障害が激減 ◦ dependabotによる⾃動アップデートが可能に ◦ セキュリティホールの解消 ◦ 不具合発⽣時の迅速な対応が可能に変⾰への取り組み①：テスト⽂化の確⽴ 44

© Findy Inc. • 移⾏前の状況 ◦ CircleCIでのビルド ◦ AWS Codepipelineでのデプロイ
◦ EBの⼿動swap ◦ 複雑な⼿順と時間のかかるデプロイフロー変⾰への取り組み②：デプロイ⾃動化 47

◦ EBの⼿動swap ◦ 複雑な⼿順と時間のかかるデプロイフロー • 実現した改善変⾰への取り組み②：デプロイ⾃動化 48

◦ EBの⼿動swap ◦ 複雑な⼿順と時間のかかるデプロイフロー • 実現した改善 ◦ GitHub Actionsへの完全移⾏ ◦ デプロイプロセスの完全⾃動化 ◦ CIのキュー待ち解消 ◦ 年間30万円のコスト削減変⾰への取り組み②：デプロイ⾃動化 49

© Findy Inc. • 分割前の課題 ◦ Backend/Frontend密結合による⾮効率 ◦ ⽂字修正でも半⽇かかるリリース ◦
サーバー負荷による画⾯表⽰への影響 ◦ PRの⼤規模化とレビュー遅延 ◦ 頻発するコンフリクト変⾰への取り組み③：モノリス解体 52

サーバー負荷による画⾯表⽰への影響 ◦ PRの⼤規模化とレビュー遅延 ◦ 頻発するコンフリクト • 実施内容と決断変⾰への取り組み③：モノリス解体 53

サーバー負荷による画⾯表⽰への影響 ◦ PRの⼤規模化とレビュー遅延 ◦ 頻発するコンフリクト • 実施内容と決断 ◦ Backend/Frontendの完全分離 ◦ 開発プロセスの抜本的⾒直し ◦ 中途サービスの3ヶ⽉開発停⽌ ◦ unit testによる安全性担保変⾰への取り組み③：モノリス解体 54

サーバー負荷による画⾯表⽰への影響 ◦ PRの⼤規模化とレビュー遅延 ◦ 頻発するコンフリクト • 実施内容と決断 ◦ Backend/Frontendの完全分離 ◦ 開発プロセスの抜本的⾒直し ◦ 中途サービスの3ヶ⽉開発停⽌ ◦ unit testによる安全性担保 • 分割後の効果変⾰への取り組み③：モノリス解体 55

サーバー負荷による画⾯表⽰への影響 ◦ PRの⼤規模化とレビュー遅延 ◦ 頻発するコンフリクト • 実施内容と決断 ◦ Backend/Frontendの完全分離 ◦ 開発プロセスの抜本的⾒直し ◦ 中途サービスの3ヶ⽉開発停⽌ ◦ unit testによる安全性担保 • 分割後の効果 ◦ リリース頻度が週1から1⽇数回(フロント/バック) ◦ ⽂字修正が数分で本番反映可能に ◦ PR粒度の最適化 ◦ レビュー効率の⼤幅向上 ◦ コンフリクト発⽣の激減変⾰への取り組み③：モノリス解体 56

© Findy Inc. • 刷新前の技術的課題 ◦ Class Componentによる制約 ◦ Flow型システムの限界
◦ Redux依存による画⾯間の強結合 ◦ Componentの設計不備 ◦ テストの⽋如変⾰への取り組み④：フロントエンド刷新 59

◦ Redux依存による画⾯間の強結合 ◦ Componentの設計不備 ◦ テストの⽋如 • 実施した改善変⾰への取り組み④：フロントエンド刷新 60

◦ Redux依存による画⾯間の強結合 ◦ Componentの設計不備 ◦ テストの⽋如 • 実施した改善 ◦ Nxの導⼊ ◦ Function Componentへの完全移⾏ ◦ unit testの拡充 ◦ フォルダ構成の⾒直し ◦ Reduxへの過度な依存からの脱却 ◦ component設計の刷新変⾰への取り組み④：フロントエンド刷新 61

◦ Redux依存による画⾯間の強結合 ◦ Componentの設計不備 ◦ テストの⽋如 • 実施した改善 ◦ Nxの導⼊ ◦ Function Componentへの完全移⾏ ◦ unit testの拡充 ◦ フォルダ構成の⾒直し ◦ Reduxへの過度な依存からの脱却 ◦ component設計の刷新 • 得られた効果変⾰への取り組み④：フロントエンド刷新 62

◦ Redux依存による画⾯間の強結合 ◦ Componentの設計不備 ◦ テストの⽋如 • 実施した改善 ◦ Nxの導⼊ ◦ Function Componentへの完全移⾏ ◦ unit testの拡充 ◦ フォルダ構成の⾒直し ◦ Reduxへの過度な依存からの脱却 ◦ component設計の刷新 • 得られた効果 ◦ キャッシュによる迅速な切り戻し ◦ 画⾯間の影響度低減 ◦ 開発効率の向上 ◦ 保守性の改善変⾰への取り組み④：フロントエンド刷新 63

© Findy Inc. • EBからFargateへの移⾏ ◦ Elastic Beanstalkからの完全移⾏ ◦ GitHub
Actionsによる⾃動化実現 ◦ インフラ管理コストの⼤幅削減変⾰への取り組み⑤：インフラ刷新 66

Actionsによる⾃動化実現 ◦ インフラ管理コストの⼤幅削減 • 実現した改善変⾰への取り組み⑤：インフラ刷新 67

Actionsによる⾃動化実現 ◦ インフラ管理コストの⼤幅削減 • 実現した改善 ◦ リリース作業の完全⾃動化 ◦ 切り戻しの容易化 ◦ 運⽤負荷の激減 ◦ インフラ管理の効率化変⾰への取り組み⑤：インフラ刷新 68

© Findy Inc. • 段階的なアプローチ ◦ 内部向け管理画⾯での検証と実装 ◦ 企業向け画⾯からの段階的移⾏ ◦
問題のある画⾯の完全リプレイス変⾰への取り組み⑥：GraphQL化 71

問題のある画⾯の完全リプレイス • 現在変⾰への取り組み⑥：GraphQL化 72

問題のある画⾯の完全リプレイス • 現在 ◦ ほぼGraphQLが当たり前の状況にリプレイス完了 ◦ ⼀部RestAPIもある変⾰への取り組み⑥：GraphQL化 73

© Findy Inc. • 技術⾯での改善 ◦ テストカバレッジ95-99%を維持 ◦ terraformによる安定した再現性のあるインフラ環境 ◦
何かあってもすぐに5-10分以内に切り戻せる体制の確⽴ ◦ 疎結合アーキテクチャの実現 ▪ ⼀⽅でマイクロサービス化しすぎない現在の技術⾯と開発プロセス 81

何かあってもすぐに5-10分以内に切り戻せる体制の確⽴ ◦ 疎結合アーキテクチャの実現 ▪ ⼀⽅でマイクロサービス化しすぎない • 開発プロセスの進化現在の技術⾯と開発プロセス 82

何かあってもすぐに5-10分以内に切り戻せる体制の確⽴ ◦ 疎結合アーキテクチャの実現 ▪ ⼀⽅でマイクロサービス化しすぎない • 開発プロセスの進化 ◦ 活発なレビュー環境 ▪ 今年の1⽉からの227営業⽇で1⼈平均1500件、平均6.6/day、最多4600件） ▪ レビューまでの時間も平均1.4時間 ◦ 効率的なデプロイフロー ▪ 227営業⽇で6800件超えのデプロイ、平均30.2デプロイ/day ◦ 継続的な改善サイクルと振り返り⽂化現在の技術⾯と開発プロセス 83

何かあってもすぐに5-10分以内に切り戻せる体制の確⽴ ◦ 疎結合アーキテクチャの実現 ▪ ⼀⽅でマイクロサービス化しすぎない • 開発プロセスの進化 ◦ 活発なレビュー環境 ▪ 今年の1⽉からの227営業⽇で1⼈平均1500件、平均6.6/day、最多4600件） ▪ レビューまでの時間も平均1.4時間 ◦ 効率的なデプロイフロー ▪ 227営業⽇で6800件超えのデプロイ、平均30.2デプロイ/day ◦ 継続的な改善サイクルと振り返り⽂化現在の技術⾯と開発プロセス 84 チラッ＞

継続的な改善の⽂化づくり ◦ 予防的なメンテナンス • 具体的な取り組み現在の状況 89

継続的な改善の⽂化づくり ◦ 予防的なメンテナンス • 具体的な取り組み ◦ CTO室による技術推進 ◦ 定期的なリファクタリング ◦ ライブラリの継続的な⾒直し ◦ テックリードによる改善活動現在の状況 90

継続的な改善の⽂化づくり ◦ 予防的なメンテナンス • 具体的な取り組み ◦ CTO室による技術推進 ◦ 定期的なリファクタリング ◦ ライブラリの継続的な⾒直し ◦ テックリードによる改善活動現在の状況 91 テックリードが横断で技術的負債が強いチームに数ヶ⽉⼊って設計をアップデートすることで

継続的な改善の⽂化づくり ◦ 予防的なメンテナンス • 具体的な取り組み ◦ CTO室による技術推進 ◦ 定期的なリファクタリング ◦ ライブラリの継続的な⾒直し ◦ テックリードによる改善活動現在の状況 92 テックリードが横断で技術的負債が強いチームに数ヶ⽉⼊って設計をアップデートすることで

継続的な改善の⽂化づくり ◦ 予防的なメンテナンス • 具体的な取り組み ◦ CTO室による技術推進 ◦ 定期的なリファクタリング ◦ ライブラリの継続的な⾒直し ◦ テックリードによる改善活動現在の状況 93 テックリードが横断で技術的負債が強いチームに数ヶ⽉⼊って設計をアップデートすることで負債が⽣まれにくい状況になった

© Findy Inc. • 学んだこと ◦ 負債かもと思ったらすぐに課題に挙げる ◦ 負債を解消するためのアクションを組織的に⼊れ続ける ◦
早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出して⾒極め続けようまとめ：掃除は⽇々やり続けようね！ 98

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出して⾒極め続けよう ◦ ⽇進⽉歩、⼀⽇で潰せる技術的負債は少し ▪ コツコツと返済し続けることが⼀番よいまとめ：掃除は⽇々やり続けようね！ 99

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出して⾒極め続けよう ◦ ⽇進⽉歩、⼀⽇で潰せる技術的負債は少し ▪ コツコツと返済し続けることが⼀番よい ◦ 初期の負債の返済は数年はかかる ▪ ⼼してかかるしかない…！ ▪ まずは産まないことが⼤事…！！まとめ：掃除は⽇々やり続けようね！ 100

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出して⾒極め続けよう ◦ ⽇進⽉歩、⼀⽇で潰せる技術的負債は少し ▪ コツコツと返済し続けることが⼀番よい ◦ 初期の負債の返済は数年はかかる ▪ ⼼してかかるしかない…！ ▪ まずは産まないことが⼤事…！！ ◦ とはいえリスペクトも忘れずに！まとめ：掃除は⽇々やり続けようね！ 101

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出し続けようまとめ：掃除は⽇々やり続けようね！ 102 掃除好きの⼈に⾔われました

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出し続けようまとめ：掃除は⽇々やり続けようね！ 103 「師⾛に⼤掃除するのではなく、

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出し続けようまとめ：掃除は⽇々やり続けようね！ 104 「師⾛に⼤掃除するのではなく、⽇頃から掃除していれば

早めの決断、早めの投資 ▪ とはいえこの判断が難しい。損益分岐点を出し続けようまとめ：掃除は⽇々やり続けようね！ 105 「師⾛に⼤掃除するのではなく、⽇頃から掃除していれば⼤掃除なんていらないんですよ」

ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Tec...

ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Technical Debt at Findy

More Decks by Masataka Sato

Other Decks in Technology

Featured

Transcript