シンクアラウドプロトコル

英語名 Think-Aloud Protocol
読み方 シンク アラウド プロトコル
難易度
所要時間 1セッション30〜60分、準備含め1〜2日
提唱者 カール・ダンカー(1945年)、ヤコブ・ニールセンが1990年代にUI評価に応用
目次

ひとことで言うと
#

ユーザーにタスクを実行してもらいながら、考えていること・感じていることを声に出し続けてもらう調査手法。UIのどこで迷い、何を期待し、何に驚いたかが、リアルタイムで明らかになる。5人テストすれば問題の 85% が見つかる。

押さえておきたい用語
#

押さえておきたい用語
思考発話(Think Aloud)
操作中に頭の中で考えていることをすべて声に出す行為のこと。「えっと、ここを押すのかな…あれ、違った」のように自然な独り言として発話する。
同時発話法
タスク実行と同時に発話する方法。最もリアルタイムな思考が得られるが、発話がタスクの速度を落とすことがある。
回顧発話法
タスク完了後に録画を見ながら振り返る方法を指す。タスクへの干渉が少ないが、記憶の再構成が入る。
プロンプト
参加者が沈黙したとき、思考を促す合図。「今、何を考えていますか?」と軽く声をかける。

シンクアラウドプロトコルの全体像
#

シンクアラウドプロトコル:準備→実施→分析の流れ
準備タスクシナリオ作成参加者リクルート録画環境の用意5名で問題の85%発見実施タスクを1つずつ依頼声に出して操作してもらう沈黙時にプロンプト助けず、誘導せず、観察分析発話を書き起こし問題パターンを分類重大度でスコアリング改善施策に変換する優先順位つきの改善リストユーザーの「声」に基づく改善が実現
シンクアラウドテストの実施フロー
1
シナリオ作成
テストするタスクを3〜5個用意
2
テスト実施
声に出しながら操作してもらう
3
パターン抽出
複数参加者で共通する問題を発見
改善に反映
問題をデザイン改善に落とし込む

こんな悩みに効く
#

  • UIの問題点を推測ではなく、ユーザーの実際の声で把握したい
  • ユーザビリティテストをやりたいが、大掛かりな調査の予算はない
  • 社内で「使いやすいはず」と言い張る人を、証拠で説得したい

基本の使い方
#

ステップ1: タスクシナリオを準備する

ユーザーにやってもらうタスクを 3〜5個 用意する。

  • 「商品を検索して、カートに入れて、決済まで進んでください」のように具体的に
  • 「使いやすいと思いますか?」のような主観質問はNG(行動を観察する)
  • 難易度は低→高の順に並べる(最初のタスクでウォームアップ)
ステップ2: 参加者に声を出し続けてもらう

「操作しながら、頭の中で考えていることをすべて声に出してください」と依頼する。

  • 最初にデモを見せる(「私なら"えっと、このボタンかな?押してみよう…あ、違った"のように」)
  • 10秒以上 沈黙が続いたら「今、何を考えていますか?」とプロンプト
  • 絶対にやってはいけないこと: ヒントを出す、正解を教える、「それで合ってます」と言う
ステップ3: 発見を分類して改善につなげる

録画を見返し、問題を分類する。

  • ナビゲーション問題: 「どこにあるかわからない」
  • 理解の問題: 「この言葉の意味がわからない」
  • 操作の問題: 「ボタンが小さくて押せない」
  • 複数参加者で同じ問題が出たら優先度が高い。1人だけの問題は個人差の可能性もある

具体例
#

例1:転職サイトが求人検索フローのボトルネックを発見する

状況: MAU 20万の転職サイト。求人検索→応募の転換率が 1.2% と低い。チーム内では「求人数が少ないのでは」という仮説だった。

テスト設計: ターゲットユーザー5名に「希望条件に合う求人を3件見つけて、1件に応募してください」と依頼。

発見(参加者の発話):

  • 5人中4人:「“職種"のプルダウンが多すぎて自分の職種が見つからない…」(112項目 のプルダウン)
  • 5人中3人:「“勤務地"を東京都にしたいけど、23区と市部が分かれてて面倒…」
  • 5人中5人:「応募ボタンが…あ、ページの一番下にあった。スクロールしないと見えない」

改善: プルダウンを検索可能なコンボボックスに変更。勤務地は「東京都(全域)」を先頭に追加。応募ボタンを画面下部に固定表示。

改善後、検索→応募の転換率は 1.2% → 3.4% に向上。問題は「求人数」ではなく「検索UIのフリクション」だった。

例2:社内ツールの経費精算画面を5人テストで改善する

状況: 従業員500名の企業。自社開発の経費精算システムに対し、毎月 60件 の「使い方がわからない」問い合わせが情シスに届いていた。

テスト: 営業部から5名を選び、「交通費3件と接待費1件を申請してください」と依頼。

発見:

  • 5人中5人:「“新規申請"ボタンがどこにあるか…ああ、左サイドバーの中か」(アイコンのみ、ラベルなし)
  • 5人中4人:「領収書の添付って…ドラッグ&ドロップ?あ、このエリアか。見た目が普通のテキストだった」
  • 5人中3人:「申請ボタンを押したけど…送れたのかな?」(完了フィードバックなし)

改善: サイドバーにテキストラベル追加。添付エリアに点線枠+アイコンを追加。申請完了時にサクセスメッセージ+メール通知を追加。

問い合わせは月 60件 → 18件 に減少。わずか 5人のテスト で主要な問題をすべて発見できた。

例3:高齢者向け見守りアプリの初期設定フローを改善する

状況: 利用者3万人の高齢者見守りアプリ。家族がアプリをインストールして高齢の親に渡すが、初期設定(Wi-Fi接続→アカウント連携→通知許可)の完了率が 41%。未完了のまま放置→解約が多い。

テスト: 65〜78歳の5名に「このアプリを使えるように設定してください」と依頼。

発話から得られた気づき:

  • 「Wi-Fiって何のこと?」(用語が通じない)
  • 「“アカウント連携”…連携?何と何を?」
  • 「“通知を許可しますか”…許可って怖い。何が届くの?」
  • 「画面が進んだけど、今どこまで終わったかわからない」

改善:

  • 「Wi-Fi接続」→「インターネットにつなぎます」に文言変更
  • 「アカウント連携」→「ご家族とつなぎます」に変更
  • 通知許可の前に「お子さんからのメッセージを受け取れるようにします」と説明追加
  • 全3ステップのプログレスバーを追加

改善後、初期設定完了率は 41% → 73% に向上。解約率も初月で 15% → 8% に低下した。

やりがちな失敗パターン
#

  1. 参加者を助けてしまう — 「そこじゃなくて、右のボタンです」と言いたくなるが、それをやるとテストの意味がなくなる。苦しんでいる様子こそが最も価値ある発見
  2. 「感想」を聞いてしまう — 「使いやすかったですか?」と聞くと「はい」と答える(社交辞令)。行動を観察し、発話を記録することに集中する
  3. 1人の意見で設計を変える — 1人だけが困った問題を大改修する必要はない。3人以上が同じ問題に遭遇したら優先度を上げる
  4. 大人数でテストしようとして始められない — 5人で十分。完璧な調査設計を目指すより、まず1人目を始めることが大事

まとめ
#

シンクアラウドプロトコルは、ユーザーの「頭の中」を可視化する最も直接的な手法。5人テストするだけで問題の大半が見つかり、推測ベースの議論を終わらせることができる。特別な設備は不要で、明日からでも始められる。「ユーザーはきっとこう使うはず」 という思い込みを、ユーザー自身の声で検証しよう。