日本ソフトウェア科学会第 30 回大会 (2013 年度) 講演論文集

ユーザエクスペリエンスを考慮したソフトウェア開発支援
小南 祐貴

伊藤 恵

ソフトウェアを開発する際，満たすべき機能を実装していても実際に使用するユーザにとっては使用しにくいということがしばしばある．これは，開発工程においてユーザの使いやすさ (ユーザビリティ) が重要視されていないことや，ユーザビリティテストが不十分であることによって引き起こされる．そこで本研究では，ユーザが使いやすいと感じ，快適に利用できる，すなわちユーザエクスペリエンス (UX) が優れているソフトウェアを開発するための支援を行う．UX を考慮した開発の手法や，開発を進めていく中で開発者が行う UX のテストについて考案することで，ソフトウェアに対するユーザの満足度の向上を目指す．ここでは，単にユーザビリティやユーザインタフェースを向上させる開発手法やテストを考案するだけではなく，ソフトウェアを一貫して使用することに対する快適さや楽しさを向上させるための手法やテストを考案する．

Though systems engineers develop a software that has demanded functions by client, a software is often
hard to use for software users. That is because systems engineers do not regard usability as important andusability tests are not enough carried out. So this study support to develop software that has good user
experience: software users feel easy to use and comfortably. This study aims to improve satisfaction ofsoftware users by the following two propositions. First proposition is to develop methods of software thathas considered user experience. Second proposition is to draw up tests about user experience that systems
engineers carry out in the development processes. This study proposes development methods and tests
about improvement of not only usability and user interface but also comfort and enjoyment to use software.

また，ソフトウェアを設計する際に機能重視になって1 はじめにしまうということも原因の一つである．そのため機ソフトウェア開発において，多額のコストを費やし能としては優れていても実際に使用するユーザにとったにも関わらず，そのソフトウェアやシステムが長くて使いにくいソフトウェアになってしまう．

使用されないというケースがある．米国の Standish

本研究では，ソフトウェアに対するユーザの満足度グループの調査によると，実装したシステムのうちを向上させるため，ユーザにとっての使いやすさを考45%が一度も使われないという． [1] その使われなく慮したソフトウェアの開発手法やテストについて考なる原因がいくつか挙げられる．まず，開発者がユー案する．ここでは，単に使いやすさを表すユーザビリザの要望を理解しきれないため，ユーザの利用状況ティについてのみを扱うのではなく，ソフトウェアのに不適合なソフトウェアが作られてしまうという点

機能やユーザインタフェース，またソフトウェアを使である．次にソフトウェアの使いやすさを測るテスト用することに対する感情等，広い概念を踏まえたユーが開発工程で明確にされていないことが多く，テストザエクスペリエンス (以下 UX) を考慮した設計手法を行なっていてもそのタイミングが遅いことがある．

やテストの方法について扱う．

Software Development Support with consideration forUser Experience
Yuuki Kominami, Kei Ito, 公立はこだて未来大学システ
ム情報科学部, Dept. of Systems Information Science,Future University Hakodate.

らの評価方法は開発工程の終盤，もしくは開発後に行2 関連研究われることが多いため，結果の反映に時間がかかって2. 1 ユーザエクスペリエンスしまうという問題点がある．

UX は一般に，機能とユーザビリティに加え，「快2. 3. 1 ユーザビリティラボ

適である」または「楽しい」などといったプラスのユーザビリティラボと呼ばれる実験室でユーザに感情を加味して表されるものとされている． [2] また，ソフトウェアを使用してもらうことでテストをする．

ISO(国際標準化機構) により，「製品・サービス・環境その操作の様子ユーザビリティエンジニアが観察，分との対話操作の結果による，あるいはそれによって予析することでソフトウェアの評価，改善を行う．これ期される，ユーザーの感動，信念，好み，振る舞い，により，開発者が気付かなかった効果や欠陥を見つか成果のすべて」と定義されている国際規格である． [5]られるという一方で，テストユーザの力量により大きソフトウェアやシステムの機能が複雑化する中で，く結果が変わってしまうことがあるため，確実な結果ユーザが混乱なく直感的に使えるようにするため，を得るためには多くのユーザに対してテストを行わUX を考慮したソフトウェアが必要となる．

なければならず，時間がかかってしまう．また，普段のユーザの使用環境とは異なる状況でソフトウェアを2. 2 ユーザビリティ使用してもらうため，正確な結果を得られないことも

UX を表す要素の一つであるユーザビリティは，一ある．

般に使いやすさや利用品質などと言われることが多2. 3. 2 ヒューリスティック評価

いが，これも ISO により定義されており，ある製品ユーザビリティエンジニアやユーザーインタフェーを利用し，目的を達成するために用いられる際に以下スデザイナが，既知の経験則に照らし合わせてインタの項目から表される度合いのことを示している． [4]

