ユーザビリティの定義とは

はじめに

本ページはデザインにおける重要な概念、"ユーザビリティ" について、まとめています。 対象の読者は Web デザイナーだけでなく、各種エンジニアやプロジェクト管理者、システム担当者など幅広い読者を対象にしています。

ユーザビリティについて抽象的な理解をしている読者には、具体的な理解を得られるはずです。 具体的な理解は、デザインの裏付けとなり、良し悪しを判断する上での助けとなります。 本ページではユーザビリティの説明、定義、効果、設計、原則、安全工学、テストと評価を含みます。

良いデザインの定義とは何か。 それはユーザビリティの定義を解き明かすことがヒントになります。 ユーザビリティはデザイナーだけのものではありません。 作る側、使う側のどちらにも必要な概念です。 さぁ、今こそユーザビリティを始めよう。

ユーザビリティとは

ユーザビリティ (Usability) とは、一般的に「使いやすさ」や「有用であること」を表す英語です。 use (使う) と able (できる) から来ており「使えること」が元々の意味です。 IT 分野では、「使い勝手の良さ」という意味で使われています。

ISO 13407 におけるユーザビリティの概念
ISO 13407 におけるユーザビリティの概念

ユーザビリティという言葉は、しばしば批判の対象となります。 "使いやすさ" とは程度を表す言葉であり、「使いやすい・使いにくい」といった広い意味を持ち、曖昧で、厳密な定義がなく、統一された規格や評価基準がないためです。 その結果、ユーザビリティの評価が主観的なものとなり、価値観の違いなどから意見の食い違いが起こります。

例えば、組込みシステムのユーザビリティは、製品の品質を表す概念のひとつです。 製品の品質には、信頼性、機能性、操作性などの要素があり、設計品質や実装品質などの概念で品質管理されます。 これに対して、ユーザがモノを使った結果としての品質である "利用品質" が注目されるようになりました。 ユーザビリティは、今までの品質管理にはなかった利用品質の特性のひとつの品質概念として位置付けられました。

利用品質の考え方
利用品質の考え方

ユーザビリティの第一人者であるヤコブ・ニールセンや、国際標準化機構はユーザビリティについて定義を設けました。 しかし、この定義も世界的に合意されたものではなく、依然として確立されていません。

ユーザビリティの定義が難しい理由は、すべてのユーザ・環境・目的において同じように評価できる基準がないためです。 そのため、国際標準化機構が定めるユーザビリティでは、それらの要素を限定して、ターゲットユーザが、ある状況下で、目的を達成できる場合の度合いと定義しています。

ユーザビリティという言葉自体はよく聞きますが、実態はどのようなものなのか見ていきましょう。

ユーザビリティの重要性

ユーザビリティが重要であることは理解しているものの、なぜ重要であるのか具体的に説明できる人は多くありません。 この問題は、クライアントや上司にデザインを説明する際、承認や合意を得る上での障害になります。 ユーザビリティの重要性が共有できない原因は、ユーザはデザイナーではなく、デザイナーもまたユーザではないジレンマがあるためです。 お互いが理解できる共通の問題点にフォーカスしなければ、同意は得られないでしょう。

ユーザビリティの重要性を説明する場合、分かりやすい例とはしてはコストの削減があります。 1959 年、アメリカのベル研究所に所属していた John E. Karlin は、従来の回転ダイヤル式電話機から現在の押しボタン式電話機の原型となる実験モデルを作成しました。 押しボタン式電話機は回転ダイヤル式電話機よりもダイヤル速度が向上したため、年間 100 万ドルものコスト削減に成功した事例があります。

電話機のユーザビリティ
電話機のユーザビリティ

その他にも、申込書の記入ミスの確認作業にかかるコストを削減するために、申込書のフォーマットデザインを修正した事例など、ユーザビリティの向上によるコスト削減の例は数多くあります。 ただし、ユーザビリティの向上に伴い、効果がすぐに分かるわけではないという点には注意してください。 効果を確認するためには、ある程度まとまったデータが必要になり、データを集めるためには時間がかかる場合があります。

ユーザビリティの重要性の理解が得られない問題点はまだあります。 デザインの変更によって効果がでたのか、それとも他の要因で効果がでたのか、客観的に証明することが難しい点です。 ユーザビリティの向上によって売上が伸びたことは、統計データからある程度は予想することはできますが、絶対とは言えません。 経営者の中にはユーザビリティの向上による利益を疑問視し、投資コストとは釣り合わないと判断するケースもあります。

モノ中心から人間中心へ

今までのデザインは、"モノ" の要求に合わせて設計されてきました。 機能、信頼性、生産性、コスト、納期、安全性、性能などです。 しかし、人間中心設計では、"人間" の要求に合わせて設計するアプローチになります。 それは、有効性、満足度、効率性、快適性などです。

モノ中心から人間中心にシフトすることで、現状の問題点を改善するレベルから、新しい魅力を創り出すレベルまで向上させることを目指します。 現状の問題点の改善とは、分かりにくい点、間違いや無駄な操作を改善して効率性を向上させることです。 人間中心の設計は、そこから一歩進んで、やりたいことが思い通りにできることや、今までできなかったことができることを目指し、新しい魅力を創り出すプロセスです。

人間中心の開発アプローチは、ユーザや利益関係者 (ステークホルダー) に大きな経済的、および社会的利益をもたらします。 使いやすいシステムや製品は、技術的にも商業的にも成功する傾向する傾向があります。

人間を中心に設計されたシステムは、以下のメリットがあります。

  • ユーザの生産性と組織の業務効率の向上
  • システムの理解と使用が容易になり、トレーニングとサポートのコスト削減
  • アクセシビリティの向上
  • ユーザエクスペリエンスの向上
  • 不快感、およびストレスの軽減
  • ブランドイメージの改善、および競争上の優位性確保
  • 持続可能性目標への貢献

このような人間中心の設計は、人間中心設計 (human-centered design:HCD) と呼ばれ、ユーザビリティに大きな影響を与えました。

人間中心設計とは

