リードトーク

株式会社ヴァル研究所伊藤英明

正しいものを正しくつくるワーキンググループ vol1 -ユーザーの声を受け止める-

2017/６/21

ユーザーインタビューとは何をするのか何がわかる、わからないのか

アジェンダ

• 自己紹介

• はじめに

• ユーザーインタビューとは-HCD、UXDの文脈-DRRの文脈

• まとめ-ユーザーインタビューとは何をするのか-何がわかる、わからないのか

自己紹介

• 株式会社ヴァル研究所Business Development Dept. UXデザイナー

• 自社のメイン商材である の技術をベースにした新規事業開発の仕事をしています

• 経歴的には、デザイナー(プロダクト、UI) →

ユーザビリティエンジニア→ UXデザイナー

自己紹介

• マーケティング/商品企画のためのユーザーインタビューの教科書共著

※ちなみに本を書くきっかけになったのはDevLOVEのイベントでした

はじめに

• ユーザーインタビューの諸手法に関する話はほとんどしません

• DRR(※)のためにユーザーインタビューが必要だな、できるようになりたいな、と思うきっかけになれば

※正しいものを正しくつくる= Do the Right things Right

略してDRR

ユーザーインタビューとは(HCD、UXDの文脈)

「何のためにやるのか？」

• 開発者とユーザーの間にあるギャップを埋める→開発者の視野を広げ、思い込み、ユーザーへの一方的なイメージ・レッテルを無くす

• ニーズの理解→ユーザーの現状や課題、理想とする姿からニーズを知る※「ユーザーにニーズを聞く」ではないので注意

• ユーザーから評価を得る→向かう方向が正しいのかを確認する

D.A.Norman(1986)

Three aspects model

ユーザー開発者

このように使うのがいいに違いない！

このように使うものかな？

製品、システムに対するイメージのギャップ

開発者とユーザーの間にあるギャップ

HCDプロセス

• システムを使いやすくするためにユーザの立場や視点に立って設計を行うための開発プロセス

HCDプロセス

使われる現場を確認

お試し案を作る

何が必要か考える

使えるかをチェック

開発フェーズや目的によって異なる型

• 機会探索型顧客に共感する中で、価値観を理解し、市場機会（製品やサービスの方向性）を発見する

→何を作るべきか

• タスク分析型製品が提供するべき機能・特徴、またはサービスの詳細を検討するため、顧客の活動やそこでの要求を理解する

→どう使ってもらうのがいいのか

• 仮説検証型顧客の特徴や意見、製品やサービスのコンセプト、機能・特徴、操作性など、様々なレベルでの仮説について、それが正しいことを確認し、変更すべき点を特定する

→思ったように使ってもらえるか

開発フェーズや目的によって異なる型

機会探索型→何を作るべきか

タスク分析型→どう使ってもらうのがいいのか

仮説検証型→思ったように使ってもらえるか

ユーザーインタビューとは(DRRの文脈)

「何のためにやるのか？」

• 不分明なWhat、Whyを明らかにする→分かったことを正しく作るため

• 何が価値なのか、という課題仮説を検証する→ユーザーにとっての価値を明らかにするため

共通点はユーザーの理解

• HCD、UXDの文脈開発者とユーザーの間にあるギャップを埋めるニーズの理解ユーザーから評価を得る

• DRRの文脈不分明なWhat、Howを明らかにする何が価値なのか、という課題仮説を検証する

• どちらも、開発を進める上でわからない事があるので「ユーザーに問う」こと

例：こんなことありませんか？

例：こんなことありませんか？

上司「進捗どうですか？」

部下「進捗ダメです。」

上司「どこがダメなの？」

部下「単体テストが遅れています」

上司「どれくらい遅れてるの？」

部下「えーと・・・、0.5日分くらいです」

上司「項目数でいうと？全部で何件？何件進まないといけないの？なんで遅れたの？対策は？なんで早めにアラート上げてくれなかったの？」

部下「え、えーっと・・・」

例：こんなことありませんか？

上司「困ってますか？」

部下「・・・はい。困ってるといえば確かに困って

います。」

もしくは、

「いえ、別に困ってないです。順調です。」

例：こんなことありませんか？

• 「進捗どうですか？」→考えないと答えられない質問整理や解釈のステップがどうしても必要になる

• 「困ってますか？」→深く考えなくても答えられる質問まずは事実を答えればいい

聞きたいことによって質問を使い分ける

• オープンクエスチョン

インタビューとして基本になる聞き方

あえてフォーカスを絞らないことで、ユーザーにとって一番気になっていることを聞けたり、話を広げる効果も

問診の「今日はどうされましたか？」もこれに相当

具体的に確認したいことがあるときは、答えの選択肢を設けた上で聞くこともある

YES/NOで答えられる問いや、利用の期間など数字に置き換えられるもの

• クローズドクエスチョン

聞きたいことによって質問を使い分ける

まとめ：ユーザーインタビューとは何をするのか

• HCD、UXDの文脈開発者とユーザーの間にあるギャップを埋めるニーズの理解ユーザーから評価を得る

• DRRの文脈不分明なWhat、Whyを明らかにする何が価値なのか、という課題仮説を検証する

• どちらも、開発を進める上でわからない事があるので「ユーザーに問う」こと

まとめ：何がわかる、わからないのか

• ユーザーインタビューは言わば「事情聴取」→ある事柄についてのユーザーの印象、理解、解釈を確かめる手段

※「ユーザーの声聞くべからず」と言われる所以

• 「現場検証」で「状況証拠」を得るためには行動観察の方が向いている→ユーザーインタビューでは「ユーザーが無意識にやっていること」はわからない

→課題にフォーカスではなく、ある事柄についてのユーザーの「関わり」を聞くことでわかることはある

顕在的意識と潜在的意識

顕在的意識

人が自分で言葉にできる

問いかけることで、言語化できる

潜在的意識

引き出すことで⾔葉にできる

聞き⽅によっては意識を刺激して引き出せる

無意識の領域

⾃分では気づいておらず、言葉にできない

無意識のため言葉として聞き出すことは困難

参考：やってみたくなったら

• ユーザーインタビューの計画、実施テンプレートhttps://www.slideshare.net/userinterview/interview-

template-ver100

• 計画〜準備〜実施〜考察時のチェックリストhttps://www.slideshare.net/userinterview/interview-

checklist-48529142

ご静聴ありがとうございました。