トピック

ユーザー指向の設計とは ページの先頭へ

ユーザー指向の設計は何によって構成されるかという点について、明確な共通認識は存在しません。その中で、ジョン・グールドとその同僚が 1980 年代に IBM で生み出したアプローチは Design for Usability 参考資料 [GOU88] と呼ばれ、そこには現在最も広く受け入れられている定義が網羅されています。このアプローチは、IBM の 1984 Olympic Messaging System 参考資料 [GOU87] など、数々の対話型システムにおける実践的経験から導き出されました。 下の通り、このアプローチには 4 つの主要コンポーネントがあります。

ユーザーへの注目 ページの先頭へ

グールドは、開発者はどのような集団をユーザーとするか判断し、可能な限り早い段階でユーザーの参加を得ることが必要だとしています。また彼は、ユーザー、そのタスク、要求を熟知するため数多くの方法を提案しています。

·    ユーザーとの対話

·    顧客の訪問

·    ユーザーの仕事の観察

·    ユーザーの仕事のビデオ撮影

·    業務組織に関する知識

·    自分で仕事をやってみる

·    ユーザーの作業中の考えを言葉にさせる

·    参加型の設計

·    ユーザー側の専門家の設計チームへの参加

·    タスク分析の実行

·    調査アンケートの活用

·    テスト可能な目標の設定


 RUP (Rational Unified Process) では、いくつかの重要段階で検討会議を行いますが、完全な青写真を得たいなら、これら会議をグルードが説明するある種の作業によって補完する必要があります。(この背後には、人間には自分が何をするかについて、実際のやり方とはかけ離れた説明をする傾向があるという議論があります。作業の配置や"意味のわからない"無駄な資料の存在など、一般的なタスクや一見重要でないと思われる詳細は忘れられがちであり、現在のプロセスに"正式に"組み込まれていないという理由から排除されることもあります)。

設計との統合ページの先頭へ

使いやすさに関するタスクは、開発の当初から並行して取り組まれるべき作業です。こういったタスクには、ユーザー インターフェイスのスケッチ、ユーザー ガイド、オンライン ヘルプの立案などが含まれます。これについてもグールドは、使いやすさについては 1 グループが責任を負うべきと指摘しています。  

統合設計の大きな特徴は、詳細なユーザー インターフェイス設計を導くため全体的なアプローチ (フレームワーク) を開発し、これを早い段階でテストするという点にあります。このことは、ユーザー指向の設計と他の真にインクリメンタルな技術との大きな相違点となっています。これにより後のフェーズでインクリメンタルな設計を実行した際にフレームワークにシームレスに適合させ、ユーザー インターフェイスの外観、用語、概念に一貫性をもたせることが可能になります。 

RUP では、ドメイン・モデルを使用してこのフレームワークを確立し、それによってユーザー・インターフェースのすべての用語および概念を業界、特にユーザーが普通に認知できるようにすることができます。 (ドメイン・モデルのサブセットには、ユーザーの特定のグループにのみ適用できるものがある場合があります。 そのため、こういったサブセットを簡単に識別できるようにドメイン・モデルを編成することが必要です。) ユーザー・インターフェースの設計が進行するにつれ、多くのドメイン・クラスがユーザー・インターフェースの要素として表現されていきます。 ユーザー・インターフェースの要素およびそれらの相互の関係は、ドメイン・モデルと矛盾せず、設計中のシステム全体を通じて一貫した表現にすべきです。 (こうすることでユーザーの助けとなるだけでなく、ユーザー・インターフェース・コンポーネントの再利用を促進します。)

初期のユーザー テストページの先頭へ

初期段階でユーザー テストを行うことは、早期の絵コンテ作成、忠実度の低いプロトタイプの早期の開発を意味します。忠実度の高いプロトタイプは、後のプロセスで作成されます。

