ユーザー中心の設計 (UCD) は、使いやすいアプリケーションを設計するための方法論として一般に広く受け入れられているもので、それを使用するユーザーの必要性を真に満たすソフトウェアを作成します。今回の記事では、2回シリーズの第2回として、さまざまなタイプのプロジェクトで、非常に役に立つと思われる設計作業について説明します。すなわち、ベンダー・アプリケーションの選択、現行アプリケーションの拡張、現行アプリケーションの書き直し、および新規アプリケーションの開発を取り上げます。第1回記事 では、設計と評価の中心的な作業について説明しました。これらの作業について不慣れな場合は、第1回記事からお読みになることをお勧めします。ではまず、プロジェクト・タイプ毎に、どの作業がもっとも有用なのかについて見ていきましょう。

プロジェクト・タイプ別の設計の進め方

次の表は、いくつかの一般的なプロジェクト・タイプに対して、推奨される作業セットを示したものです。ベンダー・アプリケーションでは、ベンダーの選択を援助する作業と、トレーニングやサポートが適切であるかどうかを検証する作業に焦点が当てられます。最も普通のプロジェクト・タイプ、つまり現行アプリケーションの拡張では、新規機能のシームレスな統合を援助する作業に焦点が当てられます。現行アプリケーションの書き直しでは、環境内での統合とユーザビリティー問題の解決に焦点が当てられます。最後の新規アプリケーションでは、ユーザー要件を定義し実現する作業と、競争に勝つ作業に焦点が当てられます。

これらの各プロジェクト・タイプについては、後で詳しく説明します。

ベンダー・アプリケーション

ベンダー・アプリケーションの場合は、重要な情報は、ベンダー・アプリケーションの選択の時点で手に入ります。トレーニング/サポートに関する情報、またビジネス要件やユーザーの要件を満たすために、どのようなカスタマイズが必要になるかを判断するのに必要な情報です。この判断を行うための有用な情報を提供する作業として、ヒューリスティック手法があります。ヒューリスティック手法では、さまざまな領域の情報が提供されます。すなわち、既存のユーザー・インターフェース (UI) ガイドラインへの準拠、標準および慣行、UI内での一貫性、ユーザー・タスク・サポートおよび情報、言語サポート、アクセシビリティなどの領域です。これらの情報は、迅速に収集できます。特定のベンダーを選択したら、作業の焦点は、2つ または3つの領域で役に立つ情報の収集に移ります。例えば、ユーザー・トレーニング/サポートの領域や、ベンダー・アプリケーションをカスタマイズするための要件 (可能なUI再設計を含む) などです。

通常、ベンダー・アプリケーションは、類似したタスク・セットを実行するための既存の手順やアプリケーションに取って代わります。ユーザーとタスク・セットが比較的安定している場合は、既存のオーディエンスとタスク情報を使用できます。ユーザー・データやタスク・データが存在しない場合は、オーディエンス定義やタスク分析を通してそれらのデータが収集されます。データは存在するが、ユーザーまたはタスク・セットが変更中である場合は、オーディエンス定義とタスク分析作業では、既存のデータの補充に焦点が当てられます。一般に、ビジネス・プロセスを変更すると、タスク・セットも変更されます。したがって、タスク分析を完了するには、新規ワークフローに対する何らかの分析とモデリングが必要になります。

カスタマイズを必要としないベンダー・アプリケーションの場合は、アプリケーションの設計が行われないため、ユース・ケース・モデル、設計プロトタイピング、およびUI仕様の作成は行われません。残りの作業としては、ユーザビリティー妥当性テストが考えられます。この作業では、ユーザー・トレーニング/サポートに役立つ情報 (ヒューリスティック手法の対象外) を収集します。この場合ユーザーは、テスト環境でアプリケーションのタスクを実行するよう要求されます。客観的データと主観的データが収集されます。アプリケーションのためのトレーニングが行われたり、トレーニング資料が用意されている場合は、それらがテストに加えられ、その効果が、トレーニングを伴う場合と伴わない場合のタスク・パフォーマンスの対比で評価されます。アプリケーションとトレーニングの改善できる領域を明確化し、それを必要事項としてベンダーにフィードバックすることができます。トレーニング資料やコースも、検出された問題に基づいて補足されます。最後に、アプリケーションで問題が発生した場合は、問題と解決策を文書化し、ユーザーが使用できるように社内サポートに渡すことができます 。

