第４分科会（リライトチーム）

ユーザのぼやきから始める使い勝手の問題箇所導出手法の提案
Extraction Method of Usability Issues from User’s Ambiguous Complaints
主査：金山
副主査 ：三井村上
リーダー ：齋藤
研究員 ：羽原中野

豊浩（株式会社ミツエーリンクス）
英樹（Weblysts.com）
和治（東京海上日動システムズ株式会社）
綾乃（株式会社インテック）
寿和（株式会社東芝）
宏昭（富士ゼロックス株式会社）

研究概要
システムのユーザから「ごちゃごちゃしている」，「面倒くさい」などの使い勝手に関する抽象的な指摘が挙げられた場合，現状では開発者がシステム改善などの対応をすることが難しい．なぜなら，ユーザの声から具体的な問題（システム改善の要件）を把握することができないからである．そこで本研究では，ユーザの声をもとに使い勝手の問題箇所を導出するための手法を提案する．本手法では，ユーザの声とそれを構成するシステム上の問題となりうる箇所を抽出し，表にまとめた．この表を用いて対象のシステムを評価することで，ユーザビリティの知識がない開発者でも問題箇所の絞込みができることを確認した．
Abstract
We face ambiguous complaints about usability of business system from users often such like,"Bothersome", "Messy". In this case, it is very difficult for developers to improve the system,
because they can’t locate concrete issues based on such user’s complaints. In this report, we
propose a new method to extract concrete issues about usability in the system from ambiguouscomplaints. In this method, we associate user’s ambiguous complaints with typical issues anddefine indexes. Evaluating the target system using those indexes, developers can narrow relativeproblems with user’s complaints in the system without knowledge of “Usability”.
1.

はじめに
業務システムの運用・保守フェーズにおける課題の一つ が，「画面がごちゃごちゃして見づらい」，「操作がいちいち面倒くさい」などのユーザからの使い勝手に関する抽象的な指摘が開発者にフィードバックされた際，開発者が指摘の裏にある問題を正確に把握できず，システム改善などの対応をすることが難しい点である．その結果，ユーザからの指摘をシステムの開発に取り入れられないため，ユーザのシステムの使い勝手に対する不満が解消されず，問い合わせ対応にかかる保守コストが削減できない，作業効率の悪化やシステムを使ってやりたいことができないといった事態に陥り，最悪の場合，システムが使われなくなるなどの影響が出る可能性がある．
上記課題の対応には，ユーザの言葉をシステム改善の要件に変換するためのユーザビリティの知識が必要だが，開発者はユーザビリティの知識を備えていないことが大半である ．
そこで，ユーザビリティの知識がない開発者でも利用できる指標があれば，ユーザからの使い勝手に関する抽象的な指摘の裏にある問題を把握するための手がかりになるのではないかと考え，ユーザの声をもとに使い勝手の問題箇所を導出するための手法を提案する．
本手法では，ユーザからの使い勝手に関する抽象的な指摘について，それを構成するシステム上の問題となりうる箇所を抽出し，表にまとめた．実験により，この表を用いて対象
1

第４分科会（リライトチーム）のシステムを評価することで，ユーザビリティの知識がない開発者でも問題箇所の絞込みができることを確認した．
以降，第 2 章で本研究を実施するに至った背景，問題を示す．第 3 章で本研究の関連研究，第 4 章で提案する「ユーザの声から使い勝手の問題箇所を導出する手法」の実施プロ
セスと指標の内容を説明する．第 5 章で提案手法の有効性についての実験内容と結果を示し，第 6 章でまとめとして本研究の考察と今後の課題について述べる．
2.

