2シグマ：
ユーザビリティとシックスシグマ品質保証

経営管理の流行語である「シックスシグマ」は、ユーザビリティに何らかの関係があるのだろうか？答えはイエス。だが、シックスシグマの品質指標とテクニックを適用するには、困難が待ち受けている。現状のウェブユーザビリティは、シックスシグマの品質レベルより10万倍低い。また、ユーザインターフェイスデザイナーが、システマチックな品質工学的手法を導入することはめったにない。製造業の企業がもつ、品質に対する周到なアプローチに学べることは数多い。

『シックスシグマ』の説によれば、すべての工程で、その結果と平均値との差が、標準偏差で6度以内に収まっているものを許容範囲とする。（ギリシア文字のシグマ σ は、統計学で標準偏差を表わす伝統的な記号である。）

以下の表は、最近の私たちの調査プロジェクトにおける品質測定値を示したものだ。テスト対象となったウェブサイトは139サイト。この表には、ユーザの平均成功率が掲載してある。私の定義では、これはユーザが各自のタスクを達成する能力を表している。

イントラネットでのユーザテストの成功率は75％だった。イントラネットの成績は、ウェブサイトよりも高くなる傾向にある。というのも、従業員たちは、自社のイントラネットを使い慣れているからで、ユーザビリティ上の問題があっても、乗り越えてくれる可能性が高いからだ。だが、だからといってイントラネットデザイナーが、ユーザビリティを軽視してよいということにはならない。第一に、仕事をしようとしている従業員に25％もの失敗を経験させるなどということは、許されないことだからだ。第二に、イントラネットのデザイナーは、単なる成功率以上の品質指標を視野に入れなければならない。タスクにかかる時間は特に重要だ。従業員がイントラネットでもたもたすると、その分の給与を会社が払うことになるからだ。

品質レベルの比較

この表からもわかるとおり、一般向けのウェブサイトユーザが、シンプルなインターネットタスクを行う際に、成功を収めるユーザは平均して全体の2/3ということになる。言い換えると、35％のユーザが失敗しているということでもある。これは、シックスシグマ流の品質算定でいえば、1.9シグマの品質レベルになる。イントラネットでは、これが2.2シグマになる。

（統計学的注釈：私は35％の失敗率を低いシグマ水準としたが、シックスシグマの実務家たちは、「シグマシフト」という仮想の値に数字を丸めることがある。私は、ここで彼らの見識を取り入れ、それに準拠することにした。これによって、文献にある数値との比較が可能になる。）

シックスシグマで許容範囲とされるのは、製造工程において100万個あたり3.4の失敗までである。それとは反対に、ウェブでは100万回のインタラクションあたり、35万の失敗が発生している。このふたつの品質レベルの間には、10万倍の開きがある。にも関わらずウェブが機能しているのはなぜだろう？それは、各自にフレキシビリティと失敗にあたっての再挑戦の意志があるからである。（とはいえ、それを行うのは、別のウェブサイトに行った後の話だが）。

ウェブが現状の原始的な機能性から脱却して、より進んだユーザの目的に資するようになってくれれば、というのは多くの人の願いだ。だが、この表からもわかるとおり、タスクが複雑になるほど（アプリケーション、ショッピング）、成功率は低下する。一方で、もっともシンプルなタスク（Eメールニュースレターの申し込み）ほど、成功の確率が高くなる。より先進的なウェブを実現させるには、実質的なユーザビリティ上の進歩が必要なことは明らかだ。

シックスシグマのプロセスは実行可能

出荷する商業用ソフトウェアのコード1000行ごとに、プログラマは6つのバグを残すのが通例だ。これは4シグマに相当する。ソフトウェア工学は、シグマレベルでいえば、ウェブユーザビリティと製造業の中間に位置する。

ソフトウェアの品質はお世辞にもいいとはいえない。だが、ユーザビリティの品質は（2シグマのレベルで苦戦しているわけで）目をおおうばかりだ。私たちは、シックスシグマの方法論をいくつか応用して、ウェブの品質を追及する一助とするべきだろう。

シックスシグマの品質工学は、DMAICという5ステップのプロセスに依拠している。これはぞれぞれ、定義（define）、計測（measure）、分析（analyze）、改善（improve）、制御（control）に照応している。これら各ステップを導入することで、ウェブプロジェクトは、より優れた、よりシステマチックな品質を獲得することができるだろう。

• 定義。最初のステップとして、顧客にとってもっとも価値のあるユーザビリティ属性とは何かを特定する。ユーザが実行するタスクの中で、もっともやりやすくしておかねばならない第一のタスクは何か？決定的な目的を達成するための時間は、どれくらい短縮しなければならないか？
• 測定。私は、つねづね定性的なユーザビリティ調査の重要性を説いている。それは、ユーザビリティの主たる目的が、デザインの原動力となることだからである。だが、正式な品質保証としては、上項で定義したユーザビリティ指標に関して、各自のデザインが、どれくらいそれを達成できたかを示すきっちりした数字を出すために、定量調査を行わねばならない。
• 分析。実測値と、あるべき品質レベルの間には、乖離があるのが普通だろう。テスト結果を分析して、その原因を洗い出そう。これによって、特定のデザイン変更を余儀なくされるだけでなく、そもそも、どうしてこういったユーザビリティ上の欠陥がデザインに入り込んだのかを洗い出す一助にもなるはずだ。
• 改善。デザインの修正。欠点を取り除くステップについては言うまでもないが、同時に、デザインプロセスの改善も行うべきである。これによって、次回以降、何かをデザインする際に混入する欠陥をより低く抑えることができる。
• 制御。気持ちをゆるめないように。引き続き、より進んだタスクのサポートを導入する過程においても、ユーザ体験の品質レベルを監視し続け、ユーザビリティに関するユーザの期待値を、しだいに高めるようにしなければならない。デザイン手法を改善し、全体の品質に寄与する各チームメンバーのアカウンタビリティを維持すること。

最後の項目が、もっとも重要なことかもしれない。他の数多くの分野から得られる教訓のうちでもっとも重要なのは、継続的な品質の向上こそが、本物の優秀性へ通じる道だということだ。これは幸運なチャンスとも言える。今のところ、ウェブユーザビリティの品質は許容範囲にはるかに及ばず、それはとうてい一度で取り戻せるレベルではない。継続的な改善だけが、私たちに残された最後の道なのだ。

2003年11月24日