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
February 16, 2025
Technology
3
100
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
2025/02/13に、Developers Summit(デブサミ)で発表した、浅井の資料です。
Recruit
PRO
February 16, 2025
Tweet
Share
More Decks by Recruit
See All by Recruit
RECRUIT TECH CONFERENCE 2025 プレイベント【関田】
recruitengineers
PRO
0
21
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
85
RECRUIT TECH CONFERENCE 2025 プレイベント【岡本】
recruitengineers
PRO
2
28
RECRUIT TECH CONFERENCE 2025 プレイベント【恒川】
recruitengineers
PRO
0
23
20250130_『SUUMO』の裏側!第2弾 ~機械学習エンジニアリング編
recruitengineers
PRO
1
950
Asset Centric な データ変換パイプラインの攻略法
recruitengineers
PRO
1
140
Kotlin Multiplatformのポテンシャル
recruitengineers
PRO
2
210
デザイン初め新年会2025_川端_PdM Days2025
recruitengineers
PRO
1
69
Azure Functions HTTPトリガーにおけるタイムアウトでハマったこと
recruitengineers
PRO
2
390
Other Decks in Technology
See All in Technology
技術的負債解消の取り組みと専門チームのお話 #技術的負債_Findy
bengo4com
1
1.2k
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
320
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
240
AndroidXR 開発ツールごとの できることできないこと
donabe3
0
110
バックエンドエンジニアのためのフロントエンド入門 #devsumiC
panda_program
16
6.5k
サーバーレスアーキテクチャと生成AIの融合 / Serverless Meets Generative AI
_kensh
12
3k
PL900試験から学ぶ Power Platform 基礎知識講座
kumikeyy
0
110
Data-centric AI入門第6章:Data-centric AIの実践例
x_ttyszk
1
370
まだ間に合う! エンジニアのための生成AIアプリ開発入門 on AWS
minorun365
PRO
4
580
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
0
160
Classmethod AI Talks(CATs) #15 司会進行スライド(2025.02.06) / classmethod-ai-talks-aka-cats_moderator-slides_vol15_2025-02-06
shinyaa31
0
170
Building Products in the LLM Era
ymatsuwitter
10
4.4k
Featured
See All Featured
Six Lessons from altMBA
skipperchong
27
3.6k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
51k
4 Signs Your Business is Dying
shpigford
182
22k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
The Pragmatic Product Professional
lauravandoore
32
6.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
BBQ
matthewcrist
86
9.5k
The Invisible Side of Design
smashingmag
299
50k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
950
A Modern Web Designer's Workflow
chriscoyier
693
190k
Transcript
明⽇からできる! 技術的負債の返済を加速する ための実践ガイド 〜『ホットペッパービューティー』の事例をもとに〜 株式会社リクルート 浅井 徹
⾃⼰紹介 • 浅井 徹 (あさい とおる) • 略歴 ◦ (前職)
▪ 2014年に新卒⼊社 ▪ iOSアプリエンジニア ◦ 株式会社リクルート ▪ 2019年に中途⼊社 ▪ 『ホットペッパーグルメ』 ▪ 『ホットペッパービューティー』 • 現在の仕事内容 ◦ 『ホットペッパービューティー』アプリの品質を、 中⻑期な視点で維持‧向上するための活動 https://x.com/trsxxii https://github.com/trsxxii
『ホットペッパービューティー』とは? ▼国内最⼤級のヘアサロン‧リラク&ビューティサロンの検索‧予約サービス • ネイティブアプリ(iOS‧Android)とWeb(PC‧SP)にて提供 • キレイ領域(リラク&ビューティ)ではネイル‧まつげ‧リラク‧エステなど複数ジャンルに対応 HOT PEPPER Beauty 経由での年間予約数※1
1億8388万件 (2023年度) ※1 予約受付⽇ベース
今⽇の⽬的 「機能開発で溜まった技術的負債を返済できずに困っている⼈」 に
今⽇の⽬的 「機能開発で溜まった技術的負債を返済できずに困っている⼈」 に 「改善の分類⽅法とKPIツリーに基づいた優先順位の付け⽅」 を伝えることで
今⽇の⽬的 「機能開発で溜まった技術的負債を返済できずに困っている⼈」 に 「改善の分類⽅法とKPIツリーに基づいた優先順位の付け⽅」 を伝えることで 「明⽇から技術的負債の返済活動を始めてほしい」
みなさんこんなことありませんか? • 機能開発は順調にやれている • その反⾯、技術的負債が溜まってしまっており、 負債を返済したいのになかなか着⼿できない • ⼯数が限られている中でどう進めるのが良いかわからない
『ホットペッパービューティー』アプリでも同じ課題が‧‧‧ • リプレイスから約6年が経っており、技術的負債は溜まってきていた • 返済活動をメンバーの主体性に任せていた結果、担当者によって掛ける⼯数が異なる など、計画性がなく気合でどうにかする運⽤となってしまっていた • ゴール定義が無かったので、順調に進捗しているかわからなかった
『ホットペッパービューティー』アプリでも同じ課題が‧‧‧ • リプレイスから約6年が経っており、技術的負債は溜まってきていた • 返済活動をメンバーの主体性に任せていた結果、担当者によって掛ける⼯数が異なる など、計画性がなく気合でどうにかする運⽤となってしまっていた • ゴール定義が無かったので、順調に進捗しているかわからなかった いまは計画的かつ順調に返済活動が出来ているので、ご紹介!
発表の流れ 発散 収束 決定
と、その前に
と、その前に この活動を⼀緒にやる「仲間」を⾒つけること いくつかの⼯程は1⽇集まって集中して作業すること ポイントゼロ
と、その前に 『ホットペッパービューティー』では、 • チームリーダー、iOS/Androidリーダーの計3名 + 上司のレビュー • つぎの3⼯程は1⽇集まってがっつり集中 ◦ 「理想の世界観を定義」
◦ 「理想‧課題の仮説を洗い出す」 ◦ 「仮説のマージと改善の分類」 この活動を⼀緒にやる「仲間」を⾒つけること いくつかの⼯程は1⽇集まって集中して作業すること ポイントゼロ
理想の世界観を定義 発散 収束 決定
理想の世界観を定義 技術的負債の返済を考える上で… • ⾃分たちはプロダクトをどうしたいのか • どんなプロダクトにしていきたいか ⾔語化して形に残し、悩んだときに⽴ち返る場所として使う
理想の世界観を定義 技術的負債の返済を考える上で… • ⾃分たちはプロダクトをどうしたいのか • どんなプロダクトにしていきたいか ⾔語化して形に残し、悩んだときに⽴ち返る場所として使う とにかく徹底的に話し合う ポイント①
理想の世界観を定義 ~ 『ホットペッパービューティー』では ~
理想の世界観を定義 ~ 『ホットペッパービューティー』では ~ デリバリー短縮 • アプリ公開までの納期を短縮することで 多くの案件をリリースし、予約数‧売上に貢献出来ている 品質向上 •
障害が起こらず安定して使い続けられている • 技術的負債の継続的な返済が出来ている • 開発中の弊害が少なく開発速度が速い
理想の仮説を洗い出す 発散 収束 決定
理想の仮説を洗い出す いまある最新技術などのやりたいこと(=理想の仮説)とその理由の洗い出し • 効果の有無は関係なくすべて洗い出す (=まだ仮説状態でOK) • 洗い出しと同時に簡単なグルーピングもしておく
理想の仮説を洗い出す いまある最新技術などのやりたいこと(=理想の仮説)とその理由の洗い出し • 効果の有無は関係なくすべて洗い出す (=まだ仮説状態でOK) • 洗い出しと同時に簡単なグルーピングもしておく ⽇頃から最新技術を理解しておく 普段の業務中に常に理想を考えておく ポイント②
理想の仮説を洗い出す ~ 『ホットペッパービューティー』では ~
理想の仮説を洗い出す ~ 『ホットペッパービューティー』では ~
課題の仮説と解決策案を洗い出す 発散 収束 決定
課題の仮説と解決策案を洗い出す いまのプロダクトの課題であろうもの(=課題の仮説)とその解決策の案を洗い出す • 実際に課題かどうかは関係なくすべて洗い出す (=まだ仮説状態でOK) • メンバーにアンケートをするなど、実装時の細かい課題も洗い出す • 洗い出した課題を「なぜなぜ分析」で分析しておく •
洗い出しと同時に簡単なグルーピングもしておく
課題の仮説と解決策案を洗い出す いまのプロダクトの課題であろうもの(=課題の仮説)とその解決策の案を洗い出す • 実際に課題かどうかは関係なくすべて洗い出す (=まだ仮説状態でOK) • メンバーにアンケートをするなど、実装時の細かい課題も洗い出す • 洗い出した課題を「なぜなぜ分析」で分析しておく •
洗い出しと同時に簡単なグルーピングもしておく リーダーでもコードを触って現場感を知っている なぜなぜ分析で真因を突き⽌める ポイント③
課題の仮説と解決策案を洗い出す ~ 『ホットペッパービューティー』では ~
課題の仮説と解決策案を洗い出す ~ 『ホットペッパービューティー』では ~
課題の仮説と解決策案を洗い出す ~ 『ホットペッパービューティー』では ~
仮説のマージと改善の分類 発散 収束 決定
仮説のマージと改善の分類 「課題の仮説と解決策案」を「理想の仮説」にマージする • 理想の仮説は、課題に関係なく洗い出されていて、広い範囲をカバーしているはず 再度グルーピングをすると、これが改善の分類となる • 理想の仮説とその取り組みをやりたい理由、課題の仮説とその解決策案を再度グルー ピング
仮説のマージと改善の分類 ~ 『ホットペッパービューティー』では ~
仮説のマージと改善の分類 ~ 『ホットペッパービューティー』では ~
整理‧評価 発散 収束 決定
整理‧評価 改善の分類と施策(=理想の仮説‧課題の仮説と解決策案)を表に書き写し、 コストとリターンを埋めていく • コストとリターンは「⼤中⼩」で3秒⾒積もり スコープを絞っていく • 『ホットペッパービューティー』ではコスト⼤、リターン⼤をスコープとした • それ以外の施策は、別途保守で扱うこととした
整理‧評価 改善の分類と施策(=理想の仮説‧課題の仮説と解決策案)を表に書き写し、 コストとリターンを埋めていく • コストとリターンは「⼤中⼩」で3秒⾒積もり スコープを絞っていく • 『ホットペッパービューティー』ではコスト⼤、リターン⼤をスコープとした • それ以外の施策は、別途保守で扱うこととした
計画が必要な⼤きさの課題を取り扱う ポイント④
整理‧評価 ~ 『ホットペッパービューティー』では ~
整理‧評価 ~ 『ホットペッパービューティー』では ~ コスト‧リターン (⼤‧中‧⼩)
ファクトチェック 発散 収束 決定
ファクトチェック 解決する課題が本当に課題なのかをチェックする • おそらく⼀般的に⾔われる課題が多くあるはず • 本当に⾃分たちのプロダクトでも⾔えることなのか?をチェック
ファクトチェック 定量で測れる場合は定量調査 • 静的解析ツール‧バグや障害チケットの数など • ⽐較対象やしきい値は、社内の他プロダクトと⽐較 or ⼀般的なしきい値を調べる 定量で測れない場合は定性調査 •
ソースコードをいくつか調査して証拠を集める • 過去の障害履歴を遡ってKPI毀損数を計算 • etc
ファクトチェック 定量で測れる場合は定量調査 • 静的解析ツール‧バグや障害チケットの数など • ⽐較対象やしきい値は、社内の他プロダクトと⽐較 or ⼀般的なしきい値を調べる 定量で測れない場合は定性調査 •
ソースコードをいくつか調査して証拠を集める • 過去の障害履歴を遡ってKPI毀損数を計算 • etc 本当に課題か⾒極めて、改善に取り組む意義を確⽴する ポイント⑤
ファクトチェック(補⾜) ファクトチェックするには遅くないか?という意⾒に対して、、、 これらの理由で、評価をしてスコープを絞った上で、チェックするようにした • 定量で出来るファクトチェックばかりではない • 定性調査をするのはかなり労⼒が必要 • ある程度現場感を知っていたので、⼤きく外れることはない 効果が薄いものはあったが、
課題ではないものはなかった
ファクトチェック ~ 『ホットペッパービューティー』では ~
KPIツリーとの紐付け 発散 収束 決定
KPIツリーとの紐付け KPIツリー内の「改善の分類」の指標となるノードに、実績値を記載していく • KPIツリーがない場合は「改善の分類」の指標となるノードとパスだけでも作成する • 実績値が出せない場合は、⼀旦感覚値で仮置きして考えてもいい ◦ 重要なのは改善の分類の優先度のため、⼤きく変わらなければ仮置きでもOK 最も重要なKPIに⼤きな影響を与える順で、優先度を付けていく
KPIツリーとの紐付け
KPIツリーとの紐付け 1000件/年 20件/年 200件/年 30件/年 …
KPIツリーとの紐付け 1000件/年 20件/年 200件/年 30件/年 … 1件あたり 50件/年
KPIツリーとの紐付け 1000件/年 20件/年 200件/年 30件/年 … 1件あたり 0.1件/年 1件あたり 50件/年
KPIツリーとの紐付け ~ 『ホットペッパービューティー』では ~
優先度確定 発散 収束 決定
優先度確定 ~ 『ホットペッパービューティー』では ~ 優先度 改善の分類 1 コーディングコスト削減 2 コード認知コスト削減
3 バグ/障害の流出防⽌ 4 障害復旧時間(MTTR)短縮 5 バグ/障害の混⼊防⽌
しかし、、、 改善の分類に紐づく施策に技術的な依存関係がある場合、 優先度順には実⾏できない可能性がある • 改善の分類の優先度と、 それに紐づく施策の技術的な依存関係を紐解き、 実際の計画に落とし込む
その後 ~ 『ホットペッパービューティー』では ~
その後 ~ 『ホットペッパービューティー』では ~ 各施策を⾒積もれば、完了⽬処が⾒えて、施策順序も決まる ポイント⑥
結果 改善の分類とそれに紐づく施策が整理されて、⼯数や効果と優先度が明確になり • 適切なメンバーをアサインできるようになった • 限られた⼯数の中で効果を最⼤化できるようになった • 理想に向かう計画を⽴てられるようになった
結果 改善の分類とそれに紐づく施策が整理されて、⼯数や効果と優先度が明確になり • 適切なメンバーをアサインできるようになった • 限られた⼯数の中で効果を最⼤化できるようになった • 理想に向かう計画を⽴てられるようになった なによりも、優先度の根拠が明確にあるため、 ⾃分たちが⾃信を持って進められる状態になった
結果のその先 以前の気合でどうにかする運⽤だと課題も⽬的もはっきりせず、 技術的な解決そのものが⽬的化してしまっていた Before
結果のその先 以前の気合でどうにかする運⽤だと課題も⽬的もはっきりせず、 技術的な解決そのものが⽬的化してしまっていた Before 効果を語れるようになったことで、 事業や企画組織から理解を得やすく、⼯数獲得しやすくなった After
結果のその先 以前の気合でどうにかする運⽤だと課題も⽬的もはっきりせず、 技術的な解決そのものが⽬的化してしまっていた Before 効果を語れるようになったことで、 事業や企画組織から理解を得やすく、⼯数獲得しやすくなった After 膨⼤な⼯数がかかり、効果を語るのが難しい案件でも、 適切に効果を語ることができ、案件化することができた そのため
結果のその先 具体的には、iOSアプリにて SwiftUI導⼊を案件化できた (案件化 = KPIに寄与する事業施策として対応をするもの) • UIライブラリの置き換えなので⼀⾒、KPIに直接紐づかないように⾒える • しかし今回の整理のおかげで、SwiftUIを導⼊して開発コストを下げることで開発⽣
産性に寄与し、最終的にはKPIである予約数に影響があることを伝えられた • つまり、優先度と効果を適切に語れたことで案件化することができた
まとめ 発散 収束 決定 +技術的な依存関係の紐解き
https://www.recruit.co.jp/special/techconference2025 リクルート テックカンファレンス リクルートの開発事例・ナレッジを共有する 技術カンファレンス
WE ARE HIRING !
THANK YOU FOR WATCHING !