背景・扱う問題
業務システムの運用・保守フェーズでは，問い合わせ窓口にシステムの使い方についての質問，不具合の報告，仕様の確認，改修要望など，ユーザからさまざま な照会がくる．
その際，ふとした時にユーザからぼそっと「画面がごちゃごちゃして見づらい」，「操作がいちいち面倒くさい」などの使い勝手に関する抽象的な指摘が発せられる場合がある．業
務システムにおいて，システムが使いづらいことが業務の効率や精度に直結するため，このようなユーザの声は非常に重要であり，対応すべきだと考える．しかし，そういった指摘が開発者にフィードバックされた場合，開発者は指摘の裏にある問題を正確に把握できず，システム改善などの対応をすることが難しい．その要因を研究員各社からヒアリングした結果，次の 4 点が挙がった．
・ユーザからの使い勝手に関する抽象的な指摘が「ごちゃごちゃしている」，「面倒くさい」などのユーザの抽象的な言葉のため，指摘の裏にある問題を正確に把握できない・ユーザに指摘内容の詳細を聞く機会がなく，機会があったとしてもユーザ自身もどこが問題なのかを具体的に理解しておらず，説明できない・システムの使い勝手を把握するために用いられるユーザビリティの 知識がないため，問題の調査方法がわからない
・運用・保守フェーズにおいて，問題を特定するための調査時間，ユーザビリティの専門家に問題把握や対応策の立案を依頼する費用が予め確保されていないため，対応できない
上記の理由により，ユーザからの指摘をシステムの開発に取り入れられないため，システムの使い勝手の不満が解消されず，問い合わせ対応にかかる保守コストが削減できない，作業効率の悪化やシステムを使ってやりたいことができない といった事態に陥り，最悪の場合，システムが使われなくなるなどの影響が出る可能性がある．
以上より，開発者がユーザからの使い勝手に関する抽象的な指摘の裏にある問題を正確に把握できず，システム改善などの対応策の検討，対応を実施することが難しいという点を解決すべきだと考える．ただし，本研究としては「開発者がユーザからの使い勝手に関する抽象的な指摘の裏にある問題を正確に把握できない」という点が，ユーザの声がシステム改善に結びつかない根本の原因であると考え，これを課題として定義する．また，研究対象のシステムは，研究員各社から課題が挙がった Web ベースの業務システムとする．
3.

関連研究
システムの使い勝手を評価し，問題点を把握する代表的な手法として「ユーザテスト」
がある．これはユーザに実際にシステムを操作してもらい，問題点の抽出やパフォーマンスを測定する手法である．しかし，「ユーザテスト」は実際のユーザからフィードバックが得られるため有効性が高い反面，ユーザがシステムを操作している場面を直接観察する，もしくはユーザへのヒアリングを実施することが必要となる．そのため，「ユーザテスト」はシステムの開発フェーズで行われることが多く， 実運用に入った後では開発者及びユーザ双方にとって負担が大きく，実施が難しい．
一方，実際のユーザに頼らずにシステムの使い勝手を評価する代表的な手法として「ヒューリスティック評価」がある．ヒューリスティックスとは「経験則」を意味し，「ヒュー2

第４分科会（リライトチーム）
リスティック評価」とは，ユーザビリティに関する経験則にもとづき，システムが抱えるユーザビリティの問題点を探索する手法である．代表的なヒューリスティックスとしては，
Nielsen の提唱する「10 ヒューリスティックス（10 heuristics）」 [1][2] や Shneiderman の「8 つの黄金律」，ISO9241 の「対話の 7 原則」が知られている [3] ．しかし，「ヒューリスティック評価」を実施するにあたっては以下の課題がある．
・問題の発見率の観点から，「複数人」且つ「開発者以外の第三者」による評価が推奨されている [3] ため，評価者を開発者以外から集める必要がある・ヒューリスティックスは認知度が低く，抽象度が高い表現が使用されているため，使用するヒューリスティックスについて評価者，及び評価に携わる開発者が詳しく理解している必要がある
このため，ユーザビリティの知識のない開発者が，リソースが十分にない運用・保守フェーズにおいて「ヒューリスティック評価」を実施することは難しい．
以上のことから，「ユーザテ スト」や「ヒューリスティック評価」ではなく，ユーザビリティの知識がない開発者が，開発者自身でシステムの問題点を把握する手法が必要であると考えた．
4. 提案
4.1 不満分解表の提案
そこで，ユーザビリティの知識がない開発者が，ユーザからの使い勝手に関する抽象的な指摘から，システムの具体的な問題点の候補を把握するためのツールとして「不満分解表」を提案する．
4.2 不満分解表2 章で述べたように，ユーザからの使い勝手に関する抽象的な指摘から，開発者が具体的な問題点を把握することは難しい．そこで，ユーザの声（指摘，不満，ぼやき）とシス
テム上の典型的な問題点の紐づけを行い，それを「不満分解表」として定義した．ユーザの声については，Joey Benedek，Trish Miner により定義されている「リアクションカード」 [4] をもとに絞りこみを行い，Jesse James Garrett の UX5 階層モデル [5] を参考に分類を行った（表 1，付録-A）．
表 1：ユーザの声（指摘，不満，ぼやき）一覧
UX の 5 階層 ユーザの声（指摘，不満，ぼやき）
表層

