SEEDATAでは、生活者の価値観の変化や未来の兆しをキャッチするために、通常小規模の対象者についてデプスインタビューを行い、背後にあるインサイトを発掘することを日々行っています。それでは、インサイトを抽出するために必要なインタビューの数は、一体どの程度なのでしょうか？このブログでは、ニールセンらが1993年に発表した重要な論文を読み解きながら、課題発見に必要なインタビュー実施数と、その数理モデルについて議論していきたいと思います。
今回は、以下の論文をベースに議論を展開します。
この論文では新商品のユーザビリティ問題の解決を目的として、ユーザー本人やヒューリスティックス評価者へのヒアリング数とその効用を数理的にモデル化しています。それでは論文の主旨を理解するために、新商品開発にまつわる今回の対象について理解していきましょう。
1. プロダクト開発における問題の特定
1.1 ユーザビリティテストとヒューリスティック評価について
商品開発において、ユーザビリティテストとヒューリスティック評価は重要なプロセスですが、これら2つの方法は全く異なるアプローチをとります。ユーザビリティテストはユーザー本人たちを招集し、彼らがプロダクトを通して、特定のタスクセットを実行する様を観察します。対してヒューリスティック評価は、ユーザビリティの専門家に、開発したユーザーインターフェイスを判断させることに基づいています。
またこれらの2種類の評価を実行するメカニズムは大きく異なり、どちらの方法にも長所と短所があります。たとえば、ユーザーテストでは、実際のユーザーの考え方や働き方についての洞察が得られます。ヒューリスティック評価は、実ユーザーを持ち込んだり、プロダクトとのインタラクションを分析したりする必要がないため、セットアップが容易であり、一般的な問題と解決策に関する専門的な科学的および経験的知識を活用します。 ただし、一般的なユーザビリティエンジニアリングの観点からは、ユーザーテストとヒューリスティック評価には2つの重要な類似点があります。まず、どちらもユーザビリティ問題の発見と、そのデバッグを目指しているということです。 2つ目は、どちらも複数の小規模な評価研究の結果を集計することです。
つまり、問題を同定するためにはある程度の調査で打ち切る必要があり、経済的・時間的なコストの両面から大規模な調査を行うのは得策ではないのです。実際に行われている最新のユーザビリティエンジニアリング作業には、評価プロセスを事後的に行う見方があり、予め決めた調査規模の結果、完成した調査全体を分析しています。そこで本論文では、評価プロセスを調査と同期させ、十分な情報がいつ得られたかを判断することに関心がある場合を想定します。
1.2 モデル化に用いるデータセット
論文では、5つのユーザーインターフェイスの経験的ユーザーテストと6つのヒューリスティック評価のケースのデータを用いています。以下の表は、11の調査をすべてをリスト化し、それらの関連特性のいくつかを要約したものです。
Nielsen, et al (1993). Table1
これを見ると、ケースステディの評価者の数(Number Subjs.1 EvaIs.)は10から40程度、最大で77となっています。また下段Banking Systemは、3つの独立した評価者グループによって評価され3つのデータセットが生成されたため、データセットの総数は13となります。それぞれ発見されたユーザビリティ問題は、決して調査人数に比例しているわけではなく、9つの場合もあれば100以上発見された例もあります。次に、これらのデータをポアソンモデルでフィッティングすることを考えます。
2. ポアソンモデルによるモデル化
2.1 ポアソンモデルを導入するための仮定
上記のデータを通してモデルを開発するために、ユーザビリティの問題の発見について、いくつか基本的な仮定を行います。ポアソンモデルでは、特定のテストで特定のユーザビリティの問題が見つかる確率は、以前のテストの結果とは無関係であることが要請されます。 ある種のユーザビリティ評価では、この仮定はかなり合理的であるように思われます。例えばヒューリスティック評価は、評価者が互いに独立してインターフェースを検証することによって行われます。この手順では、特定の評価者が特定の問題を1つ見つける可能性は、他の評価者がその問題を見つけたかどうかとは無関係であることは明らかです。
ユーザーテストでは、ユーザビリティ問題の発見は2つの要因に依存します。1つ目は、被験者が問題を実際に経験しなければならず、2つ目は、実験者がユーザーが問題を経験したことを認識しなければなりません。ユーザーテストが古典的な実験方法論に従って実行される限り、被験者はおそらく互いに独立していると考えることができます。ただし、実験者の役割に関しては、独立性の仮定がすべての場合に当てはまるわけではありません。というのも、ユーザーが問題を経験したと実験者が認識するためには、同じような問題を以前確認した（認識していない）かどうかに依存する場合があるためです。このような際どい仮定にもかかわらず、本論文ではユーザビリティ問題発見のプロセスが、ポアソンモデルで近似できる可能性を示唆しています。
またこれまでの議論は、1つのユーザビリティ問題の発見に集中してきました。実際のプロジェクトでは、当然のことながら多くのユーザビリティの問題があり、いくつかのユーザビリティの問題の発見を説明するモデルが必要です。1つのユーザビリティ問題についてはポアソンモデルで表すことができても、そのパラメータ(lambda)は、ユーザビリティの問題ごとに異なる可能性があります。 実際この論文の著者Nielsenは、ヒューリスティック評価とユーザーテストで、深刻度の低い問題よりも深刻な問題が発見される可能性が高いことを発見しています[2]。
特定のインターフェースでは、ほとんどすべてのテストユーザーでいくつかの明白な問題は簡単に発見でき、他の問題は発見がより困難で特別な状況でのみ発生します。ただし、それぞれパラメタ(lambda_1)および(lambda_2)の2つの独立したポアソンプロセスを追加すると、パラメタ(lambda_1+lambda_2)に従うポアソンモデルが生成されるため、評価全体は単一のポアソン分布でモデル化できます。
2.2 データへのフィッティング
ポアソンモデルは、さまざまなユーザビリティの問題の検出が互いに独立していることを要請します。これを前提とすると、(i)人の評価者または被験者が少なくとも1回発見したユーザビリティ問題の数({rm Found}(i))は、そのリサーチにおける全問題数を(N)として以下のように表されます。
$$
begin{eqnarray}
{rm Found}(i)=N(1-(1-lambda)^i)tag{1}
end{eqnarray}
$$
パラメタ(lambda)は、ある評価者が平均的にユーザビリティ問題を見つける確率です。 Table 1は、このモデルを最小二乗法を用いてデータに当てはめた結果を示しており、決定係数も良好であることが分かります。(1-lambda)は、あるユーザビリティの問題が発見されておらず、続くもう1人のテストでも見つけられないままになる可能性です。 したがって(lambda)は、まだ発見されていない場合に、もう1人の評価者が問題を発見する可能性を示しています。Table1からわかるように、この値は単一の評価者による調査を実行したときに検出された問題の割合(Problems found by one evaluation)に近い値であり、やや(lambda)が下回っていることが分かります。同様にTable1は、モデルがのユーザビリティ問題の総数(N)をわずかに過小評価していることを示しています。したがってモデルを実際のリサーチに応用する際は、プロダクトごとの問題の総数を正確に予測するのではなく、検出される残りの問題の数の推定にのみ参考情報として用いることが望ましいです。
以下に、今回のケーススタディで予測されたモデル曲線とデータを重ねたものを示します。ユーザビリティ問題の総数(N)は正規化されています。
Nielsen, et al (1993). Figure.1
横軸は評価者の数であり、発見された問題の数は規模を大きくしても指数分布的に収束していることがわかります。このモデルの有効性は、調査において初めの2人さえインタビューすれば、おおよそ今後必要なインタビュー数や総問題数(N)について当たりが付けられるという点です。またその標準誤差は、インタビューを進めるうちに絞られていくことになるため、従来の事後的な分析ではなく、調査と評価を計画的に調査を進めることができるようになります。
また何より重要な示唆は、ユーザビリティ問題を解決するためのインタビューは、従来感覚的に踏襲されてきた通り大規模調査とする必要はないということです。Figure.1を見れば、6,7人へのインタビューで平均的に課題の75%までが把握されていることがわかります。もちろん状況にはよりますが、複雑なユーザビリティの問題を把握する際に、求められるインタビューの数はごく小規模で済むことがわかりました。
まとめ
プロダクトの開発で用いられるユーザビリティテスト・ヒューリスティック評価を通して、課題の特定に必要なインタビューの数について説明しました。その中でポアソンモデルを用いて数理的なモデルに落とし込み、調査と評価が同期した新しいリサーチについての可能性に触れました。今後は、SEEDATA内で行っているトライブレポートについても同じモデル化を行い、インサイトを十分に発見するために妥当なインタビュー数などを発信していきたいと思います。
参考文献
[1]J.Nielsen, T. K. Landauer, “A Mathematical Model of the Finding of Usability Problems”, Computer Science,CHI ’93,(1993).
[2] Nielsen, J, “Finding usability problems through heuristic evaluation.” Proc. ACM CHI’92 , 373–380. (1992).