カスタマイズが必要なベンダー・アプリケーションの場合は、既存のユース・ケース・モデルやUI仕様を変更したり拡張したりしなければならないことがあります。カスタマイズが広範囲にわたる場合は、ユーザーがUIの変更をプロトタイプ化して評価しなければならないことがあります。カスタマイズが小規模の場合や、アプリケーションのカスタマイズにコーディングがほとんど、あるいはまったく必要ない場合は、実際のアプリケーションを使用するユーザビリティー評価のほうを採用し、プロトタイピングを省くことができます。

現行アプリケーションの拡張

現行アプリケーションの拡張の場合は、重要な情報を入手し、それを使用して、新規機能をサポートするアプリケーションを拡張したり、いくつかの既存の問題を解決したりできます。現行アプリケーションに対して適切な設計/評価の作業を行うと、オーディエンス定義、タスク/ワークフロー・データ、および評価/テスト結果情報が生成されます。新規オーディエンス・メンバーに関する情報の収集が必要になります。タスクおよびワークフロー・データを更新して、統合する新規機能を組み込む必要があります。そのためには、タスクが現在どのように実行されているか、また拡張により、タスクが新規機能でどのように実行されるか、などについて多少の分析が必要になります。ワークフロー・モデリングの場合は、新規機能を追加するときに、アプリケーション内にコヒーレント・モデルが入っていることを確認するのを忘れないでください。

現行アプリケーションに対して適切な設計/評価の作業を行わなかった場合は、通常、オーディエンス定義、タスク分析、ヒューリスティック手法などの作業が実行されることになります。オーディエンス定義では全体的な再検討が必要になりますが、現行アプリケーションに追加する新規機能については、新たに定義を行わなくてもよい場合があります。統合する新規機能の種類が主たる要因となって、タスク分析作業が、新規機能だけに焦点を当てるものでよいか、あるいはもっと網羅的な分析を行う必要があるかが決まることがあります。新規機能が比較的独立したものであれば、タスク分析作業は、主に、新規機能とその統合にだけ焦点を当てればよいかもしれません。場合によっては、新規機能がアプリケーション全体に分散していることがあります。このような場合、タスク作業はアプリケーション全体が対象になります。ヒューリスティック手法の作業は、他と切り離された変更にも配布された変更にも有効で、新規機能を追加するための変更を行いながら、現行アプリケーションの問題と検討している仕様を識別することができます。

オーディエンス情報とタスク情報を収集したら、コヒーレントUIモデルを検証するためのもう1つのキー・ステップとして、新規機能について反復プロトタイピングと評価を行います。この操作は、新規機能だけに対する何らかのlo-fiプロトタイピングおよびユーザー評価から開始されます。新規機能の基本的な問題が解決されると、焦点は現行アプリケーションとの統合に移ります。基本的な問題が解決されると、hi-fiプロトタイプの構築と評価が行えるようになり、再度新規機能から始めて、焦点を統合へと移していきます。新規のユース・ケースとシナリオを組み込めるように現行のユース・ケース・モデルを更新し、アプリケーションの新規および変更済み機能を文書化します。これにより、ワークフローの変更も反映されます。同様に、UI仕様も更新されて、新規および変更済み機能の設計が反映されます。

開発チームにより新規機能が統合されると、ユーザビリティー・テストが実行され、再度焦点が、新規機能および新規機能の現行アプリケーションへの統合へ移ります。

現行アプリケーションの書き直し

現行アプリケーションの再インプリメントを示す最も卑近な例は、新規テクノロジーへの移行です (例えば、クライアント/サーバー・アプリケーションをWebへ移行する)。このプロセスでは、アプリケーションを新規環境で問題なく機能させることに主眼が置かれますが、既存の問題を解決するための好機でもあります。現行アプリケーションに対して適切な設計/評価の作業が実行されていれば、オーディエンス定義、タスク/ワークフロー・データ、およびテスト結果情報が生成されます。新規オーディエンス・メンバーに関する情報を収集する必要があります。収集しない場合は、現行データを使用することができます。タスクおよびワークフロー・データを更新して、統合する新規機能を組み込む必要があります。テスト結果では、新規設計で解決しなければならない主要な問題が提示されます。

現行アプリケーションに対して適切な設計/評価の作業を行なわれていないと、多くの場合、オーディエンス定義やタスク分析などの作業が必要となります。オーディエンス定義とタスク分析作業は、新規インプリメンテーションに組み込む必要のあるアプリケーションのすべての部分を網羅します。アプリケーションを新規テクノロジーへ移行するプロセスでは、現行のUCDデータとは関係なく、現行のUIを調べて、既存のすべての機能が新規UIに組み込まれていることを確認する必要があります。すべてのUIエレメントを新規アプリケーションに配置するか、あるいはすべてのUIエレメントを新規アプリケーションから明示的に除去する必要があります。

