目次

ユーザーインタビューとは?やり方や設計を例をもとに解説します

本サイトはアフィリエイトプログラムを利用した広告を表示しています

ユーザーインタビューをやることになったけど、どう設計すればいいのか、そもそもユーザーインタビューとは何かが分からないかもしれません。

私は上場企業やスタートアップでプロダクトマネージャとしてウェブサービスやアプリの企画に携わってきました。その中で、課題や解決策の検証などの目的でユーザーインタビューを行ってきました。

この経験を元に、この記事ではユーザーインタビューとは何か、またユーザーインタビューのやり方や設計を例を元に解説します。ユーザーインタビューを行うときの参考になればうれしいです。

この記事で対象としている読者の方

この記事はプロダクトを開発する上でユーザーインタビューをする方を対象としています。とくにエンジニアやデザイナー、プロダクトマネージャの方で、実務経験が1〜3年目くらいの方を想定しています。

著者
Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

スポンサーリンク

ユーザーインタビューとは

ユーザーインタビューとは、プロダクトの仮説を検証することを目的としたユーザーとの対話のことをいいます。ユーザーインタビューは、プロダクト開発においてもっとも重要なプロセスといえます。なぜなら、プロダクトのアイデアを出した段階では、そのほとんどが仮説で成り立っているからです。

開発に入るまでにアイデアの仮説を検証しないと、ニーズのないプロダクトをつくってしまうかもしれません。あるいは、ニーズはあるのに解決策がよくないこともあります。こんな失敗はできるだけ避けたいところです。

ユーザーインタビューは失敗する可能性を減らす

こういった失敗を減らすのがユーザーインタビューです。ユーザーと対話して、仮説について学んで検証することで仮説をなくします。ニーズがあること、解決策が問題ないことなどを検証した上で開発に入ることで、失敗する可能性を限りなく減らすことができます。

仮説の検証は、アイデアを出したときにはじまり、プロダクトが役目を終えるまで一生続きます。ユーザーインタビューによる仮説検証の繰り返しこそがプロダクト開発ともいえます。

ユーザーインタビューの目的

ユーザーインタビューの目的は、ユーザーとの対話をとおしてプロダクトについて学び、仮説を検証することです。プロダクトにはいろんな仮説があります。仮説を仮説のままにして開発すると、ユーザーに使ってもらえないプロダクトになるかもしれません。

ここでひとつ例を見てみます。

例:子育て中の親のためのレシピ共有サービス

たとえば、子育て中の親のためのレシピ共有サービスについて考えてみます。このプロダクトは忙しい親のために、「栄養のあるご飯をかんたんにつくれるレシピを閲覧できる」というコンセプトのサービスです。

このアイデアの前提として、「ユーザーはおいしい料理をつくりたいと思っている」という仮説があります。この仮説を検証しないと、このサービスが成功することは難しいでしょう。

「なに当たり前のことを言っているんだろう。おいしい料理はみんなつくりたいはず」と思うかもしれません。ただ、子育て中で忙しいユーザーは、そもそも料理自体をしたくないかもしれません。

献立を決めて材料を買い、料理して盛りつけ、片づけまでやる。子育て中の親には、レシピ共有サービスより宅食サービスの方がよりニーズに合致しているかもしれません。

スポンサーリンク

ユーザーインタビューで得られること

ユーザーと対話することでしか気づけなかったこのような学びを、ユーザーインタビューをとおして得られます。アイデアを出したら、そのアイデアの中にある仮説を整理します。

ユーザーとの対話をとおして、本当にそのアイデアが求められているかを学びます。このような仮説に対する学びを得るのが、ユーザーインタビューの目的です。

まとめ:ユーザーインタビューの目的

ウェブサービスやアプリをつくっても、使われないことがよくあります。機能的には十分だったり、とてもきれいで使いやすいものだったとしても、です。

この失敗の多くは、プロダクトが解決しようとしている課題をユーザーが抱えていなかったり、課題をもっていたとしてもその解決策がよくなかったりするから、というのが原因です。

課題をユーザーが抱えているかどうか、解決策に問題はないかどうか。こういったことを検証するのがユーザーインタビューです。ユーザーインタビューをすることで、ユーザーについて学び、課題や解決策を検証することができます。

ユーザーインタビューの種類

ここまででユーザーインタビューとはなにか、その目的について書いてきました。このユーザーインタビューには、3つの種類があります。

