明日からできる！技術的負債の返済を加速するための実践ガイド～『ホットペッパービューティー』の事例をもとに～

Slide 1

Slide 1 text

明⽇からできる！技術的負債の返済を加速するための実践ガイド〜『ホットペッパービューティー』の事例をもとに〜株式会社リクルート浅井徹

Slide 2

Slide 2 text

⾃⼰紹介 ● 浅井徹 (あさいとおる) ● 略歴 ○ (前職) ■ 2014年に新卒⼊社 ■ iOSアプリエンジニア ○ 株式会社リクルート ■ 2019年に中途⼊社 ■ 『ホットペッパーグルメ』 ■ 『ホットペッパービューティー』 ● 現在の仕事内容 ○ 『ホットペッパービューティー』アプリの品質を、中⻑期な視点で維持‧向上するための活動 https://x.com/trsxxii https://github.com/trsxxii

Slide 3

Slide 3 text

『ホットペッパービューティー』とは？ ▼国内最⼤級のヘアサロン‧リラク&ビューティサロンの検索‧予約サービス ● ネイティブアプリ(iOS‧Android)とWeb(PC‧SP)にて提供 ● キレイ領域（リラク&ビューティ）ではネイル‧まつげ‧リラク‧エステなど複数ジャンルに対応 HOT PEPPER Beauty 経由での年間予約数※1 1億8388万件 (2023年度) ※1 予約受付⽇ベース

Slide 4

Slide 4 text

今⽇の⽬的「機能開発で溜まった技術的負債を返済できずに困っている⼈」に

Slide 5

Slide 5 text

今⽇の⽬的「機能開発で溜まった技術的負債を返済できずに困っている⼈」に「改善の分類⽅法とKPIツリーに基づいた優先順位の付け⽅」を伝えることで

Slide 6

Slide 6 text

今⽇の⽬的「機能開発で溜まった技術的負債を返済できずに困っている⼈」に「改善の分類⽅法とKPIツリーに基づいた優先順位の付け⽅」を伝えることで「明⽇から技術的負債の返済活動を始めてほしい」

Slide 7

Slide 7 text

みなさんこんなことありませんか？ ● 機能開発は順調にやれている ● その反⾯、技術的負債が溜まってしまっており、負債を返済したいのになかなか着⼿できない ● ⼯数が限られている中でどう進めるのが良いかわからない

Slide 8

Slide 8 text

『ホットペッパービューティー』アプリでも同じ課題が‧‧‧ ● リプレイスから約6年が経っており、技術的負債は溜まってきていた ● 返済活動をメンバーの主体性に任せていた結果、担当者によって掛ける⼯数が異なるなど、計画性がなく気合でどうにかする運⽤となってしまっていた ● ゴール定義が無かったので、順調に進捗しているかわからなかった

Slide 9

Slide 9 text

Slide 10

Slide 10 text

発表の流れ発散収束決定

Slide 11

Slide 11 text

と、その前に

Slide 12

Slide 12 text

と、その前にこの活動を⼀緒にやる「仲間」を⾒つけることいくつかの⼯程は1⽇集まって集中して作業することポイントゼロ

Slide 13

Slide 13 text

と、その前に『ホットペッパービューティー』では、 ● チームリーダー、iOS/Androidリーダーの計3名 + 上司のレビュー ● つぎの3⼯程は1⽇集まってがっつり集中 ○ 「理想の世界観を定義」 ○ 「理想‧課題の仮説を洗い出す」 ○ 「仮説のマージと改善の分類」この活動を⼀緒にやる「仲間」を⾒つけることいくつかの⼯程は1⽇集まって集中して作業することポイントゼロ

Slide 14

Slide 14 text

理想の世界観を定義発散収束決定

Slide 15

Slide 15 text

理想の世界観を定義技術的負債の返済を考える上で… ● ⾃分たちはプロダクトをどうしたいのか ● どんなプロダクトにしていきたいか⾔語化して形に残し、悩んだときに⽴ち返る場所として使う

Slide 16

Slide 16 text

理想の世界観を定義技術的負債の返済を考える上で… ● ⾃分たちはプロダクトをどうしたいのか ● どんなプロダクトにしていきたいか⾔語化して形に残し、悩んだときに⽴ち返る場所として使うとにかく徹底的に話し合うポイント①

Slide 17

Slide 17 text

理想の世界観を定義 ~ 『ホットペッパービューティー』では ~

Slide 18

Slide 18 text

理想の世界観を定義 ~ 『ホットペッパービューティー』では ~ デリバリー短縮 ● アプリ公開までの納期を短縮することで多くの案件をリリースし、予約数‧売上に貢献出来ている品質向上 ● 障害が起こらず安定して使い続けられている ● 技術的負債の継続的な返済が出来ている ● 開発中の弊害が少なく開発速度が速い

Slide 19

Slide 19 text

理想の仮説を洗い出す発散収束決定

Slide 20

Slide 20 text

理想の仮説を洗い出すいまある最新技術などのやりたいこと(=理想の仮説)とその理由の洗い出し ● 効果の有無は関係なくすべて洗い出す (=まだ仮説状態でOK) ● 洗い出しと同時に簡単なグルーピングもしておく

