ユーザビリティテストの進め方｜誰に頼むかの判断軸

機能はきちんと動くのに、「使いにくい」「よく分からない」という声や低評価レビューが減らない。登録や購入といった重要なフローで離脱が起きているのに、どこで詰まっているのか特定できない。

そんな状況に心当たりがあるなら、必要なのはバグ探しではありません。ユーザー目線で「迷う・つまずく」箇所を洗い出す評価です。

この記事では、ユーザビリティテストの進め方を基本手順から整理します。そのうえで記事の核として、「どんな場合に、どんな背景のテスターが適切か」を比較表で示します。手順そのものより「誰に評価させるか」で成否が分かれる、という視点で読み進めてください。

「機能は動くのに使いにくい」はなぜ起きるのか

「使いにくい」という言葉は曖昧です。バグのように「この画面のこのボタンが動かない」と特定できるものではありません。「なんとなく分かりにくい」「途中で面倒になる」といった感覚として表れます。

だからこそ、開発チームの手元では原因を掴みにくいのです。機能が仕様どおり動いていること自体は正しい、という点にも難しさがあります。動作の正しさと、使ったときの体験の質は、別の軸で評価しなければ見えてきません。

「使いにくい」という声・低評価レビューが減らない構造

低評価レビューやアンケートの自由記述には、「登録が面倒」「どこを押せばいいか分からない」といった声が並びます。しかし、それらは結果であって原因ではありません。

具体的にどの画面の、どの一手で迷ったのかが分からない。だから改善の打ち手が定まらないまま時間が過ぎます。声は届いているのに手が打てない、という状態が続くのです。

離脱率やレビューの数字は「症状」であり、原因そのものは操作の観察からしか見えてきません。この構造を理解しておくことが、評価の出発点になります。

作り手は「作った本人バイアス」で迷いに気づけない

開発者やデザイナーは、その画面を隅々まで理解しています。どこに何があるか、次に何を押せばいいかを、考えるまでもなく分かっています。

これは強みである一方、致命的な盲点にもなります。初めて触れるユーザーがどこで手を止めるかを、作り手は想像しにくいのです。仕様を熟知しているほど、初見の迷いは見えなくなります。

• 導線の分かりにくさ: 作り手には「当然の順序」でも初見には不明
• 用語のズレ: 社内で通じる言葉がユーザーには伝わらない
• 手数の多さ: 慣れた人には気にならない手間が離脱を生む

だからこそ、予備知識のない第三者の目が必要になります。

バグ（動く/動かない）と体験の質は別問題

機能テストは「仕様どおり動くか」を検証します。一方、ユーザビリティ評価が見るのは「迷わず使えるか」です。この違いを整理しておくと、社内で必要な評価の種類がはっきりします。

品質保証とテストは重なる部分もありますが、担う役割は異なります。全体像を先に押さえておきたい方は、バグ検出と品質保証の違いを整理した記事で全体像を確認することをおすすめします。バグがゼロでも「使いにくい」は残る、という前提に立つことが最初の一歩です。

ユーザビリティテストとは何か（品質特性における位置づけ）

ユーザビリティテストを正しく位置づけるには、「使いやすさ」がソフトウェア品質の正式な一要素である、という前提を押さえる必要があります。感覚的な良し悪しではなく、評価すべき品質特性の一つなのです。

使用性は「品質特性」の一つ（ISO/IEC 25010）

ソフトウェアの品質を体系化した国際規格 ISO/IEC 25010 には、品質特性の一つとして「使用性（ユーザビリティ）」があります。布施昌弘『ソフトウェアテストの教科書』でも核心として扱われる枠組みで、機能適合性や信頼性と並ぶ正式な特性です。

使用性はさらに副特性に分かれます。代表的なものに、習得性（学びやすさ）・運用操作性（操作のしやすさ）・ユーザーエラー防止性などがあります。「使いやすさ」と一口に言っても、評価すべき側面は複数あるということです。

なお、アクセシビリティも規格上は使用性の副特性に含まれます。ただし支援技術という独立した評価スキルを要するため、本記事では別観点として扱います。

作り手が「当たり前品質」を満たしているつもりでも、ユーザーにとって当然あるべき使いやすさが欠けていれば、強い不満につながります。

バグテストとの違い＝「動くか」ではなく「迷わず使えるか」

機能テストとユーザビリティテストは、見ている対象が根本的に異なります。両者を混同すると、必要な評価が抜け落ちます。

観点	機能テスト（バグ検出）	ユーザビリティテスト
問う内容	仕様どおり動くか	迷わず使えるか
合否の基準	期待結果との一致	ユーザーがゴールに到達できたか
主な発見	不具合・エラー	迷い・つまずき・離脱
評価する人	テスト担当者	想定ユーザーに近い評価者