色やアイコンなどヴィジュアル面に対する指摘：
直観的でない，ピンとこない，チカチカする骨格

画面内で情報が整理されていないことに対する指摘 ：ごちゃごちゃしている，わかりづらい，一貫性がない構造

システム全体として情報が整理されていないことに対する指摘：
面倒くさい，イライラする，鬱陶しい，しっくりこない，パッとできない

本研究では，この中からユーザの声として得られることが多い [6] 2 項目「ごちゃごちゃしている」，「面倒くさい」を選定し，それぞれに不満分解表を定義した（表 2，付録-B）．
不満分解表は「因子」「指標」「閾値」で構成されており，各用語は以下を意味している．
因子：ユーザの声（指摘，不満，ぼやき）を引き起こす要因となりうるもの
指標：システムが因子を有するかどうかを判断するための計測項目
閾値：計測値を評価するための基準
因子については，Nielsen の 10 ヒューリスティックスをもとに抽出を行った（付録-C）．
また，閾値については仮決めし，妥当性も含めて検証を行った．なお，入力作業に関連す3

第４分科会（リライトチーム）
る付録-B の一部因子や表 2 の No.5 の因子については汎用的な閾値を設定するには至らなかったため，妥当性確認の対象からは除外している．
表 2：不満分解表「ごちゃごちゃしている」
No.

因子

指標閾値

1

雑然と並んでいる（例：規則性がわからない）

１カテゴリ内の項目数

10 以上

画面内のカテゴリの数

13 以上

2

余白がない

横並びのブロックの数
5 以上（画面全体での 横並び の大きなブ ロ
ックの数，または 1 ブロック内の小さなブロックの横並びの数）

3

定義のわからない言葉が多い（例：生活ガイド）

定義がわからな い言葉 の数，また は 4 以上同じ言葉にもか かわら ず異なる意 味
で使われている言葉の数

4

色が多い

画面内の色味※の数（※マンセル色相環 [7] の 10 色相）

5あたりがつけられない

目的の選択肢を クリッ クするまで の 秒数

8 以上

4.3 不満分解表の利用手順
本研究で提案する手法の実施手順は次の 4 ステップである．
(1) ユーザの声をもとに対応する不満分解表を選定する(2) 不満分解表の各因子について指標に従い，該当システム の計測を行う(3) 各因子について指標の計測結果と基準を照合し，閾値を超えた因子を抽出する(4) 抽出された因子を問題点の候補として検討する
以下に各ステップの詳細な実施手順を示す．
(1) ユーザの声をもとに対応する不満分解表を選定する「ごちゃごちゃしている」，「面倒くさい」といったユーザからの使い勝手に関する抽象的な指摘をもとに，該当する不満分解表を選定する．例えば，ユーザから「面倒くさい」という声が得られた場合，「面倒くさい」に対応するシステム上の問題点の候補は，付録-B に示す 6 因子となる．
(2) 不満分解表の各因子について指標に従い，該当システム の計測を行う(1)で選定した不満分解表内の各因子について，それぞれ該当する指標に従い，システムに対して計測を行う．計測する項目は大きく分けて以下の 2 つである（表 3）．
表 3：計測項目の種類
設計値から確認できる指標値