絵コンテユース ケースと共に、設計中のシステムの具体的なシナリオ作成に活用できます。これらは物語、絵付きの物語 (絵はユーザー インターフェイスのモデルを使用)、絵コンテ、ユーザーとのウォークスルー、ユーザー指向グループなどの形式を取ることができます。これらの形式は、多くのソフトウェア開発者にとってなじみの薄いものです。しかし、こういった方法を取ることで、実装に移った後で設計に不適当な箇所を発見したり、要求の誤解があることが判明した場合よりもはるかにコストを抑えることができます。

反復的設計ページの先頭へ

オブジェクト指向開発は、反復的プロセスと同義語となっています。反復的設計は、理解の洗練と要求の変更を必要とするような問題への対応に特に適しています。当然、反復的設計はユーザー指向設計の中心的コンポーネントとなります。この理由の一つには、徐々に変化するユーザー ニーズが挙げられますが、その他にも、各種のニーズに対応する設計ソリューションの開発に伴う複雑さも挙げられます。

ユーザー指向では、統合フレームワーク内で反復設計を行う点に注意してください。ここでは「間に合わせ仕事」のソリューションになりがちな、合意のフレームワークの範囲から外れる段階的な開発作業は慎重に避けています。

ユーザー指向の設計の必要性 ページの先頭へ

ユーザー ニーズへの適合 ページの先頭へ

対話型システムは、その成功を左右するユーザー ニーズへの適応に基礎を置いています。このことは、各種のユーザー コミュニケーションの特定のみならず、個々のユーザーの持つ各種のスキル、経験、嗜好を認識することを意味します。

開発者や管理者は自分がユーザー・ニーズを理解していると思いがちですが、実際に理解していることはまれです。 ユーザーがどうタスクを実行すべきか という点に注意が向いてしまい、ユーザーがどう実行することを好むか という点にはあまり目が向けられません。 多くの場合、制御におけるフィーリングはそれ自体重要ですが、嗜好の問題はそれを超えた問題です。 また嗜好は、経験、能力、および使用方法により変わります。 これらの問題は、国際標準 [ISO 13407] (タイトルは「human-centered design processes for interactive systems」) に準拠するため、設計プロセスにとって非常に重要であると考えられています。 この標準と関連する問題については、このページの後の部分でわかりやすく説明されています。

ユーザー インターフェイスの設計 ページの先頭へ

ユーザーは、ユーザー インターフェイスを通じてシステムを理解し、システムと相互にやり取りを行います。このため、インターフェイスで使用される概念、画像、用語は、ユーザーのニーズに適合したものでなければなりません。例えば、顧客に直接チケットを販売するためのシステムは、チケットの販売要員が使用するものとは異なるはずです。この違いは、要求や、まして詳細なユース ケースにあるのではなく、ユーザーとシステムの使用環境の特性にあると言えます。

またユーザー インターフェイスは、少なくともコンピュータとドメインという 2 つの側面において、潜在的に幅広くそれぞれの経験に対応するものでなければなりません (図 1) 。コンピュータ経験には、コンピュータに対する一般的な精通度の他、開発中のシステムに対する経験も含まれます。コンピュータとドメインのいずれについても経験の浅いユーザー (図の左角) には、専門家レベルのユーザー (図の右角) 用のものとはまったく異なるユーザー インターフェイスが必要です。

付随するテキストで説明されているダイアグラム。

図 1: コンピュータや領域の経験が各種ユース ケースの学習度に与える影響

経験の浅いユーザーも、時間が経過すれば必ず専門家となるという訳ではないので注意が必要です。経験の浅いユーザーが専門家レベルに到達するのを妨げる要因は様々です。例えば、使用頻度の低さ、動機の弱さ、複雑さなどがあります。また逆に、中には、ほとんどが専門家レベルのユーザーであるというシステムもあります。ここでの要因は、トレーニング、商品どの高さ、動機の強さ (仕事で使用する) などです。これらの問題の一部、そしてそれがユーザー インターフェイスに与える影響について表 1 にまとめました。

 

