プロダクトディスカバリー入門｜作る前に確かめる進め方

三か月かけて新機能を作りました。リリースしました。

そして、ほとんど使われませんでした。

心当たりはありませんか。

作るものを決める会議では、たいてい声の大きい理由が勝ちます。営業から要望が来ている、競合が出した、経営から言われた。

理由としてはどれも本物です。

ただし、それが本当に作るべきものかどうかは、その時点でまだ誰も確かめていません。

プロダクトディスカバリーは、その確認を作る前に済ませる活動です。この記事では教科書的な定義よりも、明日から回せる順番と、進む・やめるを決める基準を中心に書きます。

ディスカバリーは、正解を当てる活動ではない

プロダクトディスカバリーとは、何を作るかを決める前に、それが本当に必要とされているかを確かめる一連の作業のことです。作って届ける側の活動をデリバリーと呼ぶのに対して、その手前を担当します。

ここでよくある誤解がひとつあります。ディスカバリーは、開発の前に置く長い調査フェーズではありません。

三か月調べてから作り始めるのではなく、今週着手するものを決めるために、先週小さく確かめるくらいの粒度で回すものです。開発と並走します。

もうひとつ、目的の勘違いもよく起きます。ディスカバリーは正解を引き当てる魔法ではありません。

やっているのは、外れを安く見つけることです。三か月かけて外すのを、三日で気づく状態に変える。

それだけです。

当たる確率より、外れたときの損失を見る

新機能の多くは期待どおりに使われません。これは能力の問題ではなく、確率の話です。

だから改善すべきは打率ではなく、一回の空振りにかかるコストのほうです。ここが下がると、挑戦の回数を増やせます。

十打数三安打を目指すより、一打席あたりの時間を三か月から三日にする。ディスカバリーが効くのはこの一点です。

確かめるのは四つ。しかも順番が決まっている

作る前に潰しておきたい不確実性は、大きく四種類あります。それぞれ問いの形が違うので、確かめ方も変わります。

まず全体像を並べます。名前を暗記する必要はないので、問いの形だけ覚えてください。

四つのうち、最初に確かめるべきは価値です。ここが崩れていると、残り三つがどれだけ完璧でも成果はゼロになります。

ところが現場でいちばん飛ばされるのも、この価値の確認です。理由は単純で、使いやすさや実現性のほうが着手しやすいから。

デザインの叩き台を作るのも、技術検証をするのも、手を動かした実感が残ります。需要があるかを問い直す作業には、その手応えがありません。

順番を間違えた例

ある社内向け機能で、フォームの入力体験を二週間かけて磨いたチームがありました。項目を減らし、入力補助を入れ、レビューも通しました。

リリース後、そのフォームを開いた人は月に四人でした。

磨く前に、開く人がいるかを確かめる。順番はそれだけの話です。

実現性と事業性は、早めに一度だけ当てる

価値を優先するといっても、残り三つを最後まで放置していいわけではありません。作ると決めたあとで期間的に無理だと分かるのが、いちばん高くつく失敗です。

現実的なのは、仮説シートができた時点でエンジニアに十五分だけ目を通してもらうやり方です。数日で作れるのか半年かかるのかで、検証にかけてよい手間の量も変わります。

事業性も同じで、価格の見当と運用の当たりだけは先に取っておく。無料でなら使うという声は、事業の判断材料にはなりません。

進め方は、課題から入って解決策で止まらない

ディスカバリーの入り口は、いつも解決策ではなく課題です。ここを逆にすると、議論が好みの戦いになります。

やり方は難しくありません。誰の、どの場面の、どんな不便かを一行にするところから始めます。

対象と場面を一行に絞る

対象がユーザー全般になっている時点で、その仮説はまだ検証できません。場面まで絞ると、聞きに行く相手が具体的に決まります。

書き方の型はこうです。実際の仮説シートとして、そのまま使えます。

対象  : 月末に請求書をまとめて発行する、従業員10〜50名の会社の経理担当
場面  : 毎月25日〜月初の3営業日に、20〜80件の請求書をまとめて作るとき
現状  : 表計算ソフトのテンプレートに手入力し、PDFにして個別にメール送信
不便  : 宛先や金額の転記ミスが月に数件出て、確認と再送に半日かかる
仮説  : 一括作成と一括送信ができれば、この半日がゼロに近づく
まだ不明: 転記ミスが本当に月数件あるのか。半日という体感が実測と合うか

最後の行が肝心です。まだ不明の欄が埋まらない仮説は、思い込みのまま進んでいます。

現状の代用手段を必ず聞く

課題が本物かどうかを見分ける、いちばん簡単な基準があります。今それを何で代用しているかを、相手が即答できるかどうかです。

表計算ソフトで頑張っている、手作業でやっている、諦めている。何かしら答えが返ってくるなら、その不便は実在します。