人間中心設計 (human-centered design) とは、問題を解決するプロセスのすべての工程において、人間の視点を含み問題解決の設計、および管理するフレームワークのことです。 狭義の Web サイトの設計においては、UX を中心とした設計や、改善するプロセスを指します。 人間中心設計は、イギリスの人間工学者である Shackel, B. が提唱し、ユーザビリティ工学の基礎を築くことになりました。

人間中心設計の設計プロセスは、1999 年に ISO 13407 として国際規格化され、その後 2010 年に改定され ISO 9241-210 が制定されました。 また、日本語化されたものは JIS 規格の JIS Z 8530 となっています。

ISO 9241-210:2010 の定義では、ユーザのニーズや要件に、人間工学やユーザビリティの知識・技術を適用することにより、システムを有用なものにすることを目指すアプローチと定めています。 このアプローチは、有効性、効率性、幸福度、満足度、アクセシビリティ、持続可能性を高め、健康、安全性、パフォーマンスに悪影響を及ぼす可能性のあるものを防止します。

利用状況の把握と明示

利用状況の把握と明示は調査のプロセスとなります。 ユーザの要求を知る技術が求められます。 その手法の例として、アンケート、インタビュー、フォーカスグループ、フィールド調査/観察、エスノグラフィー調査などがあります。

対象製品をどのような人が、どのような環境で、何のために、どのように使用するかを明確にします。 状況の把握は、市場調査や技術調査だけではなく、利用現場でのユーザの様子を観察したり、インタビューするアプローチも含まれます。

そのような調査によって情報を収集・分析し、ユーザの特性、環境の特性、仕事の特性を具体的に明らかにするプロセスになります。

ユーザの特性として、想定するユーザ層、年齢層、知識レベル、スキルなどがあります。

環境の特性として、対象製品が使用される環境の特性、物理的環境 (空間・温度・時間帯など)、社会的環境 (組織・言語・法律・文化など) があります。

仕事の特性として、実現されるインタラクション、精度・速度・信頼度などがあります。

ユーザと組織の要求事項の明示

ユーザと組織の要求事項の明示は分析のプロセスとなります。 ユーザの要求をシステムの要求に変換する技術が求められます。 その手法の例として、ユースケース図、ペルソナ分析、シナリオベースドデザイン、ペーパープロトタイピングなどがあります。

ユーザと組織の要求事項の把握のために作成するドキュメントと、記述する内容は以下のとおりです。 また、各ドキュメントには根拠となるデータや、その収集・分析方法も求められます。

  • 製品開発戦略書:製品開発の目的、市場における位置付け、市場へのインパクトなど
  • ユーザ分析書:想定されるユーザの範囲、想定されるユーザの動向、開発される製品に関わるステークホルダーなど
  • 要求分析書:ユーザ視点での要求事項、ステークホルダーからの要求事項、異なった要求項目感の優先順位など
  • 法規分析書:準拠すべき法律、国際規格、国内規格、産業規格など
  • 利用品質定義書:製品が達成すべき利用品質 (理解性・取得性・運用性・魅力性) の目標、利用品質目標評価のための指標など

設計による解決策の作成

設計による解決策の作成は作成のプロセスとなります。 デザインや設計案を作り込むための技術が求められます。 その手法の例として、対話の原則 (ISO 9241-110 (JIS Z 8520))、対話設計 8 つの黄金率、難作業を簡単にする 7 原則、各種 HCD ガイドラインなどがあります。

このプロセスは、要求仕様に従って具体的な設計を行います。 アウトプットとして、基本設計 (コンセプト設計、技術設計、インタラクション設計など) や運用設計 (教育訓練方法、マニュアル作成指針) があります。 設計の妥当性を確認するためにはシミュレーションやモデル、モックアップなどがあります。 これらのプロトタイプを用いて、利用者からの視点で設計の確認を行います。

要求事項に対する設計の評価

要求事項に対する設計の評価は評価のプロセスとなります。 デザインや設計案の妥当性を評価する技術が求められます。 その手法の例として、HCD 評価チェックリスト、ユーザビリティテスト、ヒューリスティック評価、認知的ウォークスルー、プロトコル分析、パフォーマンステスト、操作ロギングなどがあります。

このプロセスは、人間中心設計の中でもっとも重要なステップです。 利用品質が確保できるかどうかは、設計の問題点を正しく発見できるかどうかにかかっています。 問題点を正しく発見するためには、正しい評価を行う必要があるためです。 問題点が発見できれば、再設計・再評価を反復することで利用品質は改善されていきます。

評価のステップと成果物は、計画 (評価方法、データ収集方法)、評価とフィードバック (分析方法、課題)、改善要求 (課題の優先度、改善策)、改善があります。 また、設計の評価は「設計改善のためのフィードバックの提供」、「ユーザおよび組織の目標を達成したかどうかの査定」、「長期的なモニタリング」によって実施されます。

人間中心設計とユーザ中心設計

人間中心設計 (human-centered design) と ユーザ中心設計 (user-centered design) は、類似した概念であるため、しばしば同じ意味で混同されます。

ユーザ中心設計は人間中心設計よりも歴史が古く、1986 年にアメリカの認知工学者である Donald Arthur Norman が著書 "The Design of Everyday Things" の中で提唱したものです。 同書の中で、ユーザのニーズに基づいて行うデザインを "ユーザ中心設計" という用語を使って表しました。 ユーザ中心設計は、タスクの構造を簡素化し、物事を可視化し、マッピングを正しくし、制約を利用し、誤りが起きないようにデザインすることです。

ISO の定義では、人間中心設計の方が、ユーザだけではなく多数のステークホルダーまで言及しているため、やや範囲が広くなっています。 社会的な問題まで包括して解決策を組み込むか、特定のユーザの問題のみを扱うかによって、いずれかの設計方法を選択することになります。 しかし、人間中心設計もユーザ中心設計もプロセスや手法に大きな違いはありません。

提唱者の専門分野の違いから、人間中心設計は人間工学の操作性に重点を置き、ユーザ中心設計は認知工学の認知性に重点を置いています。 現在のユーザビリティでは、いずれの要素も取り入れらた考え方になっています。

人間中心設計もユーザ中心設計も、設計時にはペルソナ/シナリオ法が用いられます。 ペルソナ/シナリオ法は、架空のターゲットユーザ (ペルソナ) を仮定し、要求分析を行う方法です。 ペルソナとして選定されるターゲットユーザには、年齢、性別、職業、住所、家族構成など、様々な属性が与えられます。