低い

高い

コンピュータの経験

簡単な質疑応答、簡単なフォーム入力、Web (ハイパーリンク)、メニュー形式のインターフェイス

複雑なフォーム入力、Web (ハイパーリンク)、メニュー形式のインターフェイス (質疑応答、簡単なフォーム入力は経験のあるユーザーには大きなストレスとなる場合がある)

ドメインの経験

一般的な用語と概念

そのドメインに固有の用語、概念

トレーニング

学びやすさに焦点を置く (一貫性、予測性、強い印象)

使いやすさに焦点を置く (直接的、カスタマイズ可能、非直観的)

使用頻度

学びやすく記憶に残る、シンプルなインターフェイス

使いやすい、ユーザーによる制御を可能にする複数のショートカットと技術

動機

使い甲斐がある、パワフルながら複雑な感じがしない

洗練され、高度でカスタマイズ可能な機能が多い


1: ユーザー インターフェイスの設計に影響する要因

対話型システムは、ユーザーそれぞれの経験や環境への適応を考えて設計するか、 一般的設計に制約を課す段階を設ける必要があります。例えば、トレーニングは複雑なシステムの学びやすさに対する要求を低減するために活用されます。また、システムによってはユーザーの主要な要求への対応度を高めるため、その有効範囲を狭めることもあります (アラン・クーパー著 『The Inmates Are Running the Asylum』参考資料 [COO99])。

法律と標準 ページの先頭へ

ユーザー指向の設計の一環として、ユーザーのスキルや物理的属性について考慮する必要があります。こういった問題は、現在、法律面で大きくなってきています。 中でも最も顕著な問題が、障害を持つ方への対応です。一般に、幅広い層のユーザーが使用できるシステムを作ることは、ユーザーのコミュニティ全体にもメリットのあることだと考えられています。

下の表は、世界各地の関連法律と資料をまとめたものです。

説明 Web サイト

オーストラリア

 
Disability Discrimination Act http://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm
Disability Rights http://www.hreoc.gov.au/disability_rights/index.html

ヨーロッパ

 
European Disability Forum http://www.edf.unicall.be

イギリス

 
Disability Discrimination Act http://www.hmso.gov.uk/acts/acts1995/1995050.htm
New Deal for Disabled People http://www.disability.gov.uk
Digital Access Campaign http://www.rnib.org.uk/digital/welcome.htm

国連

 
United Nations Standard Rules on the Equalization of Opportunities for Persons with Disabilities http://www.un.org/esa/socdev/enable/dissre00.htm
Social Development Information on the Internet http://www.unescap.org/esid/psis/disability/index.asp

アメリカ

 
Americans with Disabilities Act (ADA): US Department of Justice http://www.usdoj.gov/crt/ada/
Section 508 of the Workforce Investment Act: US Department of Justice http://www.usdoj.gov/crt/508/508home.html 
US Access Board Electronic and Information Technology Advisory Committee (EITAAC) http://www.access-board.gov 
World Wide Web Consortium Web Accessibility Campaign http://www.w3.org/wai/ 

その他の資料

 
障害者関係のインターネット資料 http://www.disabilityresources.org

 表 2a: 国、地域、団体別の障害者関係法

法律とは別に考えても、以下に示す通りユーザー指向の設計とユーザー インターフェイス設計は標準化の大きなテーマとなりつつあります。

説明 Web サイト / 標準

ANSI

www.ansi.org

ANSI

ANSI-HFES

ANSI-NSC

ANSI と Human Factors and Ergonomics Society は、共同で数々の標準を発行しています。また ANSI は ANSI-NSC Z365 を発行しています。これは累積性ストレス障害 (反復過多損傷、RSI) の制御と回避に関連した法律です。

ANSI は、 Information Infrastructure Standards Panel (IISP) の一環として、人間とコンピュータとの相互関係に関する標準を作成しています。

