こんにちは！プロダクト開発部のすずまさです。
今回は、ある新機能を追加するプロジェクトでユーザーインタビューをしてみたら、予想外の回答がたくさん返ってきて「ユーザーに話を聞きに行っといてよかった…」となった話をしようと思います。
経緯
マネージャーから「CS（カスタマーサクセス）によるとここの機能の改善要望が提案校に対して50%あるみたいです！」と連絡を受けたことをきっかけに、やる価値は大きそうだと判断しプロジェクトが始動しました。
エンジニアとマネージャーで話し合った結果、大きく分けて3パターンのUI案が出揃いました。 3案のうち、どのUIパターンがユーザーに適切かを判断するべく、何校かの学校の先生にアポイントを取ってユーザインタビューする機会を得ました。
インタビューの結果
期待していた通り、インタビューをしたことによりどのUI案が良いか絞ることができました。
また、UI案を考える段階で「この機能を追加すると、新規のユーザーは良くても既存のユーザーにとってはかなり体験が悪くなってしまうのではないか。悪くならないような別機能も追加するべきではないか。」というようなことを時間かけて話し合っていたのですが、これが全くの杞憂だったこともわかりました。危うく需要のない機能を追加するところだったので良い収穫でした。
ただ、予想外だったのは、そもそも今回のプロジェクトで追加したい機能がほとんどのユーザーに刺さっていなかったことです。
前提として「需要がある」と聞いたから発足したプロジェクトなのに、ユーザーに直接聞いたら「あったら嬉しいと言えば嬉しいけど、そこまで強く欲しいわけではないかな…」という温度感ばかりだったので非常に戸惑いました。
なぜ予想外の結果になったのか
私たちは、上述した通り「CSによると、この機能の改善要望が提案校に対して50%あるらしい」という情報をきっかけに動き出しています。
この時、情報の精査をしていなかったのが原因でした。
一口に "ユーザー" と言っても、どの地域の学校なのか？学校の種類は？どの役職の先生なのか？…など、種類は多岐に渡ります。
ここの情報の精査をしておらず、機能を欲しているユーザー層がわかっていなかったため、インタビュー後に「需要あるって聞いてたのに…」と意気消沈する結果になってしまいました。
一応この後、上記の結果を踏まえて先生の役職などを意識してアポイントを取ったところ、ちゃんと「この機能があると嬉しいし欲しい！」という声も聞けたので、プロジェクトが潰れることなく開発を進めることができました。
学校の取り巻く環境や先生の仕事内容によって、ユーザーの欲する機能はこんなにも大きく変わるのかと学びました。
インタビューしてなかったらどうなっていたか
"顧客が本当に必要だったもの" じゃないものを作っていたのは間違いないと思います。
インタビュー前に「このUIが一番良さそうだよね」と話していた案とインタビューで得られた結果は違っていたので、もしインタビューをしていなければユーザーにとって不便な画面を作っていたでしょうし、不要な機能も追加していたと思います。
曖昧な要望を元に伝言ゲームで不要なものを作ってしまうという、まさに下記の風刺画通りのアンチパターンを踏むところでした。
また、インタビューをしていなかったら今後の戦略も立てられなかったと思います。
今回様々な層のユーザーに話を聞いたことで「そこよりもこっち不便だから直してほしいんだよね」といった生の改善要望をたくさん聞くことができました。
改善要望としてはTODOに積んであっても、優先順位を決めかねていたので、どのユーザーがどういう背景でどのくらい困っているかを解像度高く聞けたのはとても参考になりました。
「問い合わせには一回も来ていなかったが実は多くのユーザーが困っていた」というような盲点になっていた箇所を見つけられたのも大きかったです。
反省
上述した反省点も含め、まだまだ改善できることがありそうだと感じたので、プロジェクト始動〜仕様確定までの振り返り会を開くことにしました。
時系列を振り返りながら進めたかったので、The Story of a Storyを使って振り返り会を行いました。
The Story of a Storyという手法を使うのは今回が初めてでしたが、長いプロジェクトだと結構忘れている部分が多いので、みんなで時系列を振り返りながら進められるこの手法はかなりよかったです。
Tryから一部抜粋して紹介します。
プロジェクト始動前に分かっていること / 分かっていないこと / 知りたいことを整理する
上述した「一次情報の精査をしていなかった」という反省点から出たTryです。
伝言で伝わってきた曖昧な情報にも関わらず、そのことを全く意識せずに盲信してプロジェクトを進めていました。 プロジェクトを進める前に、一呼吸おいてじっくり情報を整理する時間を設けるべきでした。
次回別のプロジェクトを始める際は、インセプションデッキを使用して全員で情報を確認したいと思います。
早めにステークホルダーに意見を聞く
今回、ユーザーだけでなく、社内のCSの方やPMM（プロダクトマーケティングマネージャー）といったステークホルダーを巻き込んだ進め方はできていました。 ただし、ユーザーインタビューを何回かやった後に「ユーザからの需要があまりないかもしれない」という不安からCSに意見を聞きに行っていたので、初めから話を聞きに行っていれば良かったなと思いました。
インセプションデッキの「ご近所さんを探せ」などを使って関係者を整理し、わかっていないことに対して関係者に話を聞きに行くという動きを早めに行えていたら、スムーズにプロジェクトを進められたかもしれません。
早めにプロトタイプを作成してフィードバックをもらう
今回、私たちはUI案を話し合って簡単な画面設計だけしてからユーザーインタビューをしていました。 そしてその内容を元にUIを決めて開発に着手し始めたのですが、しばらくすると「この部分こっちの画面に移動した方がいいんじゃないか…?」という改善案が出てきて仕様を変更することになってしまいました。
幸い、インタビューの内容は無駄にならずに済みましたが、もしもっと大きめの仕様変更だったらせっかく悩んだUIが全て台無しになっていたかもしれません。 作ってみないと気づかないことはたくさんありますし、素早く改善のサイクルを回すためにもプロトタイプを早めに作っておくべきでした。
また、アポイントを取ってユーザーインタビューを行うのは、プロダクトチームとユーザーの間で調整も必要なので時間がかかります。 プロトタイプを早めに作っておけば、ユーザーに聞く前に社内のステークホルダーに意見を聞くこともできたので、もっと早く改善を回せたかもしれません。
「小さく早く改善のサイクルを回す」というアジャイルの基本が、わかっているつもりで意識できていなかったことに気がつきました。
プロトタイプの重要性は下記の記事でも触れています。是非併せてご覧ください。
まとめ
ユーザーインタビューを行うのは今回が初めてでしたが、ユーザーがプロダクトの一番の理解者であると改めて実感でき、とても良い経験になりました。 何より「ここ直して欲しい！」という声を直接聞くとすぐにでも改善したい気持ちになるので、モチベーションが上がって最高でした。
良いことづくめなので、ユーザーインタビューに参加したことのない方は是非参加してみて欲しいです！
ここまで読んでいただきありがとうございました。
