この技術でできること
- インタビューで発生する主要なバイアスを特定できる
- バイアスが結果を歪める前に、防ぐ仕組みを作れる
- 「なんとなくの結論」ではなく偏りのないデータで報告できる
例: 5人中4人が「使いやすい」と答えても、インタビュアーの表情や質問の仕方でそう答えさせていた可能性がある。バイアス制御はそのリスクを減らす技術
なぜ難しいか
バイアスの最大の問題は、自分がバイアスを持っていると自覚できないこと。
人は「自分は公平に聞いている」と思い込む。でも実際には、仮説に合う回答に深くうなずき、仮説に反する回答はさらっと流している。この無意識を制御するには、知識だけでなく構造的な仕組みが必要になる。
バイアス制御の進め方
全体フロー
「知る」→「設計で防ぐ」→「実施中に気づく」→「分析で検証する」。バイアスは意志力で防ぐものではなく、仕組みで制御するもの。
インタビューで起きる主要なバイアス
| バイアス | 何が起きるか | 誰に起きるか |
|---|---|---|
| 確証バイアス | 仮説を支持する情報だけを集める | インタビュアー |
| 社会的望ましさバイアス | 「良い回答」をしようとする | ユーザー |
| 初頭効果 | 最初の印象に引きずられる | インタビュアー |
| 近接効果 | 最後に聞いた話を重視する | インタビュアー |
| 同調バイアス | 前の人と同じ答えをする | ユーザー（グループ） |
| ホーソン効果 | 「観察されている」と普段と違う行動をする | ユーザー |
ステップ1: 設計段階で防ぐ
目的: インタビュー開始前にバイアスが入りにくい構造を作る
やること:
質問設計:
- 誘導質問を排除する（質問設計参照）
- 仮説に反する質問も意図的に入れる
- 質問順序による影響を検討する（ポジティブ→ネガティブの順で固定しない）
インタビュアーの準備:
- 自分の仮説を紙に書き出す（自覚する）
- 「仮説が外れたら嬉しい」というマインドセットを持つ
- 可能なら、仮説を知らない人がインタビューする
具体例:
仮説: 「ユーザーは検索機能に不満がある」
❌ 検索の不満を中心に質問を構成する
✅ 全体的な利用体験を聞いた上で、検索が出てくるか観察する
ステップ2: 実施中に気づく
目的: インタビュー中にバイアスが発動していることに気づく
やること:
確証バイアスのチェック:
- 仮説に合う回答に深くうなずいていないか
- 仮説に反する回答をさらっと流していないか
- 深掘りの回数が偏っていないか
社会的望ましさバイアスのチェック:
- ユーザーが「正解」を探す目つきをしていないか
- 「〇〇ですよね？」と確認を求めてきていないか
- 「良いことを言おう」としている雰囲気がないか
対処:
- 「正解はありません。普段のままを教えてください」と明言する
- 行動を聞く（「何をしましたか？」）。意見を聞かない（「どう思いますか？」）
- 「使いにくかった」と言っても表情を変えない
具体例:
ユーザー: 「この機能は…（インタビュアーの顔を見る）…便利だと思います」
👉 顔色を伺うシグナル = 社会的望ましさバイアスの可能性
インタビュアー: 「実際に使った時のことを教えてもらえますか？最後に使ったのはいつですか？」
👉 意見から行動に切り替える
ステップ3: 分析段階で検証する
目的: 結果にバイアスが混入していないかを事後検証する
やること:
- インタビュー録音を聞き直し、自分のリアクションの偏りをチェック
- 仮説に反するデータを意図的に探す（「仮説が間違っている証拠は？」）
- 複数人で分析し、解釈の一致率を確認する
- 最初のインタビューと最後のインタビューで、質問の仕方が変わっていないか確認
よくある失敗
❌ 「自分はバイアスがない」と思っている
最大の失敗。バイアスは全員にある。
なぜ失敗するか: 「バイアスを知っている」と「バイアスを制御できる」は全く別。知識があっても、無意識は制御できない。
対策:
- 知識ではなく仕組みで制御する
- 他の人にインタビュー録音を聞いてもらう
- 「自分にもバイアスがある」をデフォルトにする
❌ ポジティブな反応を返しすぎる
ユーザーが良い話をした時に「いいですね！」「素晴らしい！」と反応する。
なぜ失敗するか: ユーザーは「良い反応がもらえる話」を増やし、「反応がもらえない話」を減らす。結果、ポジティブな情報に偏る。
対策:
- ポジティブな話にもネガティブな話にも同じトーンで反応する
- 「ありがとうございます、もう少し教えてください」を基本にする
- 表情のコントロールを意識する
❌ 1人目の回答に引きずられる
最初のインタビューで得た印象が、その後の全インタビューに影響する。
なぜ失敗するか: 初頭効果。最初の情報が「基準点」になり、以降の情報をそれと比較して解釈してしまう。
対策:
- 各インタビューの前にメモをリセットする
- 「この人はこの人」と意識的に切り替える
- 分析は全インタビュー終了後にまとめて行う
実践チェックリスト
最低ライン（Must）
理想ライン（Better）
応用テクニック
デビルズ・アドボケイト
いつ使うか: 分析段階で、チーム全員が同じ結論に飛びつきそうな時
意図的に反対意見を取る役割を設ける。「でも、この結論が間違っているとしたら？」と問いかける。
例: 「認証の手間が最大の課題」という結論に対して
「もし認証を簡略化しても離脱率が変わらなかったら、本当の原因は何だと思う？」
崩れるパターン: 毎回やりすぎると議論が進まなくなる。「結論が出そうな時に1回」が目安。最終決定を遅らせるためではなく、思考の穴を埋めるために使う。
ブラインドレビュー
いつ使うか: 分析結果の客観性を担保したい時
発話データを匿名化して、仮説を知らないチームメンバーにコーディングしてもらう。
手順:
- 発話データからユーザー情報を匿名化
- 仮説を伝えずにコーディングを依頼
- 結果を自分のコーディングと比較
- 一致しない部分を議論
崩れるパターン: 人的コストが大きいので全インタビューにやるのは非現実的。重要な意思決定に直結するインタビューに限定する。
関連技術
前提となる技術
セットで使う技術
次に学ぶ技術
- リモートインタビュー — リモート特有のバイアスリスク
まとめ
- この技術の本質: バイアスは意志力で防ぐものではなく、仕組みで制御するもの
- できるようになること: 偏りのないデータを収集・報告できる
- 次に学ぶべき技術: リモートインタビュー（リモート特有のバイアスと対処法）