システムの設計値から取得する値（例：「1 カテゴリ内の項目数」）

計測して取得する指標値

実際にシステムを操作し，計測することで値を取得（例：「目的の選択肢をクリックするまでの秒数」）

1 つは，システムの設計値から確認できる値，もう 1 つはユーザの運用シーンを想定し，システムを実際に操作し て時間や操作回数を計測することで値を得るものである．
例えば，表 2 の No.1 の因子「雑然と並んでいる」の指標である「1 カテゴリ内の項目数」
4

第４分科会（リライトチーム）
は，各画面の設計値から確認できる指標値である．一方，No.5 の因子「あたりがつけられない」の指標である「目的の選択肢をクリックするまでの 秒数」は，実際に操作してかかった時間を計測することで得られる指標値である．
(3) 各因子について指標の計測結果と基準を照合し，閾値を超えた因子を抽出する
問題点の候補がどこにあるか絞り込みを行うため，各項目に閾値を設けている．この
閾値と計測値を比較し，基準値を超えるものを抽出することで，具体的な問題点の候補を絞り込むことができる．例えば，表 2 の No.1 の指標である「1 カテゴリ内の項目数」
について，9 以下であればカテゴリ内の項目数の影響で「ごちゃごちゃしている」という印象をユーザに与えている可能性は低いと判断でき，10 以上であればカテゴリ内の項目数の多さが要因の 1 つとなっている可能性が高いと判断できる．
(4) 抽出された因子を問題点の候補として検討する(1)～(3)の結果で得られた項目（閾値を超えた因子）が使い勝手に影響しているシステム上の問題点候補となる．これにより，はじめは漠然としていた ユーザからの使い勝手に関する抽象的な指摘を，ユーザビリティの専門家に頼らず，開発者自身が具体的なシステムの問題点として検討することが可能となる．
5. 提案手法を用いた評価実験
5.1 実験内容
本研究では，提案手法の有効性を確認するため，以下の 2 つの研究課題を定義し，実験を行った．
研究課題 1：不満分解表による評価と，評価者の感覚による評価が同様の傾向になるか（不満分解表内の因子と指標の妥当性評価）
研究課題 2：ユーザビリティの知識がない評価者でも評価ができるか（不満分解表の利用手順の妥当性評価）
実験のステップは以下の 6 ステップである．なお，本研究の対象は Web ベースの業務システムであるため，Web サイトで検証を行った．
(1) 評価対象となる Web サイト（計 6 件）を選定する（説明のため，選定した Web サイトを以下では，A～F として記載）(2) ユーザビリティに関する専門知識がない人を評価者として選定 する（計 3 名）
（研究課題 2 に対応）
(3) 各評価者が評価対象の Web サイトそれぞれにアクセスし，以下 3 つの作業を目的として操作，記録を収集する
作業 1：転入届の申請方法
作業 2：傘をゴミ回収に出す際のルールの確認
作業 3：子供手当の申請方法(4) 「ごちゃごちゃしている」，「面倒くさい」の 2 つの観点で，評価対象の Web サイトそれぞれに官能評価を行い，順位付けを実施する(5) (3)の操作記録，操作中に参照した Web ページの構造や見た目に基づいて不満分解表を用いて評価者が評価を実施する（研究課題 2 に対応）
(6) (4)と(5)のそれぞれの評価結果を比較する（研究課題 1 に対応）
(1)については以下を考慮し，市町村のホームページを評価対象とした．
・評価対象の Web サイトすべてに対して同じ目的の作業が可能なこと
・各 Web サイトのデザインが異なること
5第４分科会（リライトチーム）
・各 Web サイトはさまざまなユーザに，さまざまな目的で利用されていること・評価者にとって評価時に行う作業が容易に理解できること・評価時，サイトにアクセスしやすいこと（評価作業における障害がないこと）
各 Web サイトを評価する際，(3)に示した通り，アクセスする目的を「転入届の申請方法」など，身近で理解しやすい作業とした．また，(4)での順位付けについて，「面倒くさい」という感覚は操作の内容に大きく依存すると考え， 3 件の作業それぞれについて評価を行った．(5)での「ごちゃごちゃしている」に関する各 Web サイトの評価は，操作中に最も「ごちゃごちゃしている」と感じたページを対象に評価を行った ．(6)の比較の手順としては，まず指標ごとに評価対象の順位(1 位～6 位)を求め，適用するすべての指標の順位を評価対象ごとに合計した．その後，その合計値の少ない順で順位付けした結果を不満分解表を用いた評価結果とし，官能評価の結果との比較を行った．
5.2 実験結果
5.2.1 不満分解表「ごちゃごちゃしている」（表 2）に関して
5.1 で示した実験のステップの(3)提案手法による評価，(4)評価者の官能評価の結果を以下に示す（図 1，図 2）．なお，「定義が分からない言葉の数」（No.3）の指標については，今回の実験では評価対象ごとの違いが明確には検出できなかったため報告の対象から除外
し，「1 カテゴリ内の項目数」と「画面内のカテゴリの数」（No.1），「横並びのブロックの数」（No.2），「画面内の色味の数」（No.4），及び各作業での「目的の選択肢をクリックするまでの秒数」（No.5）について評価結果を説明する．

