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

by Recruit

Slide 1

Slide 1 text

『ホットペッパービューティー』におけるリアーキテクチャの歩み RECRUIT TECH CONFERENCE 2025 「技術的負債」の返済プロセス中里　直人株式会社リクルートプロダクトディベロップメント室部長

Slide 2

Slide 2 text

中里直人休日は3人の子どもと一緒にSwitchで遊んでます経歴 / Career 2017年にリクルートに入社。 Androidアプリエンジニアとしてキャリアをスタートし、『ホットペッパービューティー』アプリのフルリプレイスプロジェクトに参画。その後チームリーダーやTechLeadを担当しアプリ向けAPI のリプレイスやWebシステムのリアーキテクチャを推進。 2021年からマネジャー、2024年から部長を担当し、『ホットペッパービューティー』の価値を最大化するための開発組織・文化・システムの構築に奮闘中。趣味 / Hobbies プロダクトディベロップメント室販促領域エンジニアリング2ユニットビューティー領域エンジニアリング部

Slide 3

Slide 3 text

Agenda 1. 『ホットペッパービューティー』について 2. これまでの取り組み 3. Webサイトのリアーキテクチャ 4. 今後の展望

Slide 4

Slide 4 text

『ホットペッパービューティー』について

Slide 5

Slide 5 text

『ホットペッパービューティー』について ● 国内最大級のヘアサロン・リラク＆ビューティーサロン検索・予約サイト ● 2007年4月にWebサービスを開始し現在は年間1.9億回予約されるサービスに成長 ※2025年1月時点 https://beauty.hotpepper.jp/doc/guide/saishindata.html

Slide 6

Slide 6 text

『ホットペッパービューティー』を支えるシステム ● 10年ほど経った頃には急速なプロダクト成長の裏でシステムがレガシーで複雑な状態になりつつあった ○ さらなる成長に向けてやりたいことがたくさんあるが莫大な工数がかかる状況 ○ システム規模の大きさや仕様とアーキテクチャの複雑さから学習コストが高く優秀なエンジニアが活躍するまで時間がかかる状況 ● 初期は業務委託中心の体制だったが2012年頃よりエンジニア採用を開始し内製化を推進 ○ 機能開発だけでなく技術的改善にも投資

Slide 7

Slide 7 text

『ホットペッパービューティー』を支えるシステム ● 本日はこれまでの技術的改善について軽く紹介し、直近進めているリアーキテクチャについて工夫したポイントを共有します

Slide 8

Slide 8 text

これまでの取り組み

Slide 9

Slide 9 text

2016年ごろ

Slide 10

Slide 10 text

2016年〜2018年

Slide 11

Slide 11 text

モバイルアプリのリプレイス ● 2010年に提供開始したiOS/Androidアプリ ● アプリからの予約が増え改善が急がれる中で技術的負債が溜まり開発スピードが遅かった ● 2016年からシステムリプレイスの検討を開始し 2018年にリプレイスが完了 ● 人材要件や開発プロセスも見直すことで、企画組織・開発組織が一体となって高速なプロダクト開発に向き合う状態を作ることができた

Slide 12

Slide 12 text

2016年〜2018年

Slide 13

Slide 13 text

2018年〜2021年

Slide 14

Slide 14 text

APIのリプレイス ● モバイルアプリの開発スピードが向上しAPIの開発スピードがボトルネックになっていた ● 2018年からAPIのリプレイスの検討を開始し2021年に全てのAPIをリプレイス完了 ○ モノリシックなアプリケーションをBFFとBackendに分割 ○ BFFにはサーバーサイドKotlinを採用 https://speakerdeck.com/recruitengineers/jjug2019spring

Slide 15

Slide 15 text

2018年〜2021年

Slide 16

Slide 16 text

2022年〜

Slide 17

Slide 17 text

Webサイトのリアーキテクチャ

Slide 18

Slide 18 text

Webサイトのリアーキテクチャ ● Webサイトの開発工数が相対的に大きくなってきた ○ 社内独自フレームワーク ○ Java 8で書かれたコード ● Webサイトとモバイルアプリでほぼ同じ機能を提供 ○ 同じ目的でも別々のシステムをそれぞれ開発する必要がある ○ 意図せず細部の仕様が異なり要件検討や問い合わせ対応にも時間がかかる ● 2022年からWebサイトのリアーキテクチャを検討開始

Slide 19

Slide 19 text

Java8 社内独自FW Java17 Spring Boot

Slide 20

Slide 20 text

リアーキテクチャを進めるうえで工夫した5つのポイント ● フェーズ分割とスコープ策定 ● 移行対象クラスの調査 ● AppとWebの仕様統一 ● 変更内容の取り込み ● 現新比較ツール

Slide 21

Slide 21 text

フェーズ分割とスコープ策定 ● 大規模システムであるため全体のリアーキテクチャには大きな工数がかかるが、リアーキテクチャの実現可能性やリアーキテクチャの効果も確証が持てていない ○ 技術的改善の目的は長期的なプロダクト価値の最大化である

Slide 22

Slide 22 text

