プロダクト開発に役立てるユーザインタビューの取り組み

Tatsuya Izumori

はじめに

こんにちは！アルダグラムでエンジニアリングマネージャーをしているizmrです。
当記事では、私たちが日々どのようにユーザインタビューを実施しているか、ユーザインタビューを実施する際にはどのような点に注意しているか、についてお話したいと思います。なお、当社のプロダクトはB2B SaaSなので、ユーザインタビューもそれを前提としています。

背景

当社のプロダクト開発ではユーザインタビューを重視しており、新しい機能を検討する際には必ず事前にユーザインタビューを実施しています。
ちなみに、私自身もそうですが、当社ではエンジニアがユーザインタビューを行うことがあります。エンジニアがユーザインタビューに参加してドメイン知識を深めることは色々なメリットがあると考えています。
例えば、LayerX CPOの榎本さんが公開している「CPOが開発する覚悟」では、「見積もりができる＋アウトカムがわかる＝コスパの良い落とし所がわかる」とありますが、まさにその通りと感じます。

なぜユーザインタビューを重視するか

ユーザインタビューを重視する理由は以下の3つです。

①ニーズの無いプロダクトを作るリスクを減らすため

トヨタ生産方式では製造プロセスにおける「7つのムダ」を定義されていますが、中でも「つくりすぎのムダ」が一番最悪のムダと言われています。
ニーズの無いプロダクトを作ってしまうことは、この「つくりすぎのムダ」を生じさせます。
開発コストが損失になるだけでなく、価値を生まない機能をメンテナンスし続ける負債を抱えることになるので、リソースが常に不足しているスタートアップでは絶対に避けたい事態です。
そのため、ユーザインタビューで「お客様にとっての深刻なニーズ」をシビアに見極める必要があります。

②優先度を立てて「やらないこと」を決めるため

解決したい課題は山程ありますが、すべてを同時に解決できないので、優先度を立てる必要があります。どの課題から解決するべきかを判断するためには、たくさんの顧客の声を聞き、最もインパクトの大きな課題を見極める必要があります。

③仕様やUIを検討する際にあるべきユーザ体験を理解するため

具体的な仕様やUIを詰める段階では、エッジケースも含めて細かい論点まで議論します。その際の判断基準は常に「顧客が使いたい仕様かどうか」であり、顧客理解なく意思決定できません。顧客イメージがふわっとしてる中で仕様を決めても、開発者としても納得感がないと思います。
そういった意味でもユーザインタビューで顧客理解を深めることが重要です。

ユーザインタビューで何を見極めるか

ユーザインタビューでは、開発予定の機能イメージを提示する前に、以下の点を確認します。

  • Q. 今、顧客が抱えている課題は何か？

  • Q. なぜ、その課題が発生するか？

  • Q. その課題を解決するために、今どのように対応しているか？（代替手段の確認）

  • Q. その課題解決にどの程度コストや労力を払っているか？

上記を確認した上で、改めて開発予定の機能イメージを提示し、以下の点を確認します。

  • Q. 提示した機能で課題を解決できるイメージを持てたか？

    • 解決できるイメージを持てる場合

      • Q. 具体的にどのように活用したいか？

      • Q. 社内で利用するにあたってハードルになりそうな問題は何か？

      • Q. 実際に利用するにあたって足りない機能はあるか？

    • 解決できるイメージを持てない場合

      • Q. 理想との差分はどこか？

特に「その課題解決にどの程度コストや労力を払っているか」を確認することは重要です。これにより、課題解決に対する顧客の本気度を確認しています。もし現時点でその課題解決にコストも労力も払っていないなら、その課題は実際には「特に重要ではない課題」の可能性があります。

ユーザインタビューで注意すること

実際にユーザインタビューを行うにあたって、いくつか気をつけたいことがあります。

顧客に先入観を与えない

機能イメージを提示する前に現状確認についての質問をしていますが、これは顧客に先入観を与えないためです。
例えば、事前に機能イメージを提示してから「今、何にお困りですか？」と聞くと、「この機能でこういう問題を解決したい」と、機能ありきの回答になることがあります。これでは、本当に知りたい「今、何にお困りか」がわからなくなります。
できるだけ顧客のありのままの状況を理解したいので、機能イメージの提示は後回しにしています。

少なくとも10社以上の顧客に会う

複数のお客様の声を聞くと、「ほぼ全員が求める機能」と「一部の顧客だけ求める機能」の違いが分かってきます。顧客に会う数が少ないと、汎用的なニーズと個別のニーズの区別がつかないことがあります。
最低でも10社の顧客と会うことで、ニーズの傾向が見えてきます。例えば、同じ業界の顧客であっても、組織規模の違いで求められる機能が大きく変わることがあります。

機能イメージは「ちょっと足りない」程度に抑える

機能を考える際、色々なユースケースを想定して仕様を盛りたくなりますが、「ちょっと足りないかな」と感じる程度の必要最小限の範囲に留めます。
以下のような理由があります。

  • 作り込みに時間をかけるより先に顧客に会った方が最終的に妥当な仕様が得られるため

  • 作り込み過ぎると、逆に先入観を生じて回答の幅が狭まるため

  • 「機能イメージには無かったけど、追加でこれが欲しい！」という意見を得るため

特に最後の理由が重要です。
本当にニーズのある機能であれば、「これが欲しい！」と必ず言われます。
例えば、10社ヒアリングして、その内8社から類似する要望をいただいたとすれば、それは汎用的かつ重要なニーズである可能性が高いです。
逆に、開発者が「これはニーズありそうだな」と思った仕様でも、実際には誰からも求められないことがあります。これも初めから仕様に盛り込んでしまうとニーズの有無を見極めづらくなるので、機能イメージからあえて省いた上で「顧客の方から求められるかどうか」を確かめると、本当に必要なニーズかどうかを検証できます。

最後に

当社は、世界中の「現場」に対して生産性の課題を解決するB2B SaaS「KANNA」を開発・運用しています。「現場」という響きからドメスティックなサービスを連想するかもしれませんが、実際にはグローバル展開に適した事業特性を持ち、市場規模も大きいです。

グローバル規模の大きな課題を解決したい方は、ぜひ我々と一緒に働いてください！
https://herp.careers/v1/aldagram0508

エントランスBookはこちら！
https://poised-ceres-9a8.notion.site/Engineer-Entrance-book-a8f0fb8d1bb44306a6e33aacc8f8c32d

いいなと思ったら応援しよう！