ペルソナ/シナリオ法の要求分析は、ペルソナが満足するための目標設定を行います。 ペルソナが製品をどのように操作し、どのように学習していくかシナリオを作成し、検証していく過程でユーザビリティに関する問題点を洗い出します。

ペルソナ/シナリオ法のメリットは、設計や実装時にインターフェースや操作性の制約が、ハードウェアやプログラムによって左右されない点です。 また、ペルソナという架空のユーザがいることで、ユーザ視点に立った要求が見えやすいというメリットもあります。

ただし、ペルソナ/シナリオ法にはデメリットもあります。 詳細は、次の人間中心設計の誤解と批判で述べます。

人間中心設計の誤解と批判

人間中心設計とは問題を改善するために繰り返すプロセスであり、ユーザの要求に応える設計手法ではありません。 つまり、ユーザが要求していることを単純に作ることは人間中心設計ではありません。

ユーザは、いつも正しいとは限りません。 ユーザの要求は、ただの思いつきかもしれませんし、本質的な課題を解決するような要求ではないかもしれません。 しかし、現場ではユーザが神格化され、要求をそのまま実装してしまうケースは珍しくありません。 人間中心設計は、ややアカデミックで現場ではユーザの声を無視するわけにもいかないため、本来論からは外れてきています。

Norman は「モノの使用を決定するのはデザインの中でもっとも難しい部分なので、人間中心設計の原則は、できるだけ長い間、問題を特定することを避け、その代わり暫定的なデザインを繰り返すこと」と記しています。 つまり、ユーザでさえ問題の本質や、それらを解決するための最適なデザインを提示することは難しく、安易に実装してはならないと述べています。

人間中心設計は、人間中心という設計哲学の根本とも言える部分に対して批判があります。 つまり、"人間" とは誰のことを指すのか?という問いです。

デザイナーがターゲットユーザを決める場合、ペルソナ分析を行ったり、ユーザのモデル化を行ったり、シナリオをデザインしたりします。 しかし、そうやって作られたユーザは架空のものであり、見当違いで的外れか、ユーザを神格化してしまう原因となります。 デザイナーはユーザの行動や問題をすべて把握することはできません。 しかし、分析を行っていると、あたかもユーザを理解したつもりになっている場合があるため、一部では人間中心設計は危険で有害であるとさえ評価されています。

また、特定のユーザに最適化された製品を作る場合、ターゲットから外れたユーザには苦痛を強いることになります。 例えば、初心者と熟練者に対して、同じインターフェースを提供した場合、お互いを最適化することはできません。 初心者に最適化すると熟練者は冗長だと感じ、熟練者に最適化すると初心者は難解だと感じます。

人間は、すべて調和の取れた論理的な存在ではなく、ときには理解を超えた行動をする矛盾した存在として理解するべきです。 そのため、人間中心設計のベストプラクティスとしては、"利用状況の把握と明示" の調査プロセスで、ユーザの要求をそのままデザインするのではなく、利用状況やステークホルダーのニーズから総合的に設定します。

ユーザビリティの定義

ユーザビリティの代表的な定義は 2 つあります。 国際標準化機構による "ISO 9241-11" と、ヤコブ・ニールセンの著書「Usability Engineering (日本語訳:ユーザビリティエンジニアリング原論)」に登場する "ユーザビリティ特性" です。

ユーザビリティを構成する規格
ユーザビリティを構成する規格

ISO 9241-11/JIS Z 8521

ISO 規格である ISO 9241-11 は、ユーザビリティを以下のように定義しています。

  • ユーザビリティ:特定の利用状況において、特定のユーザによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザの満足度の度合い。
  • 有効さ:ユーザが指定された目標を達成する上での正確さ、完全性。
  • 効率:ユーザが目標を達成する際に、正確さと完全性に費やした資源。
  • 満足度:製品を使用する際の、不快感のなさ、および肯定的な態度。
  • 利用状況:ユーザ、仕事、装置 (ハードウェア、ソフトウェア、および資材)、ならびに製品が使用される物理的、および社会的環境。

1998 年に成立した ISO 9241-11 は、JIS Z 8521として 1999 年に JIS 化され、ユーザビリティに関する厳密な定義が行われています。 具体的には、ユーザビリティとは "ある製品が、指定された利用者によって、指定された利用の状況下で、指定された目標を達成するために用いられる際の有効さ、効率及び満足度の度合い" として定義されています。 有効さ (effectiveness) は、"ユーザが、指定された目標を達成する上での正確さと完全さ"、効率 (efficiency) は "ユーザが、目標を達成する際に正確さと完全さに費やした資源"、満足度 (satisfaction) は "不快さのないこと、及び製品使用に対しての肯定的な態度" という定義がされています。 有効さと効率の 2 つの概念は、相互排他性があります。 また、満足度は部分的に有効さと効率に従属する関係性を持ちます。 なぜなら、有効であり効率的であれば、それによってユーザが満足感を得られるからです。

ISO 9241-11 のユーザビリティの定義は、ヤコブ・ニールセンの定義と比較して広義の意味になっており、大きなユーザビリティ (big usability) と呼ばれることがあります。 ISO 9241-11 のユーザビリティの定義は、その後、ISO 13407 や ISO 20282、CIF (ISO 25062) などの各種の規格においても用いられることになり、ユーザビリティに関する標準的定義であると言えます。

ソフトウェアのユーザビリティ

ソフトウェアのユーザビリティは、ソフトウェア品質特性モデルと呼ばれ、ISO/IEC 9126 (JIS X 0129-1) に定義されています。 品質特性は 6 つの大きな分類と、それぞれいくつかの副特性の定義で構成されています。

ソフトウェアの品質特性 ISO/IEC 9126 (JIS X 0129-1)
ソフトウェアの品質特性 ISO/IEC 9126 (JIS X 0129-1)

