プロトタイプ検証したのに使われない機能が生まれるパターンの振り返り
「どんな機能なら使われるのか」という問いは、プロダクトの体験・機能をデザインするとき、本当に恐ろしく本質的な悩みになると感じます。
どんな価値を提供するアプリだったとしても、使われなければ無価値です。
そして、「提供した機能の64%は使われない」とも言われています。
これは、アプリの機能を提案することを仕事にしている人間には、本当に大問題です。
上のグラフは、あまり高い信憑性はあるとは言われておらず、2002年の研究で社内向けのプロダクトを対象にデータを出しているようです。ユーザー数が多いConsumerアプリに適用して語ることはできません。
しかし、僕が今関わっているのは社内向けのCRMプロダクト。火の玉ストレートで喉元に突き刺さりました。
「自分が企画した機能が使われないのは嫌すぎる」
そこで、使われるプロダクトの条件を改めて意識し、「使われるには」を見つめ直すことにしました。
プロトタイプ検証では上々の反応、でも使われない…
開発するのには開発チームの工数がかかるし、できるだけ「本当に使われる機能」だけをリリースしたい。
だから、まずはサクッとプロトタイプを作ってみてユーザーの反応を見る。
Notionで情報をまとめてミニアプリ化
Excelのマクロや関数でそれっぽく
SpreadSheetにGAS書いて、ついでにAppSheetでイイ感じに成形
Figmaのプロトタイプ機能で紙芝居
などなど。
プロトタイプ検証用にサクっと機能の一部を切り出して実装してみることは、本職エンジニアでなくとも比較的容易に行えます。
しかしながら、ここで「最高だぜ〜！🙌」と両ヒレをあげたくなるようなフィードバックをユーザーから貰えた企画も、実際に開発してリリースすると、なかなか使われないことがあります。嫌だなぁ。
なぜ使われない？
なぜ「最高だぜ〜！🙌」と言われた機能も使われないことがあるのでしょうか。
思い当たることを書き連ねてみます。
大きく分類して、以下の2パターンがプロトタイプ検証の失敗を招くパターンだと考えます。
① ユーザーに気を遣われている（検証方法が悪い）
②「機能の一部を切り取って検証」というコンセプトが機能していない
ユーザーに気を遣われている（検証方法が悪い）
① は、ユーザーと頻繁にコミュニケーションをとる関係構築をすると次第に現れるアンチパターンと思われます。
インタビューの意義や進め方を理解し、快くリサーチに協力してくれるユーザーは、短いスパンで企画の改善を繰り返すには強い味方となりますが、FBにバイアスがかかっていることがあり、理解した上でインサイトをまとめていく必要がありそうです。
ユーザーの言葉全てを本心と思わず、言葉の裏に潜むニュアンスを読み取ることで、使われると思い込んだ機能が使われない状況に陥ることを防げるはず。
その際のチェックポイントとして、
なぜその機能を使ったのか
他の方法を使わなかったのはなぜか
使いたいと思ったか、試しただけか
あたりをインサイトとして拾えると良さそうです。
「機能の一部を切り取って検証」というコンセプトが機能していない
② は、プロトタイピングという手法の弱点として「大規模なシステム開発に向いていない」という側面があることに起因します。
プロトタイプ検証の主戦場は、基本的に0→1フェーズの機能における価値検証で、新規事業の色が強いです。
しかし、大規模システムの追加機能としての価値検証となると、プロトタイプで単体検証しても、実装後には数多くの機能と共存する必要があるため、「単体の体験」から「複合体としての体験」でユーザーのもとに届くことになります。
この体験構造が変化することによって、プロトタイプ検証が徒労に終わるパターンを図にまとめました。
どんなプロダクトも最初は規模が小さく、プロトタイピングで価値検証され、PDCAサイクルの中でブラッシュアップされていくのに適した状態です。
しかし、いよいよ規模が大きくなり機能が増えてくると、それぞれの機能が担当する体験がなんなのか、明確な区分がなくなっていきます。
プロトタイプで価値検証をすることに意味がないわけではなかったように思いますが、既存機能との価値が被っていないか、全く異なる価値体験を混ぜ込んだキメラのような企画になっていないか、注意する必要性が高いと感じました。
プロダクトの持つ価値が増えてくると、本当に考慮すべき競合調査も多く、考慮漏れをなくすために相当な労力を要しますが、「ここまでできて一人前」と自戒の念を込めて書かせて頂きます🙇♀️
使われる機能をリリースするためには
プロトタイプ検証の向き不向きをよく理解して活用しないと、僕のように悲しい気持ちになることになります。
プロトタイピングで念頭に置くべきと感じたことをまとめると、以下のようになりました。
0→1や小規模なプロダクトほど、プロトタイプ検証での感触は信用できる
大規模プロダクトの追加要件でのプロトタイプ検証は、他機能やプロダクト内の体験構造の設計まで手を抜いてはいけない
プロトタイプ検証時点で、本物の好感触を得られているなら、新プロダクトとしてのリリースを検討した方がいい可能性がある
機能を主語とせず、体験を構築してあげることを第一とする
あとがき
失敗経験から、大規模プロダクトの追加機能企画とプロトタイプ検証について書かせて頂きましたが、僕はプロトタイプ検証が他社でどのように行われているのかあまり詳しくないです。
開発工数が潤沢なチームや、プライオリティが最優先の企画担当であれば、最初から開発に進み、β版としてリリースしながら改善していくことができると思います。
しかし、無数の企画の中からROIが高いものから進める必要がある場合や、限られたリソースの中で確度の高い企画を選び取ったりする場合には、何かしらの根拠を作る必要があります。
これという正解が見つからない感覚がありますが、不正解を避け、なるだけ自信を持って開発工数をベットできる状況をつくらないとなぁ、と頭を悩ませる毎日です。
新卒1年目時代の記事はこちらです。気になる方はこちらもどうぞ！
最後まで読んでくれてありがとうございます！
ぜひ、スキしていってください！
