ユーザーの声が"上司の意見"にすり替わる瞬間
「ユーザーにとって、最高に便利でクールなプロダクトをつくりたい！」
CEOやCTO、プロジェクトマネージャー、技術リード、デザイナー、エンジニア。開発チームに参画するメンバー全員がそう思っているはずです。しかしながら、現実はなかなかうまくいきません。特に、CTOやTech-Lead、PMの方は、そんな経験があるのではないでしょうか？
Stripeによるスタートアップ統計や厳しく悲しいTandemの創業ストーリーから、成功することの難しさと良いプロダクトをつくる大変さがものすごく分かります。私自身、開発者として便利なプロダクトをつくろうと、何度もトライしてきました。
経験がある方ならきっと分かると思いますが、「こういうのが欲しかったんだよ！」 とユーザーに言ってくれるような製品をつくるのは、本当に難しいですよね。
私が最近、特に難しいと感じたことは、ユーザーの気持ちを代弁しているつもりが、いつしか自分の意見を述べているだけになってしまうことです。ユーザーの声や意見が、個人や上司の意見に変わってしまう瞬間ってないでしょうか？
ユーザーの本心とは、ズレた機能や体験を実装してしまい、結果的にチームに失敗を招いてしまう。あなたのチームでは、そういったことがないでしょうか？
私が過去の開発現場で体験した、開発チームとユーザーで"ズレ"が発生する具体的なケースをいくつかご紹介します。 皆様のプロダクト開発のお役に立てば幸いです！
開発チームとユーザーに"ズレ"が起きる具体例
1.機能案の意見や助言を、開発チームのメンバーや上司に求め、それで決定してしまう
こちらが記事タイトルの例です。
機能に関する重要な意思決定を開発メンバーだけで行っていませんか？具体的なシーンがこちらです。
私:（もしかしたら、この課題の解決策は〇〇をアプリケーション化したものかもしれない。ユーザーは、XXの業務フローをクリックとボタン操作1つでできるようになるとすごく喜ぶかもなぁ。）
私:「チームの皆さん、昨日夜に犬の散歩をしていて気づいたのですが、ユーザーは△△ができるアプリを欲しいと思っているかもしれません。前聞いたとおり、ユーザーは■■に課題を感じていたので、こういう機能があると喜ぶかもしれないです。」
メンバー:「確かにそのとおりかも。いいと思いますよ！」
上司:「私もユーザーと会話していて、それに近いことを課題に感じていたので喜ぶと思います。いいですね！」全員:（全員の意見が概ね一致している、さっそく実装してみよう！）
特に重要な機能に関する判断をするのであれば、複数のユーザーに確認し、ユーザーと議論したほうが間違いがないです。開発チーム内でただ盛り上がっているだけで、いまいちユーザーに刺さらない微妙な機能になる可能性があります。
ユーザーと接点を持ち、質問や会話がしやすい環境を日頃から構築できているかが課題となります。ユーザーとのフィードバックループを構築していなければ、最終的に 「お金を払ってでも買いたい」と感じる価値まで成長することが難しいかと思います。
初めて自分の製品をつくったときや、プロダクト開発の経験が浅いときに、このミスを何度もやっていました。チーム内であれだけ盛り上がっていた機能が、ユーザーに「う〜ん」と微妙な反応をもらったときの落胆というと、ほんとに悲しいものです。
2. 自分が困っている課題を、みんなも困っている課題と盲信し、確かめない
私:（チームのドキュメント管理や情報管理に課題を感じるな。これはどの開発チームやプロジェクトでも間違いなく悩む問題だ！さっそくつくってみよう。）
自分が困ったと感じた課題を、他の人もおそらく困っているだろうと盲信し、さっそく開発をはじめていませんか？見つけた課題を一度抽象化し、複数のユーザーに確かめ、改めて具体化し、もう一度確かめると、真に解決すべき課題が見えてきます。
自分のGitHubリポジトリに、そんな"つくりかけ"の製品がたくさんあります。見られると恥ずかしいので、もちろんPrivateです笑。
ユーザーから本当に必要とされる製品になるため、開発前に見つけた課題を検証するステップが必要かと思います。
3. すごく自信のあるアイデアだから、ユーザーに確かめない
課題や解決策を日々考えていると、どこかで圧倒的閃きがやってくるものです。
私:（これだ！このアイデアで〇〇という課題を完璧に解決できる！！）
私:（ユーザーに一度確かめたほうがいいかな...？いや、今回はさすがに革新的すぎて確かめるまでもないだろう。一度つくってみよう！）
だめでした。あのときの閃光が嘘のように、ユーザーと会話してみると改善ポイントがポツポツと浮かんでくるものです。
どれだけ自信があろうとも、複数のユーザーにそのアイデアが本当によいものかを確かめるべきです。空回りする、独りよがりな製品や機能ができる可能性があります。
4. 技術ファーストで動いてしまい、市場性やニーズを確かめない
私:「この機能を汎用的にAPI化するよう改善すれば、技術的に無限の可能性ができる！ユーザーもきっとそれを望んているはず！」
私:「イーサリアムのスマートコントラクトを使って〇〇ができるアプリをつくろう。きっとウケるはず！」最近のトレンド:「これからはAIだ！AIを取り入れた最先端の製品を顧客は求めている。今の製品にAIを取り入れるぞ。」
これもエンジニアあるあるかと思います。開発者は技術的にすごく魅力を感じていても、ユーザーはそうではないことがよくあります。「そんな大層な機能より、ピン留め機能をつけてほしい」や「UIやUXをもっとシンプルに使いやすくしてほしい」などが、ユーザーにとっては価値に感じるかもしれません。
その技術を使うことや最先端の技術を導入することが目的になり、課題を解決する手段のひとつであることを忘れてしまいがちです。
5. ユーザーの気持ちになって、真剣に分析して出した答えを、ユーザーに確かめない
私:（これだけなぜなぜ分析したから、完全にユーザーを理解できたはずだ。ユーザーはこの課題を解決する機能を求めているに違いない。もう分析に時間をかけるのは辞めて、次に移ろう。）
ユーザーに確認し、もし分析結果が的外れだったら、分析にかけた時間と進捗が失われ、喪失感だけが残ります。
ユーザーを理解するパートは苦しく、終わりの見えないものに思えます。早く次のステップに進もうとして、失敗することがよくありました。真剣に分析して出した答えをしっかりとユーザーに確認し、確証のある自信に満ち溢れた考えにできれば、どんな人からの質問や批評にも答えられるようになります。
ユーザーとの"ズレ"を確認するチェックリスト
開発チームとユーザーの間で、認識や温度感にズレが起きていないかを確認できるチェックリストを作ってみました！
ぜひ、皆さんのチームで当てはまることがないか、確認してみてください。
- 直近1ヶ月以上、ユーザーと会話していない
- 「ユーザーと会話するのは自分の役目じゃない」と考えるチームメンバーが多い / ユーザーとの会話を誰かに一任している
- 機能を実装するとき、UIやUXに試行錯誤する時間的余裕がない / 開発途中で気づいた改善アイデアを取り入れることに障壁がある
- スプリントプランニングで、何故この機能の実装に今取り組むべきなのか、ユーザーが具体的にどういう場面で必要としているかを説明できない
- リリースした機能や今のプロダクトについて、ユーザーの評価を聞くことがない / 今回のリリースでどれだけ成長できたのかをモニタリングしない
- 何を開発しているかを隠し、突然リリースしてユーザーを驚かせたいと考えることが多い / ユーザーに何度も会話し、確かめる文化が好きではない
2つ以上当てはまれば、要注意です。
長期的な視点で、プロダクトの成長がいつか停滞し始めるかもしれません。
最後に
チームで「これはユーザーの声だ」って言えるもの、いくつありますか？
それ、本当にユーザーに聞いたって胸張って言えますか？
フィードバックループが大事だ！と叫ばれる昨今ですが、本当にそれを実行するのはすごく難しいと感じています。
私は今、これらの課題を解決できるプロダクトを開発しています。 これがすごく難しく、皆さんの意見をお聞きしたいです。どうか、お助けいただけませんか？
"これ、自分にも思い当たるな…”と思った方は、そのときのエピソードについて、ぜひコメント欄で教えてくれませんか？他にも、共感・意見・反論、どんなコメントも大歓迎です。
もっと深く話したいという方、XのDMも大歓迎です！BlueskyやLinkedInでも構いません。
今イメージしている解決策やプロダクト案もお話しできます！
あなたの意見を、ぜひプロダクトに反映させてください！
最後まで読んでいただき本当に感謝です。
Discussion