Slide 1

Slide 1 text

エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 2025/02/21 @Product Engineer Night #7 rince (@kazumax1218)

Slide 2

Slide 2 text

rince(@kazumax1218) ○ 2011- カカクコム(食べログ→キナリノ) ○ 2018- メルカリ(ソウゾウ→メルペイ) ○ 2020- マイベスト ○ 旅とキャンプとサウナが好き⛺ ○ 最近は育児に奮闘中👶 ○ 先月からCTOになりました🔥 自己紹介

Slide 3

Slide 3 text

月間利用者数 3,000 ユーザーの“選択”を サポートする 商品比較サービス 万人以上

Slide 4

Slide 4 text

商品を自社で購入し、専門性を持ったメンバーが徹底検証 倉庫やラボ、撮影スタジオなどの環境を完備したオフィスで、各領域の専門性を持ったメンバーが商品を比較検証

Slide 5

Slide 5 text

● 話すこと ○ プロダクトディスカバリーにエンジニアがいるといいよ!という話 ● 話さないこと ○ 作らずに価値検証すること(重要だけど今回は別の話) 今日の話

Slide 6

Slide 6 text

プロダクトディスカバリーとは 1 エンジニアが加速させる プロダクトディスカバリー 2 実例 3 まとめ 4 目次

Slide 7

Slide 7 text

プロダクトディスカバリーとは 1

Slide 8

Slide 8 text

何を作るかを見極める 迅速な学習が重要 主にPdM・デザイナー中心 プロダクトディスカバリーとプロダクトデリバリー ディスカバリー デリバリー 決めたものを作り、ユーザーに届ける 安定性・スケーラビリティが必要 主にエンジニア中心 プロダクトディスカバリーとは、問題と解決策を探索し、何を作るかを見極めるフェーズ

Slide 9

Slide 9 text

なぜプロダクトディスカバリーが必要なのか プロダクト開発が失敗する根本原因はユーザーが求めていないものを時間をかけて作ってしまうこと 開発(ビルド)はアジャイルだが、全体としてはウォーターフォールになっている → リスクが最後に来る アイデアの少なくとも 半分はうまくいかない

Slide 10

Slide 10 text

● 価値のリスク ○ 顧客はこれを買ったり、これを使うことを選んでくれるだろうか? ● ユーザビリティのリスク ○ ユーザーはこれの使い方がわかるだろうか? ● 実現可能性のリスク ○ 私たちはこれを作れるだろうか? ● 事業実現性のリスク ○ このソリューションは私たちのビジネスに貢献するだろうか? 次の重要なリスクに対処し、できる限り迅速にアイデアの妥当性を立証すること プロダクトディスカバリーの目的

Slide 11

Slide 11 text

エンジニアが加速させる プロダクトディスカバリー 2

Slide 12

Slide 12 text

正しい問題を見つける ユーザーインタビュー、データ分析、 カスタマージャーニーマップ、etc. プロダクトディスカバリーの2つのフェーズ 正しい解決策を見つける ブレインストーミング、コンセプトテスト、 プロトタイピング、A/Bテスト、etc. ディスカバリーには問題の探索と解決策の探索の2つのフェーズがある(ダブルダイヤモンド) プロダクトディスカバリー

Slide 13

Slide 13 text

● 解決策の探索においては作らずに済むにこしたことはない ○ コンシェルジュ、オズの魔法使い、コンセプトテスト、Figma、etc. ● が、以下のケースでは作ることも選択肢に入る ○ 作った方が速いケース(ex. デザインシステムやAIの活用) ○ 作った方が精度の高い仮説検証ができるケース(ex. 一定のトラフィック) ● その場合、エンジニアがディスカバリーにいると、 ○ 素早くプロトタイプを作り、ユーザーに実際に触ってもらえる ○ A/Bテスト等を行い、定量的な数値を元に判断することができる ● 作るか作らないかにとらわれず、どうすれば最速で学習したいことが学べるか 特に「解決策の探索」では、迅速な学習が最重要 解決策の探索で「作る」という選択肢

Slide 14

Slide 14 text

ディスカバリーフェーズからエンジニアも参加する 一般的にはPdMとデザイナーやリサーチャーが中心となってディスカバリーを行うことが多いが、 ここに少なくとも1人エンジニアが参加する プロダクト マネージャー デザイナー/ リサーチャー エンジニア プロダクト ディスカバリー テックリード/ プロダクトエンジニア

Slide 15

Slide 15 text

● 課題を深く理解して解決策を考えられる ● 実現可能性を早期に見極められる ● 作るかどうかの判断の精度が上がる ● 仮説検証のための最適な落とし所がわかる ● 分析結果から即座に次の仮説検証を回せる プロダクトディスカバリーにおける価値探索のスピードを上げることができる ディスカバリーにエンジニアがいることのメリット

Slide 16

Slide 16 text

ディスカバリーの各フェーズにエンジニアが関わることで、最速で価値ある機能に辿り着ける プロトタイプ開発のプロセス

Slide 17

Slide 17 text

実例 3

Slide 18

Slide 18 text

Web接客機能 オフラインでの接客体験(ex. 家電量販店)をオンラインで実現する 質問にポチポチ 答えていくと、 自分に最適な 商品がわかる

Slide 19

Slide 19 text

どのように進めたか 今回は「問題の探索」は既にユーザーインタビューで済んでいるところからスタート 1. 解決策を考える ○ 社内の元販売員(接客経験者)にヒアリング ○ 実現可能性の観点も含める 2. 検証方法と仕様を決める ○ ワイヤレスイヤホンと格安SIMにカテゴリを絞って検証 3. 設計・実装する ○ テーブルを作らず、回答と絞り込みのマッピングを定数で ○ APIも作らず、Frontendのみで簡易的に実装 4. テスト・分析する ○ A/Bテストを実施、分析して次の仮説検証へ 実工数:1〜2人日

Slide 20

Slide 20 text

テスト・分析・改善のループを回す リスクの高い部分から検証を進めて、学習して徐々に精度を高めていく 1. まずは使われるかを検証 ○ 約22%のユーザーに使われた! 2. 次にUIを改善して選びきれるかを検証 ○ 5%ほどCVRが上がった! 3. 細かく数値を分析してブラッシュアップ ○ おすすめ商品の出し方 ○ ハーフモーダルの掲出タイミング ○ 条件変更を可能に ○ 質問内容と回答内容の改善

Slide 21

Slide 21 text

● リスクの高い部分から検証する ○ 一気にすべてを検証しない、最初から作り込み過ぎない ● ユースケースを絞る ○ 考えること・作るものをなるべく減らす ● 保守性やスケーラビリティを犠牲にしてスピードを取る ○ コードを使い捨てることを恐れない、捨てやすくしておく、掃除を忘れない ● AIを活用する ○ GitHub Copilot、Cursor、v0などを使い開発速度を上げる ● 時には手作業を厭わない ○ 汎用的にしない、早すぎる最適化をしない スピードを上げるために どうすれば学習スピードを最大化できるか考え、学習のための最小の労力で作る(時に作らない)

Slide 22

Slide 22 text

まとめ 4

Slide 23

Slide 23 text

● プロダクトディスカバリーは問題と解決策を探索し、何を作るかを見極める フェーズ ● プロダクトディスカバリーフェーズからエンジニアが入ることによって価値 探索のスピードを加速させることができる ● どうすれば学習スピードを最大化できるかを考えるのが大事 ● ユーザーの課題を解決し、価値を届けるプロダクトを作っていきましょう! まとめ