「ユーザビリティエンジニアリング(第2版)」無料サンプル版（第2章全文）

iii　　　はしがき

はしがき

　本書は『ユーザビリティエンジニアリング』（オーム社刊）の第 2版です。2005 年発行の初版は、その実践的な内容が好評を博し、8年間で 9刷まで増刷を重ねる「ロングセラー」となりました。

　そして、昨年、第 2版を執筆することが決まったのですが、その時に、私は製品やサービスのバージョンアップと同じようなリスクがあると感じました。それは、付加的な機能や直近の先端技術をてんこ盛りにする一方、本質的な価値をもたらす機能や特徴を不用意に変更 / 削除してしまうと、ユーザ（読者）から「前の方がよかった」と言われることです。

　そこで、今回は以下の 3点を念頭に置いて執筆を進めました。

◎内容や特徴の継承：初版の内容の 7割は、ほぼそのまま引き継いでいます。そのうえで、同じくらいの分量の新たなコンテンツを追加しました。また、「謝礼の金額まで書いてある」「現実的な落としどころを書いてある」と好評だった実践的な内容や、平易で読みやすい文体を改めて心掛けました。

◎変化への適応：初版を執筆した 2004 年頃は、まだ日本ではユーザエクスペリエンスという言葉さえほとんど知られていませんでした。iPhone は存在しておらず、アジャイル開発やリーンスタートアップ（顧客開発モデル）の潮流は極々小さいものでした。それから 10年が経ち、私たちを取り巻く環境は大きく変化しています。本書では 2010 年代の製品やサービス開発に適応する内容を目指しました。

iv はしがき

◎読書体験の向上：読みやすさのために段落間に空白行を入れました。また、1つの章の分量を 20～30 ページ程度に抑えたので気軽に読み進められるでしょう。ただ、章の数が増えて相互の関連性が把握しづらくなるといけないので、全体を大きく三部構成として、それをページ右端の「ツメ（タブ）」で示すようにしました。また、イラストレータの中西隆浩氏の手による挿絵の数々は、内容の理解を深めるとともに読む楽しさを提供してくれます。

　「ユーザビリティについて学びたいときに、まず最初に手に取るべき 1冊」――これは初版に対する書評の 1つです。その価値を継承・拡大し、この第 2版もUX / ユーザビリティ分野の定番本として、今後も長く読み継がれることを願っています。

　2014 年 1月

著者しるす　

v　　　目　次

目　　次

まえがき　　iii

Introduction

Chapter 1　ユーザ中心設計概論

1-1　ユーザビリティ 2

①使いモノにならない！／②ユーザビリティ≠使いやすさ／③ユーザビリティの定義

1-2　失敗の原因 6

①ゴムのユーザ／②コンテキスト／③点と線

1-3　ユーザエクスペリエンス 12

①ユーザビリティを超えて／②エクスペリエンスの価値／③UXの構造

1-4　ユーザ中心設計 18

①UCDのプロセス／②反復デザイン

Part 1 調査・分析

Chapter 2　インタビュー法

2-1　ユーザの声聞くべからず 24

①ユーザの声の神話／②アンケートの神話／③グルインの神話

2-2　ユーザに弟子入り 31

①師匠と弟子／②弟子の心得

Chapter 3　インタビューの実践

3-1　リクルート 44

①師匠の条件／②師匠の人数／③師匠の探し方

vi 目　次

3-2　インタビューの準備 47

①インタビューの設計／②場所・機材・人員

3-3　インタビューの進行 53

①インタビュー冒頭／②インタビュー前半／③インタビュー中盤／④インタビュー終盤

Chapter 4　データ分析法

4-1　質的データ分析 62

①質的データ／②KJ法／③分析例

4-2　ペルソナ 73

①仮想のユーザ／②ペルソナの作り方／③ペルソナの使い方

Part 2 設　計

Chapter 5　発想法

5-1　ブレインストーミング 84

①基本ルール／②魔法の言葉／③収束方法

5-2　キャンバス 89

①ビジネスモデルキャンバス／②リーンキャンバス

5-3　シナリオ 93

①シナリオに基づく設計／②シナリオ発想法／③シナリオの視覚化

Chapter 6　プロトタイプ

6-1　プロトタイプの原則 100

①プロトタイプ≠試作品／②ローファイとハイファイ／③ Tプロトタイプ／④オズの魔法使い

6-2　プロトタイプの制作 108

①プロトタイプ制作ツール／②プロトタイプ制作のポイント／③プロトタイプの制作者／④ペーパープロトタイプ／⑤パワーポイントの利用

vii　　　目　次

6-3　カードソート 121

①階層構造の設計／②クローズド・カードソート／③オープン・カードソート

Part 3 評　価

Chapter 7　ユーザビリティ評価法

7-1　評価とは 128