ステージ種類目的
CPFプロブレムインタビューユーザーの課題を検証する
PSFソリューションインタビュー課題の解決策を検証する
PCF/PMFプロダクトインタビュー解決策の実現方法を検証する

まずひとつ目がプロブレムインタビューです。これは、「アイデアで解決しようとしている課題をユーザーが本当に抱えているのか?」ということを検証するインタビューです。Customer Problem Fitのステージで行います。

次に行うのがソリューションインタビューです。これはユーザーの課題をどう解決するかという解決策を検証するインタビューです。Problem Solution Fitのステージで行います。

最後に行うのがプロダクトインタビューで、解決策をどう機能として提供するかを検証します。Product Customer Fit、Product Market Fitの段階で行います。

インタビューが進むにつれてより具体的なものを用いてインタビューしていきます。プロブレムインタビューでは対話のみで検証しますが、ソリューションインタビューではプロトタイプ、プロダクトインタビューはMVPや実際の製品を用いてインタビューします。

アイデアの段階からひとつひとつ仮説を検証していくことで、失敗しないプロダクトによりはやくたどり着くことができます。

スポンサーリンク

ユーザーインタビューのやり方

では実際のユーザーインタビューのやり方について書いていきます。ユーザーインタビューのプロセスは大きく次の5つになります。

  1. 仮説を整理する
  2. 台本をつくる
  3. インタビューする
  4. 結果を整理する
  5. 仮説を更新する

この5つのプロセスについて、ひとつずつまとめていきます。

1. 仮説を整理する

これまでに書いたとおり、ユーザーインタビューの目的は仮説を検証することです。まずは仮説を整理します。仮説は、重要度と不確実度の二軸でマッピングし、重要かつ不確実な仮説から検証していきます。

ひとつひとつの仮説についてはMVPキャンバスというフレームワークを用いて整理すると、より仮説を検証しやすくなります。仮説の整理方法については、「仮説マトリクスの作り方」をお読みください。

2. 台本をつくる

検証する仮説が決まったら、それを検証するための台本をつくります。インタビューの形式は対話で、時間は30分を目安に行います。効果的なインタビューを行うための進行例を次に示します。

  1. あいさつをする(3分)
  2. ユーザーのプロフィールを確認する(3分)
  3. インタビューの目的を伝える(3分)
  4. 質問する(15分)
  5. ほかのユーザーを紹介してもらう(3分)
  6. おわりのあいさつをする(3分)

質問については、ユーザーの意見を聞くのではなく事実を答えられるようにします。たとえば「ユーザーはおいしい料理をつくりたいと思っている」という仮説について、「ふだんどれくらい料理をしていますか?」と聞くと、自分をよく見せようと多めの回数を答えるかもしれません。それより「過去1週間で何回料理しましたか?」と聞いてみます。

また、ひとつの仮説に対していくつかの角度から質問してみます。「ふだんどれくらい料理をしていますか?」とあわせて「料理をしているときにいちばん楽しいこと、逆にいちばんつらいことはなんですか?」と聞くと、ユーザーが本当に料理をつくりたいかどうかの仮説を確かめることにつながります。

ノートアプリなどに台本を書いたら、何度かシミュレーションをするとよいでしょう。インタビューを繰り返すことで、シミュレーションが必要ないくらい慣れてくると思います。

3. インタビューする

インタビュー当日は、つくった台本をもとにインタビューを進めます。ただ、台本はあくまで台本です。重要なことは仮説を検証することで、台本どおりに進めることではありません。ユーザーの回答のしかたによって質問を変えるなど、柔軟に進めましょう。

たとえば、ある質問に対してユーザーが熱く語ったりすることがあります。その質問はユーザーにとって重要な課題かもしれません。こういった回答をしたときはさらに深掘りしてみます。

深掘りのやりかたとしては、相手の回答の中からキーワードを探します。たとえば「料理をしているときにいちばんつらいことはなんですか?」という質問に対して「料理は食材を洗ったり切ることが一番つらいですね」という回答をしました。

このとき、「食材」「洗ったり」「切ること」「つらい」というキーワードを拾います。つまり「どんな食材を使うと手間がかかりますか?」「どういう洗い方、切り方をするときに手間がかかりますか?」という質問をすることで、ユーザーの料理に対する気持ちを読み取ることができます。

注意しなければならないことは、仮説を補う意見をもらうようユーザーを誘導しないようにします。仮説が棄却されることもユーザーインタビューの重要な役目です。

