Comments
Description
Transcript
動的Webサイトを考慮した ユーザビリティ評価支援システムの開発 木浦
NAIST-IS-MT0751041 修士論文 Webjig：動的 Web サイトを考慮した ユーザビリティ評価支援システムの開発 木浦 幹雄 2009 年 2 月 5 日 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 本論文は奈良先端科学技術大学院大学情報科学研究科に 修士 (工学) 授与の要件として提出した修士論文である。 木浦 幹雄 審査委員： 松本 健一 教授 （主指導教員） 関 浩之 教授 （副指導教員） 門田 暁人 准教授 （副指導教員） 大平 雅雄 助教 （副指導教員） Webjig：動的 Web サイトを考慮した ユーザビリティ評価支援システムの開発∗ 木浦 幹雄 内容梗概 Web サイトのユーザビリティを改善するためには，ユーザビリティ評価を行う 必要がある．Web サイトのユーザビリティ上の問題を発見するために有効なユー ザビリティ評価手法としてユーザテストがある．しかし，ユーザテストを行うに は多くのコストを必要とするため容易に実施することができない．そこで，低コ ストでのユーザビリティ評価支援を目的とし，実際のユーザがどのように Web サ イトを利用しているかをネットワークを介して記録するシステムが提案されてい る．しかし，従来システムは Web サイト利用時のユーザ行動（マウスカーソルの 移動やマウスクリック等）を取得する際に，Web ブラウザに表示されている内容 に着目しないため，動的 Web サイトを利用するユーザ行動を把握することが難 しい．本研究では Web ユーザビリティ評価支援システムとして Webjig を提案す る．Webjig は，ユーザの Web ブラウザに表示されている内容とユーザ行動とを 関連付けて記録する．従来システムに比べ，Webjig は動的な Web サイトを利用 するユーザ行動の詳細をより正確に把握することを支援する．Webjig の有効性 を確かめるための実験を行った結果，Webjig を利用することで効率的に Web サ イトのユーザビリティを改善することができた． キーワード Web ユーザビリティ，ユーザビリティ評価，ユーザ行動の分析，動的 Web サイト ∗ 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 修士論文, NAIST-ISMT0751041, 2009 年 2 月 5 日. i Webjig: A support system for evaluating usability of dynamic websites∗ Mikio Kiura Abstract In order to improve website usability, developers need to better understand how users use websites. Usability testing is an effective method for detecting problems of usability on a website, but it requires stakeholders (e.g., users, developers, experts, and so forth) to spend a large amount of time and money. Hence developers cannot conduct the usability testing easily. So far, several systems have been proposed to automatically collect data of users’ behaviors such as mouse motions, positions of mouse click, and timings of mouse clicks by embedding JavaScript codes into a webpage. Although the systems help developers to evaluate web usability at much lower cost, they are designed not for dynamic websites but for static websites. In this paper, I introduce Webjig which is a system to resolve the problems of the existing systems. Webjig can collect user data not only from static websites but also from dynamic ones. Moreover, Webjig allows developers to precisely identify users’ activities on websites. From an experiment to evaluate usufullness of Webjig, I have confirmed that developers could improve usability of website effectively. Keywords: web usability, usability evaluation, analysis of user interactions, dynamic websites ∗ Master’s Thesis, Department of Information Systems, Graduate School of Information Science, Nara Institute of Science and Technology, NAIST-IS-MT0751041, February 5, 2009. ii 目次 1. はじめに 1 2. Web ユーザビリティ評価の現状と課題 3 Web ユーザビリティ評価の現状 . . . . . . . . . . . . . . . . . . . 3 2.1.1 ユーザインスペクション . . . . . . . . . . . . . . . . . . . 3 2.1.2 ユーザテスト . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.3 関連研究：遠隔 Web ユーザビリティ評価システム . . . . . 4 Web ユーザビリティ評価の課題 . . . . . . . . . . . . . . . . . . . 5 2.2.1 動的 Web サイトのユーザビリティ評価 . . . . . . . . . . . 6 2.2.2 自然なユーザ行動の把握 . . . . . . . . . . . . . . . . . . . 8 2.2.3 テスト被験者のリクルーティング . . . . . . . . . . . . . . 9 2.3 本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 2.2 3. 提案システム：Webjig 11 3.1 Webjig の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Webjig::Fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Web サイトへの Webjig::Fetch のインストール . . . . . . . 13 3.2.3 動作シーケンス . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4 JSONP を利用したクロスドメイン通信 . . . . . . . . . . . 17 3.2.5 DOM ツリーの差分検出および通信 . . . . . . . . . . . . . 18 Webjig::DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.1 アクセス管理エンティティ . . . . . . . . . . . . . . . . . . 22 3.3.2 DOM ツリー管理エンティティ . . . . . . . . . . . . . . . . 24 3.3.3 DOM ツリー構造管理エンティティ . . . . . . . . . . . . . 24 3.3.4 ウィンドウサイズ管理エンティティ . . . . . . . . . . . . . 24 3.3.5 キーボード操作管理エンティティ . . . . . . . . . . . . . . 25 3.3.6 マウス操作管理エンティティ . . . . . . . . . . . . . . . . 25 3.3 iii スクロールバー管理エンティティ . . . . . . . . . . . . . . 25 Webjig::Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.7 3.4 3.4.1 4. システム評価 28 4.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 動的 Web サイトのユーザビリティ評価 . . . . . . . . . . . . . . . 28 4.2.1 評価指針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.2 実験概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.3 実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.3 自然なユーザ行動の取得 . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1 評価指針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.2 実験概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.3 実験結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4 テスト被験者のリクルーティング . . . . . . . . . . . . . . . . . . 41 4.4.1 評価指針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4.2 評価概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4.3 評価結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5. 考察 43 5.1 課題 1：動的 Web サイトのユーザビリティ評価 . . . . . . . . . . 43 5.1.1 従来システムの限界 . . . . . . . . . . . . . . . . . . . . . 43 5.1.2 Web ユーザビリティ評価における Webjig の有用性 . . . . 43 5.1.3 Webjig を用いたユーザビリティ改善点の優先順序判別 . . 44 5.2 課題 2：自然なユーザ行動の取得 . . . . . . . . . . . . . . . . . . 45 5.2.1 ユーザテストの限界 . . . . . . . . . . . . . . . . . . . . . 45 5.2.2 Web ユーザビリティ評価における Webjig の有用性 . . . . 46 5.3 課題 3：テスト被験者のリクルーティング . . . . . . . . . . . . . 46 5.3.1 費用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.3.2 時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 iv 6. おわりに 48 謝辞 49 参考文献 51 v 図目次 1 遠隔 Web ユーザビリティ評価のシステムの概要 . . . . . . . . . . 5 2 ドロップダウンメニューを採用した動的 Web サイトの例 . . . . . 7 3 Webjig の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Webjig::Fetch 導入前の html ソース . . . . . . . . . . . . . . . . . 14 5 Webjig::Fetch 導入後の html ソース . . . . . . . . . . . . . . . . . 14 6 Wbjig::Fetch の動作シーケンス . . . . . . . . . . . . . . . . . . . 15 7 DOM の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8 DOM ツリーのハッシュを計算した例 . . . . . . . . . . . . . . . . 20 9 DOM ツリーの差分検出 . . . . . . . . . . . . . . . . . . . . . . . 21 10 Webjig::DB の ER 図 . . . . . . . . . . . . . . . . . . . . . . . . . 23 11 Webjig::Analysis によるユーザ行動の再生 . . . . . . . . . . . . . 26 12 実験 1 で利用する Web サイト . . . . . . . . . . . . . . . . . . . . 30 13 各ユーザのタスク完了時間 . . . . . . . . . . . . . . . . . . . . . . 31 14 カテゴリ分類による各ユーザのタスクの完了時間の比較 . . . . . . 35 15 グループ D に属する被験者の行動フロー . . . . . . . . . . . . . . 38 16 グループ E に属する被験者の行動フロー . . . . . . . . . . . . . . 39 表目次 1 各タスクで探す項目 . . . . . . . . . . . . . . . . . . . . . . . . . 29 2 実験の被験者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3 タスク 1 実行時の探索順序とカテゴリ . . . . . . . . . . . . . . . . 32 4 タスク 2 実行時の探索順序とカテゴリ . . . . . . . . . . . . . . . . 32 5 タスク 3 実行時の探索順序とカテゴリ . . . . . . . . . . . . . . . . 33 6 タスク 4 実行時の探索順序とカテゴリ . . . . . . . . . . . . . . . . 33 7 タスク 5 実行時の探索順序とカテゴリ . . . . . . . . . . . . . . . . 34 8 カテゴリ分類改善案 . . . . . . . . . . . . . . . . . . . . . . . . . 34 9 実験の被験者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 vi 10 各グループの被験者の比較 . . . . . . . . . . . . . . . . . . . . . . 37 11 各手法における費用の比較 . . . . . . . . . . . . . . . . . . . . . . 41 12 改善前と後のカテゴリを最初に探索した被験者の割合の比較 . . . 44 vii 1. はじめに 高度に発達したハードウェア，ソフトウェア，ネットワークを利用することに よって，Web ブラウザは高解像度表示，リアルタイムな情報表示など，アプリ ケーション実行環境としての高い地位を確立しつつある．ユーザは Web ブラウ ザを利用することによって，ハードウェアや OS に依存せず，インターネットを 介して，アプリケーションを利用することが可能である．一方，アプリケーショ ン開発者は Web ブラウザを実行環境としてアプリケーションを提供することに よって，アプリケーション開発期間の短縮や，サービスを早期にユーザに公開し， サービスを提供しながら改善することができるといった，従来のパッケージアプ リケーションには存在しなかったメリットがある．また，JavaScript を利用する ことで，ページ遷移せずに Web サーバと非同期通信を行い，様々な情報のやり取 りをしたり，表示中の Web ページの内容を書き換えることが可能である．これに よって Web 関連の標準規格である W3C1 に準拠しつつも，デスクトップアプリ ケーションと同等の機能，および操作性を備えた Web サイトを開発することが 可能である．Gmail2 ，Google Calendar3 ，Flickr4 等の様々な種類のアプリケー ションが Web サイト上で提供されている．それに伴い，Web サイトのユーザビ リティに対する関心が高まってきており，Web サイトのユーザビリティ向上が重 要な課題になってきている． Web サイトのユーザビリティを向上させるためには，Web サイトのユーザビ リティ評価を行う必要がある [13]．代表的なユーザビリティ評価手法としてユー ザインスペクションや，ユーザテストが存在する [15]．しかし，これらの評価手 法を用いてユーザビリティ評価を実施するためには多くの時間や費用と言ったコ ストが必要となるため，容易に実施できるものではない [9]．そのため，先行研究 として遠隔 Web ユーザビリティ評価システム [7, 8] が提案されている． しかしながら，従来の遠隔 Web ユーザビリティ評価システムには，動的な Web サイトに対応できない, 本来のユーザの行動を把握できない，テスト被験者のリ 1 2 3 4 http://www.w3.org/ http://mail.google.com/ http://www.google.com/calendar/ http://www.flickr.com/ 1 クルーティングが困難という問題点が存在する．本論文では，この問題を解決す るためにシステム Webjig を提案する． 本論文の章構成は以下の通りである．2 章では，まず Web ユーザビリティ評価 の現状と課題および関連研究について述べる．3 章では提案システム Webjig につ いて述べ，4 章では提案システムの評価について述べる．5 章で考察を行う．6 章 では本研究のまとめを述べる． 2 2. Web ユーザビリティ評価の現状と課題 2.1 Web ユーザビリティ評価の現状 Web サイトのユーザビリティを向上させるためには，ユーザビリティ評価を 行う必要がある．代表的なユーザビリティ評価の手法として，ユーザインスペク ションとユーザテストが存在する． 2.1.1 ユーザインスペクション ユーザインスペクションとは，ユーザビリティ評価者が，Web サイトのユーザ ビリティ上の欠陥や開発基準を満たしていないものを見つけ出すことである．具 体的な精査技法として，チェックリスト評価，ヒューリスティック評価，認知的 ウォークスルーなどがある [9]．ただし，どの精査技法を用いても，エンドユーザ が直面する問題をうまく予測できないことがわかっている [14]．たとえば樽本に よると，ある Web サイトの再設計プロジェクトでは，評価者 3 名でヒューリス ティック評価を行ったところ，トップページに対して 22 項目の問題点が発見され た．しかし，同じ Web サイトでユーザテスト（被験者 10 名）を実施したところ， トップページに関して発見された問題点は 7 項目であり，ヒューリスティック評 価とユーザテストで共通した問題点は 4 項目だけであった [17]． そこで，ユーザを観察することによってユーザビリティ上の問題を発見する， ユーザテストを行うことが重要であると考えられている． 2.1.2 ユーザテスト ユーザテストでは，評価対象の Web サイトを用いて，Web サイトの対象ユー ザにユーザビリティ評価者が注目しているタスク（課題）を専用ルームで行って もらう．この様子を観察し，発話や操作内容を記録する．これによって，ユーザ の思考過程や行動から Web サイトの課題が明確になったり，ユーザビリティを改 善するためのアイデアを発掘できる可能性がある．また，ユーザテストを行うこ とにより，ユーザトラブルを引き起こす Web サイト上の重大な問題点や，開発 3 者には思いもよらない問題点を発見しやすい [16]．また，近年では，視線計測装 置を利用することによって，ユーザが画面のどこに着目していたかを測定し，評 価に役立てる手法も試みられている [9]．しかし，ユーザテストを行うためには， 被験者のリクルート，専用ルームの準備など，非常に多くのコストが必要になる ため，容易に実施できない． 2.1.3 関連研究：遠隔 Web ユーザビリティ評価システム 前述のとおり，ユーザテストはユーザビリティ評価のために有効であるが，コ ストが高いため容易に実施することが出来ないという問題点が存在する．また， 被験者が普段利用している環境（ハードウェア，OS，ブラウザ等）を利用して 評価することが出来ず，被験者にとって非日常的な状況で評価せざるを得ないこ とから，発見できない問題点が存在する可能性があると考えられる [7]．さらに， ユーザは初心者から中級者，さらには熟練者になるにつれて，Web サイト上にお ける行動が変化する（たとえば，目的達成のためのショートカットを使用したり， 文章を斜め読みしたり，サイト内検索機能を使用するなど）可能性がある．しか し，長期的なユーザ行動をユーザテストで把握し，評価することはコスト面から 現実的では無い． そこで，ネットワークを介することによって，ユーザがどのように Web サイト を利用しているかを低コストで把握し，ユーザビリティの改善に役立てるシステ ムとして，MouseTrack[7] や UsaProxy[8] が提案されている． 遠隔 Web ユーザビリティ評価システムの概要を図 1 に示す．このシステムを 利用するためには，ユーザは対象の Web ページを保持している Web サーバにア クセスする前に，Web ブラウザが Proxy サーバを経由して Web サーバにアクセ スするように設定を行う．この設定によりユーザは Web サーバにアクセスする 際に，Proxy サーバに対して HTTP リクエストを行う（図 1（１））．Proxy サー バでは，Web ブラウザからの HTTP リクエストを受け取ると，Web ブラウザの 代わりに Web サーバに対して HTTP リクエストを行う（図 1（２））．そして， Web サーバから受信した HTML ファイル（図 1（３））に，JavaScript コードを 埋め込み Web ブラウザに対して送信する（図 1（４））．埋め込まれた JavaScript 4 (1)HTTPリクエスト ( 4)HTMLファイル Webブラウザ + JavaScript コード (2)HTTPリクエスト (3)HTMLファイル Proxyサーバ Webサーバ (5)ユーザ行動情報 データ収集サーバ 図 1 遠隔 Web ユーザビリティ評価のシステムの概要 コードは，ユーザのブラウザで実行され，ユーザのマウスの動きやボタン押下， 画面スクロール量などを取得し，情報収集サーバに送信する（図 1（５））．情報 収集サーバでは，受信したユーザ行動情報を分析し，ユーザが Web ページ上で どのように行動したか，どこにユーザビリティ上の問題点が存在するかについて 検討を行う． また，従来研究によって，Web 閲覧時のユーザの視線とマウスカーソルの位置 に関する様々な知見が得られている．Chen らはマウスカーソルの位置と視線と の間には強いがあり，マウスカーソルの位置を把握することで，ユーザの興味が ある個所を予測し，ユーザの意図を推論できる可能性があると報告している [10]． さらに，Muller らの実験の結果，35%のユーザは Web ページの文章を読むとき， マウスカーソルで文章をなぞることがわかっている [12]．このことから，マウス カーソルの位置を取得することで，Web ページのどこが見られている，見られて いないの判断を支援することも可能となる． 2.2 Web ユーザビリティ評価の課題 しかし，先述したシステムには，以下に示す 3 つの問題点があると考える． 5 • 動的 Web サイトのユーザビリティ評価を行うことが難しい • 自然なユーザ行動を取得することが難しい • テスト被験者をリクルーティングし，テストを行うことが難しい これらについて，以下で説明する． 2.2.1 動的 Web サイトのユーザビリティ評価 従来システムでは，Web ページ上でのユーザの振る舞いのみに着目しているた めに，動的 Web サイトを利用するユーザ行動を正確に把握できない．このため， 動的 Web サイトのユーザビリティ評価が難しいという問題がある． 動的 Web サイトとは，ユーザの操作や，アクセスするタイミングによって，表 示内容が異なる Web サイトのことである．これには，サーバ側で動的に変化する Web サイトとクライアント側で動的に変化する Web サイトが存在する．サーバ 側で動的に変化する Web サイトとは，ユーザのリクエストに応じて Perl や PHP 等の技術を用いてサーバ側で動的に Web ページを生成する Web サイトのことで あり，クライアント側で動的に変化する Web サイトとは JavaScript 等の技術を用 いて，Web ページ読み込み時や，タイマやユーザ操作等の各種イベントの発生に 応じて，ユーザが閲覧している Web ページの内容を変化させる Web サイトであ る．例えば mixi5 や facebook6 に代表されるような SNS サイトは Web サーバ側 で動的にページ内容を生成しており，同じ URL であったとしてもアクセスするタ イミングやユーザ ID によって表示される画面が異なる．また，Gmail7 や Google Calendar8 に代表される Web アプリケーションでは，JavaScript を用いることに よって，ページ遷移させずに Web ブラウザに表示される内容を変化させている． このように，動的 Web サイトを構築することで，従来の静的な HTML ファイル 5 6 7 8 http://mixi.jp/ http://www.facebook.com/ http://mail.google.com/ http://www.google.com/calendar/ 6 のみで構成されていた Web サイトでは提供できなかったようなコンテンツおよ びインタフェースをユーザに提供することが可能になっている． これら動的 Web サイトでは同じ座標をクリックしたとしても，Web サイトの 挙動が異なる場合があり，従来の遠隔ユーザビリティ評価システムを用いたユー ザビリティ評価の実施を困難としている．具体例を図 2 に示す． （ｂ）ドロップダウンメニューが開いた状態 （ａ）ドロップダウンメニューが閉じた状態 図 2 ドロップダウンメニューを採用した動的 Web サイトの例 図 2 は JavaScript で実現したドロップダウンメニューを採用した動的 Web サイ ト（http://www.naist.jp/）の例である．この Web サイトでは，ドロップダウン メニューが閉じている場合（図 2（ａ））と，開いている場合（図 2（ｂ））では， 同じ座標をクリックした際の挙動が異なる．たとえば，ドロップダウンメニュー が開いている場合（図 2（ｂ））にメニュー項目をクリックすると，メニュー項 目に対応した Web ページに移動することが出来る（「沿革」と書かれた部分をク リックすると，沿革に関する情報を掲載した Web ページに遷移する）が，ドロッ プダウンメニューが閉じている場合（図 2（ａ））に同じ座標（メニュー項目が表 示されていた部分）をクリックしても，メニュー項目に対応した Web ページには 移動できない． 従来システムのようにマウスクリックの位置を取得するだけでは，ドロップダ 7 ウンメニューが開いているか，閉じているかを知ることが出来ないため，ユーザ 行動を正確に把握することが困難となっている．他にも，JavaScript を用いるこ とで，タブを用いた表示情報の切り替えや，ドラッグアンドドロップによるイン ターフェースなど様々なインターフェースをページ遷移を伴わずに実現可能であ る．しかし，このような動的 Web サイトにおけるユーザ行動をマウスカーソル の軌跡やクリック座標のみで把握することは不可能であることから，動的 Web サ イトにおける従来システムを用いたユーザビリティ評価を困難としている． 2.2.2 自然なユーザ行動の把握 前述のとおり，ユーザテストとはユーザに Web サイトを利用してもらうこと によって，Web サイトに存在する問題点を発見するユーザビリティ評価手法であ る．ユーザテストは，Web サイトのユーザビリティ評価手法として非常に有効な 手法であるが，ユーザテストの際のユーザ行動は，本来のユーザ行動と差異が生 じる可能性がある． 例えば調査会社が行った調査 [5] によると，Web サイトに会員登録する際に，利 用規約に同意することが必須になっていたとしても，利用規約に目を通すユーザ は 4 割に満たないことがわかっている．ユーザにアンケートを行ったところ，利 用規約の存在自体を知らないユーザは 1 人も居らず，約 9 割のユーザが利用規約 を読まない理由として「読むのが面倒」「読んでも理解できない」と挙げている． また，ある企業は自社のソフトウェアの利用規約に「弊社にメールを頂けたら 金一封を差し上げます」と書いたおいたにも関わらず，初めてユーザからのメー ルを受け取ったのは，ソフトウェアのダウンロードが 3000 人を突破してからで あったとしている [11]． ところが，実際にユーザテストを行うと，多くのユーザは利用規約を読むと言 われている．これは利用規約について， 「読まなければならないものだが，読む のが面倒であるし読んでも理解できないため，実際には読まないでいい」とユー ザが考えているためである．このため，ユーザテストにおいてほとんどのユーザ が利用規約を読んでいたとしても，ユーザが利用規約に書いてある知識を持って いることを前提にサービスを提供してしまうと，ユーザが操作に戸惑う可能性が 8 ある． ユーザテストの際のユーザ行動と，普段のユーザ行動が異なる他の例として， 会員登録や商品購入時等のフォーム入力の場面があげられる．ユーザテストの際 には，評価者に依頼されて，Web サイトを利用するため，フォーム入力途中での Web サイトからの離脱というものが発生しにくい状況にある．しかしながら実際 には，フォーム入力前，もしくはフォーム入力中やフォーム入力後に離脱するユー ザの数はかなり多いとされており，ある調査によると，入力フォームでの離脱率 は 9 割とも報告されている [6]．ユーザビリティ評価を行う目的として，離脱率と コンバージョン率の改善がある．離脱率とは，Web ページにアクセスしたユーザ が他の Web サイトに移動したり，Web ブラウザを閉じてしまう割合であり，コ ンバージョン率とは，Web サイトを訪問したユーザの人数に対する Web サイト の目的（取引成立，資料請求，会員登録など）を達成したユーザの人数の割合で ある．しかし，ユーザテストの際のユーザは離脱を行うことが少ないため，離脱 要因の特定が困難だと考えられる． これらの例のように，ユーザが， 「これはユーザテストである」と意識してしま うと，程度の差はあったとしても普段のユーザ行動と異なる行動を取ってしまう 場合がある．実際に，Web サイトの評価者が知りたいのは普段のユーザ行動であ るため，こうしたユーザ行動の差異が Web サイトにおけるユーザビリティ上の 問題点の追及を困難にしていると言える． 2.2.3 テスト被験者のリクルーティング ユーザテストを行う際に問題となるのが，ユーザテスト被験者のリクルーティ ングについてである． 現状では，ユーザテストを行う際には，調査会社に被験者のリクルーティング を依頼することが一般的となっている．しかし，調査会社を利用する際のコスト は非常に大きい．また，従来のユーザテストでは，ユーザテストの実施場所まで 被験者に来てもらう必要があり，往復の交通費や被験者への謝礼も必要である． UsaProxy や MouseTrack といった従来システムを利用すれば，ユーザの拘束時 間が短くなるため，費用を少なく抑えることが可能である．しかし，これらのシ 9 ステムを利用するためには，ユーザの PC に新しいソフトウェアをインストール するか，Web ブラウザの設定を変更して専用の Proxy サーバを利用する必要があ る．しかし，多くのユーザは，ユーザテストのために自身の PC への新しいソフ トウェアをインストールしたり，自身の Web ブラウザの設定を変更したりするこ とに，拒否反応を示すことがわかっている [8]． 2.3 本研究の目的 近年，サーバの低価格化，Aptana9 等の Web サイトおよび Web アプリ開発環 境の普及，PHP10 等の Web アプリ開発を前提としたプログラミング言語の普及， Symfony11 等の各種 Web アプリケーションフレームワーク普及，jQuery12 等の 各種 Ajax フレームワークの普及，そして数多くの Web サイト，Web アプリ作成 のための技術書の出版等の結果，低予算で Web サイトを作成し，非営利目的で ユーザに提供することも一般的になっている．しかしながら，彼らがユーザに対 して使いやすいサイトを提供したいと思ったとしても，Web サイトのユーザビリ ティ評価のために多くの費用がかかる現状では，ユーザに対して使いやすいサイ トを提供することは困難である． そこで，前述した動的 Web サイトのユーザビリティ評価，自然なユーザ行動 の把握，テスト被験者のリクルーティングと言う Web サイトのユーザビリティ評 価における課題を解決し，安価にユーザビリティ評価を行うためのシステムとし て Webjig を提案し，有用性の評価を行うことを本研究の目的とする． 9 10 11 12 http://www.aptana.com/ http://www.php.com/ http://www.symfony-project.org/ http://jquery.com/ 10 3. 提案システム：Webjig 3.1 Webjig の概要 従来の遠隔 Web ユーザビリティ評価支援システムには，以下に示す 3 点の課題 がある． • 動的 Web サイトのユーザビリティ評価を行うことが難しい • 自然なユーザ行動を取得することが難しい • テスト被験者のリクルーティングが難しい Webjig では，これらの課題を，クロスドメイン通信，および DOM（Document Object Model）差分検出によって解決している．Webjig を利用することで，動 的 Web サイトであるかどうかに関わらず，自然なユーザ行動を安価に取得可能 である． Webjig のシステム構成を図 3 に示す．クライアント-サーバシステムなっており， クライアントは JavaScript で記述されており Web ブラウザ上で動作する．サーバ は PHP で記述されており，XAMPP13 環境上で動作する．システムは Web サイ トにアクセスしたユーザの情報を収集するシステム（Webjig::Fetch）と Web サ イト評価者にユーザの情報を表示するシステム（Webjig::Analysis）の 2 つのサブ システムと，ユーザ行動情報を保存しておくための Webjig::DB から構成されて いる． 3.2 Webjig::Fetch Webjig::Fetch は Web サイトにアクセスしたブラウザに対するユーザ行動に関 する情報を収集し，Webjig::DB に記録する．本節では，Webjig::Fetch の概要を 説明した後，Webjig::Fetch のインストール方法，および動作シーケンスについて 述べる．その後，クロスドメイン通信と DOM 差分検出について述べる． 13 http://www.apachefriends.org/en/xampp.html 11 ユーザビリティ 評価者 Webブラウザ 情報提示サーバ Webjig::Analysis Webjig::DB ユーザ 情報収集サーバ Webブラウザ Webjig::Fetch 図 3 Webjig の概要 3.2.1 概要 Webjig::Fetch は，Web サイトにアクセスしたユーザのブラウザ上の行動を収 集し記録するシステムである．本システムで収集し，記録する情報には以下のも のがある． • ユーザの利用しているブラウザの種類，バージョン • ブラウザの表示領域のサイズ • ブラウザの表示領域に表示されている内容 • ブラウザのスクロールバーの位置 • マウスカーソルの位置 • マウスボタンの押下のタイミングと，ボタンの種類 • キーボードの押下タイミングと，キーの種類 12 これらの中で，ユーザの利用しているブラウザの種類，バージョン以外の情報 は，ユーザが Web ページを閲覧している最中に変更される可能性があるため，一 定間隔で変更の有無を確認し，変更を検知するごとに情報の取得を行う．取得し た情報は，一定時間ごと，およびユーザが Web ページから離脱する際にサーバ に送信する． 3.2.2 Web サイトへの Webjig::Fetch のインストール Webjig を利用するためには，ユーザビリティ評価の対象となる Web サイトの HTML ソースに，<script src= ”Webjig::Fetch の URL ”></script> の 1 行を挿入する．例えば，図 4 のような HTML ソースを持つ Web ページに対して， Webjig::Fetch をインストールすると，図 5 のようになる．実際には，SCRIPT タ グは HTML ソースの中であればどこに挿入しても動作する．しかし，多くの Web ブラウザでは，HTML ソースの先頭から解釈して描画を行う．このため，なるべ く HTML ソースの最後に挿入することによって，オリジナルの HTML に関する 描画を優先させることを推奨する． 3.2.3 動作シーケンス Webjig::Fetch の動作シーケンスを図 6 に示す． 13 <html> <head> <title>Sample Page<title> </head> <body> <p>Sample Content</p> </body> </html> 図 4 Webjig::Fetch 導入前の html ソース <html> <head> <title>Sample Page<title> </head> <body> <p>Sample Content</p> </body> <script src= ”Webjig::Fetch の URL ”></script> </html> 図 5 Webjig::Fetch 導入後の html ソース 14 報情動行ザーユ） １１（ mod bu pool 求要D Iクーニユ）６ （ li tu 入挿 グタGM I ）８（ 成生） ５（ 成生） ４（ 成生） ３（ tini 図 6 Wbjig::Fetch の動作シーケンス ターデ像画） ０１（ 報情MOD） ２１（ D Iクーニユ）７ （ バーサ gijbW み込み読 ）２（ daol 求要 ターデ像画） ９（ み込み読） １（ ザウラブ beW 15 Webjig::Fetch がインストールされた Web サイトにユーザがアクセスすると， Web ブラウザは Webjig::Fetch のコードが存在する URL（SCRIPT タグの SRC 属性で指定した URL）から JavaScript のコードを読み込む（図 6（1））．そして， 読み込んだコードを実行する．この段階で Web ブラウザには load クラスが生成 される．このクラスは Webjig::Fetch のメインとなる，サーバとの通信処理を実 行するための JavaScript コードの読み込みを行う（図 6（2））． JavaScript は多くの Web ブラウザで実行可能となっているものの，Web ブラ ウザによって JavaScript の処理系が異なる．処理系によっては定義されていない クラス，メソッド，変数，定数などが存在するため，同じコードでも処理速度が 異なる場合や，異なる動作を行う場合や，動作しない場合が存在する．このため， Webjig ではユーザの利用している Web ブラウザを判断し，それぞれの処理系に 最適化されたクラスを生成する．この時，load クラスによって生成されるクラス を init クラスと呼ぶ．init クラスでは，内部に util クラス，ub クラス，dom クラ スの生成を行う（図 6（3）（4）（5））．util クラスは，Webjig::Fetch の動作を制 御し，ユーザの識別等の動作を行い，ub クラスはユーザ行動に関わる情報を収集 し，dom クラスは DOM の管理を行う．なお，init クラスで生成されるこれらの クラスは，事実上，マルチスレッドで動作を行う． util クラスのインスタンスが生成されると，コンストラクタがサーバに対して， ユーザの利用しているブラウザの種類，バージョンに関する情報を引数として， ユニーク ID の発行を依頼する（図 6（6））．このユニーク ID は各ユーザが各 Web ページにアクセスするたびに新しいものが発行される（図 6（7））．Webjig では， このユニーク ID に，ユーザ行動情報と，ブラウザに表示されていた内容を関連 付けて扱う．util クラスは，ユニーク ID が発行されると，IMG タグを利用して 1 ピクセル× 1 ピクセルの透明画像を，Web ページの中に挿入する（図 6（8））．な お，この画像は透明であり，かつ絶対座標で配置されるため，オリジナルの Web コンテンツに影響を与えない．IMG タグが Web ページ内に挿入されると，Web ブラウザはサーバに対して IMG タグの SRC 要素で指定された画像をサーバに要 求する（図 6（9））．なお，このサーバへの画像要求時に，先述のユニーク ID を 引数として用いる．サーバ側では要求に応じて画像の生成を行い Cookie を用いて 16 ユーザの識別を行う（図 6（10））．Cookie にはユニークなユーザ ID が保存されて おり，データベース上でユーザ ID とユニーク ID を関連付けることによって，特 定のユーザがどの Web ページにアクセスしたかを知ることが可能となっている． ub クラスは Web ページを閲覧中のユーザ行動に関する情報を収集する．収集 する情報については下記の通りである． • ブラウザの表示領域のサイズ • スクロールバーの位置 • マウスカーソルの位置 • マウスボタンの押下のタイミングとボタンの種類 • キーボードの押下タイミングとキーの種類 ブラウザの表示領域のサイズ，スクロールバーの位置，マウスカーソルの位置に ついては，以前取得した値から一定値以上の変化があったタイミングで値を取得 する．ただし，Web ページ読み込み時は以前取得した値が存在しないため，必ず 値を取得する．取得した値は，一定時間ごとにサーバに送信する（図 6(11)）． dom クラスでは，Web ブラウザの表示領域に表示されている内容に関する情報 を収集する．収集した情報は一定時間ごとにサーバに対して送信する（図 6(12)）． 3.2.4 JSONP を利用したクロスドメイン通信 JavaScript では XMLHttpRequest オブジェクトを利用することで HTTP 通信 が可能になっている．しかし，JavaScript ではセキュリティ上の理由から，Web ページをダウンロードしたドメイン以外との通信（クロスドメイン通信）を制限 している． Webjig でユーザ行動を取得する際，ユーザがアクセスした Web ページと，Webjig::Fetch をダウンロードし，ユーザ行動情報を送信する Web ページは異なる． このため，クロスドメイン通信を行う必要があり前述の制限に該当してしまう． 従来システムでは，直接評価対象の Web サイトにアクセスせずに Proxy サーバ 17 を利用して評価対象の Web サイトにアクセスすることで，Web ページのダウン ロード元と，ユーザ情報の送信先を同一ドメインにし，クロスドメイン通信の制 限を回避している．しかし，この手法を採用した場合，ユーザ自身の PC に対し て設定変更を要求する． この問題を解決するための手法として，Webjig では JSONP（JSON with Padding） [2] という SCRIPT タグを利用した Ajax 実装手法を利用することによって，クロ スドメイン通信を実現する．JSON[3] は 2006 年 7 月に RFC4627 で仕様が規定さ れた JavaScript におけるオブジェクトの表記法をベースとした軽量なデータ記述 言語である．JSONP は，JSON データを引数として，JavaScript の関数を呼び出 す形式でレスポンスを受け取る方式である． 3.2.5 DOM ツリーの差分検出および通信 動的 Web ページでは，アクセスしたユーザおよびタイミングによって表示さ れる内容が異なったり，表示中のページ内容が変更される場合が存在する．この ため，ユーザビリティ評価者は，ユーザの画面に表示されたページの内容を知る 必要がある．しかし，Web ページ全体を毎回サーバに送信すると，通信量が莫大 になってしまい，回線帯域を圧迫してしまう可能性がある．そこで，Webjig では DOM の差分検出を行うことによって，必要最低限な部分だけをサーバに送信す る．まず，この手法の前提として Web ブラウザが Web サーバから受信した内容を 画面に表示する仕組みを述べる．次に，DOM スクリプティングおよび，DOM ツ リーのハッシュ値計算および差分検出手法について述べる．そして DOM ツリー データのサーバとの通信方法について述べる． DOM[1] とは W3C によって勧告されている HTML ドキュメントへの API であ る．DOM では図 7 のように HTML ドキュメントをツリー構造として扱っており， JavaScript を用いることでブラウザ内部の DOM ツリーに対して要素の追加，取 得，変更，削除を可能にしている．これによって，ページ遷移せずに Web ブラウ ザで表示中の内容に変更を加えることができる． 18 HTML HEAD TITLE BODY LINK DIV P SPAN 図 7 DOM の例 DOM のハッシュ計算 Webjig では，DOM ツリーの差分検出を行うために，一 定時間ごとに Web ブラウザ内部の DOM ツリーを取得して，前回取得時のハッ シュ値と比較し変更の有無を確認する．そして，変更を検知した場合，前回と比 較することによって，どこが変更されたのかを確認し，差分をサーバに対して送 信する．Webjig では，DOM ツリーの差分を検出するため，まず DOM ツリーの ハッシュを計算する．DOM ツリーのハッシュ値の計算方法は下記の通り実行さ れる． 1. DOM ツリーから，子ノードを持たない，もしくは子ノードのハッシュがす べて計算されているノードを探索する 2. そのハッシュを計算する 3. 1 および 2 を根ノードのハッシュが計算されるまで繰り返す たとえば，図 7 の場合であると，子ノードを持たない，もしくはすべての子ノー ドのハッシュが計算されているノードとして，TITLE，LINK，DIV，P，SPAN が存在する．これらのノードを発見すると，その属性と子ノードのハッシュ値から 要素のハッシュ値を計算する．ここで，属性とは，タグごとに設定できる値（IMG 19 タグであれば SRC 等，A タグであれば HREF 等）のことである．ハッシュ値の計 算が終わった段階で，DOM ツリーから，子ノードを持たない，もしくは子ノード のハッシュがすべて計算されているノードを探索すると，HEAD タグと，BODY タグが該当するため，これらについても，属性と子ノードのハッシュ値から，そ のノードのハッシュ値を計算する．その後，根ノードである HTML のハッシュ値 を計算し，ハッシュ値の計算を終了する．Webjig では根ノードのハッシュ値をそ の DOM ツリーのハッシュ値として扱う．ハッシュ値を計算した DOM ツリーの 例を図 8 に示す．タグの名前の下に書かれた文字列が，ハッシュの値を示す． HTML plqw HEAD k4r5 TITLE d9kl BODY 7ujk LINK 3kdl DIV fdad P dxze SPAN adfa 図 8 DOM ツリーのハッシュを計算した例 Web ページを DOM で表現すると，同一の内容の Web ページは同一の DOM ツ リーになるというメリットがある．たとえば，HTML では，各タグの要素の記述 順序が異なっていても，表示される内容は同じである．このため，ソースファイ ルを単純に比較した場合，表示される画面は同じでも異なるものして判断されて しまう．DOM を利用することで，同一のページは同一の DOM として表現する ことができ，さらにハッシュを計算することで，根ノードのハッシュを比較する だけで，同一内容か，そうでないかを判別することが可能となっている． 20 DOM ツリーの差分検出 2 つの DOM ツリーの根ノードのハッシュ値を比較し て，それらの DOM が異なると判断した場合，ハッシュを利用することで異なる 箇所の特定も容易である．図 9 を用いて説明する．図 9（a）の DOM ツリーには BODY タグの子ノードに P タグのノードが存在するが，図 9（b）の DOM ツリー には BODY タグの子ノードに P タグのノードが存在しない． HTML plqw HEAD k4r5 TITLE d9kl HTML 3kos BODY 7ujk LINK 3kdl DIV fdad P dxze HEAD k4r5 TITLE d9kl SPAN adfa （a）P ノードが存在する DOM ツリー BODY 48js LINK 3kdl DIV fdad SPAN adfa （b）P ノードが存在しない DOM ツリー 図 9 DOM ツリーの差分検出 DOM ツリーの根ノードである HTML タグのノードのハッシュ値が異なるとい うことは，子ノードのどこかに差異が存在するということである．このため，ま ず根ノードの子ノードのハッシュ値を比較する．図 9（a）と図 9（b）では HEAD タグのノードのハッシュ値は等しいため，HEAD タグのノードを根とするサブツ リー同士は等価であるとみなすことができる．一方，BODY タグのノードのハッ シュ値は異なるため，BODY タグのノードを根とするサブツリーに差異が存在す ることがわかる．このようにして，ツリーをたどっていくと，図 9（b）には，図 9（a）に存在する P タグのノードが存在ないことがわかる．Webjig では，この ようにハッシュ値を用いて DOM ツリーの差分を検出し，DOM ツリーの構造を データベースに登録する． DOM ツリーのデータベースへの登録 Webjig::Fetch が Web ブラウザに読み込 まれると，一定周期ごとに，Web ブラウザに表示されている内容を監視する．そ 21 して，内容に変化が発生したとき（Web サイトにアクセスした瞬間は DOM ツ リーが存在しないため，変化が発生したものとして扱う），新しく DOM ツリー を構築する．DOM ツリーの構築が完了すると，まずは根ノードのハッシュ値と， その DOM ツリーの構築時刻（つまり，Web ブラウザで表示している内容に変化 があった時刻）をサーバに送信する．サーバでは，根ノードのハッシュ値が一致 する DOM が存在し，すでに登録されているかどうかを探索する． 探索の結果，見つからなければ，見つからなかった旨を Web ブラウザに通知 し，見つかれば見つかった旨，および，DOM ツリーが完全であるか，完全でない かを通知する．ここで，完全とは，該当するハッシュ値を根とするツリーをサー バ上にあるデータだけで構築できるか否かであり，構築できないサブツリーが存 在すれば，完全では無いとする．DOM ツリーが完全ではなく，欠損しているサ ブツリーが存在する場合，欠損しているサブツリーの根のハッシュ値をクライア ントに通知する．クライアントでは通知されたハッシュ値を根とするサブツリー の情報をサーバに対して送信する． この手法を採用することで，通信量を削減し，効率的にユーザ側の情報を取得 することが可能となっている． 3.3 Webjig::DB Webjig では，Webjig::Fetch で Web サイトにアクセスしたユーザのデータを Webjig::DB に保存し，Webjig::Analysis によって，Webjig::DB に保存してある データを取り出して加工し，ユーザビリティ評価者に提示する．本節では，We- bjig::DB のエンティティ構成と，その目的について述べる．図 10 に Webjig::DB の ER 図を示す． 3.3.1 アクセス管理エンティティ 本エンティティでは，ユーザが特定の Web ページにアクセスしたログを記録 する．記録する情報にはユニーク ID，ユーザ ID，アクセス日時，アクセス URL， ユーザエージェントを含む．本システムでは，ユーザが 1 つの URL にアクセス 22 DOM変更管理 アクセス管理 DOM変更ID アクセスID ノードハッシュ 変更時間 アクセスID ユーザID アクセス日時 アクセスURL ユーザエージェント DOM構造管理 ノードID ノードハッシュ 子ノードID ノード名 属性 スクロールバー位置管理 スクロールバー位置ID アクセスID スクロールバー位置 変更時間 キーボード操作管理 マウス操作管理 ウィンドウサイズ管理 キーボード操作ID アクセスID 操作内容 変更時間 マウス操作ID アクセスID 操作内容 変更時間 ウィンドウサイズID アクセスID ウィンドウサイズ 変更時間 図 10 Webjig::DB の ER 図 23 するごとに，1 つのユニークな ID を発行する．クライアントからサーバに対して 通信を行うときは，このユニーク ID を用いて通信を行い，サーバ側では，どの クライアントからの通信であるかを識別することが可能となっている．また，本 システムでは，各ユーザに ID を発行し Cookie を用いてユーザ識別を行っている． これによって，各ユーザが，Web サイトの中をどのように遷移したか，何回目の サイト訪問か，訪問回数を重ねるごとに行動に変化が見られるか等を知ることが 可能である． 3.3.2 DOM ツリー管理エンティティ 動的 Web ページにおいては，同一の Web ページに滞在しつつも，画面に表示 されている内容が変化する場合がある．そこで，アクセス ID ごとに，画面の内 容が変化したタイミングと，変化した内容を本エンティティを用いて記録してい る．本エンティティによって，ユーザが Web ページに滞在中に，画面がどのタイ ミングで，どのように変化したかを知ることができる． 3.3.3 DOM ツリー構造管理エンティティ 本エンティティでは，DOM ツリーの構造を記録する．前述のとおり，Webjig では，Web サイトを DOM ツリーとして扱い，ハッシュによる差分検出を行って いる．その DOM ツリーの内容を，本エンティティで管理している． 3.3.4 ウィンドウサイズ管理エンティティ 本エンティティでは，ユーザが利用している Web ブラウザの表示領域サイズ を記録している．Web サイトは，Web ブラウザの表示領域によって，見え方が異 なる場合があり，ユーザ行動に変化が表れると考えられる．同一の Web ページに アクセス中に，Web ブラウザの表示領域サイズが変更される場合もあるため，各 ユーザ ID における，タイミングと画面の表示領域サイズを記録する． 24 3.3.5 キーボード操作管理エンティティ Web サイトアクセス中にキーボードを利用する場合がある．たとえば，Tab キー を用いてフォーカスを移動させたり，アクセスキーを利用したり，フォームに文 字を入力する等である．これらの情報を取得するために，本エンティティでは， ユーザのキーボードの押下タイミングとリリースのタイミング，キーの種類を記 録する． 3.3.6 マウス操作管理エンティティ Web サイトを利用する際に，多くのユーザはマウスを利用する．従来の静的な Web サイトにおいては，マウスクリックはリンクをたどりページ遷移が発生する 時に用いる事が多い．しかし，動的 Web サイトにおいては，ページ遷移が発生 しない場合であっても，ユーザにクリックを要求する場合がある．そして，これ はユーザビリティ評価に重要な情報であると考えられる．そのため，本エンティ ティでは，ユーザのマウスクリックのタイミングとボタンを記録している． 3.3.7 スクロールバー管理エンティティ Web ブラウザのウィンドウ内に収まりきらないサイズの Web ページにアクセ スする際，ユーザは必要に応じてスクロールバーを用いて表示領域移動させる． スクロールバーの位置を知ることで，ユーザが Web サイトのどの部分を表示さ せているかがわかる．本エンティティでは，ユーザのブラウザのスクロールバー がどの位置に表示されているかを記録している． 3.4 Webjig::Analysis Webjig::Analysis では，Webjig::Fetch によって収集された情報を解析しユーザ に提示することによって，ユーザビリティ評価を支援する事を目的としている． 25 3.4.1 概要 Webjig::Analysis では，Webjig::Fetch によって Webjig::DB に記録された情報 を利用し，Web サイト利用時のユーザ行動を再生することができる． ユーザ行動再生時の画面構成は図 11 のように，ユーザの Web ブラウザに表示 されていた画面と，制御・各種情報提示用のフローティングウィンドウから構成 される． 図 11 Webjig::Analysis によるユーザ行動の再生 再生制御ウィンドウによって，ユーザ行動の再生を制御することが可能であり， 任意のタイミングで，再生，一時停止が可能である他，巻き戻しや早送りと言っ た操作や，スクロールバーを用いることによって，任意のタイミングに移動する ことが可能となっている． 26 また，通常の Web サイトは，複数の Web ページから構成されていることが一 般的であり，同一のユーザが複数の Web ページに連続してアクセスした場合は， 複数の Web ページ内での行動を，連続的に再生することができる． また，ページ内におけるマウスカーソルの軌跡を表示するこが可能であるため， ユーザが Web ページ内のどこを見ているか，または見ていないかの判断を支援 する．さらに，行動を時系列で表示する機能も備える． さらに，フローティングウィンドウはプラグイン形式になっており，ユーザビ リティ評価に必要な任意の機能をユーザビリティ評価者が追加可能である．プラ グインからは，ユーザの情報行動に自由にアクセスすることができるため，プラ グインを利用してユーザ行動の統計的処理・データマイニングを行うことが可能 である． 27 4. システム評価 4.1 概要 本論文では従来の Web ユーザビリティ評価手法の課題として以下の 3 点を挙 げた． • 動的 Web サイトのユーザビリティ評価を行うことが難しい • 自然なユーザ行動を取得することが難しい • テスト被験者のリクルーティングが難しい 本章では，これらの課題が Webjig を利用することによって解決されていること を確認する．動的 Web サイトのユーザビリティ評価を行うことが難しい点およ び，自然なユーザ行動を取得することが難しい点については実験によって，テス ト被験者のリクルーティングが難しい点についてはコストから見積もり値を算出 する事によって評価する． 4.2 動的 Web サイトのユーザビリティ評価 4.2.1 評価指針 Webjig を利用することで，従来システムと比較して効率的に動的 Web サイト に対してユーザビリティの評価・改善が実施可能であることを確認する． 4.2.2 実験概要 実験手順 実験は以下の手順で行う． 1. 実験用 Web サイトを作成する 2. 実験用 Web サイトを用いて，グループ A の被験者にタスクを与える 28 表 1 各タスクで探す項目 タスク名 商品 タスク 1 電池 タスク 2 SD メモリーカード タスク 3 マッサージチェア タスク 4 電子辞書 タスク 5 ファックス 3. グループ B の被験者が Webjig を利用してユーザビリティ評価を行い改善を 行う 4. ユーザビリティ改善を行った実験用 Web サイトを用いて，グループ C の被 験者に 2 と同様のタスクを与える 実験用 Web サイト 動的なプルダウンメニューを持つ Web サイト（図 12）を実 験に用いる．この Web サイトは， 「パソコン」や「カメラ」といった商品カテゴ リのラベル上にマウスを移動させると，その商品カテゴリに含まれる商品のリス トが表示される．なお，商品のカテゴリ分類は，大手家電量販店の Web サイトで 実際に利用されているものを参考にした． 実験タスク 実験で用いるタスクは，実験用 Web サイトのメニューの中から表 1 に示す項目を探しクリックを行うものである． 被験者 被験者は表 2 に示す 3 つのグループからなる 54 名である．まず，グルー プ A の 24 名の被験者にタスクを与える．次に，この結果を参考にしてグループ B の 3 名の被験者にユーザビリティ評価を行い改善提案を行わせる．その後，改 善によって，ユーザ行動がどう変化するかを調べるために，グループ C の 27 名 の被験者に同一のタスクを与える．なお，複数のグループに所属する被験者は存 在しない． 29 図 12 実験 1 で利用する Web サイト グループ 表 2 実験の被験者 属性 人数 グループ A 工学を専攻している学生 24 人 グループ B Web 制作経験者 3人 グループ C 工学を専攻している学生 27 人 30 4.2.3 実験結果 オリジナルのカテゴリ分類による実験 実験の結果，24 人の被験者全員が，与え られたタスクを完了することができた．各タスクのタスク完了時間を図 13 に示 す．また，表 3，4，5，6，7 は，被験者がタスクを与えられてから何回目にどの カテゴリを探索したかの割合を示す．なお，各タスクの正解カテゴリ名を太字で 示す． 例えば，表 3 はタスク 1 実行時の被験者の 54%が，電池を探すために 1 回目の 探索で生活家電のカテゴリを探索したことを示している．また，1 回目の探索で 電池を見つけられなかった被験者の 30%が，2 回目の探索でオフィス機器のカテ ゴリを探索していることを示している． ） 秒 （ 完 完 完 完 タ タ タ 0 5 1 0 0 1 0 5 0 タタタ1 タタタ2 タタタ3 タタタ4 タタタ名 タタタ5 図 13 各ユーザのタスク完了時間 31 表 3 タスク 1 実行時の探索順序とカテゴリ カテゴリ名 探索順序 1 回目 2 回目 3 回目 4 回目 5 回目 カメラ 6 回目 29 ％ 9％ 0％ 0％ 0％ 0％ パソコン 0％ 22 ％ 18 ％ 0％ 0％ 0％ AV 機器 4％ 26 ％ 71 ％ 80 ％ 100 ％ 0％ 生活家電 54 ％ 13 ％ 6％ 0％ 0％ 0％ ゲーム 4％ 0％ 0％ 20 ％ 0％ 0％ オフィス機器 8％ 30 ％ 6％ 0％ 0％ 0％ 健康 0％ 0％ 0％ 0％ 0％ 0％ 表 4 タスク 2 実行時の探索順序とカテゴリ カテゴリ名 探索順序 1 回目 2 回目 3 回目 4 回目 5 回目 6 回目 カメラ 13 ％ 24 ％ 69 ％ 80 ％ パソコン 46 ％ 38 ％ 6％ 0％ 0％ 0％ AV 機器 33 ％ 33 ％ 6％ 0％ 0％ 0％ 生活家電 4％ 0％ 13 ％ 20 ％ 0％ 0％ ゲーム 4％ 0％ 0％ 0％ 0％ 0％ オフィス機器 0％ 5％ 6％ 0％ 100 ％ 0％ 健康 0％ 0％ 0％ 0％ 0％ 0％ 32 0 ％ 100 ％ 表 5 タスク 3 実行時の探索順序とカテゴリ カテゴリ名 探索順序 1 回目 2 回目 3 回目 4 回目 5 回目 6 回目 カメラ 0％ 0％ 0％ 0％ 0％ 0％ パソコン 0％ 0％ 20 ％ 0％ 0％ 0％ AV 機器 0％ 11 ％ 0％ 0％ 0％ 0％ 生活家電 71 ％ 6％ 0％ 0％ 0％ 0％ ゲーム 0％ 0％ 0％ 0％ 0％ 0％ オフィス機器 4％ 11 ％ 0％ 0％ 0％ 0％ 25 ％ 72 ％ 80 ％ 100 ％ 0％ 0％ 健康 表 6 タスク 4 実行時の探索順序とカテゴリ カテゴリ名 探索順序 1 回目 2 回目 3 回目 4 回目 カメラ 5 回目 6 回目 0％ 0％ 0％ 0％ 0％ 0％ パソコン 13 ％ 10 ％ 50 ％ 0％ 0％ 0％ AV 機器 0％ 30 ％ 0％ 0％ 0％ 0％ 生活家電 29 ％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 58 ％ 60 ％ 50 ％ 100 ％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ ゲーム オフィス機器 健康 33 表 7 タスク 5 実行時の探索順序とカテゴリ カテゴリ名 探索順序 1 回目 2 回目 3 回目 4 回目 5 回目 6 回目 カメラ 0％ 0％ 0％ 0％ 0％ 0％ パソコン 4％ 6％ 29 ％ 0％ 0％ 0％ AV 機器 21 ％ 17 ％ 0％ 0％ 0％ 0％ 生活家電 29 ％ 61 ％ 71 ％ 100 ％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 46 ％ 17 ％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ 0％ ゲーム オフィス機器 健康 カテゴリ分類改善案の作成 実験結果をもとにユーザビリティ評価を行い，カテ ゴリ分類の再検討によるユーザビリティ改善案の作成をグループ B の被験者に依 頼した．表 3，4，5，6，7 を参考に，被験者の一度目の探索でタスク完了となる 可能性が最も高くなるカテゴリに項目を移動することとした．表 8 にカテゴリ分 類改善案を示す．ただしタスク 4 の電子辞書に関しては，一度目の探索でオフィ ス機器を探索するユーザが最も多かったため，改善する必要はないと判断した． 表 8 カテゴリ分類改善案 商品 改善前カテゴリ 改善後カテゴリ 電池 AV 機器 生活家電 SD メモリーカード カメラ パソコン マッサージチェア 健康 生活家電 電子辞書 オフィス機器 オフィス機器 ファックス 生活家電 オフィス機器 34 新しいカテゴリ分類による実験 カテゴリ分類の改善を行った商品についてグ ループ C の被験者 27 人にタスクを与えた結果，27 人の被験者全員が，与えられ たタスクを実行することができた．オリジナルのカテゴリ分類と，改善後のカテ ゴリ分類における，各タスクのタスク実行完了時間の比較を図 14 に示す． ） 秒 （ 完 完 完 完 タ タ タ 0 5 1 オオオオオ 改改改 0 0 1 0 5 0 タタタ1 タタタ2 タタタ3 タタタ5 タタタ名 図 14 カテゴリ分類による各ユーザのタスクの完了時間の比較 図 14 より，カテゴリ分類の改善を行ったすべてのタスクにおいて，各ユーザの タスクの完了時間が短くなっていることがわかる． 35 グループ 表 9 実験の被験者 Web サイトへの誘導 人数 グループ D ユーザテストとして入力を依頼 20 人 グループ E 検索エンジンから誘導 100 人 4.3 自然なユーザ行動の取得 4.3.1 評価指針 Web サイトに対してユーザビリティ評価を行う際に，ユーザテストと意識して Web サイトを操作するユーザと，自発的に Web サイトを操作するユーザで，行 動に差が出ることを確認する． 4.3.2 実験概要 実験手順 実験は以下の手順で行う． 1. 実験用 Web サイトを作成する 2. 実験用 Web サイトを用いて，被験者にタスクを与える 3. Webjig を利用して被験者グループにおける行動の差異を分析する 実験用 Web サイトおよびタスク 実験用 Web サイトとして入力フォームを持つ Web サイトを用いる．この Web サイトはアンケートフォームになっており，複 数の設問への回答と，ユーザの個人情報（名前とメールアドレス）を入力させる． 被験者 被験者は表 9 に示す 2 つのグループからなる 120 名である．グループ D はユーザテストとして入力を依頼した 20 人であり，グループ E は検索エンジン から誘導したユーザ 100 人である． 36 4.3.3 実験結果 各グループの被験者の Web サイト内での行動を，アクセス直後のスクロール の有無，アンケートへの記入の有無，データの送信の有無，エラー発生の有無， エラー修正の有無，タスク完了の有無によって比較を行った結果を表 10 に示す． また，グループ D に属する被験者の行動フローを図 15 に，グループ E に属する 被験者の行動フローを図 16 に示す． なお，アクセス直後のスクロールとは，被験者が Web ページにアクセスした 後，ページスクロールを行ったかどうかである．アンケートへの記入とは，被験 者が Web ページにアクセスした後，離脱する前に少なくとも 1 つの設問に対し て回答を行ったかどうかである．データの送信とは，ユーザがアンケートに記入 し，データを送信するために送信ボタンを押下したかどうかである．エラー発生 とは，送信したデータに不備（入力されていない項目がある，フォーマットが異 なる等）があるかどうかである．エラー修正とは，エラーが発生した部分を修正 し，データの送信を行ったかどうかである．タスク完了とは，エラーが発生した 場合は修正を行い，エラーが出ない状態のデータの送信を行ったかどうかである． 表 10 各グループの被験者の比較 グループ D グループ E アクセス直後のスクロール 0％ 48 ％ アンケートへの記入 100 ％ 18 ％ データの送信 100 ％ 9％ エラー発生 35 ％ 7％ エラー修正 35 ％ 5％ タスク完了 100 ％ 7％ ページアクセス直後のスクロール グループ D の被験者 20 人の全員が，アンケー ト記入前に Web ページのスクロールを行わなかった．しかし，グループ E の被 験者 100 人中 48 人が，ページアクセス直後にページのスクロールを行った． 37 流入 100人 スクロール Yes No 20人 アンケート記入 Yes 20人 データ送信 Yes 20人 No エラー発生 Yes 7人 エラー修正 Yes 7人 完了 図 15 グループ D に属する被験者の行動フロー 38 7人 完了 流入 100人 Yes スクロール Yes 48人 アンケート記入 Yes 10人 データ送信 Yes 8人 エラー発生 Yes 7人 エラー修正 Yes 5人 完了 No No No No No 38人 離脱 52人 No アンケート記入 Yes 8人 No データ送信 Yes 2人 離脱 1人 エラー発生 離脱 離脱 No 完了 1人 完了 2人 離脱 図 16 グループ E に属する被験者の行動フロー 39 44人 7人 1人 アンケート記入 グループ D の被験者 20 人のうち全員がアンケート記入を行っ た．スクロールを行ったグループ E の被験者 48 人のうちアンケート記入を開始 した被験者は 10 人であり，スクロールを行わなかったグループ E の被験者 52 人 のうち，アンケート記入を開始した被験者は 8 人であった． データ送信 グループ D の被験者は 20 人の被験者全員がアンケートを記入後に， データの送信を行った．スクロールを行ったグループ E の被験者 10 人中 8 人がア ンケートの記入後にデータの送信を行った．スクロールを行わなかったグループ E の被験者 8 人のうち 1 人だけが，アンケートの記入を行いデータを送信した． エラー発生および修正 グループ D の被験者は 20 人中 7 人がアンケートの回答 内容に不備があった．このため，7 人全員がエラー項目について修正を行い，デー タの再送信を行った．グループ E の被験者 11 人中 7 人がアンケートの回答内容 に不備があった．エラー画面が表示されたものの，エラーを修正しデータの再送 信を行ったのは 7 人中 5 人であり，7 人中 2 人は，エラー画面が表示された時点 でページから離脱した． Web サイトからの離脱 グループ D の被験者は，20 人全員がアンケートの全項 目について回答を行った．また，フォーム送信後にエラーが出た場合は全被験者 がエラーが出た項目の修正を行った．つまり，コンバージョン率は 100%であった． 一方，グループ E の被験者 100 人のうち，82 人は，フォームへの入力前に離 脱を行った．残りの 18 人の被験者は入力フォームへの入力を開始したが，入力 フォームへの入力を開始した被験者のうち 9 人はフォームへの入力途中に離脱を 行った．フォームに入力したデータを送信したのは 9 人であった．このうち，入 力したデータに不備があった被験者は 7 人であり，エラーが表示された被験者の うち 2 人はエラー画面が表示された時点で Web ページからの離脱を行った．エ ラーを修正して，再度データの送信を行った被験者は 5 人であった．この結果， 最終的にデータの送信を行った被験者は 7 人となり，コンバージョン率は 7%と いう結果になった． 40 4.4 テスト被験者のリクルーティング 4.4.1 評価指針 Web サイトに対してユーザビリティ評価を行う際に，ユーザ行動情報を収集す るコストについて見積もりを行う． 4.4.2 評価概要 実験では，特定の Web サイトに対してユーザから行動情報を収集すると仮定 した際に，ユーザテストを実施した場合，Webjig を利用した場合，従来システム を利用した場合を想定し，それぞれのシステムを利用することによって，どのよ うな差が出るかについて分析を行う． 4.4.3 評価結果 各手法における費用の比較を表 11 に示す． 表 11 各手法における費用の比較 調査会社の費用 ユーザへの謝礼 設備利用料 ユーザテストの実施 1 万円から 2 万円 従来システムの利用 1 万円から 2 万円 2500 円から 5000 円 0円 0円 0円 0円 Webjig の利用 ユーザテストを実施する場合 5000 円から 1 万円 15 万円から 20 万円 ユーザテストを実施する場合，および従来システ ムを利用する場合，被験者を募るため調査会社に会員紹介を依頼する．費用は調 査会社によって異なるが，1 人あたり 1 万円から 2 万円である．また，調査会社 に支払う料金とは別に，ユーザに渡す謝礼を用意する必要がある．謝礼の相場は 1 時間のテストの場合，交通費込みで 5000 円から 1 万円である．このことから， 41 被験者 1 人あたりの費用は 1 万 5000 円から 3 万円である．また，ユーザテストの ための設備をレンタルする場合は，1 日あたり 15 万円から 20 万円の費用が必要 となる [17]． 従来システムを利用する場合 従来システムを利用する場合，被験者への謝礼は 交通費を必要とせず，拘束時間が短くなることから若干少なくすることが可能で ある．被験者への謝礼がユーザテストの半額になると仮定すると，被験者 1 人あ たりの費用は 1 万 2500 円から，2 万 5000 円となる．費用の大半は調査会社への 費用となっていることから，被験者を収集するためのコストは，ユーザテストの 際とほとんど変わらない．ただし，ユーザテストのための設備をレンタルする必 要がないため，安価にユーザビリティ評価を実施することが可能となる． Webjig を利用する場合 Webjig を利用する場合，Web サイトにアクセスした ユーザの行動を取得し評価を行うため，調査会社および被験者に支払う費用が発 生しない．また，ユーザテストのための設備のレンタルも不要である． 42 5. 考察 本章では，4 章で行ったシステム評価の結果をもとに，Webjig が前述した課題 を解決できているかについて考察を行う． 5.1 課題 1：動的 Web サイトのユーザビリティ評価 5.1.1 従来システムの限界 古典的な静的な Web サイトにおいては，ユーザが何らかの操作を行う度にペー ジ遷移が発生する．このため，メニューの操作をはじめとするすべてのユーザ行 動は，従来システムを利用することによって把握することが可能であった．しか し，近年増加している動的 Web サイトにおいては，ページ遷移を伴わない操作 が発生する場合が多く発生する．従来システムではユーザが動的 Web サイトを 利用する様子を該当する Web ページに流入してから離脱するまでのマウスの動 きでしか把握することが出来ないため，ユーザビリティ改善のための仮説を立て ることが困難である． 例えば本実験のように，メニューから特定の項目を選ぶタスクであれば，従来 システムを利用することによって各タスクの完了時間を知ることが出来る．その 結果，図 13 のように項目ごとの時間を比較することによって，他の項目と比較 して探索に時間がかかる項目を調べ，ユーザビリティ上の問題点を探ることが可 能である．図 13 の場合であると，タスク 4 に比べて，タスク 1,2,3,5 のタスク完 了時間が大きい．このため，タスク 1,2,3,5 実行時に，何らかのユーザビリティ上 の問題点があるのではないかと仮説を立てることが可能である．しかし，問題点 の存在がわかったとしても，原因を追求することが出来なければ問題点を取り除 くことは困難である． 5.1.2 Web ユーザビリティ評価における Webjig の有用性 Webjig を利用することで，従来システムでは得ることが出来なかったユーザ行 動に関する情報を得ることが可能となっており，ユーザビリティ改善のための仮 43 説を，ユーザ行動を根拠に立てることが可能となる． タスク 1 を例に説明する．表 3 より，電池を探すタスク実行時に過半数のユー ザは，実際には電池が AV 機器カテゴリに分類されているにも関わらず，生活家 電のカテゴリを探していたことがわかる．このことから， 「多くのユーザは，電 池が生活家電に属すると考えている」と言う仮説を立て，電池が属するカテゴリ を AV 機器から生活家電に変更した．これによって商品を発見するまでの時間が 短縮された．このように，Webjig を利用することで，動的 Web サイトにおける ユーザの詳細な行動を把握することが可能になるため，従来システムを利用した 場合に比較して，効率的にユーザビリティ上の問題点の原因追究を行うことが可 能であると言える． 5.1.3 Webjig を用いたユーザビリティ改善点の優先順序判別 原因追究を行った上で，ユーザビリティ改善案を検討し，再度実験を行った結 果，図 14 より，ユーザビリティ改善案を適用したすべてのタスクにおいてタスク 完了時間が短くなっていると言える．特に，タスク 1，2，3 においては，完了時 間が大幅に短縮されている．しかし，タスク 5 においては，改善前と改善後で大 きな変化は見られなかった． そこで，改善前と後のカテゴリを最初に探索した被験者の割合の比較を表 12 に示す．タスク 1 では，電池が属していた AV 機器のカテゴリを最初に探索した ユーザの割合は 4%であったが，生活家電のカテゴリを探索したユーザの割合は 表 12 改善前と後のカテゴリを最初に探索した被験者の割合の比較 改善前のカテゴリ 改善後のカテゴリ 改善後のカテゴリ 改善前のカテゴリ タスク 1 4％ 54 ％ 13.5 タスク 2 13 ％ 46 ％ 3.5 タスク 3 25 ％ 71 ％ 2.8 タスク 5 29 ％ 46 ％ 1.6 44 54%と，13.5 倍の差があった．タスク 2 では，SD メモリーカードが属していた カメラのカテゴリを探索したユーザの割合は 13%であったが，パソコンのカテゴ リを探索したユーザの割合は 46%と，3.5 倍の差があった．タスク 3 では，マッ サージチェアが属していた健康のカテゴリの探索したユーザの割合は 25%であっ たが，生活家電のカテゴリを探索したユーザの割合は 71%と，2.8 倍の差があっ た．タスク 5 では，ファックスが属していた生活家電のカテゴリの探索したユー ザの割合は 29%であったが，オフィス機器のカテゴリを探索したユーザの割合は 46%と，1.6 倍の差であった．このように，改善前カテゴリと，改善後カテゴリの 探索ユーザの割合に，ある程度の差が存在しないと，カテゴリ分類の検討による 差がほとんど見られないことがわかった． つまり，他の項目と比較してタスク完了時間の長さでカテゴリの分類を検討す るのではなく，ユーザ行動を把握することによって，どの部分を改善すると効果が あるかを検討したうえで，Web ページの改善を行う必要がある．Webjig を利用す ることによって，より細かいユーザ行動を把握することが可能であるため，Web サイトのどの部分を改善するべきか検討することも可能になる．しかし，従来シ ステムではユーザ行動を詳細に把握することができないため，ユーザビリティ改 善の優先順位を検討することが困難である． 5.2 課題 2：自然なユーザ行動の取得 5.2.1 ユーザテストの限界 実験の結果，ユーザテストの被験者の行動と本来のユーザの行動には大きな差 があることがわかった．例えば，実験ではユーザテストにおける被験者のコンバー ジョン率は 100%であったにも関わらず，検索サイトから誘導した被験者のコン バージョン率は 7%であった．離脱するユーザ行動を把握することができないた め，ユーザテストによってユーザが Web ページから離脱する原因を探ることは 困難を極める． 45 5.2.2 Web ユーザビリティ評価における Webjig の有用性 Webjig を利用することで，Web サイトが本来対象とするユーザの行動を記録 することができる．記録されたユーザ行動を分析することによってユーザが離脱 する原因を効率的に追及し，改善できる可能性がある． ユーザテストの被験者は，Web ページにアクセス後，Web ページをスクロー ルさせずにフォームへの入力を開始した．しかし，実際のユーザの約半数は Web ページにアクセス後，Web ページをスクロールし，設問の量及び内容を確認して いることがわかった．つまり，最初にスクロールを行った時点で Web フォームの 内容に疑問を感じたり，設問の量が多いと感じた場合は離脱してしまう可能性が ある．そこで，不要な設問を表示しないように設定したり，ページを分割するな どして設問の数を少なく見せる工夫を行うことで離脱率が下がる可能性がある． また，ユーザテストのユーザは，Web フォームに記入を開始後，途中で離脱す ることはなかったが，実際のユーザの約 7 割は，フォーム入力中に離脱を行ってい る．Webjig を利用して Web フォームへの入力中のユーザ行動を取得することで， どの項目を入力中にユーザが離脱するかについて調べることが可能になり，わか りにくい文章の改善や説明の追加，設問の必要性の検討などを行うことによって， 離脱率を削減できる可能がある． 5.3 課題 3：テスト被験者のリクルーティング 実際に Web サイトのユーザビリティ評価を行う場合に問題となるのは，被験 者のリクルーティングである． 5.3.1 費用 Web サイトのユーザビリティ評価に費用をかけることが可能であるならば，ユー ザテストを行うことも可能であるが，一般に，ユーザテストにかけられる費用は プロジェクト全体の 10%程度までだと言われている．このため，2000 万円以上の プロジェクトでないと，ユーザテストを実施することができない [17]． 46 しかし，Web サイト制作会社である株式会社ミツエーリンクスの行った調査 [4] によると，Web サイトにかける年間予算の金額は 500 万円未満の企業が過半数を 占めており，多くのプロジェクトではユーザテストを実施するための費用を捻出 するのが困難であることがわかる． MouseTrack や UsaProxy 等の従来システムを利用することで安価にユーザビ リティ評価を実施することが可能になるが，調査会社を利用する際の費用が必要 になる． Webjig を利用することで，安価にユーザ行動を取得することが可能になり，小 規模なプロジェクトであっても，容易にユーザビリティ評価を実施することが可 能になる． 5.3.2 時間 ユーザテストを実施する場合，被験者のリクルーティングやユーザテストの準 備にある程度の時間が必要になる．また，従来システムを利用する場合であって も，被験者のリクルーティングやテストの準備に時間が必要になる． Webjig を利用する場合，Web サイトに Webjig をインストールするだけでユー ザ行動を記録することが可能になるため，ユーザビリティ評価の立案から，実際 に評価を行うまでに要する時間を短くすることが可能である．また，Web サイト へのインストールは，HTML ファイルに指定された SCRIPT タグを挿入するだ けであり，テキストエディタの利用経験があれば，比較的容易に行えるものと考 えられる． 47 6. おわりに 本論文では，まず，2 章でユーザビリティ評価の現状を述べ，従来システムの 課題として，動的 Web サイトのユーザビリティへの対応が困難であること，本来 のユーザ行動が取得できないということ，被験者のリクルーティングに多くのコ ストが必要であることを挙げた．次に，3 章において，これらの課題を解決する ためのシステムとして Webjig の提案を行った．次に 4 章で，提案した Webjig を 利用することで前述した課題を解決できているかどうかの評価を実施した．その 結果，5 章で示すように，課題を解決できていること確認した． 本論文では，Webjig の有用性を評価するために，動的なメニューから指定され た商品を探すというタスクで実験を行い，Webjig がユーザビリティ改善に有用 であることを確認した．しかし，1 章で述べたとおり，JavaScript を用いること で，様々な種類のアプリケーションを開発し提供することが可能である．このた め，様々な種類のアプリケーションにおいて Webjig が有用であるか評価するこ と，そして，実際に Web サイトを作成するプロセスに Webjig を組み込むことに よって，Webjig を利用しない場合と比較して，Webjig が有用であるかを確認す ることが今後の課題として挙げられる． 48 謝辞 本研究を進めるにあたり，多くの方々に御指導と御協力を頂きました．ここに お世話になった方々への感謝の意を表したいと思います． 奈良先端科学技術大学院大学情報科学研究科 松本健一教授には，本研究の主 指導教員を担当して頂き，また，研究に限らず研究室内での活動を支えて頂きま した．ありがとうございました． 奈良先端科学技術大学院大学情報科学研究科 関浩之教授には，本研究の副指 導教員を担当して頂き，多くの御意見や御指摘を頂きました．ありがとうござい ました． 奈良先端科学技術大学院大学情報科学研究科 門田暁人准教授には，本研究の副 指導教員を担当して頂き，発表練習では御意見や御指摘を頂きました．また，定 量班において多くの御指導を頂きました．研究に限らず研究室内での活動も支え て頂きました．ありがとうございました． 奈良先端科学技術大学院大学情報科学研究科 森崎修司助教には，サーバの運 営等で研究活動を支えて頂いた他，研究に限らず研究室内での活動も支えて頂き ました．ありがとうございました． 奈良先端科学技術大学院大学情報科学研究科 大平雅雄助教には，HCI 班にお ける研究の御指導のほか，研究室内での活動を支えていただきました．ありがと うございました． ソフトウェア工学講座の皆様には，本研究について多くの御協力を頂きました． 皆様には研究活動以外の様々な場面でも御助力して頂き，充実した時間を過ごす ことができました．ありがとうございました． サイボウズ・ラボ株式会社 代表取締役 畑慎也様には，未踏 IT 人材発掘・育成 事業のプロジェクトマネージャとして Webjig の実装および機能について多くの 御指導，御意見を頂きました．ありがとうございました． テクノロジーシードインキュベーション株式会社の堀田芳子様には，未踏 IT 人 材発掘・育成事業を通して様々な支援を頂きました．ありがとうございました． 日本アイ・ビー・エム株式会社 ベンチャー・ディベロップメント・エグゼクティ ブの勝屋久様，筑波大学大学院システム情報工学研究科 加藤和彦教授，株式会社 49 コーエー代表取締役 松原健二様には，未踏 IT 人材発掘・育成事業の中間報告会， 成果報告会等を通して，Webjig に対して様々な御指導，御意見を頂きました．あ りがとうございました． 独立行政法人情報処理推進機構には，Webjig の開発を支援して頂きました．あ りがとうございました． 株式会社ミツエーリンクスの栗山進様には，Web ユーザビリティの専門家とし て，ユーザビリティ評価についてご指導頂き Webjig についてのご意見を頂いた 他，システムの評価や研究の進め方についてについて，多大なご指導を頂きまし た．ありがとうございました． 日本アイ・ビー・エム株式会社 ユーザエクスペリエンスデザインセンターの皆 様には，インターンシップの際に大変お世話になりました．またユーザビリティ の専門家として，ユーザビリティ評価についてご指導頂きました．ありがとうご ざいました． 株式会社 jig.jp 代表取締役の福野大介様には，御社製品である jig ブラウザと Webjig の名前が似てることを笑って流して頂きました．ありがとうございました． 奈良先端科学技術大学院大学および奈良工業高等専門学校の多くの方には，被 験者として実験に参加して頂きました．ありがとうございました． 50 参考文献 [1] Document object model (dom) technical reports. available from http://www.w3.org/DOM/DOMTR accessed 2009-2-5. [2] Remote json - jsonp. available from http://bob.pythonmac.org/ archives/2005/12/05/remote-json-jsonp/ accessed 2009-2-5. [3] Rfc 4627 - the application/json media type for javascript object notation (json). available from http://tools.ietf.org/html/rfc4627 accessed 2009-2-5. [4] ウェブ サ イ ト に 関 す る ア ン ケ ー ト 調 査 報 告 書. available from http://www.mitsue.co.jp/case/questionnaire/2007/q09.html accessed 20092-5. [5] 携帯有料サイトの利用規約を必ず読む女性は 4 割弱. available from http://release.center.jp/2008/11/1001.html accessed 2009-2-5. [6] 離脱率が 90%は当たり前！ ？最後の難関『入力フォーム』の離脱を改善する. available from http://markezine.jp/article/detail/1582 accessed 2009-2-5. [7] Ernesto Arroyo, Ted Selker, and Willy Wei. Usability tool for analysis of web designs using mouse tracks. In CHI’06 extended abstracts on Human factors in computing systems, pages 484–489, 2006. [8] Richard Atterer and Albrecht Schmidt. Tracking the interaction of users with ajax applications for usability testing. In the SIGCHI conference on Human factors in computing systems(CHI’07), pages 1347–1350, 2007. [9] Carol M. Barnum. Usability Testing and Research. Longman, London, 2001. [10] Mon Chu Chen, John R. Anderson, and Myeong Ho Sohn. What can a mouse cursor tell us more?: correlation of eye/mouse movements on web browsing. In CHI’01 extended abstracts on Human factors in computing systems, pages 281–282, 2001. 51 [11] Larry Magid. It pays to read license agreements. available from http://www.pcpitstop.com/spycheck/eula.asp accessed 2009-2-5. [12] Florian Mueller and Andrea Lockerd. Cheese: tracking mouse movement activity on websites, a tool for user modeling. In CHI’01 extended abstracts on Human factors in computing systems, pages 279–280, 2001. [13] Jakob Nielsen and Thomas K. Landauer. A mathematical model of the finding of usability problems. In the INTERACT’93 and CHI’93 conference on Human factors in computing systems, pages 206–213, 1993. [14] Jakob Nielsen and Robert L. Mack. Usability Inspection Methods. Wiley, New York, 1994. [15] 岡田 英彦. ユーザビリティとその評価手法. システム制御情報学会誌, 45(5):269–276, 5 2001. [16] 吉武良治 山崎和彦, 松田美奈子. 使いやすさのためのデザイン ユーザーセ ンタード・デザイン. 丸善株式会社, 東京, 2004. [17] 樽本徹也. ユーザビリティエンジニアリング −ユーザ調査とユーザビリティ 評価実践テクニック−. 株式会社オーム社, 東京, 2005. 52