2015 年度 修士論文
操作履歴を基にした Android アプリケーション のユーザビリティ評価支援手法に関する研究
2016 年 2 月 1 日（月）提出
指導：深澤 良彰 教授
早稲田大学大学院 基幹理工学研究科 情報理工・情報通信専攻 深沢研究室
学籍番号：5114F080-1
松澤 岬
i
第1章 はじめに ... 1
第2章 ユーザビリティ ... 3
2.1 ユーザビリティ概念の定義 ... 3
2.1.1 ISO 9241-11における概念 ... 3
2.1.2 Jakob Nielsenの概念 ... 4
2.2 UIデザイン ... 5
2.3 ユーザビリティ評価 ... 6
第3章 統計学的分析 ... 9
3.1 正規性検定 (Shapiro-Wilk test) ... 9
3.2 Parametric test ... 9
3.2.1 F test ... 9
3.2.2 T test ... 9
3.3 Non-Parametric test ... 10
3.3.1 Wilcoxon rank sum test ... 10
第4章 関連研究 ... 11
4.1 テストスクリプト自動生成による評価の効率化 ... 11
4.2 GUI操作による状態モデルの自動生成 ... 11
4.3 UIの画面遷移情報による評価 ... 12
4.4 評価モデルと基準データの再編成 ... 12
4.5 ベンチマーキングによる評価基準の形成 ... 13
第5章 本研究の特徴 ... 14
5.1 情報取得、評価の自動化によるコスト削減 ... 14
ii
5.2 問題箇所の明確化 ... 15
5.3 具体的な問題内容の抽出 ... 15
第6章 Nielsenの10箇条の対応付け ... 17
第7章 本研究の概要 ... 19
7.1 ユーザテストにおける事前準備 ... 20
7.1.1 ユーザプロフィール ... 20
7.1.2 タスク・ステップの設定 ... 21
7.2 ユーザの操作履歴取得 ... 22
7.2.1 ロギングツール ... 22
7.2.2 Logcatツールの設定 ... 23
7.2.3 AndroidアプリケーションでのGUIの作成方法 ... 26
7.2.4 操作履歴取得のための追加ソースコード・リソースIDの認識 ... 26
第8章 本研究によるユーザビリティ評価 ... 28
8.1 問題箇所の明確化 ... 29
8.1.1 各評価項目の回数の計測方法 ... 29
8.1.2 取得データにおける統計的分析 ... 30
8.2 問題箇所における問題内容の明確化 ... 32
第9章 本手法の評価 ... 34
9.1 ユーザテスト設定 ... 34
9.1.1 対象Androidアプリケーション ... 34
9.1.2 ユーザプロフィール ... 34
9.1.3 タスク、ステップ設定 ... 35
9.2 ユーザビリティ評価 ... 37
9.2.1 問題箇所の評価 ... 37
9.2.2 問題内容の明確化 ... 42
ii
第10章 考察 ... 46
第11章 おわりに... 48
謝辞 ... 49
参考文献 ... 50
研究業績 ... 54
1
第 1 章 はじめに
近年、一般ユーザのタブレットによるアプリケーションの利用が世間に浸透 し始めている。世界的な市場ではモバイル端末のオペレーティングシステムと
して Android と iOS のアカウント数が約 90%を占めている [1]。市場の中で
OSの比較としては現在、Androidのシェア率はiOSの約2倍である [2]。その シェア率の上昇傾向はこれからもさらに高まるだろう。さらに普及を促進させ るためにはユーザの満足度が必須と考えられる。また、グラフィカルユーザイ ンタフェース（GUI）のユーザビリティがユーザの満足度に強く関係している と考えている。タブレットのアプリケーションにおいて、ユーザの満足度は
Android アプリケーションよりも iOSのアプリケーションの方が高いという調
査結果が出ている [3]。ユーザの満足度を向上させるためには、Androidアプリ ケーションのユーザビリティを向上させる必要がある。しかし、タブレットは 新たな操作性を持つため、タブレットにおいて実行されるアプリケーションの ユーザビリティを向上させるために行われるユーザビリティ評価の手法に関す る研究が重要になってくる。
ユーザビリティとは、一般的に「使いやすさ」、「使い勝手」のように和訳さ れることが多い。ソフトウェアのユーザビリティは、ユーザの利用目的、利用 頻度、ソフトウェアにおける知識などの情報によって変化してくるため、ユー ザビリティの定義を 1 つに絞ることは非常に困難である。しかし、より高いユ ーザビリティを持つソフトウェアを開発しなければ、ユーザはユーザビリティ の低いソフトウェアを利用しなくなり、ソフトウェア開発に用いた時間や労力 が無駄になってしまう。
変化していくユーザビリティに対応させるために、ユーザテストを行い、そ のテストの情報を利用してユーザビリティ評価を行う必要がある。ユーザビリ ティ評価を行えば、ソフトウェア上でのユーザの操作を解析、評価できる。さ らに、何度もこの過程を繰り返すことで、よりユーザビリティの高いソフトウ ェアを開発することができるようになる。しかし、従来のユーザビリティ評価 の手法としては、テスティングルームでのユーザテストを記録[4][5]し、ユーザ ビリティの知識のある専門家などによる評価が行われるというものが主流とな
2
っていたが、これは専門家への評価依頼のコストや評価時間がかかる。
そこで私たちはタブレット向けのインターネットに依存しない Android アプ リケーションをユーザビリティ評価する手法を提案する。本手法はユーザの操 作履歴を統計的な分析することで、特定の箇所に存在するユーザビリティ上の 問題を発見することができる。問題箇所とは評価者が定めたユーザの操作手順 のことである。評価者はユーザビリティ評価を実施するユーザビリティにおい て知識のある人である。さらに、本手法は問題箇所における具体的な問題内容 も評価者に示すことができる。ユーザが行ったタップやスクロールのような操 作や操作時間から得た問題箇所においてNielsenのヒューリスティクス10箇条 と照らし合わせることで問題内容が分かるようになっている。問題内容とはそ の具体的な操作内容と対応したNielsenの10箇条の項目において満たされてい ないことを表している。つまりどこに問題箇所があり、どのような問題内容が あるかが明確になるため修正点が認識しやすく、修正点を発見するための労力 削減、時間短縮ができるようになっている。
本論文では、本章を含め、9章から構成される。第2章では、本研究の核とな る部分であるユーザビリティ、UIデザインについて述べる。第3章では、本研 究の目的であるユーザビリティ評価について述べる。第 4 章では、本研究分野 に関する既存の研究を紹介する。第 5 章では、本研究の特徴について述べる。
第6章では、本研究の核となるNielsenの10箇条に関して述べる。第7章では、
本研究の主な流れについて述べる。第8章では、本手法の詳細について述べる。
第9章では、本手法の有効性に関する評価結果を述べる。第10章で評価結果の 考察を述べる。第11章では、本研究の内容と成果を総括し、今後の課題につい て述べる。
3
第 2 章 ユーザビリティ
ユーザビリティとは、一般的に「使いやすさ」、「使い勝手」のように和訳さ れることが多い。しかし、それらの言葉で表現される意味とは異なった意味も ユーザビリティには含まれている上に、ユーザの利用目的、利用頻度、システ ムにおける知識などの情報によって変化するものである。
2.1 ユーザビリティ概念の定義
ユーザビリティ概念の定義は、様々な条件から変化していくことから 1 つに は絞り切られていないが、独自にユーザビリティ概念を定義している規格や人 物は存在している。代表的なものとして国際標準化機構のISO 9241-11の規格
やJakob Nielsenが提唱した概念に関して以下に示す。
2.1.1 ISO 9241-11 における概念
ISO 9241-11[6]では、ユーザビリティではなく、「使用性」という用語が用い
られた。この「使用性」は、ユーザの理解に関する労力を表す理解性、ユーザ が利用できるまでにかかる時間を表す習得性、利用するために操作するまでに かかる負担を表す運用性という要素によって構成されていて比較的広い意味で 扱えるようになっている。規格化された概念としては、有効さ、効率、満足度 の 3 つによって表現されている。ISO 9241-11 における使用性の概念を図 2.1 に示す。また、それぞれの意味を以下に示す。
図 2. 1 ISO 9241-11におけるユーザビリティ概念 使用性
有効さ 効率 満足度
4
有効さ
ユーザが評価者の定めた課題を達成する上で、評価者の要求に対してどのく らい正しい操作を行なえるかという正確さ、課題のどのくらいの割合を達成で きるかという完全さ
効率
ユーザが評価者の定めた課題を達成する際、正確さ、完全さに費やした資源
（操作にかかった時間、操作上でのエラー数など）
満足度
システムを操作した際、ユーザにとって不快さのないこと、及びシステム使 用に対しての肯定的な態度
2.1.2 Jakob Nielsen の概念
Jakob Nielsen の概念[7]は、ユーザビリティはユーティリティというものと
対比させることで表現している。ユーティリティとは製品における機能や性能 といったポジティブな側面を意味している。この概念のユーザビリティは、わ かりやすさを表す認知性、取り扱いやすさを表す操作性、心地良さを表す快適 性といった面において問題点をなくしていくという非ネガティブな側面を意味 している。問題点をなくしていくという非ネガティブな側面からユーザビリテ ィに関して考えている理由としては、Jakob Nielsenが経験則から問題点を発見 し、なくしていくという手法が重要と考えているからである。Nielsenのユーザ ビリティ概念の構成[6]を図2.2に示す。また、Nielsenはよりわかりやすい表現 をするため、ユーザビリティを構成する要素として、学習可能性、効率性、記 憶可能性、エラー、満足度という表現もしている。5 つの要素[7]それぞれに関 して以下に示す。
使い勝手
ユーザビリティ ユーティリティ
認知性 操作性 快適性 機能 性能 図 2. 2 Nielsenにおけるユーザビリティ概念
5
学習可能性
システムは、ユーザがすぐに処理を開始することができるくらい操作の習得 が容易に設計されていなければならない。
効率性
システムは、ユーザが操作を 1 度習得した後、より高度な生産性を上げるこ とが可能となるように、効率的な利用をできるように設計しなければならない。
記憶可能性
システムは、ユーザが 1 度でも操作を習得した場合、そのシステムに関心の 薄いユーザであっても時間が経過したときに勉強し直さずに利用できるように しなければならない。容易にシステムの操作を記憶できる設計をしなければな らない。
エラー
システムは、ユーザが操作を行う上で低いエラー率である必要がある。エラ ーが少ない中で発生してしまったエラーに関しても、容易にそのエラーを回復 できるような設計にしなければならない。
満足度
システムは、ユーザが快適に操作を行える必要があり、操作しているユーザ が主観的に満足、今後も操作のしやすさという意味で使いたいと思えるように 設計しなければならない。
2.2 UI デザイン
UI(ユーザインタフェース)デザインとは、ビジュアルデザインとインタラクシ ョンデザインという 2 つのデザイン構成を考慮することでユーザビリティを向 上させることを目的としたデザインのことである。ビジュアルデザインとイン タラクションデザインに関しては以下に示す[8]。
ビジュアルデザイン
実装されたアプリケーションにおける画面上の GUI オブジェクトに注目し、
アイコンの形状や色彩、メニューバーやタブバーなどの配置などを決定してい
6 くデザインである。
インタラクションデザイン
実装されたアプリケーションにおける操作の流れに注目し、画面遷移やアプ リケーションの全体像を把握しやすいような画面を生成していくデザインであ る。
2.3 ユーザビリティ評価
評価とは、開発途上のプロトタイプや世間に出回っているものをある評価基 準と照らし合わせることで、ユーザの生活や業務でどのように適合しているか を判断していき、不適合な部分が存在していた場合はそれを改善していく活動 である。ユーザビリティ評価は、その活動において認知心理学的特性や人間工 学的特性などの人間として共通で普遍的な部分、調査によって得られたユーザ の目標や社会的な状況に関するものといった情報を評価基準としてユーザビリ ティの改善、向上を行うことである。
ユーザビリティ評価の種類は、大きく 2 つに分類される。その 2 つの評価方 法であるユーザビリティテスト、インスペクション法に関してそれぞれ以下に 示す。
(1) ユーザビリティテスト
ユーザビリティテスト[6]はユーザテストとも呼ばれ、従来テスティングルー ム（マジックミラーなどが備え付けられている部屋）にてユーザに評価したい システムを操作してもらい、ユーザビリティの知識を持つ専門家がユーザの操 作の様子を解析し、評価していく方法である。そのテストにはユーザの操作履 歴、表情などを記録するためのビデオカメラ、ユーザにテストの操作を支持す る進行係が必要である。また、専門家は進行係とは別に必要で、ユーザの操作 に影響しないよう空間的に遮られた場所からユーザを観察していくような仕組 みになっている。テスティングルームがもし準備できなかった場合においても、
ユーザと専門家を空間的に遮ることで、ユーザに専門家を意識させないように しなければならない。どこでテストを実施する場合でもそのような準備を行い、
ユーザの操作履歴を取得しなければ効果的な結果を得ることができないとされ ている。
ユーザビリティテストの手法としては、パフォーマンス評価、主観評価、イ ンタラクション評価の3つがある。それぞれの詳細を以下に示す。
7
パフォーマンス評価
「使いやすさ」を評価していく手法である。時間の計測やユーザのエラー数 などの計測をすることで、作業速度やエラー率といった定量的なデータを得る ことができる。利点としては、計測の作業が単純であるため評価の実施が容易 であるという点である。一方、欠点として時間とエラー数などだけでは、ユー ザがどのように問題に直面しているのかということが把握できない点である。
主観評価
操作を経験した上でユーザの主観的印象や感じたことをアンケートなどで評 価する手法である。ユーザが操作を行った結果、例えば、「スムーズに感じた度 合い」、「不快に感じた度合い」などを 5 段階で回答してもらうことで、主観的 なデータを数値化することで定量的なデータを得ることができる。利点として は、質問内容が多くあるためより幅広くデータを収集することが可能な点であ る。欠点は、パフォーマンス評価と同様にユーザがどのように問題に直面した かが把握できない点である。
インタラクション評価
「わかりやすさ」を評価する手法である。この手法は、テストを受けている ユーザの操作を観察することで、「どの箇所で問題につまずいているか」、「どの ように問題を解決しているか」といった情報を得ることができる。利点として は、多くの項目に関しての評価が可能であり、具体的な問題点を把握すること ができる点である。欠点としては、ユーザの細かい操作履歴を解析するため、
手間がかかってしまう点、さらにテストを受けるユーザの知識、経験量や評価 者のスキルによって評価結果が変化してしまう点である。
(2) インスペクション法
インスペクション法[6]は、専門家の経験則で対象物を単独で評価していく手 法である。この手法に共通する利点は、設備や被験者の準備を必要としないた め費用が掛からない点、開発途中のライフサイクルに容易に取り入れることが できる点、問題が発生した場合でも速やかに解決する点がある。欠点は単独で の作業であるため、どうしても主観的な固定概念などが存在してしまう点であ る。固定概念によってユーザビリティには必要不可欠な点に気付けない可能性 も出てくる。インスペクション法の種類としてはヒューリスティック評価、認
8
知的ウォークスルーの2つがあり、それぞれを以下に示す。
ヒューリスティック評価
ユーザビリティの知識を持つ評価者が単独で、一定の原則に照らし合わせな がらユーザビリティを評価していく手法である。また、一定の原則とはヒュー リスティクスとして膨大な量の項目が考案されている。ソフトウェアのUIでも UIがドキュメンテーション（文書など）でも分析する場合はヒューリスティク スに適用させることでより優れた製品になるとされている。膨大な項目のある ヒューリスティクスの中でもNielsenの考案した10箇条のユーザビリティヒュ ーリスティクス[7]、Gerhardt-Powals による 10 個の認知的設計原則[7]などが 存在する。
認知的ウォークスルー
認知プロセスを熟知する専門家がユーザにとっての学びやすさなどの有効性 に絞って評価をする手法である。ユーザが問題解決する場合のシミュレーショ ンを行って、開発途中でも評価することが可能だが、評価者が認知心理学また は認知的ウォークスルーのプロセスの教育を受けている場合にしか効果を発揮 することができない手法である。
9
第 3 章 統計学的分析
統計学とは複数のデータの分布や大きさなどを求めたり、様々な分析や誤差 などの検定を行ったりするために用いられる手法である。その中でも検定とは データである標本を基に母集団に関して仮説が成立するかどうかを判定するた めの手法である。データ全てを求められている場合、検定は必要ないが実際に 求められるデータはごく一部であるため検定を用いることで傾向をつかむこと ができる。
3.1 正規性検定 (Shapiro-Wilk test)
正規性検定[9]とはデータの母集団において分布型が正規分布[10]になってい るかを判定するための検定である。正規分布はデータが中央の値に最も多く存 在し、増加、減少するに伴い左右対称の形でデータが減少していく分布型であ る。
3.2 Parametric test
Parametric testとは検定を行う際、データにおいて特定の分布条件を満たし
た場合に用いられる検定の総称である。様々な検定が存在するが今回はF test、
T testの詳細を述べる。また、F test[11][12]、T test[13]は共にデータの分布型
が正規分布であることが条件となっている[14]。
3.2.1 F test
F testはT testを行うにあたって2種類データの母分散が等しいかどうかを
判定するために用いる。ここで 2 種類データの関係性が等分散か不等分散かを 判定できる。
3.2.2 T test
T test は 2種類データの母集団における平均値に差があるかどうかを判定す
10
る検定手法である。そこでT testにはデータの分布型において異なった種類の
T testを行う必要性がある。3.2.1の結果によって2種類データの関係性が等分
散なのか不等分散なのかを判定した上で以下のT testをそれぞれ行っていく。
具体例としては、男性の平均身長と女性の平均身長といった独立した 2 種類の データにおいて有意差があるかどうかに用いられる。
Student’s t-test … 2種類データの分布が等分散の場合
Welch’s t-test … 2種類データの分布型が不等分散の場合
3.3 Non-Parametric test
Non-Parametric test[15][16]とは検定を行う際、データにおいて特別な分布 型を満たしていない場合に用いられる検定の総称である。また、データの標本 数が小さい場合や分布型が不明な場合などにも利用できるが Parametric test よりも有意差があることを判定できる可能性は低い手法である。様々な検定が 存在するが今回はWilcoxon rank sum testの詳細を述べる。
3.3.1 Wilcoxon rank sum test
Wilcoxon rank sum test[17][18]は2種類データの関係性が非正規分布である
ときの中央値に差があるかを判定する検定である。正規分布時の検定である T test に類似した結果を得ることができる。特別な分布型の特徴もなかったり、
データの標本数が小さかったりする可能性があるためデータにおいて小さい順
（もしくは大きい順）に順位を割り当てる。その順位の平均値を求めることで 検定を行っていくためデータの特徴に関係なく検定を行うことができるように なっている。
11
第 4 章 関連研究
4.1 テストスクリプト自動生成による評価の効率化
Mark GrechanikらはGUIのイベントリスナなどのソースコードの情報を複
数のバージョンが存在するアプリケーションを比較することで差異を明らかに する。そこでGUIのイベントリスナにおいて木構造のような認識をし、差異か ら変更点を明らかにした結果からユーザビリティ評価をするためのテストスク リプトを自動生成するための手法を提案している[14]。
たいていのテストスクリプトは様々な GUI-based Applications (GAPs)を関 連付けることで生成されるが、Mark Grechanikらは修正された新しいGUIオ ブジェクトの情報と古いバージョンの GAPsを比較することで修正点が明確に なすることを可能とした。 インターネットに依存したアプリケーションであろ うがそうでないアプリケーションでも関係なくテストスクリプト生成は可能で ある。しかし、複数のバージョンが存在しないアプリケーションにおいてこの 手法は利用できない。また、テストスクリプトを自動生成することはできるが 実際にアプリケーションをユーザビリティ評価していくためにはユーザビリテ ィの知識を持った評価者が必要となってくる。
4.2 GUI 操作による状態モデルの自動生成
Wontae ChoiらはAndroidアプリケーションのGUI情報（どのようなイベン
トリスナが認識されているかで判定）としてユーザがどのような操作手順を辿 るのかを明確にし、ユーザビリティ評価を効率化する手法を考案している。そ こでユーザが操作することで自動的に操作順序のパターンを状態モデルとして 生成できるSwiftHandという手法を提案している[19]。
アプリケーションのGUI情報を探索し、自動的に操作手順を生成するために は必ずデータ更新のためにアプリケーションの再起動が必要となる。再起動を 多くし、状態モデルのパターンを正確に更新することは信頼性の高い手法だが
12
再起動にかかる時間とコストがかかってしまう。Wontae Choiらは効率的なア ルゴリズムを考案し再起動を減らし、近似モデルの活用でアプリケーションの 確かな構成を把握することなく状態モデルのパターンを自動生成することを可 能としている。ユーザの操作手順を状態モデルで自動生成できるが、その操作 手順をユーザビリティ評価としてどこにどのような問題が存在しているかとい う手法に繋げることがまだできていない。ユーザビリティ評価によってどのよ うな問題内容がアプリケーションに存在しているのかを把握していく必要があ る。
4.3 UI の画面遷移情報による評価
Xiaoxiao Ma らはアプリケーションへ埋め込み型のシステムによって、予め
設定したいくつかのタスクをユーザがどのように遷移していくかを明らかにす る。これによって、どのタスクにUIの問題が含まれているかを明確にする提案 をしている[20]。
具体例として AppJoy というアプリケーションにおいてタスクを設定し、ユ ーザにテストを受けてもらっている。その結果、ユーザの操作でどのようなイ ベントリスナが実装されているかを認識させることで操作履歴を取得した。そ のデータからユーザがタスク間をどのように遷移しているのかを示し、ユーザ ビリティの問題がどのタスクに存在しているかを見つけ出している。この研究 では、抽出したユーザビリティの問題としてはテスティングルームでのテスト 結果と同等のものを得ることできたと述べられている。しかし、ユーザテスト 時にユーザの画面遷移における予期せぬ動きによって情報が部分的に取得でき ない場合があった。さらに、タップやスクロール、削除の操作といった内容の ユーザの操作の詳細を示す反応には対応していない。よって問題の詳細を抽出 することは困難である。
4.4 評価モデルと基準データの再編成
Artur H. Kronbauerらは基準となるデータを収集し、ユーザビリティ評価す
るモデルを構成し、そのモデルをメトリクスのデータやユーザの感情的なデー タと統合することでユーザビリティを向上させる手法を提案している[21]。
モデルではアプリケーションのソースコードとユーザの相互作用に関係する コードを照らし合わせることでマッピングし、オリジナルのソースコードを生
13
成する。そのソースコードには、ユーザのプロフィールや操作履歴 (操作時間、
タスクの完遂といったユーザの相互作用、明度、雑音などの文脈的なデータ、
ユーザの感情)といったデータ項目に対応している基準を新たに組み込む。そし て、追加されたソースコードと既存のデータを照らし合わせることでユーザビ リティの情報を抽出すると述べている。評価の方法に関してはどのように照ら し合わせていくのかなどは詳しく書かれていなかった。
4.5 ベンチマーキングによる評価基準の形成
Brian Kimball Dunnらは、ユーザビリティの向上を考えている熟練者がより
ユーザビリティ評価を容易に行えるようにすることを目的とした。そのために デルファイ方式を用いることで評価において有効性の高いタスク設定をする手 法を提案している[22]。
この研究では、ソーシャルネットワークを通じて条件を満たした被験者を集 めた。その被験者にスマートフォンを通常通り利用してもらうことで、得た情 報においてデルファイ方式を用いることで、必要なタスクを設定した。そして、
アプリケーションの利用頻度、それぞれの被験者へのアンケートによってアプ リケーションの重要性を数値化している。その利用頻度とユーザの感じる重要 性に相関関係があることを示し、ユーザビリティの高さを評価するためにデル ファイ方式によるタスク設定は利用できると述べている。しかし、評価条件に 適した被験者などを募集したり、被験者の情報をまとめたりすることなどを考 えるとデータを解析するまでに時間がかかる。さらにそれぞれのアプリケーシ ョンを実装中、ユーザがどのような操作を行っているかというようなことを把 握することが困難である。
14
第 5 章 本研究の特徴
5.1 情報取得、評価の自動化によるコスト削減
PC のソフトウェアにおけるユーザビリティ評価の研究は多く行われている。
しかし、タブレットは新たな操作性を持つため、インターネットに依存するし ないにかかわらずタブレットで実装されるアプリケーションにおけるユーザビ リティ評価の研究は始まったばかりである。ユーザの操作履歴を自動で取得す る研究はいくつか存在している[14][19][20][21][22]が、評価までを自動で行う研 究はさらに少ない。この評価の自動化においても、イベントリスナの呼び出し を認識し、ユーザの操作による画面遷移を明確にするというものである。よっ てユーザの画面遷移だけではなく、その画面上での細かい操作履歴を取得する ことはできてない。ユーザの細かい操作履歴を取得するためには、従来のユー ザビリティ評価のようにテスティングルーム[6]のような設備を準備し、専門家 に依頼し、ユーザの操作の様子を観察、もしくは高価な機器を用いて操作履歴 の記録によって取得しなければならない。画面遷移の情報だけではなく、画面 上でのタップやスクロールといった操作履歴を取得することで、今までに操作 履歴からでは得ることのできなかったユーザビリティの問題点を抽出すること ができる。
このようなユーザの操作履歴、画面遷移の情報を得た後、膨大な情報の解析、
評価を行うことでユーザビリティの問題点がどの箇所に存在するかまでは自動 で行える。しかし、どのようなユーザビリティの問題点が存在しているのかと いうことを抽出することは自動では行えないため、手動で確認する必要がある。
本研究では、ロギングツールの一種であるLogcatツール[23]を利用し、ユー ザの画面上でどのくらいの時間、どのような操作を行っているのか、どのよう に画面遷移をしているのかを取得する。その取得した履歴から操作時間やシン グルタップなどの操作履歴[24]の利用頻度を自動で解析することで、問題がどの 箇所に存在するかを自動的に抽出できる。さらに、ヒューリスティクス[7]を対 応付けておくことで問題点に照らし合わせることが可能となる。本研究の情報
15
取得、ユーザビリティ評価の自動化を行うことでユーザビリティに関する知識 を持つ専門家の労力の軽減、評価にかかる時間を短縮できる。
5.2 問題箇所の明確化
ユーザビリティの問題を効率良く発見するためにはユーザが操作したより詳 しい操作の手順を認識する必要がある。操作の手順の中で問題が存在する可能 性を明確にする際、評価者が取得したユーザの操作履歴において、統計学的分 析を実施する。統計学的分析を行うことによって客観的に評価し、閾値を正確 に定めることができるため信頼性の高いものとなる。また、より詳しいユーザ の操作を認識するために本手法ではタスク、ステップという概念を用いる（第 6 章で定義を示す）。
ユーザテストの実施前にあらかじめタスクとステップを設定する必要がある。
しかしタスク、ステップの概念によってそれぞれのタスクにおける操作の難易 度だけではなく、それぞれのステップにおけるユーザの操作履歴まで分析でき る。そしてステップごとに問題が存在している可能性があるのかどうかを統計 学的に明確化することが可能である。
5.3 具体的な問題内容の抽出
ユーザビリティ評価は、問題点をなくし、ユーザビリティの向上を考えたも のであるため、どのような問題内容が存在しているのかを明確にすることがで きればソースコードの修正も容易になる。ユーザビリティの具体的な問題内容 を抽出するためには、問題の存在する可能性のある箇所を把握してからその状 況に応じた問題を膨大な量定義されているヒューリスティクスの項目に照らし 合わせながら考えなければならない。
そこで、統計学的分析によって 2 種類のユーザの間に有意な差が存在する箇 所に対応したヒューリスティクスを用意する。有意な差があった問題箇所とヒ ューリスティクスを照らし合わせることが容易になり、具体的な問題内容が問 題箇所から明確にすることが可能となる。
本手法では、Nielsenのユーザビリティヒューリスティクス10箇条[7]の定義 に沿って条件を照らし合わせられるようにした。その結果、どの箇所にどのよ うな具体的な問題内容が存在する可能性があるかを10項目に当てはめて抽出す ることができるようになる。ユーザビリティヒューリスティクスを定めて、ユ
16
ーザビリティ評価を行うため、どの観点での評価が良いか悪いかがわかりやす くなる。また、対象アプリケーションの特性やユーザの特性などに応じて重要 な観点を優先的に修正可能となる。
17
第 6 章 Nielsen の 10 箇条の対応付け
各ステップの問題箇所に対応付けていくNielsenのヒューリスティクス10箇 条[7]に関して以下に示す。また、本手法で評価対象とする項目とNielsenの10 箇条の対応表を表6.1に示す。
① システム状態の視認性
システムは、ユーザが状況に関する情報を把握しているようにすべきである。
② システムと現実世界との調和
システムは、ユーザが熟知している用語、現実世界の語句や概念を使用すべ きである。
③ ユーザの制御と自由
システムは、ユーザが操作上で不都合な事象が発生した場合、取り消しとや り直しといった回避動作をサポートすべきである。
④ 一貫性と標準
システムは、ユーザが迷わないように異なる語句や状況または行動が、同じ ものを意味しているのかどうか理解しやすいようにするべきである。
⑤ エラー防止
システムは、適したエラーメッセージの表示よりも、最初から障害を発生さ せないような注意深い設計であるべきである。
⑥ 記憶より再認
システムは、GUI オブジェクト、行動、オプションを可視化することで、ユ ーザが記憶する必要のないようにすべきである。さらにシステムの使用に関す る説明は、目に見えるか、あるいは容易に検索できるようにすべきである。
⑦ 使用の柔軟性と効率
システムは、熟練者ユーザに対する相互作用を効率化する機能を初心者ユー ザに見えないようにすべきである。また、頻繁に行う操作は、ユーザに合わせ
18 られるようにすべきである。
⑧ 美的感覚と最小限度の設計
システムは、無関係、必要ない情報を入れないようにすべきである。
⑨ ユーザがエラーを認識、判断して回復するまでのサポート
システムは、理解しやすい言語でエラーメッセージを表現し、問題点を的確 に示して、効率的に解決策を提案するべきである。
⑩ ヘルプとドキュメンテーション
システムは、必要なヘルプとドキュメンテーションの提案をし、容易に検索で きるユーザが理解しやすいように簡潔に表示すべきである。
表 6.1 評価項目とNielsen10箇条の対応表
評価項目 対応項目
操作時間
②システムと現実世界との調和
⑤エラー防止
⑥記憶より再認
選択回数
①システム状態の視認性
②システムと現実世界との調和
④一貫性と標準
⑤エラー防止
⑦使用の柔軟性と効率
⑧美的感覚と最小限度の設計 スクロールの長さ
②システムと現実世界との調和
⑥記憶より再認
⑩ヘルプとマニュアルの用意
不要なダブルタップの回数
①システム状態の視認性
②システムと現実世界との調和
④一貫性と標準
⑥記憶より再認
⑨エラーを認識、回復までのサポート 戻るボタンの利用回数
④一貫性と標準
⑤エラー防止
⑨エラーを認識、回復までのサポート
19
第 7 章 本研究の概要
本手法は、タブレットで実装された Android アプリケーションにおけるユー ザの操作履歴を取得し、その操作履歴におけるユーザビリティ評価することに よって問題箇所、問題内容を抽出する。本手法のシステムの構成を図7.1に示す。
図 7.1 本システムの構成 初心者ユーザ
熟練者ユーザ
ユーザテスト
ユーザの操作履歴 操作履歴出力機能 付きソフトウェア
ユーザビリティ評価
操作時間の情報 アクション情報
操作履歴の解析
時間の抽出 アクションの抽出
問題点
本システム
20
本研究の流れは、ユーザビリティ評価に必要な操作履歴を取得するまでと取 得した後の操作である以下の2段階から構成される。
(1) ユーザの操作履歴取得
(2) 操作履歴を基にしたユーザビリティ評価
本研究では、OSがAndroidであるタブレットを対象とし、Javaで生成され
た Android アプリケーションを対象とする。しかし、本研究で必要とする操作
履歴が取得できるロギングツール[23]を用いることが可能ならば、他のタブレッ トでも本手法の適用は可能である。また、必要とされる操作履歴のログさえあ れば本手法は利用可能である。
7.1 ユーザテストにおける事前準備
ユーザテスト[6]実施の前に評価対象となるAndroidアプリケーションにおけ る経験のレベル、前提となるタッチパネルの経験レベルなどをユーザプロフィ ールとして取得する必要がある。また、今後のユーザビリティ評価を効率的に 実施するためにユーザの操作を細かく区分けしていく必要がある。そこでユー ザプロフィールについて述べるとともに本研究で対象とする熟練者ユーザと初 心者ユーザの定義、タスク・ステップの概念を以下に示す。
7.1.1 ユーザプロフィール
本研究では初心者ユーザが熟練者ユーザと同様な操作を行うことができるア プリケーションをユーザビリティが高いアプリケーションとする。そのため
Android アプリケーションにおける熟練者ユーザと初心者ユーザを条件に合わ
せて決定していく。ユーザプロフィール[7]の役割としてユーザ情報の記録を残 すことでユーザテスト実施後、返答が必要な場合や追加実験が必要になった場 合に必要なユーザへのアプローチが容易になる。
本研究は 2 種類のユーザを区別するためにユーザテストを実施する前に評価 者が定めた基準を満たしているかどうかを確認する必要がある。そのために予 めアンケート調査の実施によって把握する。熟練者ユーザは対象の Android ア プリケーションに関する知識を備えていて、構造に関しても理解が深い人材（評 価者、開発者の可能性もある。）であるかを評価者が決定し指名する。一方、初 心者ユーザは熟練者ユーザに該当しない人材かつ対象の Android アプリケーシ
21
ョンの利用経験がなく、タッチパネルを最低限利用したことがある程度の人材 を一般募集によって決定する。アンケート調査の具体的な例を表7.1に示す。
表7.1 アンケート調査内容の例
質問項目 回答内容
○ 年齢 ( )
○ 性別 □ 男性 □ 女性
○ 職業 ( )
○ 利き腕 □ Right □ left
○タッチパネルの 利用経験
□ <1 年 □ 1–2年 □ 3–4年
□ 5–6年 □ 7–8年 □ ≥9 年
7.1.2 タスク・ステップの設定
評価対象の Android アプリケーションにおいて評価者が指定したタスクを 被験者がタブレットで実行する。タスクはユーザが目的（UMLのユースケース と類似した意味で、アプリケーションの利用でできること）を達成するために 行われる自然な操作と定義する。ステップは 1 タスクをボタンのタップや画面 遷移などの操作で細かく区切られた操作と定義する。このステップごとに評価 を行うことでそれぞれに対して問題内容を対応付けて抽出する。具体的な例と してGPS を利用した地図アプリケーションにおけるタスクXについて述べる。
タスク X はアプリケーションを起動し、出発地点、経由地点、到着地点を検索 し設定するまでの操作である。また、ステップはより詳細に説明するために図 を用いて説明する。タスクXを3ステップに区切った例を説明する。また、ス テップ 1 からステップ 2 に至る経路において操作履歴を図として可視化した一 例として図7.2を示す。
22
図7.2 3ステップで構成されたタスクX
ステップ 1 はユーザによってアプリケーションのメニュー画面が起動され、
出発地点の設定が決定されるまでの操作とする。ステップ 2 はユーザによって 経由地点の設定が決定されるまでの操作とする。最後のステップ 3 は到着地点 の設定が完了するまでの操作とする。さらに、1×、1+、1*を説明する。1×、
1+、1*は全て評価者によって指定されたステップではなく、ステップ 1 とステ
ップ2の間で行われたユーザの操作エラーを示している。1×はステップ1から 操作が行われ、目的を達成できなかったことを示す。1+は目的を達成すること はできたが繰り返しの操作が行われ、余計な手順を踏んだことを示す。1*は繰 り返しの操作ではないが無駄な手順を踏んだ上でステップ 1 の目的を達成して いることを示す。
7.2 ユーザの操作履歴取得
まず、ユーザビリティ評価を行う前にユーザの操作履歴を取得するための
logCat ツール[23]の設定に関して述べる。また、操作履歴を取得するために必
要なこと、各GUIオブジェクトの情報を識別するための考え方も述べる。
7.2.1 ロギングツール
ユーザテストを行う際、ユーザの操作履歴を取得するためにロギングツール が必要になってくる。ロギングツールとは、ユーザがシステムを操作している ときのユーザがいつどのようなアクションを起こしているのか、そのアクショ
23
ンによってシステムはどのような反応をしているのかを自動的に記録するツー ルのことである。ロギングツールを利用した場合の利点としては、ユーザの操 作履歴とシステムの反応を定量的データとして得ることができるため、そのデ ータを参考に評価を容易に行うことができるようになる。本研究で利用してい
くAndroid開発用のロギングツールであるLogCatツールに関して以下に示す。
LogCatツール
LogCat ツールは、オープンソース化されている Java 開発ツールである
Eclipseで開発を行う場合、ユーザの操作と同時にユーザの操作履歴、システム
の反応のログ(記録)を取得していくことが可能なツールである。ログのメッセー ジとしては、ログのメッセージのレベル、ログが出力された時間、実装されて いるソースのプロセスID/スレッドID(自動で振り分けられるID)、実装されて いるソースのパッケージ名、タグ(項目名)、テキスト(内容)などが出力される。
タグとテキストはソースコード内で開発者が自由に設定することが可能になっ ていて、表示したい項目名と内容を決定することができる。ログのメッセージ として出力できるレベルVerbose / Debug / Information / Warn / Errorの5段 階を以下に示す。
(1) Verbose (冗長)
実装されたプログラムがどのように動作しているかというトレース情報の詳 細が全て表示されるレベル
(2) Debug (デバッグ)
全てのトレース情報からデバッグ情報に絞り込んで出力するレベル (3) Information (情報)
実装されたプログラムによって形成されたアプリケーションがどのように動 いているかという動作情報を出力するレベル
(4) Warn (警告)
アプリケーションの復旧ができるくらいの状態を警告として出力するレベル (5) Error (エラー)
アプリケーションの実装において致命的であるエラーを出力するレベル
7.2.2 Logcat ツールの設定
24
操作履歴を出力する機能として利用していく LogCat ツールによって表示され る項目の中で項目名、内容をユーザの各アクションで出力する。また、全ての アクションの条件を認識するタイミングとしては、ユーザが画面に触れ、触れ た状態で画面を移動している場合、もしくは画面から指をどのように離したか によってアクション判定を行っている。本研究において項目名に適用するユー ザのアクション情報の種類、それぞれのアクションに関してユーザが画面に触 れたとき、どのような条件で認識されるのかということを以下に示す。
(1) シングルタップ
タップの認識後、動かさずにそのまま指を離した場合に認識する。
(2) ダブルタップ
シングルタップの認識後、すぐに同じ箇所でもう一度画面に触れ、動かさず にそのまま指を離した場合に認識する。
(3) スクロール
タップの認識後、画面から指を離さずに別の位置に動かしている間の変化全 て、動きが止まっている状態で指を画面から話した場合に認識する。
(4) フリック
タップの認識後、画面に指が触れているときはスクロールを認識している。
画面から指をはらうように移動させながら離した場合に認識する。主に文字入 力などの際、用いられることが多い。
(5) 長押し(ロングタップ / ホールド)
タップの認識後、画面に触れた状態で動かさずに一定時間経過した場合に認 識する。
これらの項目名によってユーザの画面上におけるアクションの種類を明確に している。内容は、上記に述べたアクション情報全てに共通させている。それ ぞれのアクションがどのような位置で行われているのかということを確認する ことができるように X 座標、Y座標として表示している。座標で表示されるこ とでユーザが画面上のどのような箇所に触れることで操作を行っているのか、
どのような箇所に注目しやすいのかということがわかる。さらに、ユーザが複 数の指で画面に触れた場合、ユーザによる戻るボタンでの操作、ユーザが操作 したときのリアルタイムな時間表記に関する項目名に関して以下に示す。
25 (6) ポインタ数
ユーザが複数の指で画面に触れた場合、複数の指が画面に触れたということ を認識する。
(7) 戻るボタン
ユーザによるエラーもしくは効率的に操作を行うためにタブレットに設定さ れている戻るボタンを押した場合に認識する。
(8) リソースID
ユーザが操作上でボタンやテキストボックスなどのGUIオブジェクトを選択 した場合、認識し各々が数値で表現される。ユーザによって操作されたボタン やテキストボックスなどを明確にすることができるためタスク、ステップの設 定に用いる。
(9) 時間
ユーザによって対象 Android アプリケーションが操作され、アクション情報 が出力されるタイミングの時間を示す。
「ポインタ数」の内容は、ユーザが複数の指で画面に触れた場合、触れた箇 所のX座標、Y座標、指の本数を表示できるようにしている。「ポインタ数」と いう曖昧な表示をしている理由は、複数の指を利用して行える操作は Android アプリケーションによって各々の設定が施されていることがあるからである。
よって利用頻度の比較的高いピンチイン/ピンチアウトという操作に限定させず に、複数の指で触れた後、座標を参考にしてどのような操作を行っているかを 判定するようにしている。
「戻るボタン」の内容は、画面の左下に設置されている仮想ボタンである戻 るボタンをユーザが押した場合にボタンが押されたという表示できるようにし ている。戻るボタンが押されて 1 つ前の画面に画面遷移したことが明確になる ことで、ユーザの画面遷移に関する操作履歴が把握しやすくなる。また、開発 者（もしくは評価者の可能性もある）が Android アプリケーションにおいて予 め戻るボタンを用意していた場合、仮想ボタンの戻るボタンのみがアクション の項目の「戻るボタン」ということになる。
ユーザが Android アプリケーションを実際に操作したときの具体的な操作履
歴を図7.3に示す。
26
7.2.3 Android アプリケーションでの GUI の作成方法
ユーザがどのような操作を行ったかどうかだけではなく、ステップの設定時 にGUIのどの位置を操作したかを認識する必要がある。そのために対象アプリ ケーションのGUIオブジェクト（ボタン、エディタ、スピナーなど）それぞれ を識別できるようにする。Androidでの GUI 構成は、XML形式で表すか、プ ログラムへ直接記述するかのどちらかである。本手法ではXML形式の方を推奨 する。その際、 Layout Editor[25][26]の利用により、ビジュアルに GUI 構成 を指定すると、XML 形式の GUI 構成を生成することができる。アプリケーシ ョンのGUI構成はプログラムに直接表現することも可能だが、評価者の労力が かかってしまう。また、評価者の技術的な差によって操作履歴の精度に差が出 てしまう可能性もある。そのため本手法では Layout Editor によって視覚的に 確認できる方法を推奨している。
7.2.4 操作履歴取得のための追加ソースコード・リソース ID の認識
Logcat ツールを利用してユーザビリティ評価に必要なユーザの操作履歴を
取得するために評価者がソースコードを対象のアプリケーションへ追加しなけ ればならない。
また、コンパイルしたときにGUI構成を記述したXML形式のソースコード が基となる“R.java”というファイルが自動的に生成される。このファイル内にそ
図 7.3出力されるユーザの操作履歴
27
れぞれのGUIオブジェクト情報が数値として示される。その数値はリソースID と呼ばれ、それぞれのGUIオブジェクトを識別するために用いられる。評価者 はこのリソースID と GUI オブジェクトの対応を把握しておかなければならな い。リソースID は GUI オブジェクト情報を操作履歴として出力することで、
ユーザがどのGUIを操作したかを明らかにすることができる。この方法を利用 してタスクをステップに分割することでより細かい操作の流れを分析できるよ うにしている。リソース ID を出力できるようにするために評価者、もしくは 開発者が追加しなければならないソースコードを図6.4に示す。リソースIDの 例を図7.4に示す。
⋮ 1 2 3 4
public void onClick(View v){
int id = v.getID();
String hex = Integer.toHexString(id);
Log.v("OnClick","Resource_id = " + "0x" + hex);
⋮ }
図 7.4 追加するソースコード
28
第 8 章 本研究によるユーザビリティ評価
ユーザテストの実施で取得した Android アプリケーションに関するユーザの 操作履歴において、ユーザビリティ評価を行っていく。ユーザビリティ評価を どのように行っていくかという構成を図8.1に示す。
操作時間の情報 アクション情報
操作時間
スクロール時間 シングルタップ数
ダブルタップ数 戻るボタンの利用数
問題点の抽出
Nielsenの10箇条
(ヒューリスティクス)
問題点
ユーザビリティ評価
図 8.1 ユーザビリティ評価の構成 アクション情報
本システム
29
8.1 問題箇所の明確化
まず、操作時間の情報、アクション情報を統計学的に分析することで、設定 した各ステップの中でどの箇所に問題が存在する可能性があるかを評価してい く。評価項目として定義する5項目を以下に示す。
操作時間
スクロール時間
シングルタップ数
画面遷移に無関係のダブルタップ数
戻るボタンの利用回数
8.1.1 各評価項目の回数の計測方法
操作履歴の各評価項目における計測方法は大きく分けて 3 つの方法があるた め以下に示す。また、計測方法が異なるのは評価項目において求めるべき対象 が時間、回数の違いが主な要因である。
操作時間
各タスク、ステップにおいてユーザがどのくらいの時間操作を行ったかを計 測する。計測方法は各ステップを区切るときに用いるGUIオブジェクトのリソ ースID を認識させることで求める（ステップが終了する GUI オブジェクトの リソースID が認識されたときの時間‐ステップが開始する GUIオブジェクト のリソース ID が認識された時の時間）。具体的な操作履歴を例として図 8.2 に 示す。
図 8.2 操作時間の計測方法の例
183[ms] = 10955[μs] = ⋯ 20894844 − ⋯ 20883889
30
スクロールの利用時間
スクロールの利用時間は操作履歴にScroll、Drag、Flickが含まれている行が 存在した場合に認識される。しかし、スクロールは行数の認識ではどの程度画 面にタッチし続けて操作が行われているのかが明確ではない。よって経験的に スクロールと認識されるアクションのメソッドが呼び出される速度から定めた 手法 (スクロールが認識された行・20[𝑚𝑠]) によって回数を時間に置き換えら れるようにしている。
シングルタップの回数、ダブルタップの回数、戻るボタンの利用回数 シングルタップは操作履歴にSingletap、Resource_idが含まれている行が存 在した場合に認識される。ダブルタップは Doubletap が含まれている行が存在 した場合に認識され、戻るボタンはBack buttonが含まれている行が存在した 場合に認識される。各評価項目において指定された文字列が操作履歴に含まれ たときの対応を表8.1に示す。
表 8.1 評価項目を認識するための文字列対応
アクション情報 操作履歴に表示された文字列 シングルタップ Singletap，Resource_id
ダブルタップ Doubletap
バック Back button
スクロール Scroll，Drag，Flick
8.1.2 取得データにおける統計的分析
問題箇所を明確化するために実施する手順を図8.3に示す。そしてこの手順は 主に3種類の検定によって構成され、統計的に分析するようになっている。
(1) 操作の種類、操作時間の取得データに正規性があるかどうかを分析
(2) (1)によって熟練者ユーザ、初心者ユーザ両方の取得データにおいて正規性
がある場合、2種のデータの関係が等分散かどうかを分析 (3) 2種類の取得データにおいて有意な差があるかどうかを分析
31
図 8.3 統計的分析の流れ
32
まず手順 1 として熟練者ユーザ、初心者ユーザの取得データ（各ステップの 操作の種類、操作時間）に正規性があるかどうかを分析する。利用する検定と
してはShapiro-Wilk test [9]を用いることで正規分布 [10]かどうかを判定する。
もしデータが正規分布ならば、例外処理を行わなければならない。正規分布内 に外れ値が存在すると 1 つのデータによって結果が大きく影響することがある ため必要な操作である。外れ値[10]かどうかを判定するために平均 (=μ)と標準 偏差(=σ)を利用する。そしてデータが μ-2σ より低い値か、もしくは μ+2σ より 高い値の場合は外れ値と判定される。信頼区間は一般的な 95%に設定し、これ に含まれないデータを外れ値としている。
手順2で熟練者ユーザと初心者ユーザの取得データが両方正規分布だった場
合、F test [11]を行うことで2種類のデータが等分散かどうかを判定する。その
結果に対してT test [13]を行う。判定結果が等分散だった場合、手順3として Student’s t test [13]を利用し、不等分散だった場合、Welch’s t test [13]を利用 する。それぞれのT testによって熟練者ユーザと初心者ユーザのデータ（平均）
に有意な差があるかどうかを判定することができる。
一方、手順1で熟練者ユーザと初心者ユーザのデータのいずれかが非正規分 布であった場合、Non-Parametric test [15][16] を行わなければならない。本手 法はNon-Parametric test としてWilcoxon rank sum test [17][18]を利用する。
Wilcoxon rank sum test はデータを数値としてではなく、ランクとして置き換
えてから行う検定であるため、F test、T testの流れと同様なデータの平均の有 意差を求めることができる。評価者はステップごとに平均値の有意差があるか どうかを判定することで、ユーザビリティ上の問題箇所を明確に認識すること ができる。
8.2 問題箇所における問題内容の明確化
問題箇所の評価を行うことで、ユーザの操作時間の情報、アクション情報(ス クロール時間、シングルタップ数、ダブルタップ数、戻るボタンの利用回数)か らどのステップにそれぞれの情報に関する問題が存在する可能性があるかを抽 出することが可能となる。このそれぞれの情報に Nielsen のヒューリスティク ス10箇条[7]を対応付けることで具体的な問題内容を抽出する。そこで過去の資 料 や 文 献[27][28][29][30]を 基 に ユ ー ザ ビ リ テ ィ 上 の 具 体 的 な 問 題 内 容 が
Nielsenのヒューリスティクス10箇条のどの項目に対応しているかを定める。
つまり具体的な問題内容の原因となるユーザの操作を評価項目である操作時間、
33
アクション情報に対応付ける。その結果、評価項目に対応する Nielsen のヒュ ーリスティクス 10 箇条という具体的な問題内容を導き出すことが可能となる。
問題点が存在する可能性があると判断された評価項目と Nielsen のヒューリス ティクス10箇条を表6.1により対応させる。その結果出、評価者へ提示される 問題内容の具体的な例（評価項目：スクロール）を表8.2に示す。
表 8.2 具体的な問題内容の例（評価項目：スクロール）
対応項目 可能性のある問題内容
②システムと現実世界との 調和
・ 表示された言語が不明確で理解困難
・ オブジェクトの意図を直観的に理解するこ とが困難
・ 通常使用しない言語が存在
・ 通常使用しない操作方法が存在
⑥記憶より再認 ・ 選択できるオブジェクトなのかが不明確
・ オブジェクトの意図を直観的に理解するこ とが困難
・ どの画面をユーザが操作しているか不明確
・ 操作方法が多様すぎて困難
・ 文字、オブジェクトなどのサイズが不適切
⑩ヘルプとドキュメンテー ション
・ ヘルプとドキュメンテーションの不足
・ アプリケーションの構成が複雑
・ ヘルプ、ドキュメンテーションの内容が理解 困難
34
第 9 章 本手法の評価
本手法を用いて、タブレットで実装された Android アプリケーションにおい てユーザビリティ評価を行った。その評価結果を以下に示す。
9.1 ユーザテスト設定
どのような Android アプリケーションをユーザビリティ評価したのか、どの ような被験者を対象としたのかということを以下に示す。
9.1.1 対象 Android アプリケーション
本手法によって対象 Android アプリケーションの問題箇所、問題内容が抽出 できるかを確認するために単純な構成になっている自作の家計簿アプリケーシ ョンを対象とした。家計簿アプリの構成はアプリケーションを起動させた時点 画面として日付表示画面が表示されるように設定しているためこの画面をメイ ン画面としている。他に入力項目を追加する画面、日付を選択するためのカレ ンダー画面、入力項目を月毎に表示する画面で構成されている。
対象Androidアプリケーション内で配置されているGUIオブジェクトのリソ
ースIDはあらかじめ把握しているものとし、全てが数値的に操作履歴として表 示されるようになっている。
9.1.2 ユーザプロフィール
ユーザテスト[6]の被験者は大学生を対象とし、熟練者ユーザは評価者を含む 8 名を指名し、初心者ユーザは一般応募によって 12 名の計 20 名においてテス トを実施した。その際、タブレットによる操作を行った経験があり、簡単な操 作(シングルタップ、スクロールなど)を行うことが可能であるという前提条件は アンケート調査[7]によって確認した。また、対象Androidアプリケーションの 構成を理解した上で操作において熟練しているユーザを熟練者ユーザ、ほぼ操 作が初めてという対象アプリケーションに慣れていないユーザを初心者ユーザ としている。
35
9.1.3
タスク、ステップ設定ユーザが Android アプリケーションを利用する際、違和感のない目的を設定
することで、ユーザが普段利用するような現実的な操作履歴を用いてユーザビ リティ評価を実施した。
本研究のタスク設定としては 8 タスク準備し、それぞれのタスクは 2 ステッ プから構成されるよう設定した。ステップの設定はGUIオブジェクトのボタン のみで設定してあるが必ずしもその必要はない。設定した 8 タスクの操作目的 を表9.1に示す。今回のユーザテストでは8タスクのうちタスク1と5、タスク
2と6、タスク3と7は同様な操作内容にしている。8タスクを分割した16 ス
テップにおいて、リソースIDでどのように分割しているかを表9.2に示す。ま た、本システムにおいて評価者が実際に各ステップの操作履歴から分析に必要 な情報を抽出するための操作例を図9.1に示す。
表 9.1 ユーザテストのタスク設定
タスク 操作目的
タスク1 指定した日付に項目を入力
タスク2 日付表示で項目が正しく入力されているかを確認 タスク3 月毎の表示でも同様な表示になっているかを確認 タスク4 入力した項目を日付表示で削除
タスク5 タスク1とは異なった日付に項目を入力
タスク6 日付表示で項目が正しく入力されているかを確認 タスク7 月毎の表示で同様な表示になっているかを確認 タスク8 入力した項目を月毎の表示で削除
36
表 9.2 各ステップとリソースIDの対応 ステップ リソースID (ボタンの詳細)
ステップ1 0x7f090000（追加画面へのボタン）
ステップ2 0x7f090008（項目をデータベースへ入力するボタン）
ステップ3 0x7f09000d（カレンダー画面へのボタン）
ステップ4 0x7f090040（項目表示を更新するためのボタン）
ステップ5 0x7f09000b（月毎の表示へのボタン）
ステップ6 0x7f090040（項目表示を更新するためのボタン）
ステップ7 0x7f09000e（カレンダー画面で月変更するためのボタン）
ステップ8 0x7f090040（項目表示を更新するためのボタン）
ステップ9 0x7f090000（追加画面へのボタン）
ステップ10 0x7f090008（項目をデータベースへ入力するボタン）
ステップ11 0x7f09000d（カレンダー画面へのボタン）
ステップ12 0x7f090040（項目表示を更新するためのボタン）
ステップ13 0x7f09000b（月毎の表示へのボタン）
ステップ14 0x7f090040（項目表示を更新するためのボタン）
ステップ15 0x7f09000e（カレンダー画面で月変更するためのボタン）
ステップ16 0x7f090045（アプリケーション終了のためのボタン）
図 9.1 システムの操作例
分析に必要な情報を抽出
