Microsoftのコアコンピタンス
開発のコアコンピタンスとしてのユーザビリティ
−実用的で使いやすく、魅力的にー
ソフトウェア的視点：
実際のところ、すべてのソフトウェア プロジェクトに UX デザイナを参加させるのは困難です。つまり、ソフトウェアの開発に携わるすべてのチームが
UX に注力することの重要性を認識していても、専門知識を身に付けた十分な人材が揃っておらず、今後も確保できる見込みが少ないということです。だからこそ、何でも開発者にやらせようとする今日の現実があるのです。昔の開発者なら、これを特に問題だとは思わないでしょう。
開発者は賢明です。良い物を作ろうと考え、ほとんどの開発者が学習を怠らず、自分の能力と製品の質を高めるべく努力を続けています。私が思うに、UX
への注力や、実用的で、使いやすく、魅力的な製品の開発作業への注力は、開発者の継続的な自己研鑽のかなめです。ユーザビリティについては Charlie
が説明してくれたので、長々と続けるつもりはありません。私は、上司の Dr. Komischke がよく引き合いに出す International
Standards Organization (ISO) の定義を紹介したいと思います。
ユーザビリティとは、"特定のユーザー
グループが特定のタスク群を特定の環境で遂行するときの、効果、効率性、満足度" です。
実際、これはかなり幅の広い定義であり、多くの人々が最近 "ユーザー
エクスペリエンス" と呼んでいるものを内包しているように思えます。UX コミュニティも成熟してきており、UX
プロフェッショナルの担当業務とその呼び名について、数々の議論が行われているようです。この分野が成熟し、定義が明確になるにつれ、ユーザビリティも洗練されてきています。私は、Dr.
Larry Constantine がこの内容について語るときに使う "ユーザー パフォーマンスのためのデザイン" という表現が気に入っています。
ユーザビリティを高めるには、ユーザーがソフトウェアで何らかの作業を遂行する必要があるときに妨げとなる障壁やエラーを最小限に抑え、取り除く必要があります。さいわいなことに、エラーが命取りになる軍事、航空、医療などの分野のおかげで、ユーザビリティの領域には多くの科学的知識が蓄えられています。これはおそらく、UX
の中でも最も研究の進んでいる領域です。これらの研究から得られた豊富な知識を基に、ソフトウェアの構築方法や、構築する製品のユーザビリティをより適切に確保するうえで役立つ評価手法を学ぶことができます。（Ambrose Little）
実用性：
実用性の確保は簡単です。既に手に入れているからです。実用性は機能とかかわりがありますが、実用的なソフトウェアと機能するソフトウェアはイコールではありません。ソフトウェアが完全に機能し、バグもなく、仕様どおりにデザインされていても、対象のユーザーにとってまったく便利ではないという可能性もあります。要件の収集と仕様
(および仕様どおりの構築) を重視する考え方から、ソフトウェアの対象ユーザーが何を実現したいのか
(ユーザーにはどのような目的があり、どのような方法でそれを遂行するのか) を把握することを重視する考え方に転換する必要があります。
この領域は、ソフトウェアに対するユーザー中心のアプローチである UX
アプローチとアジャイルが最も重なり合う領域だと思います。アジャイル開発では、関係者から定期的に情報を得ることが推奨されます。UX
アプローチはもっと直接的な場合があり、(理想的には)
ユーザーから定期的にフィードバックをもらいます。こうすることで、正しい道をさらに先まで進むことができるのです。このアプローチを採用した場合、対象ユーザーとその目的をより明確に理解するために、前もって特定の作業を行う必要があります。対象ユーザーがソフトウェアに望む機能をたずねるだけでは不十分です。何を行っているかをたずね、可能であれば実際に観察します。ユーザーの動機
(何がユーザーを動かし、行っていることのどんなところが好きで、どんなところが気に入らないか、など) を明らかにしてください。私たちはこれをユーザー
リサーチと呼んでいます。リサーチの手法には、ユーザーへのインタビュー、アンケート、エスノグラフィ
(人々をその居住地で観察し、データを収集、凝縮して、ペルソナなどの便利なツールに作り替える科学的手法) などがあります。
この側面と、UX
への取り組みがもたらす知識と手法には、ソフトウェアの質を高めるうえで、認められている以上の効果があります。ほとんどの人が UX
について考えるとき、ユーザビリティや魅力について考える傾向にありますが、実用性が低ければ、残りの要素が優れていても意味はありません。これまでに構築された中で最も機能が豊富で、使いやすく、見た目の洗練されたソフトウェアであっても、ユーザーがやりたいことをスムーズにできなければ、無用の長物にすぎません。ユーザーがやりたいことと、遂行する必要のあることに注目し、ソフトウェアをそのパズルにどうはめ込むことができるかを解き明かす取り組みからは、思いもよらない見識を得ることができます。この見識は実用的なソフトウェアの開発に役立ち、真に必要とされるソフトウェアを生み出すことにもつながるでしょう。
魅力：
見た目の美しさのことです。私たち人間には見た目の美しさを理解する力が生まれつき備わっているため、見た目の洗練された製品は確かによく売れます。一般の人々に自分のソフトウェアを使用してもらう必要がある場合、UX
のこの側面に投資しようと考えるのは至極当然のことです。しかし、販売の必要がない場合はどうすればよいのでしょうか。使用するユーザーが既に決まっている場合や、ソフトウェアの内部使用が義務付けられている場合はどうなるでしょうか。
近年、人間とコンピュータの対話という領域における研究活動では、ソフトウェアのユーザビリティと実用性の両方を高める手段として、見栄えに対する注目度がますます高まってきています。昨年
9 月、Human Factors and Ergonomics Society の 2008
年年次総会に出席したとき、このトピックに関する論文がいくつか発表されました。まだ研究の初期段階ですが、意義はあります。
見栄えに関しては、内部使用のソフトウェアの場合にも、見過ごすことのできない側面がもう 1
つあります。自分の体験を思い出してください。製品に欠点があっても、さらには会社の全体的な印象が悪くても、見た目が洗練されているだけで許容されることもあります。
さらに、ソフトウェアを使用するのが楽しければ、積極的に使おうという気持ちになります。デザインのお粗末なソフトウェアが与えられた場合、多くの人々は、たとえ使用が義務付けられたソフトウェアであっても使わずに済まそうとするでしょう。仕事に対する満足度を高め、結果的に、従業員をつなぎ留めておくことができます。したがって、内部使用のソフトウェアであっても、見栄えを重視する意義は十分にあります。
ただし、魅力を左右するのは見栄えだけではないことに注意してください。ソフトウェアの魅力は、ユーザビリティや実用性と深く結び付いています。ソフトウェアの見栄えは、せいぜいソフトウェアのこれらの側面を補強し、全体的な魅力を高める要素にすぎません。
開発者にとっての意味：
それでは、こうした要素は開発者にとって何を意味しているのでしょうか。基本的に私は、開発者はアジャイル、ドメイン駆動設計、テスト駆動開発など、全体的な効果を高めるアプローチや手法と同じように、UX、ユーザビリティ、実用性、魅力などの要素を取り入れ、学ぶことができる
(そしてその必要がある) と考えています。UX 開発のベスト
プラクティスを取り入れるメリットは、単に、環境を問わずより効果的にソフトウェアを構築できるようになるという点です。ソフトウェア開発者にとって、ユーザビリティは重要な問題です。
１・２