ユーザビリティは、使用性の品質特性に分類されます。 使用性は、「指定された条件下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力」であると定義されています。 使用性を度合いを表す副特性として、理解性、習得性、運用性、魅力性、使用性標準適合性の 5 つがあります。

  • 理解性:ソフトウェアが特定の作業に特定の利用条件で適用できるかどうか、およびどのように利用できるかを利用者が理解できるソフトウェア製品の能力
  • 習得性:ソフトウェアの適用を利用者が習得できるソフトウェアの能力
  • 運用性:利用者がソフトウェアの運用および運用管理を行うことができるソフトウェア製品の能力
  • 魅力性:利用者にとって魅力的であるためのソフトウェア製品の能力
  • 使用性標準適合性:使用性に関連する規格、規約、スタイルガイドまたは規則を遵守するソフトウェア製品の能力

ヤコブ・ニールセンのユーザビリティ特性

ヤコブ・ニールセンの著書「ユーザビリティエンジニアリング原論」では、インタフェースのユーザビリティとは、以下の 5 つのユーザビリティ特性を定義しています。

  • 学習しやすさ:システムは、ユーザがそれを使ってすぐ作業を始められるよう、簡単に学習できるようにしなければならない。
  • 効率性:システムは、一度ユーザがそれについて学習すれば、後は高い生産性を上げられるよう、効率的な使用を可能にすべきである。
  • 記憶しやすさ:システムは、不定期利用のユーザがしばらく使わなくても、再び使うときに覚え直さないで使えるよう、覚えやすくしなければならない。
  • エラー発生率:システムはエラー発生率を低くし、ユーザがシステム使用中にエラーを起こしにくく、もしエラーが発生しても簡単に回復できるようにしなければならない。また、致命的なエラーが起こってはいけない。
  • 主観的満足度:システムは、ユーザが個人的に満足できるよう、また好きになるよう楽しく利用できるようにしなければならない。
システムの受容性の構成
システムの受容性の構成

上記の定義は、人間工学、認知工学、感性工学的な側面を考慮したものになっていますが、網羅的、かつ相互排他的になっていないため、概念定義としては不十分なものとなっています。 また、学習のしやすさや効率などの要素は、"問題がない" ことと定義しています。 これは 0 レベルからマイナス方向に減らないようなネガティブな評価方法であると言えます。 一方、ISO では 0 レベルからプラス方向に増やすようなポジティブな評価方法になります。 その意味で、ヤコブ・ニールセンのユーザビリティは、小さなユーザビリティ (small usability) と呼ばれることがあります。

また、ユーザビリティとユーティリティを合わせた概念として "ユースフルネス (usefulness)" という上位概念を位置付けています。 これは ISO9241-11 のユーザビリティ定義に近いものになっています。 しかし、ヤコブ・ニールセンの定義するユーザビリティは、ISO 9241-11 よりも意味が限定的であり、ISO 13407 とは内包関係にあります。 ヤコブ・ニールセンの定義では、"ユーザが望む機能をシステムが満たしているか" は、ユーティリティ (実用性) に含んでいます。 しかし、ISO 13407 の定義するユーザビリティは "その機能をユーザがどれくらい便利に使えるか" という意味であり、ユーティリティとは区別しています。

学習のしやすさ

学習のしやすさは、ある意味でもっとも根本的なユーザビリティ特性です。 すべてのシステムは簡単に学習できるようにするべきであり、ユーザに使い方のトレーニングを強いるべきではありません。

学習のしやすさは、初心者ユーザと熟練者ユーザで習熟スピードが異なります。 学びやすいシステムである場合、初心者ユーザは短時間で習熟レベルに到達します。 一方で、熟練者ユーザは知識がある分、逆に新しいシステムの習熟スピードが遅くなる原因になります。 しかし、あるタイミングから初心者ユーザの効率性を上回るようになります。

初心者と熟練者の学習曲線
初心者と熟練者の学習曲線

習熟度は、時間に比例した線形的な伸び方ではなく、曲線的な伸び方になります。 このような曲線的なグラフになるのは、システムの複数の機能を少しずつ習熟することで、徐々に効率化されるためです。

ユーザは、システムのすべてのインターフェイスを学習してから使い始めるわけではありません。 ごく一部のインターフェイスを学習し、徐々に自分の使える範囲を拡大していきます。 多くの場合は、重要な機能や、よく使う機能から学習します。

学習のしやすさを測定するには、システムの習熟度を数値化して測定します。 習熟度を測定するためには、ユーザが特定の作業を時間内に終わらせることができるかで評価します。 システムのすべての機能が使いこなせることは、測定や評価の対象ではありません。

効率性

効率性は、学習曲線が水平になった時点、つまりパフォーマンスレベルが一定した状態をピーク値として定義します。 複雑な操作が必要なシステムの場合、熟練者のレベルに到達するまで数年かかるものもあります。

効率性を測定する場合、システムの経験者を選出しますが、"経験" には決まった時間的な定義がありません。 多くの場合、そのシステムを一定期間以上使用している人を経験者として定義します。 このような定義方法は、経験者がいない新しいシステムの実験によく使われます。

効率性の測定は、テストユーザにシステムを一定時間使ってもらい、それから効率を測定します。 測定は特定の作業にどれだけの時間がかかるかを継続的に測定し、パフォーマンスがそれ以上伸びなくなった時点で安定レベルに到達したと評価されます。

記憶しやすさ

記憶のしやすさは、不定期にシステムを利用するユーザに対して有効な指標です。 不定期ユーザは、初心者ユーザと熟練者ユーザとは異なり、断続的にシステムを利用するユーザを指します。

不定期ユーザは、以前にシステムを利用したことがある点において初心者ユーザと区別されます。 不定期ユーザが初心者ユーザと異なる点は、システムを過去に学習済みであり、一からの学ぶ必要がなく思い出すだけで利用することができる点です。

記憶のしやすさは、原則的にシステムを再利用するときの指標であり、システムを初めて利用するときの指標ではありません。 記憶のしやすさの測定方法は、不定期ユーザに対して標準的なユーザテストを行う方法と、システムの使用後に記憶テストを行う方法があります。

一般的に記憶のしやすさ特性は、前者の標準的なユーザテストが用いられます。 しかし、複雑で多機能なシステムである場合、不要な機能や、重要でない機能が後者の記憶テストによって思い出せないという形で洗い出すことができます。

エラー発生率

どのようなシステムにおいても、エラーの発生率は可能な限り少なくするべきです。 ここでのエラー発生率とは、"目的を達成しないあらゆる行動" と定義されています。

