はじめに

プロダクトの価値をテストする方法について、今までは主観的にテストをしていましたが、もう少し効果的にテストできないかを考えてみました。

まだ私が実際に試していないものも多く、特にUXやデザイン関連の知識については学習不足の領域でもあるので、不完全な机上の空論である点を理解して読んでいただければ幸いです。

なお、本記事では顧客の要求を正しく理解する方法についてはスコープ外です。顧客の要求を正しく理解しているという前提で記事を書いています。

はじめに
プロダクトの価値とは何か
- プロダクトを通じて得られる利益の大きさ
- 利益を得るまでの障壁の大きさ
プロダクトの価値をテストする方法
おわりに
参考文献
- プロダクトの価値の定義
- テスト方法

プロダクトの価値とは何か

テストをするには何が正解か（期待値）が必要なので、まずプロダクトの価値の定義が必要です。

ここでは、プロダクトの価値は「プロダクトを通じて得られる利益の大きさ」と「利益を得るまでの障壁の大きさ（小さい方が良い）」で決まると定義してます。*1

プロダクトを通じて得られる利益の大きさ

プロダクトを通じて得られる利益とは、以下の3つの利益を指します。*2

機能的利益（情報を得る、成果物を作る、効率化するなど）
感情的利益（嬉しい、楽しい、落ち着くなど）
社会的利益（人によく思われたいなど）

また、プロダクトを通じて得られる利益は人によって変わりますし*3、同じ人であっても状況によって*4プロダクトを通じて得られる利益は変わります。

そのため、プロダクトを通じて得られる利益を正しく理解するためには、以下を理解する必要があります。

プロダクトのユーザーは誰か
ユーザーはどのような状況でプロダクトを利用するか
各ユーザーが各状況で得られる利益は何か
プロダクトを通じて利益を得るために必要なプロセスは何か。

利益を得るまでの障壁の大きさ

利益を得るまでの障壁とは、ユーザーの特性やプロダクトを利用する環境における、以下のようなもの事象を指します。

プロダクトが使いにくい
利益を得るまでの操作量が多い、操作時間がかかる
利益を得るまでに疲れる、イライラする
プロダクトの学習時間がかかる
プロダクトの不具合によって機能を使いたい時に使えない・感情的利益を損なう

ユーザーの特性とは、例えば以下のようなものを指します

視力など五感の能力
体の大きさ
知識やスキル

プロダクトを利用する環境とは、以下のようなものを指します。

利用端末、明るさ、騒音、空間といった物理的な制約
音を出してはいけないといった社会的な制約

プロダクトの価値をテストする方法

次に、プロダクトの価値をテストする方法についてです。

プロダクトを通じて得られる利益の大きさ

プロダクトを通じて得られる利益の大きさについては、基本的には開発組織内で主観的に評価するか、ユーザーからのフィードバックを用いて評価することになると考えられます。ただし、一部の正解が客観的に決まっている機能的利益については、開発組織内で評価しやすいものもあります。例えば、成果物が形式通りに作成されているかどうか、工数が削減できているかなどです。

開発組織内で主観的に評価する方法

開発組織内で主観的に評価する方法は、以下のような方法が考えられます。

定義した利益を得られているかを基本設計書のレビューや手動テストなどで評価する
カスタマージャーニーマップなどで定義した理想の体験ができているかを基本設計書のレビューや手動テストなどで評価する
上記について、過去のユーザーからのフィードバックも参考にする
toC向けのプロダクトであれば、実際に自分自身がユーザーになるのも良いですね！

ユーザーからのフィードバックを用いて評価する方法

ユーザーからのフィードバックを用いて評価する方法は、以下のようなものがあります。

リリース前にペーパープロトタイプや仮実装したプロトタイプなどを用いてユーザーインタビューを行う
ユーザーを呼んでスプリントレビューを行う
リリース後にユーザーからの定性的なフィードバックをもらう
- 場合によってはベータ版のリリースを行う
ユーザーの行動履歴（定量指標）を分析する
実際にユーザーがプロダクトを利用している状況を観察する

もしユーザーの行動履歴が不足している場合は、機能開発することも検討してみてください。例えば、以下のようなものです。

各操作のログを出力する
コンテンツが良かったことを評価するために「ためになった」ボタンを追加する
ページの滞在時間やヒートマップを計測できるようにする

利益を得るまでの障壁の大きさ

利益を得るまでの障壁の大きさに関するテストについては、上記の評価方法に加え、開発組織内で技術的に評価する方法が考えられます。

開発組織内で技術的に評価する方法

開発組織内で技術的に評価する方法とは、以下のようなものが考えられます。

デザイン、ユーザービリティ、UXライティング、アクセシビリティ等に関する技術的なセオリーやガイドラインを充足するか否か
ページの描画時間や操作量などの定量的な数値
機能性のテストの実行結果

テストするスコープ

最後に、特にプロダクトをローンチ後に新機能を開発した場合におけるテストのスコープについてです。

新機能を開発する場合、新機能が使えるかという観点でテストを行うことが多いと思います。しかしながら、新機能次第ですが、なるべく新機能と他機能も含めたプロダクト全体のUXに問題がないかをテストした方が望ましいです。なぜならば、新機能によって他機能のUXを阻害したり、新機能が他機能を考慮した作りになっていなかったりするからです。