①総括的評価と形成的評価／②実践的手法と分析的手法

7-2　ヒューリスティック評価 � 133

①インスペクション／② 10ヒューリスティックス／③ヒューリスティック評価の実施手順／④ヒューリスティック評価の限界

7-3　認知的ウォークスルー � 150

①探査学習／②認知的ウォークスルーの実施手順／③認知的ウォークスルーの分析例

Chapter 8　ユーザテスト

8-1　ユーザテストとは 156

①ユーザテスト体験記／②ユーザテストの概要

8-2　代表的なテスト手法 159

①思考発話法／②回顧法／③パフォーマンス測定

8-3　ユーザテストの基本理論 � 169

①ユーザビリティの論理学／②ユーザテストの被験者数／③反復デザインの効果

8-4　プライバシーと倫理 � 176

①個人情報保護／②倫理的責任

Chapter 9　ユーザテストの準備

9-1　テスト計画 � 180

①ユーザテストのスケジュール／②ユーザテストの時間割／③ユーザテストの費用

viii 目　次

9-2　リクルート � 186

①リクルート条件の決定／②スクリーナの作成／③リクルートの実施

9-3　テスト設計 � 195

①タスクの設計／②インタビューガイドの作成／③実査ツールの準備／④パイロットテストの実施

Chapter 10　ユーザテストの実施

10-1　テスト会場の設営 210

①テスト会場／②テスト機材／③録画方法

10-2　ユーザテストの進行 �220

①受　付／②イントロ／③事前インタビュー／④事前説明／⑤タスク実行観察／⑥事後インタビュー／⑦エンディング

10-3　ユーザテストの見学� �230

①“目撃者”を増やす／②見学マナー／③観察テクニック

Chapter 11　分析と再設計

11-1　ユーザテストの分析� �236

①テスト記録の作成／②データの分析／③レポートの作成

11-2　再設計�� 247

①問題解決ブレスト／②問題解決の原則

Ending

Chapter 12　ユーザ中心設計活動

12-1　UCDの始め方 � �254

①成熟度モデル／②テスト・ファースト／③スカンクワークのすゝめ

参照文献 � ��259

索　　引 266

ix　　　目　次

■UXとは？� 16

■UXの国際規格� 21

■質問は1つだけ用意する� 38

■もつれた糸を解きほぐす� 40

■こんなので役に立つの？� 59

■一泊三日� 67

■コーディング≠プログラミング� 72

■ペルソナ重み付け機能一覧� 79

■偽のペルソナ� 81

■発想ゲーム� 97

■完全なプロトタイプ� 103

■オズの魔法使いの使いみち� 106

■UI 設計の秘伝書� 154

■共同発見法� 162

■ユーザビリティ・アンケート調査法� 167

■謝礼の相場� 185

■ショーが始まらない� 194

■タスクの本質� 200

■書画カメラ� 218

■インタビュー“マル秘”テクニック� 228

■ユーザは本当に「お得」がお好き？� 234

■レポートよりも対話を� 246

■小さな変更、大きな成果� 252

■調査と評価� 258

Column

Part 1　調査・分析

Chapter 2

インタビュー法

24 Chapter 2　インタビュー法

ユーザの声聞くべからず

❶ ユーザの声の神話

　UCD（ユーザ中心設計）の概念を非常に単純に言えば「靴に足を合わせるのではなく、足に合う靴を作る」ということになります。そう聞くと、「そんなことは当たり前ではないか」「その程度のことは既に実行している」と感じる人が多いかもしれません。

　確かに、マーケティングや経営の分野でも「マーケット・イン」や「アウトサイド・イン」といった類似した概念がありますし、従来の製品開発でもユーザニーズの把握は重視されてきました。皆さんも要求獲得のためにユーザからヒアリングしたり、お客様アンケートやグループインタビューを実施したりした経験があるでしょう。

　ところが、それらの調査で得られた「この部分をこんな風に変更して欲しい」「こんな機能があれば便利だと思う」といった“ユーザの声”に基づいて製品を改善しても、あまり満足してもらえなかったり、せっかくの新機能がほとんど利用されなかったりといった結果に終わることは少なくありません。

　「ユーザは気まぐれだから…」と責任を転嫁しても問題は解決しません。そもそも「ユーザの声に応えればユーザは満足する」という前提が間違っているのです。驚くなかれ、UCDの第一原則とは「ユーザの声聞くべからず」なのです。

ａユーザの声の正体　ユーザの声の背後には必ず具体的な体験――その多くは何かをしようとしたときに「上手くできなかった」「手間取った」「イライラした」などのネガティブな体験――があります。

　ユーザの声とは、そういった体験をユーザ自身が分析（多くの場合“素人分

-12

252-1 ユーザの声聞くべからず

IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

析”）した結果に過ぎません。そもそも正しく分析されたという保証はありませんし、それらを改めて分析しても新たな発見は得られません。

