エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers

2025/02/21 ＠Product Engineer Night #7

プロダクトディスカバリーのフェーズからエンジニアが入ることによって、価値探索のスピードを加速させることができるという発表をさせていただきました。

Transcript

1. エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 2025/02/21 ＠Product Engineer Night #7 rince (@kazumax1218)
2. rince（@kazumax1218） ◦ 2011- カカクコム（食べログ→キナリノ） ◦ 2018- メルカリ（ソウゾウ→メルペイ） ◦ 2020- マイベスト ◦ 旅とキャンプとサウナが好き⛺ ◦ 最近は育児に奮闘中👶 ◦ 先月からCTOになりました🔥 自己紹介
3. 月間利用者数 3,000 ユーザーの“選択”を サポートする 商品比較サービス 万人以上
4. 商品を自社で購入し、専門性を持ったメンバーが徹底検証 倉庫やラボ、撮影スタジオなどの環境を完備したオフィスで、各領域の専門性を持ったメンバーが商品を比較検証
5. • 話すこと ◦ プロダクトディスカバリーにエンジニアがいるといいよ！という話 • 話さないこと ◦ 作らずに価値検証すること（重要だけど今回は別の話） 今日の話
6. プロダクトディスカバリーとは 1 エンジニアが加速させる プロダクトディスカバリー 2 実例 3 まとめ 4 目次
7. プロダクトディスカバリーとは 1
8. 何を作るかを見極める 迅速な学習が重要 主にPdM・デザイナー中心 プロダクトディスカバリーとプロダクトデリバリー ディスカバリー デリバリー 決めたものを作り、ユーザーに届ける 安定性・スケーラビリティが必要 主にエンジニア中心 プロダクトディスカバリーとは、問題と解決策を探索し、何を作るかを見極めるフェーズ
9. なぜプロダクトディスカバリーが必要なのか プロダクト開発が失敗する根本原因はユーザーが求めていないものを時間をかけて作ってしまうこと 開発（ビルド）はアジャイルだが、全体としてはウォーターフォールになっている → リスクが最後に来る アイデアの少なくとも 半分はうまくいかない
10. • 価値のリスク ◦ 顧客はこれを買ったり、これを使うことを選んでくれるだろうか？ • ユーザビリティのリスク ◦ ユーザーはこれの使い方がわかるだろうか？ • 実現可能性のリスク ◦ 私たちはこれを作れるだろうか？ • 事業実現性のリスク ◦ このソリューションは私たちのビジネスに貢献するだろうか？ 次の重要なリスクに対処し、できる限り迅速にアイデアの妥当性を立証すること プロダクトディスカバリーの目的
11. エンジニアが加速させる プロダクトディスカバリー 2
12. 正しい問題を見つける ユーザーインタビュー、データ分析、 カスタマージャーニーマップ、etc. プロダクトディスカバリーの2つのフェーズ 正しい解決策を見つける ブレインストーミング、コンセプトテスト、 プロトタイピング、A/Bテスト、etc. ディスカバリーには問題の探索と解決策の探索の2つのフェーズがある（ダブルダイヤモンド） プロダクトディスカバリー
13. • 解決策の探索においては作らずに済むにこしたことはない ◦ コンシェルジュ、オズの魔法使い、コンセプトテスト、Figma、etc. • が、以下のケースでは作ることも選択肢に入る ◦ 作った方が速いケース（ex. デザインシステムやAIの活用） ◦ 作った方が精度の高い仮説検証ができるケース（ex. 一定のトラフィック） • その場合、エンジニアがディスカバリーにいると、 ◦ 素早くプロトタイプを作り、ユーザーに実際に触ってもらえる ◦ A/Bテスト等を行い、定量的な数値を元に判断することができる • 作るか作らないかにとらわれず、どうすれば最速で学習したいことが学べるか 特に「解決策の探索」では、迅速な学習が最重要 解決策の探索で「作る」という選択肢
14. ディスカバリーフェーズからエンジニアも参加する 一般的にはPdMとデザイナーが中心となってプロダクトディスカバリーを行うことが多いが、 ここに少なくとも1人エンジニアが参加する プロダクト マネージャー デザイナー エンジニア プロダクト ディスカバリー
15. • 課題を深く理解して解決策を考えられる • 実現可能性を早期に見極められる • 作るかどうかの判断が的確にできる • 仮説検証のための最適な落とし所がわかる • 分析結果から即座に次の仮説検証を回せる プロダクトディスカバリーにおける価値検証のスピードを上げることができる ディスカバリーにエンジニアがいることのメリット
16. ディスカバリーの各フェーズにエンジニアが関わることで、最速で価値ある機能に辿り着ける プロトタイプ開発のプロセス
17. 実例 3
18. Web接客機能 オフラインでの接客体験（ex. 家電量販店）をオンラインで実現する 質問にポチポチ 答えていくと、 自分に最適な 商品がわかる
19. どのように進めたか 今回は「問題の探索」は既にユーザーインタビューで済んでいるところからスタート 1. 解決策を考える ◦ 社内の元販売員（接客経験者）にヒアリング ◦ 実現可能性の観点も含める 2. 検証方法と仕様を決める ◦ ワイヤレスイヤホンと格安SIMにカテゴリを絞って検証 3. 設計・実装する ◦ テーブルを作らず、回答と絞り込みのマッピングを定数で ◦ APIも作らず、Frontendのみで簡易的に実装 4. テスト・分析する ◦ A/Bテストを実施、分析して次の仮説検証へ 実工数：1〜2人日
20. テスト・分析・改善のループを回す リスクの高い部分から検証を進めて、学習して徐々に精度を高めていく 1. まずは使われるかを検証 ◦ 約22%のユーザーに使われた！ 2. 次にUIを改善して選びきれるかを検証 ◦ 5%ほどCVRが上がった！ 3. 細かく数値を分析してブラッシュアップ ◦ おすすめ商品の出し方 ◦ ハーフモーダルの掲出タイミング ◦ 条件変更を可能に ◦ 質問内容と回答内容の改善
21. • リスクの高い部分から検証する ◦ 一気にすべてを検証しない、最初から作り込み過ぎない • ユースケースを絞る ◦ 考えること・作るものをなるべく減らす • 保守性やスケーラビリティを犠牲にしてスピードを取る ◦ コードを使い捨てることを恐れない、捨てやすくしておく、掃除を忘れない • AIを活用する ◦ GitHub Copilot、Cursor、v0などを使い開発速度を上げる • 時には手作業を厭わない ◦ 汎用的にしない、早すぎる最適化をしない スピードを上げるために どうすれば学習スピードを最大化できるか考え、学習のための最小の労力で作る（時に作らない）
22. まとめ 4
23. • プロダクトディスカバリーは問題と解決策を探索し、何を作るかを見極める フェーズ • プロダクトディスカバリーフェーズからエンジニアが入ることによって価値 探索のスピードを加速させることができる • どうすれば学習スピードを最大化できるかを考えるのが大事 • ユーザーの課題を解決し、価値を届けるプロダクトを作っていきましょう！ まとめ