『ホットペッパービューティー』における リアーキテクチャの歩み

2025/2/20に開催したRecruit Tech Conference 2025の中里の資料です

Transcript

1. 『ホットペッパービューティー』における リアーキテクチャの歩み RECRUIT TECH CONFERENCE 2025 「技術的負債」の返済プロセス 中里　直人 株式会社リクルート プロダクトディベロップメント室 部長
2. 中里 直人 休日は3人の子どもと一緒にSwitchで遊んでます 経歴 / Career 2017年にリクルートに入社。 Androidアプリエンジニアとしてキャリアをスタートし、 『ホットペッパービューティー』アプリのフルリプレイス プロジェクトに参画。 その後チームリーダーやTechLeadを担当しアプリ向けAPI のリプレイスやWebシステムのリアーキテクチャを推進。 2021年からマネジャー、2024年から部長を担当し、 『ホットペッパービューティー』の価値を最大化するため の開発組織・文化・システムの構築に奮闘中。 趣味 / Hobbies プロダクトディベロップメント室 販促領域エンジニアリング2ユニット ビューティー領域エンジニアリング部
3. Agenda 1. 『ホットペッパービューティー』について 2. これまでの取り組み 3. Webサイトのリアーキテクチャ 4. 今後の展望
4. 『ホットペッパービューティー』について
5. 『ホットペッパービューティー』について • 国内最大級のヘアサロン ・リラク＆ビューティーサロン検索・予約サイト • 2007年4月にWebサービスを開始し現在は年間1.9億回予約されるサービスに成長 ※2025年1月時点 https://beauty.hotpepper.jp/doc/guide/saishindata.html
6. 『ホットペッパービューティー』を支えるシステム • 10年ほど経った頃には急速なプロダクト成長の裏で システムがレガシーで複雑な状態になりつつあった ◦ さらなる成長に向けてやりたいことがたくさんあるが莫大な工数がかかる状況 ◦ システム規模の大きさや仕様とアーキテクチャの複雑さから 学習コストが高く優秀なエンジニアが活躍するまで時間がかかる状況 • 初期は業務委託中心の体制だったが2012年頃よりエンジニア採用を開始し内製化を推進 ◦ 機能開発だけでなく技術的改善にも投資
7. 『ホットペッパービューティー』を支えるシステム • 本日はこれまでの技術的改善について軽く紹介し、 直近進めているリアーキテクチャについて工夫したポイントを共有します
8. これまでの取り組み
9. 2016年ごろ
10. 2016年〜2018年
11. モバイルアプリのリプレイス • 2010年に提供開始したiOS/Androidアプリ • アプリからの予約が増え改善が急がれる中で 技術的負債が溜まり開発スピードが遅かった • 2016年からシステムリプレイスの検討を開始し 2018年にリプレイスが完了 • 人材要件や開発プロセスも見直すことで、 企画組織・開発組織が一体となって 高速なプロダクト開発に向き合う状態を作ることができた
12. 2016年〜2018年
13. 2018年〜2021年
14. APIのリプレイス • モバイルアプリの開発スピードが向上しAPIの開発スピードがボトルネックになっていた • 2018年からAPIのリプレイスの検討を開始し2021年に全てのAPIをリプレイス完了 ◦ モノリシックなアプリケーションをBFFとBackendに分割 ◦ BFFにはサーバーサイドKotlinを採用 https://speakerdeck.com/recruitengineers/jjug2019spring
15. 2018年〜2021年
16. 2022年〜
17. Webサイトのリアーキテクチャ
18. Webサイトのリアーキテクチャ • Webサイトの開発工数が相対的に大きくなってきた ◦ 社内独自フレームワーク ◦ Java 8で書かれたコード • Webサイトとモバイルアプリでほぼ同じ機能を提供 ◦ 同じ目的でも別々のシステムをそれぞれ開発する必要がある ◦ 意図せず細部の仕様が異なり要件検討や問い合わせ対応にも時間がかかる • 2022年からWebサイトのリアーキテクチャを検討開始
19. Java8 社内独自FW Java17 Spring Boot
20. リアーキテクチャを進めるうえで工夫した5つのポイント • フェーズ分割とスコープ策定 • 移行対象クラスの調査 • AppとWebの仕様統一 • 変更内容の取り込み • 現新比較ツール
21. フェーズ分割とスコープ策定 • 大規模システムであるため全体のリアーキテクチャには大きな工数がかかるが、 リアーキテクチャの実現可能性やリアーキテクチャの効果も確証が持てていない ◦ 技術的改善の目的は長期的なプロダクト価値の最大化である
22. フェーズ分割とスコープ策定 • 大規模システムであるため全体のリアーキテクチャには大きな工数がかかるが、 リアーキテクチャの実現可能性やリアーキテクチャの効果も確証が持てていない ◦ 技術的改善の目的は長期的なプロダクト価値の最大化である • リアーキテクチャをフェーズ分割し、 改修頻度が高くリアーキテクチャの価値が大きいと思われる画面から実装 ◦ 想定外の事態や状況の変化によりプロジェクトを中断したとしても、 完了した画面についてはリアーキテクチャの効果が享受できる状態を作ることで、 プロダクト価値の毀損リスクを低減した状態でプロジェクトを始めることができた
23. 移行対象クラスの調査 • 大規模なシステムであるため、移行対象画面の動作に必要なクラスの洗い出しが大変 ◦ 特にJSPから呼び出されるJavaクラスが追いづらい
24. 移行対象クラスの調査 • 大規模なシステムであるため、移行対象画面の動作に必要なクラスの洗い出しが大変 ◦ 特にJSPから呼び出されるJavaクラスが追いづらい • BTraceを利用し画面表示時に呼び出されるクラスを一覧化 ◦ 移行対象クラスを一覧化できた https://github.com/btraceio/btrace
25. AppとWebの仕様統一 • AppとWebで細かい仕様に差異があり、API統一するうえでどちらかに寄せる必要がある ◦ SEO要件による差異や画面サイズによる差異の場合は統一しない判断もあり得る
26. AppとWebの仕様統一 • AppとWebで細かい仕様に差異があり、API統一するうえでどちらかに寄せる必要がある ◦ SEO要件による差異や画面サイズによる差異の場合は統一しない判断もあり得る • 仕様策定プロセス・フォーマットを作成 ◦ 仕様策定を分担し短期間で実施することができた ◦ ドキュメント化することで新規参画者も経緯が分かるように
27. 変更内容の取り込み • リアーキテクチャと並行して通常の機能開発も進行している ◦ プロジェクトの途中で機能変更を随時取り込む必要がある ◦ リリース後もセッションなどの新旧共通で利用するものは変更を取り込む必要がある
28. 変更内容の取り込み • リアーキテクチャと並行して通常の機能開発も進行している ◦ プロジェクトの途中で機能変更を随時取り込む必要がある ◦ リリース後もセッションなどの新旧共通で利用するものは変更を取り込む必要がある • リアーキテクチャしたクラスに移行元のファイル名とリビジョンをコメントで記載 ◦ 移行元に変更があった場合は自動で検知し取り込み漏れを防ぐことができた ◦ コメント自体の記載忘れもCIで検知することで対応漏れを防ぐことができた
29. 現新比較ツール • 仕様を統一した箇所以外は基本的に既存の仕様を踏襲 • リアーキ前後で意図しない仕様変更がないかテストしたいが画面数やパターン数が多い
30. 現新比較ツール • 仕様を統一した箇所以外は基本的に既存の仕様を踏襲 • リアーキ前後で意図しない仕様変更がないかテストしたいが画面数やパターン数が多い • 現新比較ツールを作成
31. 現新比較ツール • Karateやreg-cliを用いてリアーキ前とリアーキ後のシステムを比較できるツールを開発 ◦ 仕様変更も含んでいるので必ずしも同一になるわけではない ◦ 差分を可視化することで意図しない差分を検出しやすくする • 可視化する差分の例 ◦ ページのスクリーンショットの差分 ◦ ページ内のリンクやmetaタグの差分 ◦ ページ読み込み後の通信内容の差分 • 大量のURLやデータパターンに対する 確認負荷を大きく軽減することができた ◦ リアーキ後の機能改修でも活用 https://karatelabs.github.io/karate/ https://github.com/reg-viz/reg-cli スクリーンショットの差分
32. 成果 • 2024年8月にクーポン画面のみリリース ◦ クーポン絞り込み機能の改修において3割程度の工数削減が確認できた ◦ 社内独自FWからの脱却と開発環境の整備により いままで3日もかかっていた開発環境構築も1時間程度で実現できるようになった ◦ 内製開発体制を強化し企画組織と一体となってプロダクト開発する体制を構築できた ◦ DBパフォーマンスのモニタリングや改善を API開発チームに一任することで専門性強化と保守工数削減を実現できた • クーポン画面以外のリアーキテクチャも着々と進行中……！
33. 今後の展望
34. 今後の展望 • Webサイトのリアーキテクチャは規模を拡大して引き続き推進 • 『ホットペッパービューティー』だけでなく『サロンボード』やDBの改善も進行中 ◦ 『サロンボード』の改善はDay1で発表していたのでアーカイブをご覧ください • 技術的改善への投資と開発体制の強化のサイクルを回す ◦ 将来の様々なビジネスチャンスに対応できる状態を構築する • キレイになったシステムでどんどんプロダクト開発していきたいエンジニアも、 大規模システムを大胆にリアーキテクチャしていきたいエンジニアも募集中です！