　一方、個別のユーザの体験はまだ分析されていない生のデータなので、それを設計者の手で慎重に分析すれば、ユーザ本人でさえ気付いていない“暗黙”の要求まで探索することができます。

　ユーザの声を聞くというのは、極論すれば単なる“ユーザ任せ”に過ぎません。ユーザから出された「○○が欲しい」といった明示的な要求に応えるだけでは不十分です。ユーザ自身が気付いていないような暗黙の要求まで満たしてこそ、プロの設計者としての存在価値があるのです。

ａプロフェッショナルの条件　私たち設計者の役割とはユーザに解決案を提案することです。ユーザから提案してもらって、それを持ち帰るだけならば、それはプロフェッショナルの仕事とはいえないでしょう。

　プロフェッショナルの代表例として、仮に医者を取り上げてみましょう。一般に医者は患者の言うことを決して“鵜呑み”にはしません。もし患者が「私

ユーザの声の正体ユーザの声を「V」、ユーザの体験を「x」とすればその関係は V=f（x）と表せる。ユーザの声とは、自分の体験をユーザ自身で分析した結果に過ぎない。


は胃がんだと思うので手術してください」と訴えたとしても、医者は慎重に診察して正確な診断を下してから、治療法（解決案）を提案するはずです。これは医者に限らず、弁護士、弁理士、経営コンサルタント等々のすべてのプロフェッショナルに共通します。クライアントの要求に応える程度ではプロとはいえないのです。

　同じように、私たち設計者も（素人の）ユーザでは全く想像もつかないような解決案を提案してこそプロといえるでしょう。そのためには、ユーザの声ではなくユーザの体験に目と耳を傾けるべきなのです。

❷ アンケートの神話

　「調査」と聞いて、まず最初に思い浮かぶのは『アンケート調査（survey）』かもしれません。飲食店の店頭に設置されたお客様アンケートから公的機関が行う世論調査まで日々様々なアンケート調査が実施されていますし、テレビや新聞などを通じてそうした調査結果を目にする機会も多いです。確かに、アンケートは“超”定番の調査手法ですが、ユーザの体験を把握するという目的には適していません。

ａ量と質　調査手法は『量的調査（Quantitative research）』と『質的調査（Qualitative research）』に分けられます。

プロフェッショナルの条件医者は患者の言うことを鵜呑みにしない。慎重に診察して診断を下す。


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

　量的調査は数値データやカテゴリデータを収集し、それを演算・集計して数表やグラフなどで結果を表します。量的調査は原則としてある集団の全体像を推定するために行います。二千人分程度のデータから国民（有権者）全体の傾向を統計的に推定する「世論調査」はその代表例です。

　一方、質的調査はインタビューや観察といった数値化できないデータを扱います。KJ法などを使ってデータを分類・構造化して、文章や図で結果を表します。通常、質的調査では統計的な精度は求めません。たとえ 1つしか事例がなくても、そこから深い洞察が得られるのであれば、その調査には価値があるといえます。

　アンケートは量的調査の手法です*1。自社製品に対するユーザ全体の満足度などを調べるためには適した手法ですが、個々のユーザの個別の体験をこと細かく調べるための手法ではありません。

ａ生成と検証　調査の目的という観点から分類すると『生成的調査（Generative research）』と『検証的調査（Evaluative research）』に分けることもできます。

　例えば、自社製品のバージョンアップを企画していて、これまでにないユニークな新機能を追加したいと考えているとしましょう。そんな斬新な機能のアイデアを発想するために調査を行うとすれば、それは生成的調査です。そして、いくつかのアイデアの中からどれを採用するか決めるために調査を行うとすれば、それは検証的調査です。

　アンケートは検証的調査の手法です。原則としてユーザは事前に定義された質問と選択肢の範囲内で回答します。しかし、私たちはユーザ本人でさえ気付いていないような潜在的なニーズを探索している段階です。どうやって「誰も気付いていないニーズ」に関する質問と選択肢を用意できるというのでしょうか。

　　　　　　　　　　　　　　＊ 1　�アンケートには「自由回答（文字回答）」という質的なデータタイプもありますが、アフターコーディングし

てカテゴリデータとして集計するか、そのままリスト化して補助的データとして使用することが多いです。


　もし、そのような目的をアンケートで果たそうとするのであれば、「あなたが気付いていないような潜在的なニーズがあればご記入ください」という自由回答形式の質問を用意することになりますが、この質問は明らかに論理的に矛盾しており回答不可能です。

❸ グルインの神話

　座談会形式のインタビューを『フォーカス・グループインタビュー（Focus Group Interview）』（略してグルイン）といいます。グルインでは、調査目的に応じて、性別、年代、経験やライフスタイルなどで切り分けたグループを設定します。そのグループ毎に、 1度に 6名前後の参加者に集まってもらい、円卓を囲んだ座談会を開催します。座談会にはモデレータ（司会者）が同席して、参加者にテーマを提示したり、インタビューの進行を管理したりします。

