ユーザビリティテストのソースを表示

'''ユーザビリティテスト'''（{{Lang-en|usability test}}）もしくは'''ユーザテスト'''（{{Lang-en|user test|links=no}}）とは、[[ユーザー中心設計]]の[[インタラクションデザイン]]において、ある製品を評価するために実際にユーザーにその製品を試してもらう手法のことである。他の方法では得られない、「ユーザーたちが実際にどのようにシステムを扱うか」という直接的な知見が得られる<ref>Nielsen, J. (1994). Usability Engineering, Academic Press Inc, p 165</ref>。これはユーザーの意見を聞くこと無くユーザーインターフェースを評価する、ユーザビリティ検証法とは対照的である。

ユーザビリティテストはある製品がどれだけ意図された目的に適うかを測る事に重きを置いている。ユーザビリティテストによって利益の出やすい製品の例として、[[食品]]、消費者向け製品、[[ウェブサイト]]、アプリケーション、CPUインターフェース、文書、装置などが挙げられる。ユーザビリティテストは特定の、もしくは複数の物のユーザビリティ、すなわちどれだけ使いやすいかを計る事が出来るのに対し、人間とコンピュータの相互作用を研究する一般的な学問においては、ある種の普遍原理を定式化する事を目的とする。

== ユーザビリティテストではないこと ==
物体や文書等の対象に対して、ただ意見を集めることは市場調査や定性調査にあたり、ユーザビリティテストではない。通常、ユーザビリティテストは統制された条件の下で組織的観察を行い、ユーザーがその商品をどれくらい上手く使用するか検証する<ref>http://jerz.setonhill.edu/design/usability/intro.htm</ref>。しかしユーザーの行動に加えてその動機や認識をより深く理解するため、ユーザビリティテストと定性調査は併用されることが多い。

ただユーザーに草稿を与えて、「この内容がわかりますか？」と問うのではなく、ユーザビリティテストではユーザーが与えられた対象を意図された用途に沿って使用する様子を観察する。例えば組み立てるタイプのおもちゃの説明書を検証する場合、被験者はまず説明書とおもちゃを与えられ、それらについてただ意見を求められるのではなく、実際にそのおもちゃを組み立てることが求められる。説明書の文章、絵のクオリティ、そしておもちゃのデザインなどすべてが組み立てる工程に影響を及ぼすのである。

== 手法 ==
ユーザビリティテストでは観察者が記録する中、入念に設計されたシナリオや現実的な状況下で、被験者は検証対象である商品を使ったいくつかのタスクを行う。合わせて、指示書やペーパープロトタイプ、事前/事後アンケートなども商品についてのフィードバックを得るために用いられることがある。例えばメールの添付機能を検証するにあたっては、シナリオ上ではユーザが添付メールを送らなければならない状況下にある事を説明し、そのタスクを行うことを要求する。開発者が問題点や人々の嗜好を見つけるために、ユーザが現実的で普段通りの行動を行うところを観察することが目的である。思考発話、共同発見学習、[[アイトラッキング]]などの手法が、ユーザビリティテスト中にデータを集める目的で多用される。

=== ホールウェイテスト ===
ホールウェイテストはユーザビリティテストの安価な手法の一つで、無作為に選ばれたユーザーに（例：そのあたりの廊下・街頭を歩いている人）商品やサービスを使用してもらうものである。このテストは新デザインの初期段階における「煉瓦の壁」、すなわち使用するにあたって進めなくなるほどの致命的な問題を発見する一助となる。プロジェクト関係者やエンジニア以外が対象となる（プロジェクトに近しい者は一般的ではない「専門家」として意見を述べてしまいがちになるため）。