ISO

www.iso.ch
ISO 9241 主にワークステーションの人間工学に関する大規模な標準群、その他に使いやすさに関する指針も含みます (パート 11)。また現在作成中の ANSI-HFES 200 のベースとなる規格でもあります。
ISO 10075: 1991 頭脳労働の負荷に関する人間工学の原則をまとめたものです。
ISO 17041-1: 1995 テキスト編集のカーソル制御に関するものです。
ISO 11581 アイコンとポインタに関するもので現在作成中です。
ISO 13407: 1999 対話型システムの人間中心の設計プロセスに関する標準です。

 表 2b: ユーザー インターフェイスとユーザー指向設計に関する ANSI と ISO 標準

RUP のユーザー インターフェイスの設計 ページの先頭へ

ユーザー・ニーズに適したシステムを開発するためには、要求の分析に相当の労力が必要です。 ユーザー指向設計では、この作業を特にエンド・ユーザーに焦点を当てて行います。 これについては後述の要求分野でアクターとして詳しく説明します。

ただし、ユーザー指向設計の最大のポイントは、上に挙げた成果物で説明されている役割を担う現実の人々の要求を理解するという点にあります。特に、ソフトウェア システムの設計に好都合な仮想上の人物のための設計は避けなければなりません。またエンド ユーザーについて説明する成果物は、ユーザーとの十分な直接対話の後に作成しなければなりません。ユーザー指向設計では、この直接対話がコンテクチュアル インクワイアリーと呼ばれるプロセスの一部となることがあります。ヒュー・ベイヤーとカレン・ホルツブラットは、その著作『Contextual Design』参考資料 [BEY98] の中でコンテクチュアル インクワイアリーの前提を下のように説明しています。

"...顧客が実際に作業をしている場所に行き、作業の様子を観察し、作業について顧客と話し合うこと"

(この具体例については、ユーザーへの注目に示されています)。このアプローチはシステム要求をより正確に理解するだけでなく、ユーザー自身やそのタスク、環境への理解のためにも活用されます。各々が固有の属性を持ちますが、それらをまとめて使用のコンテキストと言います。これらは、下に示したユーザー指向の設計に関する ISO 標準に詳しく説明されています。

使用のコンテキスト ページの先頭へ

ISO の Human-centered design processes for interactive systems 参考資料 [ISO13407] では、設計の第1段階を使用のコンテキストの理解と指定としています。ここで挙げられている属性は下の通りです。

コンテキスト 属性

タスク

システム使用の目的、性能の頻度と期間、健康状態と安全性に関する考察、作業の割り当て、人間と技術的リソースとの間の運用段階。製品やシステムが提供する機能、特徴に対してタスクを単独で説明することはしないでください

ユーザー (各種のタイプ、役割)

知識、スキル、経験、教育、トレーニング、物理的属性、習慣、嗜好、能力。

環境

ハードウェア、ソフトウェア、資料など、物理的、社会的環境、関連する標準、技術的環境、周囲環境、法律環境、社会的、文化的環境。


表 3: ユーザー指向設計に関する ISO 標準の使用のコンテキスト

ユーザーのコンテキストを 2 つの構成要素 (ユーザーのタイプと役割) に分けてから、下の 4 つのコンテキスト間の関係を考慮すると作業が楽です。

付随するテキストで説明されているダイアグラム。

図 2: コンテキスト間の関係

図 2 は、ある環境内のあるユーザーが担当するある役割の中で実行される各タスクについて示したものです。これらのコンテキストは表 4 に示す通り RUP の成果物に対応しています。

ISO 13407 コンテキスト RUP 成果物

環境

ユーザー

ロール

タスク


 表 4: ユーザー指向設計に関する ISO 標準のコンテキストと対応する RUP 成果物