　マーケティングでは質的調査の定番手法としてグルインが多く用いられてきましたが、アンケートと同じく、ユーザの体験を把握するという目的には適していません。

ａグルインは“ユーザの声”が中心　グルインのメインコンテンツは参加者同士のディスカッションです。モデレータがテーマを投げかけ、ある参加者がテーマに対して「私はこう思う」と発言すると、他の参加者がその発言に対して「私もそう思う。○○という理由

アンケート調査アンケートは検証向き。アイデア生成には向いていない。


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

で」または「私は××という理由で反対」といった感じで賛否両論が巻き起こります。

　この議論の過程を記録・分析することで、テーマに対する多面的な見方と、それがどのように相互に影響を与えながら結論に至るのかが明らかになります

（ただし米国と異なり日本人はディスカッション下手なので、実際に日本で行われているグルインは集団面接に近いものが多いです）。

　つまり、グルインで得られる情報の多くは“ユーザの声”になります。もちろん、それを補足するような断片的な体験も含まれることはありますが、発言の多くは「ここが不便だと思う」「こんな機能が欲しい」といったものになります。しかし、こういった情報が当てにならないことは前述しました。

ａ 1 人当たり 16分

　もちろん、モデレータが工夫すれば、ユーザの声ではなく具体的な体験を引き出すことは可能でしょう。しかし、1人ずつの体験談を詳細に引き出そうとすると、今度はグループであることがマイナス要因になります。

　まず、1人当たりの発言時間が短くなります。グルインは 1グループ 6名で2 時間というのが標準的です。2時間の中には、モデレータが話している場面や無駄な時間も含まれるので、2時間全部が発言に費やせるわけではありませ

グループインタビューグルインは意見が中心のうえ、他の参加者の影響を受ける。

私は○○のほうがよかったと思うけど... 僕は△△のほうが

よかったと思う。私も...

僕は...


ん。どんなに効率のよいグルインでも参加者が発言している時間は全体の80％以下でしょう。そうすると、1人当たりの発言時間は「2時間×80％÷ 6人＝約 16 分」に過ぎなくなります。

　これでは、簡単な体験談を 1つ話すのが精一杯です。そもそも、参加者 1人ずつに順番に話を聞いていくのならば、わざわざ集まってもらう必要はありません。

ａ脚色されたストーリー　また、グルインでは他の参加者の発言を聞いているうちに、自らの体験を加工してしまいがちです。グルインは、グループダイナミズムを前提としており、参加者の発言は相互に影響を与えます。そのため、他の人の話を聞いているうちに「そういえば、そんなこともあったな」と思うと、そのトピックを自分の体験談に追加することがあります。

　これは、決して悪気があってやっているのではありません。私たちは、人に話をする時には、なるべく手短に、わかりやすく、同じような話題はまとめて話すようにトレーニングされているからです。つまり“要点”を伝えようとするのです。“大人”の社会では、ダラダラと出来事を羅列するのは、あまり優れたコミュニケーション方法ではありません。

　それにグルインでは集団の中で発言するので、参加者は普段よりも上手く話をしようとします。例えば、他の人の話に刺激を受けて自分の話をバージョンアップしたり、複数の話題を要領よくまとめて要点を絞った話にしたりして、参加者は嘘にならない範囲で体験を“脚色”するのです。ただ、このような状況で語られた体験は真実と乖離してしまうのは想像に難くないでしょう。

　グルインの達人といわれる人たちは、参加者の“本音”を引き出すのが上手いといわれています。これは、主にユーザの“声”に基づくマーケティングには重要なことですが、ユーザの“体験”に基づくユーザ中心設計にはあまり役に立ちません。なぜなら、悪い利用体験に対するユーザの本音は「何となく腹立たしい」だけだからです。

312-2 ユーザに弟子入り

IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

ユーザに弟子入り

❶ 師匠と弟子

　アンケートやグルインといった定番手法は使わない――。では、どうするのか？　それが「師匠と弟子（Master/apprentice）」という人間関係モデルに基づいたユニークな調査手法『コンテクスチュアル・インクワイアリー

（Contextual Inquiry*2）』です。

　この手法ではインタビューアを弟子、ユーザを師匠と見立てて、師匠の体験を弟子に“継承”します。基本プロセスは以下のようになります。

　1．インタビューアはユーザに“弟子入り”する。　2．ユーザは仕事を見せながら説明する。　3．インタビューアは、不明な点があればその場でどんどん質問する。　4．一通り話を聞いたら、インタビューアは理解した内容をユーザに話して、

間違っていないかどうかチェックしてもらう。

2