両者は補完関係にあります。どちらか一方では、製品の質は担保できません。

定性評価と定量評価（射程の違いに注意）

ユーザビリティ評価には、大きく2つの見方があります。

• 定性評価: 操作の様子を観察し、どこで・なぜ迷ったかを言葉で拾う
• 定量評価: タスク成功率や所要時間、離脱ポイントなどを数値で捉える

ここで注意したいのが、両者の射程の違いです。タスク成功率や離脱率のような定量指標は、本来もっと多くのユーザーやアクセスログ側で測る数値です。少人数観察で得た値を、そのまま離脱率と読み替えてはいけません。

少人数の観察が強いのは、あくまで「なぜ迷うか」という定性的な問題発見です。定性で問題の芯を掴み、定量の裏づけは実ログや十分な母数のデータ側で取る。この役割分担を意識してください。

ヒューリスティック評価との使い分け

実ユーザーに操作してもらうユーザビリティテストに対し、専門家がユーザビリティ原則の観点からUIを点検するのがヒューリスティック評価です。

前者は「実際のユーザーがどう詰まるか」を、後者は「原則から見て何が問題か」を明らかにします。被験者の調達が難しい場面では、まず専門家評価で粗を取り、その後に実ユーザー評価で裏を取る、という組み合わせも有効です。

ユーザビリティテストの進め方（基本ステップ）

ここからは、具体的な手順に落とし込みます。NN/g（Nielsen Norman Group）のユーザビリティテストの定義に関する解説でも、代表的なユーザーに実際のタスクを行ってもらい、その様子を観察する手法として整理されています。全体像は次の5ステップです。

ステップ	やること	アウトプット
1	目的とゴールを決める	評価の焦点・仮説
2	タスクを設計する	被験者に依頼する操作課題
3	被験者を選ぶ	誰に・何人に頼むか
4	観察・記録する	迷い/つまずきの記録
5	分析する	問題点と改善候補の一覧

ステップ1：評価の目的とゴールを決める

最初にやるべきは、「何を明らかにしたいか」を1つに絞ることです。目的が曖昧なまま始めると、観察しても解釈できません。

• 「新規登録フローのどこで離脱が起きるか」
• 「初見ユーザーが検索機能に迷わずたどり着けるか」

このように、検証したい仮説を具体的な問いの形にします。目的が定まっていない評価は、データは取れても打ち手につながりません。

ステップ2：実際の利用シーンからタスクを設計する

次に、被験者に実際に行ってもらう操作課題（タスク）を設計します。ここで重要なのは、机上の理想手順ではなく、現実の利用シーンに沿ったタスクにすることです。

「アカウントを新規作成し、商品を1つカートに入れて購入直前まで進めてください」のように、ユーザーが実際に達成したいゴールの形で提示します。誘導的な指示（「右上のボタンを押して」など）は避け、ゴールだけを伝えるのがコツです。

利用シーンからタスクを組み立てる発想は、機能テストのテストケース設計にも通じます。Copeland『はじめて学ぶソフトウェアのテスト技法』が示す、ユースケースから現実の操作シナリオを起こす考え方は、タスク設計のヒントになります。より体系的に設計したい場合は、ユーザー視点でタスクを設計するユースケース駆動テストの手順を読むと、抜け漏れの少ないタスク設計に役立ちます。

ステップ3：被験者は何人・どんな人を選ぶか

「何人でやればいいのか」は多くの人が悩む点です。ここで有名な指針が、NN/g の5ユーザーで約85%の問題が見つかるという知見です。

ただし注意点があります。この5ユーザー則は、あくまで定性的な問題発見のための指針です。前述のとおり、離脱率のような定量指標を精密に測るには足りません。少人数で観察・改善・再評価のサイクルを回すのが効率的、と理解してください。

もう一つの前提が、想定ユーザー層の均質さです。5人で約85%というのは、ユーザー層がおおむね均質な場合の目安です。ターゲット層が複数に分かれる製品では、層ごとにそれぞれ5人程度が必要になります。この考え方は、次章のテスター選定表とも通じます。

被験者をどう集めるかも、最初の壁になりがちです。いきなり大規模に構える必要はありません。段階的に調達手段を広げれば十分です。

調達手段	手軽さ	向くケース
社内の非開発・非デザイン部署の人	高	まず素の反応を見たい初期段階
知人・家族	中	一般消費者に近い層で試したい
モニター募集サービス	低	ターゲット層を絞って集めたい