フェーズ分割とスコープ策定 ● 大規模システムであるため全体のリアーキテクチャには大きな工数がかかるが、リアーキテクチャの実現可能性やリアーキテクチャの効果も確証が持てていない ○ 技術的改善の目的は長期的なプロダクト価値の最大化である ● リアーキテクチャをフェーズ分割し、改修頻度が高くリアーキテクチャの価値が大きいと思われる画面から実装 ○ 想定外の事態や状況の変化によりプロジェクトを中断したとしても、完了した画面についてはリアーキテクチャの効果が享受できる状態を作ることで、プロダクト価値の毀損リスクを低減した状態でプロジェクトを始めることができた

Slide 23

Slide 23 text

移行対象クラスの調査 ● 大規模なシステムであるため、移行対象画面の動作に必要なクラスの洗い出しが大変 ○ 特にJSPから呼び出されるJavaクラスが追いづらい

Slide 24

Slide 24 text

移行対象クラスの調査 ● 大規模なシステムであるため、移行対象画面の動作に必要なクラスの洗い出しが大変 ○ 特にJSPから呼び出されるJavaクラスが追いづらい ● BTraceを利用し画面表示時に呼び出されるクラスを一覧化 ○ 移行対象クラスを一覧化できた https://github.com/btraceio/btrace

Slide 25

Slide 25 text

AppとWebの仕様統一 ● AppとWebで細かい仕様に差異があり、API統一するうえでどちらかに寄せる必要がある ○ SEO要件による差異や画面サイズによる差異の場合は統一しない判断もあり得る

Slide 26

Slide 26 text

AppとWebの仕様統一 ● AppとWebで細かい仕様に差異があり、API統一するうえでどちらかに寄せる必要がある ○ SEO要件による差異や画面サイズによる差異の場合は統一しない判断もあり得る ● 仕様策定プロセス・フォーマットを作成 ○ 仕様策定を分担し短期間で実施することができた ○ ドキュメント化することで新規参画者も経緯が分かるように

Slide 27

Slide 27 text

変更内容の取り込み ● リアーキテクチャと並行して通常の機能開発も進行している ○ プロジェクトの途中で機能変更を随時取り込む必要がある ○ リリース後もセッションなどの新旧共通で利用するものは変更を取り込む必要がある

Slide 28

Slide 28 text

変更内容の取り込み ● リアーキテクチャと並行して通常の機能開発も進行している ○ プロジェクトの途中で機能変更を随時取り込む必要がある ○ リリース後もセッションなどの新旧共通で利用するものは変更を取り込む必要がある ● リアーキテクチャしたクラスに移行元のファイル名とリビジョンをコメントで記載 ○ 移行元に変更があった場合は自動で検知し取り込み漏れを防ぐことができた ○ コメント自体の記載忘れもCIで検知することで対応漏れを防ぐことができた

Slide 29

Slide 29 text

現新比較ツール ● 仕様を統一した箇所以外は基本的に既存の仕様を踏襲 ● リアーキ前後で意図しない仕様変更がないかテストしたいが画面数やパターン数が多い

Slide 30

Slide 30 text

現新比較ツール ● 仕様を統一した箇所以外は基本的に既存の仕様を踏襲 ● リアーキ前後で意図しない仕様変更がないかテストしたいが画面数やパターン数が多い ● 現新比較ツールを作成

Slide 31

Slide 31 text

現新比較ツール ● Karateやreg-cliを用いてリアーキ前とリアーキ後のシステムを比較できるツールを開発 ○ 仕様変更も含んでいるので必ずしも同一になるわけではない ○ 差分を可視化することで意図しない差分を検出しやすくする ● 可視化する差分の例 ○ ページのスクリーンショットの差分 ○ ページ内のリンクやmetaタグの差分 ○ ページ読み込み後の通信内容の差分 ● 大量のURLやデータパターンに対する確認負荷を大きく軽減することができた ○ リアーキ後の機能改修でも活用 https://karatelabs.github.io/karate/ https://github.com/reg-viz/reg-cli スクリーンショットの差分

Slide 32

Slide 32 text

成果 ● 2024年8月にクーポン画面のみリリース ○ クーポン絞り込み機能の改修において3割程度の工数削減が確認できた ○ 社内独自FWからの脱却と開発環境の整備によりいままで3日もかかっていた開発環境構築も1時間程度で実現できるようになった ○ 内製開発体制を強化し企画組織と一体となってプロダクト開発する体制を構築できた ○ DBパフォーマンスのモニタリングや改善を API開発チームに一任することで専門性強化と保守工数削減を実現できた ● クーポン画面以外のリアーキテクチャも着々と進行中……！

Slide 33

Slide 33 text

今後の展望

Slide 34

Slide 34 text

今後の展望 ● Webサイトのリアーキテクチャは規模を拡大して引き続き推進 ● 『ホットペッパービューティー』だけでなく『サロンボード』やDBの改善も進行中 ○ 『サロンボード』の改善はDay1で発表していたのでアーカイブをご覧ください ● 技術的改善への投資と開発体制の強化のサイクルを回す ○ 将来の様々なビジネスチャンスに対応できる状態を構築する ● キレイになったシステムでどんどんプロダクト開発していきたいエンジニアも、大規模システムを大胆にリアーキテクチャしていきたいエンジニアも募集中です！