フェースを評価し，ユーザビリティ問題を明らかにす• 有効さ
目標を達成する上での正確さや完全さ• 効率
目標を達成する際に正確さと完全さに関連して費やした資源• 満足度る評価手法のことであり，被験者を必要としないため短期間で評価できるという利点がある．しかし，そのエンジニアやデザイナによりアウトプットの質が変わってしまうという欠点がある．

2. 3. 3 プロトコル分析
被験者に発話しながら製品やサービスを利用して不快さのないこと，及び製品使用に対しての肯定もらい，そこで発生した問題を観察し分析する手法的な態度である．これは，被験者が間違った箇所・混乱した箇• 利用の状況

所・時間がかかった箇所などをリストアップし，その利用者，仕事，装置，並びに製品が使用される物

原因を分析・整理することで評価する．しかし，発話理的及び社会的環境にない認知処理の問題や，分析の処理に多大な時間やこれらを満たし，利用品質を高めることで優れたUX をもったソフトウェアに繋がる．

労力がかかってしまうという問題点がある．

2. 3. 4 CIF（Common Industry Format forUsability Test Report）

2. 3 ユーザビリティ評価

ISO により規格された，ユーザビリティ品質がど開発したソフトウェアがユーザにとって使用しやすの程度のレベルにあるのかを客観的に測定するためいものであるかを測るためにユーザビリティ評価を行の書式である．これはユーザビリティの問題点を見つい，その結果を元にソフトウェアをより良いものにしけ出すことよりもソフトウェアのユーザビリティレベていく．その手法としてアンケートやインタビューのルを品質としてとらえ，そのソフトウェアがどの程度ような手法から以下の様な手法がある．しかし，これのユーザビリティレベルにあるかを定量的に把握することを目的としている．

2. 4 ユーザビリティテストのポイント
まず，準備段階において，そのテストの目標を明確化すること，適切にタスクを指示すること，正しく被験者を選定することがポイントである．次に，実施段
階では，実際に使用される場面の状況と同じにし，問題の原因が分かるような進行で実際の使い方を再現する必要がある．そしてそれらを分析するにあたって，問題抽出の基準を明確にし，問題を想定する． [3]2. 5 ソフトウェア開発手法
ソフトウェアの開発工程としてウォーターフォールモデルというものが一般的に利用されている (図 1)．
これは工程を管理しやすく，チームメンバーが複数の作業場所に分散していても効率よく作業ができると

図2

プロトタイピングモデル

いうメリットがある．

2. 6 ソフトウェア開発工程と評価方法
このような開発工程にはいくつか問題点がある．
ウォーターフォールモデルではユーザビリティ及びUX についての評価をするプロセスが曖昧であり，図1 中の総合テストやシステムテストのプロセスで UXのテストを行なってしまうと手戻りが発生してしまう可能性が高くなってしまうという問題点がある．また，プロトタイピングモデルにおいては，評価のプロセスが明確ではあるが，大規模なシステムではプロトタイプの作成までに時間がかかってしまうため利用しにくいなど，手間と費用が多くかかってしまうという図1

ウォーターフォールモデル

また，プロトタイピングモデルと呼ばれる開発プロセスがある (図 2)．これは開発の始めの段階でユーザデメリットがある．

3 UX を考慮したソフトウェア開発手法の提案にプロトタイプという試作品を提示して，修正する

新たなソフトウェアの開発手法を提案する上で，優工程を繰り返していくことでユーザの要求を明確にれた UX についての定義をし，これまでの開発工程してから開発していく方法である．これにより開発に組み込めるような手法やテストにするにはどうすが進んだ段階での修正や手戻りが少ないというメリッべきかを考案する．

トがある．

3. 1 優れた UX の定義
本研究における UX についての定義をする．従来の UX の定義では単に UX とはどのようなものかを定義しているのみであるため，2.1 節で述べた「機能，れに基づいてテストを行う．

ユーザビリティ，プラスの感情」の 3 つの観点を元に，優れた UX とはどのようなものかを定義する．そうすることでソフトウェア開発で考慮すべき UX を明確にする．
そこで優れた UX の条件を以下に定義する．

(1) 要求された機能をすべて満たしている(2) 目標を達成するために，最小のステップで実現することができる直感的なユーザインタフェー
スである(3) システムを快適に利用でき，また使いたいと思うようなプラスの感情を得られる(4) 利用するユーザとその利用環境に適している
図3

UX を考慮した開発モデル

3. 2 UX のテスト開発が終了し，そのソフトウェアのユーザに利用

3. 2. 3 UX のテストの一例

してもらい，UX が優れているのかどうかを測るテス

