フレームワーク活用ガイドひとことで言うと#
「作る前に、作るべきものを見つける」ための探索活動。ユーザーインタビュー、プロトタイプ、実験を組み合わせて、価値・ユーザビリティ・実現可能性・事業性の4つのリスクを事前に潰す。デリバリー（開発）の前工程として位置づけられる。
押さえておきたい用語#
- ディスカバリー（Discovery）
- 何を作るべきかを探索する開発前の検証フェーズのこと。デリバリー（実装・リリース）と対になる概念。
- 4つのリスク（Four Risks）
- 価値・ユーザビリティ・実現可能性・事業性という新機能が失敗する4つの原因カテゴリを指す。
- プロダクトトリオ（Product Trio）
- PM・デザイナー・エンジニアの3職種が一体でディスカバリーに取り組む最小チームを指す。
- スモークテスト（Smoke Test）
- 実際にプロダクトを作る前にユーザーの関心度や行動を軽量に検証するテスト手法のこと。LPやモックを使う。
プロダクトディスカバリーの全体像#
こんな悩みに効く#
- 開発に時間とお金をかけたのに、リリース後にユーザーに使われない
- 要件定義がステークホルダーの「声の大きさ」で決まってしまう
- プロダクトバックログが「頼まれたもの」で埋まっている
基本の使い方#
ユーザーインタビュー、データ分析、カスタマーサポートの声などからユーザーが本当に困っていることを洗い出す。
- ユーザーの行動ログで離脱ポイントを分析する
- 週次のインタビューで「何に困っていますか？」ではなく「先週どうやって○○しましたか？」と聞く
- Opportunity Solution Treeで機会を構造化する
ポイント: 「機能のリクエスト」ではなく「根底にある課題」を見つけることが目的。
課題が明確になったら、複数の解決策を出す。1つに絞らないのがコツ。
- 最低3つ以上のアイデアを出す
- チーム全員（PM・デザイナー・エンジニア）で発散する
- 既存事例や他業界のアプローチも参考にする
エンジニアの視点が重要: 技術的に簡単で効果が大きい解決策はエンジニアにしか見えないことが多い。
解決策候補それぞれについて、以下のリスクを検証する。
- 価値リスク: ユーザーは本当にこれを欲しいか？（インタビュー、スモークテスト）
- ユーザビリティリスク: ユーザーは使い方がわかるか？（プロトタイプテスト）
- 実現可能性リスク: 技術的に作れるか？（テクニカルスパイク）
- 事業性リスク: ビジネスとして成り立つか？（収益シミュレーション）
全部を検証する必要はない。最もリスクが高いものから順に潰す。
検証の結果をチームで共有し、次のアクションを決める。
- Go: リスクが十分に低い → デリバリーに進む
- Pivot: 方向性を変えて別の解決策を試す
- Kill: この課題は今やるべきではないと判断する
「Kill」を選べることがディスカバリーの価値。開発に入ってから中止するよりはるかにコストが低い。
具体例#
課題の特定: データ分析でトライアルユーザーの行動を調べたところ、「レポート機能」を使ったユーザーの有料転換率が3倍高いことが判明。しかし、トライアル期間中にレポート機能を使うユーザーはわずか12%。
解決策の発散:
- オンボーディングでレポート作成を必須ステップにする
- サンプルレポートを自動生成して「こんなことができます」と見せる
- レポート機能をトップナビに移動してアクセスしやすくする
リスク検証:
- 案1: プロトタイプでユーザビリティテスト → 「強制されると離脱する」と判明（Kill）
- 案2: スモークテスト → サンプルレポートを見たユーザーの68%が自分のレポートも作成（Go）
- 案3: A/Bテスト → ナビ変更だけでは利用率が2%しか上がらず（Kill）
結果: 案2をデリバリーに進め、有料転換率が8% → 14.4%（1.8倍）に改善。ディスカバリーに2週間かけたが、3案すべてを開発していたら3ヶ月かかっていた。2週間の検証で2.5ヶ月分の無駄を回避。
物流スタートアップ（ドライバー800名利用）が、配送ルート最適化機能の開発を検討した事例。
課題の特定:
- ドライバーの1日の配送効率にばらつきが大きい（上位20%と下位20%で配送件数に2.3倍の差）
- インタビュー: 「ルートは経験で決めている。毎朝30分かけて地図を見ながら考える」
- 課題の本質: 効率的なルートを組める人と組めない人の差が大きい
解決策の発散:
- AIによる自動ルート最適化（開発工数: 6ヶ月）
- ベテランドライバーのルートパターンをテンプレート化（開発工数: 2ヶ月）
- 前日の配送実績を元に翌日のルートを自動提案（開発工数: 3ヶ月）
4つのリスク検証:
- 価値リスク: ドライバー50名にプロトタイプを見せ、「使いたい」と回答したのは案2が82%、案1は48%（AIへの不信感）
- ユーザビリティ: 紙のプロトタイプで確認。案2はベテランのルートを「見る」だけなので直感的
- 実現可能性: 案1は地図API費用が月額200万円。案2はスプレッドシートのデータ化で実現可能
- 事業性: 案2で配送効率が15%改善すれば年間3,600万円のコスト削減
判断: 案2をGo、案1は将来の検討課題としてKeep。
結果（3ヶ月後）:
- 下位20%のドライバーの配送件数が1.6倍に
- 全体の配送効率が12%改善（年間2,880万円のコスト削減）
- ドライバー満足度: 「朝のルート検討時間が30分→5分になった」
最も高コストな案が最善とは限らない。ディスカバリーで4つのリスクを潰したことで、2ヶ月の開発で6ヶ月分以上の成果を出せた。
人口8万人の地方自治体が、住民向け情報アプリ（ダウンロード数2.3万）に新機能を追加する際にディスカバリーを実施した事例。
課題の特定:
- アプリのMAU: 3,800人（ダウンロード数の16.5%）
- 利用者アンケート: 「情報は見るが、手続きは結局役所に来る」が68%
- 役所の窓口: 「アプリで完結する手続きがあるのに知らない住民が多い」
解決策の発散:
- 全手続きのオンライン化を推進（開発予算: 5,000万円、期間: 2年）
- よく使われる3手続きに絞ってオンライン化＋プッシュ通知（予算: 800万円、期間: 4ヶ月）
- 窓口混雑状況のリアルタイム表示＋来所予約機能（予算: 300万円、期間: 2ヶ月）
リスク検証:
- 価値リスク: 住民200名にアンケート → 「すぐ使いたい」の回答率は案3が72%で最高（案1は38%、案2は55%）
- ユーザビリティ: 高齢者（65歳以上）にプロトタイプを見せたところ、案3は操作に迷いなし。案2は「マイナンバーカードの連携がわからない」
- 実現可能性: 案3は既存の番号札システムのAPIで実現可能
- 事業性: 案3で窓口の待ち時間が30%削減できれば、住民満足度向上＋職員の負担軽減
判断: 案3をGo。案2は案3の効果検証後に再検討。
結果（3ヶ月後）:
- アプリMAU: 3,800 → 8,200人（2.2倍）
- 来所予約利用率: 窓口利用者の35%が予約利用
- 窓口の平均待ち時間: 42分 → 18分
- 住民アンケート「便利になった」: 78%
「全部やる」より「最も求められている1つ」を見つけて素早く届けるほうが、住民の満足度もアプリの利用率も劇的に向上した。
やりがちな失敗パターン#
- ディスカバリーとデリバリーを完全に分離する — ウォーターフォールに逆戻りする。デリバリーと並行して常にディスカバリーを回し続けるのが正しい姿
- PMだけでディスカバリーをやる — プロダクトトリオ（PM・デザイナー・エンジニア）で取り組まないと、実現可能性リスクの見落としや、創造的な解決策の不足が起きる
- 検証せずに「わかった気」になる — 3人にインタビューしただけで「ユーザーはこれを求めている」と結論づけるのは危険。定量データと定性データの両方で裏付ける
- Killの判断を避ける — 検証結果が悪くても「もう少し工夫すれば」と開発に進んでしまう。Killできることがディスカバリー最大の価値であり、無駄な開発コストを回避する
まとめ#
プロダクトディスカバリーは「正しいものを作る」ための探索プロセス。作ってから失敗するのではなく、作る前にリスクを潰す。週に数時間でもディスカバリーの時間を確保するだけで、チームのアウトプットの質が劇的に変わる。「忙しくて検証する時間がない」と感じたときこそ、ディスカバリーが最も必要なサインだ。