オーディエンス、タスク、および現行アプリケーションに関する情報を収集したら、次のステップとして、アプリケーションの設計プロトタイピングと評価をその新規環境で反復実行します。この操作は、何らかのlo-fiプロトタイピングとユーザー評価から開始されます。基本的な問題が解決されると、ユーザーと一緒にhi-fiプロトタイプの反復的な構築と評価が行われます。hi-fiプロトタイプの構築には、通常、汎用プログラミング・ツールが最も有用ですが、このhi-fiプロトタイプが実際のアプリケーションに展開されるのではないという点に注意する必要があります。この作成されたものは、反復評価の結果を素早く反映するために構築された設計プロトタイプであって、実際の配置に耐えるだけの強固さと、メインテナンスのための十分な文書化は望めません。

反復プロトタイピングと評価は、主要な設計問題がすべて解決されるまで続けられます。この時点で、UIで行われた変更の性質と程度によっては、UI仕様を全面的に書き直さなければならなかったり、単に以前のプラットフォームまたは環境と新規のそれとの違いを識別するだけでよかったりします。操作可能なシステムが使用できれば、ユーザビリティー・テストを実行して、残ったすべての問題を明らかにします。反復設計と評価を利用すれば、問題は少なくなり、また比較的小さいものになるはずです。

新規アプリケーション

新規アプリケーションとは、実際に以前存在していなかったアプリケーション、またはプロセスとしてのみ存在していたアプリケーションを言います。新規アプリケーションの場合は、機能の観点からだけでなく、さらに機能をユーザーに提供する方法の点から、ユーザー要件を把握し、それを解決することに主眼が置かれます。市販のアプリケーションの場合は、もう1つの主眼点として、機能と使いやすさをうまく組み合わせることで競争に勝つことが挙げられます。

新規アプリケーションの場合、設計/評価の作業は、オーディエンス、機能、およびユーザビリティーの要件が明確に定義されていることを確認する作業から開始されます。これ自体はUCD作業ではなく、設計チームが参加する作業です。アプリケーションを設計するためには、これらの要件をプロジェクトの早い段階で明示し、プロジェクトの進展に伴って精度を高めながら定義していきます。

要件プロセスでターゲット・オーディエンスが識別されると、設計/評価の作業がそれらの要件に関する情報の収集を開始します。真っ向から競合するアプリケーションが存在していて、オーディエンスが同じ場合は、情報の一部をそれらの競合アプリケーションのユーザーから収集することもできます。さらに、主要な競合他社アプリケーションに対してヒューリスティック手法を行ってみるのもこの種のプロジェクトには非常に有効であり、新規アプリケーションの目的を設定する場合に役立ちます。

該当するユーザーを選択するための十分な詳細度でオーディエンス特性を定義したら、タスク分析作業を進めることができます。要件と同様に、情報内容は、初めは、"広く浅く" です。詳細な情報は、まず、重要なタスクで収集され、最終的には、アプリケーションの影響を受けるすべてのタスクで収集されます。

基本的なオーディエンス/タスク情報を入手すると、概略的な、しかし基礎がしっかりした設計を作成することができます。この作業は通常、一連のスケッチで開始された後、アプリケーションのストーリーボードへ進みます。このストーリーボードは概略的なものですが、通常、重要ないくつかのタスクについては、掘り下げられて記述されます。このことは、設計ウォークスルー作業でこの概念を評価するのに十分な情報をユーザーに提供するという意味で重要です。lo-fiペーパー・ストーリーボードで間に合う場合もあれば、さまざまなツールを使ってエレクトロニック・ストーリーボードを作成する場合もあります。

lo-fiアプローチは、多くの場合、概念の初期検証に使用されますが、その後で、いずれかの電子ツールを使ってより精度の高いバージョンを構築すれば、それをより広い範囲のオーディエンスに配布して検証することができます。これがhi-fiプロトタイプへの第一歩ですが、通常は、せいぜい2回ぐらいまでしか繰り返しません。それは、簡単に変更したり適応したりできるhi-fiプロトタイプを作成することがあまりにも難しいからです。このため、hi-fiプロトタイプを開発する際は、迅速な開発と変更が可能なツールを使用します。そうすることにより、設計はユーザー・インプットをもとに容易に展開できます。ユーザーは、新しい領域を追加したり古い領域を作り直したりしながら、設計プロトタイプを評価します。