エラー発生率の測定方法も、そのような行動が起こった回数によって測定されます。 また、エラー発生率の測定は他のユーザビリティ特性の測定時に併せて行うことが可能です。

エラー発生率の測定方法の難しいポイントは、ユーザがすぐに修正できて、処理速度が多少落ちる以外に何の影響もないエラーなどは、エラーとしてカウントしないことです。 そのようなエラーは、ユーザの処理時間という観点から測定された使用効率として評価されるべきです。

エラーは、すべて同じようにカウントせず、重大さによってカテゴライズすることが推奨されています。 例えば、ユーザがミスに気付かない、または修正できないエラーや、作業に対して致命的なダメージを与えるエラーは、他のエラーとは区別してカウントするべきです。

主観的満足度

主観的満足度は、ユーザがシステムを使うことがどれのくらい楽しいかという特性で、特に重要な特性です。 主観的満足度の高いシステムは、ユーザが長時間使用していてもストレスを与えず、特にエンターテイメントの分野において重要視されます。

主観的満足度は、その他の特性とは異なり、何かの作業を効率的に行うスピードよりも、どれだけ楽しい体験ができるかに価値があります。

主観的満足度の測定方法は、ユーザに簡単な質問を使ってユーザテストを行います。 ユーザの回答内容は主観的ですが、多数のユーザから回答をまとめた統計データは満足度の客観的な測定結果となります。

多くの場合、ユーザは質問に対して一番難しい、または一番悪いと感じた点を答えます。 ある実験では、作業の中で一番難しい操作が全行程時間の中でわずかな時間であったにも関わらず、主観的な評価ではその操作について多くの回答が得られました。 このことから、全体のパフォーマンス向上を目標としている場合、ユーザの評価だけに頼ると全行程の評価ができない場合があります。

ユーザビリティの効果

ヤコブ・ニールセンは、開発プロジェクト予算の 10 % をユーザビリティに回すことで、ユーザビリティを 135 % 向上すると述べています。 シンプルなユーザテストは 2 ~ 3 日程度で、その結果からデザインの改善点に関するヒントを得られるため、ユーザビリティへの投資対効果は高くなります。

ヤコブ・ニールセンは、ユーザビリティを測定した 42 件のデータを分析した結果、平均してトラフィックは 150 %、生産性は 161 %、ターゲット機能の利用率は 202 % に改善したことが分かりました。 ユーザビリティのメリットはコストを上回るため、将来的にはユーザビリティに回す予算は増大すると予測しています。

ヤコブ・ニールセンがそのような予測を行ったのは 2003 年ですが、2017 年のアメリカ国内における研究開発費への投資額のデータを見ると、予想を超えるペースで予算額が増大しています。 Amazon、Google、Intel、Microsoft、Apple などの企業は 1 兆円を超える投資を行っています。 特に Amazon は売上額の 20 % を超える額を投資に回しています。 Amazon のような EC サイトでは、ユーザビリティの改善が売上に直結するため、より大きい金額を投資している点は納得感があります。

日本では、経済産業省が 2002 年にまとめた「人間生活指向型製品の製造・販売に係る経済的効果などに関する調査研究」に、効果がまとめられています。 アンケート調査結果によると、使いやすい製品の 64 % が人気が高く、50 % がこれらの製品により企業のブランドイメージが向上し、企業予測の 30 % を超えた売上を記録しました。 また、従来品と比べて以下のメリットが期待されます。

  • 機能や性能の改善や革新 (本質的効果)
  • 機能や性能に対するコストの向上、省エネ化の向上 (金銭的効果)
  • より短時間での操作、より簡単な操作 (時間的効果)
  • 設置や収納の場所の削減 (空間的効果)
  • 操作の身体的、精神的負荷の改善、操作の快適性の向上 (身体的効果)
  • 騒音、熱発生、空気汚染の軽減 (精神的効果 A)
  • 多用なデザイン・色彩による選択自由度、斬新性による愛着感、使用の楽しさの向上 (精神的効果 B)

ユーザビリティの設計

ユーザビリティを考慮したソフトウェアの開発は、人間中心設計で説明した「ISO 13407 コンピュータを用いたインタラクティブシステムのライフサイクルプロセス」があります。 この規格では、どのようにして人間中心設計を開発で確保していくかを、プロセスマネジメントとして規定しています。

組込みシステムにおけるユーザビリティを向上させるための基本的な考え方として、一貫性フィードバックわかりやすさの 3 つのキーワードがあります。 この 3 つは重要な設計原則であり、ユーザビリティの高い製品を実現するためには、これらの原則に従う必要があります。

一貫性

一貫性とは、ユーザが操作を覚えやすく、スムーズに利用できるユーザビリティを指します。 具体的には、画面レイアウト、画面遷移の構成、操作や表示におけるデザインの一貫性などです。

操作手順や表示のデザインに一貫性を持たせると、一部の操作手順を覚えるだけで他の機器や、他の操作の学習コストを下げて応用できることになります。 一貫性を持たせるためには、用語、ボタンの配置、カラーリング、画像の表現、メッセージ表示などのユーザインタフェース全体を統一します。

フィードバック

インターフェースの世界でフィードバックとは、ユーザの行動に対する機器からの返答のことを指します。 フィードバックは、画面上に表示されるメッセージだけでなく、スイッチの ON/OFF、LED の点灯/消灯、電話機のプッシュ音、音声ガイダンス、バイブレーション機能などもフィードバックに含まれます。

フィードバックは、機器の操作を行う上でユーザに気付きを与え、目的のタスクを達成するために判断に迷わず、直感的に認識、または理解できるため、ユーザビリティとして重要な意味を持ちます。 効果的なフィードバックを実現するためのポイントとしては、フィードバックの速度の考慮操作ミスの可能性を減らす仕組みを入れる機器の状態や操作を理解するための仕組みを入れるがあります。

「フィードバックの速度の考慮」とは、ユーザの操作に対して素早く適切なレスポンスを返すことです。 フィードバックを行う目標の時間は設計時に明確にすることが重要です。 例えば、テレビのリモコンで電源を入れて、本体の LED が 1 秒を超えて点灯する場合、多くのユーザは反応していないと認識してもう一度電源ボタン押してしまいます。 このようなケースでは、ON/OFF を繰り返してしまうことになるため、ユーザビリティとして重大な問題になります。