Slide 21

Slide 21 text

理想の仮説を洗い出すいまある最新技術などのやりたいこと(=理想の仮説)とその理由の洗い出し ● 効果の有無は関係なくすべて洗い出す (=まだ仮説状態でOK) ● 洗い出しと同時に簡単なグルーピングもしておく⽇頃から最新技術を理解しておく普段の業務中に常に理想を考えておくポイント②

Slide 22

Slide 22 text

理想の仮説を洗い出す ~ 『ホットペッパービューティー』では ~

Slide 23

Slide 23 text

理想の仮説を洗い出す ~ 『ホットペッパービューティー』では ~

Slide 24

Slide 24 text

課題の仮説と解決策案を洗い出す発散収束決定

Slide 25

Slide 25 text

課題の仮説と解決策案を洗い出すいまのプロダクトの課題であろうもの(=課題の仮説)とその解決策の案を洗い出す ● 実際に課題かどうかは関係なくすべて洗い出す (=まだ仮説状態でOK) ● メンバーにアンケートをするなど、実装時の細かい課題も洗い出す ● 洗い出した課題を「なぜなぜ分析」で分析しておく ● 洗い出しと同時に簡単なグルーピングもしておく

Slide 26

Slide 26 text

Slide 27

Slide 27 text

課題の仮説と解決策案を洗い出す ~ 『ホットペッパービューティー』では ~

Slide 28

Slide 28 text

課題の仮説と解決策案を洗い出す ~ 『ホットペッパービューティー』では ~

Slide 29

Slide 29 text

課題の仮説と解決策案を洗い出す ~ 『ホットペッパービューティー』では ~

Slide 30

Slide 30 text

仮説のマージと改善の分類発散収束決定

Slide 31

Slide 31 text

仮説のマージと改善の分類「課題の仮説と解決策案」を「理想の仮説」にマージする ● 理想の仮説は、課題に関係なく洗い出されていて、広い範囲をカバーしているはず再度グルーピングをすると、これが改善の分類となる ● 理想の仮説とその取り組みをやりたい理由、課題の仮説とその解決策案を再度グルーピング

Slide 32

Slide 32 text

仮説のマージと改善の分類 ~ 『ホットペッパービューティー』では ~

Slide 33

Slide 33 text

仮説のマージと改善の分類 ~ 『ホットペッパービューティー』では ~

Slide 34

Slide 34 text

整理‧評価発散収束決定

Slide 35

Slide 35 text

整理‧評価改善の分類と施策(=理想の仮説‧課題の仮説と解決策案)を表に書き写し、コストとリターンを埋めていく ● コストとリターンは「⼤中⼩」で3秒⾒積もりスコープを絞っていく ● 『ホットペッパービューティー』ではコスト⼤、リターン⼤をスコープとした ● それ以外の施策は、別途保守で扱うこととした

Slide 36

Slide 36 text

整理‧評価改善の分類と施策(=理想の仮説‧課題の仮説と解決策案)を表に書き写し、コストとリターンを埋めていく ● コストとリターンは「⼤中⼩」で3秒⾒積もりスコープを絞っていく ● 『ホットペッパービューティー』ではコスト⼤、リターン⼤をスコープとした ● それ以外の施策は、別途保守で扱うこととした計画が必要な⼤きさの課題を取り扱うポイント④

Slide 37

Slide 37 text

整理‧評価 ~ 『ホットペッパービューティー』では ~

Slide 38

Slide 38 text

整理‧評価 ~ 『ホットペッパービューティー』では ~ コスト‧リターン (⼤‧中‧⼩)

Slide 39

Slide 39 text

ファクトチェック発散収束決定

Slide 40

Slide 40 text

ファクトチェック解決する課題が本当に課題なのかをチェックする ● おそらく⼀般的に⾔われる課題が多くあるはず ● 本当に⾃分たちのプロダクトでも⾔えることなのか？をチェック

Slide 41

Slide 41 text

ファクトチェック定量で測れる場合は定量調査 ● 静的解析ツール‧バグや障害チケットの数など ● ⽐較対象やしきい値は、社内の他プロダクトと⽐較 or ⼀般的なしきい値を調べる定量で測れない場合は定性調査 ● ソースコードをいくつか調査して証拠を集める ● 過去の障害履歴を遡ってKPI毀損数を計算 ● etc

Slide 42

Slide 42 text

ファクトチェック定量で測れる場合は定量調査 ● 静的解析ツール‧バグや障害チケットの数など ● ⽐較対象やしきい値は、社内の他プロダクトと⽐較 or ⼀般的なしきい値を調べる定量で測れない場合は定性調査 ● ソースコードをいくつか調査して証拠を集める ● 過去の障害履歴を遡ってKPI毀損数を計算 ● etc 本当に課題か⾒極めて、改善に取り組む意義を確⽴するポイント⑤

Slide 43

Slide 43 text

