前回はPoCの環境に関しての説明をさせていただきましたが、今回は検証の観点に関して説明をしていきたいと思います。

検証の観点は以下の3種に集約されると考えています。

・効果や有用性があるか
・技術的な実現性があるか
・実現に向けた具体事項は何か

効果や有用性があるか

まず、はじめに想定しているモデルが課題解決の方法として見込むことができるか、また、ビジネスモデルが成立するかを確認する必要があります。
スモールスタートで検証を実施するため、小規模のテストで課題解決のインパクト試算/測定が必要になります。

pocではテスト対象者が限定されるため、たまたま、良かったと言っている人がいたからといって、これでいいという判断にはなりません。
サンプルの数が少ないので、ユーザインタビューなどを通じてどこがどうよかったのかを追求していくことでインパクト試算/測定が精緻になります。
さらに、ユーザインタビュー等では正直な回答が何より重要です。仲間内で空気の読み合いで良かったと評価した場合、実運用には到底耐えられません。

すなわち、テスト対象者は数多く実施するにこしたことはありませんが、中でもそのサービスに対して真摯な意見を述べてくれる人の意見から効果と有用性の判断を実施していくことが実態としては望ましいと思います。

技術的な実現性があるか

これはコンセプトが机上の空論にならず、技術的に実現可能かを検証するということです。
これはプロダクトを設計する段階での検証が一回目。次に実際にユーザが利用した後に、そのフィードバックをもって改善するのに実現可能性があるかを確かめる二回の工程があると考えています。

特に重要なのは二回目のユーザからのフィードバックを受けた後になります。
例えば、画像認識のAIを活用したプロトタイプを作成したとして、そのユーザフィードバックで認識精度が弱いと意見があったとします。

認識精度の弱さはどのように改善するか、そこに技術的な実現性はあるかといった具合になります。Googleの機械学習エンジンのアルゴリズムが足りていないのか、それとも正解データが足りていないのか。掘り下げていくことによって技術的実現可能性があるかを探っていくことになります。

実現に向けた具体事項は何か

最後に具体化するにあたっての必要事項の確認になります。
コンセプトが要求する追加仕様や改善策、検討課題は何かをそろえていきます。

本格運用/開発に向けてユーザ視点での課題を抽出し、追加仕様を洗い出し精緻化することになります。ここでもやはり重要なのはユーザからの真摯なフィードバックです。どうしても最後には漏れがでます。この漏れをいかに潰しマーケットに送り出すことができるかで、立ち上がりの速さは変わってくると考えています。

ここではKPIも同時に検討が可能になってくるので、当該サービスにおける各種KPIに対してプロダクトが許容範囲で稼働可能であるかを十分に検証し、本番を迎えていきます。

以上PoCの検証観点に関する説明でした