「操作ミスの可能性を減らす仕組みを入れる」とは、ユーザがミスをしてもその場で気付きを与え、誤操作を行わないような仕組みのことです。 例えば、背景色や警告音などの視覚・聴覚に訴える方法が効果的です。 一般的にはメッセージなどのテキストよりも、瞬間的に気付く視覚・聴覚の効果の方が有効であると言われています。

「機器の状態や操作を理解するための仕組みを入れる」とは、ユーザが操作結果を理解するため、操作前後の状態をわかるようにすることです。 例えば、ビデオレコーダーでは、電源を OFF にしても終了処理があるため、電源が完全に切れるまでに遅延が生じます。 しかし、ユーザにはそのような事情は分からないため、終了処理を行っているメッセージを表示するなどして、ユーザが理解するためのフィードバックが重要になります。

フィードバックには大きく分けて操作前と操作後の 2 種類があります。 操作前には、「説明情報」、「選択可能状態」、「選択不可状態」、「待ち状態」があります。 操作後には、「操作の反応」、「操作の判定」、「実行前の確認」、「操作結果」、「操作過程の表現」があります。

操作前のフィードバックについては以下のとおりです。

  • 説明情報:フォーカスされたボタンなどへ注意事項や説明を表示する
  • 選択可能状態:ボタンがオンにできる状態であるなど、対象の操作が操作可能であることを示す
  • 選択不可状態:ボタンがオンにできない状態であるなど、対象の操作が操作不可能であることを示す
  • 待ち状態:機器やソフトウェアが処理を実行中であり、すべての操作を受け付けないことを処理の待ち時間の表示などで示す

操作後のフィードバックについては以下のとおりです。

  • 操作の反応:ユーザの操作への反応を示す (ボタンが押されたことを示すなど)
  • 操作の判定:処理を進める前にユーザの操作が適正なものか判断し、適正でない場合は判定を促がす
  • 実行前の確認:後戻りできない操作に対して、ユーザに実行の確認を取る
  • 操作結果:操作が完了、または完了できなかった場合、情報や結果を表示する
  • 操作過程の表現:機器が行っている操作の過程を示し、ユーザに状況を認識させる

わかりやすさ

製品が不具合により動かなかった場合でも、使い方が分からない場合でも、ユーザにとっては要求が達成されないという意味では同じです。 そのため、「わかりやすさ」はユーザビリティ上、重要な意味を持ちます。

わかりやすさには、「操作のわかりやすさ」、「構成のわかりやすさ」、「見やすさ」があります。

操作のわかりやすさには、以下の観点があります。

  • 操作手順がシンプルでわかりやすい
  • 次の操作に迷わない
  • 操作内容がすぐに理解できる
  • エラー内容が容易に理解できる
  • 警告音やサウンドを効果的に使用している

構成のわかりやすさには、以下の観点があります。

  • 難しい専門用語や略語を使用してない
  • 重要な情報が強調されている
  • 用語やアイコンに統一感がある

見やすさには、以下の観点があります。

  • 表示の明るさが適切である
  • 文字の大きさ色が適切でメリハリがある
  • 表示される情報が多すぎない

対話の 7 原則

ISO 9241 では、視覚表示装置 (VDTs) を用いたオフィス作業に対する人間工学的要求事項を取り扱っています。 ISO 9241 は、第 1 章 ~ 第 17 章で構成されていますが、その中でユーザビリティについて述べられているのは第 10 章 (ISO 9241-10、後の ISO 9241-110) と第 11 章 (ISO 9241-11) です。 ISO 9241-10 では「対話の原則」として、一般用語で表した人間工学的原則を示し、ISO 9241-11 ではユーザビリティを定義しています。 対話の 7 原則は以下のとおりです。

  • 仕事への適合性 (suitability for the task)
  • 自己記述性 (self descriptiveness)
  • 可制御性 (controllability)
  • 利用者の期待への合致 (conformity with user expectations)
  • 誤りに対しての許容度 (error tolerance)
  • 個人化への適合性 (suitability for individualisation)
  • 学習への適合性 (suitability for learning)

仕事への適合性

仕事への適合性とは、ユーザインタフェースにより目的とする仕事 (タスク) を効果的、かつ効率的に行えるを示します。 例えば、携帯電話では相手の番号をアドレス帳に登録することにより、次回からの通話を効率的に行えるナビゲーションを実装しています。

ユーザが、製品を利用する様々な局面で実行するタスクを明確にし、具体的な操作手順を設計することが "仕事への適合性" です。 そのためには、事前にユーザの典型的な行動を分析し、タスクを理解する必要があります。

自己記述性

自己記述性とは、ユーザが操作している対象を、即座に理解できる、または機器からのフィードバックによって状態をすぐに理解できることを示します。 例えば、ビデオレコーダーでは、番組の録画予約を失敗しないために、予約操作最中に選択した番組のテレビ画面への表示、同一時間帯に予約済みの番組が存在している場合には、警告やその番組名の表示、操作完了後に予約完了のメッセージ表示をするなどです。

機器はユーザからの操作に応じて適切なフィードバックを返す必要があります。 そのために設計者は、画面のデザインや操作ボタン・操作手順の設計を工夫することが必要です。

可制御性

可制御性とは、ユーザが目標に到達するまでの操作を制御できることを示します。 例えば、Google マップでは、ユーザが地図のスクロールの速度や幅を調整できるように設計されています。

可制御性が低いシステムでは、操作の途中でわからなくなったり、操作を中断することがあります。 つまり、ユーザはシステム操作の主導権を失ってしまいます。 このような状態にならない、またはこのような状態から回復できることを「可制御性」と呼びます。

利用者の期待への合致

「利用者への期待への合致」とは、システムの操作がユーザの理解度、経験、常識と矛盾がないことを示します。 例えば、複合機プリンターでは、異なる機能においても択や決定の操作方法の一貫性が保たれ、ユーザが操作に迷わないように設計されています。

