アイデアの仮説を検証する『ユーザインタビュー』のやりかた、ユーザの集めかた

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

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

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

ユーザインタビューとは

ユーザインタビューとは、プロダクトの仮説を検証することを目的としたユーザとの対話のことをいいます。

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

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

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

こういった失敗を減らすのがユーザインタビューです。

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

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

ユーザインタビューさえすればプロダクトは間違いなく成功する、とはいえませんが、失敗する可能性を減らすことはできます。

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

ユーザインタビューの目的は、ユーザとの対話をとおしてプロダクトについて学び、仮説を検証することです。

プロダクトにはいろんな仮説があります。仮説を仮説のままにして開発すると、ユーザに使ってもらえないプロダクトになるかもしれません。

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

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

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

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

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

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

ユーザと対話して、ユーザの本質的な課題を理解することで、プロダクトが失敗する可能性を減らすことができます。

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

ユーザと対話することでしか気づけなかったこのような学びを、ユーザインタビューをとおして得られます。

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

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

ここまででユーザインタビューとはなにか、その目的について書いてきました。このユーザインタビューには、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

Webエンジニア&プロダクトマネージャ。 スタートアップ創業→上場企業など5社で20以上のプロダクトをリリース。 共著に『現場で使えるRuby on Rails 5』。

プロフィールをみる
記事を読んだことを共有しよう

あなたがどんなことに興味をもっているかをフォロワーに知ってもらうきっかけになります

ツイート画面をひらく
関連記事関連書籍
現場で使えるRuby on Rails 5

共著で「現場で使えるRuby on Rails 5(マイナビ出版)」を出版しました。

Amazonでみる
product-development.io
エンジニアのための技術情報サイト
© product-development.io