概念: ユーザビリティ エンジニアリング

トピック
概念

概論ページの先頭へ

ユーザビリティ エンジニアリング (または、ユーザー指向の設計) は、エンドユーザーの理解を深め、要求、ユーザー インターフェイス設計、テスト作業にユーザーを参加させることで、よりよいシステムを構築する技術です。基本概念は、「概念: ユーザー指向の設計」で説明しています。先に進む前に読んでおいてください。ここでは、RUP (Rational Unified Process) が現在ユーザービリティ エンジニアリングをどのように扱っているかを説明します。

役割ページの先頭へ

RUP には、使いやすさに関しての多くの役割があります。システム分析者ユース ケース定義者には、ユーザー、ユーザーのタスク、ユーザーの環境に関する情報を収集して分析する技術、これらを要求やの成果物から取得する技術が必要です。この資料は、要求レビュー担当者.../process/workers/wk_tstr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト担当者../process/workers/wk_tstanl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト分析者の役割は、使いやすさのテストに責任を持ちます。ユーザー インターフェイス設計者は、ユーザー インターフェイスの設計と「外見」に責任を持ちます。実装担当者は、ユーザー インターフェイスを選択または開発して、機能的なユーザー インターフェイスを構築します。

プロジェクト 管理者にも重要な役割があります。プロジェクト管理者は、ユーザーが開発環境を利用できるようにし、使いやすいシステムを構築するために必要なスキルを持つ要員で開発組織を組織します。../process/workers/wk_depm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません導入管理者../process/workers/wk_crsdv.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんコース開発者、../process/workers/wk_tchwr.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテクニカル ライターなどにも、導入システムを使いやすくするための責務があります。

基本プロセス ワークフローページの先頭へ

次に、RUP の基本プロセス ワークフローを、使いやすさで最も重要な作業と成果物の面から説明します。

要求ページの先頭へ

使いやすさの面から、要求の基本プロセス ワークフローでは次の点に注目します。

  • ユーザーとそのニーズを理解する
  • ユーザーに最大の利益となるユース ケースを識別する

具体的な作業と成果物は次のとおりです。

作業

成果物

使いやすさに関する内容

利害関係者の要望の顕在化 利害関係者の要望

この作業には、ユーザーへのインタビュー、アンケート、検討会議の開催が含まれます。ユーザーとユーザー環境への理解を深めます。次の作業が含まれます。

../webtmpl/templates/req/rup_stkreq.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: 利害関係者の要望のテンプレートでは、教育に関する経歴、コンピュータに関する基礎知識、経験、既存の環境、期待、目標など、詳細なユーザー プロファイルを把握します。また、ユーザーの視点から、問題および優先順位の詳細も把握します。利害関係者の要望は、開発構想書の材料になります。

開発構想書の作成 開発構想書

開発構想書テンプレートの「ユーザー環境」では、エンドユーザーの作業環境や、ISO の環境コンテキストを説明します [ISO 13407]。

開発構想書テンプレートの「ユーザー プロファイル」では、ユーザーの専門領域、技術的な背景、責任、成功の条件、納品可能物などを説明します。これは、ISO でユーザー コンテキストと呼ばれます [ISO 13407]。

アクターとユース ケースの獲得ユース ケース モデルの構成ユース ケースの詳細の作成 ユース ケース モデル

ユース ケース モデルは、ユーザー (人間のアクター) が実行するタスク (ユース ケース) を表します。汎化関係を使用して、アクター間の類似性や関係を把握します。アクターはユース ケースに関連付けられます。Constantine の 「役割モデル」と同様です [CON99]。ユース ケースは、コミュニケーション関連包含汎化拡張の関係を通して構成され、相互に、またはアクターに関係付けられます。

検討会議は、ユーザーを参加させるための適切な方法です。「../process/workguid/wg_ucwsh.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんユース ケース検討会議」を参照してください。

 

アクター

人間のアクターの特性は、アクターの属性として把握されます。これには、次のものがあります。

  • アクターの責任範囲
  • アクターがシステムを使用する物理的環境
  • アクターによって表されるユーザー数
  • アクターがシステムを使用する頻度
  • アクターの問題領域に対する知識レベル
  • アクターの一般的なコンピュータ経験レベル
  • 専門知識レベル (教育)、社会的な関わり合い (言語)、年齢などのアクターの一般的特性
 

