スマートフォン版サロンボードの 機能改善の土台づくり

2024/02/21に、RECRUIT TECH CONFERENCE 2024で発表した、小谷野の資料です。

Transcript

1. スマートフォン版サロンボードの 機能改善の土台づくり プロダクトディベロップメント室 販促領域開発ディレクションユニット ⼩⾕野 雄史
2. ⼩⾕野 雄史 クラフトビール‧レコード‧ラジオ 経歴 / Career 2017年リクルートホールディングス新卒⼊社。 旅⾏領域にて『じゃらん』のレコメンド施策の提案‧実装 や、飲⾷領域にて『Airメイト』のAndroidアプリ開発に携 わる。 現在はビューティー領域にて『ホットペッパービュー ティー』のAPIの開発リーダーを担当。 さらに、開発チームの⽴ち上げやリプレイスをきっかけにス マートフォン版『サロンボード』の開発リーダーや開発 ディレクターを担当。 趣味 / Hobbies 株式会社リクルート プロダクトディベロップメント室 販促領域開発ディレクションユニット 飲⾷‧ビューティー領域開発ディレクション部 ビューティー開発ディレクショングループ
3. プロダクト紹介：『サロンボード』 サロンボード利⽤店舗数 HOT PEPPER Beauty 経由での年間予約数※1 ▼美容室や、ネイル‧まつげ‧リラク‧エステ各サロン向け予約‧顧客管理サービス • 予約‧顧客管理を始めとして、会計‧集計‧分析‧HOT PEPPER Beauty上の掲載情報管理など様々な機能を提供 • サロンワークにおける業務効率アップ‧集客の最⼤化を⽀援 • PC版Webアプリ(タブレット含む)とスマートフォン(SP)版Webアプリを提供 1億6500万件以上 全国10万店舗以上 ※1 予約受付⽇ベース
4. ▼SP版サロンボードの位置付け • 2012年のリリース当初は、PC版の利⽤がメインでSP版はサブ的に利⽤するという位置付けだった • PC版と⽐較してSP版は提供機能も少なく、SP端末のユースケースに特化したSP版独⾃の機能も存在していなかった • SP版の機能改善もアクティブに進めておらず、⼀部画⾯のUI/UXの改善に留まるのみだった スマートフォン(SP)版サロンボードが抱えていた課題
5. ▼SP版サロンボードの需要の変化 • 近年はSP版の需要が⾼まり、PC版でしか利⽤できない機能をSP端末からでも利⽤したいというニーズが増加していた • しかし、SP版の機能が⾜りない‧使いづらいという理由からSP端末からPC版を利⽤するユーザーが増えていた ▼SP端末に最適化した機能提供ができていない • SP端末からPC版を利⽤できたとしても、SP端末に最適化した機能を提供できているわけではなかった • SP版のポテンシャルを⼗分に発揮できるように改善できれば、サロンボード全体の提供価値も向上できるはず • そこで、事業としてSP版の抜本的な機能改善に取り組むことを検討していた スマートフォン(SP)版サロンボードが抱えていた課題 SP端末だと ⾒切れてしまう PC版をSP端末から利⽤した場合のイメージ SP端末からの操作を 前提としたUIに なっていない
6. ▼SP版サロンボードの需要の変化 • 近年はSP版の需要が⾼まり、PC版でしか利⽤できない機能をSP端末からでも利⽤したいというニーズが増加していた • しかし、SP版の機能が⾜りない‧使いづらいという理由からSP端末からPC版を利⽤するユーザーが増えていた ▼SP端末に最適化した機能提供ができていない • SP端末からPC版を利⽤できたとしても、SP端末に最適化した機能を提供できているわけではなかった • SP版のポテンシャルを⼗分に発揮できるように改善できれば、サロンボード全体の提供価値も向上できるはず • そこで、事業としてSP版の抜本的な機能改善に取り組むことを検討していた スマートフォン(SP)版サロンボードが抱えていた課題 SP端末だと ⾒切れてしまう PC版をSP端末から利⽤した場合のイメージ SP端末からの操作を 前提としたUIに なっていない ユーザーのためにも、事業としても SPサロンボードの 抜本的な機能改善を進めたい！ しかし SP版サロンボードの改善を思うように 進めることが難しい状況にあった
7. SP版サロンボードの改善が進まない要因 保守性低下のサイクルによる開発スピードの低下 継続的な改善にフォーカスしづらい開発体制
8. 保守性低下のサイクルによる開発スピードの低下 ▼技術的負債に起因する保守性低下のサイクル • 過去に過度に短期デリバリーを優先した結果、テストや適切な設計の⽋如などの技術的負債が積み重なっていた • それによって中⻑期的な品質担保まで⼿が回らない状態が続き、さらに保守性が低下するというサイクルに陥っていた
9. 継続的な改善にフォーカスしづらい開発体制 ▼SP版専任の開発チームの不在 • PC版‧SP版でモジュールは分かれているものの、同⼀のチームでPC版‧SP版の両⽅を開発しているため SP版にフォーカスできるような開発体制ではなく、SP版の改善にもオーナーシップを持ちづらくなっていた ▼SP版改善の優先度が上げづらいプロダクトバックログ • プロダクトバックログの優先順位は、緊急度‧重要度‧コスト‧効果など複数観点からPOやチームが判断している • PC版とSP版のユーザー規模を⽐較すると、インパクトが⼤きいPC版の改善の⽅が優先されやすくなってしまっており SP版の継続的な改善改善サイクルを回したり、同じメンバーを継続してアサインするのが難しくなっていた
10. 継続的な改善にフォーカスしづらい開発体制 ▼SP版専任の開発チームの不在 • PC版‧SP版でモジュールは分かれているものの、同⼀のチームでPC版‧SP版の両⽅を開発しているため SP版にフォーカスできるような開発体制ではなく、SP版の改善にもオーナーシップを持ちづらくなっていた ▼SP版改善の優先度が上げづらいプロダクトバックログ • プロダクトバックログの優先順位は、緊急度‧重要度‧コスト‧効果など複数観点からPOやチームが判断している • PC版とSP版のユーザー規模を⽐較すると、インパクトが⼤きいPC版の改善の⽅が優先されやすくなってしまっており SP版の継続的な改善改善サイクルを回したり、同じメンバーを継続してアサインするのが難しくなっていた 専任の開発チームを立ち上げて リプレイスによって保守性を改善することで 機能改善にフォーカスできるようにしたい！
11. 継続的な改善にフォーカスしづらい開発体制 ▼SP版専任の開発チームの不在 • PC版‧SP版でモジュールは分かれているものの、同⼀のチームでPC版‧SP版の両⽅を開発しているため SP版にフォーカスできるような開発体制ではなく、SP版の改善にもオーナーシップを持ちづらくなっていた ▼SP版改善の優先度が上げづらいプロダクトバックログ • プロダクトバックログの優先順位は、緊急度‧重要度‧コスト‧効果など複数観点からPOやチームが判断している • PC版とSP版のユーザー規模を⽐較すると、インパクトが⼤きいPC版の改善の⽅が優先されやすくなってしまっており SP版の継続的な改善改善サイクルを回したり、同じメンバーを継続してアサインするのが難しくなっていた しかし、それらを進めづらい 別の要因があった・・・
12. ▼SP版は1プロダクトというよりは１サブシステムという位置付けになっていた • サロンボードというプロダクトのメインスコープはPC版になっており、SP版は１サブシステム的な位置付けだった • サロンボード全体としてのプロダクトビジョンは定義されていたものの、あくまでPC版がメインだったため SP端末からの利⽤ニーズを考慮したSP版独⾃のプロダクトビジョンや提供価値を定義できていなかった ▼SP版改善の妥当性や、SP版にフォーカスした開発体制の必要性を明確にできていなかった • SP版として取り組むべき機能改善のプロダクトバックログアイテムは⽤意されていたが SP版サロンボードの中⻑期的な⽅向性や、継続的に追うべき価値やKPIを定められていなかった • 結果的にリプレイスや機能改善の妥当性や、SP版にフォーカスした開発体制の必要性が説明しづらくなっていた SP版サロンボードが1プロダクトという位置付けになっていない
13. SP版サロンボードの改善が進まない要因の構造 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下
14. SP版サロンボードの改善が進まない要因の構造 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 システム 組織 プロダクト 保守性低下のサイクルによる開発スピードの低下
15. SP版サロンボードの改善が進まない要因の構造 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 システム 組織 プロダクト 保守性低下のサイクルによる開発スピードの低下
16. エンジニアが最も得意とするシステム⾯だけを 変えようとしても全体の状況は変わりづらい 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト
17. エンジニアが最も得意とするシステム⾯だけを 変えようとしても全体の状況は変わりづらい 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト エンジニアとして得意な部分だけに着目して 改善の提案をしても うまくステークホルダーの合意を得られなかった
18. 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト 顧客や市場のニーズや事業の変化に合わせて ⼟台部分も⼀緒に変えていく必要がある
19. 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト 顧客や市場のニーズや事業の変化に合わせて ⼟台部分も⼀緒に変えていく必要がある プロダクトとしてどう変化していくべきかの 自分なりの仮説や戦略を持ち込みながら ステークホルダーを巻き込むことで 協力を得られやすくしていった
20. 1プロダクトという位置付けになっていない 継続的な改善にフォーカスしづらい開発体制 保守性低下のサイクルによる開発スピードの低下 システム 組織 プロダクト         ▶ 段階的なシステムのリプレイス         ▶ 開発チームとプロダクトバックログの分離         ▶ プロダクトビジョンやKPIの定義 1エンジニアとして3つのアプローチを提案して プロダクト→組織→システムの順で実施
21. プロダクト：SP版独⾃のプロダクトビジョンやKPIの定義 ▼SP版の１プロダクトとして再定義 • PC版とSP版では業務上のユースケースが⼤きく異なり、そもそも提供価値⾃体が異なるため SP版をPC版に付随する１つのサブシステムではなく、１つのプロダクトとして位置付けを再定義した • PdMと⼀緒にSP版としてのプロダクトビジョンや提供価値、プロダクトKGI‧KPIなどを定めた ▼SP版改善の妥当性や、SP版にフォーカスした開発体制の必要性を明確にした • サロンボード全体の⽅針とは整合性を取りつつも、SP版としての⽬指すべき⽅向性と提供価値を定めることで SP版改善の妥当性を明確にし、専任の開発チームを作りやすい状態にした ※必ずしもプラットフォーム軸で価値を定義するのが最適とは限らないが、現時点のサロンボードではSP版として価値を定義することがよいと判断
22. 組織：開発チームとプロダクトバックログの分離 ▼開発チームの分離 • サロンボード全体の開発チームを分離して、SP版にオーナーシップを持つ専任の開発チームを新たに⽴ち上げ • SP版の継続的な改善にフォーカスできるような開発体制を作った ▼プロダクトバックログの分離 • サロンボード全体のプロダクトバックログを分離し、SP版の価値提供に集中したプロダクトバックログを作成 • チームとして、SP版の課題に集中できるようになり、機能改善や保守性の改善に着⼿しやすくなった
23. システム：段階的なシステムのリプレイス ▼段階的なシステムのリプレイス • PC版とSP版は別システムとして稼働していたため、SP版のシステムをリプレイスして保守性を根本的に改善 • 既存システムと並⾏稼働させ、リプレイス完了した画⾯からリリースしてトラフィックを流すようにした ▼継続的な改善サイクル • システムやコードを書き換えるだけでなく、必要に応じて機能追加や改善も同時に実施 • 段階的なシステムリプレイスと、リプレイスした機能のさらなる改善を並⾏で実施
24. 保守性の⾼いシステムに置き換えられ 少ない⼯数で改善ができるようになった SP版にフォーカスして改善し続けられる 開発体制を作ることができた SP版を個別のプロダクトとして 重視できるようになった アプローチの結果どう変化したのか システム 組織 プロダクト
25. 保守性の⾼いシステムに置き換えられ 少ない⼯数で改善ができるようになった SP版にフォーカスして改善し続けられる 開発体制を作ることができた SP版を個別のプロダクトとして 重視できるようになった アプローチの結果どう変化したのか システム 組織 プロダクト SP版サロンボードの 機能改善の土台が揃うことで 素早い改善サイクルが回り出すようになった！
26. さいごに ▼プロダクトの機能改善がうまく進められないとき、その背景に改善の優先度をあげづらい構造がある • プロダクトとして価値をどう定義するかが、組織やシステムの構造にも影響する • 顧客‧市場ニーズや事業の変化によってプロダクトが変わるとき、合わせて組織‧システムも最適化する必要がある ▼エンジニアとしてシステムの課題を解決しようとするとき • 時にはシステムだけを変えようとせずに、その⼟台となる組織やプロダクトの課題にも注⽬する • システムリプレイスが必要になるまで技術的負債が積み重なるとき、プロダクトや組織の構造の問題を疑う システム 組織 プロダクト プロダクトバックログ KPI プロダクト価値 プロダクトビジョン チーム 技術的負債 保守性
27. さいごに ▼プロダクトの機能改善がうまく進められないとき、その背景に改善の優先度をあげづらい構造がある • プロダクトとして価値をどう定義するかが、組織やシステムの構造にも影響する • 顧客‧市場ニーズや事業の変化によってプロダクトが変わるとき、合わせて組織‧システムも最適化する必要がある ▼エンジニアとしてシステムの課題を解決しようとするとき • 時にはシステムだけを変えようとせずに、その⼟台となる組織やプロダクトの課題にも注⽬する • システムリプレイスが必要になるまで技術的負債が積み重なるとき、プロダクトや組織の構造の問題を疑う システム 組織 プロダクト プロダクトバックログ KPI プロダクト価値 プロダクトビジョン チーム 技術的負債 保守性 エンジニアとして システムだけではなく プロダクトや組織にも目を向けよう！