逆に、言われてみればあったら便利ですね、で止まる話は要注意です。代用手段のない課題は、たいてい課題ではありません。

このあたりの仮説の立て方と検証の型は、仮説検証型のプロダクト開発｜思いつきで作らないための型で詳しく扱っています。

課題は決め打ちせず、並べてから選ぶ

聞き取りを重ねると、課題はたいてい複数出てきます。最初に出会ったものへ飛びつくと、大きさを比べないまま作り始めることになります。

いったん書き出して、それぞれに起きる頻度と、起きたときの痛みの大きさを添えてください。頻度が高くて痛みも大きいものから確かめる、という順番になります。

比べる手間はかかりますが、作り直しの費用に比べれば安く済みます。ここで選び損なうと、あとの検証をどれだけ丁寧にやっても成果は小さいままです。

聞き方ひとつで、答えの価値が変わる

課題インタビューで最もやりがちな失敗は、考えている機能の感想を聞いてしまうことです。こういう機能があったら使いますか、という質問には、ほぼ全員が使うと答えます。

人は仮定の話には親切だからです。その親切さが、そのまま誤った確信になります。

代わりに聞くのは、過去に実際にやったことだけ。未来の意向ではなく、直近の行動を聞くと覚えておけば大きく外しません。

仮定の質問が厄介なのは、外れている案に前へ進む理由を与えてしまう点です。無回答より、根拠のない肯定のほうがずっと高くつきます。

聞きたいのは、先月それをどうやりましたか、という過去形の質問です。実際の手順、かかった時間、途中で詰まった場面が具体的に出てきます。

そこから、そのとき何で代用したか、いくらまでなら払うか、へ順に広げていきます。三十分の枠なら、二十分は過去の話に使ってください。

解決策の説明は最後の十分で足ります。順序を逆にすると、相手はこちらの案に合わせて過去を語り直してしまいます。

需要は、作らずに測れる

価値リスクを確かめるのに、動くものは必ずしも必要ありません。作らずに需要を測る手段がいくつもあります。

代表的なものを、かかる期間と一緒に並べます。どれを選ぶかは、いま何が分からないかで決めてください。

四つめの手作業での代行は見落とされがちですが、効果は大きいです。仕組みを作る前に、担当者が裏で手作業して価値だけ先に届けます。

たとえばレポート自動生成の機能なら、まず数社ぶんを人力で作って送る。続きが欲しいと言われなければ、自動化する価値もありません。

数字で見た、需要テストの判断ライン

LPで需要を測る場合の具体例を出します。事前に判断ラインを決めておくことが何より重要です。

2週間の実測（既存サイトの機能紹介ページ）
  ページ到達        820 人
  説明を最後まで閲覧 246 人  （到達の30.0%）
  興味ありボタン押下   31 人  （閲覧者の12.6%、到達の3.8%）
  事前登録フォーム送信 9 人  （押した人の29.0%）

事前に決めた基準
  進む   : 閲覧者の10%以上がボタンを押す
  保留   : 5〜10%（訴求を作り直して1回だけ再測定）
  やめる :  5%未満

この例なら12.6%なので進む判断になります。ただし、基準を後から決めると、人は必ず自分に都合よく線を引きます。

三日目に数字を見てから基準を決めるのは、検証ではなく後づけです。始める前に紙に書いてください。

既存の訪問者がある程度いるなら、A/Bテストとして出し分けるほうが精度は上がります。時期や流入の違いによる影響を受けにくいからです。

進め方はA/Bテストの始め方｜ノーコードで検証する手順と注意点にまとめています。

計測できる範囲を、正確に把握しておく

需要テストで測るのは、あくまでサイト上の行動です。到達数、閲覧の深さ、ボタンの押下、フォーム送信、そして再訪。

Strideはこの範囲、つまり訪問から回遊、フォーム到達、コンバージョン、再訪までを、Cookieを使わず個人情報も集めずに計測します。流入元は検索・広告・メール・SNS・外部サイト・直接に自動で分類されるので、どの入り口から来た人が反応したのかまで分かります。

ここは正確に書いておきます。ログイン後のプロダクト内で機能がどれだけ使われたかは、ウェブ解析ツールの守備範囲の外です。

そちらはプロダクト内の利用ログを扱う仕組みが別に要ります。ディスカバリー段階で測りたいのはサイト側の反応なので、多くの場合はそこまでで足ります。

数字と声は、往復させて初めて意味を持つ

需要テストの数字は、何人が反応したかを教えてくれます。なぜ反応しなかったのかは教えてくれません。

だから片方だけでは足りません。数字で場所を決め、声で理由を探すという往復が要ります。

順番も決まっています。先に数字を見て、落ちている箇所を特定してから、そこで止まった人の行動や声を見に行く。