まずは社内の門外漢1〜2名に頼む、という最小スタートで構いません。そのうえで、想定ユーザーとの近さが足りなければ外部の手段に広げていきます。被験者は「何人か」以上に「どんな人か」が決定的です。この点は次章で詳しく扱います。

ステップ4：観察・記録し、迷い/つまずきを拾う

評価本番では、被験者の操作を観察し、記録します。ここでの原則は「口を出さない」ことです。

• 迷って手が止まった箇所とその長さ
• 誤ってタップ・クリックした場所
• 発話（後述の思考発話法で拾う）
• ゴールに到達できたか、途中で諦めたか

思考発話法とは、操作しながら考えていることを声に出してもらう手法です。「あれ？」「どこだろう」といった言葉が、迷いの在りかを教えてくれます。

観察環境は、大がかりに構えなくても始められます。PCの画面録画とオンラインの画面共有だけで十分で、専用ルームは不要です。助け船を出したくなっても我慢し、ユーザーが自力でどう動くかをそのまま記録します。この生の観察データが、後の分析と改善の土台になります。

ユーザビリティテストは誰に頼む？対象別・テスター選定の判断軸

ここが本記事の核心です。ユーザビリティテストの成否は、手順の精緻さよりも「誰に評価させるか」で大きく左右されます。同じ製品でも、評価してほしい問題が変われば、適したテスターの背景も変わるからです。

次の表は、テストの目的・対象ごとに「見抜きたい問題」と「適切なテスターの背景・専門性」を対応づけたものです。自社がどの行に当てはまるかを考えながら読んでください。

テスト目的・対象	見抜きたい問題	適切なテスターの背景・専門性
BtoC Webサービスの登録・購入フロー	どこで迷い、なぜ離脱するか	ターゲット層に近い一般ユーザー（予備知識のない初見者）
スマホアプリの操作性	タップ導線・画面遷移のつまずき	該当OS・デバイスを日常利用する評価者
UI文言・日本語の違和感	不自然な言い回し・表記ゆれ・トーン不統一	日本語ネイティブで言語感度・校正観点の高い評価者
海外製プロダクトの日本語ローカライズ	翻訳調・文化的不整合・用語の直訳	日英両言語に通じたローカライゼーション評価者
専門業務システム	ドメイン特有の業務フローの使いにくさ	当該業務の実務経験者（ドメインエキスパート）
アクセシビリティ	支援技術下での利用可否・操作到達性	支援技術ユーザー／アクセシビリティ知見者

各行を、もう少し補足します。

• 登録・購入フローは、予備知識のない初見者でないと「当たり前に見える導線の落とし穴」が見えません。
• スマホアプリの操作性は、対象OSやデバイスを日常的に使う評価者でないと、指の動きや画面遷移の自然さを判断できません。
• UI文言の違和感は、言語感度の高い日本語ネイティブでなければ、微妙な表記ゆれやトーンの不統一を拾いきれません。
• 専門業務システムは、その業務の実務経験者でないと、そもそも何が不便なのかを判断する土台がありません。
• アクセシビリティは、支援技術を実際に使う人や知見者でないと、操作到達性の可否が分かりません。

表の読み方：目的が変わればテスター像も変わる

この表の要点は、「万能のテスター」は存在しない、ということです。同じアプリでも、離脱の原因を知りたいのか、文言の違和感を知りたいのかで、頼むべき相手はまったく変わります。

評価を依頼する前に「今回見抜きたい問題は何か」を1つに定めると、必要なテスター像が自ずと決まります。目的とテスター像はセットで考えるべきものです。

「一般ユーザー」で足りる場合と専門性が要る場合の線引き

一般消費者向けの登録・購入フローのように、「初見でどう迷うか」を知りたい場合は、ターゲット層に近い一般ユーザーで十分です。むしろ専門知識がないほうが、素の反応が得られます。

一方で、専門性が要る場面もはっきりしています。

• 業務システムの使い勝手 → ドメインの実務経験
• 日本語・ローカライズの品質 → 言語の専門性
• アクセシビリティ → 支援技術の知見

いずれの場合も、評価の前提は「実際に使う人の視点」に立つことです。その「ユーザー」が誰なのかを取り違えると、評価そのものが的外れになります。

日本語・ローカライゼーションテストは専門評価者でないと粗が残る

UI文言や日本語の自然さは、一般ユーザーの操作観察だけでは拾いきれません。使えてはいるが、どこか翻訳調で不自然、という粗は、言語感度の高い評価者でないと言語化できないからです。