ユース ケース

Constantine の参考資料 [CON99] で説明されている、基底ユース ケースが含まれます (基底ユース ケースについて詳しくは、「概念: ユーザー指向の設計」を参照してください)。特定のユース ケースの具体的な使いやすさに関する要求は、../webtmpl/templates/req/rup_ucspec.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんユース ケース仕様の「特殊な要求」として把握されます。
ソフトウェア要求の詳細の作成

補足仕様書

補足仕様書では、ユース ケースで指定されていない要求を把握します。これには、使いやすさに密接に関連する、利用可能性や性能に関する要求が含まれます。複数のユース ケースに適用される一般的な使いやすさに関する要求は、適用される法規や使いやすさの標準と共に、ここで把握されます (使いやすさに関する法規と標準について詳しくは、「概念: ユーザー指向の設計」を参照してください)。
要求のレビュー 変更依頼 ユーザー指向の開発作業では、すべての要求レビューに可能な限りユーザーを参加させます。
共通語彙の把握 用語集 ユーザーの問題領域に固有な共通語彙を把握し、ユーザーとその他の開発チーム間のコミュニケーションと理解を促進します。

これらの要求作業に加えて、ほかの有効な手法があります。

    • アフィニティ作図法 [HOL96BEY98]。ユーザーとそのタスクについて収集した情報の断片を、付箋紙に書いて貼り付ける手法です。ユーザーと分析者は協調して、関連するメモを概念的なグループまたは「類似性 (アフィニティ)」でまとめます。この作業は、問題、その相対的な重要性、その関係について、共通の理解を深めるために役立ちます。
    • カード ソート法 [CON99]。索引 カードの情報をグループにまとめるのと同様の作業です。カードは、重要性や頻度などでもソートできます。
    • 階層タスク モデリング [MAY99CON99]。現在ユーザーが実行しているタスクを分析し、階層にまとめます。階層は、タスクに対するユーザーや組織の理解を反映します。

分析と設計 ページの先頭へ

この基本ワークフローの多くの作業では、ユーザー インターフェイスの具体化や設計に集中します。これらを次に示します。

作業

成果物

使いやすさに関する内容

ユーザー インターフェイスの設計

絵コンテ

ナビゲーション マップ

この作業では、一般的に概念的な設計と呼ばれるものを作成します [FER01]。これは、ユーザー インターフェイスの初期の抽象化であり、ユーザーに対して表示されるメイン ウィンドウやナビゲーション経路が作成されます。この作業では、ユーザー インターフェイスの設計を駆動するユース ケースに注目します。

ナビゲーション マップは、やり取りを行う場所 (画面、ウィンドウ、ダイアログ ボックス) のナビゲーション経路の概要を示します。参考資料 [CON99] を参照してください。

ユーザー インターフェイスのプロトタイプの作成 ユーザー インターフェイスのプロトタイプ

3 種類の基本的なプロトタイプの作成が可能です。

図 (紙)
ビットマップ (描画ツール)
実行可能形式 (対話型)
ほとんどのプロジェクトでは、3 種類のプロトタイプのすべてを、ここに示した順序で使用します。

ユーザー インターフェイスのプロトタイプを作成する主な目的は、実際に設計と開発が開始される前に、システムの機能と使いやすさを明らかにしテストすることです。これにより、開発に多くの時間とリソースを費やす前に、適切なシステムを作成しているかどうかを確認できます。


次の方法も、ユーザー インターフェイスの設計の一部として有効です。

    • カード ソート法 [CON99]。前にも説明しましたが、ユーザー インターフェイスの設計でも有効です。各メニュー項目やコンテンツ項目をカードで表し、ユーザーがカードを論理的にグループ分けします。

ここで説明した作業に加えて、次のような分析と設計作業でユーザー インターフェイスの設計を補足します。

作業

成果物

使いやすさに関する内容

ユース ケース分析 分析クラス
ユース ケースの実現

以下も参照してください。

クラス設計

