プロダクトディスカバリーは、作るものを決める側の工程を指します。何を作るかを見極めることをディスカバリー、それを実際に作ることをデリバリーと呼んで分けたのが、元の使われ方です。
骨格の説明は、どこで読んでもだいたい揃っています。分かりにくいのは終わり方です。どこまで調べて、何が出てきたら「決まった」と言えるのか。ここは記事によって説明が食い違っていて、そもそも終わりを前提にしていない立場もあります。
語の出どころ、説明が割れている理由、そして期間を区切って外部に頼むときに受け取れるもの。2026年8月時点の整理です。
語の出どころは新薬開発
この意味で discovery を使い始めたのは Marty Cagan（Silicon Valley Product Group）です。2005年頃から試験的に使い、2007年に『INSPIRED』の初版を書く段階で、それまでの「要件の収集と定義」に代わる語として本格的に採用したと本人が書いています。医薬品の新薬開発からの類推で選んだ語です。
置き換えの狙いは、この対比に出ています。要件という語は、決めるべきことが誰かの頭の中に既にあって、それを聞き取って書き起こす作業を指します。ディスカバリーは、何を作るべきかがまだ分かっていないところから始める前提に立ちます。
Cagan の定義では、ディスカバリーが「何を作るか見極めること」、デリバリーが「それを作ること」です。
説明が割れているのは「いつ終わるか」
作る前に検証する、という骨格は共通しています。割れているのは、それが終わる活動なのかどうかです。
Cagan は一区切りの工程として説明しています。「必要な解決策が分かったという証拠がある程度集まったら、エンジニアに本番品質のソフトウェアを作らせる」。証拠が集まった時点でディスカバリーは終わり、デリバリーに移る。2015年に公開された記事です。
もう一方が Teresa Torres の継続的ディスカバリーです。2016年の記事で、開発前に完了する一区切りの工程ではなく、チームが継続的に多くのアイデアを探索し続けるものとして再定義しました。「プロダクトを作るチーム自身が、望む成果を追って毎週顧客と小さな調査活動を行うこと」という定義です。ここには終わりがありません。
日本語の解説記事は、Nue が2026年8月に確認した範囲では継続的プロセス側の説明に寄っていました。ただし、どこまで検証すれば十分かへの具体的な答えは見当たりません。判断軸まで踏み込んでいたのは翔泳社の記事（初出2022年）で、「事業計画や開発リソース観点で失敗を許容できるか」を挙げたうえで、明確な終了ラインはケースバイケースとしています。
2つの立場は、想定している状況が違うだけだと Nue は見ています。自社のプロダクトを持ち続けるチームなら、来週も顧客に会う。終わりを定義する必要がありません。一方、新規事業の立ち上げのように「作るか、作らないか」をある時点で決めなければならない側にとっては、終わりの定義がないこと自体が問題になります。決まらない状態が続くだけでコストがかかるからです。
この食い違いは、言葉の使い方の問題で終わりません。提案を受ける側から見ると、「継続的に回します」という言い方は、いつ請求が止まるのかが読めない説明にもなります。逆に「4週間で終わります」という説明も、何をもって終わりとするのかが書かれていなければ、期間だけの約束です。
期間を区切ると、決まるものが3つに絞られる
Nue は プロダクト開発支援 を4週間固定の商品として設計しています。調査、インタビュー、課題整理、コンセプト、プロトタイプ、ユーザーテストの6工程を順に通します。期間を固定し、範囲の方を調整して終わらせます。
期間を先に固定すると、最初に決めることが1つ増えます。4週間で答えを出す問いを1つに絞ることです。問いが複数あると、どれも中途半端に終わります。聞く相手も、作るプロトタイプの粒度も、この問いから逆算して決まります。
問いが決まったあと、4週間で確定させにいくのは次の3つです。
誰の、どの課題を解くか
調査とインタビューで集まるのは事実の羅列です。それを解くべき課題の形に組み直すのが課題整理の工程で、6工程の中で人の判断が最も効くところです。ここが弱いまま先に進むと、あとの工程がどれだけきれいに流れても的を外します。
つまずくのは、事実が足りないからというより、事実を課題文に変える手前で止まっているときです。「使いにくいという声が多い」は事実の要約であって、解くべき課題ではありません。誰が、どの場面で、何ができずに、代わりに何をしているか。ここまで言葉にできて、ようやく解き方の案を並べられます。聞き方から課題文に落とすまでの手順はユーザーインタビューの記事に書きました。
やらないことの線引き
コンセプトの工程では複数の案から1つを選びますが、選ばなかった案も記録に残します。半年後に同じ議論を繰り返さないためです。
成果物に「やらないと決めたこと」とその理由を入れているのも、同じ狙いです。決まったことだけを渡すと、次の意思決定の場が「あの案はどうなったのか」から始まります。
次に進んでよい条件
プロトタイプを触ってもらう工程で取りにいくのは、満足度の感想ではなく、どこで詰まったかです。詰まった箇所が、そのまま次に直す場所になります。
この決め方は、検証に入る前に何を決めておくかという話と地続きです。合格ラインと、外れたときの手順を先に文章にしておかないと、結果が出ても判断が動かない。PoCが進まない理由で書いたのと同じ構造です。
どうなったら終わりなのか
発注する側から見た終了条件は、受け取るものの形で言い切れます。4週間の終わりに残るのは、課題の整理、コンセプト、プロトタイプ、ユーザーテストの結果、そして「やらないと決めたこと」とその理由です。
成果物の一覧に落とすと、埋まっているかどうかで終わりを判断できます。課題が1行で言えるか。選ばなかった案の理由が書いてあるか。ユーザーテストで詰まった箇所が特定できているか。ここが埋まっていないなら、期間が終わっていても問いには答えが出ていません。
もう1つ、「作らない」と決まることも成果に数えます。決まらないまま半年を使うより安い、という位置づけで設計しています。作ると決まった場合は、プロトタイプとユーザーテストの結果が既にあるので、要件を一から起こさずに次へ進めます。
期間を固定する側の代償は、範囲を削ることです。4週間で答えを出す問いを1つに絞る、というのはその代償の払い方です。問いが2つあると、どちらも中途半端な材料しか揃いません。絞る作業は最初の打ち合わせでやることになります。
終了条件を先に置くと、検証の深さは自動的に決まります。証拠が完全に揃うまで続けるのではなく、その問いに答えが出た時点で止める。Cagan の言う「証拠がある程度集まったら」 を、期間の側から縛った形です。
4週間で回るのは、工程を削ったからではない
短くなった理由は工程を減らしたことではなく、工程間の待ち時間を削ったことです。従来のリサーチは、調べる人、まとめる人、作る人が分かれていて、受け渡しのたびに数日の待ちが出ていました。リサーチの整理とプロトタイプ生成がAIで速くなったぶん、少人数が通しで担当できます。
AIで圧縮しているのはリサーチの整理、発言録の分析、プロトタイプの生成までです。誰に何を聞くかの設計と、出てきた結果の解釈は人がやります。ここを機械に任せると、それらしいが的外れな結論が出ます。設計と解釈にかかる時間は変わりません。速くなったのは、案を試す回数を増やせるところです。
向いていない場合
期間を区切って外に頼む意味が出るかどうかは、いま止まっている判断があるかで変わります。状態によって入口が別になります。
- 作るものが既に決まっている AI受託開発に直接進む
- リリース済みで、伸ばし方を探している ディスカバリーとは別の工程になる
- 社内のチームが毎週顧客に会う体制を回せている 継続的ディスカバリーが動いている。外に頼む必要は薄い
- 判断を止めている問いが具体的にあり、自力では動かない 期間を区切る意味が出る
受託開発で何を、どこまで作るかはプロトタイプとMVPの違いで扱っています。