翻訳：アジャイルプロセスへのUCDの適用
PDF版はこちら
UCDと開発手法の統合についての論文を訳す。
上の気持ち悪い生物は、開発者は「完璧なユーザー」を思い描くということを皮肉った絵。
アジャイルプロセスへのUCDの適用：対話
William Hudson
Syntagm Ltd, Design for Usability
Abingdon, UK
william.hudson@syntagm…
エクストリーム・プログラミングや他のアジャイルプロセスは、無秩序と厳格すぎる手法（時に「文書化による死」といわれる）との間に妥協点をもたらす。多くのチームにとって、アジャイルな取り組みの特に魅力的な面は、どれだけ開発が進行していようとも変更に適応しようとする勇気だ。しかし、この柔軟性こそがユーザーインターフェースデザインの問題とそれに伴うユーザビリティ上の問題を引き起こす。
ユーザーインターフェースデザインにユーザー中心の取り組みを適用することでこれらの問題に取り組むことができる。ここからのユーザー中心デザイン（UCD、ユーザーセンタードデザイン）コンサルタントとエクストリーム・プログラミング（XP）チームリーダーによる模擬会話によってこのことを説明したい。
XP: 私たちのチームはXPに移行したときから開発プロセスの改善にかなり興奮しているが、ユーザーはそれほど熱狂的ではない。ユーザーの口から最初に出る言葉は「使いやすい」ではなく、私たちのサポートデスクは大忙しだ。
UCD: アジャイルプロセスはチームにとってのよりよい物を開発するというところに焦点があり、実のところユーザーに提供するものは多くない。図１を見よ。
図１ OO、アジャイルとUIデザインの関係
OO(訳注：Object-Oriented、オブジェクト指向)デザインは隠されたシステムのアーキテクチャと関わる。そのアーキテクチャは要求機能を実現するためのオブジェクトとその通信に着目している。これはとても内観的な方法で、ユースケース*1は特効薬だとされている。しかし不幸なことに、大抵は混乱を引き起こす。OOデザイン自体はプロジェクトがどのように遂行されるべきか、あるいはどんな方法で努力への対価を最大限にするかは示さない。
アジャイルプロセスはOOデザインからのベストプラクティスをいくつか採用している。だがユースケースをユーザーストーリーに置き換え、多くのチームと開発者を何十年と悩ませてきたプロジェクトマネジメントの問題に取り組んでいる。しかし、本当のユーザーの要求を理解しようという努力はいまだになされず、ユーザビリティテストを通じてソフトウェアを評価するということにも触れられていない。
ユーザーまたは人間中心デザイン*3と呼ばれる取り組みによって行う。それは主に観察とインタビューとからなる。
その他の問題として、代表のユーザー（ユーザーの代表者）がしばしば間違った理由によって選定されるということがある。彼らはおそらくこのようだろう。
彼らは決して典型的なユーザーではありえない。たとえもしそうだったとしても、わずか数週間でそうではなくなる。その時までに彼らは、
私たちがユーザー中心デザインでやろうとしていることは十分な使用文脈*4を必ず理解しようとすることだ。ユーザーは誰か、背景、動機、責任、役割、仕事、それぞれの頻度と重要性、加えて彼らが働いている物理的・社会的な環境といった。
XP: 私たちの参加しているほとんどのプロジェクトにとって、それはきっとやり過ぎだ。
UCD: 問題のリストは確かにとても長いが、当然ながらほとんどのプロジェクトにとっては関連があるものはごくわずかだ。私たちが最初にやろうとしていることの一つはどの使用文脈が重要かを理解することだ。例えば、ある場合では使用の頻度が全体としてのシステムにとっても個々の機能にとっても非常に重要であったりする。他方、ユーザーが多くの背景騒音と頻繁な中断のあるコールセンターのような緊張を要する環境で働いているようなこともあるだろう。
XP: それでは、私たちの開発しているものを変えるのはどのようなものなのだ？
UCD: 頻繁な中断の例を挙げよう。いくつかの潜在的な解決策がある。
XP: しかしあなたは主にインターフェースの変更について話しているのではないか？どうして私たちはこれを後になって簡単に解決することができないのだ？
UCD: ユーザーインターフェースがどれほどシステムのアーキテクチャに影響を及ぼしえるかを、ほとんどの開発チームが認識していないことが問題だ。それは単純なフォームを埋めるようなアプリケーションへの小さな影響から、複雑で高度にインタラクティブなシステムへの大きな影響まで様々だ。ユーザーインターフェースがとても複雑になりつつあるかユーザーが次に何をしなければならないかがわからなくなった、ということをチームが認識し始める、ということは開発プロセスでよく起こる。（この事実は通常のユーザビリティテストをすれば極めて早く見つかるだろうが、実際のユーザーが開発プロセスに参加していないときは、製品の公開まで遅くなるだろう。）これは背後にあるシステムのアーキテクチャへの大きな変更が、ユーザーインターフェースにも同じく影響を及ぼすということだ。ユーザーインターフェースの全体構造と、アプリケーションがそれ自体をユーザーに提示する有り様とをデザインすることは、システムのアーキテクチャが決定される前になされなければならない。
さっきの例に戻ろう。十分なフィードバックを与えることは、ユーザーインターフェースの容易な変更かもしれないし、そうでないかもしれない。後の例はシステムのアーキテクチャに依存している。不完全なデータを保存させることと複合的な更新をさせることは、ほぼ間違いなくアーキテクチャ上の大きな変更が必要となるだろう。
これらの筋書きの中でデータの整合性を保つことは、それを支える堅牢なアーキテクチャ無しでは悪夢だろう。これらはあなたが開発の終盤になって取り組みたがるような問題ではないだろう。
XP: では何が必要なんだ？私たちは早期のデザインを削減するためにアジャイルプロセスを利用しているのだ。今やあなたたちは、私たちにはもっとデザインが必要だと提案している。
UCD: ソフトウェアとユーザーインターフェースの両者は、それらの度重なる変更によってデザインが浸食されたことの影響を受ける。ソフトウェアについて、特に最小限のデザインだけのアジャイルプロセスでは作業を堅固な基盤の上で続行できるように、システムを構成するオブジェクトを再構築しなければならない時がくる。これはリファクタリングと呼ばれる。開発チーム外の誰一人として大きな変化の影響を受けないから、これは功を奏する。いずれにしても、オブジェクトのグループに線を引くことと、そのグループ内で明白に外的な変更を生じさせないように再構築することは通例可能だ。
ユーザーインターフェースのためのリファクタリングは広範囲な公開前の段階においては可能であるが、その後はとても困難になる。ユーザーは一貫性を求める。公開された製品のメニュー項目の名前や位置を変更することは非常に高くつくだろう。
主な有形の副作用としては、このようなものがある。
無形の影響はこれらを含む。
もちろん、これらの副作用は、変更の種類と量、頻度によって変化するが、一般的にユーザーインターフェースの変更は注意して管理する必要がある。
XP: しかし今のところ私たちはチームにユーザーインターフェースをおざなりに修正させている。私はアジャイルプロセスにおいてどのようにこれを管理できるのかがわからない。
UCD: いくつもの構成要素が必要だ。
使用文脈についてはすでに述べた。これらを理解すれば、すぐにいくつかのペルソナ*5を確認でき、次にユーザーストーリーから概念モデルを作成できる。ペルソナはシステムに対するユーザーの主要な種類を確認するとても強力な方法で、開発チームが彼らの要求と予想を理解できるようにペルソナを描写する。私たちはみな、他者の観点から物事を見ることが難しい。ペルソナはバランスを取り戻す一つの方法だ。
ここに実際の例がある。私は最近、官庁のwebサイトのユーザビリティテストを行った（当惑を避けるため、どの官庁かは明かさない）。そのサイトは従業員と雇用者の双方に雇用に関する法律と関連する文書の情報を提供することを意図されていた。テストの被験者の一人は大工だった。彼をロブと呼ぼう。ロブは言葉を遠回しに言うような人物ではなかった。サイトのデザイナーは、大部分の人は困らない専門用語を使っていると考えていたのだろうが、それらは公務員の使い方に大きく左右され、関係する部門で使われるものだ。フォトライブラリの写真とユーザビリティセッションからの抄録が付加された、ロブのための架空のペルソナを参照していれば、その事態ははただちに明らかになっただろう。ロブは専門用語を好ましく思わない。彼の意見の中には上品な人々の間では繰り返して言えないものもあったが、デザインを議論している最中に発せられる、「ロブはそれを理解するだろうか？」という言葉の効力を想像するのは難しくないだろう。
ペルソナはユーザーの主要なグループを表現するために利用されるが、ユーザープロフィールよりもずっと実体的で付き合いやすい方法だ。大方のプロジェクトはごく少数のペルソナしか扱っていない。
XP: ペルソナは少し扱いにくいと思う。それらは本当にやってみる価値があるのか？
UCD: すでに言ったように、全ては観点の問題だ。もしあなたのチームがユーザーの身になることを厭わない（加えてそれを証明するためのユーザビリティテストを行う）なら、ペルソナに悩まされる必要には迫られないだろう。しかしながら、ほとんどの開発者は結局のところ架空の「完璧なユーザー」のためのアプリケーションを開発することになる。偶然なのだが、これについて過去に描いた絵を持っている。図２を見よ。
図２ 架空の「完璧なユーザー」
ユーザーに関して開発者が信じたいことは、このようなことだ。
XP: 分かった。その絵姿は理解したが、さっき言ったことは私を悩ませる。私たちはすでにユーザーストーリーを製作している。それなのになぜユーザーは完成したユーザーインターフェースと相変わらず格闘しなければならないのだ？
UCD: ユースケースと同じように、ユーザーストーリーはユーザーが行いたいこと、役立つことを記述するとされている。ユースケースとユーザーストーリーとの大きな違いは、ユースケースは常にユーザーを扱うとは限らないことだ（それらは恣意的な”アクター”とシステムとの間の相互作用を記述することができる）。その上、ユースケースは全ての起こりうる結果を記述しようとしてしばしばとても複雑になりがちだ。一方で、ユーザーストーリーは短く簡単であるように計画的に保たれる（複雑な状況を記述しなけらばならない時には、より多くのストーリーが作られる）。これらの違いにもかかわらず、ユーザーストーリーはユースケースとの混同を引き起こしてきた多くの同種の問題からあおりを受ける。本当のところを言えば、あなたがユースケースとユーザーストーリーを書くときにはこのようなことを自問する必要があるのだ。
これらの問題のいくつかを解決するには、ほとんどの開発者が経験してきたような方法ではなく、適切に取り組むためには人間とコンピュータとの相互作用の理解を必要とする。しかしながら、開発時間と作業の節約のために専門家を参加させる価値は十分にある。
実装の仕様をどれだけユーザーストーリーに盛り込むべきかという大きな問題も隠れている。もしユーザーストーリーがプロセスの初期に書かれるならば、詳細すぎる記述は邪魔になり、尚早なデザインの決定にもつながる。また詳細すぎる記述が含まれているときには、デザインを簡単にすることが難しい。「木を見て森を見ず」というやつだ。
初期のユーザーストーリーから実装の仕様を除外することのもう一つの理由は、私たちはユーザーの概念モデルをそれらから導きたいからだ。これはユーザーが知っていなければならないもの（実体）とそれらとの関係を表した単純な図だ。例として図３を見よ。
図３ ホテル宿泊の概念モデル
XP: とはいえ、これはUMLのクラスモデルだろう！
UCD: それは正しくもあり、間違ってもいる。これはUMLのクラスモデル記法を利用しているが、クラスを表しているのではなく、アプリケーションがどう実装されるかに関わらず、ユーザーが知っていなければならない概念的な実体を表している。これらの実体の大部分はシステムの実装段階で結局はクラスとなるだろうが、私たちにとっては重要なことではない。私たちは後になって情報を提示する「ビュー」（普通はウィンドウやダイアログ）とユーザーがタスクを遂行するために必要な制御を加える。ところでこの一つめの図はCookとDaniels*6が本質的モデルとして参照したものだが、私はむしろこれを概念と呼びたい。それは私たちのユーザーの概念モデルを表しているからだ。
XP: それは少し単純に割り切りすぎのように見える。
UCD: この段階では、そうだ。しかしいくつかのビューと属性を図４で追加してみる。
ビューはこの段階のモデリングにも利用可能なように二つの異なった形式で加えられている。客室ビューと宿泊客ビューはアイコン形式で表現されている。これは通例はデータベースビューのために使われる、Rational Roseの標準アイコンなので、いささか変わった印象だ。もう一つのものはより明確で仕様の次の段階で必要とされる。ホテル宿泊ビューは”View”ステレオタイプを用いて表現されている。これは私たちに普通のクラス記号の使用と、後に必要な属性と操作とを加えさせる。客室と宿泊客の実体は属性を持つ実体の例だ。これらはユーザーが知っていなければならないものだけであり、ユーザーのゴールを達成するために修正される必要があるということを忘れてはいけない。私たちはそれがどのようにコンピュータの内部で表現されるかということについては気にしない。また、ビューは関連している実体をいつも表示しているわけではない。一例として自動チェックイン機を開発しようとしているときはどうか。そこには、最後の宿泊客は誰かなどといった、私たちがビューに表示したくないかなり多くの詳細があるだろう（しかし、それは支配人のビューには表示されてもよいだろう）。
最後にもう一つ。ホテル宿泊ビューと客室とを結ぶ線には”free rooms”という文が中括弧で囲まれて付加されている。これはUMLでは制約と呼ばれ、ビューは空いている客室だけを表示するように制限されていることを意味する。
XP: 仕様のもう一つの段階について述べたか？
UCD: CookとDanielsは三つのものを提案した。本質（概念と名前を変更した）、仕様、そして実装だ。ユーザーインターフェースの実装モデルは、何が表示されるかということと、少なくともどのように表示するかについて詳しく記述されている必要がある。図５はホテル宿泊ビューだけの例を表している。これはユーザーが知る必要のあるビューの属性と、それらがどのように表示されるかということについての概略を一覧にしている。操作（この場合は”Select room”だけ）はユーザーストーリーかユースケースに対応している。もし必要なら、ユーザーがこのビューとどのようにやりとりするかを詳述するのにUMLの相互作用図を用いることができるだろう。
図５ ホテル宿泊ビューの実装モデル
XP: 今や私たちはビューとそれが包含しなければならないものについて理解した。では、どのような形式で仕様書に記述すればよいのだ？
UCD: ここでペーパープロトタイピング*8が役に立つ。私たちはビューを紙に描いてユーザーと初期のユーザビリティテストを行う。これには高価なユーザビリティラボやビデオ録画装置を必要とせず、プロセスを熟知している人とペーパープロトタイプ、何人かの現実のユーザーとノート（紙でできたもの！）があればよい。デザインに関わったスタッフがこの問題に近すぎるために起用できないときのために、ユーザビリティの専門家があなたのチームにいると理想的だろう。
XP: ユーザビリティの専門家を雇うことは贅沢に思える。
UCD: そうではない。ここに二つの問題がある。一つ目は、人的要因（訳注：human factors）と人間とコンピュータの相互作用やユーザビリティの素養をもつチームメンバーを擁することが重要だということだ。たとえいくつかのユーザビリティに関する作業が自分で可能だとしても、目標となりえる人物が必要だろう。二つ目は、人的要因、人間とコンピュータの相互作用とユーザビリティの経験を有益に利用できる多くの活動があるということだ。それらはプロダクトデザイン、ユーザーインターフェースデザイン、ユーザーガイド、ユーザー補助、ヘルプデスクの教育、開発者の教育などだ。
XP: まだ疑問が一つある。例えば私たちは仕様を実装のレベルまで精密にした概念モデルを考え、ペーパープロトタイプを作製した。後の開発でどのように変更に対処すればよいのだ？
UCD: よろしい、これらは不変というものではなく、注意深く変更される必要があるだけだ。最も重要なことは、変更は人的要因と人間とコンピュータの相互作用やユーザビリティの専門家を擁しているユーザーインターフェースのチームによって検討されなければならないということだ。彼らはどんな変更も以下に反していないことに注意するだろう。
XP: それでは、ライフサイクルを通じて出てくる、無数の新機能についての要求についてはどうすればよいのだ？
UCD: 最初にどんな新機能であってもあなたたちのペルソナ（覚えているだろうか？）のためのものかどうかを確認するべきだ。全てのユーザーを満足させるプロダクトなどあり得ないし、どんな新機能であっても増大する複雑さと低下するユーザビリティという犠牲を伴う。あなたたちが個々の機能追加のことを考えているときには、これは自明ではないかもしれない。しかし何十もの機能をユーザーインターフェースに追加しようとするときにはきっとユーザーを困惑させるだろう。新機能が一人以上のペルソナにとって価値があることを確認できたなら、それがプロダクトの概念モデルをどれだけ変化させるかを検討しないといけない。あなたは新しい高レベルの概念を導入することを何度も望まないだろう。だが一方、ユーザーが事をうまく成し遂げられるような、操作や属性への些細な変更は影響が小さいだろう。
XP: それはもっともらしく思えるが、どうやって始めればよいのだ？
UCD: 新しいプロジェクトのために用いられる方法は、既にその要点をだいたい述べた。
あなたはこれらすべてを自分でやることを厄介に感じて、ユーザー中心デザインコンサルタントに手を貸してもらうことを考えたくなるかもしれない。彼か彼女はそれを順調に開始させ、頻繁な周期をプロジェクトの進行につれて、より少なくさせることができるだろう。ほとんどの活動は終始行われるユーザビリティテストとともにプロジェクトの初期にあることに注意してほしい。
XP: このユーザビリティテストを追加しようとしてから、他のテストの形式に簡易化することはできるか？
UCD: 間接的にであれば可能だ。あなたが注意するべき他の節約はたくさんあるが、ソフトウェアテストとユーザビリティテストは全く別のものだ。ソフトウェアテストはチームが意図する通りにアプリケーションが動作することを確認しようとする。ユーザビリティテストはそれがユーザーが求めている動作をするかどうかということに的を絞る。この差違は時には信じ難いほどだ。
あなたが開発中に注意するべき節約は必要になる再作業の総計だろう。他と比較してアジャイルプロセスでは再作業は高くつかないのかもしれないが、それでも負担がない訳ではない。特に開発の後期で大規模なアーキテクチャ上の変更が必要になったときなどは。
XP: 既存のアプリケーションにはどのように取り組めばよいのだ？
UCD: 初めの一歩は深刻なユーザビリティ上の問題が存在するかどうかと、それらを修正するために何が必要となるかを見つけることだろう。このためには何度かのユーザビリティ評価が必要となるだろう。私はユーザーとのユーザビリティテストに続く最初の専門家によるレビューを必要があれば勧める。それによってレビュアーはアプリケーションの”逆設計された”概念モデルを用意することもできるだろう。これはあなたのデザインしたモデルと比較できる。モデル間の明らかな不合理、加えてユーザビリティ評価によって確認された問題領域はチームが注意を集中する必要がある所だ。さらに、ユーザー中心デザイン専門家はこれらの解決の手助けができるだろう。
アプリケーションが大規模な再作業や置換を必要とするなら、私が述べたほとんどの成果物のために、あなたはそれを新しいプロジェクトとみなすべきだ。ペーパープロトタイプが辛うじて省略できうるただ一つのものだ。ユーザーストーリー形式の使い古されたやり方を採ることはアジャイルな方法に反していると思うかもしれないが、それが後のプロセスを導いていくのだから、それが使用文脈と重要なペルソナによってユーザーの要求を正しく反映していることが重要だ。
ユーザー中心デザインと既存のソフトウェア開発プロセスとの統合に関する文献*9は多くないので、現在のところコンサルタントと親密に作業することはおそらく避けられない。私は遠くない将来にユーザー中心手法が主流のソフトウェア開発に適用され始めることを期待している。使いやすいシステムを提供することのできる私たちの能力はそれにかかっている。
参考文献
Beyer H. & Holtzblatt K. (1998) Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, San Francisco, CA.
Cook S. & Daniels J. (1994) Designing Object Systems: Object-Oriented Modelling with Syntropy. Prentice Hall, New York, NY.
Cooper A. (2003) About Face. John Wiley & Sons Inc, New York, NY.
Fowler M. & Scott K. (2000) UML Distilled: Applying the Standard Object Modelling Language. Addison-Wesley, Reading, MA.
Hudson W. (2001) Towards Unified Models in Object-Oriented and User-Centered Design. In: M.van Harmelen (ed), pp. 313-362. Addison-Wesley, Boston, MA.
[ISO/TC159. Human-centered design processes for interactive systems. ISO 13407:1999. 1999. Geneva, Switzerland, International Organization for Standardization.]
Roberts, Dave, Berry, Dick, Isensee, Scott, and Mullaly, John. 1998. Designing for the User with OVID: Bridging User Interface Design and Software Engineering, Macmillan Technical Publishing.
Snyder C. (2003) Paper Prototyping. Morgan Kaufmann, San Francisco, CA.
*1: ユースケースはシステムとその外部の実体との間の相互作用を記述する。Ivar Jacobsonはこの主題についての最初の論文で外部のアクターをユーザーと呼んだ。”ユーザー”が”アクター”に変化し、これだけが原因ではないが、それからすぐにユースケースは顔をしかめさせるようになった。
*2: ISO標準13407では”人間中心”とされているが、実際にはユーザー中心と人間中心は同じことである。また標準の題名に英国式綴が用いられていることも無視せよ。（訳注：centreの綴り）[ISO/TC159 1999]を参照。
*3: 文脈調査についての充実した議論は[Beyer & Holtzblatt 1998]に見つけられるだろう.
*4: [ISO/TC159 1999] ISO 13407標準に詳細に記述されている。
*5: ペルソナについての長い議論のためには、[Cooper 2003]を参照せよ。
*6: [Cook & Daniels 1994]を参照。Martin Fowlerは[Fowler & Scott 2000]において、これらを”パースペクティブ”としても議論している。彼は”本質”的モデルを”概念”とも呼んでいる。
*7: [Roberts et al. 1998]に基づく。
*8: ペーパープロトタイピングについてのより広範な議論については[Snyder 2003]を参照せよ。
*9: ユーザー中心デザイン、UMLとユースケース主導の手法に関するより詳細な議論については、[Hudson 2001] を参照せよ。
UCDと開発手法の統合についての論文を訳す。
上の気持ち悪い生物は、開発者は「完璧なユーザー」を思い描くということを皮肉った絵。
アジャイルプロセスへのUCDの適用：対話
William Hudson
Syntagm Ltd, Design for Usability
Abingdon, UK
william.hudson@syntagm…
エクストリーム・プログラミングや他のアジャイルプロセスは、無秩序と厳格すぎる手法（時に「文書化による死」といわれる）との間に妥協点をもたらす。多くのチームにとって、アジャイルな取り組みの特に魅力的な面は、どれだけ開発が進行していようとも変更に適応しようとする勇気だ。しかし、この柔軟性こそがユーザーインターフェースデザインの問題とそれに伴うユーザビリティ上の問題を引き起こす。
ユーザーインターフェースデザインにユーザー中心の取り組みを適用することでこれらの問題に取り組むことができる。ここからのユーザー中心デザイン（UCD、ユーザーセンタードデザイン）コンサルタントとエクストリーム・プログラミング（XP）チームリーダーによる模擬会話によってこのことを説明したい。
XP: 私たちのチームはXPに移行したときから開発プロセスの改善にかなり興奮しているが、ユーザーはそれほど熱狂的ではない。ユーザーの口から最初に出る言葉は「使いやすい」ではなく、私たちのサポートデスクは大忙しだ。
UCD: アジャイルプロセスはチームにとってのよりよい物を開発するというところに焦点があり、実のところユーザーに提供するものは多くない。図１を見よ。
図１ OO、アジャイルとUIデザインの関係
OO(訳注：Object-Oriented、オブジェクト指向)デザインは隠されたシステムのアーキテクチャと関わる。そのアーキテクチャは要求機能を実現するためのオブジェクトとその通信に着目している。これはとても内観的な方法で、ユースケース*1は特効薬だとされている。しかし不幸なことに、大抵は混乱を引き起こす。OOデザイン自体はプロジェクトがどのように遂行されるべきか、あるいはどんな方法で努力への対価を最大限にするかは示さない。
アジャイルプロセスはOOデザインからのベストプラクティスをいくつか採用している。だがユースケースをユーザーストーリーに置き換え、多くのチームと開発者を何十年と悩ませてきたプロジェクトマネジメントの問題に取り組んでいる。しかし、本当のユーザーの要求を理解しようという努力はいまだになされず、ユーザビリティテストを通じてソフトウェアを評価するということにも触れられていない。
ユーザーまたは人間中心デザイン*3と呼ばれる取り組みによって行う。それは主に観察とインタビューとからなる。
その他の問題として、代表のユーザー（ユーザーの代表者）がしばしば間違った理由によって選定されるということがある。彼らはおそらくこのようだろう。
- 分野の専門家
- 同僚と親しいか親しくないかのどちらか（彼らを選定する方法による）
- マネジメントと親しいか親しくないかのどちらか（彼らを選定する方法による）
- 最も技術力がある人間
- 開発チームの一員となるのに地理的に適当なところにいた
彼らは決して典型的なユーザーではありえない。たとえもしそうだったとしても、わずか数週間でそうではなくなる。その時までに彼らは、
- プロジェクトの技術面に精通しすぎる
- 決定した解決策に偏った持続的興味を持つ
- ミッションクリティカルなアプリケーションの最新リリースを誰の助けも借りずに理解するために、一人で離れた場所に座っているという状況がどんなものかを忘れてしまっている。
私たちがユーザー中心デザインでやろうとしていることは十分な使用文脈*4を必ず理解しようとすることだ。ユーザーは誰か、背景、動機、責任、役割、仕事、それぞれの頻度と重要性、加えて彼らが働いている物理的・社会的な環境といった。
XP: 私たちの参加しているほとんどのプロジェクトにとって、それはきっとやり過ぎだ。
UCD: 問題のリストは確かにとても長いが、当然ながらほとんどのプロジェクトにとっては関連があるものはごくわずかだ。私たちが最初にやろうとしていることの一つはどの使用文脈が重要かを理解することだ。例えば、ある場合では使用の頻度が全体としてのシステムにとっても個々の機能にとっても非常に重要であったりする。他方、ユーザーが多くの背景騒音と頻繁な中断のあるコールセンターのような緊張を要する環境で働いているようなこともあるだろう。
XP: それでは、私たちの開発しているものを変えるのはどのようなものなのだ？
UCD: 頻繁な中断の例を挙げよう。いくつかの潜在的な解決策がある。
- 中断した箇所に復帰できるように、ユーザーが十分なフィードバックを得られることを確実にする
- ユーザーが更新を放棄しなければならないことのないよう、不完全な情報が保存されることを許可する
- 複合的な更新が同時に処理できるようにユーザーインターフェースをデザインする
XP: しかしあなたは主にインターフェースの変更について話しているのではないか？どうして私たちはこれを後になって簡単に解決することができないのだ？
UCD: ユーザーインターフェースがどれほどシステムのアーキテクチャに影響を及ぼしえるかを、ほとんどの開発チームが認識していないことが問題だ。それは単純なフォームを埋めるようなアプリケーションへの小さな影響から、複雑で高度にインタラクティブなシステムへの大きな影響まで様々だ。ユーザーインターフェースがとても複雑になりつつあるかユーザーが次に何をしなければならないかがわからなくなった、ということをチームが認識し始める、ということは開発プロセスでよく起こる。（この事実は通常のユーザビリティテストをすれば極めて早く見つかるだろうが、実際のユーザーが開発プロセスに参加していないときは、製品の公開まで遅くなるだろう。）これは背後にあるシステムのアーキテクチャへの大きな変更が、ユーザーインターフェースにも同じく影響を及ぼすということだ。ユーザーインターフェースの全体構造と、アプリケーションがそれ自体をユーザーに提示する有り様とをデザインすることは、システムのアーキテクチャが決定される前になされなければならない。
さっきの例に戻ろう。十分なフィードバックを与えることは、ユーザーインターフェースの容易な変更かもしれないし、そうでないかもしれない。後の例はシステムのアーキテクチャに依存している。不完全なデータを保存させることと複合的な更新をさせることは、ほぼ間違いなくアーキテクチャ上の大きな変更が必要となるだろう。
- 背後のシステムは不完全なデータを受容することができなければならないだろう
- 影響のあったレコードはユーザーの注意を喚起する必要があるだろう
これらの筋書きの中でデータの整合性を保つことは、それを支える堅牢なアーキテクチャ無しでは悪夢だろう。これらはあなたが開発の終盤になって取り組みたがるような問題ではないだろう。
XP: では何が必要なんだ？私たちは早期のデザインを削減するためにアジャイルプロセスを利用しているのだ。今やあなたたちは、私たちにはもっとデザインが必要だと提案している。
UCD: ソフトウェアとユーザーインターフェースの両者は、それらの度重なる変更によってデザインが浸食されたことの影響を受ける。ソフトウェアについて、特に最小限のデザインだけのアジャイルプロセスでは作業を堅固な基盤の上で続行できるように、システムを構成するオブジェクトを再構築しなければならない時がくる。これはリファクタリングと呼ばれる。開発チーム外の誰一人として大きな変化の影響を受けないから、これは功を奏する。いずれにしても、オブジェクトのグループに線を引くことと、そのグループ内で明白に外的な変更を生じさせないように再構築することは通例可能だ。
ユーザーインターフェースのためのリファクタリングは広範囲な公開前の段階においては可能であるが、その後はとても困難になる。ユーザーは一貫性を求める。公開された製品のメニュー項目の名前や位置を変更することは非常に高くつくだろう。
主な有形の副作用としては、このようなものがある。
- ドキュメントやオンラインヘルプの変更
- 変更された機能をユーザーが発見したり理解するのに浪費する時間
- 結果として生じるエラーの代価、特に外部の顧客が巻き込まれる場合
- サポート窓口への電話の増加
無形の影響はこれらを含む。
- フラストレーションとストレスの増加
- 信頼の喪失と変更への恐怖感
- 無力感、統制の喪失
- 変更への抵抗
- 集団が変更に適応するまでの混乱と非能率
もちろん、これらの副作用は、変更の種類と量、頻度によって変化するが、一般的にユーザーインターフェースの変更は注意して管理する必要がある。
XP: しかし今のところ私たちはチームにユーザーインターフェースをおざなりに修正させている。私はアジャイルプロセスにおいてどのようにこれを管理できるのかがわからない。
UCD: いくつもの構成要素が必要だ。
- 使用文脈
- ペルソナ
- ユーザーストーリー
- 概念モデル
- ペーパープロトタイプ
- ユーザビリティテスト
使用文脈についてはすでに述べた。これらを理解すれば、すぐにいくつかのペルソナ*5を確認でき、次にユーザーストーリーから概念モデルを作成できる。ペルソナはシステムに対するユーザーの主要な種類を確認するとても強力な方法で、開発チームが彼らの要求と予想を理解できるようにペルソナを描写する。私たちはみな、他者の観点から物事を見ることが難しい。ペルソナはバランスを取り戻す一つの方法だ。
ここに実際の例がある。私は最近、官庁のwebサイトのユーザビリティテストを行った（当惑を避けるため、どの官庁かは明かさない）。そのサイトは従業員と雇用者の双方に雇用に関する法律と関連する文書の情報を提供することを意図されていた。テストの被験者の一人は大工だった。彼をロブと呼ぼう。ロブは言葉を遠回しに言うような人物ではなかった。サイトのデザイナーは、大部分の人は困らない専門用語を使っていると考えていたのだろうが、それらは公務員の使い方に大きく左右され、関係する部門で使われるものだ。フォトライブラリの写真とユーザビリティセッションからの抄録が付加された、ロブのための架空のペルソナを参照していれば、その事態ははただちに明らかになっただろう。ロブは専門用語を好ましく思わない。彼の意見の中には上品な人々の間では繰り返して言えないものもあったが、デザインを議論している最中に発せられる、「ロブはそれを理解するだろうか？」という言葉の効力を想像するのは難しくないだろう。
ペルソナはユーザーの主要なグループを表現するために利用されるが、ユーザープロフィールよりもずっと実体的で付き合いやすい方法だ。大方のプロジェクトはごく少数のペルソナしか扱っていない。
XP: ペルソナは少し扱いにくいと思う。それらは本当にやってみる価値があるのか？
UCD: すでに言ったように、全ては観点の問題だ。もしあなたのチームがユーザーの身になることを厭わない（加えてそれを証明するためのユーザビリティテストを行う）なら、ペルソナに悩まされる必要には迫られないだろう。しかしながら、ほとんどの開発者は結局のところ架空の「完璧なユーザー」のためのアプリケーションを開発することになる。偶然なのだが、これについて過去に描いた絵を持っている。図２を見よ。
図２ 架空の「完璧なユーザー」
ユーザーに関して開発者が信じたいことは、このようなことだ。
- ユーザーは妨害や気を散らすものがなく、静かで秩序ある環境において作業している。
- ユーザーはコンピュータで行ったことを全て記憶する。
- ユーザーは自分の精神的健康を顧みず、生じるどんな問題でも解決しようという熱意がある。
- ユーザーは休憩や食事、睡眠を取る必要がない。
- ユーザーは悪意によってしか失敗を犯さない。
- ユーザーはシステムの設計者と同じように内部の仕組みを理解している。
XP: 分かった。その絵姿は理解したが、さっき言ったことは私を悩ませる。私たちはすでにユーザーストーリーを製作している。それなのになぜユーザーは完成したユーザーインターフェースと相変わらず格闘しなければならないのだ？
UCD: ユースケースと同じように、ユーザーストーリーはユーザーが行いたいこと、役立つことを記述するとされている。ユースケースとユーザーストーリーとの大きな違いは、ユースケースは常にユーザーを扱うとは限らないことだ（それらは恣意的な”アクター”とシステムとの間の相互作用を記述することができる）。その上、ユースケースは全ての起こりうる結果を記述しようとしてしばしばとても複雑になりがちだ。一方で、ユーザーストーリーは短く簡単であるように計画的に保たれる（複雑な状況を記述しなけらばならない時には、より多くのストーリーが作られる）。これらの違いにもかかわらず、ユーザーストーリーはユースケースとの混同を引き起こしてきた多くの同種の問題からあおりを受ける。本当のところを言えば、あなたがユースケースとユーザーストーリーを書くときにはこのようなことを自問する必要があるのだ。
- 現実のユーザーはそうするだろうか？
- どのようにユーザーは理解するだろうか？
- その情報や理解はどこから由来するのか？
- 要求された動作は一貫しているか？
- ストーリーはユーザーのワークフローに沿ったものであるか？
- 全体のストーリーが中断せずに完了することを期待することは合理的か、それとももっと柔軟性が要求されるか？
これらの問題のいくつかを解決するには、ほとんどの開発者が経験してきたような方法ではなく、適切に取り組むためには人間とコンピュータとの相互作用の理解を必要とする。しかしながら、開発時間と作業の節約のために専門家を参加させる価値は十分にある。
実装の仕様をどれだけユーザーストーリーに盛り込むべきかという大きな問題も隠れている。もしユーザーストーリーがプロセスの初期に書かれるならば、詳細すぎる記述は邪魔になり、尚早なデザインの決定にもつながる。また詳細すぎる記述が含まれているときには、デザインを簡単にすることが難しい。「木を見て森を見ず」というやつだ。
初期のユーザーストーリーから実装の仕様を除外することのもう一つの理由は、私たちはユーザーの概念モデルをそれらから導きたいからだ。これはユーザーが知っていなければならないもの（実体）とそれらとの関係を表した単純な図だ。例として図３を見よ。
図３ ホテル宿泊の概念モデル
XP: とはいえ、これはUMLのクラスモデルだろう！
UCD: それは正しくもあり、間違ってもいる。これはUMLのクラスモデル記法を利用しているが、クラスを表しているのではなく、アプリケーションがどう実装されるかに関わらず、ユーザーが知っていなければならない概念的な実体を表している。これらの実体の大部分はシステムの実装段階で結局はクラスとなるだろうが、私たちにとっては重要なことではない。私たちは後になって情報を提示する「ビュー」（普通はウィンドウやダイアログ）とユーザーがタスクを遂行するために必要な制御を加える。ところでこの一つめの図はCookとDaniels*6が本質的モデルとして参照したものだが、私はむしろこれを概念と呼びたい。それは私たちのユーザーの概念モデルを表しているからだ。
XP: それは少し単純に割り切りすぎのように見える。
UCD: この段階では、そうだ。しかしいくつかのビューと属性を図４で追加してみる。
ビューはこの段階のモデリングにも利用可能なように二つの異なった形式で加えられている。客室ビューと宿泊客ビューはアイコン形式で表現されている。これは通例はデータベースビューのために使われる、Rational Roseの標準アイコンなので、いささか変わった印象だ。もう一つのものはより明確で仕様の次の段階で必要とされる。ホテル宿泊ビューは”View”ステレオタイプを用いて表現されている。これは私たちに普通のクラス記号の使用と、後に必要な属性と操作とを加えさせる。客室と宿泊客の実体は属性を持つ実体の例だ。これらはユーザーが知っていなければならないものだけであり、ユーザーのゴールを達成するために修正される必要があるということを忘れてはいけない。私たちはそれがどのようにコンピュータの内部で表現されるかということについては気にしない。また、ビューは関連している実体をいつも表示しているわけではない。一例として自動チェックイン機を開発しようとしているときはどうか。そこには、最後の宿泊客は誰かなどといった、私たちがビューに表示したくないかなり多くの詳細があるだろう（しかし、それは支配人のビューには表示されてもよいだろう）。
最後にもう一つ。ホテル宿泊ビューと客室とを結ぶ線には”free rooms”という文が中括弧で囲まれて付加されている。これはUMLでは制約と呼ばれ、ビューは空いている客室だけを表示するように制限されていることを意味する。
XP: 仕様のもう一つの段階について述べたか？
UCD: CookとDanielsは三つのものを提案した。本質（概念と名前を変更した）、仕様、そして実装だ。ユーザーインターフェースの実装モデルは、何が表示されるかということと、少なくともどのように表示するかについて詳しく記述されている必要がある。図５はホテル宿泊ビューだけの例を表している。これはユーザーが知る必要のあるビューの属性と、それらがどのように表示されるかということについての概略を一覧にしている。操作（この場合は”Select room”だけ）はユーザーストーリーかユースケースに対応している。もし必要なら、ユーザーがこのビューとどのようにやりとりするかを詳述するのにUMLの相互作用図を用いることができるだろう。
図５ ホテル宿泊ビューの実装モデル
XP: 今や私たちはビューとそれが包含しなければならないものについて理解した。では、どのような形式で仕様書に記述すればよいのだ？
UCD: ここでペーパープロトタイピング*8が役に立つ。私たちはビューを紙に描いてユーザーと初期のユーザビリティテストを行う。これには高価なユーザビリティラボやビデオ録画装置を必要とせず、プロセスを熟知している人とペーパープロトタイプ、何人かの現実のユーザーとノート（紙でできたもの！）があればよい。デザインに関わったスタッフがこの問題に近すぎるために起用できないときのために、ユーザビリティの専門家があなたのチームにいると理想的だろう。
XP: ユーザビリティの専門家を雇うことは贅沢に思える。
UCD: そうではない。ここに二つの問題がある。一つ目は、人的要因（訳注：human factors）と人間とコンピュータの相互作用やユーザビリティの素養をもつチームメンバーを擁することが重要だということだ。たとえいくつかのユーザビリティに関する作業が自分で可能だとしても、目標となりえる人物が必要だろう。二つ目は、人的要因、人間とコンピュータの相互作用とユーザビリティの経験を有益に利用できる多くの活動があるということだ。それらはプロダクトデザイン、ユーザーインターフェースデザイン、ユーザーガイド、ユーザー補助、ヘルプデスクの教育、開発者の教育などだ。
XP: まだ疑問が一つある。例えば私たちは仕様を実装のレベルまで精密にした概念モデルを考え、ペーパープロトタイプを作製した。後の開発でどのように変更に対処すればよいのだ？
UCD: よろしい、これらは不変というものではなく、注意深く変更される必要があるだけだ。最も重要なことは、変更は人的要因と人間とコンピュータの相互作用やユーザビリティの専門家を擁しているユーザーインターフェースのチームによって検討されなければならないということだ。彼らはどんな変更も以下に反していないことに注意するだろう。
- 最初の概念モデル
- ユーザーインターフェースのどこかにある他のもの
- ユーザビリティとアクセシビリティのガイドライン
- あなたたちのチーム内スタイルガイド
XP: それでは、ライフサイクルを通じて出てくる、無数の新機能についての要求についてはどうすればよいのだ？
UCD: 最初にどんな新機能であってもあなたたちのペルソナ（覚えているだろうか？）のためのものかどうかを確認するべきだ。全てのユーザーを満足させるプロダクトなどあり得ないし、どんな新機能であっても増大する複雑さと低下するユーザビリティという犠牲を伴う。あなたたちが個々の機能追加のことを考えているときには、これは自明ではないかもしれない。しかし何十もの機能をユーザーインターフェースに追加しようとするときにはきっとユーザーを困惑させるだろう。新機能が一人以上のペルソナにとって価値があることを確認できたなら、それがプロダクトの概念モデルをどれだけ変化させるかを検討しないといけない。あなたは新しい高レベルの概念を導入することを何度も望まないだろう。だが一方、ユーザーが事をうまく成し遂げられるような、操作や属性への些細な変更は影響が小さいだろう。
XP: それはもっともらしく思えるが、どうやって始めればよいのだ？
UCD: 新しいプロジェクトのために用いられる方法は、既にその要点をだいたい述べた。
- 使用文脈
- ペルソナ
- ユーザーストーリー
- 概念モデル
- ペーパープロトタイプ
- ユーザビリティテスト
あなたはこれらすべてを自分でやることを厄介に感じて、ユーザー中心デザインコンサルタントに手を貸してもらうことを考えたくなるかもしれない。彼か彼女はそれを順調に開始させ、頻繁な周期をプロジェクトの進行につれて、より少なくさせることができるだろう。ほとんどの活動は終始行われるユーザビリティテストとともにプロジェクトの初期にあることに注意してほしい。
XP: このユーザビリティテストを追加しようとしてから、他のテストの形式に簡易化することはできるか？
UCD: 間接的にであれば可能だ。あなたが注意するべき他の節約はたくさんあるが、ソフトウェアテストとユーザビリティテストは全く別のものだ。ソフトウェアテストはチームが意図する通りにアプリケーションが動作することを確認しようとする。ユーザビリティテストはそれがユーザーが求めている動作をするかどうかということに的を絞る。この差違は時には信じ難いほどだ。
あなたが開発中に注意するべき節約は必要になる再作業の総計だろう。他と比較してアジャイルプロセスでは再作業は高くつかないのかもしれないが、それでも負担がない訳ではない。特に開発の後期で大規模なアーキテクチャ上の変更が必要になったときなどは。
XP: 既存のアプリケーションにはどのように取り組めばよいのだ？
UCD: 初めの一歩は深刻なユーザビリティ上の問題が存在するかどうかと、それらを修正するために何が必要となるかを見つけることだろう。このためには何度かのユーザビリティ評価が必要となるだろう。私はユーザーとのユーザビリティテストに続く最初の専門家によるレビューを必要があれば勧める。それによってレビュアーはアプリケーションの”逆設計された”概念モデルを用意することもできるだろう。これはあなたのデザインしたモデルと比較できる。モデル間の明らかな不合理、加えてユーザビリティ評価によって確認された問題領域はチームが注意を集中する必要がある所だ。さらに、ユーザー中心デザイン専門家はこれらの解決の手助けができるだろう。
アプリケーションが大規模な再作業や置換を必要とするなら、私が述べたほとんどの成果物のために、あなたはそれを新しいプロジェクトとみなすべきだ。ペーパープロトタイプが辛うじて省略できうるただ一つのものだ。ユーザーストーリー形式の使い古されたやり方を採ることはアジャイルな方法に反していると思うかもしれないが、それが後のプロセスを導いていくのだから、それが使用文脈と重要なペルソナによってユーザーの要求を正しく反映していることが重要だ。
ユーザー中心デザインと既存のソフトウェア開発プロセスとの統合に関する文献*9は多くないので、現在のところコンサルタントと親密に作業することはおそらく避けられない。私は遠くない将来にユーザー中心手法が主流のソフトウェア開発に適用され始めることを期待している。使いやすいシステムを提供することのできる私たちの能力はそれにかかっている。
参考文献
Beyer H. & Holtzblatt K. (1998) Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, San Francisco, CA.
Cook S. & Daniels J. (1994) Designing Object Systems: Object-Oriented Modelling with Syntropy. Prentice Hall, New York, NY.
Cooper A. (2003) About Face. John Wiley & Sons Inc, New York, NY.
Fowler M. & Scott K. (2000) UML Distilled: Applying the Standard Object Modelling Language. Addison-Wesley, Reading, MA.
邦訳：UML モデリングのエッセンス―標準オブジェクトモデリング言語の適用
Hudson W. (2001) Towards Unified Models in Object-Oriented and User-Centered Design. In: M.van Harmelen (ed), pp. 313-362. Addison-Wesley, Boston, MA.
[ISO/TC159. Human-centered design processes for interactive systems. ISO 13407:1999. 1999. Geneva, Switzerland, International Organization for Standardization.]
Roberts, Dave, Berry, Dick, Isensee, Scott, and Mullaly, John. 1998. Designing for the User with OVID: Bridging User Interface Design and Software Engineering, Macmillan Technical Publishing.
関連資料：Crafting the Compelling User Experience Using a methodical software-engineering approach to model users and design （読む価値あり、133P）
Snyder C. (2003) Paper Prototyping. Morgan Kaufmann, San Francisco, CA.
邦訳：ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする
*1: ユースケースはシステムとその外部の実体との間の相互作用を記述する。Ivar Jacobsonはこの主題についての最初の論文で外部のアクターをユーザーと呼んだ。”ユーザー”が”アクター”に変化し、これだけが原因ではないが、それからすぐにユースケースは顔をしかめさせるようになった。
*2: ISO標準13407では”人間中心”とされているが、実際にはユーザー中心と人間中心は同じことである。また標準の題名に英国式綴が用いられていることも無視せよ。（訳注：centreの綴り）[ISO/TC159 1999]を参照。
*3: 文脈調査についての充実した議論は[Beyer & Holtzblatt 1998]に見つけられるだろう.
*4: [ISO/TC159 1999] ISO 13407標準に詳細に記述されている。
*5: ペルソナについての長い議論のためには、[Cooper 2003]を参照せよ。
*6: [Cook & Daniels 1994]を参照。Martin Fowlerは[Fowler & Scott 2000]において、これらを”パースペクティブ”としても議論している。彼は”本質”的モデルを”概念”とも呼んでいる。
*7: [Roberts et al. 1998]に基づく。
*8: ペーパープロトタイピングについてのより広範な議論については[Snyder 2003]を参照せよ。
*9: ユーザー中心デザイン、UMLとユースケース主導の手法に関するより詳細な議論については、[Hudson 2001] を参照せよ。
♪ The Velvet Underground / Pale Blue Eyes
♪ AJICO / 深緑
♪ U2 / So Cruel
♪ くるり / ばらの花
♪ Daft Punk / Harder, Better, Faster, Stronger
ユーザー調査からリファクタリングまでとても欲張った論文。
UCDを開発プロセスに適用するときの問題と利用できる手法について俯瞰的に概説してある。
UMLでの仕様モデリングの部分など、デザインの人には読み難いかもしれないが、とても興味深いと思えたので訳してみた。
少なくとも、「完璧なユーザー」の絵は、クーパーの「ゴムのユーザー」よりもインパクトがあるだろう。
理想をいえば、ソフトウェア技術者はUCDを学ぶべきだし、UCD専門家はソフトウェア開発を経験するべきだろう。（苦しさを実際に体験しないと、新しいプロセスが生まれてくる理由がわからないだろうし。）
アジャイルが槍玉に挙げられているのだが、述べられている問題は開発プロセスを限定するようなものではないし、何よりもアジャイルがイテレーティブ開発であるということから目を逸らしているようにも思った。少しエンジニアを擁護しておくと、現在のXPでは、イテレーションごとにユーザーの受け入れテストを実施すべしというプラクティスが定義されている。これを実施すれば、ユーザーインターフェース上の乖離はイテレーションごとに発見されるだろう。
日本では、やっとペルソナのことが広く紹介され始めたくらいだから、この論文で述べられているような、デザインとシステムの統合についてはまだまだだし、開発側でもアジャイルプロセスを導入することはあまりないだろう。
個人的にはペルソナよりも、モデリング言語を用いてユーザーロールを表現することに可能性を見いだしている。ペルソナに懐疑心を抱くエンジニアも納得させることができるかもしれない。
参考文献には挙げられていないが、今ではこの本も参照されるべきだろう。
Cohn M. (2004) User Stories Applied: For Agile Software Development Addison-Wesley Pub