はじめに
はじめまして！
ソーシャルデータバンク企画チームの塩浦です。
私の仕事は、弊社のプロダクトである「Liny」のサービス価値向上のために新しい機能を考えたり、既存機能を改善することです。
さまざまな機能を開発していく中で、「すごく頑張って作ったのにあんまり喜んでもらえない！？」という経験をすることがあります。
開発に携わる人間であれば、誰しも経験したことのある悩みではないでしょうか？
今日はプロダクト作りのあるあるとも言える「せっかくリリースした機能が"喜んでもらえない"」現象の原因と対策について、私の経験を中心にまとめてみたいと思います。
なぜ喜んでもらえないのか
せっかく作った機能がユーザーから喜んでもらえない原因を、「3つのない」としてまとめてみます。
「3つのない」とは
私たち開発者目線で見ればユーザーに「喜んでもらえない」という状況ですが、ユーザーの立場に立つとどうでしょうか。
悪意を持って喜ばないようにしているユーザーは存在しませんから、何らかの原因で「喜ぶことができない」と考えるのが自然です。
喜ぶことができない原因は、次の3つの不足（＝ない）にあるような気がします。
1. 解決しない
2. 使いたくない
3. 気づかない
それぞれ説明します。
「解決しない」問題
ユーザーはさまざまな「叶えたい願望」や「解決したい課題」を抱えています。
ということは、「願望の解決」や「課題の解決」をしてあげることができれば、ユーザーは喜びを感じます。
これこそが、プロダクトの価値であるとも言えます。
私たちが新しい機能を考える時も、社内データベースに貯めている「ユーザーが抱える願望や課題」が起点になっています。
それにも関わらず喜んでもらえない理由の1つとして、「そもそもその機能じゃ課題が解決しないんだよ！」というケースがあります。
「課題が解決しない」問題は次の2つに分解できます。
- 願望／課題を捉え間違えている
- 願望／課題とズレたアプローチをとっている
願望／課題を捉え間違えている
願望や課題を間違えていたら、そこから出来上がった機能が喜ばしいものになるはずがありません。
しかしながら、この問題は非常に難しく、根深いです。
なぜならば、「ユーザーの言うことを文字通り捉えても、真の課題を捉えたとは限らない」からです。
例えば、ユーザーから「予約ステータスの一括変更機能が欲しい」と言われ、愚直にその機能を実装したとします。
無事「ステータスの一括変更機能」は実装されましたが、一括処理に時間がかかり「100個の予約ステータスを変えるのに10分かかる（しかも同期処理）」だったらユーザーは喜ぶでしょうか？
おそらく喜ばないと思います。
なぜならばこの人の望みは「一括変更」ではなく「一つひとつステータスを変更するのは手間がかかるので時間短縮したい」と言うことだからです。
上記の例は抽象化していますが、私も似たようなことを経験したことがあります。
願望／課題とズレたアプローチをとっている
これは1つ目の捉え間違える問題と密接に関わっています。
願望／課題を捉え間違えればアプローチもズレてしまうのはもちろん、願望／課題を適切に理解していてもアプローチがずれてしまうことがあります。
この場合、願望／課題の解像度が粗いことが多いように思います。
「なんとなく課題はわかってるけど、言語化されていない」という状況は、チームで開発しているとそれぞれの解釈の齟齬を生みます。
結果として、目的から逸脱したものが出来上がってしまうのです。
「解決しない」の対策：解像度の高さが勝負！
課題を捉え間違えてしまう場合も、アプローチを間違える場合も、経験上その多くは解像度の粗さに起因します。
顧客の課題を考えるのであれば、本当にその人の気持ちになって、「誰が、何のために、何を実現しようしているのか」を想像することが重要です。
このユースケースを具体的にイメージできればできるほど、課題の捉え間違いはなくなります。
もしも全くイメージができないのであれば、まずはヒアリングから始めた方がベターでしょう。
アプローチを間違う場合も同様に、捉えた課題をなるべく具体的なもの（＝文字情報）として明文化することで防ぐことができます。
課題が明文化されていれば、アプローチがズレてきた時に検知・軌道修正を行えるからです。
とにかく解像度を高くすることが「解決しない」問題の対策方法だと考えています。
「使いたくない」問題
課題を解決できる機能は作れた。
それでもユーザーが喜んでくれない場合、「使いたくない」と思われている可能性があります。
「いやいやせっかく作ったのに使いたくないってどう言うこと！？」
と言う感じですが、この感情は非常にあるあるだと思います。
機能の価値は、「その機能によって得られる利益」から「支払うコスト」を引いた差分だと思います。[1]
機能の価値 ＝ 得られる利益 ー 支払うコスト
この「支払うコスト」が、「得られる利益」より大きい場合、ユーザーは「使いたくない」と言う感情を抱きます。
極端な例を出すと「課題は解決するけど月額1,000万円です」と言われたら誰も使ってくれないですよね？と言う話です。
現実な話としては、どのような場合にコストが高くなるのでしょうか？
支払うコストが高くなりやすい機能
1. 選択肢が多い機能
「選択」という行為はユーザーに負荷をかけるものであり、多くの場合コストになります。
機能を拡張すると設定項目が増えていきますが、「できることが増える」一方で「選択というコストが高くなる」というトレードオフであることを忘れないようにしたいです。
2. 斬新な機能
「選択」と同様に「新しさ」もユーザーにとって負荷になります。
「今までに見たことのない素晴らしいUI」や「超すごい斬新な切り口の最強のデータ分析機能」などは、ユーザーが労力を払って使い方を理解する必要があるのです。
そういえば、MacBook Proのタッチバーは消えていきましたね。
3. 単体では完結しない機能
これは分析系の機能で考えるとわかりやすいのですが、「分析」は分析それ自体が価値なのではなく、「分析によって得られたインサイトによる施策立案・実行」が価値です。
そのため、分析系の機能はその分析手法がいかに素晴らしかったとしても、それを使いこなすだけの戦略・設計が必要であり、それはユーザーが支払うコストなのです。
「使いたくない」問題の対策：トレードオフの意識！
機能の価値は、「その機能によって得られる利益」から「支払うコスト」を引いた差分だと言いましたが、残念ながらコストをゼロにはできません。
しかしながら「これだけのコストを支払ってでも得たい利益があるだろうか」と考え続けることは重要です。
また、コストを抑える努力はできます。
- 選択を少しでも減らせるように不必要な選択項目は非表示にする／デフォルト値を入れる
- コンサルによるサポートを実施する
- チュートリアル機能を入れる
など、プロダクト内外関わらず、コストを削減するための方法は考えられます。
（もちろん、実装・稼働工数という自社が支払うコストとの兼ね合いも必要ですが、それでも「出した機能が使われない」という事態を受容する結論は避けなければなりません）
「気づかない」問題
最後に紹介するのは、ユーザーがリリースされた機能に「気づかない」という問題です。
これは読んで字のごとくですね。
どんなに課題を捉えていて、少ないコストで大きな利益を得られる素晴らしい機能だとしても、その存在に気づかなければ喜ぶこともないわけです。
当たり前に感じますが、開発を進めていると意外な盲点になることがあるので注意です。
「〇〇がしたいです！」と言われて「あ、それ先月できるようになったんですけど・・・」ってなった経験、一度くらいはないですか？
「気づかない」問題の対策：気づける仕組みをつくる
「さすがに気づいてくれるだろう」と楽観的に捉えると、この問題にぶち当たることが多いです。
心持ちとしては「気づいてくれないかもしれない」と悲観的に捉えた方がベターです。
だからこそ、「絶対に気づける仕組み」をつくるのが対策だろうと思います。
- 絶対に目に入る画面の動線をつくる
- 営業の提案資料に組み込んでもらう
他にも色々ありそうですね。
気づいてもらうための努力は惜しまない方良い、というのが経験上の私見です。
おわりに
取り止めもなく書いてしまいましたが、やっぱり自分たちが作ったものによって誰かが喜んでくれるという経験は何にも変え難いものです。
せっかく作るのであれば、誰かに喜んでもらえるように、その誰かのことを想像し、喜べない要素を取り除いてあげることが重要なんじゃないかな、と思います。
読んで思ったことなどあれば、是非コメントに書いてください。
では。
Discussion