特に海外製プロダクトの日本語版では、直訳や用語の不統一が信頼感を損ないます。ここは校正・ローカライゼーションテストの観点を持つ評価者に委ねるのが確実です。

複数観点が絡む場合の組み合わせ方

実際には、1つの製品に複数の観点が絡むことも珍しくありません。たとえば海外製の業務アプリなら、「ドメイン知識」と「ローカライズ品質」の両方が問われます。

その場合は、無理に1人でまかなおうとせず、観点ごとに評価者を分けるのが現実的です。アクセシビリティも、吉井健文『フロントエンド開発のためのテスト入門』が扱うように、支援技術の利用可否という独立した観点として押さえる必要があります。観点の掛け合わせを意識すると、抜けのない評価体制が組めます。

社内でできない場合、第三者評価・外注をどう判断するか

ここまで読んで、「そもそも社内に、そんな客観評価ができる人がいない」と感じた方も多いはずです。専任のUX担当を置ける体制ばかりではありません。ここでは、内製の限界と、第三者評価という選択肢の判断軸を整理します。

内製が難しい典型パターン（専任者不在・作り手バイアス）

社内評価が機能しにくいのは、次のようなパターンです。

• 専任者がいない: ユーザビリティを客観評価する役割が社内に定義されていない
• 作り手バイアス: 開発・デザイン担当が評価すると、無意識に「正しい手順」で操作してしまう
• 忖度が働く: 社内の人間関係の中では、率直な「使いにくい」を言い出しにくい

これらが重なると、内製の評価は「問題がない」という結論に傾きがちです。実際には問題があるのに、見えていないだけ、という状態です。

内製・外注の手間とコストの目安

判断のために、進め方ごとの手間とコスト感を整理します。金額は変動が大きいため、あくまで大小の目安として捉えてください。

進め方	手間・工数の目安	コスト感
社内モニターによる内製	担当者の人件費・数人日程度	小（実質は社内工数）
簡易な外注（小規模）	対象を絞れば短期間	中（一般に数十万円規模から）
専門会社による本格的な外注	設計〜レポートまで一式	大（規模に応じ変動）

費用は規模・評価対象・評価者の専門性によって大きく変動します。上記の金額は幅を持たせた一般的な目安であり、断定的な相場ではありません。実際の見積りは対象範囲を定めたうえで確認してください。

第三者評価で得られる客観性

第三者に評価を委ねる最大の価値は、しがらみのない客観性です。製品を初めて触る評価者は、作り手が「当然」と思い込んでいる前提を持ちません。

第三者評価の本質は、作り手が見えなくなっている「初見の迷い」を代わりに可視化してくれることにあります。社内では出てこない指摘が、率直に言語化されるのです。

リソース不足で評価まで手が回らない、という課題も、外部の力で解けます。外部テストでリソース不足の品質課題を解決する方法を確認すると、内製の限界を補う具体像がつかめます。

外注先を見るときの観点（誰が評価者になるか）

外注を検討する際に最も重要なのは、「誰が評価者になるか」です。会社の看板ではなく、実際に手を動かす評価者の背景を確認します。前章の比較表が、そのまま確認項目になります。

確認する観点	見るべきポイント
被験者・評価者の調達力	ターゲット層に近い評価者を集められるか
言語適合	日本語・ローカライズの専門評価者がいるか
ドメイン適合	対象業務の知見を持つ評価者を用意できるか
レポートの具体性	「どこで・なぜ」まで踏み込んだ指摘か

自社が見抜きたい問題に対して、適切な背景の評価者を用意できるかどうか。ここが外注先選定の核心です。

評価結果を「上長への説明材料」と改善優先順位に変える

ユーザビリティ評価は、実施して終わりではありません。得られた所見を、改善の優先順位と、上長を説得する材料に変えて初めて価値が出ます。定性的な「使いにくい」を、動かせる意思決定に翻訳する段階です。

観察の頻度そのものが一次証拠になる

定量データがまだ整っていなくても、悲観する必要はありません。「5人中4人が同じ箇所で止まった」という観察頻度自体が、上長への立派な一次証拠になります。

同じ場所で複数人が詰まった、という事実は、深刻度の高い定性シグナルです。まずはこの観察頻度を持って、改善提案の口火を切ることができます。

定性所見と定量指標（離脱・成功率）の関係を正しく扱う

観察で得た定性的な所見は、そのままでは「担当者の主観」に見られがちです。そこで、実ログ側の定量指標と照らし合わせます。

• 「登録フォームの入力項目で3人中3人が手を止めた」→ 深刻度の高いシグナル。該当ステップの実際の離脱率をログで確認する
• 「検索結果からの導線に半数が迷った」→ 実データ上のタスク成功率・完了率と突き合わせる