ユーザは、機器を利用する場合、ある程度は利用の仕方を想定しています。 ユーザの想定に合わせて操作全体を構成することで、操作の開始時や操作途中で迷うことが少なくなります。

誤りに対しての許容度

「誤りに対しての許容度」とは、誤操作に対して、最小の訂正作業、または訂正作業なしでも、意図した結果に到達できることを示します。 例えば、ユーザがファイルを削除する際には、現在の操作が「ファイル削除」であることを強調し、確認メッセージを表示、および削除済みフォルダに一定期間保存するなどです。

基本的には誤った操作が少ないユ一ザインタフェースを設計することが前提です。 しかし、もしもの場合は復旧できる設計が求められます。 また、安全性に関わる操作には、注意を促したり、確認のステップを入れることで誤操作を防止します。

個人化への適合性

「個別化への適合性とは」、ユーザの嗜好や熟練度、機能の必要性に合わせて機器の設定をカスタマイズ可能にすることです。 例えば、家電製品で時計やタイマー機能は不要と思うユーザのために、時計を非表示にできるよう設計をするなどです。

しかし、カスタマイズ可能な機能を増やすことは、機能が複雑化し、ユーザビリティが低下する危険性があります。 特に、安全性が求められる製品や、不特定多数の人が利用する公共の機器のカスタマイズ設定は、慎重になるべきです。 他にも、カスタマイズの設定は特定の権限を持つユーザに限定するなどの予防措置もあります。

学習への適合性

「学習への適合性」とは、機器がユーザの機器の使い方を学習することに対して支援を行い、誘導することです。 例えば、デジタルカメラなどで、異なる撮影モードで撮影した時、どのような違いが発生するか確認できるような機能を設け、ユーザが常に適切なモードを選択していくように学習する仕組みの設計をします。

ユーザが機能の効果を実感でき、機能や操作を学習できるように設計します。 そのためには、用語をわかりやすくする、ユーザが覚えることを減らすなど、ユーザの学習コストを下げる配慮も重要です。

安全工学とユーザビリティ

安全工学は、「人はミスをする」、「機械・システムは故障する」との前提で、安全を工学的に保証する技術です。 これらは、ユーザビリティの高いソフトウェアの開発をする上でも重要な指針となります。

人間の見間違い、操作ミス、判断ミスによって意図しない結果が起きた失敗や事故をヒューマンエラーと呼びます。 ヒューマンエラーは、JIS Z 8115:2000 において意図しない結果を生じる人間の行為と規定されています。

ヒューマンエラーは、しばしば人災とも呼ばれ、責任を追求する事態に発展します。 しかし、ヒューマンエラーは人災などではなく、何らかの原因でミスが発生した結果です。 安全工学では、人災と呼ばれる事例は故意や過失を指し、失敗や事故とは区別しています。

見間違いをしたのは、警告やメーター類の表示が見にくかったのではないか。 ボタンの押し間違えは、ボタンの形や色、配置が悪かったのではないか。 操作を間違えたのは、焦り、疲れ、眠気、緊張、やる気などが原因ではないか。

ヒューマンエラーは人間の体調、心理状況、社会的背景も含まれます。 例えば、1999 年に発生した大韓航空 8509 便墜落事故では、社会的背景によって機長と副操縦士の間に明確な上下関係があり、機長の誤った判断を誰も止められなかったために起きた事故とされています。

安全工学は、ヒューマンエラーを予防・対策を行い、安全を工学的に保証します。 そのため、ある程度のユーザビリティを犠牲にする場合もあります。 例えば、カーナビは自動車の走行中には操作ができないように設定されている場合があります。 これは、ユーザビリティを犠牲にしてでも、走行中の安全性を優先している例になります。

ただし、上記のカーナビの場合、ユーザビリティが低いとは評価されません。 なぜなら、ユーザビリティは、すべての安全性を優先して初めて実現するからです。 上記のヒューマンエラーを防ぐためには、予防策と対応策があります。

予防策としては、下記のものがあります。 啓発や注意喚起するもの、注意力や意識が散漫になることを防ぐもののほか、「人間は間違える」ことを前提とした対策が考案されてきました。

  • 危険予知トレーニング
  • 指差し確認
  • メモやチェックリストによる記憶エラー対策
  • 疲労を起させないための勤務時間管理、適度な休息
  • ガム・コーヒーなど眠気覚ましになるものを喫食する。
  • ダブルチェック・トリプルチェック

対応策としては、下記のものがあります。 主に物理的なものや機械的バックアップによるものとなります。

  • 安全距離 (保安距離)
  • 安全装置
  • フェイルセーフ
  • フールプルーフ
  • アフォーダンス
  • 多層防御

ユーザビリティテスト

ユーザビリティテストとは、ユーザが実際に Web サイトをどのように扱うかを観察、および意見を聞くことで問題点を発見する評価手法です。 ユーザビリティテストは、どれだけ意図された目的が達成されているかを測ることに重きを置いています。 ユーザビリティテストは "検証" であり、後述するアンケート評価などの "調査" とは明確に評価方法を区別しています。

ユーザビリティテストでは少なくとも "観察者" と "被験者" がいます。 被験者は、検証対象である Web サイトを利用したいくつかのタスクを行い、観察者はその様子を記録します。 また、被験者からのフィードバックを受けるために、事前/事後アンケートなどを用いることもあります。

ユーザビリティテストのひとつで、無作為に選ばれたユーザに商品やサービスを利用してもらう "ホールウェイテスト" と呼ばれる手法もあります。 人通りの多い都心部などでは、街頭で新商品のテストを行っている場合もあります。 新デザインの初期段階において、それ以上進めなくなるほどの致命的な問題、すなわち "煉瓦の壁" を発見するために役立ちます。 プロジェクト内のエンジニアや関係者など近しい者は一般的な意見ではなく、専門家としての意見を述べてしまいがちであり、致命的な問題であるにも関わらず見過ごしてしまう可能性があるため、ホールウェイテストが行われます。

ヒューリスティック評価