設計が安定化し始めると、作業は2つの作業へ進むことができます。1つはユース・ケース・モデルで、ワークフロー・モデリングおよび、アクターやユース・ケースの正式な記述を使用して早期に開始されます。UI設計のエレメントを参照するシナリオに最終詳細データを追加することができます。もう1つは、UIのすべてのエレメントを文書化したUI設計仕様です。正式なユース・ケース・モデルとUI設計仕様の文書は、アプリケーションを合理的に拡張する際の重要なエレメントです。要求された変更は、これらの2つの文書に照らし合わせて表現されます。

UI設計仕様とユース・ケース・モデルが完了すると、アプリケーションの開発へ進みます。操作可能なバージョンのアプリケーションが使用できるようになると、設計妥当性テストが実行されます。このテストには、アプリケーションでキー・タスクを実行する実際のユーザーが参加します。客観的データと主観的データを収集し、それらを使用して、このプロジェクトの初期の段階で設定した目的に照らし合わせてアプリケーションを評価することができます。

上に戻る

結論

このシリーズの第1回記事では、広範囲のアプリケーション開発プロジェクトにまたがって最も役に立つ設計/評価作業の中心部分を取り上げて説明しました。このリストには、オーディエンス定義、タスク分析、ヒューリスティック手法、ユース・ケース・モデリング、反復設計と評価、設計仕様、およびユーザビリティー妥当性テストが含まれています。

この第2回記事では、アプリケーションの設計と開発で頻繁に行われる4つのプロジェクト・タイプについて説明しました。これらのプロジェクト・タイプには、ベンダー・アプリケーション、現行アプリケーションの拡張、現行アプリケーションの書き直し、および新規アプリケーションが含まれます。これらの各プロジェクト・タイプは簡単に見分けられ、それぞれ設計/評価作業に関する固有な難題と機会とを持ち合わせています。プロジェクト・タイプを識別すると、推奨されるフォーカス・アイテムを使用して、必要かつ十分な設計/評価作業を定義することができます。定義した設計/評価作業をプロジェクトに適用すれば、有用で使いやすいアプリケーションが作成されます。

参考文献

• IBMから提供されるUCDや関連サービスの詳細については、IBM Ease of Use Webサイトにアクセスしてください。
  
  
• Constantineおよび Lockwoodの使用法中心の設計に関する考え方について詳しくは、2人のWebサイト にアクセスしてください。
  
  
• アクセシビリティ問題の詳細については、IBM Accessibility Center（日本語サイト「IBMのアクセシビリティへの取り組み」）にアクセスしてください。ここでは、身体に障害のある人たちのための製品およびサービス情報も提供されます。
  
  
• 最後の参考文献は、Usability Professionals Association Webサイトです。ここには、単にユーザビリティー・プロフェッショナル用だけでなく、ユーザビリティーに関する詳しい情報を見つけたいと考えている人のための情報や参考文献も収められています。
  
  

著者について

Lynn Percivalは、18年間以上にわたりIBMのヒューマン・ファクター・エンジニアとして、各種のIBM製品、アプリケーション、およびWebサイトの設計と評価を担当してきました。技術領域としては、ネットワーク管理、アプリケーション開発および構成管理ツール、ヘルスケア・クリニカル情報システム、Webサイト・インフラストラクチャーおよびツール、オンライン教育デリバリーおよび管理などがあります。現在は、RTP, North Carolina, for IBM Global Services User-Centered Design Servicesで働いています。ルイビル大学で実験心理学の博士号を取得。氏のEメール・アドレスはpercival@us.ibm.com です。

Jack Scanlonは、この15年間にわたり、IBMのヒューマン・ファクター・エンジニアとして働いています。氏は、さまざまなアプリケーションの設計に携わってきました。例えば、ネットワーキングおよびワイヤレス・ソフトウェア、アプリケーション設計および開発ツール、ヘルスケア・クリニカル情報システムなどがそれです。現在は、RTP, North Carolina, for IBM Global Services User-Centered Design Servicesで働いています。アリゾナ大学で実験認知心理学の博士号を取得。氏のEメール・アドレスはscanlonj@us.ibm.com です。

この記事を評価する

コメント

上に戻る

目次

• プロジェクト・タイプ別の設計の進め方
• 結論
• 参考文献
• 著者について
• コメント