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 25, 2024
Technology
2
200
スマートフォン版サロンボードの 機能改善の土台づくり
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、小谷野の資料です。
Recruit
PRO
March 25, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
SIerでの経験が活きた!『SUUMO』『ゼクシィ』担当PdMの企画プロセスを紐解く〜プロデザ!〜
recruitengineers
PRO
0
68
事業目的とのプロトコル変換
recruitengineers
PRO
4
96
Boosting Hotel Profits: The Power of Enhanced Cancellation Predictions
recruitengineers
PRO
3
670
ヘルススコアの改善の過程で起きた嬉しい変化
recruitengineers
PRO
4
720
スクラム開発導入による 他組織を巻き込んだ開発生産性向上の取り込み
recruitengineers
PRO
3
380
大公開!SUUMOの裏側 -データ組織の取り組みLT会-
recruitengineers
PRO
4
120
FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
recruitengineers
PRO
5
160
組合せ最適化による問題解決の実践的アプローチ
recruitengineers
PRO
8
1.4k
社内のAI活用事例と活用促進のための取り組みを大公開!
recruitengineers
PRO
4
710
Other Decks in Technology
See All in Technology
AOAI Dev Day - Opening Session
yoshidashingo
2
440
Flutter研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
160
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
390
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
15
3.7k
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8.1k
ここがすごいよ! AWS Systems Manager!
saichan11
0
1.8k
コミュニティサービスに「あなたへ」フィードを リリースするまでの試行錯誤
takapy
1
150
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
150
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
20240725 LLMによるDXのビジョンと、今何からやるべきか @Azure OpenAI Service Dev Day
nrryuya
3
1.2k
Featured
See All Featured
Facilitating Awesome Meetings
lara
46
5.8k
A better future with KSS
kneath
231
17k
The Brand Is Dead. Long Live the Brand.
mthomps
52
36k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
Building Applications with DynamoDB
mza
89
5.8k
Designing with Data
zakiwarfel
96
5k
How STYLIGHT went responsive
nonsquared
93
5k
GitHub's CSS Performance
jonrohan
1026
450k
Become a Pro
speakerdeck
PRO
15
4.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.3k
Transcript
スマートフォン版サロンボードの 機能改善の土台づくり プロダクトディベロップメント室 販促領域開発ディレクションユニット ⼩⾕野 雄史
⼩⾕野 雄史 クラフトビール‧レコード‧ラジオ 経歴 / Career 2017年リクルートホールディングス新卒⼊社。 旅⾏領域にて『じゃらん』のレコメンド施策の提案‧実装 や、飲⾷領域にて『Airメイト』のAndroidアプリ開発に携 わる。
現在はビューティー領域にて『ホットペッパービュー ティー』のAPIの開発リーダーを担当。 さらに、開発チームの⽴ち上げやリプレイスをきっかけにス マートフォン版『サロンボード』の開発リーダーや開発 ディレクターを担当。 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 販促領域開発ディレクションユニット 飲⾷‧ビューティー領域開発ディレクション部 ビューティー開発ディレクショングループ
プロダクト紹介:『サロンボード』 サロンボード利⽤店舗数 HOT PEPPER Beauty 経由での年間予約数※1 ▼美容室や、ネイル‧まつげ‧リラク‧エステ各サロン向け予約‧顧客管理サービス • 予約‧顧客管理を始めとして、会計‧集計‧分析‧HOT PEPPER
Beauty上の掲載情報管理など様々な機能を提供 • サロンワークにおける業務効率アップ‧集客の最⼤化を⽀援 • PC版Webアプリ(タブレット含む)とスマートフォン(SP)版Webアプリを提供 1億6500万件以上 全国10万店舗以上 ※1 予約受付⽇ベース
▼SP版サロンボードの位置付け • 2012年のリリース当初は、PC版の利⽤がメインでSP版はサブ的に利⽤するという位置付けだった • PC版と⽐較してSP版は提供機能も少なく、SP端末のユースケースに特化したSP版独⾃の機能も存在していなかった • SP版の機能改善もアクティブに進めておらず、⼀部画⾯のUI/UXの改善に留まるのみだった スマートフォン(SP)版サロンボードが抱えていた課題
▼SP版サロンボードの需要の変化 • 近年はSP版の需要が⾼まり、PC版でしか利⽤できない機能をSP端末からでも利⽤したいというニーズが増加していた • しかし、SP版の機能が⾜りない‧使いづらいという理由からSP端末からPC版を利⽤するユーザーが増えていた ▼SP端末に最適化した機能提供ができていない • SP端末からPC版を利⽤できたとしても、SP端末に最適化した機能を提供できているわけではなかった • SP版のポテンシャルを⼗分に発揮できるように改善できれば、サロンボード全体の提供価値も向上できるはず
• そこで、事業としてSP版の抜本的な機能改善に取り組むことを検討していた スマートフォン(SP)版サロンボードが抱えていた課題 SP端末だと ⾒切れてしまう PC版をSP端末から利⽤した場合のイメージ SP端末からの操作を 前提としたUIに なっていない
▼SP版サロンボードの需要の変化 • 近年はSP版の需要が⾼まり、PC版でしか利⽤できない機能をSP端末からでも利⽤したいというニーズが増加していた • しかし、SP版の機能が⾜りない‧使いづらいという理由からSP端末からPC版を利⽤するユーザーが増えていた ▼SP端末に最適化した機能提供ができていない • SP端末からPC版を利⽤できたとしても、SP端末に最適化した機能を提供できているわけではなかった • SP版のポテンシャルを⼗分に発揮できるように改善できれば、サロンボード全体の提供価値も向上できるはず
• そこで、事業としてSP版の抜本的な機能改善に取り組むことを検討していた スマートフォン(SP)版サロンボードが抱えていた課題 SP端末だと ⾒切れてしまう PC版をSP端末から利⽤した場合のイメージ SP端末からの操作を 前提としたUIに なっていない ユーザーのためにも、事業としても SPサロンボードの 抜本的な機能改善を進めたい! しかし SP版サロンボードの改善を思うように 進めることが難しい状況にあった
SP版サロンボードの改善が進まない要因 保守性低下のサイクルによる開発スピードの低下 継続的な改善にフォーカスしづらい開発体制
保守性低下のサイクルによる開発スピードの低下 ▼技術的負債に起因する保守性低下のサイクル • 過去に過度に短期デリバリーを優先した結果、テストや適切な設計の⽋如などの技術的負債が積み重なっていた • それによって中⻑期的な品質担保まで⼿が回らない状態が続き、さらに保守性が低下するというサイクルに陥っていた
継続的な改善にフォーカスしづらい開発体制 ▼SP版専任の開発チームの不在 • PC版‧SP版でモジュールは分かれているものの、同⼀のチームでPC版‧SP版の両⽅を開発しているため SP版にフォーカスできるような開発体制ではなく、SP版の改善にもオーナーシップを持ちづらくなっていた ▼SP版改善の優先度が上げづらいプロダクトバックログ • プロダクトバックログの優先順位は、緊急度‧重要度‧コスト‧効果など複数観点からPOやチームが判断している • PC版とSP版のユーザー規模を⽐較すると、インパクトが⼤きいPC版の改善の⽅が優先されやすくなってしまっており
SP版の継続的な改善改善サイクルを回したり、同じメンバーを継続してアサインするのが難しくなっていた
継続的な改善にフォーカスしづらい開発体制 ▼SP版専任の開発チームの不在 • PC版‧SP版でモジュールは分かれているものの、同⼀のチームでPC版‧SP版の両⽅を開発しているため SP版にフォーカスできるような開発体制ではなく、SP版の改善にもオーナーシップを持ちづらくなっていた ▼SP版改善の優先度が上げづらいプロダクトバックログ • プロダクトバックログの優先順位は、緊急度‧重要度‧コスト‧効果など複数観点からPOやチームが判断している • PC版とSP版のユーザー規模を⽐較すると、インパクトが⼤きいPC版の改善の⽅が優先されやすくなってしまっており
SP版の継続的な改善改善サイクルを回したり、同じメンバーを継続してアサインするのが難しくなっていた 専任の開発チームを立ち上げて リプレイスによって保守性を改善することで 機能改善にフォーカスできるようにしたい!
継続的な改善にフォーカスしづらい開発体制 ▼SP版専任の開発チームの不在 • PC版‧SP版でモジュールは分かれているものの、同⼀のチームでPC版‧SP版の両⽅を開発しているため SP版にフォーカスできるような開発体制ではなく、SP版の改善にもオーナーシップを持ちづらくなっていた ▼SP版改善の優先度が上げづらいプロダクトバックログ • プロダクトバックログの優先順位は、緊急度‧重要度‧コスト‧効果など複数観点からPOやチームが判断している • PC版とSP版のユーザー規模を⽐較すると、インパクトが⼤きいPC版の改善の⽅が優先されやすくなってしまっており
SP版の継続的な改善改善サイクルを回したり、同じメンバーを継続してアサインするのが難しくなっていた しかし、それらを進めづらい 別の要因があった・・・
▼SP版は1プロダクトというよりは1サブシステムという位置付けになっていた • サロンボードというプロダクトのメインスコープはPC版になっており、SP版は1サブシステム的な位置付けだった • サロンボード全体としてのプロダクトビジョンは定義されていたものの、あくまでPC版がメインだったため SP端末からの利⽤ニーズを考慮したSP版独⾃のプロダクトビジョンや提供価値を定義できていなかった ▼SP版改善の妥当性や、SP版にフォーカスした開発体制の必要性を明確にできていなかった • SP版として取り組むべき機能改善のプロダクトバックログアイテムは⽤意されていたが SP版サロンボードの中⻑期的な⽅向性や、継続的に追うべき価値やKPIを定められていなかった
• 結果的にリプレイスや機能改善の妥当性や、SP版にフォーカスした開発体制の必要性が説明しづらくなっていた SP版サロンボードが1プロダクトという位置付けになっていない
SP版サロンボードの改善が進まない要因の構造 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下
SP版サロンボードの改善が進まない要因の構造 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 システム 組織 プロダクト 保守性低下のサイクルによる開発スピードの低下
SP版サロンボードの改善が進まない要因の構造 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 システム 組織 プロダクト 保守性低下のサイクルによる開発スピードの低下
エンジニアが最も得意とするシステム⾯だけを 変えようとしても全体の状況は変わりづらい 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト
エンジニアが最も得意とするシステム⾯だけを 変えようとしても全体の状況は変わりづらい 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト エンジニアとして得意な部分だけに着目して 改善の提案をしても
うまくステークホルダーの合意を得られなかった
1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト 顧客や市場のニーズや事業の変化に合わせて ⼟台部分も⼀緒に変えていく必要がある
1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト 顧客や市場のニーズや事業の変化に合わせて ⼟台部分も⼀緒に変えていく必要がある プロダクトとしてどう変化していくべきかの 自分なりの仮説や戦略を持ち込みながら
ステークホルダーを巻き込むことで 協力を得られやすくしていった
1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト ▶ 段階的なシステムのリプレイス ▶ 開発チームとプロダクトバックログの分離
▶ プロダクトビジョンやKPIの定義 1エンジニアとして3つのアプローチを提案して プロダクト→組織→システムの順で実施
プロダクト:SP版独⾃のプロダクトビジョンやKPIの定義 ▼SP版の1プロダクトとして再定義 • PC版とSP版では業務上のユースケースが⼤きく異なり、そもそも提供価値⾃体が異なるため SP版をPC版に付随する1つのサブシステムではなく、1つのプロダクトとして位置付けを再定義した • PdMと⼀緒にSP版としてのプロダクトビジョンや提供価値、プロダクトKGI‧KPIなどを定めた ▼SP版改善の妥当性や、SP版にフォーカスした開発体制の必要性を明確にした • サロンボード全体の⽅針とは整合性を取りつつも、SP版としての⽬指すべき⽅向性と提供価値を定めることで
SP版改善の妥当性を明確にし、専任の開発チームを作りやすい状態にした ※必ずしもプラットフォーム軸で価値を定義するのが最適とは限らないが、現時点のサロンボードではSP版として価値を定義することがよいと判断
組織:開発チームとプロダクトバックログの分離 ▼開発チームの分離 • サロンボード全体の開発チームを分離して、SP版にオーナーシップを持つ専任の開発チームを新たに⽴ち上げ • SP版の継続的な改善にフォーカスできるような開発体制を作った ▼プロダクトバックログの分離 • サロンボード全体のプロダクトバックログを分離し、SP版の価値提供に集中したプロダクトバックログを作成 •
チームとして、SP版の課題に集中できるようになり、機能改善や保守性の改善に着⼿しやすくなった
システム:段階的なシステムのリプレイス ▼段階的なシステムのリプレイス • PC版とSP版は別システムとして稼働していたため、SP版のシステムをリプレイスして保守性を根本的に改善 • 既存システムと並⾏稼働させ、リプレイス完了した画⾯からリリースしてトラフィックを流すようにした ▼継続的な改善サイクル • システムやコードを書き換えるだけでなく、必要に応じて機能追加や改善も同時に実施 •
段階的なシステムリプレイスと、リプレイスした機能のさらなる改善を並⾏で実施
保守性の⾼いシステムに置き換えられ 少ない⼯数で改善ができるようになった SP版にフォーカスして改善し続けられる 開発体制を作ることができた SP版を個別のプロダクトとして 重視できるようになった アプローチの結果どう変化したのか システム 組織 プロダクト
保守性の⾼いシステムに置き換えられ 少ない⼯数で改善ができるようになった SP版にフォーカスして改善し続けられる 開発体制を作ることができた SP版を個別のプロダクトとして 重視できるようになった アプローチの結果どう変化したのか システム 組織 プロダクト
SP版サロンボードの 機能改善の土台が揃うことで 素早い改善サイクルが回り出すようになった!
さいごに ▼プロダクトの機能改善がうまく進められないとき、その背景に改善の優先度をあげづらい構造がある • プロダクトとして価値をどう定義するかが、組織やシステムの構造にも影響する • 顧客‧市場ニーズや事業の変化によってプロダクトが変わるとき、合わせて組織‧システムも最適化する必要がある ▼エンジニアとしてシステムの課題を解決しようとするとき • 時にはシステムだけを変えようとせずに、その⼟台となる組織やプロダクトの課題にも注⽬する •
システムリプレイスが必要になるまで技術的負債が積み重なるとき、プロダクトや組織の構造の問題を疑う システム 組織 プロダクト プロダクトバックログ KPI プロダクト価値 プロダクトビジョン チーム 技術的負債 保守性
さいごに ▼プロダクトの機能改善がうまく進められないとき、その背景に改善の優先度をあげづらい構造がある • プロダクトとして価値をどう定義するかが、組織やシステムの構造にも影響する • 顧客‧市場ニーズや事業の変化によってプロダクトが変わるとき、合わせて組織‧システムも最適化する必要がある ▼エンジニアとしてシステムの課題を解決しようとするとき • 時にはシステムだけを変えようとせずに、その⼟台となる組織やプロダクトの課題にも注⽬する •
システムリプレイスが必要になるまで技術的負債が積み重なるとき、プロダクトや組織の構造の問題を疑う システム 組織 プロダクト プロダクトバックログ KPI プロダクト価値 プロダクトビジョン チーム 技術的負債 保守性 エンジニアとして システムだけではなく プロダクトや組織にも目を向けよう!