ファクトチェック(補⾜) ファクトチェックするには遅くないか？という意⾒に対して、、、これらの理由で、評価をしてスコープを絞った上で、チェックするようにした ● 定量で出来るファクトチェックばかりではない ● 定性調査をするのはかなり労⼒が必要 ● ある程度現場感を知っていたので、⼤きく外れることはない効果が薄いものはあったが、課題ではないものはなかった

Slide 44

Slide 44 text

ファクトチェック ~ 『ホットペッパービューティー』では ~

Slide 45

Slide 45 text

KPIツリーとの紐付け発散収束決定

Slide 46

Slide 46 text

KPIツリーとの紐付け KPIツリー内の「改善の分類」の指標となるノードに、実績値を記載していく ● KPIツリーがない場合は「改善の分類」の指標となるノードとパスだけでも作成する ● 実績値が出せない場合は、⼀旦感覚値で仮置きして考えてもいい ○ 重要なのは改善の分類の優先度のため、⼤きく変わらなければ仮置きでもOK 最も重要なKPIに⼤きな影響を与える順で、優先度を付けていく

Slide 47

Slide 47 text

KPIツリーとの紐付け

Slide 48

Slide 48 text

KPIツリーとの紐付け 1000件/年 20件/年 200件/年 30件/年 …

Slide 49

Slide 49 text

KPIツリーとの紐付け 1000件/年 20件/年 200件/年 30件/年 … 1件あたり 50件/年

Slide 50

Slide 50 text

KPIツリーとの紐付け 1000件/年 20件/年 200件/年 30件/年 … 1件あたり 0.1件/年 1件あたり 50件/年

Slide 51

Slide 51 text

KPIツリーとの紐付け ~ 『ホットペッパービューティー』では ~

Slide 52

Slide 52 text

優先度確定発散収束決定

Slide 53

Slide 53 text

優先度確定 ~ 『ホットペッパービューティー』では ~ 優先度改善の分類 1 コーディングコスト削減 2 コード認知コスト削減 3 バグ/障害の流出防⽌ 4 障害復旧時間(MTTR)短縮 5 バグ/障害の混⼊防⽌

Slide 54

Slide 54 text

しかし、、、改善の分類に紐づく施策に技術的な依存関係がある場合、優先度順には実⾏できない可能性がある ● 改善の分類の優先度と、それに紐づく施策の技術的な依存関係を紐解き、実際の計画に落とし込む

Slide 55

Slide 55 text

その後 ~ 『ホットペッパービューティー』では ~

Slide 56

Slide 56 text

その後 ~ 『ホットペッパービューティー』では ~ 各施策を⾒積もれば、完了⽬処が⾒えて、施策順序も決まるポイント⑥

Slide 57

Slide 57 text

結果改善の分類とそれに紐づく施策が整理されて、⼯数や効果と優先度が明確になり ● 適切なメンバーをアサインできるようになった ● 限られた⼯数の中で効果を最⼤化できるようになった ● 理想に向かう計画を⽴てられるようになった

Slide 58

Slide 58 text

結果改善の分類とそれに紐づく施策が整理されて、⼯数や効果と優先度が明確になり ● 適切なメンバーをアサインできるようになった ● 限られた⼯数の中で効果を最⼤化できるようになった ● 理想に向かう計画を⽴てられるようになったなによりも、優先度の根拠が明確にあるため、⾃分たちが⾃信を持って進められる状態になった

Slide 59

Slide 59 text

結果のその先以前の気合でどうにかする運⽤だと課題も⽬的もはっきりせず、技術的な解決そのものが⽬的化してしまっていた Before

Slide 60

Slide 60 text

結果のその先以前の気合でどうにかする運⽤だと課題も⽬的もはっきりせず、技術的な解決そのものが⽬的化してしまっていた Before 効果を語れるようになったことで、事業や企画組織から理解を得やすく、⼯数獲得しやすくなった After

Slide 61

Slide 61 text

結果のその先以前の気合でどうにかする運⽤だと課題も⽬的もはっきりせず、技術的な解決そのものが⽬的化してしまっていた Before 効果を語れるようになったことで、事業や企画組織から理解を得やすく、⼯数獲得しやすくなった After 膨⼤な⼯数がかかり、効果を語るのが難しい案件でも、適切に効果を語ることができ、案件化することができたそのため

Slide 62

Slide 62 text

結果のその先具体的には、iOSアプリにて SwiftUI導⼊を案件化できた (案件化 = KPIに寄与する事業施策として対応をするもの) ● UIライブラリの置き換えなので⼀⾒、KPIに直接紐づかないように⾒える ● しかし今回の整理のおかげで、SwiftUIを導⼊して開発コストを下げることで開発⽣産性に寄与し、最終的にはKPIである予約数に影響があることを伝えられた ● つまり、優先度と効果を適切に語れたことで案件化することができた

Slide 63

Slide 63 text

まとめ発散収束決定 +技術的な依存関係の紐解き

Slide 64

Slide 64 text

https://www.recruit.co.jp/special/techconference2025 リクルートテックカンファレンスリクルートの開発事例・ナレッジを共有する技術カンファレンス