図 2：実験結果「ごちゃごちゃしている」（計測値）

図 1：実験結果「ごちゃごちゃしている」（設計値）

図 1 は「1 カテゴリ内の項目数」，「画面内のカテゴリの数」，「横並びのブロックの数」，「画面内の色味の数」についての実験結果であり，左の軸（積み上げ棒グラフ）は不満分
解表内の指標ごとの順位の合計値を示し，右の軸（折れ線グラフ）は官能評価での順位(ごちゃごちゃ順)を示している．例えば評価対象 A では，「1 カテゴリ内の項目数」は 3 位，「画面内のカテゴリ数」は 4 位，「横並びのブロックの数」は 3 位,「画面内の色味の数」は 4位であり，4 つの指標を合わせた結果はそれぞれの順位を合計し， 14 となっている．図 2
は「目的の選択肢をクリックするまでの秒数」についての実験結果であり，左の軸（積み上げ棒グラフ）は作業 1 から作業 3 の作業時間の順位を合計した値，右の軸（折れ線グラフ）は図 1 と同じく官能評価の順位を示している．図 1 の積み上げ棒グラフの凹凸（不満分解表による評価結果）と折れ線グラフ（官能評価の結果）から，評価対象 D と E 以外については，不満分解表による評価と官能評価は同様 の傾向であると言える．評価対象 D とE は，不満分解表による評価ではごちゃごちゃしている状態ではないという結果であったが，感覚的にはごちゃごちゃしていると評価されている．これは今回採用した指標の他に，感覚的な評価に影響を与える指標が存在するためだと思われる．また，図 2 に示す通り，今回の実験では「目的の選択肢をクリックするまでの秒数」と感覚的な評価には関連が見られないという結果となった．これは，作業にかかる時間が さまざまな要因から影響を受ける指標であるためと考えられ，指標の詳細化や別指標の検討を含め，改善が必要である．
6

第４分科会（リライトチーム）
5.2.2 不満分解表「面倒くさい」（付録-B）に関して
作業１から作業 3 のそれぞれの実験結果を以下に示す（図 3，図 4，図 5）．なお，「「あれ？」と思った回数」（No.3）と「異常時の手戻り最大ステップ数」（No.6）については今回の実験では評価対象ごとの違いが明確には検出できなかったため報告の対象から除外し，「ユーザ操作の切り替わり数」と「遷移する画面数」（No.1），「実施ステップ数/最小ステップ数」（No.4）について説明する．図 3，図 4，図 5 の左の軸（積み上げ棒グラフ）は不満分解表内の指標ごとの順位を合計した値を示し，右の軸（折れ線グラフ）は官能評価での順位(面倒くさい順)を示している．

