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
57
スマートフォン版サロンボードの 機能改善の土台づくり
2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、小谷野の資料です。
Recruit
PRO
March 25, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
460
プロデザ! BY リクルート vol.18_リクルートのリサーチ実践組織「リサーチブーストコミュニティ」
recruitengineers
PRO
3
300
事業状況の大きな変化を乗り越えるためのAirレジ オーダーのアジャイル開発
recruitengineers
PRO
1
67
横断組織から見たリクルートのインフラの歴史と目指すべきクラウド活用像
recruitengineers
PRO
1
30
Datadog による 自己完結的アプリケーションモニタリング
recruitengineers
PRO
4
270
プロデザ! BY リクルートvol.17_『じゃらんnet』公式アプリの高速リニューアル事例を大公開
recruitengineers
PRO
6
200
自己完結な開発者組織を支える プラットフォーム作り
recruitengineers
PRO
3
320
検索エンジニアが考える、 生成AI時代の人間の付加価値とは
recruitengineers
PRO
3
150
エンジニア思考で解決! 家事育児を劇的に進化させる開発プロセス応用術
recruitengineers
PRO
3
120
Other Decks in Technology
See All in Technology
生産性向上チームの紹介
cybozuinsideout
PRO
1
950
高専で制御を、大学でセンシングを学び、次は脳みそ
satoshirobatofujimoto
0
120
実例で紹介するRAG導入時の知見と精度向上の勘所
yamahiro
7
2k
Babylon.js JAPAN活動紹介 (2024/4)
limes2018
1
120
止まらないLinuxシステムを構築する_高信頼性クラスタ入門
koedoyoshida
3
2k
【SORACOM UG 東海】あらゆるモノがつながる社会へ、IoT と SORACOM
soracom
PRO
1
160
社内アプリで Cloudflare D1を プロダクト運用してみた体験談(Tokyo)
haochenx
0
130
IaCからAWSに入門した初心者が CloudFormationを通して考えた「AWS操作」の使い分け
maimyyym
2
530
MapLibreとAmazon Location Service
dayjournal
1
190
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
0
1.9k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
37k
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
1
740
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Building a Modern Day E-commerce SEO Strategy
aleyda
22
6.4k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Agile that works and the tools we love
rasmusluckow
325
20k
Writing Fast Ruby
sferik
622
60k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
Fireside Chat
paigeccino
22
2.6k
How to train your dragon (web standard)
notwaldorf
75
5.2k
Build The Right Thing And Hit Your Dates
maggiecrowley
25
2k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Optimising Largest Contentful Paint
csswizardry
13
2.4k
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 プロダクト価値 プロダクトビジョン チーム 技術的負債 保守性 エンジニアとして システムだけではなく プロダクトや組織にも目を向けよう!