画面サイズと生産性
大きい画面の利点についてのテストには、2 つの間違いがあった。現実的なタスクでテストしていなかったことと、現実的な利用方法でテストしていなかったことだ。生産性は、労働環境のユーザビリティを語る上で重要な項目になるが、それを計測する場合は、注意深く行わなければいけない。
高い解像度にあわせてウェブページをデザインすることについてのコラムで、Apple が出した大きな画面が生産性に与える影響についてのレポートについて言及した。私は Apple の方法論が間違っていたと思ったので、あまり詳しくは書かなかったが、その後かなりの注目が集まったため、補足しておくことにする。
たとえばApple が行ったテストについての記事は、「 Excel の表でのカット・アンド・ペーストが、生産性を 51.31 ％伸ばした。大きな画面では 20.7 秒かかったのに対し、小さな画面では 42.6 秒かかった。」と書いている。
まず、タスクにかかった時間を 42.6 秒から 20.7 秒に短縮した場合、生産性の成長は 105 ％であって、51 ％ではない。生産性は、従業員が 1 時間に処理できる仕事量で計測する。小さい画面で 42.6 秒かかったということは、ユーザが 1 時間で 85 回、カット・アンド・ペーストできることを意味し、大きな画面で 20.7 秒かかったということは、1 時間で 174 回、同じことができるということを示す。言い方を変えれば、ユーザの働きから得られた成果は、大きな画面を使うことによって 85 から 174 に伸びたということになり、コピー・アンド・ペーストの回数が 105 ％伸びたことになる。
（考え方としては、General Motors が工場の改良を行い、1 時間毎の生産台数を以前の 82 台から、174 台に伸ばしたのと同じだ。この場合も、同じ従業員数によって、倍以上の成果をあげることになるため、生産性は 105 ％伸びたと言うことになる。）
しかし、ここでは正しい数字が何であったかなど問題ではないのだ。なぜなら、テスト自体が的はずれだからだ。計測テストは正しく行うのが困難で、このテストは間違いを犯しすぎていて、計測値には何の意味もないのだ。
操作 対 タスク
Apple のテストは、計測する労働のレベルを間違えている。表のセルをコピー・アンド・ペーストすることは、低レベルでの操作であって、タスクではない。複数の操作を組み合わせて実現する、もっと現実的で意味のある生産性を、もっと高いレベルで計測しなくてはいけないのだ。
たとえば私が最近行ったタスクは、セミナーを 1 日追加すると、カンファレンスの予算がどう変わるかをみるために、それを表の上に反映させることだった。そのようなタスクは、以前から予定されていたセミナーの 1 日にかかる経費が記入されているセルをみつけ、それをコピーし、新しく追加したセミナーの日付のセルにそれをペーストして、再計算を行わせて、その差額をみるという操作が含まれている可能性は高い。
この場合で本当の生産性は、ユーザが新しい予算をどれだけ速く導き出せるかになる。大きな画面は、このタスクでコピー・アンド・ペースト以外の操作も、楽にしてくれる。たとえば、大きな予算表の中で、全ての項目を一度に見渡すことができれば、突出した項目を探し出すのにかかる時間は短縮される。前と後の予算を両方とも横に並べて見比べることができれば、比較にかかる時間も短縮される。私は大きな画面のほうがよいということについては、全く異論がない。ただ Apple がその度合いを計測するために行ったテストが、信頼できるものではないということを、いっているのだ。
アプリケーションのデザインに置いて、操作とタスクは、明確に分けることが重要だ。なぜなら個別の操作をこなすよりも、タスクをこなすためにユーザ・インターフェイスを最適化するほうが、目的だからだ。例として、Judy Olson と Erik Nilsen が書いた、大きな表のための 2 つのインターフェイスを比較した、傑作といえるレポートをみてみよう。1 つ目のインターフェイスには、表を操作するための沢山の機能があり、各機能は状況によってタスクにかかる時間を短縮できるようになっていた。2 つ目のインターフェイスには、これら特定状況に最適化された機能がなく、1 つ目のインターフェイスの各機能が想定しているような特定状況では、操作自体にかかる時間は長くなるようになっていた。
どちらのデザインのほうが、タスクを速くこなせただろうか。テストが出した答えは、機能が少ないほうだった。機能が少ないデザインでは、操作毎に何をするか考えるために 2.9 秒費やした。それに対して機能が多いデザインでは、操作毎に 4.6 秒費やした。どの機能を使うかという選択肢が多いと、判断を行うのに要する時間が長くなるのだ。豊富な機能の中から選び出すために余計に費やした 1.7 秒が、その豊富な機能によって節約できた時間を上回ってしまったのだ。
反復作業 対 現実的な利用
Apple のテストが間違えている 2 つ目の点は、反復作業を正確にこなすよう訓練された（つまり、間違いを起こさない）ユーザを使っていることだ。もちろん現実では、ほとんどの人がこのようなコンピュータの使い方をしない。
表の同じセルを、台本通りに何度も繰り返してコピー・アンド・ペーストするようなことはない。普通は目的を達成するために、使う必要のありそうなコンピュータの機能を、あちらこちらと探して使うのが普通だ。その最中、多くの時間を（前述したように）判断に費やす。それと同時に、残念ながら間違いを犯し、その間違いから復帰するのにも時間を費やす。
反復作業の最適化は、ユーザビリティの分野の中で扱われるべき問題ではあるものの、その必要性は低い。
ウェブでは滅多に反復作業は発生しない。なぜならユーザは、いつも新しいページに遭遇し、選択肢を選ぶために考え、そこに出ているコンテンツを理解するためにほとんどの時間を費やしているからだ。これが、ほとんどのウェブサイトがドラッグ・アンド・ドロップといった機能を捨て、全てのサイトで共通して使われている最も簡単なインタラクション技術に集中すべき理由だ。ユーザが慣れ親しんだ方法でサイトが機能すれば、ユーザはコンテンツに集中できる。
新しい機能は、特定の操作を素早くこなすことを可能にするかもしれない。だが一般的にそれによって節約できる時間は、その代償よりも小さい。ユーザはその機能によって時間を節約できたと、1、2 回は感じるかもしれないが、その機能自体を理解するために、さらに膨大な時間を必要としてしまう。低レベルでのインタラクションの能率をよくするための新機能を実装するかいがあるのは、ユーザたちがその特定操作をサイト内で何度も繰り返し行うような場合だけだ。
アプリケーションの中でも反復作業は希だ。なぜなら、最近のオフィス労働者は、一般的に複数のタスクを抱え、複数の画面を行き来するからだ。私たちがこれまでにみてきた中で、反復作業といえるのは、コールセンターなどで、数少ないタスクを繰り返し行っているような場所だけだ。
ほとんどの場合は、インターフェイスを考えながら使わなければいけないユーザたちによる、断続的な利用を前提にデザインするのがよい。
現実的な生産性の例
以下が生産性の向上率を測る時のルールだ。
- テストユーザを選ぶ時に、幅広い層のユーザを選ぶ。（エキスパートだけではダメだ。）
- ユーザに業務の中で行いそうなタスクを行わせる。（低レベルの操作だけではダメだ。）
- どのようにタスクをこなすか教えてはいけない。実際どのようにしてこなすかを、観察する必要がある。
私のコラムを毎回読んでいる読者たちならば、これらはユーザビリティを実践する上での基本ルールだということが判るだろう。
不幸にも信頼できるテストの内、画面サイズによる生産性の向上率を計測したものは、私の知る限り最近のものでも 640 × 480 が大画面と呼ばれていた頃のものだ。そのためここでは、画面サイズではないものの、生産性の向上を計測した別のテストを紹介しよう。
イントラネットのユーザビリティ・テストでは、従業員が毎日行っているような数々の業務をどれだけ早くこなせるか、沢山の企業のイントラネットを使ってテストした。タスクの内の 1 つは、特定部署またはグループの部長を捜すことだった。ベスト 25 ％（つまりはユーザビリティの評価上位 1/4 ）のイントラネットの従業員たちは、このタスクを平均 1 分 37 秒でこなした。それに対し、ワースト 25 ％のイントラネットのユーザたちは、同じタスクで平均 3 分 59 秒かかった。
ユーザがどれだけ早く特定のページまで辿り着けたか、またはどれだけ早く検索エンジンに名前を入力できたかを、計測していないことに注目して欲しい。イントラネットでどのようなインタラクション戦略を立てるかは、ユーザ次第だ。ここで問題となったのは、現実世界であり得るタスク、つまりは特定の部長をみつけるのに、どれだけの時間かかったかだ。ユーザが実際に行う可能性のある高レベル・タスクではなく、システムの特定機能をテストしてしまうというのは、ユーザビリティの分野に入って間もない初心者が陥りやすい典型的な間違いだ。機能は、タスクをこなすための手助けだ。機能自体のユーザビリティが高くても、それが現実的な目的を達成する上で機能しなければ、意味がないのだ。
改善の計算
よいイントラネットと、悪いイントラネットの性能の違いが判ったところで、生産性への影響を計算できる。部長を探すタスクの場合、たとえばこのタスクを従業員が 1 週間に 1 回、または 1 年で 50 回行うとしよう。それを前提にすると、よいイントラネットを使っている従業員たちが 1 年間でこのタスクに時間を費やすのは 1.3 時間になり、悪いイントラネットを使っている従業員たちの場合は、3.3 時間になる。
時間を金額に変換するために、従業員の平均手取り報酬は 4 万ドルという前提にして、企業が負うオーバーヘッドは、それに 50 ％上乗せしたものとしよう。そうすると、従業員 1 人あたりの経費は、1 時間 30.77 ドルということになる。その結果、様々な部署の部長を探す従業員にかかる経費は、ユーザビリティのよいイントラネットで年間 41 ドル、ユーザビリティの悪いイントラネットで年間 102 ドルということになる。
この例でいえばワースト 25 ％のイントラネットは、イントラネットを改善してトップ 25 ％のユーザビリティを実現させれば、生産性を 149 ％伸ばすことができる。これはとてもよいように見える。しかし、それによる経費削減は、従業員 1 人あたり 61 ドルにしかならない。そう考えると、やりがいがほとんどないように見える。
もちろんこれが従業員を 1 万人抱える企業であれば、従業員 1 人あたり年間 61 ドルの削減は、年間 61 万ドルの経費削減、または一般的なイントラネットの改修インターバルである 2 から 3 年を視野に入れれば（たとえ割引キャッシュフローで計算したとしても） 100 万ドル以上の節約ができる計算になる。
全生産性の数値化
このデータの本来の使い方は、ここで私が行ったように 1 つのタスクをみるためのものではない。イントラネットの潜在的な生産性向上率を求めたいならば、イントラネットで行われている業務を全て計測して生産性を数値化し、細かいことが書かれたレポートにあるイントラネットのデータと見比べるべきだ。もしデザインし直すことが、ユーザビリティ上どの程度の向上が見込めるか判れば、全体的にどの程度の生産性の向上が期待できるのかも判る。最終的には、目標の生産性と、現在の計測値の差分を計算し、イントラネットの改修によって、節約できる金額を求めることができる。
もちろん、見積もるだけではなく、改修前と後の実際の計測値があるに超したことはないが、それは改修したものを実際に駆動させた後でなければ、求めることができない。そのため、まずは改修前のデザインで生産性を計測し、また同じテストを改修後のデザインに行わなければいけない。いくつかの大企業でこれをやったところを知っているが、最終的に膨大な金額を節約できていることが判った。
生産性はユーザビリティ上最も重要な要素の 1 つなので、デザインが生産性へ与えた影響を、もっと多くの人に計測してもらいたいと思う。だが、意味のある値を得るためには、正しく計測を行うことが必要であり、それは本当のユーザが現実的なタスクを行う様子をテストすることを意味する。
2006 年 10 月 23 日
