更新日：
1. ユーザビリティ基礎講座を振り返る
ユーザビリティ基礎講座も、今回が最後になる。最後の講座に入る前に、まず、これまでの流れを振り返って見る。第1回は、『使いやすさのガイドライン』を活用するということで、ユーザビリティを向上させるための基本原則について触れた。同時に、ユーザビリティを向上させるために、デザインガイドラインを製品開発にどのように組み込んでゆくかを解説している。第2回は、『操作や表示の一貫性が分かりやすい製品を生む』として、ユーザビリティを実現する上で、最も重要な概念である『一貫性』の実現の仕方を解説した。第3回では、『ユーザーの操作に反応を返す的確なフィードバックが重要』と題して、ユーザビリティの向上を目指す要因として重要にもかかわらず、あまり配慮されることが少なかった『フィードバック』にフォーカスした。第4回は、『「スタイル・ガイド」の運用や設計のコツに気を配る』というテーマで、設計上のヒントをまとめている。第5回は、『チェックリストを用いた評価』ということで、それまでのデザインガイドラインを応用して、デザイン評価のためのチェックリストの作り方と運用について解説している。
以上の解説を通じて、読者のユーザインタフェース設計において、有効な情報が得られたとすれば幸いである。これまで解説してきたデザインガイドラインは、ユーザインタフェースの設計の『仕方』を示すものではなく、平たく言えば、ヒント集に近いものである。実際は、プロジェクト間で共有すべきルールとして、プロジェクト内や製品ラインナップのユーザインタフェースの整合性を保つことに重きがある。
一方、実際のユーザインタフェース設計では、種々の困難に直面する。デジタルカメラを例にしてみれば、新たな機能をどうようにして定義し、それらの重みづけをどうするのか、さらに、決めた機能をグラフィカルユーザインタフェースやソリッドユーザインタフェースにどのように配分するのか、シーン設定はいくつまでが妥当か、というような課題は、毎回の開発において直面するであろう。こういった課題に対して、デザインガイドラインは、直接的な解答は出せない。実際は、これらは作り込みの中で、決められてゆくものである。そうであるならば、ユーザインタフェース設計は、ケースバイケースであり、これ以上、マネージメント不能ということになる。しかしながら、現在は、この作り込みをガイドする、プロセスガイドラインという考え方がある。ユーザビリティ基礎講座を締め括るにあたって、ユーザビリティを高めるための、次のステップを示す意味で、今回は、ユーザビリティにおけるプロセスガイドラインである、人間中心設計プロセスについて解説したい。
2. 開発プロセスを方向づけるガイドライン
2-1. ISO13407について
ユーザビリティを高めるための設計プロセスは、人間中心設計プロセスと言われる。人間中心あるいはユーザー中心という言葉は、従来から使われてきた言葉であり、企業中心という考え方のアンチテーゼとして使われてきた流れがある。そのため、経営理念上の考え方として理解されていることが多く、その検証として、顧客満足調査によって評価するというアプローチが想定される。しかし、ここでの人間中心設計プロセスは、具体的な作り込みに関するアプローチまでブレークダウンしているものである。このプロセスは、1999年にISO13407 Human-centred Design Processes for Interactive Systems （JIS Z 8530:2000 − インタラクティブシステムの人間中心設計プロセス）として国際規格化されている。この詳細なプラクティス事例としては、ISO 18529: Ergonomics - Ergonomics of human-system interaction - Human-centred lifecycle process descriptionsがある。
まず、このプロセスの基本的な考え方しては、(1)ユーザーが積極的に開発プロセスに参加し、ユーザーとそのタスクによる要求を明確に理解すること、 (2)技術一辺倒による自動化ではなく、ユーザーが行うべきことと、システムがするべき役割を適切に配分すること、(3)設計と評価のプロセスを適切に繰り返すこと、(4)設計者だけなく、企画、意匠、営業などの複数の部門との協働によって設計をすすめること、の4つの点を指摘している。
では、人間中心設計プロセスとは、何を意味しているのか。これは、図1のような4つのプロセスを意味している。このプロセスは、ソフトウェア工学利用される場合と同じ意味であり、一連の活動の集合を意味している。一般的に使われるプロセスには、手続きという意味合いが含まれるが、ここでのプロセスは、手続きではなく、それぞれのプロセスの順番は規定されていない。
図1：人間中心設計プロセス
Human-centred Design Processes for Interactive Systems（JIS Z 8530:2000 − インタラクティブシステムの人間中心設計プロセス）
それでは、それぞれのプロセスを概観してみる。
まず、『人間中心設計の必要性の特定』では、開発プロジェクトを遂行するにあたって、人間中心設計プロセスを採用することをプロジェクトマネージャーが確認することから始まる。その上で、一般的には、『利用状況の把握と明示』に関するプロセスから実施する。ここでの利用状況とは、ユーザー、タスク、組織環境及び物理環境を指している。これらを明確にした上で、想定される要求事項を整理する。『ユーザーと組織の要求事項の明示』では、いわゆる仕様を作成するプロセスである。仕様は、フェーズによって、目的、詳細さが異なるが、ユーザインタフェース設計に関しては、要求仕様とユーザインタフェース設計仕様が直接関係する。『設計による解決策の作成』では、仕様に基づいて設計案を作成するプロセスである。仕様の詳細さによって、様々なプロトタイプやモックアップにすることによって、可視化することができる。『要求事項に対する設計の評価』は、前プロセスにある、仕様に基づいて、設計案を評価することを意味している。これも、フェーズに応じて、様々な評価法がある。
2-2. インターフォンのユーザインタフェース設計プロセスを例にして
それでは、実際に、訪問者の情報を記録できる、一般家庭向けのディスプレイ付きインターフォンのユーザインタフェース設計プロセスをISO13407によった場合にどのようになるかを辿ってみる。
2-2-1. インターフォンの利用状況を分析し、要求を明確にしてゆく
このプロセスでは、システムが利用される状況を分析して、ユーザインタフェース設計上の制約条件を明確にする。
まずは、ユーザインタフェース開発目標を明確にして、開発サマリーを文書化し、共有するところから始める。ここでは、既に開発コンセプトが決まっていると想定できるので、それに関係するマーケティングや技術情報を整理、何を訴求点にするかを明記する。例えば、今回であれば、玄関ユニットを通じての送られてくる情報を室内ユニットに記録できることを訴求機能としてみる。
サマリーが確認された段階で、インターフォン（システム）に関わるユーザーグループを明確にすることから始める。マーケティング活動が事前に終了されているならば、対象ユーザーのセグメンテーションの情報があると考えられる。それに基づいて、ユーザーグループを想定する。この場合は、ユーザグループは、利用する家族と住宅のタイプを想定するのが一般的であろう。ユーザーグループを特定することによって、その特性による要求事項を整理しておく。例えば、高齢者が利用するのであれば、基本的な機能はマニュアルなしに、すぐに使えるようにしなければならないなど、すぐに思いいたる。このユーザーグループをさらに具体化して、具体的な人格を付与したペルソナというものを設定する方法もある（図2）。これによって、要求事項を詳細に想定してゆくことができる。
図2：ペルソナの例
ペルソナは、想定されるユーザグループの中から代表とされるユーザ像について、リアルな人物像を想定したものである。適切なペルソナを設定することによって、より具体的な要件が明確になる。
また、この段階で、ユーザーグループごとのリスクを見積もってゆくことも大事である。システムを利用する際に、想定される危険性について明示しておくことが重要である。
そして、ユーザーグループが特定された段階で明確にしなければならないのがユーザー目標とそのためのタスクである。タスクとはユーザーがある目的を達成するために行うべき行動のことである。
さて、このようなユーザやタスクに関する情報は、想像によって記述することも可能であるが、実際の利用状況を調査・分析することによって本質的な情報が得られる。この調査・分析の手法は、心理学や社会学が応用される、極めて重要な活動であるが、今回のシリーズのテーマを超えるため省略する。さらに詳細な情報が必要であるならば、『ユーザ工学入門（黒須正明 他、共立出版）』の一読をお勧めする。
2-2-2. 基本的なユーザインタフェース仕様を決める
ここでは、ユーザインタフェースの仕様作成を行うフェーズである。まず、基本的な機能要求を抽出し、要求仕様を定義することから始める。
機能要求を抽出するには、前フェーズで収集したユーザーの利用状況を整理しながら特定することから始めると良い。企画提案で出される要求仕様には、単なる要求機能がリストされることも少なくないが、その背景をトレースするために、ユーザーグループから想定される機能、利用状況を規定する物理環境、社会環境、技術環境から想定される機能を整理してゆく。インターフォンの対象ユーザーを考えると、子供の場合や高齢者については、意識して要求される機能を検討する必要があろう。また、今回の物理環境では、室内ユニットを置かれる場所、玄関ユニットが置かれる場所。そして、これに関連する機器の存在−たとえば電話やFAX、TV等が想定できるが、これらが、それぞれの環境に置かれた場合の要求を整理する。社会環境であれば、家族構成や家族関係、セキュリティへの要請、ご近所との関わりなどから想定される機能が整理される。技術環境情報は重要であり、今回は録画機能を訴求点にしているので、これに関する情報を適切に収集し、想定しなければならない機能を明確にする。
また、前のプロセスで特定したタスクについてのタスクシナリオを吟味する。想定されるユーザーがどのようなシーンで、どのような文脈で、タスクを行うかを表現したものである。より具体的に記述することが望ましい。このタスクシナリオが、実際のユーザインタフェースの操作の流れの基本となる。図2は、タスクシナリオをグループで議論しているものである。
図3：タスクシナリオのグループでの吟味の例
2-2-3. 基本的な設計案（プロトタイプ）を開発する
設計案は、前プロセスの仕様を受けて検討する。まずは、前述までに明確になったタスクや機能からユーザインタフェースのコンセプトを特定することから始める。例えば、今回のインターフォンであれば、ユーザ特性などから『家族の誰でもマニュアルなしで簡単に操作できる』、『間違えても危険度が高い方向にならない』などを想定できる。このコンセプトの有効性については、外部の専門家によって、検証してもらうのが望ましい。
次に、タスクシナリオを基に、基本的な操作の流れを特定する。また、機能分析や構造化を通じて、操作オブジェクトやモードを特定してゆく。そして、ソリッドユーザインタフェース(SUI)とグラフィカルユーザインタフェース（GUI）への割り振りを決め、おおまかな基本的な画面の構成と操作手順を決定してゆく。
この設計案の妥当性の確証を得るために可視化する必要がある。この段階では、詳細なものを構築するよりも簡易なプロトタイプとしてまとめる。プロトタイプは、文章による利用シナリオ、絵コンテ、ペーパープロトタイプなどバリエーションに富むが、大切なことは、評価の際に、設計課題に焦点するように、適切な詳細度が求められる。
2-2-4. プロトタイプを評価する
前述のプロトタイプは、第3者のいるユーザーに評価してもらうのが理想的である。このユーザーは、対象ユーザーグループからの代表者であることが望ましい。設計案のプロトタイプを提示して、基本機能の振る舞いが理解できるか、そして、それを利用したいと考えるかなどを評価してもらう。事前に、評価のための利用シナリオが準備される必要がある。
一方、ユーザーにお願いするための時間やコストなどの制約が大きい場合は、ユーザインタフェース設計に詳しい専門家によるユーザビリティのインスペクションを行う。一般的には、ヒューリスティックに問題出しを行う場合と、ユーザーのタスクの流れに応じて、詳細に問題点を洗う方法がある。
2-2-5. ユーザインタフェース仕様の詳細化をする
プロトタイプの評価結果を受けて、ユーザインタフェース仕様の改善や、詳細化が進められる。評価と設計が繰り返されながら、画面レイアウト、オブジェクト、パーツ、フォント、文字などの仕様が決められてゆくことになる。
2-2-6. ユーザインタフェース設計案を詳細化する
最終的な仕様が決まってくると、その振る舞いを、汎用的なオーサリングツールなどを利用したシミュレーションを作成することができる。これらの汎用的なもの以外に、状態遷移を検証するためのシステムが市販されている。
2-2-7. シミュレーションを利用してユーザテストを行う
ユーザインタフェース設計も最終案に近くなってくれば、実際のユーザによって、妥当性を確認することが望ましい。一般的にユーザビリティテストと言われる評価方法は、ユーザビリティ・ラボと呼ばれる設備（図4）が必要になる。今回のインターフォンの場合は、基本的なインタフェースの画面を作成して、操作オブジェクト応じた応答を、別な場所にいる人間が行うという、オズの魔法使い型と言われる評価方法が有効である。図5は、実際に、オズの魔法使いを利用して評価をしている模様である。
図4：ユーザビリティラボの構成
図5：インターフォンのプロトタイプの評価例
さて、ユーザビリティテストでは、基本的な3つの評価尺度から評価される。これらは、有効性、効率性、満足度の3つの尺度である。
まず、有効性とは、ユーザーが利用する目的を達成できるかどうかを意味する。今回であれば、(1)問題なく基本機能（応対および記録）を利用することができたか、(2)マニュアルを利用して、初期設定を変更できたか、(3)再生機能を利用できたか、などである。
効率性とは、これらの目的を効率的に達成することを意味している。今回の仕様から考えると、基本機能の利用については、マニュアルが無くとも戸惑うことなく利用できること。あるいは、「1秒以内に」機能を終了できるなど、定量的な尺度も重要である。
最後に、満足度とは、主観評価の総称である。ユーザーが利用にあたって、どのように感じていたのかを示すことである。満足の他に、戸惑ったこと、楽しかったことなど、ユーザーの思ったこと、考えたことをアンケートやインタビューによって聞き出す。
さらに、ユーザビリティ評価については詳細に知りたい方は、『ユーザビリティテスティング（黒須正明 他、共立出版）』を参照いただければと思う。巻末には、サポートをしてくれる機関名も記述されている。
2-2-8. ユーザインタフェース仕様書を作成する
評価を受けて最終的な改善を加えて、最終的なユーザインタフェース仕様書が作成される。これは、画面遷移図、画面指定図、パーツレイアウトおよびデザインなどによって構成される。
以上、インターフォンのユーザインタフェース設計のプロセスを例に、ISO13407を基にした人間中心設計プロセスについて解説した。このプロセスを図示したものが図6である。ISO13407は基本的なプロセスを定義したものであるので、この図のように、それぞれの開発プロセスに合わせて、プロセス基準を作成することが望ましい。これによって、開発プロジェクトにおいて何をすべきなのかが理解できる。開発よって得られるノウハウなども、プロセスに応じて管理してゆくことができる。これまでの講座で解説してきたデザインガイドラインは、このようなプロセスガイドラインの下でマネージメントされることが有効である。
図6：人間中心設計プロセスによるインターフォンのユーザインタフェース設計プロセス
3. プロセスの制度化を目指して
ユーザビリティ基礎講座の最終回にあたり、これまでのデザインのためのガイドラインに加えて、プロセスガイドラインについて解説してきた。組織的、戦略的にユーザビリティの向上を考えるのであれば、人間中心設計プロセスを導入し、適切なプロセスマネージメントが必要になる。これは、組織に定着化させるために、最終的には、開発ライフサイクルの中に制度化する必要がある。
製品開発におけるユーザビリティ活動は世の中のトレンドに合わせた一過性のアプローチでは、知識が組織に内在化されない。外面的なユーザインタフェースの問題と認識してしまうと、国際的競合の中に、数年内に追随できなくなることは必至である。長期的な展望のもとに、ユーザビリティをマネージメントする仕組みを構築することは経営戦略上、避けがたい課題である。
その上で、設計者の教育訓練、各種手法の開発管理、ソフトウェア工学の管理手法の統合化など鋭意進められる必要がある。特に、ユーザビリティを高める設計を実装できる技術者の教育訓練の要請は、急を要するものと実感される方も少なくないと思われる。これに対して、現在のところ、明確なカリキュラムを持つ大学はほとんどない。文科省の知的クラスタ創成事業の一貫して行われている札幌ITカロッツェリア（http://www.it- cluster.jp/index.html）プロジェクトでは、組込みソフトウェア技術者のための教育事業を展開した（図7）。
図7：札幌知的クラスタ ユーザビリティ教育支援事業の構成
また、昨年、2005年には、国内のユーザビリティ活動を支援するための団体である、NPO法人『人間中心設計推進機構』（http: //www.hcdnet.org/）が設立された。これは、国内のユーザビリティ関係者が参集し、行政や民間のユーザビリティ課題に対して、研究、規格・認定、受託業務、社会化、教育の事業を通じて、支援する団体である。このNPOは、個人単位、企業単位ごとの教育事業を推進するとともに、ユーザビリティ技術に関する資格認定制度を検討している。
欧米と比較すると、ユーザビリティに関するスキルを高めるための社会基盤は、まだ、整備されているとは言えないが、着実に環境はされつつある。今回の基礎講座によって、ユーザビリティに関する関心を広げていただき、支援環境へアクセスしていただくきっかけとなっていただければ、望外の喜びである。
（第6回・おわり）