図 3：実験結果「面倒くさい」（作業 1）

図 4：実験結果「面倒くさい」（作業 2）

図 5：実験結果「面倒くさい」（作業 3）

図 3 により，作業 1 に関しては不満分解表による評価と官能評価が同じ傾向となっており，作業 1 に対する不満分解表の適用は妥当であることを示すことができた．図 4 に示す
作業 2 に関する実験結果については，不満分解表に よる評価と官能評価が概ね同じ傾向になっていることを示すことができているが，評価対象 F については乖離がある結果となっている．これは，「遷移する画面数」が多い場合でも「面倒くさい」という感覚には直結しないことがあるためと考えられ，この点ついて今後も検討が必要である．また，図 5 に示す作業 3 に関する実験結果については，不満分解表による評価と官能評価の結果には関連性が見られなかった．これは分析に用いた計測値の中に，評価者が作業 3 の目的を達成できなかった場合の値が含まれていることが原因であった．この結果により不満分解表による評価では，評価者が目的を達成できた場合の計測値のみを用いた方が妥当な結果を得られるということが分かった．
5.2.3 不満分解表の閾値の妥当性評価
不満分解表の閾値について，以下の方法で妥当性の確認を行った．
(1) 官能評価の結果をもとにユーザにより受け入れ不可と評価されたサイトと受け入れ可と評価されたサイトの 2 グループに分類する （前者を NG グループ，後者を OK グループとする）(2) それぞれのグループに対して閾値を超えているサイトの割合（閾値を超えているサイト数/グループ内のサイト数）を，指標ごとに算出する(3) (2)で算出した OK グループと NG グループの結果を比較し，OK グループと NG グループが同一，若しくは NG グループのほうが多ければ，閾値は妥当と判断 する
なお，今回の評価に用いたデータでは，閾値を評価する程の有意な差が見られない指標
7

第４分科会（リライトチーム）があった．このため，「ごちゃごちゃしている」については，「1 カテゴリ内の項目数」，「画面内のカテゴリの数」，「画面内の色味の数」の 3 つの指標，「面倒くさい」については「実施したステップ数/最小ステップ数」の 1 つの指標を対象に評価を行った．なお，「面倒くさい」に関する作業 2 の計測結果と，作業 3 のうち，評価対象 F に関する計測結果は，官能評価の結果との関連性が見られなかったため，閾値の妥当性評価には用いていない．
妥当性評価の結果を以下に示す（表 4）．いずれの指標についても，(3)の手順にて閾値は妥当であると評価できた（付録-D）．
表 4：閾値の妥当性評価の結果
ユーザの声指標

評価結果
NG グループでの割合

OK グループでの割合

1 カテゴリ内の項目数

2/3

2/3

画面内のカテゴリの数

1/3

0/3

画面内の色味の数

1/3

0/3

面倒くさい（作業 1） 実施ステップ数
面倒くさい（作業 2） /最小ステップ数

2/2

1/4

面倒くさい（作業 3）

3/3

ごちゃごちゃしている※官能評価との関連性が見られないため，適用外
1/2

6.