　　　　　　　　　　　　　　＊2　�Contextual�Inquiry については様々な訳が可能です。文脈における質問、文脈的質問、文脈的調査、現地調査、

現地現物、etc...。そのため本書では、敢えてカタカナ表示にとどめました。

師匠と弟子ユーザが師匠、インタビューアが弟子。インタビューアはユーザに弟子入りするつもりでインタビューする。

-2


　最大の特徴は、師匠（ユーザ）が手取り足取り教えるわけではないという点です。ユーザは自分の仕事は熟知していますが、それを教えるプロではありません。そこで、弟子（インタビューア）が「観察と質問」を通じて言語化されない情報も含めて自力で師匠から学び取るのです。

ａ弟子入り風インタビュー　オリジナルのコンテクスチュアル・インクワイアリーでは、インタビューアは「仕事をしている場所」で「仕事をしている人」に「仕事をしてもらいながら」、そのすぐ横で話を聞きます。当然ながらユーザの職場や家庭を訪問することが大前提です。

　しかし、実際には訪問調査を実施できない場合が少なくありません。例えば、事務機器の顧客を訪問しようとしても、営業部門が難色を示すことがあります。万一、トラブルが起きて顧客を失ったり、インタビューの中で顧客から出された要求に営業部門が対応しないといけない事態になったりするのではないかと心配するからです（それ以前に、最近のオフィスはセキュリティ管理が厳しく、部外者はオフィスに立ち入ることさえ困難になっています）。

　また、一般の調査協力者を探す場合でも、家庭訪問を第一条件にすると該当者が少なくなりがちです。その結果、他の重要な選定条件で大幅に妥協せざるを得なくなって“師匠の質”に問題が生じてしまうとすれば元も子もありません。

　そういう場合は、師匠と弟子モデルを取り入れたインタビューを実施します。ユーザには調査会場に来てもらったり、外部会場（喫茶店など）で会ったりします。その時に、普段使っている製品を持ってきてもらったり、こちらで同種の製品を用意したり、ホワイトボードや白い紙を用意して絵を描きながら話してもらったりして、なるべくユーザが師匠役を演じやすいようにします。

　もちろん、現場訪問に勝る調査はありません。調査を企画するならば、まず訪問調査を検討すべきです。しかし、訪問できないことを「調査をしない言い訳」にしてはいけません。訪問できなくても、必ず他の手段で直接ユーザと会いましょう。通常、それでも十分な洞察は得られます。


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

❷ 弟子の心得

　師匠と弟子方式のインタビューは 4ステップで構成されます。

　１．教えを請う：まず「何を教えて欲しいのか」をユーザに伝えます。話題を特定のテーマに絞っていくので「フォーカスを当てる」ともいいます。インタビューの冒頭部分では「よく使うウェブサイト」や「普段の業務」など比較的幅広い話題から話を始めてもらいます。そして、徐々に特定のトピックに絞って話を掘り下げて行きます。

　２．根掘り葉掘り：インタビューアは、単にユーザの話を聞いて帰って来るのではありません。ユーザの話の内容を理解できて、初めて“弟子入り”したといえるのです。そのためには、ユーザの行動や説明に少しでも不明な部分があれば、インタビューアは「根掘り葉掘り」質問しなければなりません。曖昧なままだと、インタビューアは自分の“憶測”でユーザの行動を解釈してしまいます。師匠と弟子方式のインタビューでは幅広く話を聞くよりも、完全に内容を理解する方が重要です。

　３．確認する：インタビューアは、フォーカスを当てた話題について一通り理解できたと思ったら、その理解した内容をユーザに話して確認してもらいます。もし誤解している部分があれば、ユーザはその点を指摘してくれ

弟子入りの基本フロー師匠と弟子方式のインタビューは、教えを乞う→根掘り葉掘り→確認する→フォーカスを移動するという手順で実施する。

教えを乞う

根掘り葉掘り

確認する

フォーカスを移動する

教えを乞う

根掘り葉掘り

確認する


教えを乞う

根掘り葉掘り

確認する



ますし、確認作業がきっかけとなって関連情報を追加してくれることもあります。

　４．フォーカスを移動する：話が一段落したら、速やかにフォーカスを移動します。確認済みの話題について「他に何かありませんか？」と粘るのは時間の無駄なだけでなく、せっかく構築した師匠と弟子という人間関係モデルを損ねてしまいます。

ａ気難しい師匠　残念ながらユーザは教えるのが下手です。例えれば「無口で気難しい師匠」――。もちろん、それは、頑固であるとか意地悪であるとかといった個々のユーザの性格の問題ではありません。一般にユーザには困った習性があるのです。

