プロダクトの検証

 前述のプロダクトの開発のすべての段階（コンセプト開発→要件定義→実装→αテスト→βテスト→正式リリース）で、段階段階で常にユーザにプロダクトをぶつけて、ターゲットとしているユーザのニーズに本当に刺さるか繰り返し検証し、修正しながら、開発を進めていくことが重要です。

 事業機会をプロダクトに落とし込むにあたって、日本のベンチャーが陥りがちな落とし穴は、途中途中でユーザにぶつけて検証せずに、自分達の仮説だけで突っ走ってしまい、プロダクトの開発途中でプロダクト要件が定まらずに迷走してしまったり、いざ完成に近いプロダクトのベータテストをしてみたら、まったくユーザの支持が得られずユーザ数が増えなかったり、継続率がまったく出なかったりするケースが非常に多く見られます。

 実際にある投資先であったケースですが、開発途中で仮説として想定しているベネフィットが本当にターゲットユーザに刺さるのか、また数ある機能の中での本当にユーザに刺さるものは何なのか、キーメンバーの中でも意見が割れ、プロダクトの開発が大幅に遅れたケースがありました。コンセプトの資料ベースのプロダクトイメージから始まりプロトタイプに至るまで、ユーザにまったくぶつけることがなく、キーメンバーが今まで対象のユーザ向けに多くのプロダクトを作ってきたため、ユーザを知った気になってしまい、各メンバーの仮説ベースでの、想定でしか議論が展開されなかったため、大紛糾し何も決められなかったのです。

 仕切りなおして、段階的にユーザにコンセプトの資料ベースのプロダクトイメージ、超初期のプロトタイプ、段階的に修正を繰り返したプロトタイプ、そして完成が近いアルファ/ベータのプロトタイプとぶつけていくと、仮説が正しかったか正しくなかったか明確な答えは出ましたし、まったく想定していなかったようなプロダクトの使い方やユーザの意見から、新たなニーズが見つかったり、想定していたニーズが先鋭化されたりして、今までの紛糾がなんだったかと思うように開発が順調に進みました。

 このように、ターゲットユーザに使ってもらい、ユーザのニーズとズレていないか/実装された機能はそのニーズを満たしているかを検証できる必要最小限のプロダクトを、段階段階で細かくプロトタイプを作成しユーザにぶつけることを、シリコンバレーでの流行の言葉で言うとMinimal Viable Product（=ＭＶＰ）となります。コンセプト開発の段階でワイヤーやコンセプトイラストなどもユーザにぶつけてみるという意味では、物理的なモノのプロトタイプである必要もありません。

 ＭＶＰの手法を活用する上で重要なのは、まずは（1）当該プロトタイプで何の仮説を検証しているのかを明確し、それを検証できるようにユーザテストを設計することが重要です。たとえば、「リア充のユーザもリアルの世界と関係のないネットの中で閉じた繋がりを求めている」というニーズそのもの仮説と、「リア充ユーザのネットの中で閉じた繋がりはアバターを介して行うのが適している」というニーズの叶え方の機能の仮説を同じユーザテストで検証しようとしてしまうと、そのプロトタイプがユーザの支持を受けなかったとき、ニーズそのもの（What）がないのか、ニーズを叶える機能（How）に不備があるのかが、わからなくなってしまいます。

 そして、（2）テスト対象のユーザが本当にターゲットのユーザを代表しているかには十分に留意する必要があります。日本のベンチャーがやりがちなテストの過ちは、身近にいてユーザテストが実施しやすいからと言って、自社内や自分達周辺の知人にテストユーザとして意見を聞いてしまうことです。その場合ベンチャーや業界界隈のユーザの意見によってしまい、アーリーアドプターの意見は大いに聞けますが、事業を大きく規模化させる上でより重要な、プロダクトがアーリーアドプターから本当にマスに広がるかどうかの検証ができません。

 また、ネット系のプロダクトだと特にやりがちなのですが、ネット時代になるとユーザのアクティビティのデータがすべて数値として取れます。ですが、事業機会の特定の所で前述の通り、開発者がユーザの使い方を洞察するところにこそ、ユーザ自身も気づいていないような金脈が眠っています。ですから、（3）ユーザテストは必ず対面（もしくはマジックミラーや撮影機材などを通じて）で開発者自身が観察することが必須です。それに、サービスのＫＰＩやユーザの行動履歴などを組み合わせることで、より深くユーザのことが理解でき、より高い精度でプロダクトをユーザに対してチューニングできるでしょう。

次回は10月15日更新予定です。