=== リモートユーザテスト ===
ユーザビリティを評価する人、開発者、将来的なユーザーが異なる国やタイムゾーンに位置している場合、一般的な研究室でのユーザビリティの評価は費用面、事業面において大きな問題を招く。これらの懸念が、ユーザーと評価者が空間的にも時間的にも隔てられたリモートユーザビリティ評価の研究へと繋がった。ユーザー固有の他業務や機材状況といった文脈における評価を促進する形になるリモートテストは、同期性と非同期性に分けられる。同期性リモートユーザテストはビデオ会議やWebExのようなリモートアプリケーションツールが用いられる。前者はユーザーと評価者がリアルタイムでやり取りをするのに対し、後者はユーザーと評価者が別々に作業を行う<ref>{{cite journal |doi=10.1145/1240624.1240838 |chapter=What happened to remote usability testing? |title=Proceedings of the SIGCHI conference on Human factors in computing systems  - CHI '07 |year=2007 |last1=Andreasen |first1=Morten Sieker |last2=Nielsen |first2=Henrik Villemann |last3=Schrøder |first3=Simon Ormholt |last4=Stage |first4=Jan |isbn=9781595935939 |page=1405}}</ref>。

非同期性手法は、クリックストリーム、アプリケーションとの相互作用の中で見つかった致命的な問題についてのログ、インターフェースについての主観的なフィードバックを自動的に集めることができる<ref>{{cite journal|doi=10.1145/971258.971264|title=Remote possibilities?|year=2004|last1=Dray|first1=Susan|last2=Siegel|first2=David|journal=Interactions|volume=11|issue=2|page=10}}</ref>。研究所内での調査と同様に、非同期性テストはタスクベースであり、プラットフォームを用いてクリック数やタスク時間を把握することができる。よって、大企業にとっては閲覧者がウェブサイトや携帯サイトを閲覧する際に持っている意図の裏にある理由を知ることができるようになる。加えてこの形式のテストはフィードバックを人口統計別、態度別、行動別セグメントにそれぞれ分けることができる。テストはユーザーの固有の環境（研究室などではない）下において実施されるため、現実的なシナリオを再現する手助けとなる。このアプローチは遠方にいて組織的援助の少ないユーザーから素早く、そして比較的に容易にフィードバックを得る方法ともなる。

これらの手法を可能にするツールは数多くある。同期性リモートユーザテストについてはWebExやGo-to-meetingが最も一般的なツールである<ref>http://www.techved.com/blog/remote-usability</ref>。しかしながら同期性リモートユーザーテストでは、協調的な調査に求められる即時性や“生”感が欠ける可能性がある。加えて、文化的/言語的差異を超えた対人動態は、関連する文化に対応したアプローチが求められる場合がある。その他の欠点として、調査環境の統制レベルの低下、被験者が慣れた環境におかれている事から起因する注意力散漫や邪魔要因が挙げられる<ref>{{cite journal|last=Dray|first=Susan|author2=Siegel, David |title=Remote possibilities?: international usability testing at a distance|journal=Interactions|date=March 2004|volume=11|pages=10–17|doi=10.1145/971258.971264|issue=2}}</ref>。同期性リモートテストを行う上で考案された新たな手法には仮想世界を使用するものがある<ref>{{cite journal|last=Chalil Madathil|first=Kapil|author2=Joel S. Greenstein |title=Synchronous remote usability testing: a new approach facilitated by virtual worlds|journal=Proceedings of the 2011 annual conference on Human factors in computing systems|date=May 2011|series=CHI '11|pages=2225–2234|doi=10.1145/1978942.1979267|isbn=9781450302289}}</ref>。近年、非同期性リモートユーザテストも一般的となり、モニタが空いた時間に自宅の慣れた環境下からフィードバックを行えるようになった。

=== 専門家審査 ===
専門家による審査はユーザビリティテストの一般的なアプローチの一つである。その名の通り、この手法は特定の分野における専門家（ユーザビリティテストに特化した企業等から）を招いて、その商品のユーザビリティを評価してもらうことである。
[[ヒューリスティック評価]]、もしくはユーザビリティ監査は人間工学の専門家によるインターフェースの評価である。評価者は、例えば1994年に[[ヤコブ・ニールセン]]に提唱された10のユーザビリティヒューリスティックなどに基づいて、特定のインターフェースのユーザビリティ、効率性、有効性を測定する<ref>{{cite web|title=Heuristic Evaluation|url=http://www.usabilityfirst.com/usability-methods/heuristic-evaluation/|publisher=Usability First|accessdate=April 9, 2013}}</ref>。
ユーザー調査や新しい機材に対応して進化したニールセンのユーザビリティヒューリスティックには下記が含まれる；
* システム状態の視認性
* システムと実世界の調和
* ユーザーコントロールと自由度
* 一貫性と標準化
* エラーの防止
* 記憶しなくても、見ればわかるように
* 柔軟性と効率性
* 美的で最小限のデザイン
* ユーザーによるエラー認識、診断、回復をサポートする
* ヘルプとマニュアル

=== 自動化された専門家審査 ===
専門家審査と同様に、自動化された専門家審査は、良いデザインやヒューリスティックのルールに基づいたプログラムを通してテストを行う。自動化された評価は人が行う場合と比べて得られる具体性や見識に劣る場合があるが、より早く安定して完了することができる。代理ユーザーを立ててユーザビリティテストを行う発想は、AIコミュニティにおける野望的な発想である。

=== A/Bテスト ===
Web開発やマーケティングおいて、ABテストもしくは多変量テストはWebデザイン（特にユーザーエクスペリエンスデザイン）に対する実験的なアプローチであり、特定の出力結果（例：バナー広告のクリック・スルー率）を最大化させるWebページ上の要因を特定することを目的としている。その名の示す通り、ユーザーの行動の影響を及ぼしうる一つの要因を除いて全く同一のページの、二つのバージョン（AとB）が比較される。例えば、e-コマースサイトにおける購入過程は、ドロップオフ率のわずかな成長もセールス全体の大幅な増益につながりかねない為、A/Bテストの典型的な比較例である。セールス文言、レイアウト、画像や色使いなどの要素を検証することで大幅な改善が見られる場合がある。多変量テストやバケツテストはA/Bテストと似ているが、それらは同時に二つ以上のバージョンをテストするものである。

== 何人テストする？ ==
1990年代初頭、当時[[サン・マイクロシステムズ]]の研究者だった[[ヤコブ・ニールセン]]が、開発工程の随所で複数の小規模なユーザビリティテスト（基本的にたった5人の被験者を対象とした）を用いるコンセプトを提唱した。彼曰く、2, 3人がホームページ上で躓く現象を確認できた上で、さらに多くの人々が同じ欠陥デザインに苦しむところを観察しても得られるものは少ない。「複雑なユーザビリティテストは資源の無駄である。最良の結果は、最高でも5人のユーザーに、小規模なテストを可能な限り実施することで得られる<ref name="useit">{{cite web|url=http://www.useit.com/alertbox/20000319.html|title=Usability Testing with 5 Users (Jakob Nielsen's Alertbox)|publisher=useit.com|accessdate=2015-06-01|date=2000-03-13}}; references {{cite conference |url=http://dl.acm.org/citation.cfm?id=169166&CFID=159890676&CFTOKEN=16006386 |title=A mathematical model of the finding of usability problems |author=Jakob Nielsen,  Thomas K. Landauer |date=April 1993 |book-title=Proceedings of ACM INTERCHI'93 Conference (Amsterdam, The Netherlands, 24–29 April 1993)}}</ref>。その後ニールセンは自身の研究を出版し、ヒューリスティック評価という用語を新造した。

「ユーザーは5人で十分」とする主張は、後に問題Uの割合を定義する数学モデルによって説明された<ref>{{cite journal |last=Virzi |first=R. A. |title=Refining the Test Phase of Usability Evaluation: How Many Subjects is Enough? |journal=Human Factors |year=1992 |volume=34 |issue=4 |pages=457–468 |doi=10.1177/001872089203400407 }}</ref>。

<math>U = 1-(1-p)^n</math>
 
pを一人のユーザーが特定の問題を発見する確率、nをユーザーの数（もしくはテストの回数）とする。このモデルは実在する問題についての漸近グラフとして表せる（下記参照）。

[[ファイル:Virzis Formula.PNG]]

後の研究からニールセンの主張は経験的証拠<ref>http://citeseer.ist.psu.edu/spool01testing.html</ref> とより高度な[[数理モデル]]<ref>{{cite journal |last=Caulton |first=D. A. |title=Relaxing the homogeneity assumption in usability testing |journal=Behaviour & Information Technology |year=2001 |volume=20 |issue=1 |pages=1–7 |doi=10.1080/01449290010020648 }}</ref> の両方から追及された。彼の主張に対するカギとなる二つの異議は：
# ユーザビリティは特定のユーザーグループに関連しているため、小さすぎる標本数は母集団の代表たり得ない。少ない標本数から得られるデータは母集団よりも標本グループそのものを反映してしまいかねない。
# ユーザビリティ上の問題が見つけやすいものとは限らない。解決困難な問題は全体の作業を減速させがちである。こういった状況下においては、工程の進行はニールセン/ラウンダーの式の予測よりずっと浅いものになってしまう<ref>Schmettow, Heterogeneity in the Usability Evaluation Process. In: M. England, D. & Beale, R. (ed.),  Proceedings of the HCI 2008, British Computing Society, 2008, 1, 89-98</ref>。

ニールセンは5人のユーザーを用いた一回のテストで止めるべきと主張したいのではなく；彼のポイントは5人のユーザーでテストを実施し、見つかった問題を修正し、調整されたサイトを別の5人のユーザーで検証することは、一つのユーザビリティテストを10人のユーザーに対して実施することよりも、限られた資源の有効活用であるということである。実際には、テストは全体の開発サイクル内での1週間に1回ないし2回行われ、１ラウンドことに3人から5人のユーザーに参加してもらい、その結果は24時間以内にデザイナーたちに届けられる。故に、プロジェクト全体における参加ユーザー数は50から100人に及ぶこともままある。

ユーザーが進行を妨げる問題に最も直面しやすい初期段階においては、平均的な知識レベルを持つ誰もがテスト被験者として参加できる。第2段階では実験者は幅広い特性の領域から被験者を募る。例えばある研究では、経験豊富なユーザーは徹頭徹尾どのデザインも問題なく使えたのに対して、ナイーブなユーザーや自己意識の高いユーザーは失敗を繰り返した<ref>{{cite web|url=http://www.asktog.com/columns/000maxscrns.html|author=Bruce Tognazzini|title=Maximizing Windows|accessdate=2015-06-01}}</ref>。後にデザインがよりスムーズになれば、ユーザーは特定の母集団から選択されるべきである。

プロジェクトが進む中で十分な数の被験者に対して手法が用いられた時、上に挙げた議論が解決する：標本の数は最早小さいとは言えず、わずかな数のユーザー間にしか発生しない程度のユーザビリティ問題が発見されるようになる。この手法の価値は、特定のデザイン上の問題は発見された直後に二度と発生しないように解決され、そもそも問題の無い部分も幾度もテストされる点にある。当初存在したデザイン上の主な問題がたった5人のユーザーによってしかテストされないという点については事実であるが、手法が正しく適用されたとき、当初のテストで問題がなかったデザイン部分は50人から100人の人々にテストされることになる。

== テスト例 ==
開発者向けの1982年製[[Apple|Apple Computer]]のマニュアルにユーザビリティテストについての記述があった<ref name="apple1982">{{cite book | url=http://www.apple2scans.net/files/1982-A2F2116-m-a2e-aiiedg.pdf | title=Apple IIe Design Guidelines | publisher=Apple Computer | author=Meyers, Joe; Tognazzini, Bruce | year=1982 | pages=11–13, 15}}</ref>。

# 「ターゲット層を選択してください。ターゲット層を認識することで人間インターフェースデザインを開始してください。ビジネスマンと子供のどちらに向けて書いていますか？」
# ターゲットユーザーがどの程度アップルコンピュータとそのソフトウェアの主な問題について知っているか決めて下さい。
# ステップ1と2はターゲット層のニーズに合わせてユーザーインターフェースをデザインすることを可能とします。会計士用の確定申告ソフトウェアであればユーザーはコンピュータについて何の知識もありませんが、税法については専門家であると考えることができます。一方、一般的な消費者向けに作られたソフトウェアでは、ユーザーは税金についてなんの知識もありませんが、アップルコンピュータの基礎知識については持ち合わせていると想定できます。

アップルは開発者たちに「友人、親戚、新入社員を対象に今すぐにテストすべきである」と助言した{{r|apple1982}}:

{{quote|我々の手法は下記の通りである。まず5から6台のコンピュータシステムを用意する。5から6人のユーザーを、2から3グループ集め、1グループずつシステムを試してもらう（多くの場合、システムそのものではなく、ソフトウェアをテストしている事を知らされてない）。デザイナー二人に同席してもらう。それより少ないと、多くの情報を見逃してしまい、それより多いとユーザーたちは圧迫感を感じて窮屈な思いをしてしまう。}}

デザイナーたちは人々がプログラムを使う場面に直接立ち会わなければならない。なぜなら；

{{quote|直面される問題の95％がユーザーのボディランゲージを通して発見される。目を細める、肩をすくめる、頭を振る、ため息など。ユーザーが思わぬ問題に直面すると、「自分がそれほど利口ではないという前提」のためと考え、それを報告せず、隠してしまう。なぜユーザーが戸惑ったのか推測をしてはいけない。それは聞かなければならない。多くの場合、彼が迷ったときに実際にプログラムが何をしていたと考えていたか、驚かされる事だろう。}}

== 脚注 ==
{{脚注ヘルプ}}
{{reflist}}

== 関連項目 ==
{{div col||20em}}
* {{仮リンク|ISO 9241|en|ISO 9241}}
* [[ソフトウェアテスト]]
* [[教育工学]]
* {{仮リンク|ユニバーサルユーザビリティ|en|Universal usability}}
* [[アイトラッキング]]
* [[ヒューリスティック評価]]
{{div col end}}

== 外部リンク ==
* [http://www.usability.gov/ Usability.gov]
* [http://www.measuringusability.com/blog/five-history.php A Brief History of the Magic Number 5 in Usability Testing] (英語)

{{DEFAULTSORT:ゆうさひりていてすと}}
[[Category:ユーザビリティ]]
[[Category:ソフトウェアテスティング]]
[[Category:教育工学]]
[[Category:評価方法]]
[[Category:検査]]
[[Category:製品テスト]]