　まず、ユーザは話を要約します。例えば「休暇はどうでしたか？」と聞かれると、「家族と東京ディズニーランドに二泊三日で行きました。子供は大喜びで、大人も結構楽しみました」などと体験を“要約”して回答するのが普通です。まさか、交通経路、利用したアトラクションとその待ち時間、レストランのメニュー、買ったおみやげ等々を事細かに説明しませんよね。そんな風に出来事を羅列するのは“幼い子供”の行動だからです。

　また、ユーザの話は不完全です。体験の途中部分から話を始めたり、途中を飛ばしたり、話の順序を入れ替えたりします。また、本当は共同で作業をしている人がいるのに、その人のことに触れなかったり、作業の前後で発生する関連作業についての話を省略したりします。

　さらに、ユーザは例外に触れようとしません。ほとんどのユーザは公式の作業手順についてのみ話します。しかし、どんな作業にも、例外処理はあります。場合によっては、例外の方が重要であることも少なくありません。

　このように、ユーザは私たちが期待するような完全な回答は提供してくれませんが、そもそもユーザから教えてもらうことを期待するほうが間違っているのです。ユーザに「良い師匠」になってもらうのではなく、インタビューアが


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

「良い弟子」になるほうが現実的です。

ａ良い弟子と悪い弟子　師匠と弟子方式のインタビューでは、質問は事前に準備するものではなく、ユーザと対話する中で自然と沸き上がってくるものです。優れたインタビューアはユーザの言うことを懸命に“理解”しようとします。そして少しでも疑問があれば、その場で素直に質問します。その結果、理解が深まり、より話が弾みます。そういうインタビューを行えば 1時間くらいは、あっという間に経ってしまいます。

　一方、多くの初心者インタビューアは、実はユーザの話を真剣に聞いていません。“師匠”の話を聞かずにいったい何をしているのかというと、一生懸命

「次の質問」を考えているのです。そのインタビューアは会話が途切れることを恐れてそうしているのですが、皮肉にも、そんな自分勝手な（文脈を無視した）質問ばかりすると話がかみ合わなくなって、結局、話は続かなくなってしまいます。実際、初めてのインタビューでは 5分も話が持たないことは少なくありません。

　初心者インタビューアのもう 1つの悪い習性は、物分かりがよすぎることです。ユーザの話の冒頭部分だけ聞いて、後は自分と同じような手順や方法でやっているのだろうと「わかったつもり」になってしまうと、それ以上突っ込んだ質問は生まれません。実際にはユーザの行動は多種多様です。同じような

ユーザの習性ユーザは「無口で気難しい師匠」みたいなもの。


話であっても、全く同じ話は 2つとないと思っておいて間違いありません。

ａ文脈をクリック　師匠と弟子方式のインタビューではユーザに「根掘り葉掘り」質問します。しかし、「根掘り葉掘り」質問することと、ユーザを「質問攻め」にすることは異なります。

　このインタビューアは事前に用意したフローに沿って質問しています。「利用場面→利用する機能→利用しない機能→利用しない理由→ナビの不満点→要望や改善点……」と矢継ぎ早に質問を切り替え続けるつもりなのだと思いますが、この作戦は遠からず破綻します。こんな調子では 10分もすれば質問を使い果たしてしまうでしょう。

　�「○○さんは普段、どんなときにカーナビを使うのですか？」�　「よく知らない場所に行くときや、遠出するときですね」　「それ以外にカーナビを使うことはないのですか？」　「近場や知っている場所に行くときは使わないですし……ああ、ときどき、ガソリンスタンドやコンビニを探すこともありますね」　�「つまり、○○さんのカーナビの主な利用場面としては、よく知らない場所へ行くとき、遠出するとき、ガソリンスタンドやコンビニを探すとき、ということになりますね」

　「（少し首をかしげながら）まあ、そういうことですかね……」　「では次に、○○さんがよく使う機能を教えてください」　「私は本当に基本的な機能しか使っていません。目的地を探してルート案内開始するだけです」

　「経由地設定の機能は使わないのですか？」　「すみません、“経由地設定”って、どんな機能のことですか？」インタビューアが説明する。

以下、省略

：インタビューア　　　：ユーザ会話例　❶


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

　このインタビューアも次々とユーザに質問をしています。しかし、前述のインタビューアと異なる点があります。それは“文脈”に沿って質問しているという点です。インタビューの冒頭部では「よく知らない場所」という抽象的な回答に対して“根掘り葉掘り”質問することで、ユーザが具体的な体験を語り出すきっかけを作っています。さらに、ユーザの体験談の中で出てきた「だいたいの場所しか出なかった」という体験をさらに深掘りしています。そして、ユーザが目的地に到着した後の体験も聞き出しています。

　インタビューアの役目とは「質問を作る」ことではありません。ユーザの話をじっくり聞いて、その中から「質問を見つける」ことです。ユーザの話には、必ず“文中リンク”や“脚注リンク”が含まれています。優れたインタビューアは、そのリンク箇所を見つけて「クリック」しているだけなのです。