逆にすると、たまたま目についた一人の意見に引っ張られます。この往復の設計そのものは定量と定性の往復｜数字とユーザーの声をつなぐ調査設計で扱っています。

声は、聞きに行くだけでなく受け取る仕組みも作る

インタビューは深く聞ける代わりに、相手の時間を押さえる手間がかかります。日々の声は、サイト上の短いアンケートで受け取るほうが続きます。

Strideにもアンケートとネットプロモータースコアの機能があり、表示するページや出すタイミングを指定して尋ねられます。料金ページを一定時間見た人にだけ一問聞く、といった使い方です。

ただし設問を増やすほど回答率は落ちます。一度に聞くのは一問か二問までにしておくのが無難です。

一人の行動を追うと、想像が事実に変わる

数字で場所が決まったら、そこで離脱した人の動きを実際に見ます。訪問者ひとりの行動を時系列で追う方法はN1分析とは｜一人の行動から改善のヒントを得るにまとめました。

Strideなら、料金や機能の説明ページを何度も往復してから帰ったのか、開いて数秒で戻ったのかを、セッションをまたいで確認できます。ページ内の動きまで見たいときは、全テキストを伏せ字にした状態のセッションリプレイもあります。

ただし、こうして得られるのは仮説です。証拠ではありません。

五人中三人が同じ動きをしていたとしても、その比率を全体に当てはめてはいけません。仮説は少人数で作り、確認は全体の数字でやる。

この分担が崩れると、ディスカバリーはただの観察日記になります。

何人聞けば十分か、という問い

ユーザー調査では五人で八割の問題が見つかる、という経験則がよく引かれます。おおむね妥当ですが、条件があります。

同じ立場の人を五人見た場合の話であって、経理担当と営業担当を混ぜた五人ではありません。対象がばらけると、五人では何も収束しないので注意してください。

実務的には、同じ条件で三人聞いて同じ話が二回出たら、いったん手を止めて考える。それくらいの感覚で十分です。

同じ話が出ないなら、対象の絞り方がまだ粗いという合図でもあります。

判断の基準と、やめる条件を先に決める

ディスカバリーがうまく回らない原因の多くは、手法ではなく運用にあります。よく見かける三つを挙げます。

ひとつめは、やめる条件がないこと。始める前に、どうなったら中止するかを一行で書いておいてください。

ふたつめは、答えを知っている人が検証すること。作りたい人が自分の仮説を検証すると、無意識に肯定する材料ばかり集まります。

数字の解釈は、別の人に一度読ませるだけでかなり変わります。

三つめは、時間が確保されていないこと。週に一枠、90分でいいので、カレンダーに固定してしまうのが結局いちばん確実です。

その90分でやることは、毎回同じで構いません。

• 先週の検証で分かったこと（観察と解釈を分けて書く）
• 判断（進む・保留・やめる）と、その根拠になった数字
• 今週いちばん怖い前提をひとつ選ぶ
• その前提を確かめる最小の方法と、判断ラインを決める

三つめが要点です。確かめる価値があるのは、外れたときにいちばん損が大きい前提であって、確かめやすい前提ではありません。

合意は、結論ではなく観察で取る

社内の合意形成でつまずくときは、たいてい結論だけを共有しています。この機能は不要だと分かりました、では反発しか生まれません。

代わりに、観察をそのまま見せてください。八社に聞いたうち六社が別の手段で解決済みだった、という事実は反論しにくい。

説得ではなく、同じものを見てもらう。この順番のほうが、結果的に早く決まります。

判断が割れたままなら、無理にその場で決めないほうがいい。何を確かめれば決められるかを合意して、次の枠まで持ち越すほうが健全です。

ディスカバリーが機能しない場面もある

万能ではありません。次のような場面では、確かめる前に作る判断が正しいこともあります。

• 法令や規約への対応など、やらない選択肢がそもそも無いもの
• 既存顧客と契約で約束済みの機能
• 作るより調べるほうが高くつく、ごく小さな改修
• 前例がなく、聞いても誰も答えられない新しい体験

四つめは判断が難しいところです。存在しないものへの感想は当てにならないので、聞くより粗くても触らせるほうが早い。

限界を知っておくと、確かめること自体が目的化するのを防げます。検証に二か月かけて、作れば二週間だったという話は珍しくありません。

まとめ

プロダクトディスカバリーは、作る前に外れを安く見つける活動です。価値、使いやすさ、実現性、事業性の順に確かめ、価値のリスクを最初に潰します。

進め方はいつも同じです。誰のどの場面かを一行に絞り、代用手段を聞き、需要を作らずに測り、判断ラインを先に決める。

そして数字で場所を決め、一人の行動や声で理由を探す。仮説は少人数で作り、確認は全体の数字でやる。

大がかりな体制はいりません。今いちばん怖い前提をひとつ書き出して、それを今週中に確かめる方法を考える。

まずはそこからで十分です。