まとめと今後の課題本研究でユーザからの使い勝手に関する抽象的な指摘のうち「ごちゃごちゃしている」,「面倒くさい」の 2 つの声を取り上げ，不満分解表を用いたシステム上の問題箇所の絞込み手法を提案し，実験により妥当性を確認した．また，ユーザからの使い勝手に関する抽象的な指摘に対して関連する因子を挙げ，評価のための指標と閾値を定めるという一連のアプローチが有効であることを示すことができた．これによって，ユーザのぼやきのようなフィードバックも，システムの改修要件に落とし込める一つの道筋ができたのではないかと考える．ただし，一部因子の閾値の検討や，業務システムでの有効性，汎用性の確認が不十分であるため，これらについて今後検討が必要である．また，今回取り上げなかったユーザの声（例：イライラする，今っぽくない）についても本研究と同様に，指標と閾値を定めて評価を行うことで，システム上の問題箇所の導出につなげることが可能であると考えている．この場合，本研究での検討方法を整理し，手順としてまとめる必要 がある．
また，今回提案した不満分解表や実験は，ユーザ特性（システムに対する知識の十分性，システムの利用目的など）を考慮していない．しかしながら，現実の問題に適用する際には，例えばユーザ特性ごとに指標や基準を整備する，ぼやきの言葉の流行への追従など，必要に応じてより細かな対応が必要であり，この点について引き続き検討が必要である．
7. 参考文献[1] Jakob Nielsen，「ユーザビリティエンジニアリング原論-ユーザーのためのインタフェースデザイン 第 2 版」，2002[2]山崎和彦，松原幸行，竹内公啓，「人間中心設計入門 第 0 巻」，2016[3]樽本徹也，「ユーザビリティエンジニアリング-ユーザエクスペリエンスのための調査、設計、評価手法」，2008[4]Tom Tullis，Bill Albert，「ユーザーエクスペリエンスの測定 UX メトリクスの理論と実践」，2014[5]Jesse James Garrett （ 浅 野 紀 予 訳 ）， The Elements of User Experience ，
http://www.jjg.net/elements/translations/element s_jp.pdf，2000[6]Jakob Nielsen，Raluca Budiu，「モバイル・ユーザビリティ 使いやすい UI デザインの秘訣」，2013[7]近江源太郎,「色の名前に心を読む 色名学入門」，2008
8

第４分科会（リライトチーム）
付録-A：UX の 5 階層とユーザの声の対応※ユーザの声の分類が複数階層にまたがっているものは，各階層に重複してユーザの声を記載している．

9

第４分科会（リライトチーム）
付録-B：不満分解表「面倒くさい」
No.

因子

指標

1

ステップ数が多い
ユーザ操作の切り替わり数
7 以上（ 例： 異 な る カテ ゴ リ に 移動 す る （入力→次へ→入力→… だと 3 ス
ためにステップがかかる）
テップ．スクロールも 1 ステップ）
遷移する画面数

閾値6 以上2目 的達 成 ま で にか か る 時 間が 見 積 自 分 の 「 位 置 」 が 分 か る 情 報 の 表 示 表 示 がもれないの有無ない（例：あと○分かかります
全 4 ステップ中 2 ステップ目）

3

思い通りの動きにならない（例：戻るボタンで始めに戻る操作ごとに読み込む不要な操作を強要される）

4

たどり着けない
実施ステップ数/最小ステップ数（最 2 以上
（ 例： や り た いこ と の 操 作方 法 が 短）不明，構造がわからない）

5

不要な情報が出てくる（例：何度も勧められる何度も確認される）

6・ エラ ー で 過 去の 入 力 が すべ て 消 異常時の手戻り最大ステップ数
える・ 一通 り の 操 作が 終 わ っ てか ら 最
初の方の入力エラーが表示される

3 以上

-

入力項目が多い-「あれ？」と思った回数

2 以上

×ボ タ ン や キ ャ ン セ ル ボ タ ン を 押 す 2 以上
回数

実際の入力項目

ユーザが想定する入力項目数とのギ ャップ（割合）入 力 項 目 で 必 須 /オ プ シ ョ ン が 分 か 分 か れれている（Yes/No）
ていない-

目的達成に必要な操作が複雑

操作の煩わしさ高：直接入力中：選択肢あり
低：確認のみ-誤操作の未然防止がない

サポートされていない文字が入力で きる（操作後にエラーとなる）-

熟 練し て も 作 業効 率 が 改 善で き な マウスなしで操作できないい※“-”の項目は，本研究内では測定できなかった因子を示している．
10--

第４分科会（リライトチーム）
付録-C：ユーザの声の因子分解結果

付録-D：妥当性検証結果（「面倒くさい」（作業 2））

3.5
3

OK内閾値越え数

閾値越え数

2.5

NG内閾値越え数

21.5
10.5
000.5

12

2.5

33.5

閾値
1144.55