プロダクトディスカバリーは、作るものを決める側の工程を指します。何を作るかを見極めることをディスカバリー、それを実際に作ることをデリバリーと呼んで分けたのが、元の使われ方です。
骨格の説明は、何を作るかを確かめる活動という点で揃っています。分かりにくいのは、個々の案をいつ実装へ進めるかという判断と、調査活動そのものをいつ終えるかという判断の違いです。
実装へ進む判断と、期間を区切って外部に頼むときに受け取れるものを整理します。
実装へ進む判断と、調査を続ける判断
1つの案に実装の判断を下しても、次の案を探す活動まで終わるわけではありません。原典が扱う時間の単位を分けて読む必要があります。
Cagan は2015年の記事で、顧客に使える解決策だという証拠が集まった案は本番品質の実装へ進めると説明しています。同じ記事で、学習を速める活動と安定した提供を同時に進めるとも書いています。これは案ごとの投資判断であり、チームのディスカバリー全体が終わるという意味ではありません。
Teresa Torres は2016年の記事でCaganらの並行した開発の考え方に触れ、複数の案を継続して探索するチームの活動を説明しています。顧客と繰り返し話し、案を試すことが次の判断を支えます。
ここで残る問いは、チーム全体の探索をいつ止めるかではありません。今回検討する案にどこまで証拠が必要か、期間を区切った依頼で何を受け取って判断するかです。
自社のプロダクトを育てるチームは、ある案を実装へ進めても、次の判断に向けた顧客との接点を続けられます。一方、期間を区切って外部へ依頼するなら、契約した調査の範囲と納品物を決める必要があります。継続的な活動の考え方と、個別の依頼の終了条件は両立します。
提案を受ける側にとっては、「継続的に回します」だけでは今回の依頼がいつ終わるか分かりません。「4週間で終わります」も、何を受け取って次の判断をするかが書かれていなければ、期間だけの約束です。
4週間で残す判断材料は3つ
Nue の プロダクト開発支援には、何を作るか決まっていない場合の4週間の入口があります。調査、インタビュー、課題整理、コンセプト、プロトタイプ、ユーザーテストの6工程を通し、期間を固定して扱う範囲を調整する設計です。
期間を先に固定すると、最初に決めることが1つ増えます。4週間で答えを出す問いを1つに絞ることです。問いが複数あると、どれも中途半端に終わります。聞く相手も、作るプロトタイプの粒度も、この問いから逆算して決まります。
問いが決まったあと、次の判断に使うため整理するのは次の3つです。
誰の、どの課題を解くか
調査とインタビューで集まるのは事実の羅列です。それを解くべき課題の形に組み直すのが課題整理の工程で、6工程の中で人の判断が最も効くところです。ここが弱いまま先に進むと、あとの工程がどれだけきれいに流れても的を外します。
つまずくのは、事実が足りないからというより、事実を課題文に変える手前で止まっているときです。「使いにくいという声が多い」は事実の要約であって、解くべき課題ではありません。誰が、どの場面で、何ができずに、代わりに何をしているか。ここまで言葉にできて、ようやく解き方の案を並べられます。聞き方から課題文に落とすまでの手順はユーザーインタビューの記事に書きました。
やらないことの線引き
コンセプトの工程では複数の案から1つを選び、選ばなかった案も記録に残す設計です。あとから同じ案を検討するときに判断の理由を見返せます。
次に進んでよい条件
プロトタイプを触ってもらう工程で取りにいくのは、満足度の感想ではなく、どこで詰まったかです。詰まった箇所が、そのまま次に直す場所になります。
この決め方は、検証に入る前に何を決めておくかという話と地続きです。合格ラインと、外れたときの手順を先に文章にしておかないと、結果が出ても判断が動かない。PoCが進まない理由で書いたのと同じ構造です。
どうなったら終わりなのか
発注する側から見た終了条件は、受け取るものの形で言い切れます。4週間の終わりに残るのは、課題の整理、コンセプト、プロトタイプ、ユーザーテストの結果、そして「やらないと決めたこと」とその理由です。
依頼の完了と、実装へ進む判断は分けて取り決めると明確です。公開されているサービスの成果物は、課題の整理、コンセプト、プロトタイプ、テスト結果と、採用しなかった案の理由です。証拠が足りない場合に未解決点、保留理由、次の検証をどう残すかは、依頼前に確認する項目です。実装を決められない場合の納品条件も、契約時に合意しておく必要があります。
もう1つ、「作らない」と決まることも成果に数えます。決まらないまま半年を使うより安い、という位置づけで設計しています。作ると決まった場合は、プロトタイプとユーザーテストの結果が既にあるので、要件を一から起こさずに次へ進めます。
期間を固定する側の代償は、扱う範囲を狭めることです。最初の打ち合わせで決めた問いの外に新たな課題が見つかったら、今回の範囲に含めるか、次の検討へ送るかを依頼者と確認するのが安全です。
今回の依頼で答える問いと、納品時に残す判断材料を先に決めると、実装へ進むか、別の案を試すかを検討しやすくなります。証拠が足りない場合に判断を保留する扱いも依頼前に確認します。その後もプロダクト全体のディスカバリーが不要になるわけではありません。
4週間の工程をどう進めるか
サービス設計では、リサーチの整理とプロトタイプの作成にAIを使い、工程間の受け渡しを減らします。これは4週間という期間に収めるための進め方で、案件ごとの所要時間や短縮率を測った結果ではありません。
AIに任せる範囲はリサーチの整理、発言録の分析、プロトタイプ案の作成です。誰に何を聞くかの設計と、結果からどの案を選ぶかの判断は人が担う方針です。期間内に判断材料が足りない場合の未確認点の残し方も、依頼前に決めておくと次の検討につなげられます。
向いていない場合
期間を区切って外に頼む意味が出るかどうかは、いま止まっている判断があるかで変わります。状態によって入口が別になります。
- 作るものが既に決まっている AI受託開発に直接進む
- リリース済みで、伸ばし方を探している Nueの改善支援を検討する。改善中も顧客との探索は続けられる
- 社内のチームが毎週顧客に会う体制を回せている 継続的ディスカバリーが動いている。外に頼む必要は薄い
- 判断を止めている問いが具体的にあり、自力では動かない 期間を区切る意味が出る
受託開発で何を、どこまで作るかはプロトタイプとMVPの違いで扱っています。