以下の画面遷移図 (図 4) の UX のテストの一部をトと，開発の段階で開発者がそのソフトウェアの UX行う．この画面遷移図は書店の書籍検索システムで用を考慮しながら開発出来ているかを測るテストの二いられていたものであり，このような画面遷移図に対通りが考えられる．

して，チェックリストを元に UX のテストを行う．そ3. 2. 1 ユーザに利用してもらうテストのチェックリストの項目の一部として以下の項目が挙これまで利用されてきたユーザビリティテストを元げられる．に UX のテストを考案する．テストを行う際は，2.4• どの画面からでも最初の画面に戻れるか

節で挙げた，目標の明確化やテストの状況作り，問題• 操作中のミスを見越した画面遷移になっているか抽出の基準を明確にするなどのポイントに注意をして• ユーザが最も使用する操作が中心となっているか行う．ユーザにソフトウェアを使用してもらい，UXこのテストを終えた後に評価を行う．まず，一点目の度合いを判断するために，これまで使われてきたの「どの画面からでも最初の画面に戻れるか」というユーザビリティについてのチェックポイントに，UXチェックリストに関しては，操作が完了するまでは最についてのチェックポイントを加える．例えば，ユー初の画面に戻れないため，クリアされていない．そのザ自身の普段の利用状況や環境に合わせられるようため，最初の画面に戻れるような画面遷移図に書きな設計になっているかなどを考慮し，UX 全体の評価換える必要がある．次に，二点目の「操作中のミスをができるように考案する．

見越した画面遷移になっているか」については，図中

3. 2. 2 開発者が行うテストに確認画面があるため，クリアされていると言える．

外部設計や内部設計などの各プロセスにおいて UX

このようにチェックリストを一点ずつ確認し，すべてのテストを行うことで，開発工程の後半になってからクリアされた時に次の開発プロセスに進めるものとの手戻りを少なくできるように開発を進める (図 3)．

する．

そこでは，設計段階で作られたフロー図や画面遷移図などの図，またはプロトタイピングを用いて，タスク

4 開発手法・テストの評価操作の中で無駄な動きは無いか，他のタスクにスムー開発手法とテストを考案するだけでは不十分であズに移行できるかなどのチェックリストを作成し，そるため，手法やテストそのものの評価をして，開発手図4

ある書店における書籍検索システムの画面遷移図

法とテストを改善していく必要があり，その評価方法ない．そのため，完全に新しいソフトウェアの開発手を二通り挙げる．まず一つ目として，既存のソフト法やテストを考案するのではなく，これまでのソフトウェアのユーザに対して提案した UX のテストを行

ウェア開発手法やテストに沿った手法やテストを考案

い，テストをすることにより見つかった UX の優れすることで，現在行われている開発手法と相違を少なている点と問題点をそれぞれ挙げ，UX について評価くすることが，新しい開発手法やテストを導入する上できているかを調べる．二つ目として，既存の開発プで重要となる．

ロジェクトを対象に，開発中に作成した図をテストすることで評価を行い，完成したシステムに対してもテ6 まとめと今後の課題ストを行う．これらのテストを通して挙げられた問題

開発したソフトウェアの満足度を向上させ，ソフ

点の解決方法を考え，どの開発プロセスで改善できるトウェアをしっかりと使用してもらうため，UX を考のかを考える．

慮したソフトウェア開発を支援する．そこで，ソフトウェア開発工程において，開発の早い段階から UX

5 UX を考慮したソフトウェア開発手法の導入
ソフトウェア開発にかけられる費用や工数が限られている中で，UX のテストに多くの費用をかけられのテストを実施し，ユーザにとって使用しやすいソフトウェアに近づける開発手法の提案を目指して概要を検討した．
その開発手法を考案する上でテストする上でのチェックポイントをより具体化し，ユーザビリティテ

参 考 文 献ストとは異なる UX のテストの分析方法を明確化し[1] Clancy, T.: Standish Group Study Report in2000 Chaos Report, http://www.spinroot.com/spin/Doc/course/Standish_Survey.htm, 2000.
[2] ISO9241-11: Ergonomic requirements for oﬃce
work with visual display terminals. Guidance on
Usability, 1998.
[3] 黒須正明: ユーザビリティテスティング‐ユーザ中心のものづくりに向けて, 共立出版, 2003.
[4] 神原典子: ソフトウェアユーザーエクスペリエンス設計, 日経 BP 社, 2010.
[5] 川西裕幸, 栗山進, 潮田浩: UX デザイン入門〜ソフトウェア＆サービスのユーザーエクスペリエンスを実現するプロセスと手法〜, 日経 BP 社, 2012.

なければならない．またユーザのソフトウェアの使用環境の調査方法やその結果に対してどのようなテストが最適なのかを考える必要がある．そして，開発者にとってその手法がどのような影響を与えるかを調査し評価し，スムーズに UX を考慮したソフトウェア開発手法を提案したい．