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

一言でいうと

作る価値があるかを、作り切る前に確かめる活動です。同じチームが開発と並行して進め、検証の結果を次に何を作るかの判断へ反映します。

提唱者と登場年

Marty Cagan は2012年9月の記事「Dual-Track Agile」で、検証の活動と開発の活動を2本の流れとして並行させる進め方を説明しました。同記事は、この呼称を Dual-Track Scrum として共有した人物として Jeff Patton を挙げています。

同じ記事は、検証の目的を「検証済みのバックログ項目を素早く作ること」と定義しています。プロダクトマネージャー、デザイナー、エンジニアが一緒に検討し、作り切る前に試作で確かめる進め方です。

何を解決するか

要望をそのまま実装すると、作った機能が使われない事態が起こります。要望を出した人も、実際に使ってみるまでは自分が何を必要としているかを言語化できないためです。

ディスカバリーは、この検証を実装の前に移します。価値があるか、使えるか、実現できるか、事業として成り立つかの4点を、小さな試作と利用者への確認で調べます。

開発が止まらない点も設計の狙いです。検証と開発を別の流れにすることで、検証の結論を待つあいだも開発チームは前の回で決まった仕事を進めます。

実際の進み方

解くべき課題を決めます。機能の指示ではなく、どの利用者のどの困りごとを解消するかを言葉にします。

次に、案を複数出して試作を作ります。この段階では実装を作り込まず、操作の流れを確かめられる程度の試作を用意します。利用者に触ってもらい、想定した使われ方になるかを確認します。

検証の結果は、次に何を作るかの判断へ反映します。通らなかった案は記録して取り下げます。取り下げた案と理由を残すと、同じ検討の繰り返しを避けられます。

導入でよくある失敗

• 検証の名前で意見を集めるだけで、判定の基準を決めていない
• 試作を作り込みすぎて、検証に開発と同じ期間をかける
• 経営や営業から来た要望を、検証の対象から外す

求人票にこの語がある場合に読み取れること

プロダクトマネージャーとプロダクトデザイナーの求人で使われます。この語がある場合、決まった仕様を受け取って実装する進め方ではなく、何を作るかの検討と優先順位づけにチームの一員として関わる役割だと読み取れます。応募者の経歴では、検証の結果として取り下げた案があるかを確認してください。通した案しか語れない場合、判定の基準を持っていない可能性があります。

隣接手法との違い