　�「○○さんは普段、どんなときにカーナビを使うのですか？」　「よく知らない場所に行くときや、遠出するときですね」　�「“よく知らない場所”とは、どんな場所のことなのですか？」　「新しくできたお店や、名前だけ知っているような場所のことです」　�「最近、そういった場所にナビを使って行ったという経験はありますか？」

　「ええ、この連休に家族で……」――中略――

　�「今のお話の中で“電話番号で検索するとだいたいの場所しか出なかった”とおっしゃっていましたが、それでも無事に到着できたのですか？」

　「店のチラシに簡単な地図が出ていたので、おおよその場所はわかっていました。そこで、ナビの地図を拡大して場所の目星を付けました。斜め向かいに公園があるのを憶えていたので、すぐわかりました」　�「ところで、店に到着した後はどうなさったのですか？」　「実は、店の駐車場がいっぱいだったので、ナビで近くの駐車場をいくつか探したのですが、行ってみると全部埋まっていました。結局、周りを走っている間に、新しくできたコインパーキングを見つけて停めることができました」

以下、省略

会話例　❷


Column 質問は1つだけ用意する

文脈をクリックインタビューアの役目とはユーザの話の中から「質問を見つける」こと。

よく知らない場所に行くときや、遠出するときですね。

新しくできたお店や、名前だけ知っているような場所のことです。

この連休に家族で・・・

　阿川佐和子さんは売れっ子の作家ですが、インタビューの達人としても知られています。週刊文春で長年連載している「この人に会いたい」では、その真価がいかんなく発揮されています。そんな阿川さんにも「初心者」の時代がありました。その頃に出会った、ある先輩アナウンサーの言葉が著書の中に記されています。

　「インタビューするときは、質問を 1つだけ用意して、出かけなさい」――そんなこと、できるわけないでしょ。と、私は笑い飛ばしました。（中略）でも、その先輩は、こういう解説を付け加えていらっしゃいました。　「もし 1つしか質問を用意していなかったら、当然、次の質問をその場で考えなければならない。次の質問を見つけるためのヒントはどこに隠れているだろう。隠れているとすれば、1つ目の質問に応えている相手の、答えのなかである。そうなれば、質問者は本気で相手の話を聞かざるを得ない。そして、本気で相手の話を聞けば、必ずその答えのなかから、次の質問が見つかるはずである。」�〈引用元：阿川佐和子：『聞く力―心をひらく 35のヒント』、文藝春秋、2012 年（p53）〉

　ジャーナリズムであれ、マーケティングであれ、ユーザエクスペリエンスであれ、インタビューの基本は同じです――「本気で相手の話を聞く」こと。決して、用意した質問リストを回答で埋めていくことではありません。


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

ａ弟子入りのアンチパターン　ユーザと「師匠と弟子」の関係を構築することがインタビュー成功の鍵です。しかし、頭ではわかっていても、ついつい、これまでの習慣が出てしまうと間違った人間関係に陥ってしまいます。

◎「インタビューする人とインタビューされる人」パターン

　現場に行くとユーザは作業を中断してインタビューに応じます。あなたの手には事前に入念に準備した「質問リスト」が握られています。あなたが質問をする、ユーザが回答する、沈黙が流れる。あなたは次の質問をする、ユーザが回答する、また沈黙が流れる……あなたは用意したすべての項目に回答を記入し終え、満足して謝意を伝えて立ち去ります。ふと振り返ると、ユーザが作業を再開している姿が目に入ります。

�　あなたは質問票を回答で埋めるために現場に行くのではありません。現場でしかできない（事前には思いつかない）ような質問をするために現場に行くのです。必ず、ユーザには作業をしながらインタビューに応じてもらいましょう。そして疑問があれば、その時にその場で「根掘り葉掘り」質問しましょう。

◎「専門家と素人」パターン

　現場に行くとユーザはあなたの到着を心待ちにしています。そして、普段、パソコンやソフトウェアについて疑問に感じている点や自分のやり方が間違っていないかを次々と質問してきます。あなたは専門知識を活かして質問に丁寧に答えてユーザの疑問を解決し、もっと上手いやり方をアドバイスします。インタビューの終わりに、ユーザは「今日は大変勉強になりました」と謝意を表します。

�　これは師匠と弟子の立場が逆転しています。あなたは質問に答えるために現場に行くのではありません。質問するために現場に行くのです。ユーザには「自分の判断」に従って普段通りに作業を実行してもらいましょう。ユーザの行動に「正しい／間違い」はありません。どんな行動であっても、それが「現実」なのです。

◎「お客さんと主人」パターン

　現場に行くとユーザの“代表者”があなたを丁重に迎えます。作業場は整理整頓されていて、“説明係”が作業を理路整然と説明してくれます。あなたは礼


Column もつれた糸を解きほぐす