これら各コンテキストは、対応するユーザー インターフェイスの設計に大きな影響を及ぼす可能性があります。このため、私たちは潜在的に数々の組み合わせに直面することになります。小規模なシステムでさえ、2 種類の環境 (オフィスと顧客サイト)、3 種類のユーザー (販売の初心者、販売の専門家、管理者)、6 種類の役割 (電話セールス アシスタント、外部の販売要員など) が存在します。この場合、潜在的にはタスクあたりの種類は最大 36 になります。ただし、実際の組み合わせは、これよりはるかに小さくなります。

タスクを個別に説明しなければならないことは明白ですが、1 つの説明がすべての順列に適合することはまれです。 そこでユーザーと環境のコンテキストを役割の説明の要素として盛り込むという方法があります。 これは、コンスタンチンとロックウッド参考資料 [CON99] が採用したソリューションです。 このソリューションでは、役割の各々の重要な組み合わせ (ユーザーと環境) ごとに「ユーザーの役割」を別々に与え、次に結果として得られたユーザーの役割に、単純な名詞ではなく分かりやすいフレーズで名前を付けます。 例えば、「顧客」という役割と、「一般顧客」、「Web 顧客」、「得意顧客」、「上得意顧客」というユーザーの役割とを比較してみてください。

それぞれのユーザーの役割の説明には、役割の詳細な説明の他、そのユーザー (役割の現職者) と環境についての説明が含まれます。このアプローチを RUP に適応するには、ユーザーの役割に対応するアクターを選択することが必要になります。

シナリオ、ユース ケース、基本的ユース ケース ページの先頭へ

シナリオ、ユース・ケース、および基本的ユース・ケースという用語は、同じような印象を受けて混乱しやすいですが、それぞれ微妙に異なる意味を持ち、各々別々の設計アプローチで使用されます。 例えば、 RUP で「シナリオ」とは、ユース・ケースのインスタンスを意味し、可能な基本的フロー、および代替案となるフローによる特定の「パス」を指します。 しかし、ユーザー指向設計方式やユーザー・インターフェース設計方式では、シナリオを使用のストーリーという意味で使用し、単なるイベントのフローではない詳細情報を含んでいることが多々あります。 このような追加情報は後の設計フェーズには無関係である場合もありますが、ユーザー、タスク、および環境への理解の一助とはなります。 このため、シナリオはビジネス・モデリング分野で(../../workguid/wg_stbd.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません絵コンテおよび../../workguid/wg_rlpl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんロールプレイにおいて) 広く使用される可能性がありますが、その焦点は要求分野のユース・ケースに移っています。

図 3 は、この用語の意味の重複について示しています。上部の目盛りには、共に変化する傾向がある多くの異なった要因が含まれています。例えば、目的の要求への指向が強まる場合、通常、構造はより正式なものとなります。基本的なユース ケースは、普通のユース ケースの右側に示されています。これは、ユーザーの役割により、基本的なユース ケースの方が限定性が高くなり (前のセクションを参照) 、このためより正確な構造を持つことになるからです。

付随するテキストで説明されているダイアグラム。

図 3: ユーザー指向設計のシナリオ、ユース ケース概念の重複

例を見ると、システムのユース ケースと基本的なユース ケースの違いがよく分かります。  表 5 は、コンスタンチンとロックウッドの Software for Use 参考資料 [CON99] のユース ケースについて示したものです。

ユーザーのアクション システムの応答
カード挿入 磁気ストリップの読み取り
印刷の要求
PIN の入力 PIN の検証
オプションの処理メニューを表示
キーを押す アカウント メニューの表示
キーを押す 合計金額の入力を求める
合計金額の入力 合計金額の表示
キーを押す カードの返却
カードの受け取り 現金の支払い
現金の受け取り  

表 5: ATM で現金を引き出す場合の一般的なユース ケース