また、確証バイアスに陥らないようにします。これは自分が正しいと思っている意見にのみ注視してしまう問題です。思っていたことと違う意見を回答こそ学びの機会だととらえ、しっかりとメモしましょう。

スポンサーリンク

4. 結果を整理する

インタビューが終わったら、その場でインタビューのメモを整理します。仮説をMVPキャンバスで整理していたなら、MVPキャンバスに結果や学びを記入します。

5. 仮説を更新する

インタビューをとおして仮説の内容や重要度、不確実度が変わることがあります。そのときは仮説マトリクスやMVPキャンバスを更新し、次のユーザーインタビューに向けた準備をします。

ユーザーの募集方法

ユーザーインタビューで重要なもうひとつのテーマは、「ユーザーをどう募集するか?」です。インタビューの準備をしっかりしても、なかなかユーザーが集まらないこともあります。ここではよいユーザーインタビューを行うためのユーザーの集めかたについて書いていきます。

ユーザーインタビューに適した相手とは

まず、「どういう人がユーザーインタビューに適しているか?」ですが、これはプロダクトが解決しようとしている課題を心の底から解決したいと切望している人です。課題に対して本当に困っていて、お金を払ってでもその課題を解決したい人にユーザーインタビューをすることで、効果的な検証が行えます。

ではどうすればこういったユーザーに出会えるのでしょうか。クラウドソーシングで有償で募集する手もありますが、筆者のおすすめはTwitterです。Twitterはタイムラインをとおしてお互いの気持ちをある程度読み取ることができますし、メッセージ機能でプロダクトへの熱意を伝えつつインタビューをお願いすることができます。

Twitterで募集する

Twitterがいいといっても「アカウントをもっていない」「フォロワーが数人、数十人しかいない」というかもしれません。ただ、これは大きな問題ではありません。本当に課題を解決したいと思っている人は、その課題を解決するためのプロダクトをつくっている方には無償でも協力したくなるものです。

実際に私もフォロワーがすくないときからTwitterでユーザーインタビューの協力をお願いしてきましたし、何度も実施できました。フォロワーがすくない方からインタビューのお願いをされたときも協力したり、ほかのユーザーを紹介したりしました。

集めかたとしては、Twitterの検索機能を使って課題をもっていそうなユーザーを見つけ、メッセージを送ります。もちろん中にはメッセージを受け取ることにネガティブな方もいますので、送り方には気をつけます。

ユーザーインタビューは無償で行う

経験的に、お金を払ってインタビューに答えてくれる方よりも、無償で対応してくれる方のほうがそのアイデアへの熱意が高く、プロダクトのファンになってくれる方は多いです。

無償ということに罪悪感をおぼえるかもしれませんが、その必要はまったくありません。ユーザーの課題を解決するプロダクトをつくろうとしているので、ユーザーにも大きなメリットがありますし、無償であることを了承した上で協力したいと思ってくれていることを忘れてはいけません。

それよりも、必ず価値を届けられるよう努力しユーザーに恩返しをしましょう。

情報発信を習慣にする

プロダクトをつくる上では、開発者がどういう人か、どういう想いでプロダクトをつくっているかを発信するかはとても重要です。まだアイデアが決まっていない状態でも、Twitterやブログのような情報発信ツールを活用して、すこしずつファンをふやしていくと、ユーザーインタビューなどで協力してくれるユーザーをふやすことができます。

もしどうしてもユーザーインタビューの相手が集まらないというときは、私にメッセージをください。私がインタビューを受けますし、ほかのユーザーを紹介できるかもしれません。

また、時間の調整にも思いのほか時間がかかります。これは時間調整ツールを使うことで解決できます。私のおすすめはTimeRexというツールで、無料から使えて十分な機能を利用することができます。

まとめ

プロダクト開発とは、言いかえると仮説を検証するプロセスの繰り返しのことで、この仮説検証にはユーザーインタビューがとても重要や役割を果たします。仮説を整理して検証する仮説を選び、台本を書きます。ユーザーインタビューをとおしてユーザーの課題について理解したら仮説を更新し次のユーザーインタビューにつなげます。

このプロセスを繰り返すことでプロダクトの仮説がなくなっていき、プロダクトが失敗する可能性を減らすことができます。

あわせて読みたい

著者
Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

スポンサーリンク

ブログをはじめよう

技術ブログの始め方を、たくさんの画像で分かりやすく解説しました。これまでブログをやったことがない人でも、エンジニアにとって重要なブログを今日から始められます。

ブログをはじめる