仮説検証を経て、最初のプロダクト（MVP）を構築した、では早速このプロダクトを用いた事業を始めましょう、というわけにはいかないですね。本格的に事業を始めるとなると、そのための体制が必要になります。動くプロダクトができたからといって、いきなり事業の体制作りを始めるのは活動上のムダを呼び込むようなものです。
では、何に取り掛かるべきでしょうか。MVPによる検証を行いましょう。作る前にすでに検証を行っているからといって、できた後は検証が不要になるわけではありません。
外部検証と内部検証
MVPによる検証、つまり立てていた仮説が成り立つのかのテストやレビューを行います。この検証には、2つの観点があります。外部検証と内部検証です。
| 外部検証 | 内部検証 | |
| 検証にあたって利用する人 | 想定ユーザー | プロダクトオーナー |
| 実施すること | ユーザーテスト | プロダクトレビュー |
| 準備する環境 | 出来る限り実際の利用状況、条件に近づけて使ってもらう ※ユーザーの手配など準備に時間を要する | ユーザーになりきって（なりかわり）、プロダクトオーナーに使ってもらう ※POとチームの都合があえばすぐにできる |
| 検証者の役割 | 観察とインタビュー | 観察とヒアリング |
| 全体の進行 | 検証者が主導 | 利用者（PO）が主導 |
| 実施後の分析 | 検証者が行う | 利用者（PO）と検証者で行う |
| 次にやること | 分析を経て、プロダクトバックログに必要な対応を加える | 分析を経て、やるべきことと判断がつきやすいものはプロダクトバックログへ。判断がつかないものは外部検証で確かめる |
大きな違いは「誰がテストを行うか」です。外部検証は、想定しているユーザーイメージに近い人たちを集めて、使ってみてもらうテストです。一方、内部検証は、プロダクトオーナーが中心となって使い、それをチームで観察し、適宜質問を投げかけていくテストになります。前者をユーザーテスト、後者をプロダクトレビューと呼び分けます。
いずれの検証も、開発チームに参画してもらいたいと思います。検証の準備と実施をリードするのは、プロダクトオーナーかもしれません。わざわざ、検証の時間をともにしなくたって、プロダクトオーナーがまとめる分析結果を文書や口頭でもらえたらそれで良いのではないか、と思われる方がいるかもしれません。検証に時間を割く分を開発に回した方が良いのではないかという声もあがってきそうですね。
しかし、プロダクト作りの質を高める、つまり、よりユーザーに必要とされるものをどんぴしゃで形にしていくには、開発チームの検証参加はその前提と言えます。なぜなら、検証はユーザーの息遣いとも言うべき、利用時の雰囲気を直接把握することができるからです。利用時に現れる、正の感情にも負の感情にも、その強弱があります。こうした感情の濃淡、反応の強弱を理解するには、文書だけでは不十分なことが多いのです。文書とあわせて、口頭の説明があったとしても、直接見聞きするのとでは大きな差があります。
これは実際にユーザーを相手にする外部検証だけではなく、プロダクトオーナーがユーザーの代わりを務める内部検証でも同じことです。内部検証はあくまで、プロダクトオーナーによる代行となりますが、どの機能をどのような流れで使ったときに、どんな感情や反応がどのくらいの強さで現れるのかを開発チームが理解する近道は、その様子を目の当たりにすることです。
そして、なぜ、そのような反応になるのか、間髪入れず確かめることができるのも、検証に直接参加する大きな利点と言えます。レポートで間接的に内容を確認できたとしても、湧いてきた疑問を確かめる機会は先になってしまうからです。結果として、プロダクトの改善は少しずつ先延ばしになってしまいます。
ユーザーに自分を憑依させる
プロダクトレビューは、ユーザーテストに比べると段取りが少なくて済む場合が多いものです。関係者の予定さえあえば、すぐにでも始められる気軽さがあります。また、ユーザーテストの前に、自分たちで作ったプロダクトの理解を深めるべく、客観的に眺める時間としてプロダクトレビューの実施を先行させると良いでしょう。
プロダクトレビューを実施する際のポイントをいくつかお伝えしておきます。最も重要なことは、プロダクトオーナー（想定ユーザーの代行者）が自分にユーザーを憑依させることです。「ユーザーのつもりで」「ユーザーになりかわって」、どのような表現でも構いませんが、要はここで必要なのは「プロダクトオーナーの個人的な意見」ではなく、「ユーザーの意見」なのです。ユーザーの行動と感情を忠実に再現させる、それにフィットするのは「憑依」というイメージです。
ですから、プロダクトレビューを始める前に、いや、プロダクト作りを始める前に、プロダクトオーナーは足繁く想定ユーザーの元へ行き、現状を観察し、言葉を書き留め、その息遣いを目の当たりにしておく必要があります。プロダクトオーナーの想定ユーザーへの理解が浅いままでは、「ユーザー再現」の解像度も粗く、せっかくプロダクトレビューを実施したとしても、かえって誤った開発をリードすることになりかねません。ユーザーの理解が浅いままで実施するプロダクトレビューでは、チームで発見した疑問（「ユーザーはこれをどう感じるだろう？」「この機能は使えるだろうか？理解できるだろうか？」）を記録し、その後の外部検証で解消していくという運用になるでしょう。
さて、ユーザーを自分に憑依させたプロダクトオーナーは、黙々とプロダクトを使うのではなく、発話していくことが求められます。語りながら、動かしていくイメージです。自分が思ったこと、頭に浮かんだ言葉を、整理することなく、そのまま発言します。現れる生の言葉を、周囲の観察者が受け止めながら、利用行為に伴走していきます。発言のうち、その言葉を発した背景、要因が想像できない場合は、その時点で確認しましょう。発言してから間を置くほど、その発言のなぜを「思い出す」ことなり、作為が入りやすくなります。
とはいえ、利用行為の途中で議論まではじめてしまうことがないようにしましょう。言葉を受け止めて、背景や要因の確認を入れながら、自分の気づきや後で議論したい内容を自分の手元で記録しておくに留めておきます。ひととおりの利用行為が終わったところで、各々が記録した気づきを共有、深堀りをする「感想戦」の時間を設けます。感想戦とは、将棋や囲碁などのゲームで対局が終わったところで、対局の一部を再現しながら、最善手を検討するふりかえりの時間です。プロダクトレビューも、利用行為の一部を再現しながら気付きの深堀りを行います。
なお、利用行為全体の記録は、Zoomなどの画面共有及び映像記録ができるツールを使うと良いでしょう。利用時の発言をくまなく拾って行こうとすると、記録が第一義となってしまい、本来の「新たな気づき、疑問」を得るという狙いがぼやけてしまいます。記録はツールに任せるのが基本です。
自分たち事感を高める
自分たちで使ってみる、評価するという行為にはもう一つの意義があります。それは、自分たち事感を高めるということです。内部検証での利用者はあくまでチーム自身です。そこで発露する感情や思考は、もちろんチームに依るものです。自分たちで自分たちから出てくる言葉、解釈を確かめていく行為は、「自分たちなりの利用に関する評価」を明らかにしていくことでもあります。それは「自分たちも利用者の一員である」という前提に置き、それを強めていく行為になりえます。
一方、外部検証、想定ユーザーを相手にテストだけし続けると何が起きるでしょう。おそらく、ユーザーの行動や思考について相当詳しくなるはずです。憑依時の再現率も高くなることでしょう。その一方で、思考や判断が受け身がちになってしまう、という面も現れてきます。
考える、判断する際の主語が、常に「ユーザー」（彼、彼女たち）になってしまうと、自分たちなりの解釈の入る余地がなくなります。そこまで行ってしまって良いのでしょうか。それで良しとするならば、「ユーザーはすべての問題を自分たちで解決することができる」という見地に立つことになります。これは、違和感がありますよね。ユーザー自身では気づけない問題、ユーザー自身では解決手段が想像もできない問題もあるはずです。
外部検証でユーザーの視界を手に入れ、内部検証では自分たちの解釈を持ち出せるようにする。自分たちの解釈と、ユーザーの評価に差分が生じるところにこそ、単なる思い違いあるいは、ユーザーを先回りする気づきの両端がありえます。プロダクトの望ましい姿を捉えるために、ユーザーの協力を得ながら、それでいて、自分たちで感じ取る、考えるということもあわせましょう。そのプロダクトの本当の最初の利用者とは、チームに他なりません。