この作業では、ユーザー インターフェイスの設計とプロトタイプの結果を使用して、クラスを設計します。プロトタイプと異なり、簡単に作成する概念的なユーザー インターフェイス作業ではなく、納品されるシステムの設計を表すことを意図しています。

以下のガイドラインも参照してください。

ガイドライン: UML を使用した Web アプリケーションの構築


実装 ページの先頭へ

ユーザー インターフェイスの実装は、一般的な実装ワークフローに従います。多くの場合、ユーザー インターフェイスの実装は、設計作業の一部として行われることに注意してください。

テスト ページの先頭へ

使いやすさのテストは、ユーザー インターフェイスの試作や実行可能形式のプロトタイプが完成すると同時に開始します。テストには、使いやすさに関連する../process/workflow/test/co_perfo.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません性能テストも含まれます。テストでは、補足仕様書で記述された、または../webtmpl/templates/req/rup_ucspec.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんユース ケース仕様書で特殊な要求として記述された、使いやすさや性能の要求が検証されます。

導入 ページの先頭へ

ユーザーは、../process/workflow/deployme/wfs_dep10.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: ベータ テスト リリースや、../process/workflow/deployme/wfs_dep3.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: 受け入れテストの管理における最終の使いやすさのテストに大きく関与します。

../process/workflow/deployme/wfs_dep2.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんワークフローの詳細: サポート資料の作成には、トレーニング教材やシステムのサポート資料の作成が含まれ、納品されたソフトウェア製品をエンドユーザーが正しく使用できるようにします。

プロジェクト管理 ページの先頭へ

../process/workflow/ovu_mgm.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト管理では、目標の達成、リスク管理、制約の克服などの間でバランスを取りながら、顧客 (ソフトウェアの開発費用を払う当事者) やユーザーのニーズを満たす製品を納品することが必要になります。ユーザビリティ エンジニアリングの観点から、最も重要な作業は作業: プロジェクト組織と要員配置の決定です。この作業では、組織構造、外部インターフェイス、役割と責務を定義します。ここでは、ユーザーを開発プロセスに参加させる範囲も定義します。また、開発者にユーザビリティ エンジニアリングの経験が必要かどうかも決定します。

環境 ページの先頭へ

../process/workflow/ovu_env.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません環境の基本ワークフローには、プロジェクトや組織が従う開発プロセスの定義が含まれます。../process/activity/ac_devca.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません作業: 開発個別定義書の作成 (../process/artifact/ar_devcs.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: 開発個別定義書) では、適用するユーザビリティ エンジニアリング技術を定義し、これらの手法を組み込むために RUP のさまざまな成果物や作業をカスタマイズする方法を定義します。

その他の重要な作業として、../process/activity/ac_dvlprjspcgdl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません作業: プロジェクトのガイドラインの準備があります。この作業では、ユーザー インターフェイスのガイドラインを含む../process/artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません成果物: プロジェクト固有のガイドラインを作成します。これらのガイドラインは、ユーザー インターフェイスの一貫性を維持するのに役立ちます。これにより、使いやすさが大きく向上します。ショートカットのガイドライン、「取り消し」機能、わかりやすい終了、モードのないやり取りなど、使いやすさに関する原則もここで把握します。

反復的開発とフェーズ ページの先頭へ

RUP のソフトウェア ライフサイクルは、時間に沿って 4 つの連続したフェーズに分解できます。各フェーズは基本的に 2 つの主要なマイルストーンに挟まれた期間で、主要なマイルストーンが達成された時点で終了します。各フェーズの終わりには、評価 を実施し、フェーズの目標が達成されたことを確認します。満足のいく評価が得られたら、プロジェクトを次のフェーズに進めます。

各フェーズには、複数の反復があります。各反復は、実行可能な製品のリリース (内部リリースまたは外部リリース) を成果物とする完全な開発ループです。これらのリリースは開発中の最終製品のサブセットであり、ひとつの反復を経るごとに徐々に成長して、最終的なシステムへと展開していきます。この反復的な手法は、使いやすさに対して有効です。早期の段階でユーザーが使いやすさについてのフィードバックを返すことができ、ユーザーのニーズに一致しない状況にまで作業を進めることを避けられます。

