Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
『ホットペッパービューティー』における リアーキテクチャの歩み
Search
Recruit
PRO
March 03, 2025
Technology
1
7
『ホットペッパービューティー』における リアーキテクチャの歩み
2025/2/20に開催したRecruit Tech Conference 2025の中里の資料です
Recruit
PRO
March 03, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
4
18
技術的ミスと深堀り
recruitengineers
PRO
3
19
『ホットペッパーグルメ』における マルチプラットフォーム化の歩み
recruitengineers
PRO
2
10
『じゃらんnet』アプリ 改善活動の軌跡
recruitengineers
PRO
2
7
『スタディサプリ for SCHOOL』における Flutter導入とその成果
recruitengineers
PRO
2
9
よりよいビジネスの「実現」のために エンジニアリングを発揮する
recruitengineers
PRO
3
20
イテレーティブな開発で 不確実性を乗り越える
recruitengineers
PRO
3
8
株式会社リクルート 社内ISUCONの裏側
recruitengineers
PRO
1
13
エンジニア主導の企画立案を可能にする組織とは?
recruitengineers
PRO
1
22
Other Decks in Technology
See All in Technology
NFV基盤のOpenStack更新 ~9世代バージョンアップへの挑戦~
vtj
0
350
Windows の新しい管理者保護モード
murachiakira
0
200
MIMEと文字コードの闇
hirachan
2
1.4k
サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
ymotongpoo
7
1.5k
スキルだけでは満たせない、 “組織全体に”なじむオンボーディング/Onboarding that fits “throughout the organization” and cannot be satisfied by skills alone
bitkey
0
170
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.6k
役員・マネージャー・著者・エンジニアそれぞれの立場から見たAWS認定資格
nrinetcom
PRO
3
5.9k
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
10
3.7k
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
OPENLOGI Company Profile
hr01
0
60k
技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話
niftycorp
PRO
0
100
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
150
Featured
See All Featured
The Invisible Side of Design
smashingmag
299
50k
Writing Fast Ruby
sferik
628
61k
The Cult of Friendly URLs
andyhume
78
6.2k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
A better future with KSS
kneath
238
17k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
570
How STYLIGHT went responsive
nonsquared
98
5.4k
Transcript
『ホットペッパービューティー』における リアーキテクチャの歩み RECRUIT TECH CONFERENCE 2025 「技術的負債」の返済プロセス 中里 直人 株式会社リクルート プロダクトディベロップメント室
部長
中里 直人 休日は3人の子どもと一緒にSwitchで遊んでます 経歴 / Career 2017年にリクルートに入社。 Androidアプリエンジニアとしてキャリアをスタートし、 『ホットペッパービューティー』アプリのフルリプレイス プロジェクトに参画。
その後チームリーダーやTechLeadを担当しアプリ向けAPI のリプレイスやWebシステムのリアーキテクチャを推進。 2021年からマネジャー、2024年から部長を担当し、 『ホットペッパービューティー』の価値を最大化するため の開発組織・文化・システムの構築に奮闘中。 趣味 / Hobbies プロダクトディベロップメント室 販促領域エンジニアリング2ユニット ビューティー領域エンジニアリング部
Agenda 1. 『ホットペッパービューティー』について 2. これまでの取り組み 3. Webサイトのリアーキテクチャ 4. 今後の展望
『ホットペッパービューティー』について
『ホットペッパービューティー』について • 国内最大級のヘアサロン ・リラク&ビューティーサロン検索・予約サイト • 2007年4月にWebサービスを開始し現在は年間1.9億回予約されるサービスに成長 ※2025年1月時点 https://beauty.hotpepper.jp/doc/guide/saishindata.html
『ホットペッパービューティー』を支えるシステム • 10年ほど経った頃には急速なプロダクト成長の裏で システムがレガシーで複雑な状態になりつつあった ◦ さらなる成長に向けてやりたいことがたくさんあるが莫大な工数がかかる状況 ◦ システム規模の大きさや仕様とアーキテクチャの複雑さから 学習コストが高く優秀なエンジニアが活躍するまで時間がかかる状況 •
初期は業務委託中心の体制だったが2012年頃よりエンジニア採用を開始し内製化を推進 ◦ 機能開発だけでなく技術的改善にも投資
『ホットペッパービューティー』を支えるシステム • 本日はこれまでの技術的改善について軽く紹介し、 直近進めているリアーキテクチャについて工夫したポイントを共有します
これまでの取り組み
2016年ごろ
2016年〜2018年
モバイルアプリのリプレイス • 2010年に提供開始したiOS/Androidアプリ • アプリからの予約が増え改善が急がれる中で 技術的負債が溜まり開発スピードが遅かった • 2016年からシステムリプレイスの検討を開始し 2018年にリプレイスが完了 •
人材要件や開発プロセスも見直すことで、 企画組織・開発組織が一体となって 高速なプロダクト開発に向き合う状態を作ることができた
2016年〜2018年
2018年〜2021年
APIのリプレイス • モバイルアプリの開発スピードが向上しAPIの開発スピードがボトルネックになっていた • 2018年からAPIのリプレイスの検討を開始し2021年に全てのAPIをリプレイス完了 ◦ モノリシックなアプリケーションをBFFとBackendに分割 ◦ BFFにはサーバーサイドKotlinを採用 https://speakerdeck.com/recruitengineers/jjug2019spring
2018年〜2021年
2022年〜
Webサイトのリアーキテクチャ
Webサイトのリアーキテクチャ • Webサイトの開発工数が相対的に大きくなってきた ◦ 社内独自フレームワーク ◦ Java 8で書かれたコード • Webサイトとモバイルアプリでほぼ同じ機能を提供
◦ 同じ目的でも別々のシステムをそれぞれ開発する必要がある ◦ 意図せず細部の仕様が異なり要件検討や問い合わせ対応にも時間がかかる • 2022年からWebサイトのリアーキテクチャを検討開始
Java8 社内独自FW Java17 Spring Boot
リアーキテクチャを進めるうえで工夫した5つのポイント • フェーズ分割とスコープ策定 • 移行対象クラスの調査 • AppとWebの仕様統一 • 変更内容の取り込み •
現新比較ツール
フェーズ分割とスコープ策定 • 大規模システムであるため全体のリアーキテクチャには大きな工数がかかるが、 リアーキテクチャの実現可能性やリアーキテクチャの効果も確証が持てていない ◦ 技術的改善の目的は長期的なプロダクト価値の最大化である
フェーズ分割とスコープ策定 • 大規模システムであるため全体のリアーキテクチャには大きな工数がかかるが、 リアーキテクチャの実現可能性やリアーキテクチャの効果も確証が持てていない ◦ 技術的改善の目的は長期的なプロダクト価値の最大化である • リアーキテクチャをフェーズ分割し、 改修頻度が高くリアーキテクチャの価値が大きいと思われる画面から実装 ◦
想定外の事態や状況の変化によりプロジェクトを中断したとしても、 完了した画面についてはリアーキテクチャの効果が享受できる状態を作ることで、 プロダクト価値の毀損リスクを低減した状態でプロジェクトを始めることができた
移行対象クラスの調査 • 大規模なシステムであるため、移行対象画面の動作に必要なクラスの洗い出しが大変 ◦ 特にJSPから呼び出されるJavaクラスが追いづらい
移行対象クラスの調査 • 大規模なシステムであるため、移行対象画面の動作に必要なクラスの洗い出しが大変 ◦ 特にJSPから呼び出されるJavaクラスが追いづらい • BTraceを利用し画面表示時に呼び出されるクラスを一覧化 ◦ 移行対象クラスを一覧化できた https://github.com/btraceio/btrace
AppとWebの仕様統一 • AppとWebで細かい仕様に差異があり、API統一するうえでどちらかに寄せる必要がある ◦ SEO要件による差異や画面サイズによる差異の場合は統一しない判断もあり得る
AppとWebの仕様統一 • AppとWebで細かい仕様に差異があり、API統一するうえでどちらかに寄せる必要がある ◦ SEO要件による差異や画面サイズによる差異の場合は統一しない判断もあり得る • 仕様策定プロセス・フォーマットを作成 ◦ 仕様策定を分担し短期間で実施することができた ◦
ドキュメント化することで新規参画者も経緯が分かるように
変更内容の取り込み • リアーキテクチャと並行して通常の機能開発も進行している ◦ プロジェクトの途中で機能変更を随時取り込む必要がある ◦ リリース後もセッションなどの新旧共通で利用するものは変更を取り込む必要がある
変更内容の取り込み • リアーキテクチャと並行して通常の機能開発も進行している ◦ プロジェクトの途中で機能変更を随時取り込む必要がある ◦ リリース後もセッションなどの新旧共通で利用するものは変更を取り込む必要がある • リアーキテクチャしたクラスに移行元のファイル名とリビジョンをコメントで記載 ◦
移行元に変更があった場合は自動で検知し取り込み漏れを防ぐことができた ◦ コメント自体の記載忘れもCIで検知することで対応漏れを防ぐことができた
現新比較ツール • 仕様を統一した箇所以外は基本的に既存の仕様を踏襲 • リアーキ前後で意図しない仕様変更がないかテストしたいが画面数やパターン数が多い
現新比較ツール • 仕様を統一した箇所以外は基本的に既存の仕様を踏襲 • リアーキ前後で意図しない仕様変更がないかテストしたいが画面数やパターン数が多い • 現新比較ツールを作成
現新比較ツール • Karateやreg-cliを用いてリアーキ前とリアーキ後のシステムを比較できるツールを開発 ◦ 仕様変更も含んでいるので必ずしも同一になるわけではない ◦ 差分を可視化することで意図しない差分を検出しやすくする • 可視化する差分の例 ◦
ページのスクリーンショットの差分 ◦ ページ内のリンクやmetaタグの差分 ◦ ページ読み込み後の通信内容の差分 • 大量のURLやデータパターンに対する 確認負荷を大きく軽減することができた ◦ リアーキ後の機能改修でも活用 https://karatelabs.github.io/karate/ https://github.com/reg-viz/reg-cli スクリーンショットの差分
成果 • 2024年8月にクーポン画面のみリリース ◦ クーポン絞り込み機能の改修において3割程度の工数削減が確認できた ◦ 社内独自FWからの脱却と開発環境の整備により いままで3日もかかっていた開発環境構築も1時間程度で実現できるようになった ◦ 内製開発体制を強化し企画組織と一体となってプロダクト開発する体制を構築できた
◦ DBパフォーマンスのモニタリングや改善を API開発チームに一任することで専門性強化と保守工数削減を実現できた • クーポン画面以外のリアーキテクチャも着々と進行中……!
今後の展望
今後の展望 • Webサイトのリアーキテクチャは規模を拡大して引き続き推進 • 『ホットペッパービューティー』だけでなく『サロンボード』やDBの改善も進行中 ◦ 『サロンボード』の改善はDay1で発表していたのでアーカイブをご覧ください • 技術的改善への投資と開発体制の強化のサイクルを回す ◦
将来の様々なビジネスチャンスに対応できる状態を構築する • キレイになったシステムでどんどんプロダクト開発していきたいエンジニアも、 大規模システムを大胆にリアーキテクチャしていきたいエンジニアも募集中です!