ヒューリスティック評価とは、専門家がユーザビリティのチェックを行い、問題点と改善案を抽出する評価手法です。 ヒューリスティックとは "経験則" という意味で、ユーザビリティエンジニアが経験則から問題点を導きます。 ユーザビリティテストと比べて柔軟性があり、被験者を必要とせず、評価期間が短く、コストが少ないことが特長です。 ヒューリスティック評価が適している例としては、企画段階や設計段階におけるユーザビリティの評価、またはプロトタイプにおけるユーザビリティの評価です。 ウォーターフォール型のような積み上げ式の開発では、最終段階で問題点を指摘されても大幅な変更を行うことが難しいため、開発の初期段階で問題点を指摘してもらう方法が有効です。

ヒューリスティックスとしては、以下のヤコブ・ニールセンのユーザビリティ 10 原則が有名です。

  • システム状態の視認性を高める
  • 実環境に合ったシステムを構築する
  • ユーザーにコントロールの主導権と自由度を与える
  • 一貫性と標準化を保持する
  • エラーの発生を事前に防止する
  • 記憶しなくても、見ればわかるようなデザインを行う
  • 柔軟性と効率性を持たせる
  • 最小限で美しいデザインを施す
  • ユーザーによるエラー認識、診断、回復をサポートする
  • ヘルプとマニュアルを用意する

認知的ウォークスルー法

認知的ウォークスルー法は、人の認知過程を基準にした評価法です。 ヒューリスティック法と同様に複数の評価者によって行われ、設計仕様書やプロトタイプから改良点を探します。 具体的には、ユーザの目標、意図、入力選択、入力実行、ディスプレイの知覚、解釈、評価のプロセスの問題点を、設計仕様書やプロトタイプから探します。 プロセスを 7 段階に分けていることで、どの段階で問題があるかが明確になるため、改良案を考えやすいという利点がありますが、認知科学の専門家が必要となります。

A/B テスト/多変量テスト

Web 開発やマーケティングおいて、A/B テスト、または多変量テストは、期待するユーザの行動特性を最大化させる Web ページ上の要因を特定することを目的としたテストです。 例えば、商品の購入ボタンの色は赤色と青色の場合、どちらがより多く購入されるかなどです。 ユーザの行動特性を調べるために、ボタンの色だけを変えた A と B の 2 種類のページを用意し、どちらのページがより効果的であったかを調べます。 大規模な EC サイトでは、テストの結果がわずかな差であっても、全体の利益を考えると大幅な増益になる可能性があります。

A/B テストでは、上記のようにボタンの色のみを変更したほぼ同じデザインのページをテストすることを指すように思われがちですが、大幅にデザインを変更した 2 種類のパターンを試すテストも A/B テストと呼ばれます。 また、A/B パターン以外にも C や D のパターンを同時に試す場合は A/B/C/D テストなどとも呼ばれます。 ただし、ページのパターンを増やす場合、各ページにトラフィックが分散するため、パターンを増やしすぎると有効な統計データも少なくなります。 A/B テストで重要な点は、個々のパーツにおける影響を調べるのではなく、サイトの目標、目的に対してどのように影響があるのか調べることです。

A/B テストと仕組みは同じですが、より多くのパターンを試す多変量テストもあります。 多変量テストは完全実施要因テストとも呼ばれます。 多変量テストとは、Web に配置されたパーツの組み合わせ毎の影響を調べるテストです。 例えば、大規模な EC サイトの場合、ボタンの色の他に、セールス文言、レイアウト、画像の色使い、レビュー欄、コメント欄、ヘッダー、フッターなど多くのパーツがあります。 それらのパーツをどのように組み合わせると成果が最大になるのかテストを行うのが多変量テストです。 多変量テストでは、組み合わせの種類が膨大な数になることもあるため、トラフィック量の多いサイトでなければ有効な統計データが収集できません。

アンケート評価 - WAMMI

WAMMI (Web site Analysis and MeasureMent Inventory) はユーザの主観的評価を測定することを目的に開発された評価手法で、5 つの尺度でユーザビリティを測定します。

具体的なアンケート内容や、尺度、計算方法などは非公開であり、英語、フランス語、ドイツ語、イタリア語などのヨーロッパの言語には対応していますが、日本語には対応していません。 WAMMI のサイトに掲載されている SCALES は以下の通りです。

  • Attractiveness (魅力)
  • Controllability (操作性)
  • Efficiency (効率性)
  • Helpfulness (有用性)
  • Learnability (学習しやすさ)
  • Global Usability (グローバルユーザビリティ)

アンケート評価 - WUS

WUS (Web Usability Scale) とは、富士通とイードが共同で開発した Web ユーザビリティを定量的に評価するためのアンケート評価手法です。 Web ユーザビリティに関する 21 項目のアンケート項目を 5 段階評価で行い、その結果から生成される 7 つの評価要素で評価します。 WUS の評価要素は以下の通りです。

  • 操作のわかりやすさ
  • 構成のわかりやすさ
  • 見やすさ
  • 反応のよさ
  • 好感度
  • 内容の信頼性
  • 役立ち感

ログデータ分析法

ジャーナルログやアプリケーションログなどから、ユーザがどのような操作を行ったのか分析する評価方法です。 これらのログデータには、どのユーザが、どの画面で、どのような操作を行ったのかすべて記録されています。

この評価方法は、定量的なデータを得ることができるので、客観的な統計データを取得できる利点があります。 しかし、初心者ユーザは目的とは異なる画面を表示させたり、違うボタンを押したりするため、データにはノイズが入ります。 そのため、マニュアルなどが用意されており、決まった手順で操作する場合に、どの部分を改良すれば効率が上がるかを評価する場合に有効です。

携帯電話や情報家電などの組込み系のソフトウェアは、専用のハードウェア上で動作するため、製品そのものを使用しての評価が難しくなります。 その場合、コンピュータ上で動作するプロトタイプやエミュレータを別に作成して評価を行うことがあります。

まとめ

ユーザビリティという言葉はありふれたものになっていますが、具体的に説明をする場合、とても難しいことに気付きます。 言葉の意味が広すぎるために、やや主観的な意味で使われる場合が多くなっていますが、いくつかの特性は客観的に測定が可能です。 ユーザビリティを向上させるためには主観的な意見に振り回されず、客観的なデータを積み重ねて改善することが重要です。

このページでは、「ユーザビリティとは何か?」という、もっとも基本的な問いに対して掘り下げてきました。 ユーザビリティの基本について理解できたら幸いです。