儀正しく振る舞い、もし説明係が質問に言葉を濁す場面があっても、それ以上あれこれ詮索することはしません。最後は代表者と説明係が玄関までうやうやしく見送ってくれます。

�　あなたは現場を“視察”するのではありません。あなたは現場に“入る”のです。必ず、現場の一員として、ユーザの傍らで一緒に作業を体験させてもらいましょう。そしてユーザがやっていることには何でも興味を示しましょう。そして、ユーザから「これ知っていますか」「これも見ていきますか」と気軽に声をかけてもらえるようになれば、それが上手く弟子入りできた証です。

　「普段、映画館に行きますか？」　「ええ、ときどき行きますよ」　「どれくらいの頻度で行きますか？」　「月に 2～ 3回ですかね」　「一番最近行ったのはいつですか？」　「先週の金曜日に行きました」　「その時のことを教えてください！」

　ユーザの体験とは「もつれた糸」のようなものです。ユーザの頭の中では過去の体験が重層的に重なり合い、もつれ合っています。このような「もつれた糸を解きほぐす」のはインタビューアの役目です。

●話の糸口をつかむ　どのようなテーマでインタビューするにしても、もつれた糸を解きほぐすためには、まず一番端っこ（話の糸口）を見つけないといけません。そのための定番パターンがあります。それは、1. 体験の有無→ 2. 体験の頻度→ 3. 直近の体験の順番で話を聞いていくのです。

　今、仮にユーザの「映画館利用体験」を調べているとします。定番パターンで話を聞くとこうなります。

　後は弟子入りの基本フローに沿ってインタビューを展開できます。


IntroductionP

art 1調査・分

析P

art 2設計

Part 3

評価

Ending

参考文献

　「普段、映画館に行きますか？」　「いいえ」　「なぜ行かないのですか？」　「結構高いですよね」　「どう高いのですか？」　「大人 1人 1,800 円ですよね。それに交通費もかかるし。家族で行って、さらに食事でもしたら 1回 1万円近くかかりますよ」　�「なるほど……では、チケットがもっと安かったら、どうですか。例えば、大人 1人千円とか」

　「まあ、それくらいならば時々行くかもしれませんね」

　なぜ、この順番で聞かないといけないのかと疑問を感じる人がいるかもしれません。もし、インタビューアが最初に「映画館に行った体験を教えてください」と質問してしまうと、ユーザは「過去の映画館体験を総括した話」を始めてしまいます。その結果、話が“もつれる”のです。話をもつれさせないためには、必ず具体的な場面を指定して話を聞きましょう。

●なぜ○○しないのですか？　上記の例では体験の有無のステップでユーザの回答が「YES」だったので、定番パターンで上手くいきました。もし、これが「NO」だったとすれば？　ここで「頭が真っ白」になるインタビューアは少なくありません。そして苦し紛れに最大の“失敗質問”をしてしまいます。

　「なぜ○○しないのですか？」――。こう質問されると、ユーザは自分の“意見”を話し始めてしまいます。「チケットが高いから行かない」「疲れるから行かない」「時間がないから行かない」etc...。そこでインタビューアがさらに深堀りすると泥沼にはまります。

　これは典型的な失敗例です。そして、実際にはよくあるインタビューの光景です。インタビューアは“弟子入り”するではなく“議論”しています。

　では、どうすればよいのでしょうか。


　「普段、映画館に行きますか？」　「いいえ」　「どれくらい行っていないのですか？」　「子供が生まれてからなので、3年くらいですかね」　「その前は行っていたのですか？」　「ええ、結婚前はよく映画デートしていたんですよ」　「その頃のことを教えてください！」

　これで標準の弟子入りパターンに持ち込めました。後はさっきと同様に弟子入りの基本フローに沿ってインタビューを展開できます。

●インタビューの禁句　「なぜ○○しないのですか？」はインタビューの禁句です。この問いかけは、ユーザに“分析”を依頼していることになるからです。

　あなたが「なぜ？」と聞くとユーザは「うーん」と言いながら下を向くことが多いはずです。それは考えて（＝分析して）いるからです。一方、あなたが「その時のこと」を聞くとユーザは「えーと」と言いながら上を向くことが多いはずです。それは考えて（＝思い出して）いるからです。

　インタビューとはユーザから答えを教えてもらう場ではありません。答えを導き出すのは、あなたの役目です。ユーザに聞かなくても、ユーザの体験を把握すれば「なぜ？」は自然と理解できるようになります。

（なお、念のために書いておきますが、実際の調査で映画館に行かない人に「映画館に行きますか？」と質問することはありません。リクルートする際に事前に確認するからです。そして、映画館に「行く人」と「行かない人」には異なる内容のインタビューを行います。）

「ユーザビリティエンジニアリング(第2版)」無料サンプル版（第2章全文）

Technology