ここで大切なのは、少人数観察の値を離脱率そのものと読み替えないことです。定性の「なぜ」を、定量の裏づけは実ログ側で取る。この切り分けを守ると、指摘の説得力が正しく上がります。

改善インパクト×工数で優先順位をつける

見つかった問題をすべて同時に直すことはできません。そこで、改善インパクトと必要工数の2軸で優先順位をつけます。

優先度	インパクト	工数	対応方針
最優先	大	小	すぐ着手
計画的に対応	大	大	計画に組み込む
余力で対応	小	小	手が空いたら
見送り検討	小	大	原則後回し

「離脱に直結し、かつ小さな工数で直せる問題」から着手するのが、最も費用対効果の高い順序です。この整理があるだけで、改善の議論は一気に進みます。

上長に「なぜ直すか」を一枚で説明する

最後に、これらを1枚にまとめます。「どの問題が」「どの数字に効き」「どれくらいの工数で直るか」を並べれば、それがそのまま説明資料になります。

投資判断として費用対効果を示す進め方は、テスト外注の費用対効果を上長に説明し稟議を通す手順を見ると、稟議の通し方まで含めて具体化できます。感覚の議論を、根拠ある提案に変えることが目的です。

ユーザビリティテストの進め方に関するよくある質問

最後に、実務でよく出る疑問を整理します。

Q. ユーザビリティテストは何人で行うべき？

定性的な問題発見が目的なら、5人程度で多くの問題が見つかるとされています。ただしタスク成功率や離脱率といった定量指標を精密に測るには、より多くの母数や実際のアクセスログが必要です。ユーザー層が複数に分かれる製品では、層ごとに5人程度を確保してください。

Q. 社内と外注（第三者評価）はどちらがよい？

判断の目安は、次のように分けて考えると整理できます。

• 社内（内製）が向く: 素の反応をまず見たい初期段階。社内の門外漢に頼めば十分始められる
• 外注（第三者評価）が向く: 専任者がいない、作り手バイアスや忖度が働く場面。客観性と評価者の専門性が必要なとき

まずは内製で試し、客観性と専門性が要る段階で外注を検討する、という順序が現実的です。

Q. 機能テストとの違いは？

機能テストは「仕様どおり動くか」を検証し、ユーザビリティテストは「迷わず使えるか」を評価します。バグがゼロでも「使いにくい」は残るため、両者は補完関係にあります。目的が異なるので、片方だけでは製品の質は担保できません。

Q. 費用の目安は？

社内モニターによる内製なら実質は担当者の工数で始められます。外注は一般に数十万円規模から幅がありますが、費用は規模・対象・評価者の専門性で大きく変動します。断定的な相場はないため、対象範囲を定めたうえで見積りを確認してください。

まとめ：ユーザビリティテストの進め方は「誰に評価させるか」で決まる

ここまで、手順とテスター選定の両面から見てきました。最後に要点を振り返ります。

手順の要約

• 「機能は動くのに使いにくい」は、動作の正しさと体験の質が別軸だから起きる
• 使用性はISO/IEC 25010の正式な品質特性（2011年版8つ、2023年改訂で9つ）
• 進め方は「目的設定→タスク設計→被験者選定→観察→分析」の5ステップ
• 5ユーザー則は定性的な問題発見の指針。定量指標は実ログ側で測る
• 被験者は少人数でも多くの問題が見つかるが、「どんな人か」が決定的

今週やる3ステップ（無料・即日着手）

大きく構える前に、まずはお金をかけずに踏める最初の一手があります。

1. 目的を1つ決める（例:「新規登録フローのどこで詰まるか」）
2. 社内の門外漢1名に、既存フローを操作してもらい黙って観察する
3. 詰まった箇所をメモに残す（何人中何人が止まったかも記録）

この3ステップは無料で今週から始められます。外注は、その先で客観性や専門性が必要になったときの選択肢と位置づけましょう。

テスター選定表の再確認（自社はどの行か）

そして最も大切なのは、手順の精緻さより、目的に合ったテスターを選べるかどうかが評価の成否を分けるという点です。登録フローの離脱を知りたいのか、日本語の違和感を正したいのか、業務システムの使い勝手を確かめたいのか。目的ごとに、頼むべき相手は変わります。

本記事の比較表に戻り、自社が今どの行に当てはまるのかを確認してみてください。そこが、評価を始める最初の一手になります。

自社のサービスにどの背景のテスターが必要か迷う場合は、ユーザビリティ評価の体制づくりについて相談するところから始めてみてください。目的の整理からご一緒します。