この例では、アクターとシステムの間のイベントを順を追って詳細に説明したもので、2 つの列を仕切る垂直線がユーザー インターフェイスに相当します。コンスタンチンとロックウッドが基本的なユース ケース用としてこのスタイルを推奨していますが、このユース ケースは特に基本的なものではないことに注意してください。この理由は、相互作用の全体的な詳細に基づいている点にあります。つまり、相互作用がどのように生じるかという点です。基本的なユース ケースでは、相互作用が何に関するものなのかに焦点があります (これをセマンティクスと言います)。表 6 は、相互作用の基本的なユース ケースを示しています。

ユーザーの目的 システムの責任
個人の確認 個人情報の検証
選択肢の提示
選択 現金の支払い
現金の受け取り  

表 6: ATM で現金を引き出す場合の一般的なユース ケース

このユース ケースは、現金引き出しの重要な要素を抽出したものです。ユーザーのアクションとシステムの応答を示す見出しは、ユーザーの目的とシステムの責任に置き換えられています。理想的なインターフェイスの設計は、ユーザーの目的と意図に焦点が置かれてますが、これらは従来のユース ケースでは表面に出ていないことが多々ありました。  基本的なユース ケースは、下のような場合特に有効です。

  • 設計上の制約が複数ある (銀行カードを FALSE とする設計上の制約など)
  • 他の個人情報確認方法に対応することでシステムを強化する可能性がある (安全なインターネット アクセスなど)
  • 制約のないプロジェクトでの再利用を可能にするため、設計上の制約のないユース ケースの作成が必要

しかし、基本的なユース ケースにも欠点があります。表 5 に示すように単純なユース ケースは、ポイントの抽出となると判断が難しくなります。例えば、カードの挿入により顧客や口座は特定されるか、という問題などです。コンスタンチンとロックウッドはカードの挿入を顧客の特定と解釈していますが、既存の ATM の多くはこれよりも遅れています。これは網膜走査、指紋による個人特定のような最新鋭技術を考慮に入れた判断であったかもしれませんし、または単なる見落としであった可能性もあります。このケースでは、複数の口座を持つ顧客は、さらに口座を特定するための選択をしなければならないことになります。

基本的なユース ケースが引き起こすもう 1 つの問題は、その抽象性ゆえ、エンド ユーザーや他の利害関係者によるレビューに適さないという点にあります。また、この問題の原因の一端は、基本的なユース ケースをユーザーのアクションを示す具体的な形に戻さなければならないというところにあります。この作業は、具体的な用語を用いて相互作用を説明するシナリオを作成し、設計モデルが使用できるようになった際に行うことが可能です (内部のオブジェクトのコラボレーションというより、むしろユーザー システムの相互作用に関連するものですが、概念としてはユース ケース の実現に類似します)。

つまり、基本的なユース ケースの構築は、以下のような場合には不適当である可能性があります。

  • ユーザー インタフェイス技術が厳しい制約を前提としている (システムが銀行カードを受け入れなければならないなど)。
  • 期待されるメリットに比べ、抽象的なユース ケースをユーザーが理解するのに時間がかかり過ぎる。

RUP の基本的なユース ケース ページの先頭へ

RUP は基本的なユース ケースについて明示的に言及することはありません。しかし作業: ユーザー インターフェイスの設計では、まず基本的ユース ケースを用い、続いて使いやすさに関する要求から開発、検討を行った上で、ガイドライン: 絵コンテで説明した通り絵コンテを作成します。   

このことは、セマンティクス (相互作用の意味) のみを残すため、すべての設計または現在の実装の詳細を取り除くことを意味します。  その後、種々の設計の選択肢を検討しながら、構文上の詳細 (相互作用がどう起きるか) が実現の 1 つの種類として基本的なユース・ケースに追加されます。  (結果的に設計の各選択肢は、1 つの基本的ユース・ケースの実現となります。)

続いて、絵コンテを作業: ユーザーインターフェイスのプロトタイプの作成への入力として使用し、ユーザー インターフェイスのプロトタイプを作成することができます。



Rational Unified Process   2003.06.15