ユーザーは各反復に参加し、要求の洗練、設計概念の評価、概念検証プロトタイプとシステムの進展の両方に関する使いやすさのテストおよび評価を行いますます。

次に、使いやすさに関連する各フェーズの完了条件と、各フェーズの主な作業について説明します。

方向づけ ページの先頭へ

方向づけフェーズの主な目標は、次の 2 つです。

  • プロジェクトのソフトウェア開発範囲と境界条件の確立。これには、運用上の開発構想、検証条件、製品の仕様などの決定が含まれます。
  • システムの成否を左右する重要なユース ケースの抽出。主要な設計のトレードオフを検討するために役立つ、主要なシナリオを抽出します。

ユーザビリティ エンジニアリングの観点からは、次の点に関する要求とビジネス モデリング作業を重視することを意味します。

  • ユーザーとそのニーズの理解
  • ユーザーに最大の利益を提供するユース ケースの識別

また、方向づけフェーズは、概念的な設計や概念検証プロトタイプを調査する機会でもあります。特に、プロジェクトの主なリスクがユーザー インターフェイスや使いやすさに関連する場合は、よい機会になります。使いやすさのテストは、ユーザー インターフェイスの試作や実行可能形式のプロトタイプが完成すると同時に開始します。テストには、使いやすさに関連する../process/workflow/test/co_perfo.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません性能テストも含まれます。

推敲 ページの先頭へ

RUP は反復的なプロセスであり、方向づけで作成された成果物はユーザーによる再考とレビューを受けます。これにより、開発範囲が管理され、開発中のシステムがユーザーのニーズを満たすことが保証されます。

推敲フェーズでは、ソフトウェア アーキテクチャに重点を置きます。これには、ユーザー インターフェイスのアーキテクチャも含まれます。概念的なユーザー インターフェイスが定義され、ユーザー インターフェイス設計の重要でリスク性の高い要素が実装されます。ソフトウェア アーキテクチャに関連する作業は、一般的にユーザー インターフェイスに適用されます。評価が必要な既存の製品、再利用の考慮、メカニズムとパターンの選択などがあります。

このフェーズでは、分析と設計の基本ワークフロー作業のサポートと共に、ユーザー インターフェイス設計作業を重視します。推敲の完了には評価可能なシステムを構築することが必要であるため、実装とテストにも関係があります。

使いやすさのテストと使いやすさに関連する../process/workflow/test/co_perfo.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません性能テストでは、補足仕様書で把握されたリスク性の高い要求や、../webtmpl/templates/req/rup_ucspec.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんユース ケース仕様書の「特殊な要求」として表された要求に注目します。

作成 ページの先頭へ

作成フェーズでは、より多くのユース ケースを実装することに重点が置かれます。これには、ユーザー インターフェイスの概念モデルや../process/artifact/ar_projspecgls.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんプロジェクト固有のガイドラインで把握されたユーザー インターフェイス ガイドラインに沿った、ユーザー インターフェイスへの追加が含まれます。新しい機能が追加された場合は、使いやすさのテストが重要です。

各反復でどの機能を実装するかは、ユーザーの価値観に基づきます。

移行 ページの先頭へ

移行フェーズの焦点は、../process/workflow/ovu_dep.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しません導入の基本ワークフローに移っていきます。ユーザー指向の開発作業では、移行フェーズまでにユーザーを参加させます。ただし、ユーザーの関与は、これまでどおり主にフィードバックを返すことです。ユーザーが開発を通じて参加している場合、正式なベータ テストや受け入れテストは小規模なものになるか、実行されないことがほとんどです。開発作業の全体を通じて、詳細なユーザーのフィードバックや承認が行われます。

トレーニング教材やシステムのサポート資料の作成は移行フェーズで完成させますが、可能な場合は、ユーザーのフィードバックを得るために、より早いフェーズで開始しておきます。

移行では、エンドユーザーが使用可能な稼働システムが存在します。移行では、少なくとも 2 ~ 3 回の反復を計画して、初期リリースで発生した問題を修正し、主要なユーザー フィードバックを組み込むことができるようにします。



Rational Unified Process   2003.06.15