ユーザーインタフェース設計の指針と方法

ユーザーインターフェース設計の指針と方法

要求仕様の設計

1

-1

1-2

要求仕様の設計

ユーザーインターフェース設計の指針と方法 First Edition

要求仕様の設計

1

-1

ユーザーインターフェース設計の指針と方法 初版 制作 ヒューマンインターフェースラボ

© 1995 by Sony Corporation

1-2

要求仕様の設計

本書の位置付け

「ユーザーインターフェース設計」 という言葉は、 ゼロックスのパルアルト研究所で、 Altoという 名前のコンピューター研究から生まれたと言われている。 つまり、 その考えかた自体がたいへん 新しい設計の分野である。 現在、 ユーザーインターフェース設計の現場では、 「押しにくいボタンだ」 「 、わかりにくいメニュー 構造だ」 「 、操作のフィードバックが遅い」 など様々な問題が議論されているが、 それらは実は人間 工学の問題であったり、 認知科学の問題であったり、 さらには集団的な価値観の問題であったり している。 つまり、 このような個々の問題を、 ユーザーインターフェース設計の問題、 すなわち 「使い やすさの設計問題」 として、 ひとく く りにとらえてしまいがちであり、 このことがユーザーインターフェー ス設計を困難にしている第一の原因である。 このような事態にいたる背景には、 ユーザーインターフェース設計自体、 歴史が浅いため、 問題 定義の枠組みがはっきりしていないということが考えられる。 そのため、 ユーザーインターフェース 設計においては、 設計問題の定義の仕方を確立することが早急であるという結論に至った。 本書 「ユーザーインターフェース設計の指針と方法」 では、 ユーザーインターフェース設計の問 題定義の仕方を中心に展開した。 具体的には、 ユーザーインターフェース設計の一連の設計プ ロセスを明らかにし、 個々のプロセスでの問題の定義の仕方を示すことにより、 目前にある設計問 題がユーザーインターフェース設計において何の問題なのかがわかることを目的とし、 さらにそ の解決の方向を示した。 すなわち本書では、 図1に示した考え方のレベルおよび一般的な解決 手法・ツールの提示を行った。 また本書ではユーザーインターフェース設計の現場で使用されるガイドラインやノウハウに関 しては踏み込まなかったが、 その理由は、 ガイ ドラインやノウハウは個々の対象製品カテゴリーに 特化した形でまとめるべきであり、 それらをひとつに集約したものは一般化せざるを得ず、 結局は 実用的でなくなってしまうためである。 なお、 本書はユーザーインターフェース設計プロセス研究の成果をもとに編集されており、 研究 の成果に応じて改訂版を発行していく予定である。

高い 考え方

概念的

手法・ツール

一般的

ユーザーインターフェース 設計の指針と方法

ガイドライン

ノウハウ

抽象度

実用的

低い

図1 本書の位置付け

要求仕様の設計

1

-1

1-2

要求仕様の設計

目次 1章 要求仕様の設計

はじめに

........................................................................................................... 1-1

プロジェクト開始（企画意図の確認）........................................................................ 1-2 要求仕様検討のための準備 ........................................................................................ 1-4 ユーザーの記述 .................................................................................. 1-4 使用環境の記述 .................................................................................. 1-7 制約の記述 ......................................................................................... 1-8 要求の抽出と分析 ....................................................................................................... 1-9 要求の抽出 ......................................................................................... 1-9 要求の明確化 ................................................................................... 1-12 要求の絞り込み ................................................................................ 1-16 要求の構造化 ................................................................................... 1-18 要求仕様の検討 ........................................................................................................ 1-20 機能方策の決定 ................................................................................ 1-20 機能重要度の設定 ............................................................................ 1-22 要求仕様の記述 ................................................................................ 1-23 要求仕様の設計プロセスにおけるアウトプット（まとめ）..................................... 1-26 参考文献 ........................................................................................... 1-28

2章 ユーザーインターフェース設計

はじめに

........................................................................................................... 2-1

ユーザー分析 ........................................................................................................... 2-6 心的情報処理の分析 .......................................................................... 2-8 心理的メカニズムの分析／生理的機能の分析／解剖学的特性の分析 ／社会・集団の価値体系の分析 ...................................................... 2-17 ユーザーインターフェース設計の考え方 ................................................................ 2-19 ユーザーインターフェース設計の設計対象 .................................... 2-19 分析から設計へ ................................................................................ 2-20 ユーザーインターフェース設計の進めかた .................................... 2-21

目次

i

UI コンセプトの決定 ............................................................................................... 2-23 実設計

......................................................................................................... 2-25

利用者案内

......................................................................................................... 2-26

シミュレーション ..................................................................................................... 2-29 評価

......................................................................................................... 2-35

承認を得る

......................................................................................................... 2-37

ドキュメント化 ........................................................................................................ 2-39 ユーザーインターフェース企画書 ................................................... 2-40 ユーザーインターフェース仕様書 ................................................... 2-41 ユーザーインターフェースガイドライン ........................................ 2-43 アイディア出しの支援 ............................................................................................. 2-44 設計プロセスを効率よく進めるために .................................................................... 2-48 設計の進め方 ................................................................................... 2-48 コンセンサスの形成 ........................................................................ 2-52 プロジェクト名を付ける ................................................................. 2-53 あいまいさの削減 ............................................................................ 2-54 会議の方法 ....................................................................................... 2-56 UI 設計者に求められる資質 .................................................................................... 2-58

資料編

パフォーマンス測定 .................................................................................................. D-1 Heuristic Evaluation ............................................................................................... D-3 Cognitive Walkthrough .......................................................................................... D-4 観察法

.......................................................................................................... D-5

プロトコル分析 ......................................................................................................... D-6 インタビュー .......................................................................................................... D-7 質問紙（アンケート）法 ........................................................................................... D-8 グループインタビュー .............................................................................................. D-9 AHP 法

........................................................................................................ D-10

ユーザーの概念モデルの分析手法 .......................................................................... D-11 ノーマンのデザインの7 原則 ................................................................................. D-12

ii

目次

1

要求仕様の設計 ユーザーの要求を分析し、 その要求を具体的な設計課題に変換するために、 機器はどんな機 能を搭載すべきなのか、 またその機能の操作性に要求されることは何かということについて明確 にすることを本書では 「要求仕様を設計する」 とよぶ。 1章では、 この要求仕様の設計プロセスに ついて述べる。

商品企画

ユーザーの要求を分析

設計

出荷

ユーザーインターフェースコンセプトの決定

設計−評価のサイクルを回す

評価

評価

ユーザーの要求を 製品仕様に解釈

U.I デザイン

コンセプト決定

設計

出荷

「答えはいつも問題の中にある。 ほかではみつけられない。 」 M. マクルーハン

はじめに ........................................ 1-1 プロジェクトの開始 .......................... 1-2 要求仕様検討のための準備 ............. 1-4 要求の抽出と分析 .......................... 1-9 要求仕様の検討 ........................... 1-20 要求仕様の設計プロセスにおけるアウトプッ ト （まとめ）..................................... 1-26

要求仕様の設計

1

-1

1-2

要求仕様の設計

はじめに

○

フォン・ノイマンの言葉

○

○

○

○

○

○

○

○

○

○

「何について語っているのかさえわからないようなら、 そのことにつ いて正確さをうんぬんしても意味がない。 」

商品設計とは、 「ユーザーの要求を、 その要求が充足される製品に変換すること」 と言い換える ことができる。 これは逆の見方をすれば、 「ユーザーが何を望んでいるのかわからなければ、 設計 のプロセスがどんなに厳密に賢明に、 また効率的に行われても、 ユーザーを満足させることはで きない」 ということである。 このことは、 ユーザーの要求を分析することがいかに重要なプロセスで あるかを示唆している。 事実、 ユーザーインターフェース設計に関わる困難さの多くは、 要求され ていることは何か、 誰がユーザーなのか、 どのような状況で使われるのか、 などに関する不明確さ にその原因を発見することができる。 設計プロセスに存在するユーザーの要求分析の不明確さ には、 次の2種類がある。 ● 商品に 「要求される」 、 または 「要求する」 ことが不明確。 ● 商品設計の参画者の間で、 要求についての一貫した理解が形成されていない。 これらの不明確さを払拭することが、 要求仕様の設計プロセスが果たすべき中心的な役割と いえる。 さらに、 ユーザーの要求が明確にされても、 それが具体的な設計課題に変換されないと、 設計 に参画する個々のメンバーは具体的な活動に移行できない。 したがって本書では、 要求仕様の 設計プロセスというものを「 、ユーザーの要求を明確にし、 さらにそれを充足するために機器がし

設計課題に変換する

○

○

○

○

○

○

○

○

○

○

○

「設計課題に変換する」 とは、 ユーザーの要求を充足するために、 機 器はどんな機能を持ち合わせるべきか、 またその機能の操作性は どうあるべきかという設計目標 （要求仕様） を示すことをここでは意 味する。 実設計段階ではそれを受けて、 具体的な機構やユーザー インタフェースの設計を始めることになる。

なければならないことは何か （設計課題） ということを示す段階までカバーするもの」 としてとらえ ている。 つまり、 本プロセスの目的は以下の3点に集約される。 ● 商品に 「要求される」 、 または 「要求する」 ことを明確にすること。 ● その要求を具体的な設計課題に変換すること。 ● 要求および変換された設計課題について、 商品設計の参画者の間で一貫した理解を形

参画者の間で一貫した理解を形成するために

○

○

○

参画者の間で一貫した理解を形成するためには、 要求仕様などの 決まったことを常に明文化しておくことが重要である。

成すること。 1章では以上の目的を達成するために、 図1-1のようなプロセスにしたがって、 要求仕様の設 計プロセスに求められる考え方や具体的な方法について解説する。

プロジェクトの開始

企 画 意 図 の 確 認

要求仕様検討のための準備

ユ ー ザ ー の 記 述

使 用 環 境 の 記 述

制 約 条 件 の 記 述

要求の抽出と分析

要 求 の 抽 出

要 求 の 明 確 化

要 求 の 絞 り 込 み

要求仕様の検討

要 求 の 構 造 化

機 能 方 策 の 決 定

機 能 重 要 度 の 設 定

要 求 仕 様 の 記 述

図1-1 要求仕様の設計プロセス

はじめに

1

-1

プロジェクト開始 （企画意図の確認）

目的 プロジェクト開始の前提

○

○

○

○

○

○

○

○

○

○

○

プロジェクト開始前には、 すでに何らかのマーケティングリサーチが 行われ、 「こういう商品を作れば売れる」 という見込みがつけられて いなければならない。

これから設計しようとする商品の企画意図を確認する。 さらにその企画意図をメンバー間で共 有し、 合意を形成することで、 以後の設計プロセスにおける認識のずれを防ぐ。

指針と方法 すべての製品設計には、 ある製品を世に送り出そうとする企画意図が存在し、 その製品の設 計目標は、 以下の一文に要約できる。 ● 製品の設計目標は、 その企画意図を満足することである 設計に参画するメンバーひとりひとりが、 その製品のターゲット市場を知らない、 何をベネフィットと して市場に訴えようとするのかの理解がされていない、 などという状態では、 必ず設計プロセス のある段階で意見の食い違いが生じる。 設計メンバーのベクトルを合わせ、 設計プロセスを効率 的に進めるためには、 プロジェクト開始時にそのプロジェクトの企画意図を確認することが必要 不可欠なプロセスである。 以下にプロジェクト開始時に確認すべき主な情報を示す。

1-2

プロジェクト開始 （企画意図の確認）

項目 商品一般情報

内容 商品名、仕向地、販売予定価格、製造所、販売チャネ ル、このプロジェクトの名前など。

市場背景

商品を導入しようとする市場のこれまでの流れ、現在の 状況や問題点など。

ターゲット市場

商品をどのユーザー、市場に訴求しようとするのか。ま たその市場規模はどれくらいか。

商品コンセプト

ターゲット市場に受け入れられるために、何を訴求する のか。何をベネフィットとして与えるのか。自社の既存 製品や他社製品とは、どのように差別化するのかなど。 ここに記述された商品コンセプトを作りあげることが、 設計の絶対条件となる。

企画目的

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

企画目的

単に利益を得るというだけでなく、 たとえば、 新規市場を開拓する、 マーケットシェアを増大する、 企業イメージの向上など、 その時々に

商品を当該市場に導入する企画目的は何か。企業として の目的にあたる。この目的如何によっては、後の設計プ ロセスにおいて何にウエイトを置くのかが、異なってく

よって微妙に違いがある。

る。最終的には、この目的を達成することが最も重要な 使命となる。 商品の定義

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

商品の定義

商品の本質は何か。何をするものか。メンバーの間で、 商品の本質についての認識のずれがあると、要求仕様に

たとえばビデオカメラの場合、 その定義は 「映像を撮影し、 あとで見 て楽しむことができるもの」 である。

関する合意形成は困難である。設計途中で行き詰まった 時などに、商品の本質に立ち返ることも重要なことであ る。 商品の主な使用目的

ターゲット市場において主にどのような目的で使用され るのか。ここでは具体的かつ代表的な使用例を記述す る。

導入する新しい技術

今回新たに、どのような技術を導入するのか。

参考モデル

自社の前機種／同カテゴリー商品、競合他社商品、その 他参考にできる商品。

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

ユーザーインタフェースを設計するにあたって、解決す

計上の課題

べき問題は何か。すでに明らかになっていることがあれ ば記入する。

スケジュール

設計プロセスにおける主なイベントスケジュール。

担当メンバー

カンパニー設計担当者、デザイン担当者、UI設計担当者 など、各役割における責任者、担当者名。以後これらの メンバー間で、共通の理解を得ながら、設計を進めてい く。

表1-1 企画意図の確認項目

プロジェクト開始 （企画意図の確認）

1

-3

要求仕様検討のための準備

企画意図が確認できたら、 要求仕様検討のための準備として、 以下の作業を行う。 ● ユーザーの記述 ● 使用環境の記述 ● 制約条件の記述

ユーザーの記述

目的

「これから設計しようとする商品のユーザーはどんな人たちか？」 これが、 ユーザーインタフェー ス設計を始めるにあたってまず初めに問うべき質問である。 設計の初期段階でこの問いに対す る答えを明確にしておくことで、 メンバーの間でユーザーの理解に関するあいまいさが取り除か れ、 共通のユーザー像を描くことができる。 ここでは以下の３つの点を明らかにする。

ユーザーとは

○

○

○

○

○

○

○

○

○

○

○

○

○

○

ユーザーとは、 設計される商品に対して何らかの影響を受けたり、 与 えたりする一人一人のことである。 顧客 （設計した商品に代償を支 払ってくれる人） だけがユーザーとは限らない。

● 対象とするユーザーを列挙し、 要求の聞き先を明確にする ● 対象とするユーザーのどんな属性が設計に影響を与えるかを明確にする ● 対象とするユーザーの属性を明確にする

指針と方法

対象とするユーザーを列挙する 何をひとつのユーザー母体とするか

○

○

○

以下の項目ごとに、 対象ユーザーを記述する。 ○

○

○

○

ユーザー母体名

対象ユーザーが企業などの団体の場合は、 その団体名称がひとつ のユーザー母体となる。 しかし主にコンスーマー商品において、 対

商品を存在させることで、 何らかの影響を受けたり、 または与えたりするユーザー母体すべてを抽

象ユーザーがあまり明確にされていないような場合は、 なかなか明 確なユーザー母体の記述は難しい。 このような場合でも、 対象ユー

出する。

ザーをできるだけ明確にとらえるために、 要求の出方が最も顕著に 異なるであろうユーザー母体は何かを考え、 それらを列挙すること が望ましい。

ユーザー区分 列挙されたユーザー母体は表1-2のどのユーザー区分にあてはまるかを明記する。 団体か個人か 対象とするユーザー母体は、 何かの団体 （企業） なのか、 それとも一般の個人なのかを明記す る。 団体と個人では、 その属性のとらえ方が異なる。

1-4

要求仕様検討のための準備

ユーザー区分 顧客ユーザー

内容 設計した商品に、実際に代償を支払ってくれるユーザー のこと。いわゆるマーケティング上のターゲット市場と 同一の母体である。

操作者ユーザー

実際に商品を操作するユーザーのこと。ユーザーインタ フェース設計においては、このユーザーの情報が最も重 要なものとなる。コンスーマー商品においては、上記の 顧客ユーザーとほぼ同一となる。ノンコンスーマー商品 の場合、顧客ユーザー以外に、操作者としてのユーザー が存在することを考慮する必要がある。

間接的に影響を受けるユーザー

○

○

○

○

○

○

○

○

間接ユーザー

たとえばウォークマンの場合、 電車の中に同乗する他の乗客など。

直接その商品を使用するわけではないが、間接的に何ら かの影響を受けるユーザーのこと。ユーザーのユーザー （2次ユーザー）や、その商品が存在することで、何ら かの迷惑を受ける可能性のあるユーザーなどが存在す る。

○

アンフレンドリーユーザー

○

○

○

○

○

○

○

○

○

アンフレンドリーユーザー

たとえばあるコンピュータシステムの場合は、 進入を企てようとする ハッカーが存在するし、 子供にフレンドリーな親子電話の場合は、 こっ

の妨害を防いだり、ユーザーの危険を配慮する場合に考 えるべきユーザーである。

そりモニターしようとするその親はアンフレンドリーな存在となる。

メーカー側の関係者

○

○

○

○

○

○

○

○

○

○

○

○

わざと友好的にしたくないユーザーのこと。その商品へ

メーカー側の関係者

たとえばナビゲーションシステムなどでは、 デモ機能がある。 この機 能は、 ユーザーのためというよりも、 店頭での販売効果を期待したも

営業マン、サービスマンなどのメーカー側の関係者。設 計のしやすさ、製造のしやすさ、販売のしやすさ、サー ビスサポートのしやすさなどの観点から、商品に対して

のである。 つまり、 セールスマンの要求に応えたものといえる。

何らかの要求があり、それらの要求を調査することも時 には重要なウエイトをしめる。 表1-2 ユーザー区分

要求仕様検討のための準備

1

-5

ユーザーのどんな属性が設計に影響を与

列挙されたユーザーについて、 そのユーザーのどんな属性が設計に影響を与えそうかを明確

えるかを明確にする

にする。 ここで考えられた属性ごとに、 明確なユーザー情報を次のステップで記述する。 属性を考 えるひとつの目安として、 代表的な属性基準を以下に示す。 以下の属性基準からチェックリスト

設計に影響を与えるユーザー属性

○

○

○

○

○

○

○

的に、 設計に何らかの影響を与えそうなユーザー属性を考えればよい。

たとえばミニディスクプレーヤーの場合、 ミニディスクという商品の特 徴から、 対象とするユーザーがワープロなどでフロッピーディスクを どの程度使用したことがあるかという、 ユーザーの知識／経験の差 がどのような操作系を実現すべきかという点で設計に影響を与える だろう。

ライフスタイル基準

○

○

○

○

○

○

○

○

○

○

○

○

対象ユーザー

代表的な属性基準

団体（企業）の場合

業務（活動）内容、活動地域、規模など。

個人の場合

年齢、性別、職業、所得、国籍、家族形態、住居形態、

ユーザーの生活構造、 生活意識、 生活行動の３つの次元から複合

居住地域、知識／経験、身体的能力、所有製品、趣味、

化して得られる分類基準。 一般的にはAIO（Activities：活動 Interests：関心 Opinions：意見） と呼ばれるライフスタイル基準

その他個別のライフスタイル基準など。

ごとに多数の質問を行い、 それを因子分析を用いて集約化するこ とで、 導かれる。 このひとつに、 商品テストラボにおいて提案された

表1-3 ユーザー属性の基準

「AV機器の使いこなし度」 という基準がある。

対象とするユーザーの属性を明確にする

すべてのユーザー母体ごとに、 設計に何らかの影響を与えるとして列挙されたユーザー属性 について、 どのような属性を持った人たちなのかその特性値を記述する。 また、 その特性値を持 つことで、 どのようなことを考慮しないといけないか、 あわせて記述する。

ユーザー母体名

ユーザー属性

ユーザー区分

・年齢

・顧客 ・操作者

・性別 ・職業 ・家族形態

・間接ユーザーなど

団体／個人

・住居形態 ・居住地域 ・知識／経験 ・趣味 ・ライフスタイル ・その他

図1-2 ユーザーの記述

1-6

要求仕様検討のための準備

使用環境の記述

目的 その商品はどのような環境で使用されるのか、 またその環境で使用されることで、 どのようなこ とを考慮する必要があるのかを記述する。 既にユーザーの記述が完了しているので、 ここで使用 環境を把握することで、 どんなユーザーがどんな環境で商品を使うのか、 その具体的なイメージ を形成することができる。

指針と方法 使用環境の記述について、 その指針と方法を以下に示す。 使用される環境の記述 その商品はどのような環境で使用されるのか、 商品の具体的な設置場所や使用される場所の 名称などを記述する。 考慮すべき事柄の記述 その商品が、 記述されたそれぞれの環境の中で使用されることで、 どのようなことを考慮する 必要があるのかを記述する。 そのためには、 記述された環境がどのような特性を持つ環境なの かを把握しなければならない。 一般的には以下のような環境の特性があるので、 これらの特性項 目を列挙されたそれぞれの環境に照らし合わせることで、 考慮すべき点を抽出してもよい。 ● 音に関する特性 ● 温度に関する特性 ● 明るさに関する特性 ● 振動、 ゆれに関する特性 ● 周辺に存在する機器に関する特性 ● 作業空間の広さに関する特性 ● 作業スタイル （服装など） に関する特性 ● その他

要求仕様検討のための準備

1

-7

制約の記述

目的 商品設計においては、 ある制約のもとで、 ユーザーの要求を実現しなければならない場面が 多い。 一般的に制約としては、 技術的制約のほかに、 コスト、 スケジュール、 人材などがある。 これ らが相互に関係しあい、 結果的にある程度のシステム上の制約が存在する。 ここでは、 実際に要 求仕様を設計する前に、 すでに存在するシステム上の制約を洗い出し、 設計に許された解空間 を明確にすることで、 その時点での最適な解を効率的に導くための準備を行う。

指針と方法 主にユーザーインタフェースの設計方針に影響を与えるようなシステム上の制約をあらかじめ 列挙しておく。 代表的なシステムの制約として、 以下のようなものが考えられる。

代表的な制約

内容

システム形態

システム寸法、形状など。

入力デバイス

ユーザーが命令をシステムに伝えるためのデバイス。リ モコン、マウス、キーボード、タッチパネル、音声な ど。

出力デバイス

機器の状態や操作の結果をユーザーに示すためのデバイ ス。LED、OSD、音声、またそれらが出力可能な情報量 など。

ストレージ、メディア

フォーマット、ストレージ容量など。

社会的制約

過去のシステムとの一貫性、業界内での慣習、法律上の 制約など。

表1-4 代表的な制約

1-8

要求仕様検討のための準備

要求の抽出と分析

すでに述べたように、 商品設計とは 「ユーザーの要求を、 その要求が充足される製品に変換す ること」 である。 そのためには、 ユーザーの要求を抽出／分析し、 あいまいさを含まぬ形で明確に 記述する必要がある。 ここでは、 要求の抽出と分析に必要な以下の作業について説明する。 ● 要求の抽出 ● 要求の明確化 ● 要求の絞り込み ● 要求の構造化

要求の抽出

目的 要求仕様設計においての材料となる、 ユーザーの要求 （原始要求） を抽出する。

指針と方法

何に関する要求を抽出するか

抽出すべき要求の種類として、 対象とするユーザー作業空間の中で発生する要求と、 既に市 場に出回っている関連機種の問題点とがある。 対象とするユーザー作業空間の中で発生する要求 すべての商品は、 ユーザーのある目的に依存する何らかの作業 （行動） 空間に対して働きか けるものである。 したがって、 その作業空間において、 どのような作業 （タスク） が存在し、 そこから どのような要求が発生するのか、 そのタスクを分析し、 調査する必要がある。 新規開発型商品の 場合は、 この作業が中心となる。 関連機種の問題点 すでに対象とするユーザー作業空間に導入されている、 自社の前機種、 同カテゴリー商品、 競 合品、 類似品などに対して、 具体的にどのような問題が発生し、 何が要求されているのかを分析 することも重要である。 改良型 （再導入型） の商品の場合は、 この作業が中心となる。

要求の抽出と分析

1

-9

どのように抽出するか

要求の抽出手段に関連して、 要求データの種類は大きく二つに分かれる。 それらは、 特定の問 題のために新たに収集されるものと、 他の用途、 目的のために既に収集されたものをいい、 前者 を一次データ、 後者を二次データとよぶ。 その性格上、 当然一次データのほうが有用性が高いが、 それだけ時間とコストが必要となる。 まずは既に存在する二次データの収集を行い、 過去のデー タを有効に利用するべきである。 二次データの収集 二次データはさらに、 以下のように内部データと外部データに分かれる。

データの種類 内部データ

代表的なデータ ・ご愛用者カード ・お客様ご相談センターに寄せられた苦情／要望 ・商品テストラボなどによる過去の評価結果 ・ヤングラボなどによる過去の調査結果 ・社内の各種情報誌 ・各部門内の蓄積データ

外部データ

・専門雑誌 ・統計書 ・白書 ・報告書 ・業界紙

表1-5 二次データ

一次データの収集 二次データだけでは十分なデータがとれない場合は、 新たに調査を行い、 一次データとして収 集する必要がある。 一次データの抽出手法として、 以下のようなものがある。 ● 質問紙法 （資料編参照） ● 観察法 （資料編参照） ● グループインタビュー （資料編参照） ● インタビュー （面接法） （資料編参照） ● ブレーンストーミング法 （資料編参照） ● プロトコル分析法 （資料編参照） ● Cognitive Walkthrough(QUIS)（資料編参照） ● 各種ガイドラインの利用 （資料編参照）

1-10

要求の抽出と分析

要求抽出時のその他の留意点

要求の抽出にあたっては、 その他以下のことに留意する。 必要でない要求をつかまえない 要求データは多ければ多いほどよい。 しかし、 それは対象ユーザーの要求であることが絶対条 件である。 対象ユーザーの要求を正確につかむためには、 前述の 「ユーザーの記述」 段階 （本文： 1-4ページ参照） での属性記述作業を十分に行い、 その属性分布にしたがって忠実にユーザー サンプリングを実施する必要がある。 顧客ユーザーの要求がすべてではない 要求を抽出すべきユーザーは、 顧客だけとは限らない。 前述の 「ユーザーの記述」 段階で列挙 された人たちが要求抽出の対象となることに留意する。 制約のフィルターを通さない 要求を抽出する段階では、 コストや技術的な制約などは考えるべきではない。 まずは実際にど のような要求があるのかを知り、 次に分析の段階でその要求の本質を理解した上で、 制約条件 を照らし合わせることが必要である。

要求の抽出と分析

1-11

要求の明確化

目的 抽出された要求には、 さまざまな要素が含まれる。 要求を明確にするためには、 その要求をこ こで説明するひとつひとつの要素ごとに正確に記述し、 把握することが必要不可欠である。 また 要求の記述については、 解決策を暗示しない本質的な形でとらえることが重要である。 これによっ て、 プロジェクトメンバーの間で、 ユーザーの要求に対する共通の認識を正確に得ることができる。

指針と方法

明確にすべき要素

以下のように5W1Hで表される要素ごとに、 抽出されたひとつひとつの要求を明確にしていく （ 「表1-6 シャッフル再生機能に関する要求記述の例」 参照） 。 だれが （Who） 主にだれが要求するのか、 または要求するであろうと予測できるのか。 その要求に応える機能 を搭載した場合、 主に使用するのはだれか。 同じ要求であっても、 要求する人が違う （要求する 人の属性が違う） ことで、 その解決方法は異なってくる。 いつ、 どこで （When,Where） 主にいつ、 どこで、 どんな状況で要求されるのか、 または要求されるであろうと予測できるのか。 機能が使用される環境や状況を正しく把握しておかないと、 設計された機器は実際の環境に適 応しない、 使いにくいものになってしまう恐れがある。 何をする （What） ようするに何をしたいのか。 一般的にユーザーインタフェース設計とは、 「ユーザーが最終的に 行いたいことをゴールとし、 そのゴールまでどのように導いていくかを考えること」 とも言い換えられ る。 したがって、 まずユーザーが最終的に行いたいことは何かを正確にとらえなくては、 その考え られた道筋はまったく無意味なものになってしまう。 そのために、 ここではようするに何をしたいの かを記述する。 どんなふうに （How） どんなふうにしたいのか。 「何をする （What） 」 で記述したことに対して、 どのような品質、 プロセ ス、 操作性を要求しているのか、 または要求されるであろうと予測できるのか。 「何をする （What） 」 を補足する補助的な要求を記述する。 何のために （Why） 何のために要求するのか。 ここでは、 具体的な使用例で表現する。 何のために要求するのか が具体的にイメージできるいくつかの代表的な例でよい。 具体的な使用例をいくつか明文化して おくことで、 これから設計する各機能がどのように利用されるのかということについて、 プロジェク トメンバーの間で共通の理解が得られる。

1-12

要求の抽出と分析

要求要素

内容

Who

10代、20代の若者

When,Where

自宅で 電車の中で、車の中で パーティー会場で、など

What

曲をランダムに聞く

How

現在演奏中の曲番号を確認しながら など

Why

聞き慣れたCDを気分を換えて聞く パーティーなどでイントロ当てクイズに使う など

表1-6 シャッフル再生機能に関する要求記述の例

要求の抽出と分析

1-13

明確化のための留意点

ユーザーの要求を明確に記述するにあたっては、 前述の各要素ごとの記述の他に、 以下の点 を考慮する。 解決策を暗示しない真の要求をつかむ ユーザーは自分が本当に望んでいることを正確に把握していない場合が多い。 声として抽出 された要求の中には、 目的に対する手段を表している場合も少なくない。 要求を設計課題に変換 する際には、 ユーザーの要求をできるだけ解決策を暗示しない、 真の要求を表現した形にする ことが重要である。 その上で改めて解決策を検討するべきである。 これにより、 既成概念にとらわ れない魅力的な商品の開発につながる。 真の要求をつかむためには、 「ニーズの層構造」 （図1-3） を参考にする。 図のように、 人のニー ズは大きく3つのレベルに分かれる。 Haveレベルのニーズは真の目的に対する手段を要求して いると考えてよい。 したがって、 要求表現の中に 「ほしい」 という言葉がある場合は、 「ようするに何

どこまで上位化すればよいか

○

○

○

○

○

○

○

○

○

がしたいのか」 を問いかけ、 Doレベルに上位化する必要がある。 また、 Doレベルのニーズでも、

この問いに対する明確な回答はない。 基本的にはBeレベルまで上 位化することが望ましいが、 Beニーズは人の普遍的な要求であり、

ユーザーが商品提供者側に存在する制約を考慮した上での発言になっている場合も多いので、

各要求がどのBeニーズの下位にあるかを知ることは、 「労多くして 益少なし」 の場合も多く、 一般的にはDoレベルでとどめるほうが効

さらに上位のDoニーズを解明することも必要である。

率的だろう （ただし、 Doレベルの中はさらに複数のDoニーズで階 層化されている場合が多く、 これらのどのレベルまで上位化するか はその時々で判断するしかない） 。

Beレベルのニーズ

普遍的なもの

∼になりたい

例 「マークに名前をつけたい （ナビゲーションシステム） 」

手段

「マークに名前をつける」 ことは真の目的ではなく、 これは 「つけたマー クが何を表しているのかわかりたい」 という目的に対する手段であ る。 これより名前をつけることだけが解決策ではなく、 たとえばわかり やすいアイコンを豊富に用意するとか、 音声でメモできるなどの解

Doレベルのニーズ

目的 ライフスタイルや ライフステージの 変化に伴い変化する

∼したい

決策が生まれる。

手段

目的

例 「自動コース設定機能がほしい （ナビゲーションシステム） 」 これもユーザーの真の要求を表現していない。 そもそも「 、自動コー ス設定機能」 とは何なのかが不明確である“ 。ようするに何がしたい

Haveレベルのニーズ

∼がほしい

のか” を問いかけることで、 「どの道を行けば早く着けるか知りたい」 という本質的な要求が抽出できる。

TPOの変化や技術 水準の変化に伴い 変化する

図1-3 ニーズの層構造

専門用語を使用せずユーザーの言葉で記述する 要求の記述にあたっては、 専門用語やこれまでに搭載されてきた機能名称などは、 なるべく使 用しないほうがよい。 日常的でない用語を使わないことは当然だが、 日常的にあたりまえに使用 されるような用語であっても、 われわれはその本当の意味を正しく理解できていない場合も多い。 解決策を暗示しない真の要求をつかむためにも、 できるだけ平易なユーザーの言葉で記述する。

1-14

要求の抽出と分析

「どんなふうに （How） 」 を記述する上での 留意点

特に新規開発型商品の場合は、 本質的にその商品を通じて何が行えればいいのかという要 求は収集できても、 それをどんなふうに行いたいのかという操作性などに関する要求は、 既存モ デル改良型の商品に比べて収集しにくい。 したがって、 どのような 「How」 が要求されるかという ことを、 ヒューリスティックに抽出する必要がある。 ヒューリスティックに抽出する際には、 以下のこ とを参考にする。 ユーザー・使用状況・使用目的を考える その要求の 「何をする （What） 」 は、 「だれが （Who） 「 」いつ、 どこで （When,Where） 「何のた 」 めに （Why） 」 行うのかを考える。 これにより「 、こういうユーザーが使用するのだから、 こんなことが 要求される」 「 、こんな状況で使用されるのだから∼」 「 、こんな目的で使われるのだから∼」 などと、 潜在的に求められる重要な要求の抽出が行える。 各種ガイ ドラインを利用する 操作性に関する要求を漏れなく抽出するために、 ユーザーインタフェース関連の各種ガイ ドラ インを利用することも意義がある。 どのガイ ドラインが最も適しているかについては一概にはいえ ないが、 それぞれの機器のカテゴリーに対応した具体的なガイドラインが社内で作成されてい るものもあるので、 そのときどきで適切なものを利用すればよい。

要求の抽出と分析

1-15

要求の絞り込み

目的 抽出された要求は、 その重要性や技術的な制約などの点で、 必ずしもすぐに対応すべき、 また は対応できるものとは限らない。 それらの要求は、 以後の設計を効率的に進めるためにも、 なるべ く早い段階で検討対象から除外することが望ましい。 ここでは、 それぞれの要求の重要性や実現 可能性について検討し、 検討対象とすべき要求を絞り込むことを目的とする。

指針と方法 抽出されたすべての要求について、 以下の指針と方法を参考に要求の絞り込みを行う。

絞り込むための指針

要求の重要性を考える いくら慎重に対象ユーザーから要求を抽出したとしても、 それらの一部は非常に少数のものだっ たり、 まったく的外れなものだったりする可能性がある。 そのようなものすべてを実現しても、 ターゲッ トとする市場においては、 あまり意味のないものになってしまう。 そのために、 まず要求の重要性を 考え、 明らかに無意味といえるものを除外する。 実現可能性を考える 要求自体の重要性が確認されても、 それを解決することが困難なものは、 やはりできるだけ早 い段階で見きわめ、 検討対象から除外することも必要である。 ただし、 ここで除外したものは今回 は対象外であっても、 将来的には検討する必要があるということを忘れてはならない。

絞り込むための方法

以下の手順に従い、 要求を絞り込む。 手順1

もうひとつのラベリング目的

○

○

○

○

○

○

○

○

○

ここでのラベリング作業の目的は、 要求を絞り込むためのものだけ ではなく、 後述する要求仕様の検討 （本文：1-20ページ） において も、 要求要素のウエイトとして利用する。

「何をする （What） 」 の項目に記述された 「結果として行いたい」 要求に対して、 以下のラベリ ングを行う。 ● M（Must）

：商品コンセプトを達成するために必ず実現すべきもの。 または当該商 品において当然具備されるべきもの。

● W（Want） ：必ず実現する必要はないが、 実現することでより商品の魅力が向上 するもの。 ● （Ignore） I

：実現する必要のないもの。

● D（Deferred）：実現することが望ましいが、 技術的に困難なため、 将来的な課題とし て延期するもの。 手順2

「どんなふうに （How） 」 の項目に記述された要求に対して、 手順1と同じく、 M,W,I,Dのラベリ ングを行う。 ただし、 手順1でIまたはDのラベルが付加された場合は、 結果として行いたいこと自 体が対象からはずれるので、 この作業は必要ない。

1-16

要求の抽出と分析

手順3 要求単位

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

すべての要求単位に対して、 手順1∼2を行う。

「だれが」 「どんなふうに」 「何をする」 などの要求要素から構成され るひとつの要求のことを要求単位とここではよぶ。

手順4 すべての要求単位に対して、 手順1∼2で付加されたラベルを参考に、 その要求単位を検討 対象とすべきかどうかを考え、 以下のラベリングを行う。 ● O（Operation） ：検討対象とする。 ● （Ignore） I

：検討対象としない。

このO、 Iのラベリングの判断は、 主に 「何をする」 に付加されたラベルにより、 下表のように行う。

「何をする」のラベル

※

検討対象とするか

M

O

W

O または I ※

I

I

D

I

対応する「どんなふうに」の要求のラベルを参考に決定する。

表1-7 検討対象とするかどうかの判断

要求の抽出と分析

1-17

要求の構造化

目的 検討対象となる要求が絞り込まれたら、 次にすべての要求をユーザーの意識に合った構造に 分類、 階層化することが必要である。 これにより、 全体としてどのような要求が存在するのかが明 白になる。 またユーザーの意識に合った構造にすることで、 得られた要求構造は、 ユーザーに対 してその製品の機能をどのような枠組みで提示していくかという判断の材料となる。

指針と方法

分類のための視点

ユーザーの要求を構造化するためには、 何らかの視点により要求を分類する必要がある。 その 分類のための視点としては、 大まかに以下の2つのアプローチがある。 ● ユーザーの動作の対象となる物体に焦点を当てる （オブジェクト主体型） ● ユーザーの動作に焦点を当てる （動作主体型）

オブジェクト主体型と動作主体型

○

○

○

○

○

○

○

どちらの分類方法がよいかについて、 一般的には、 特徴的なオブジェ クトまたは動作で分類するほうが、 ユーザーの意識に近い要求構造 に分類、 階層化できるだろう。

たとえばワープロを考えたとき、 前者のオブジェクト主体型による分類では、 ユーザーの要求が文 書に関するもの、 文字に関するもの、 図形に関するものなどのオブジェクト主体で分類される。 一 方、 後者の動作主体型では、 入力する、 編集する、 削除する、 印刷するなどの動作主体で分類さ れる。 どちらの分類がよいかについては一概にいえない。 1つの製品に対する要求について、 ケー スバイケースでオブジェクト主体型分類と動作主体型分類を使い分けながら、 分類、 階層化す ることが望ましい。 いずれにせよ、 得られた要求の構造は、 ユーザーの意識に合ったものであるこ とが必要である。

構造化の手順

以下の手順にしたがって、 絞り込まれた要求をKJ法的に構造化する （図1-4参照） 。 手順 1 要求のひとつひとつを1枚のカードに記入する。 手順 2 すべてのカードをながめ、 意味内容が同じものがあれば、 ひとつにする。

ここまでの作業の意味 要求の抽出と分析の段階においては、 以下の成果が得られ

手順 3 意味内容が似ているものがないか考え、 あれば似ているものをいくつか集めて島をつくる。

ることになる。 ● 手段を含まないユーザーの本質的な要求が明確になる。 ● 検討すべき要求が絞り込まれる。 ● 本質的な要求の構造化が図られ、 要求の全体像が把握で きる。

手順 4 作られた島について、 それぞれ集められたカードを代表する要求表現を考え、 別のカードに新た に記入する。

ここで得られる構造化された要求群は、 以後の設計の土台と なるユーザーの本質的な要求群である。 この後で説明する要 求仕様の検討では、 ある程度の解決策を検討することになり、 設計の進行具合によっては、 その要求仕様は何らかの変更を 受ける可能性がある。 しかし、 ここまでで得られた要求群はそ のような設計進捗の影響を受けない、 ユーザーが本質的に要 求するものとして存在する。 仕様の変更などの必要性が生じ た場合、 この本質的な要求群に立ち返ることになる。

1-18

要求の抽出と分析

手順 5 新たに作られたカードをながめ、 手順3、 4を繰り返す。

聞きたい曲をあらかじめ プログラムして聞く

最初からふつうに聞く

ランダムに聞く

聞きたい曲を頭だしする

最初からふつうに聞く

プログラムしたものを繰 り返し聞く

全曲を繰り返し聞く

聞きたい部分を早送りし てさがす

1曲だけ繰り返し聞く

聞きたい部分を巻き戻し してさがす

グルーピング

聞きたいところをさがす

いろいろな聞き方で聞く

聞きたい曲を頭だしする

聞きたい部分を巻き戻し してさがす

聞きたい部分を早送りし てさがす

最初からふつうに聞く

ランダムに聞く

聞きたい曲をあらかじめ プログラムして聞く

繰り返し聞く

1曲だけ繰り返し聞く

プログラムしたものを繰 り返し聞く

全曲を繰り返し聞く

階層化

聞きたいところをさがす

聞きたい曲を頭だしする 聞きたい部分を巻き戻し してさがす聞きたい部分を早送りし てさがす

いろいろな聞き方で聞く

最初からふつうに聞く 繰り返し聞く ランダムに聞く 聞きたい曲をあらかじめ プログラムして聞く

1曲だけ繰り返し聞く プログラムしたものを繰 り返し聞く 全曲を繰り返し聞く

図1-4 KJ法的階層化

要求の抽出と分析

1-19

要求仕様の検討

ここまでの段階で、 解決策を含まないユーザーの本質的な要求が明確にされた。 次のステッ プではこの要求を受けて、 機器はどんな機能を搭載すべきなのか、 またその機能の操作性に要 求されることは何かということを検討し、 設計課題として明文化する必要がある。 これが要求仕様 となる。 ここではこの要求仕様検討のための作業として、 以下を説明する。 ● 機能方策の決定 ● 機能重要度の設定 ● 要求仕様の記述

機能方策の決定

目的 ユーザーの要求を具体的な設計課題としてとらえるためには、 その要求に応えるために機器 はどんな機能を搭載すべきなのか、 機能のアウトラインを決定する必要がある。 この機能のアウ

機能方策

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

たとえば何かの論文を書く場合でも、 それぞれのパラグラフにおい て何を訴えようとするのか、 そのアウトラインが明確でないと、 それを 文章化することはできない。 製品設計においても同様であり、 搭載

トラインのことを 「機能方策」 とよぶ。 ユーザーのある要求を満たすために考えられる機能方策は ひとつとは限らない。 ここでは、 いくつか考えられる機能方策案の中から、 その時点で最適な機能 方策を決定することを目的とする。

しようとする機能のアウトラインが決定されないと、 実設計作業には 移行できない。

指針と方法

機能方策の検討

要求の抽出と分析の段階で、 すべての要求がWho,When,Where,WHy,What,Howの各 要素ごとに明確に記述された。 ここではそれらの各要素をふまえた上で、 要求ひとつひとつに対 してどのような機能で応えるべきか、 その機能方策を検討する。 考えられる機能方策はひとつと は限らないので、 まずは技術的な制約などは考えず、 ユーザーの要求に応えるためにはどのよう

1つの要求に対して複数の機能が必要な場合もある

○

○

な方策があり得るか、 可能な限り列挙する。

たとえば電話機において、 「よくかける電話番号は簡単にかけられ るようにしたい」 という要求がある。 この要求に応えるために 「よくか

たとえば、 「つけたマークが何を表しているのかすぐわかるようにしたい （ナビゲーションシステ

ける電話番号を登録する」 という機能と「 、登録した電話番号をワン タッチでかける」 という2つの機能が存在する。 つまり、 抽出された1

ム） 」 という要求があった場合、 この要求に対する機能方策として以下のようなものが考えられる。

つの要求に応えるために、 複数の機能の搭載が必要な場合がある。 この場合、 「よくかける電話番号を登録したい」 という要求は本質的 には存在しないことに注意が必要である。

・漢字で名前をつけさせる ・英数字で名前をつけさせる ・いくつかの施設名候補から選んでつけさせる ・マークにつけられるシンボルの種類をもっと増やす この4つの機能方策は、 同じユーザーの要求に応えるものであっても、 どの機能方策をとるかによっ てそのユーザーインタフェースの設計方法は全く異なるものになってしまう。 つまり、 ユーザーイン タフェース設計の方向性を示すためにも、 どの機能方策で応えるのかを次のステップで決定す ることが重要となる。

1-20

要求仕様の検討

機能方策の決定

考えられる機能方策が複数存在する場合、 その中からその時点で最適と思われるものを1つ 選定しなければならない。 数学の問題などと異なり、 ここで扱う問題には絶対的な正解はない。 相

どうなれば機能方策が決定されたといえるか

○

○

○

○

ユーザーの要求に応えるために、 おおよそユーザーにどんな操作 （詳 細な操作手順などではなく、 おおよその操作方法がイメージできる レベル） を求め、 どのような結果を与えるのかということについて、 設 計参画者の間で同一のイメージ形成がなされるとき、 機能方策が 決定されたことになる。

対的で流動的である。 このような問題において1つの最適解を決定するには、 主に以下の考え方 で整理することが望ましい。 ● それぞれの方策案のメリット、 デメリットを考える （メリット／デメリット分析） ● それぞれの方策案の優劣を判断するための、 互いに独立した判断軸は何かを考え、 そ の軸ごとに判断する 機能方策を絞り込む判断軸として、 たとえば以下のようなものが考えられる。 ● その機能から得られる結果は、 ユーザーの要求をどの程度充足するか （結果充足度） ● その機能を搭載した場合、 予想される操作性は容易か （操作容易度） ● 技術的制約などの観点から、 その機能を実現できる可能性はどの程度か （実現可能性） これらの判断軸ごとに、 絶対的または相対的にそれぞれの方策案を評価し、 総合的に判断す る。 なおここで挙げた判断軸はあくまでも一般的なものであるので、 ケースバイケースで適切な 判断軸を検討し、 用いることも必要である（ 。表1-8 参照）

機能案

結果充足度 操作容易度 実現可能性 3つの判断軸の積 決定

漢字で名前をつけさせる

5

2

3

30

英数字で名前をつけさせる

4

3

4

48

いくつかの施設名候補から 選んでつけさせる

2

4

4

32

マークに付けられるシンボルの 種類を増やす

1

4

5

20

表1-8 機能方策の決定方法 「つけたマークが何を表しているのかすぐわかるようにしたい （ナビゲーションシステム） 」 という要求に対する機能方策案の決 定例。 ここでは判断軸として 「結果充足度」 「操作容易度」 「実現可能性」 を考え、 それぞれについて5段階の値で絶対的に評 価した。 3つの判断軸の評価値を掛け合わせたものを期待値とし、 その期待値の最も大きいものが最有力候補となる。 この例 では絶対的に判断しているが、 AHP法 （資料編参照） などを利用して、 それぞれの方策案を判断軸ごとに一対比較して相対 的に評価値を求める方法もある。 さらにこの例のように判断軸が複数存在する場合は、 それぞれの判断軸のウエイ トも問題と なるので、 判断軸のウエイ トも絶対的、 またはAHP法などを利用して相対的に求めることも重要である。

要求仕様の検討

1-21

機能重要度の設定

目的 決定されたそれぞれの機能は、 その製品の企画意図を達成するためにどれくらい重要である

機能重要度の利用方法

○

○

○

○

○

○

○

○

○

○

か、 その重要さの度合いは異なる。 当然重要度の高い機能ほど、 厳しい品質を求め、 作り込む必

ここで設定された重要度は設計プロセス全般にわたって参照され る他、 具体的には後述する要求仕様の記述においても、 どのような

要がある。 また、 それぞれの機能の重要度をあらかじめ設定しておくことは、 企画意図を満足す

仕様を要求するか、 またその仕様の重要度をどれくらいに設定する か、 などの判断材料となる。 また、 設計プロセスにおける評価の段階

る製品の設計を効率的かつ効果的に進めるためにも有用なことである。 そのためにここではす

においては、 その機能を評価する評価のウエイトとしても利用でき る。

べての機能の重要度を設定し、 以後の設計プロセスにおいて参照する。

指針と方法

設定方法 設定方法について、 特に決まったやり方があるわけではないが、 大きく分けて以下の2通りの方 法がある。 ただしここで重要なのは、 どのような観点でその重要度を判断するかである。 ● 5段階評定などで、 絶対的に判断する ● AHP法などの一対比較を行い、 相対的に判断する 重要度を判断する軸 どのような観点で重要度を判断するかという問題に対する指針は、 基本的には以下の一文で 要約できる。 ● その機能は、 企画意図を達成するためにどれくらい重要か すべての製品に課せられた使命は企画意図を達成することであり、 その製品が有する機能に おいてもその使命が同様に要求される。 したがって、 企画意図を達成するために、 その機能の存 在はどれくらい重要であるかを考えることが、 機能の重要度を設定するということになる。 また、 企画意図を達成するためにどれくらい重要かということを、 さらに細かく判断できる軸を用 意することも意義のあることである。 一般的には次のような判断のための軸が考えられるが、 その 製品の特徴などからその都度最適な判断軸を検討する必要があるだろう。 ● その機能は、 どのくらいの人が使用するのか ● その機能は、 どのくらいの頻度で使用されるのか ● その機能を使うことで、 どのくらい重要な結果が得られるのか ● その機能を実現することは、 どのくらいの訴求につながるのか

1-22

要求仕様の検討

要求仕様の記述

目的 機能方策が決定したら、その機能に求められる要求仕様を記述する。 ここで記述された要求 仕様を具体的な設計課題として設計参画者の間で共有することで、 設計プロセス全体を通して、 製品に求められることに関する共通の理解を得ることができる。

指針と方法 要求仕様を記述する上での重要な考え方として、 本書では要求仕様というものを以下の2つ の側面で明確に分離することを推奨している。 ● 結果として何ができればいいのか （機能要求仕様） ● その結果を得るための操作性には何が求められるのか （操作要求仕様） この2種類の要求仕様を各機能方策1つ1つについて、 その機能の重要度、 もとになる要求の各 要素 （Who,When,Where,What,Why,How） を参考に検討し、 記述する。 以下にこの考え方 に基づいた要求仕様の記述について説明する。 なぜ2つの要求仕様を考えるのか ユーザーインタフェース設計というものが、 一連の設計プロセスの中で確固たる地位を与えら れていないような設計においては、 設計初期の段階での仕様検討の焦点は、 主に何ができれば いいのかという機能仕様に関して当てられている。 そのような設計プロセスでは当然、 設計初期 段階で機能の操作性についての議論や要求の抽出はされず、 抽出されていたとしても、 ひとつ の機能の仕様の中に埋もれてしまう可能性が高い。 機能の操作性に要求されることが不明確な ために、 ユーザーインタフェースというものが 「なんとなく」 設計されてしまうのである。 同じアウトプッ トを要求される機能でも、 その操作性に要求されることが異なれば、 その機能のユーザーインタフェー スの設計は全く違ったものになる。 ユーザーインタフェース設計を設計初期の段階から意識しよ うとする立場においては、 この機能の操作性に要求されることを要求仕様設計の段階で明確に しておくことが重要である。 機能要求仕様の記述 結果としてユーザーにどのようなアウトプットを与えるのかを明確にする。 既に検討された機能 方策にしたがい、 さまざまな制約の範囲内でユーザーの要求を最大限に満たす仕様を、 できる 要求仕様の検討順序

○

○

○

○

○

○

○

○

○

○

○

だけ具体的に記述する。 たとえば図1-5の例では、 「マークに英数字で名前がつけられる」 という

一般的に新規開発型の製品の場合は、 機能要求仕様が先に決ま り、 その仕様を持つ機能の操作性に何が求められるかを明確にす

機能方策について、 名前は何文字までつけられるのか、 文字サイズはいくらにするのかなどの具

ることで、 操作要求仕様が記述される。 それは存在しない製品に対 する操作性への要求が収集しにくいことに起因する。 しかし、 既存

体的な仕様が記述されている。 仕様といってもあくまでもユーザーの立場から考えて、 意味のあ

モデル改良型の製品では、 操作性に関する要求も比較的収集しや すく、 また操作性を改善することが第一の使命であったりする場合 もある。 そのような場合は、 まず操作要求仕様が決まり、 それを満足 するために機能要求仕様が削減または変更されることもある。

るものだけであり、 ユーザーにとって意味のない内部的な仕様は要求仕様の設計段階では必要 ない。

要求仕様の検討

1-23

操作要求仕様の記述 機能要求仕様で記述された仕様を持つ機能について、 その操作性には何が要求され るのかを明確にする「 。要求の明確化」 （本書：1-14ページ参照） 段階で記述された 「どん なふうに （How） 」 の内容がそのまま転記される場合もあるだろうし、 機能要求仕様で記述 された内容から新たに検討し、 抽出できる操作要求仕様も存在する。 新たに抽出する場 合は 「要求の明確化」 段階と同じように、 その機能を使用するユーザーやその使用目的、 使用状況などを再確認し、 また各種ガイ ドラインを使用するなどして、 ヒューリスティックに 検討する。

要 求

： つけたマークが何を表しているのかすぐわかるようにしたい（ナビゲーションシステム）

機能方策： 英数字で名前をつけさせる 機能要求仕様

操作要求仕様

・マークに英数字で名前がつけられること ・文字数は1∼4文字の範囲内で自由につけられ ること ・文字サイズは10ポイントとする ・つけた名前がそのまま地図上の目的のマーク のそばに表示されること

・名前入力時、間違えたら1文字単位で訂正でき ること ・複数のマークに対して名前をつけるとき、連 続的に行いやすいこと

M

M Sony マップ上につけたマークに 名前をつける

図1-5 要求仕様の記述例

「つけたマークが何を表しているのかすぐわかるようにしたい （ナビゲーションシステム） 」 という要求に対する機能方策案、 「英数字で名前をつけさせる」 に対する要求仕様の記述例。

要求仕様のウエイ トづけ 記述された機能要求仕様、 および操作要求仕様のひとつひとつについて、 その仕様のウエイ トとして、 以下のラベリングを行う。 これにより必ず具備すべき仕様を見きわめ、 効率的に設計が行 えるようにする。 ● M（Must）：商品コンセプトを達成するために必ず実現すべきもの。 または当該商品 において当然具備されるべきもの。 ● W（Want）：必ず実現する必要はないが、 実現することでより商品の魅力が向上す るもの。

1-24

要求仕様の検討

要求仕様はいつ完成するか 要求仕様というものは、 何度も更新されるものである。 はじめからすべての要求が抽出できると は限らないし、 製品の仕様が明らかになってきて初めて生まれる要求というものも多く存在する。 第2章以降で説明する設計プロセスをふむことで明確になる要求仕様も少なくない。 たとえばユー ザーのさらに詳細な分析を行うことで明らかになる要求仕様もあるだろうし、 ある段階での製品構 想を形にしたプロトタイプの評価を行うことで新たに判明する要求もあるだろう。 つまり要求仕様 というものは、 設計が繰り返されることで常に更新され、 徐々に明確になっていくのである。 したがっ て、 設計プロセスの初期段階では要求仕様というものがあまり具体的に記述できなくてもやむを 得ない。 具体的な仕様が決定できなければ、 ユーザーの要求と制約とを境界条件として、 その仕 様がとるべき設計解のおおよその範囲を記述しておく方法もある。 ただし、 何が問題でこの先何 を決めなければいけないのかということを明確にしておくことは、 最低限必要である。

要求仕様の検討

1-25

要求仕様の設計プロセスにおけるアウトプット （まとめ）

本章で紹介した要求仕様の設計プロセスにより得られるドキュメントとしてのアウトプットは、 図 1-6の通りである。 これらのドキュメントごとに本プロセスの経過をまとめ、 それらを一連の要求仕 様書として設計参画者の間で同意を得て、 以後の設計プロセスへと進む。 ドキュメントA

「プロジェクト開始」 段階で確認された、 企画意図などに関する情報を記述したもの。 ドキュメントB

「ユーザーの記述」 段階で検討された、 対象ユーザーに関する情報を記述したもの。 対象とす るユーザー母体は何か、 ユーザーのどんな属性基準が設計に影響を与えると予想されるか、 そ の属性基準における対象ユーザーの属性はどんなものか、 などについて記述する。 ドキュメントC

「使用環境の記述」 段階で検討された、 使用環境に関する情報を記述したもの。 使用される場 所はどこか、 その場所はどのような環境なのか、 などについて記述する。 ドキュメントD

「制約条件の記述」 段階で検討された、 技術的な制約に関する情報を記述したもの。 ドキュメントE

「要求の抽出と分析」 段階で検討された、 手段表現を含まないユーザーの本質的な要求を記 述したもの。 抽出した要求を5W1Hで明確に記述し、 その要求はMustなのかWantなのかなど のウエイ トづけがされている。 手段を含まないので、 製品をどのように設計し、 実現するかという方 針に左右されない、 製品設計のベースとなる材料として存在する。 ドキュメントF

「要求の抽出と分析」 段階で明確にした要求について、 構造的に記述したもの。 ひとつひとつ の要求を明確に記述するのではなく、 全体としてどのような要求がどのような構造で存在してい るのかが一目でわかるものがよい。 ドキュメントG

「要求仕様の検討」 段階で決定された、 製品の要求仕様が記述されたもの。 ユーザーの要求 を充足するための解決策として検討された機能方策について、 機能重要度が設定された他、 そ の機能要求仕様、 操作要求仕様が記述されたもの。 それぞれの要求仕様は、 MustなのかWant なのかでウエイ トづけがされている。

1-26

要求仕様の設計プロセスにおけるアウトプッ ト （まとめ）

プロジェクトの開始

企 画 意 図 の 確 認

要求仕様検討のための準備

ユ ー ザ ー の 記 述

使 用 環 境 の 記 述

制 約 条 件 の 記 述

要求の抽出と分析

要 求 の 抽 出

要 求 の 明 確 化

要 求 の 絞 り 込 み

要求仕様の検討

機 能 重 要 度 の 設 定

機 能 方 策 の 決 定

要 求 の 構 造 化

要 求 仕 様 の 記 述

ドキュメントA ドキュメントB ドキュメントC ドキュメントD

要求仕様書 ドキュメントE ドキュメントF ドキュメントG

図1-6 要求仕様設計のプロセスで得られるドキュメント

このように、 以後の設計プロセスに与えるドキュメントは、 いわゆる要求仕様が記述されたもの だけではない。 ユーザーや環境に関するデータ、 設計を行うにあたっての前提条件として存在す る制約データ、 要求仕様が生まれたもととなるユーザーの要求データなども、 実設計段階におい ても参照する必要のあるデータである。 以後の設計プロセスにおいては、 ここで明文化された一 連の要求仕様書を常に設計の拠り所とし、 これから具現化しようとする製品に要求されているこ とを、 設計参画者の誰もが同様に理解しておくことが重要である。 一方、 要求仕様というものは設計が繰り返されることで常に更新され、 徐々に明確になってい くものであることは既に述べた。 したがってここで示した各ドキュメントについても、 特に要求仕様 が記述されたドキュメントGについては設計が進むにつれてより明確になっていくものである。 こ こで重要なことは、 より明確になっていったり、 変更されたりした要求仕様レベルの記述について、 その履歴を残すことである。 履歴を残すことでどの時点で何がどのように変更になったのかが確 認でき、 またその変更理由などもあわせて書き留めておくことで、 後になってなぜそのような仕様 になったのか、 その時どのような議論が交わされたのかが明白になる。 これにより仕様が決定し たプロセス自体が明確になり、 設計参画者の間で不信感が生じることもない。 このことは、 要求仕 様の設計プロセスにおけるもうひとつの重要なアウトプットは何であるかを示唆する。 つまり、 要求 仕様を設計するというプロセスそのものが重要なのであり、 そのプロセスの中で全員のベクトル がひとつになることこそ、 要求仕様の設計プロセスに求められる最も重要なアウトプッ トなのであ る。

要求仕様の設計プロセスにおけるアウトプッ ト （まとめ）

1-27

参考文献

●「品質展開法1」 （著者：大藤 正他、 日科技連） ●「商品開発マーケティング入門」 （著者：梅田 修,PHP研究所） ●「要求仕様の探検学」 （著者：G.M.ワインバーグ他、 共立出版） ●「成功商品開発マニュアル」 （著者：梅澤伸嘉、 日本能率協会総合研究所） ●「工業デザイン全集第2巻 製品計画」 （編者：工業デザイン全集編集委員会,日本出版 サービス） ●「工業デザイン全集第3巻 設計方法」 （編者：工業デザイン全集編集委員会,日本出版 サービス） ●「図説エルゴノミクス」 （編者：野呂 影勇,日本規格協会） ●「使いやすさ評価ガイドブック（ 」作成：商品テストラボ,1994）

1-28

参考文献

2

ユーザーインターフェース設計 2章では、 ユーザーインターフェース設計の進めかたに沿って、 その考え方と設計方法につい て説明する。

商品企画

ユーザーの要求を分析

設計

出荷

ユーザーインターフェースコンセプトの決定

設計−評価のサイクルを回す

評価

評価

ユーザーの要求を 製品仕様に解釈

U.I デザイン

コンセプト決定

設計

出荷

起こりうるものは必ず起こる マーフィーの法則

はじめに ........................................ 2-1 ユーザー分析 ................................. 2-6 ユーザーインターフェース設計の考え方 ... 2-19 UIコンセプトの決定 ....................... 2-23 実設計 ........................................2-25 利用者案内 ................................. 2-26 シミュレーション ............................ 2-29 評価 ...........................................2-35 承認を得る................................... 2-37 ドキュメント化 ............................... 2-39 アイディア出しの支援 .................... 2-44 設計プロセスを効率よく進めるために . 2-48 UI設計者に求められる資質 ............ 2-58

要求仕様の設計

1

-1

1-2

要求仕様の設計

はじめに ユーザーインターフェース設計の存在

近代の設計の歴史を振り返ってみると、 機器の主な構成要素が歯車などの機械的部品でし められていた当時は、 設計者といえば機構設計や構造設計を指していた。 その後、 機器の構成 要素に電気回路が加わり、 半導体が加わり、 そしてソフトウエアが加わるに従って、 電気回路設 計、 半導体の回路設計、 さらにはソフトウエア設計など、 設計の専門領域の種類が増えてきた。 こ れらの専門領域の発生は、 機器の 「機能」 を実現するための構成要素の増加に従って増えて来 たと言える。 図2-1は、 ユーザーが機器を使用して何らかのアウトプットを得るという状況をモデル化したも のである。 図の右側の 「アウトプット」 とは、 例えばステレオの場合、 ユーザーが楽しむ音楽であり、 テレビの場合はブラウン管に映し出された映像である。 音楽を楽しむ場合を考えてみると、 ユーザーは機器が音を出すための機能要素、 例えば回路 内を流れる信号や電圧の変化に直接働きかけることはできない。 ユーザーが機能を利用できる ようにするためには、 ユーザーが接する機器の接面をユーザーが操作可能な形で提供する必要 がある。 ユーザーがアウトプットを得るために機器に接する部分を第1接面と呼び、 機器の機能が

第3の接面

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

共同作業の場合は、 人と人との接面として、 さらに第3の接面も考慮 する必要がある。

外界に対して作用する部分を第2接面と呼ぶ （佐伯 1988） 。 前述の各設計分野は、 機器の第2接面側、 つまり機器の機能要素に対応して発生した専門領 域と考えられる。 しかし、 機器には、 図2-1に示すように必ず第1接面が存在する。 従って、 機能を 実現する機器の構成要素に対応した設計の領域の他に、 機器の第1接面の側の設計の領域が 存在するのである。 この機器の第1接面の設計は、 機器のすべての機能要素と関連しており、 ま たこれまでは設計問題としての量がそれほど多くなかったため、 他の設計領域の中に取り込まれ、 ひとつの専門領域として独立してこなかったのである。 しかし近年になって、 機器の操作そのも のが抽象化するとともに、 第1接面の設計量が増大してきている。 また、 第1接面の設計の最適解 を求める方法論は、 他の設計の方法論では解決しきれない問題である。 このような状況から、 機 器の第1接面の設計をひとつの専門領域として、 その設計の方法論を確立することが今後強く

ユーザーインターフェース

○

○

○

○

○

○

○

○

○

○

「ユーザーインターフェース」 を、 本文中省略するときは 「UI」 と表記 する。

要求されると予測される。 本書では、 この機器の第1接面の設計をユーザーインターフェースの設 計と定義し、 その設計方法の基本的な考え方を考察するものとする。

機器

UI

機能

アウトプット

ユーザー

第1接面

第2接面

図2-1 インターフェースの基本構造 （佐伯 1988） 第2接面は機器の機能に対応し、 第1の接面がユーザーと機器とのインターフェース、 つまりユーザーインターフェースである。

はじめに

2

-1

認知されにくいユーザーインターフェース

機構設計、 電気回路設計、 ソフトウエア設計といった専門分野は、 機器を構成するシャーシ、 回

設計

路基板、 ソフトウエアといった物理的実体に直接結びついているため、 独立した専門領域として 理解されやすい。 また、 その設計の方法論としても、 歴史のある工学的方法論を持ち、 またその 設計結果も 「動作する／しない」 といったような是非の判断が明確にできる性質を持っている。 一方でユーザーインターフェース設計は、 具体的な実体の設計ではなく、 機器の操作部分の 「仕様」 の設計であり、 仕様書が作られないような設計プロセスでは設計結果そのものも見えなく なる。 さらに、 その設計結果は 「動作する／しない」 といったような判断が基本的にできるものでは ない。 また、 「良いユーザーインターフェースは見えない」 と言われるように、 設計結果が良いもの であればあるほど認知されにくい。 このように、 ユーザーインターフェース設計はその存在が認知されにくい性格を持っている。 そ のため、 新しくて奇抜な入出力デバイスや、 革新的な機器のコントロール方法といった 「見える」 ものがユーザーインターフェース設計であると主張されやすいのである。 しかし、 このような主張 は本来のユーザーインターフェース設計の問題を歪曲し、 本質的な解決から遠ざけてしまうこと になる。

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

ユーザーインターフェースは、 機器の機能を実現する個々の要素それぞれに関係し、 さらにユー ザーを記述する個々の要素、 例えばユーザーの知識、 認知的処理能力、 社会的価値感、 肉体的 能力などのすべての要素に関係する。 しばしば、 工学系の設計者から、 ユーザーインターフェー スの最適解は何かという質問が出るが、 ユーザーインターフェース設計を解析的方法論で記述 しようとした場合、 多くのパラメーターを含んだ複雑な方程式で表現されることになり、 これを計算 する複雑さは、 方程式の数の2乗以上の早さで増加する。 このような問題解決の方法領域としてはシステム工学の分野があり、 ユーザーインターフェー スの設計には、 プロセス全体としてシステム工学の方法が適用できる。 システム工学では、 ヒュー

ヒューリスティック

○

○

○

○

○

○

○

○

○

○

○

○

新しいものを見つけだす思考。 発見のための探索。

○

リスティックに設計を進めることになるが、 ヒューリスティックな方法では、 設計者はあらかじめ問 題解決のアイディアのレパートリーを豊富に持っていることが必要である。 そして、 その中からど のアイディアが問題を解決する確率が高いかを分析的、 経験的に決定する。 この設計方法では、 設計効率を上げ、 また高い品質を保つために、 例えば 「ガイ ドライン」 など、 特定の設計分野に特 化したノウハウの蓄積を行うことが重要となる。

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

以降の本書の構成を理解しやすくするために、 ユーザーインターフェース設計の設計要素とそ の大まかなプロセスを示す。 図2-2（次ページ） は、 システム工学の方法に基いたユーザーインターフェース設計の一般的 手順を簡易化して示したものである。 図2-2で示したようにユーザーインターフェース設計プロセ スは、 全体として2つのフェーズに分けられる。 はじめのフェーズは、 商品のユーザーインターフェー スのコンセプト （基本的な解決策） を決定するフェーズである。 ユーザーインターフェースをこの段 階で極力詰めておくことにより、 詳細設計に入ってからの試行錯誤が減り、 結果として設計プロセ ス全体の効率を上げられると予想する事ができる。 最後のフェーズは実設計の段階である。 この 段階では、 詳細設計と評価を進めながらその設計結果をユーザーインターフェースの仕様書と してまとめていく。 各フェーズでのアウトプットはそれぞれ 「要求仕様書」 「 、ユーザーインターフェー ス企画書」 「 、ユーザーインターフェース仕様書」 となる。 これらの内容についても以降で説明する。

2-2

はじめに

UIコンセプトの決定

実設計

次機種

要求仕様見直し

再分析

ユ ー ザ ー 分 析

代替案作成

シ ミ ュ レ ー シ ョ ン

コ ン セ プ ト 設 計

代替案作成

詳 細 設 計 評 価

承 認

︵ 手 作 り ／ 型 試 ︶

事 後 評 価

評 価

アイディア

機器

機器 ユーザー

ユーザー

モックアップ

ユーザーインターフェース企画書

ユーザーインターフェース仕様書

図2-2 ユーザーインターフェース設計の一般的手順。

はじめに

2

-3

ユーザーインターフェース設計とコスト

近年、 「Discount Usability Engineering」 といった、 時間をかけずに操作性の評価を行 うユーザーインターフェース設計の方法の有効性が唱えられたり、 コストとユーザーインターフェー ス設計の関係について議論が行われている。 このように、 ユーザーインターフェース設計がコス トとの関係で議論されるのは、 そもそもユーザーインターフェース設計がシステム工学の方法論 に従っているためである。 先にも述べたように、 ユーザーインターフェース設計では、 解析的方法 によって 「動作する／しない」 という答えが得られるものではなく、 ヒューリスティックな設計方法、 つまり設計者の解決のレパートリーから、 分析などを行うことによって仮説 （解答の目星） を立て、 それを評価し、 さらによりよい解答を見つけるというサイクルを回すことになる。 このサイクルを回 せば回すだけ要求される回答に近づく確率は増えて行くわけである。 そこで問題になるのが、 こ のサイクルを 「いつやめるか」 という問題である。 確かに、 このサイクルを回せば回すだけ品質は 良くなるが、 しかし、 ユーザーインターフェースのコンセプト出しに2年をかけたら、 周囲の状況が 変わってしまい要求そのものも変わってしまう可能性が高くなってしまう。 これでは永遠に設計が 終わらなくなってしまうわけで、 そのために設計をいつやめるのかの判断が必要となる。 そこで、 要求される回答に近づくためにサイクルを回すコストと、 その結果得られるベネフィットとのトレー ドオフの問題が、 ユーザーインターフェースでは根元的に存在するのである （図2-3） 。 従って、 前 述のユーザーインターフェース設計の一般的な設計手順も、 必要なステップを踏むために必要 なコストと、 そこから得られるアウトプットとのトレードオフの問題が、 個々の設計問題ごとに生じる ことになる。

高い

状況の変化に伴う要求品質の変化 品質

ヒューリスティックな設計にかける時間 図2-3 ヒューリスティックな設計にかける時間と品質のトレードオフ。

2-4

はじめに

ユーザーインターフェース設計プロセス

本書の目的は、 これまでの設計プロセスの中からユーザーインターフェース設計のプロセスを

の導入

発見し、 それを独立したひとつの設計プロセスとして確立することにある。 このユーザーインターフェース設計が、 独立した設計プロセスとして現在の設計プロセスに組 み込まれる過程は、 ほぼ次のようなステップを踏むと予測される。 1. 設計のプロセスの中に、 ユーザーインターフェース設計のプロセスが存在することを発見 する（ 。図2-4） 2. 設計プロセスの要所要所で、 ユーザーインターフェースの仕様決定を待って次の設計が 進むようになる（ 。図2-4のA） 3. ユーザーインターフェースのコンセプトを先に決めた方が効率がよいことに気が付く。 （図2-4のB） 上記ステップの1番目、 つまり、 設計のプロセスの中にユーザーインターフェース設計のプロセ スが存在することを発見すれば、 そのあとのステップは自然に進むであろうと予測される。 つまり、 ユーザーインターフェース設計を成功させる鍵は、 「設計のプロセスの中に、 ユーザーインターフェー ス設計のプロセスが存在することを発見する」 ことである。

設計のプロセス

実設計

A

B

UI UI

UIコンセプト の決定

実設計

実設計

図2-4 設計プロセスの中にユーザーインターフェース設計プロセスの存在が発見されると、 設計プロセスの要所要所で、 ユーザーインターフェースの仕様決定を待って次の設計が進むようになり、 結果として、 ユーザーインターフェースのコンセプ トを先に決めた方が効率がよいことに気が付くであろう。

はじめに

2

-5

ユーザー分析

分析と設計

ユーザーインターフェースの設計は、 製品の操作性に要求される品質を満足する操作系を設 計することである。 その設計方法は、 本書の 「はじめに」 でも述べたようにヒューリスティックな設計 方法をとる。 ヒューリスティックな方法では、 設計者はあらかじめ問題解決のアイディアのレパート リーを持ち、 その中からどれが要求を満足する確率が高いかに的 （マト） を絞る。 ユーザーインター フェース設計での分析とは、 この的を絞るための作業である （図2-5） 。

分析 アイディアのレパートリー 機器

これだ！

ユーザー

図2-5 分析とは、 あらかじめ持っている問題解決のレパートリーから、 要求を満足する確率が高いアイディアに的を絞るため の作業である。

分析の手順

分析は、 図2-6（次ページ） に示すように 「何の問題かを見極める」 、 そして 「その問題の解き方 で分析を行う」 という2つのステップを踏んで進められる。 つまりこれから分析する問題が、 わかり やすい概念モデルは何かといったユーザーの知識分析の問題なのか、 持ちやすい形状は何か といった人間工学的問題なのか、 それともどの色が好まれるのかといった社会的価値基準の問 題なのかでとりうる分析方法が異なる。 何の問題化の見極めが外れていると、 押しやすい大きな ボタンを付けたのだが使いやすくならないといった問題が生じてしまうのである。 一般的に、 分析を行う際に危険なことは、 人はあらかじめ持っている分析方法でしか問題を見 ることができない性質があるということである。 日頃、 統計解析を専門にしている分析者は目前の 問題をすべて統計的分析の問題とみなし、 同じ問題で人間工学専門の分析者はアイカメラを用 意し、 認知心理学の分析者は発話プロトコルをとりはじめるのである。 ユーザーインターフェース設計において 「何の問題かを見極める」 ためには、 ユーザーが機器 を操作するという行為を記述する全体的な枠組みに沿った適切なユーザーの分析の枠組みが 必要である。

2-6

ユーザー分析

本書では、 ユーザーの分析の枠組みとして図2-6に示す枠組み （J. ラスムッセン 1986） を採っ ている。 この枠組みでは、 ユーザーの心的情報処理モデルがその中心となる。 そして、 ボトムアッ プ的に解剖学的分析、 生理的機能の分析、 心理的メカニズムが影響するものとし、 さらに、 トップ ダウンの意志として、 社会・集団的価値体系が心的情報処理に影響を与えるとしている。 ユーザーインターフェース設計のための個々の研究の目的およびその成果は、 この枠組みに 対して位置付けられるべきであると考える。 本書では、 ユーザーインターフェース設計で中心となる心的情報処理の分析について、 その 分析の枠組みと考え方について述べる。 社会・集団的価値体系の分析および解剖学的分析などに関しては、 その内容が膨大である とともに、 それらが心的情報処理とどのように関わるのかといった研究は、 今後の大きな課題であ り、 現段階では個々の課題ごとのアプローチの方法の紹介にとどめる。

社会・集団的価値体系の分析 （社会学、文化人類学的アプローチ）

ゴール、 主観的成果基準の形成

Q

ユーザーインターフェース の問題

ど の 問 題 ？

心的情報処理の分析 （認知科学的アプローチ）

主観的達成基準 処理基準

行為

処理資源 パラメーターと限界

心理的メカニズムの分析 （認知科学的アプローチ） 生理的機能の分析 （生理学的アプローチ） 解剖学的分析 （人間工学的アプローチ） 図2-6 ユーザーの分析の枠組み。 （J. ラスムッセン 1986「人間とシステムの相互作用のモデル」 ）

ユーザー分析

2

-7

心的情報処理の分析

ユーザーの心的情報処理を分析するためには、 心的情報処理を記述するためのモデルが必 要になる。 このモデルには、 現在までに様々なものが提案されている。 本書では、 ユーザーインター フェースの設計には、 ユーザーの既有知識の分析が心的情報処理の分析に有効であると判断 した。 この、 ユーザーの既有知識の分析の枠組みとして 「SSOA（Syntactic−Semantic Object −Action：構文−意味／対象−操作） モデル （B. シュナイダーマン 1983） 」 を採用した。

知識

操作

対象

操作

タスク

対象 機器

意味

構文

図2-7 SSOAモデル：対象と操作の構文−意味モデル （B. シュナイダーマン 1983） 。 長期記憶領域の中のユーザー の知識を表している。 構文知識は、 多種多様で、 機器に依存しており、 暗記する必要があり、 そして忘れやすい。 意味知識には、 機器に関するものとタスクに関するものがある。 さらに、 それぞれが操作と対象に分けられる。 意味知識は、 構造化しやすく、 機 器には依存しておらず、 意味を理解しながら学習する必要があり、 そして固定的である。

2-8

ユーザー分析

SSOAモデルで、 構文知識は、 ワープロの文書保存の操作を例にとると、 A社ではファンクショ ンキーの 「F6」 を押すのに対し、 B社ではメニューからマウスで 「保存」 を選ぶといったように、 機器 に依存した知識である。 この構文知識は長期記憶の中で構造化されにく く、 繰り返し機器を使用 していないと忘れてしまうものである。 一方、 意味知識は、 機器についての知識と、 機器を使って行うタスクの知識に分けられる。 そし て、 機器およびタスクの知識は、 さらに高位のレベルの対象概念 （例えばハードディスクの階層構 造の概念） と、 低位レベルの操作概念 （例えばファイルに名前を付けて保存する操作の意味） と に分けられる。 文書作成でのユーザーの知識の分類例を図2-8に示す。 この考え方は、 ユーザー の機器に対しての習熟度に適応でき、 例えば機器の操作には素人だがタスクの専門家と、 タス クについてはよく知らないが機器の専門家といった分類ができる。

文書を作成し保存する場合の例

タスクの対象の知識 （書類、引き出し） タスクの概念の知識 タスクの操作の知識 （文書を書く、引き出しにしまう） 意味知識 機器の対象の知識 （ファイル、ディレクトリー） 機器の概念の知識 知識

機器の操作の知識 （ファイル名を付ける意味、 保存することの意味） 構文知識

（F3を押す、ファイル名を半角英数字で付ける、CTRL+Sを押す）

図2-8 文書を作成し保存する知識のSSOAモデルに基づく分析例

このSSOAモデルをもとにしたユーザーの知識の分析を行う場合、 次の2項目が分析事項と してあげられる。 1. 設計対象の機器に固有の知識に対してユーザーがどのレベルまで知っているのか → 「知識レベルの分析」 2. 判明した知識のレベルにおいて、 具体的にユーザーは何をどのように知識として持って いるのか。 → 「知識内容の分析」 上記の各分析テーマに従って次ページ以降でユーザーの知識分析の具体的説明を行う。

ユーザー分析

2

-9

知識レベルの分析

目的 ユーザーが、 設計対象の機器についての知識をどの程度持っているのかを調べる。 さらに、 そ の知識の内容の分析をする際の分析方法を決める。 ここでのアウトプッ ト ・ユーザーの知識レベルの分析結果 ・知識内容の分析方法

指針 知識レベルの差

○

○

○

○

○

○

○

○

○

○

○

○

○

知識レベルの差と言っても頭の善し悪しのことではない。 対象の機 器のある機能についての知識の差のことである。 ノーベル物理学 賞を受賞した科学者が、 ソニーのビデオデッキの録画予約の方法 を知らないからといて知識が劣っているわけではない。

知識レベルの分析について ユーザーの知識のレベル、 つまり設計対象の機器に固有の知識をユーザーがどの程度持っ ているのかを、 SSOAモデルに照らし合わせて考えてみると図2-9に示すようになる。 例えば文書を作成し保存するという操作を考えたとき、 知識が浅い初心者の場合は、 通常の 紙とペンでの文書作成の知識 （タスクレベルの知識） はあるがコンピューターを使った文書作成 と保存の知識 （機器の操作のレベルの知識） が無い。 また、 同種の機器の使用経験があるユー ザーの場合は、 書類を作成する、 書類を保存するという一般的な操作概念の知識はあるが、 それ が対象の機器の場合に、 舞台的にどうするのかかわからない。 図2-9で示したユーザーの知識のレベルのうち、 最も知識の深い、 つまり対象機器についての 構文知識を持つレベルは、 これから設計する機器 （まだ世の中にない） に関しての知識を持って いるということになるため、 考慮する必要はないであろう。 そこで、 ユーザーインターフェース設計 では、 構文知識以前のユーザーの知識 （意味知識） の分析が中心となる。 知識のレベル （対象機器に固有の知識の深さ）

浅い（初心者）

タスクの対象の知識 （書類、引き出し） タスクの概念の知識 タスクの操作の知識 （文書を書く、引き出しにしまう） 意味知識 機器の対象の知識 （書類を作る、書類を保存する） 機器の概念の知識 知識

機器の操作の知識 （「新規文書作成」、「保存」の意味）

構文知識

（F3を押す、ファイル名を半角英数字で付ける、CTRL+Sを押す）

図2-9 ユーザーの知識レベルは、 SSOAモデルをもと に分析できる。 ユーザーインターフェース設計では、 ユーザー の意味知識の分析が中心となる。 深い（習熟者）

2-10

ユーザー分析

レベルごとの知識の分析対象および分析方法 ユーザーの知識レベルを分析したら、 次に、 ユーザが具体的にどのような知識を持っているか を分析する。 知識の具体的な分析内容とその方法は、 図2-10に示すようになる。 タスクに関する知識を調 べる場合は、 その分析対象は、 これから設計する機器と同じ機能を有する既存のシステムになる。 「これから設計する機器と同じ機能を有する既存のシステム」 とは、 例えば、 ワープロの場合 「紙− ペン−消しゴム」 など、 コンピュータによる通信の場合は 「手紙−ポスト−郵便受け」 などである。 こ れら既存のシステムに対してユーザーが何をどのように理解し、 知識として有しているかを分析 する。 また、 機器に関する知識を調べる場合は、 その分析対象は、 これから設計する機器と同じ 機能を有する既存の機器が良い。 例えば、 前機種や、 他社製品である。 このような分析対象に対して、 対象の知識のもととなるのは、 ユーザーが対象のシステムをどの ように理解しているか。 つまり、 ユーザーの概念モデルである。 この分析には、 ドローイングインタビュー 法や、 ブランクフェースモデルを使った演技法プロトコルなどがある。 また、 操作の知識分析では、 対象のシステムに対してユーザーの持つ操作の知識の集合を調べることになる。 これらは、 例え るならコンピュータープログラムでのサブルーチンのようなもので、 「もし...だったら、 ∼する」 「 、...に ついては、 ∼する」 という知識の集合である。

分析内容

分析方法

タスクの対象 の知識

既存システムに対する ユーザーの概念モデル の分析

・インタービュー ・ドローイングインタビュー ・アンケート

タスクの操作 の知識

既存のシステムに対して ユーザーが有するタスク の知識の分析

・タスク分析

機器の対象 の知識

既存機器に対するユーザー の概念モデルの分析

・演技法プロトコル ・インタビュー ・ドローイングインタビュー ・アンケート

機器の操作 の知識

既存機器に対してユーザー が有する操作の知識の分析

・タスク分析 ・プロトコル分析

タスクの概念 の知識

意味知識

機器の概念 の知識

図2-10 知識レベルごとの分析内容とその方法。

ユーザー分析

2 -11

方法 ユーザーの知識のレベルは、 ひとつの機器についてある一定の知識レベルがあるのではなく、 個々の機能ごとに知識レベルが異なる。 分析したい機器の各機能毎にユーザーの知識がどの レベルなのかといった調査が必要である。 ユーザーの知識レベルの分析手法およびユーザー知識の分析方法として以下の手法が考 えられるが、 ユーザーの知識レベルは、 要求仕様書のユーザーの記述からある程度想定できる 場合が多い。 また、 ユーザーの知識レベルの分析を行う実験で、 ユーザーの知識内容の分析も ある程度行えるため、 実際には、 ユーザーの知識レベルをまず想定してユーザーの知識分析を 行い、 もし想定したユーザーの知識レベルがずれていれば、 さらに分析をするという手順になる であろう。

● 「発話プロ トコルを用いた認知的課題分析」 （ 「ユーザーが求める取扱情報を、 製品使用におけ るユーザーの認知モデルに基づいて発見する」 ドキュメントデザイン／味の素システムテクノ 1992） ユーザーの行動を知識、 操作、 認知に分けて、 与えた課題の発話プロトコルを分析する。 ● 「質問紙法」 （資料編 「質問紙法」 参照） 多くの人数を調査して、 確実性を増したい場合。 ● 「インタビュー」 （資料編 「インタビュー」 参照） 多くの人数は必要ないが、 細かい分析をしたい場合。

2-12

ユーザー分析

知識内容の分析

目的

−概念モデルの分析

ユーザーがタスクを実行する際に利用する概念モデルを分析する。 この概念モデルを分析す 概念モデル

○

○

○

○

○

○

○

○

○

○

○

○

○

○

○

まとまりをもった対象に関する体系的な知識で、 人が推論や心的操 作を行う際に活性化されるもの。 暗黙のうちに行われる推論も含む。

ることにより、 ユーザーインターフェースとして利用可能なメタファーや、 わかりやすい機能名称が 得られる。

知覚や言語的記述に基づいており、 イメージができ上がると移動し たり動かしたりたどったりできる。 概念モデルは対象のふるまいを説

ここでのアウトプッ ト

明／予測する根拠となるので、 課題を正しく理解できる可能性が高 くなる。

・対象ユーザーが理解しやすい概念モデル。 ・理解するときにユーザーが使用するメタファー。 ・対象ユーザーが経験上親しんでいる操作 対象の名称と、 その名称に対する意味付け。

指針 概念モデルの分析は非常に難しい。 それは、 ときとして、 本人でさえ今行った行動が自分自身 どう理解して行ったのかきちんと認識できない場合があるからである。 さらに、 この分析を困難に している理由は、 自分の考えを他人に伝えることが難しいからである。 そのため、 概念モデルの メタ認知能力

○

○

○

○

○

○

○

○

○

○

○

○

○

○

自分自身の認知過程を認知する能力。 自分がなぜそう考えたのか を第三者的に （メタに） 認知する能力。

分析は、 被験者のメタ認知能力とそれを表現する能力に大きく依存することになる。 そこで、 実際 の分析のための方法 （テクニック） は、 被験者のメタ認知能力と表現能力とをいかにカバーするか が中心となる。 下記に紹介するブランクフェースモデルを使った演技法によるプロトコル分析と、 ドローイングインタビュー法は、 この被験者のメタ認知能力と表現能力とをカバーする試みである。 概念モデルの分析で最も危険なことは、 作り手側が 「ユーザーはこのように理解するであろう」 と勝手に想像することである。 対象ユーザーがタスクの対象の知識しかない場合、 設計者との知 識レベルの差は非常に大きい。 知識レベルの異なった他人がどのように考えて行動するかはけっ してわからないと考えるべきである。

ユーザー分析

2 -13

方法 概念モデルの分析方法として下記のような手法が考えられる。 タスクの概念の知識を調べる 場合の分析対象は、 これから設計する機器と同等の機能を提供する既存システムであり、 機器 の概念を調べるときは、 これから設計する機器と同じ機能を有する既存の機器、 例えば、 前機種 や他社製品となる。 ● 「インタビュー」 （資料編 「インタビュー」 参照） ユーザーが頭の中に持っている概念などを、 非構成的に聞き出すのに向いている。 ユーザー やインタビュアーが絵を書きながら行う 「ドローイングインタビュー法」 （資料編 「ユーザーの概念モ デルの分析手法」 ） も有効である。 ● 「ブランクフェースモデルを使用した演技法」 （資料編 「ユーザーの概念モデルの分析手法」 ） 対象システムを 「のっぺらぼう （ブランクフェース） 」 にして、 被験者にタスクをこなしてもらう。 この とき、 実際の操作状況に極力近づけるためにお芝居をしてもらう。 この方法により、 被験者が対象 に縛られることなく、 頭の中にあるモデルが引き出される。 ● 「質問紙法」 （資料編 「質問紙 （アンケート） 法」 ） メタファーとして既存の機器が挙げられる場合や、 概念モデルの候補としていくつかのイメー ジを想定できるような場合、 統計的方法による裏付けをとったり、 全体の傾向を調べるときに利用 できる。

2-14

ユーザー分析

知識内容の分析

目的

−操作知識の分析

ユーザーが知識として持っている操作の単位と手順を分析する。 ここでのアウトプッ ト ・ユーザーが知識として持っている操作の単 位と手順 （行為のゴール−サブゴール構造）

指針 図2-11の左側がユーザーが知識として持っている操作の単位と手順になる。 つまり、 ユーザー が対象となる機器を操作するときに、 まず何をしようとするのか、 そして、 操作を選択するときに機 器に対してどのような操作系を求める （探しに行く） のか、 さらに操作した結果をどのように判断す るのか。 また、 機器の要求する操作に対してユーザーがわからない操作があるのか、 といったこ とを分析する。 これにより、 具体的な操作対象の名称や形状、 システム側のレスポンスのあり方、 機器側の操作要求に対してユーザーが想定していない操作 （適切なガイダンスが必要と予測 される） は何かがわかる。

インターフェース要素 そのためには

意図（サブゴール）

認識 （機器はこうなっている）

操作の選択

オペレーター 実行

サブゴール

機能要素 レスポンス

結果の認識 （操作の結果こうなった） それから

操作の選択

オペレーター

サブゴール

機能要素 レスポンス

ゴール ∼したい

それから？

機能

ユーザー

機器 操作の選択

オペレーター

サブゴール

機能要素 レスポンス

それから

操作の選択

オペレーター

サブゴール

機能要素 レスポンス

できた

図2-11 図の左側がゴールを達成するために必要だと考えている操作系列であり、 これはユーザーの知識に依っている。 図の右側は、 機器側で機能を実現するために必要となる機能要素。 ユーザー分析では、 ユーザーの知識にあるサブゴールと 機能要素とが一致するところはどこか、 それはどのように一致するのか、 また一致しないところはどこか、 これらがユーザーによっ て変わるのかを調べる。

ユーザー分析

2 -15

方法 ユーザーが知識として持っている操作の単位と手順 （行為のゴール−サブゴール構造） の分 析方法として下記のような手法が考えられる。 タスクの概念の知識を調べる場合の分析の対象 は、 これから設計する機器と同等の機能を提供する既存システムであり、 機器の概念を調べると きは、 これから設計する機器と同じ機能を有する既存の機器、 例えば前機種や他社製品となる。 ● 「観察」 （資料編 「観察法」 参照） 現在どのようにして目的を達成しているのかを密着観察する。 インタビューを併用するとよい。 ● 「インタビュー」 （資料編 「インタビュー」 参照） ユーザーに、 現在どのようにして目的を達成しているのか、 機器の操作方法でわかりにくい所 はないか、 それはなぜかを聞く。 観察やプロトコル分析よりも時間はかからないが、 ユーザーの答 えに無意識のうちに嘘が混じったり、 質問者の顔色をうかがったりすることがあり、 データの信頼性 が完全には保証されない。 ● 「ブランクフェースモデルを使った演技法」 （資料編 「ユーザーの概念モデルの分析手法」 参 照） この手法は、 同種の目的を達成する既存の機器が見当たらないときに特に有効である。 ● 「プロトコル分析」 （資料編 「プロトコル分析」 参照） 上記のようなことを、 より深く分析したいときには発話プロトコルを分析する。

2-16

ユーザー分析

心理的メカニズムの分析

目的

生理的機能の分析

心理的メカニズム、 生理的機能、 解剖学的特性、 社会・集団の価値体系が、 ユーザーの心的

解剖学的特性の分析

て、 実際の操作に影響する部分もある。

情報処理にどのように影響するかを分析する。 また、 解剖学的特性は、 心的情報処理とは独立し

社会・集団の価値体系の分析

指針 動機付けや早く終わらせなければならないといったストレスなどがかかると、 ユーザーは心理 的／感情的に普通と違う状態になる。 また、 疲労度や環境からくる生理的ストレスでも、 ユーザー は生理的に普通と違う状態におかれる。 さらに、 肉体的条件などで、 機器を設計する際に考慮し なければならないことがあるであろう。 このような、 ユーザーの心的情報処理に影響する要因の分 析が、 より厳密なユーザーインターフェース設計には必要となるであろう。 また、 ユーザーのキャラクター （性格や好み） 、 置かれている社会的条件 （オフィスで使うなら会 社の文化など） なども、 ユーザーインターフェース設計をする際に考慮すべきである。 特に、 概観 のデザインに対する社会的、 または集団的価値判断は、 商品そのものの価値判断にも通じるた め、 商品設計で特に注目されるところである。 しかし、 これらの要因のユーザーインターフェース 設計に対する影響のしかたの適切なモデル化が現状では確立されていないため、 その分析の 枠組みについても不明確な部分が多く、 今後の研究課題として多くの問題が残されている。

方法 心理的メカニズム、 生理的機能、 解剖学的特性、 社会・集団の価値体系といった問題に対し て、 個々の問題のレベルでは、 長い研究の歴史がそれぞれに存在する。 しかし、 それがユーザー インターフェースに対してどのように影響を与えるのか、 また、 生理的要因が心理的メカニズムに 影響を与えた結果、 それがユーザーインターフェースにどのように影響するかにについては新た な研究課題である。 それぞれ個々の研究アプローチの方法として、 現在下記の方法がとられているが、 それぞれ が心的情報処理にどのように影響するかという問題には新たなアプローチの方法がとられると予 想される。

課題

現状でのアプローチの方法

心理的メカニズムの分析

認知科学、心理学

生理的機能の分析

生理学

解剖学的分析

人間工学

社会・集団的価値体系の分析

社会学や文化人類学

表2-1 分析課題と現状でのアプローチ方法

ユーザー分析

2 -17

参考文献として下記のものがある。 ●参考文献 「図説エルゴノミクス」 （編集委員長：野呂影勇 日本規格協会刊） ●参考文献 「人体計測データベース編集に関する事業報告書」 （社団法人 人間生活工学研 究センター） ●参考文献 「航空自衛隊員の身体計測値」 （航空開発実験集団 航空医学実験隊） 自衛隊員の値なので、 普通より若干体格がいいことが予想されるが、 整備員まで含めた値な ので、 世の中の平均からそれほどずれていることはないと思われる。 ●参考文献 「使いやすさ関連データブック」 （編集：商品テストラボ） 世の中にある規格／ガイドラインや人体計測値を、 商品テストラボにて集めて編集したもの。 ●参考文献 「高齢者特性データ集」 （編集：商品テストラボ） 世の中にある高齢者に関する各種データを、 商品テストラボにて集めて編集したもの。 ●参考文献 「バリアフリーの商品開発」 （E&Cプロジェクト編 日本経済新聞社） ●参考文献 「ECHOプロジェクト 製品ガイ ドライン」 （商品テストラボ） ソニー内で視覚障害者に使いやすい商品の検討を進めた結果、 作定されたガイ ドラインをま とめたもの。

2-18

ユーザー分析

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

ユーザーインターフェース設計の方法を語る場合、 設計をどのような手順で進めたらよいかと

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

いった手続き的方法を推奨することはあまり役に立たない。 例えばある機器のある機能を表現す る記号 （アイコンや表記） を調査して、 どの記号が最も認知されているかを統計的手法で調べる といった設計手順があったとして、 同じ手順を別の機器の別の問題には適応できない。 このよう な手続き的な方法よりも「 、ユーザーインターフェース設計の設計対象は何か」 ということを意識す ることが設計を効率よく確実に進める上で重要である。

なぜ 「構造」 と 「構文」 とに分けられるのか

○

○

○

○

○

これは、 人の知識が 「それは何か、 どうなっているのか」 といった 「宣 言的知識」 と「 、いかに∼するか」 という 「手続き的知識」 とで記述で きることと同じ理由である。 つまり「 、構造」 と 「構文」 の枠組みで理解 し、 「構造」 と 「構文」 の枠組みで人に情報を伝える。 ユーザーインター フェース仕様書も、 この 「構造」 と 「構文」 に基づいて記述される。 仕様書の記述に関しては 「ドキュメント化」 参照

図2-12に示すように、 ユーザーインターフェースの設計対象は、 「構造」 と 「構文」 とに分けられ る。 構造とは、 機器を構成する部分の個々の定義と、 個々の部分の全体の中の位置付けのことで、 操作系の名称や記号、 形態や質感、 さらに配置などである。 また、 構文とは、 機器を操作するとき の文法のことであり、 機器に共通する 「選ぶ」 「 、動作させる」 「 、止める」 といった操作のルールや、 個々の機能の操作手順、 機器のシステム状態の遷移や、 ユーザーへガイダンスを出すポイントや、 さらにユーザーの操作に対する機器の反応の仕方などである。 ユーザーインターフェース設計の目に見えるアウトプットは、 実際にはユーザーインターフェース 仕様書を完成させることであるが、 このユーザーインターフェースの仕様書もまた、 構造の記述部 分と構文の記述部分とに分けることにより、 内容が明確になる。 また、 ユーザーインターフェース設 計をする場合に、 「構造の設計は十分か」 「 、構文の基本作法で抜けはないか」 とか、 「今設計しよ うとしている対象は構文だ」 というように意識する事により、 設計自体をメタ認知的にコントロール して進めることができる。

操作系の名称、記号

構造

操作系の形態、質感、フィーリング 操作系の配置 ルックス（外観デザイン）

作法（操作ルール）：選ぶ、動作させる、止める、増やす...

構文

操作手順

1 システムの状態の遷移

2 3

pipi

ガイダンス：メッセージ、ユーザーの誘導のしかた レスポンス：機器の応答

図2-12 ユーザーインターフェースの設計要素。 構造とは、 機器を構成する部分の個々の定義と個々の部分の全体の位置 付けのことであり、 構文とは、 機器を操作するときの文法のことである。

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

2 -19

分析から設計へ

ユーザーインターフェース設計では、 要求を満足するユーザーインターフェースの解決策に的 を絞るための分析作業と、 分析結果から実際のユーザーインターフェースを設計する作業に分 けられることは前に説明した。 この分析の枠組みと、 ユーザーインターフェースの設計対象を構造 と構文の枠組みでまとめたのが図2-13である。 心的情報処理の分析には、 ユーザーインターフェースの設計要素の中核部分が対応する。 ボ トムアップ的に、 心的、 生理的分析に対応した設計要素、 そして、 人間工学的分析に基づいた構 造部分が関係する。 また、 トップダウンとして、 社会、 集団的価値感によるルックス （見た目の形状 と質感） が影響する。

外観デザインが重視される理由

○

○

○

○

○

○

○

○

デザイン要素としての 「ルックス」 は、 社会的価値観に大きく影響す

分析の枠組み

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

社会、集団的 価値体系の分析

構造 ルックス

るため、 特に注目されやすい。

操作系の名称、記号 構造 操作系の形態、質感 操作系の配置 心的情報処理 の分析

心理的メカニズムの分析 認知、感情

作法 操作手順 構文 システムの状態の遷移 ガイダンス レスポンス

フィーリング 操作系の形態 構造 操作系の配置 ルックス

生理的機能の分析

人間工学的分析

構文 レスポンス

図2-13 分析の枠組みと、 個々の設計要素との関係。 この図から、 分析結果から何がわかるか、 また逆に、 設計のために何 の分析が必要かがわかる。

2-20

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

ユーザーインターフェー

コンセプト設計と詳細設計

ス設計の進めかた

ユーザーインターフェース設計は、 ボタンの配置や本体形状といったハード的な要素に加えて、 表示パネルの機能や、 ソフトウエアのロジックなどすべての機能要素に関連している。 そのため、 手作り試作や金型試作といった実設計の段階に入る前、 例えば他の設計が原理的な試作を行っ ている時期にユーザーインターフェースの設計は、 その基本的な部分を終了していなければな らない。 そのため、 ユーザーインターフェース設計は、 図2-14に示したように 「UI（ユーザーインター フェース） コンセプトの決定」 の段階と「 、実設計」 の2つの段階に分けられる。 そして、 ユーザーイ ンターフェース設計では、 実設計の段階よりもコンセプトの設計の段階が重要となる。 実際、 ユーザーインターフェース設計のプロセスが現在の設計プロセスに導入されたならば、 ソフトウエア、 メカ、 電気の個々の設計は、 ユーザーインターフェース設計からの仕様書待ちの状 態になる。 そのため、 実際の設計に入ってからユーザーインターフェースの仕様を検討しはじめ たのでは遅すぎ、 実設計がはじまる前に、 ソフトウエア、 メカ、 電気の個々の設計が設計にとりかか ることのできるレベルまで決定しておかなければならない。 逆に、 このようにすることにより、 実設計 に入ってからの代替案の検討や仕様の大幅な変更が少なくなり、 設計トータルでの効率は上が るものと予想される。 ただし、 このコンセプトを練るために使用する工数は一般的には多ければ多いほど良いので あるが、 本書 「はじめに−ユーザーインターフェース設計とコスト」 で述べたように、 コンセプト出し にかけるコストと、 そこから得られるアウトプットの品質とのトレードオフから決定されるべきである。

UIコンセプトの決定

実設計

UIの8割方は決まっている

ソフトウエア設計 UI企画書 メカ設計

電気設計

（原理試作などが行われている時期）

図2-14 ユーザーインターフェースの設計は、 他の設計がスタートを切る前までにその基本的な部分を終了していなければ ならない。 UI企画書には、 他の設計がスタートを切れるレベルの情報が盛り込まれている必要がある。

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

2 -21

設計−評価のサイクル コンセプトを決めるためのユーザーインターフェース設計や、 実設計段階でのユーザーインター フェース設計も、 その進めかたは図2-15に示すように設計−評価のサイクルを回して進められる。 これは、 ユーザーインターフェース設計がシステム工学の手順を踏み、 ヒューリスティックに設計 が進められるためである。

分析 設計

代替案検討

シミュレーション

評価 最適化 図2-15 ユーザーインターフェースは設計−評価のサイクルを回して最適化が図られる。

2-22

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

UIコンセプトの決定

目的 手作り試作や金型試作といった実設計の段階に入る前に、 他の設計がスタートを切れる状態 までユーザーインターフェースの仕様を固める。 ここでのアウトプッ ト ・ユーザーインターフェース企画書 ・承認のためのモックアップ

指針 すでに述べたように、 ユーザーインターフェース設計のプロセスが現在の設計プロセスに導入 されたならば、 ソフトウエア、 メカ、 電気などの設計のうち、 ユーザーインターフェースに関わる部分 の設計は、 ユーザーインターフェース設計からの仕様決定待ちの状態になる。 そのため、 実際の 設計に入ってからユーザーインターフェースの仕様を検討しはじめたのでは遅すぎ、 コンセプト 決定の段階で、 他の設計が設計にとりかかることのできるレベルまで仕様を詰めておく必要があ る。 コンセプト決定にかける時間は、 原理試作を行う機器ではその時期に行うのがよいであろう。 また、 原理試作を行わない場合は、 コンセプト決定にかける時間と実設計をはじめる時期とのバ ランスから判断すべきである。 コンセプト決定のプロセスでのアウトプットは、 「ユーザーインターフェース企画書」 である。 ユー ザーインターフェース企画書には、 ユーザーインターフェースのアイディアを出し、 それを評価す るプロセスを通して決定したことが記述される。 ユーザーインターフェース企画書については、 「ド キュメント化−ユーザーインターフェース企画書」 参照。

コンセプトの決定

2 -23

方法 コンセプト決定までの標準的なプロセスを図2-16に示す。

1

概念モデルのデザイン ブレスト（分析結果をもとに） ・適切な概念モデルは何か ・利用できるメタファーはあるか アイディアスケッチ ・システムモデルとして適切か ・アイディアが展開しやすいか ビジュアル／サウンドの計画 ・概念モデルを適切に伝えるには？ ・機器の制約上可能か

2

構造のデザイン ・概念モデルを忘れずに ・ユーザーにとって自然なものに ・シンプルに

3

構文のデザイン ・全体構造から徐々に細部の構造へ ・一人から少人数への分担

4

シミュレーション ・目的に合わせたレベルで

5

評価 ・目的に合わせた評価方法で

6

モックアップ作成 ・承認者にわかりやすいように

7

コンセプトの承認 ・承認会議を開く

図2-16 コンセプト決定の標準的なプロセス。

2-24

コンセプトの決定

実設計

目的 機器の実設計スケジュールに合わせてユーザーインターフェース仕様を完成する。 ここでのアウトプッ ト ・ユーザーインターフェース仕様書

指針 実設計の段階に入ると、 手作り試作、 金型試作へ向けて設計が進む。 この段階では、 電気、 メ カ、 ソフトなどの具体的な設計仕様と、 ユーザーインターフェースの仕様がお互いに関係しあいな がら決まっていく。 決定したユーザーインターフェースの仕様は 「ユーザーインターフェース仕様 書」 に順次記入される。 このユーザーインターフェース仕様書は、 設計に関わるメンバーが共有す べきものであり、 内容に変更が生じた場合にはその都度アップデートされるべきである。 ユーザー インターフェース仕様書については、 「ドキュメント化−ユーザーインターフェース仕様書」 参照。 また、 この実設計段階では、 設定された納期へ向けての工程の管理技法がプロセス全体に対 して用いられるべきである。

方法 設計の管理技法として以下の方法などがある。 ● CPM（Critical Path Method） 作業遂行に必要な時間と経費の両方を同時に考慮し、 所定の後期に対して最小費用、 最小時間でプロジェクトを完成させる。 ● デルタチャート 既知の活動のスタティックなシーケンスを描き、 これを管理する。 参考文献として下記のものなどがある。 ●「システム技法ハンドブック（ 」竹村伸一 著／日本理工出版会） ●「ソフトウエア技術レビューハンドブック（ダニエルP.フ 」 リードマン 著／TBS出版会）

実設計

2 -25

利用者案内

目的 ユーザーインターフェースの一部であるマニュアル、 オンラインヘルプ、 ガイダンスメッセージ などの役割と構成を決める。 ここでのアウトプッ ト ・利用者案内の構成

指針 マニュアル、 オンラインヘルプ、 ガイダンスメッセージなども機器とユーザーとのインターフェー スの一部である。 ユーザーがマニュアルなどの情報をいっさい必要とせずに機器を使用するこ とができれば理想的ではある。 しかしこの状況というは、 これから使用する機器に対して、 ユーザー が必要となる情報をすでに獲得している場合である。 実際にはユーザーは機器を使用するため に新たな情報を獲得しなければならない。 そして多くの場合、 情報の獲得は実際の機器のインター フェースからよりもマニュアルなどから得ることになる。 利用者案内の種類 利用者案内は図2-17に示すように、 機器のインターフェースの一部として組み込まれている ものと、 機器の外部に存在するものがある。

機器

機器 UI

UI

ユーザー 機器のユーザーインターフェースに組み込まれているもの ・オンラインヘルプ ・オンラインマニュアル ・オンラインガイダンス ・オンラインチュートリアル ・デモプログラム 図2-17 利用者案内の基本的分類。

2-26

利用者案内

ユーザー 機器と独立しているもの ・マニュアル類 ・カタログ ・コマーシャル

ユーザーの目的と利用者案内の種類 マニュアルやパンフレッ トなどは機器の操作の視点からだけではなく、 ユーザーの目的により表 2-2のように分類できる。

メディアの配布形態 ユーザーの目的 紙 買いたい

オンライン デモプログラム

カタログ

（コマーシャル）

習いたい

チュートリアル

使いたい

マニュアル類

オンラインチュートリアル オンラインヘルプ オンラインマニュアル

表2-2 利用者案内をユーザーの目的により分類する「 。紙とオンラインの資料の分類」 （Duffyら 1992） を追加修正。

ユーザーの知識レベルと利用者案内の構成 SSOAモデル （ 「ユーザー分析」 参照） によるユーザーの知識分析を利用者案内の構成に適 応することにより、 利用者案内の構成立ての指標を得ることができる。 表2-3（次ページ） はユーザーの知識レベルごとに、 紙およびオンラインの利用者案内を対応 させたものである。

方法 マニュアルの作成に関しては下記のものがまとめられている。 ●「ソニー・マニュアルガイドライン」 ●「和文マニュアルライティングルール集」 ●「フォーマット・ライティングルール集」 ●「The Sony Document Design Center Style Guide」

利用者案内

2 -27

対応する利用者案内

ユーザーの知識レベル 紙 カタログ

知識

・知識がまったく無い場合

チュートリアル

タスク

構文

チュートリアル

知識

・機器を使って行うタスク は知っている場合

オンラインチュートリアル

プロシジャー

操作

対象

タスク

機器 意味

構文

機能リファレンス

知識

・機器を使って行うタスク ・機器を使った操作の概念 を知っている場合

オンラインガイダンス オンラインマニュアル

操作

操作

対象

タスク

対象 機器

意味

構文

早わかり （クイックリファレンス）

知識

・機器を使って行うタスク ・機器を使った操作の概念 ・実際の操作方法 を知っている場合

アンチョコ （カード形式など） 操作

操作

対象

タスク

対象 機器

意味

表2-3 ユーザーの知識レベルと対応する利用者案内。

利用者案内

デモプログラム （コマーシャル）

機器 意味

2-28

オンライン

構文

オンラインヘルプ

シミュレーション

目的 設計しているボタン、 つまみなどのユーザーインターフェース要素が目的通り機能するかを設 計途中で判断可能なものとする。 さらに全体として要求仕様を満足するかどうかの評価ができる 形態にする。 ここでのアウトプッ ト ・目的に応じたシミュレーション

指針

シミュレーションの2つの目的 シミュレーションを行う目的には2つの意味がある。 ひとつは、 現在設計しているユーザーイン ターフェースが目的通り正しく機能するかどうかを設計途中で判断可能にするということである。 このことは、 逆に言えばユーザーインターフェースがシミュレーション可能であるということである。 シミュレーション可能であるということは、 対象物が全体として目的を持った2つ以上の相互間の 機能が規定された要素から構成されているというこであり、 これはユーザーインターフェースを構 成するボタン、 つまみ、 表示などの個々の要素がひとつの 「システム」 を構成しているということに 他ならない。 あるシステムを設計するためには、 シミュレーションによりシステムの挙動を見ながら設計を進 める方法がとられる。 つまり、 ユーザーインターフェースの設計は、 そもそもが、 シミュレーションを行 いながら設計を進めるものなのである。 もう一つの目的は、 設計したユーザーインターフェースが、 要求仕様を満足するかどうかの評 価ができる形態にすることである。 評価可能な形態にするためには、 アイディアを外在化しなけれ ばならないが、 シミュレーションはこの目的のためにも行われる。 シミュレーションのレベル シミュレーションは、 頭の中で行うレベルからコンピューターを使用したもの、 さらには、 実際にも のを作り一定期間テスト的に導入するといったレベルまである。 どの方法を選択するかは、 目的 とコストによって判断する。 また、 設計のアイディア出しのためのシミュレーションは、 ユーザーイン ターフェース設計者個人が最もやりやすくアイディアを出しやすい方法をとることになる。

シミュレーション

2 -29

シミュレーションの水平型／垂直型 （Nielsen） J.Nielsenによると、 システムのシミュレーションには垂直型と水平型があり、 垂直型とはシステ ム全体の中の１部分の機能のみを実際のデータやタスクでテストするもの、 水平型とは全ての機 能を網羅するが実際の環境やデータは使わないものである。 また、 機能も１部分のみで、 環境や データも実際のものを使わないで、 あらかじめ考えたシナリオに沿って評価する方法もある。 この 方法だとプロトタイプの作成にそれほど手間をかけずに、 ある程度現実的な結果が得られる。 こ のように、 シミュレーションは、 すべての機能に対してきちんと作り込む必要はなく目的にあった 「部 分」 の作成で十分である。

コンピューターシミュレーションによる評価

ユーザーインターフェースのコンセプト設計の段階では、 動く試作品はまったくない状態である

での考慮事項

ことが多い。 専門家が評価する場合は、 アイディアやスケッチなど紙の状態でも評価できるが、 ユー ザーによる評価は紙だけではむずかしい。 そこで、 コンピューター上にシミュレーションを作成す ることが特に有効となる。 しかし、 シミュレーションで実際の状態を完全に再現することはできない。 シミュレーションによる評価の限界や評価の際注意すべき点として下記の事項が予測される。 シミュレーションで評価を行う際には、 これらの欠点をふまえて、 モックアップによる評価を併用す るなどの対応が必要である。 ほぼ完成品と同様に評価できる部分 シミュレーションが管面に表示されるものであることを考えると、 管面メニューなどはほぼ再現 できる部分であると考えられる。 しかし、 メニュー操作をマウスを使って行う場合と、 機器に付属さ れるリモコンを使って行う場合とでは、 かなり操作感が違う場合があるので注意しなければなら ない。 機器に付属されるリモコンと類似のリモコンを使って操作できればさらによい。 評価できない部分 ●見る／さわるといった 「扱いやすさ」 に関する部分 管面のシミュレーションである以上、 機器の物理的操作感は当然ながらわからない。 物理的操 作感の例としては以下のものがある。 ・ 液晶表示／LED等の明るさや見やすさ ・ ボタンの感触／操作部への力の入れ具合 ・ 携帯した感じ （手になじむか、 等） ・ メカ的な動き （押すと開きパチンと閉じる蓋、 等） （実際にどのように動くか想像してもらうことは可能） これらは、 ちょっとした設計上の手違いから、 扱いにくいものになってしまう可能性があるが、 ほ とんど完成品に近い試作品ができないと評価することができない。 ●立体的な構造物としての把握 携帯用の機器の場合、 表裏両方にボタンが配置されていることが多い。 ユーザーが自然に機 器を裏返して裏のボタンをみつけることができるかといったことを知りたくても、 １つのシミュレーショ ン画面に表裏両方の図が表示してあったのではわからない。 １つの画面の図は表だけにして、 「裏 返す」 「裏面を見る」 といったボタンを画面に別途作ることでだいぶ救えるが、 これでも何らかのバ イアスはまぬがれない。

2-30

シミュレーション

●機器の大きさについての認識 ボタンの扱いやすさや携帯性など、 大きさで判断したいことはあるが、 大型の機器の場合物理 的に画面上に大きさを再現できない。 小型の機器で、 実際と同じ大きさにコンピューターシミュレー ションを作成することができても、 表示するディスプレーの大きさで変化してしまうこともある。 実際 に実物と同じ大きさで画面上に再現されていても、 画面上では実際より大きめに見えてしまうこと があり、 正しい判断はむずかしい。 なお、 タバコの箱等、 比較の対象になるものを同一画面に描い ておくのは判断の助けになる。 ●機器の重量やバランスについての認識 管面上のシミュレーションである以上、 当然機器の重さはわからない。 何グラムかを教えたり、 同じぐらいの重さの物を持ってもらうこともできるが、 実際に持った感じがどうなるのかはやはりわ からない。 評価する際に注意が必要な部分 ●アイコン表示とボタンの区別 アイコンや枠つきの文字表示などを、 ボタンと間違えて押してしまいやすい。 これは、 ボタンも表 示も、 画面上ではただの絵だからである。 これを防ぐには、 ボタンは押せるということがはっきりわ かるように立体的に描き、 アイコンは機器の表面上に載っていることがわかるように平面的になる よう、 うまく描かねばならない。 ●機器の立体感や厚みの認識 うまく絵が描かれていないと、 立体感や厚みがわからず機器の全体の感じが把握できず、 得 られるはずのアフォーダンスが得られないことがある。 ●点灯／点滅の表現 管面はいわば全て光っているので、 イルミネーション等の光が表現しにくい。 が、 明るい色を使 うことによって、 ある程度表現することはできる。 ●関係する全ての機器をシミュレートする困難さ 通信等で他の機器にも影響を及ぼす場合、 関係する全ての機器のシミュレーションプロトタイ プを作成する時間やマンパワーがない場合が多い。 この場合は、 実験者が口で説明したり、 画面 上に簡略図や文字表示を出すことで、 かなりの部分を補える。 ●シミュレーション自体の完成度 連続的な動きの場合、 スムーズな動きに見せるためにはかなり多くの絵を描かなければならな い。 全ての動きを実物と同様にスムーズに動かす必要はないので、 どの部分のアニメーションに 力を入れどの部分に手を抜くかを、 評価の目的に合わせて考慮する必要がある。 その他に注意する点 コンピューターに慣れている人が操作する場合はいいのだが、 商品のターゲッ トユーザーに合 わせて高齢者などを被験者として使う場合、 マウス操作に慣れていないことが多いことに注意し なければならない。 マウスを使わずにタッチパネルにした場合も、 指を離した時に反応するなど、 ボタンの操作感とは違う部分がある。 また、 被験者の抽象的思考力 （シンボル操作能力） が低い場合、 どうしても実際の機器を操作 しているつもりになれず、 実際の状況とは違うことをしてしまうことがある。 これには、 シミュレーショ ンそのものや周囲の状況を、 なるべく現実に近づけることで対応するしかない。

シミュレーション

2 -31

実験者の教示で補うべき点 ●操作上の相手役が必要なとき 電話など一人で操作する機器ではない時、 だれかが相手役になった方が自然に操作できる。 シミュレーションに音声を組み込むこともできるが、 実験者が相手役になった方が柔軟な対応が できる。 ●シミュレーションが完全ではないとき あくまでもシミュレーションなので、 実際と同様には動かないことがある。 また時間の関係上、 完 全に動くようには作り込めないこともある。 評価をする際、 上記のような不十分な点を事前に説明 しては操作のヒントを与えることになってしまう場合がある。 この場合は、 問題の箇所に突き当たっ た時に、 完全ではない旨、 実験者が説明するようにする。 シミュレーション作成時に考慮すべき点 有効性の高いユーザーインターフェース評価を行うことのできるコンピューターシミュレーショ ンを作成するためには、 以下のようなことに注意する必要がある。 ●外界の変化をユーザーに示す場合はユーザー側に立った表現で 機器の絵の上ではなく画面の隅に直接描かれたボタンで、 環境の変化や他の機器の状態の 変化をコントロールすることがある。 このボタンをユーザーに操作してもらいたい場合は、 ユーザー の視点に立った表現にしなければならない。 実験者が操作するボタンである場合も、 ユーザーが シミュレーションを操作している間に無用の混乱をおこさないようにするためには、 ユーザーの視 点に立った表現になっている方が望ましい。 （たとえば 「着信」 ではなく 「外から電話がかかってく る」 とする） 画面上に直接描かれたボタンの説明は、 最初にしておくのが望ましい。 ●シミュレーションを外部に発注する際の注意点 内部でシミュレーションを作成するのではなく、 社外や他の部署に作成を依頼する際、 シミュレー ションの目的がユーザーインターフェース評価であることを明示する必要がある。 どのような目的 で、 どのような評価を行うためのシミュレーションであるかよく説明し、 必要なら仕様書等を提出す る方がよい。 作成する人がよく理解していないと、 小さな不都合が評価実験に大きな支障をきた すことになる。 ●操作を表わす表題を画面につけない 機器の名前等の表題はつけてもかまわないが、 操作を表わすような表題 （ex.「予約録画」 ） を 画面上につけると、 操作のヒントになってしまうことがあるので、 そのような恐れのある表題は書い てはならない。

2-32

シミュレーション

方法 設計、 評価目的とそこで利用されるシミュレーションの形態について表2-4に示す。

設計／評価目的

シミュレーションの形態

設計／評価手法

構造評価

・スケッチ ・コンピューターなどを利用した シミュレーション

・Heuristic Evaluation ・ガイドラインに基づい たチェックリスト ・QUIS

構文評価

・操作仕様書 ・取扱説明書 ・コンピューターなどを利用した シミュレーション

・Heuristic Evaluation ・QUIS ・ガイドラインに基づい たチェックリスト

構造と構文の ・コンピューターなどを利用した シミュレーション 評価 ・試作機

・Heuristic Evaluation ・観察／統制実験 ・ガイドラインに基づい たチェックリスト ・パフォーマンス測定

表2-4 設計／評価目的とそこで利用されるシミュレーションの形態。 さらに、 設計／評価方法も載せる。

ユーザーインターフェース設計では、 コンピューターを用いたシミュレーションが有効な場合が 多い。 コンピューターを用いたシミュレーションを行うための機器およびソフトウエアには下記のも のがある。 コンピューター本体 評価行う場合、 モニターには必要に応じてタッチパネルがあると良い。 シミュレーションのソフ トによっては、 シミュレーションを作成した機器と再生する機器とで処理速度が異なると、 タイミン グが合わなくなるといった問題が発生するため、 作成する機器と再生する機器は同程度のもの がよい。 シミュレーション用ソフトウエア ●HyperCard：カード型のデータベースソフトであるが、 これを、 機器のシミュレーションに利用 できる。 1枚のカードにボタン、 グラフィック、 テキストを配置することができ、 HyperTalkというオブ ジェクト指向のプログラム言語機能を持っているため、 柔軟なシミュレーションを作成できる。 アッ プル社が作成しているためQuickTimeやAppleイベントレベルの制御もできる。 ただし、 現在 のバージョンでは基本的には、 白黒であることと、 コンパイルしないと動作速度が遅いという問題 がある。 しかし、 使いやすさの点から言えばデザイン過程では非常に有効なツールである。 値段 は機能限定版 （"magic"コマンドですべての機能を使えるようになる） はMacintosh本体に付 属されている。 市販のものは3万円前後。

シミュレーション

2 -33

●Macromedia Director：マルチメディアタイトル作成で現在主流のソフトウエア。 これを、 機 器のシミュレーションに利用できる。 Lingoというオブジェクト指向のプログラム言語機能を持っ ているため、 かなり柔軟な制御ができる。 ただし、 絶対的な時間制御ができないため、 機器の処 理速度に動作速度が依存する。 作成方法は、 ステージ、 キャスト、 スクリプトという 「舞台」 メタファー で行うためちょっとした慣れが必要。 値段は15万円前後。 ●Authorware：機能的には、 Macromedia Directorとほぼ同じである。 こちらはCBT （Conputor Based Trainning） から出発したもので、 現在は駿台予備校が版権を得ている。 作成方法が 「舞台」 メタファーではなく、 アイコンを論理的にならべていく方法のためたいへん作 成しやすい。 ただし、 Macromedia Directorと競合しないようにしたためか、 一般用というより も教材作成でのシステム売りとなっており、 価格も100万円のレベル。 素材作成用ソフトウエア Macromedia Directorでシミュレーションを行うには、 素材となる絵や音を作成しなければ ならない。 素材作成用ソフトウエア選択で注意すべきポイントは、 使用するシミュレーションソフト がハンドリング可能なファイルフォーマットで保存できるものを選ぶこと、 また、 絵の素材作成では 作成する絵のデータのカラーパレット情報をコントロールできるものが必要である。 これら素材作成用ソフトに以下のようなものがある。 （絵）

2-34

シミュレーション

SuperPaint：ペイントとドローの両方で絵を作成できる。

（動画）

Adobe Premiere：QuickTime編集ソフト。

（音）

SoundEdit：音のサンプリングと編集ソフト。

評価

目的 ユーザーインターフェース設計の各段階において、 要求仕様を満足しているかを判定する。

指針

設計プロセスに評価を入れること自体の困難さ すでに述べたように、 ユーザーインターフェース設計は設計と評価を繰り返して進められる。 と 分析

ころが、 この 「設計と評価を繰り返して進める」 ということが実際の設計が動き出したときに一番難

設計

しく、 実現されない部分なのである。 つまり、 評価にかけるコストとそこから得られる結果とのトレー 代替案検討

シミュレーション

ドオフを考えたときに、 評価の重要性が認識されにくいということがある。 つまり、 評価に時間をか けるくらいなら、 その分その時間を設計に回したいと考えるのである。 そしてさらに、 本質的に評 価はやりたくないという意識がある。

評価 最適化

この問題の出所として考えられるのは、 現状の評価が 「評論」 、 つまり一般的社会的な価値基 準での評価になってしまっているということがある。 いわゆる評論であれば、 設計者自身が設計 を行いながら常時やっているわけであり、 よけいな時間をとってやるだけの価値はない。 ここで重 要になるのが設計に先立って要求仕様をきちんとまとめておくということである。 要求仕様には、 開発に携わるメンバーでコンセンサスが得られた評価基準が記述されており、 設計結果が要求 仕様を満足しているかどうかを品質基準のものさしにすることによって評価結果の価値も明確に なる。 また、 自分の設計したものを評価されたくないと考えるのは、 その評価がやはり評論であるから である。 そのような評価では、 設計者は、 設計者自身の価値観が評価者の価値観で評論されて しまうことを察するのである。 評価が、 製品の要求品質基準として行われれば、 またいくつか出し たアイディアの最適化を行うプロセスとして機能すれば、 評価のプロセスが動き出すであろうと 考えられる。 評価のタイミング 要求仕様を満足しているかの評価を行うタイミングとして以下が考えられる。 ●UIコンセプトの評価：UIコンセプトとして検討可能なレベルにアイディアを絞り込んだあと。 評 価対象としては、 アイディアスケッチのような紙のものや、 コンピューターによるシミュレーションな どのプロトタイプが使われる。 ●仕様書／試作品の評価：UIコンセプトが決定し、 実設計に入ったあと。 評価対象としては、 設 計仕様書や手作り／型物試作品などになる。 ●最終製品の評価：この段階ではもう当該商品に評価結果をフィードバックできないが、 次ロット や後継機種でのバージョンUP要件や、 ご相談センターなどへの商品情報にフィードバックできる。

評価

2 -35

方法 設計−評価のプロセスとして、 受け入れ検査や並行設計などがあるが、 （ 「設計プロセスを効 率よく進めるために−設計の進め方」 参照） 判定をするためには何らかの点数化が必要である。 単純に物理的に測定可能なことのみを測定するのがパフォーマンス測定。 Heuristic Evaluation ／QUIS／観察では、 頻度や重大性といった観点から人が判断して点数化を行う。 チェックリス トでは、 単純に不合格がいくつあるかで判定する場合と、 それに重大性などの観点を取り入れる 場合がある。

評価方法

紙のアイディアスケッチから試作品まで、 ほとんどあらゆる場合に使える手法。

QUIS （資料編「Cognitive Walkthrough」の項参照）

動くプロトタイプがない紙の段階、特に仕 様書の評価に有効である。

観察法（資料編参照）

動くプロトタイプがある場合にはどの段階 でも使える。最終製品の評価では特に有 効。

ガイドラインに基づいたチェッ クリスト

だれでも評価できるのが利点。試作品の確 認や出荷判定などのとき特に有効である。

パフォーマンス測定 （資料編参照）

動くプロトタイプがある場合に使う。いく つかの案の優劣を判定したり、最初に設定 した基準を満たしているかを判定する場合 に有効。

表2-5 評価方法の種類とその内容。

2-36

評価

内容

Heuristic Evaluation （資料編参照）

承認を得る

目的 ユーザーインターフェースのアイディアの承認を得る。

指針 ユーザーインターフェース設計プロセス全体を見たとき、 ユーザーインターフェースの内容は、 コンセプトを決める段階でほぼ決まってしまう。 そのため、 ユーザーインターフェースのコンセプト がまとまった時点で、 コンセプトの承認を得ておくことが必要である。 承認を得るためにやるべきことは、 承認の決定権を持つ相手にコンセプトを理解してもらうこと である。 これまで設計に携わってきたメンバーの間では、 要求仕様の作成からはじまって、 コンセ プトを作るまでの設計プロセスを通してひとつのコンセンサスが形成されてきている （もし、 メンバー 間でのコンセンサスが得られていなければ、 まずメンバー内での承認を得ることが必要であろう） 。 しかし多くの場合、 承認の決定権を持っている人へは設計途中での様々な事情や制約といった 情報が届いていない場合が多い。 そのため、 設計のメンバー間ではわかっていることが、 わかっ ていなかったり、 そもそも要求仕様に対して設計メンバーと同じコンセンサスを得ていないという 場合もある。 承認をスムーズに得るためには、 次の3つのポイントを押さえる必要がある。 1. 要求仕様を決めるプロセスに承認の決定者を巻き込む。 2. コンセプトをわかりやすく伝える（ 。次の 「プレゼンテーションのためのモックアップ」 参照） 3. コンセプトを決めるプロセスの要所要所で承認の決定権を持つ人を巻き込む。 （次の 「選 好」 参照） プレゼンテーションのためのモックアップ ユーザーインターフェースのコンセプトを正しく伝えるための媒体としては 「ユーザーインターフェー ス企画書」 がある。 しかし、 企画書はアイディアを主に言葉を使って 「まとめた」 ものである。 設計に 関わってきたメンバーの間ではこれから作ろうとしている商品のイメージがすでに形成されてい るため、 そのイメージを詳細に定義するドキュメントは容易に理解できるものである。 しかし、 設計 に携わってこなかった人がドキュメントからイメージを構成することは難しい場合が多く、 また労 力を要するものになる。 また、 実際の承認の場で企画書を1ページ目から読む時間をとることは難しいことである。 そこ で、 設計に直接関わらない人 （特に、 製品化の承認権を持つマネージャーなど） に対して、 「これ が、 私達の考えている製品が表面上どのように見えるかを示したものです。 」 というモックアップを 利用することは、 相手に自分たちのアイディアを理解させる上で有効な手段である。 また、 モック アップを見せた瞬間に示す反応により承認者が大筋でYesかNoかを知ることができる。

承認を得る

2 -37

選好 選好の重要性

○

○

○

○

○

○

○

○

○

○

○

○

○

○

選好はアイディアをたくさん出すことでもある。 もし選好を行わなかっ たら、 解の範囲内の任意の点を見つけた時点で設計が止まってし

実際のユーザーインターフェース設計過程では、 制約条件から答えが一義的に決まる場合は 少なく、 一般にある範囲を持った制約条件の中のある1点を答えとする場合がほとんどである。

まう。

図2-18に示すように、 制約条件から解が存在する範囲のうち、 ある任意の点が解となるので

また、 人はあるアイディアを出したときにそのアイディアが解の範囲 内でどれだけ価値があるかということよりも「 、自分が考えた一番最

あるが、 解はこの点である必要はなく、 解の範囲のどの点も正解となりうるのである。

初のアイディアである」 ということに価値を持ってしまう傾向がある。 さらに、 選好を行うための商品価値を計るものさしについての議論 自体が、 設計している商品にとって何が選好か、 つまり 「我々が設計 している商品の商品価値とは何か」 を考えさせることになる。

解の範囲 条件1 制約

解

制約 条件2 図2-18 制約条件で決まる解の範囲の任意の点が解となりうる。 図の解はあくまでも任意の点であり、 他の点も解となり うる。

「選好」 とは 「好きなものを選ぶ」 という意味の造語である。 つまり、 図2-18で示した解の範囲か ら最も好まれる解を選ぶ行為のことである。 商品設計では、 解の範囲の中から 「より商品価値を上 げるものは？」 というものさしで解を探すべきである。 この商品価値を上げる解を探すことが選好で ある。 このような選好のプロセスの中で決定された解に対して承認者に同じ決定を導くには、 どちら が商品価値を上げるのかという選好の際に、 承認の決定権を持つ人を参画させるか、 もしくは情 報を提供するべきである。

方法 ユーザーインターフェースのモックアップには色々なレベルがあるが、 限られたコストと時間の 中で最もアイディアをわかりやすく伝える方法がとられるべきである。 コンピューターを使ったものでは、 シミュレーション作成と同じ環境を利用することができる。 選好について次の文献にくわしく書かれている「 。選好」 という言葉自体は 「要求仕様の探索学」 からとったものである。 ● 「要求仕様の探索学」 p206∼ （D.C. ゴーズ、 G.M. ワインバーグ 著／共立出版株式会社） ● 「決定を支援する」 （小橋康章 著／東京大学出版）

2-38

承認を得る

ドキュメント化

ユーザーインターフェース設計での重要かつメインとなるアウトプットは、 仕様書、 つまり ドキュ メントである。 ユーザーインターフェース設計のプロセスの中で作成される仕様書には、 このあと で説明するように、 「ユーザーインターフェース企画書」 「 、ユーザーインターフェース仕様書」 「 、ユー ザーインターフェースガイドライン」 の3種類が考えられる。 まず、 これらユーザーインターフェース 設計で作成する仕様書全体に関わる一般的な内容について説明する。 構造記述と構文記述 ユーザーインターフェース設計に関わる仕様書の記述には、 「ストーリーボード」 「 、状態遷移図」 、 「ベース画面デザイン」 など色々なものがある。 さらに、 同じ状態遷移図にも、 様々な記述方式があ る。 これらすべてを定義し、 必要なものを洗い出すと考えると大変であるが、 実は必要な仕様書は たった2つの視点のみであると考えると、 現実は非常にすっきりする。 すでに述べたように、 ユーザーインターフェースの設計要素は、 「構造」 と 「構文」 とに分けられる。 そして、 ユーザーインターフェースの仕様書も、 この 「構造」 と 「構文」 の2つの視点から構成される のである。 構造記述とは、 機器を構成する各要素についてその働きや仕組み、 各部位の関係などについ て記述したものである。 例えば、 操作系の構成や、 ボタンの配置、 メニュー構造 （ツリー図） などで ある。 一方、 構文記述とは、 機器にある行為を及ぼしたときの変化について記述したものである。 状 態遷移図や操作手順の記述などがそれにあたる。 適切な記述方法とは 構造記述と構文記述の方式には、 色々な記述の様式が考えられている。 色々な記述の様式の うちどれを使ったらよいのかの答えは、 「設計の現場にあったものを選んで使う」 というのがその答 えである。 そもそも、 ユーザーインターフェースの仕様書は、 ユーザーインターフェースの設計の考え方を、 他の設計者に伝えるためのものである。 そのため、 機器の設計に関わる人達が最も理解しやす い方法が最も良い。 逆に考えれば、 色々ある記述方法のうち、 最適な方法を見つけるということも ユーザーインターフェース設計者がまず 「設計」 しなくてはならない要素である。

ドキュメント化

2 -39

ユーザーインターフェー ス企画書

目的 対象機機のユーザーインターフェース設計の基本的な考え方を明確にし、 ソフトウエア、 メカ、 電気それぞれの設計が設計にとりかかることのできるレベルまでの仕様を記述する。 ここでのアウトプッ ト ・ユーザーインターフェース企画書

指針 ユーザーインターフェース企画書の内容として一般的に考えられる項目を以下に示す。 1 設計上の条件 1-1

UI設計上考慮すべきユーザーの特性

1-2

UI設計上考慮すべき使用状況

1-3

UI設計上考慮すべき設計制約事項

2 基本概念 2-1

利用できる概念モデル

2-2

利用できるメタファ

3 基本構造 3-1

機器の操作系の基本構成

3-2

操作系の基本部分の構造

4 基本操作構文 4-1

基本作法

4-2

ストーリーボード （状態遷移図）

4-3

ガイダンス構造

5 利用者案内 5-1

利用者案内の構成

5-2

使用用語基準

5-3

オンラインヘルプシステム

5-4

取扱説明書

方法 ソフトウェアの構造的記述技法を体系的に網羅した書籍として次のものがある。 ● 「ソフトウェア構造化技法」 （著者：J. マーチン／C. マックルーア 近代科学社）

2-40

ドキュメント化

ユーザーインターフェー ス仕様書

目的 ユーザーインターフェースの仕様を機器の設計開発に関わる人達に伝える。 ここでのアウトプッ ト ・ユーザーインターフェース仕様書

指針 ユーザーインターフェース仕様書の内容として一般的に考えられる項目を以下に示す。 項目 の1から4、 そして6の一部は、 ユーザーインターフェース企画書である。 これに、 実設計の中で決 まったことを追加し、 または変更したものが仕様書となる。 1 設計上の条件 1-1

UI設計上考慮すべきユーザーの特性

1-2

UI設計上考慮すべき使用状況

1-3

UI設計上考慮すべき設計制約事項

2 基本概念 2-1

利用できる概念モデル

2-2

利用できるメタファ

3 基本構造 3-1

機器の操作系の基本構成

3-2

操作系の基本部分の構造

4 基本操作構文 4-1

基本作法

4-2

ストーリーボード （状態遷移図）

4-3

ガイダンス構造

5 UI構造 5-1

表示

5-1-1

ボタン

5-1-2

メニュー

5-1-2-1 メニュー構成ルール 5-1-2-2 ベース画面のレイアウトルール 5-1-3

アイコン

5-1-4

カーソル

5-1-5

フォント

ドキュメント化

2 -41

5-1-6

カラー

5-1-7

視覚効果

5-1-8 5-2

音響効果 入力系

5-2-1 （キーボード／リモコンなど） 配列 5-2-2

入力操作

6 利用者案内 6-1

利用者案内の構成

6-2

使用用語基準

6-3

オンラインヘルプシステム

6-4

取扱説明書

6-5

ご相談センターに伝えるべき情報

7 データ 7-1

ボタン・表示用語一覧

7-2

ガイダンスメッセージリスト

7-3

オンラインヘルプ内容一覧

方法 ソフトウェアの構造的記述技法を体系的に網羅した書籍として次のものがある。 ● 「ソフトウェア構造化技法」 （著者：J. マーチン／C. マックルーア 近代科学社）

2-42

ドキュメント化

ユーザーインターフェー スガイドライン

目的 後継機開発のために、 対象機器のユーザーインターフェース設計の基本的な考え方を残す。 ここでのアウトプッ ト ・ユーザーインターフェースガイドライン

指針 ユーザーインターフェース仕様書は、 設計したその機器の仕様であるが、 その機器に続く後継 機を設計する場合、 まったく同じ設計者グループが設計に関わるとは限らない。 ユーザーインター フェースガイ ドラインは、 後継機開発のために、 どのような考え方でユーザーインターフェースを設 計したか、 どのような判断のプロセスを通して機器のインターフェースが決定されたかを後の設 計者のために残したものである。 また、 後継機開発を、 外部の会社で行う場合にもこのガイ ドライ ンが有効となる。 さらに、 このガイ ドラインを作ることによって、 自分たちの判断を振り返って見るこ とができるという意味でも重要であると考えられる。 ユーザーインターフェースガイドラインの内容として一般的に考えられる項目を以下に示す。 1 設計思想

3 基本構文

1-1

ユーザーの分析

3-1

基本作法

1-2

基本的な設計原則

3-2

基本部分の状態遷移

1-3

グラフィックの使用原則

1-4

プログラミング上の原則

4 UI要素の仕様

2 基本構造

5 各国化への対応

2-1

機器の基本構造

2-2

コントロール系

2-3

表示系

2-4

カラーの使用ルール

2-5

サウンドの使用ルール

方法 参考となるガイドラインとしては、 次のひとつしか見あたらない。 ● 「Apple Human Interface Guidelines（日本語版） （ 」著者：アップルコンピュータジャパ ン株式会社 トッパン）

ドキュメント化

2 -43

アイディア出しの支援

目的 ユーザーインターフェースのアイディアを出すプロセスを支援する。

指針 良いユーザーインターフェースのアイディアを出すためには、 まず、 できるだけ色々なアイディア を出し、 次に、 出したアイディアを絞り込み、 そして最終的に絞ったアイディアが要求仕様を満足 するかを評価するというサイクルを回すことである。 そこで、 できるだけ色々なアイディアを出すと いうことと、 出したアイディアを絞り込むことについの指針を述べる。 できるだけ色々なアイディアを出す アイディアを出す場合、 ともすると良さそうなアイディアがひとつ見つかるとそれで満足しまった り、 あるいはそれに固執してしまいがちである。 また、 そのアイディアがうまく行かなかった場合に は、 あきらめてしまうという傾向が、 私達 （人間） にはある。 この傾向は、 我々が思っている以上に強 いと言われており、 創造的問題解決の大きなネックになっている。 そのため、 現在までに様々な問 題解決法が編み出されているが、 良いアイディアを出すための方法として、 次の2つのポイントを 良く理解しておくことが重要である。 ● 我々人間は、 よさそうなアイディアがひとつ見つかると、 それで満足してしまい、 またそれに 固執してしまいがちであるということをメタ認知する。 ● できるだけたくさんのアイディアを出す手法を積極的に活用する （ 「方法」 参照） 。 良いアイディアを出すための必要条件 アイディアを出すということは、 すでに持っているアイディアのレパートリーの中から答えとして もっとも適切なものを選び出すことである。 そして、 「分析」 という作業は、 持っているアイディアのレ パートリーの中から適切なアイディアに的 （マト） を絞るための作業である。 アイディアのレパートリー が乏しくても良いアイディアは見つからないし、 分析が正しくなくても良いアイディアにはたどり着 けない （図2-19） 。 つまり、 良いアイディアを出すための必要条件は、 次の2点である。 ● 適切な分析を行う ● 豊富なアイディアのレパートリーを持つ

2-44

アイディア出しの支援

分析結果と十分なアイディアのレパートリーがあれば、 そこから適切なアイディアを選び出す作 業は簡単そうであるが、 実際には、 手持ちのアイディアを思考の壇上にあげるということが以外と 難しい。 つまり、 必要なときに適切なアイディアを思い出せるかということである。 そのために、 ブレー ンストーミングなどのアイディアをたくさん出す手法や、 またはいくつかの設計のためのガイ ドライ ンが有効となる。

アイディアのレパートリー

分析 ユーザー

これだ！

アイディアのレパートリー

分析 ユーザー

?

アイディアのレパートリー

分析 ユーザー

?

図2-19 分析は、 アイディアのレパートリーの中から適切なアイディアに的 （マト） を絞るための作業である。 アイディアの レパートリーが乏しくても良いアイディアは見つからないし、 分析が正しくなくても良いアイディアにはたどり着けない。

出したアイディアを絞り込む 出したアイディアを絞り込む方法は、 アイディアの合成と分解である。 つまり、 同じようなアイディ アをまとめること、 そして、 ひとつのアイディアを分解し、 他のアイディアと結合してみることである。 このような手法の代表的なものとして、 KJ法などの手法がある。 また、 ブレーンストーミングでも他 人のアイディアを分解、 または合成して新しいアイディアを出す作業を行う。 このブレーンストーミ ングの手法をデザインに応用したものとしてブレーンドローイングなどがある。

アイディア出しの支援

2 -45

方法 アイディアをたくさん出すため、 さらに頭の中にあるアイディアを思考の壇上に持ち上げるため のヒントとして次の事柄が挙げられる。 発想を豊かにするための教訓 1. 感情的になるな 2. あきらめるな 3. 思いこむな

多様な発想のための刺激剤 1. 視点を変えてみる （マクロに見る、 ミクロに見る、 逆から見る） 2. 馬鹿なことを考える 3. 間違いを恐れない 4. 人の意見を聞く 5. インキュベーション （あたためる／別のことをしてみる） 6. 自分の発想の癖をメタ認知する できるだけ色々なアイディアを出し、 出したアイディアを絞り込むための色々な手法がこれまで に考案されている。 アイディアをたくさん出すための手法 1. ブレーンストーミング アイディアを出すことを目的とした会議方式。 「判断禁止」 「 、自由奔放に」 「 、多量なアイディ アを出す」 「 、結合の改善」 という4つの基本的ルールをもとにアイディアを出す。 2. ブレーンドローイング ブレーンストーミングと同じ手法をデザインで行う。 参加者はアイディアを言葉ではなく絵 で表現する。 3. KJ法 アイディアを個々のカードに記入し、 その組み合わせや配列などにより効率的に発想を行っ ていく。 4. シナリオ法 対象がある状態から他の状態に変化してゆくときの変化を引き起こす変数、 要因を相互 的に考慮しながら散文的に変化してゆく情景を描写してゆく方法。 「Future Analysis 法」 、 「Gap 法」 「 、Project 展開法」 などいくつかの方法がある。 5. 並行設計 （次節 「設計プロセスを効率よく進めるために」 参照） 何人かで並行して設計を行い、 どの案が最も優れているのかを判定する。 また、 優れてい ると判定されなかったものの中からでも、 よい部分を取り入れるというこをする。

2-46

アイディア出しの支援

アイディアを縮小する手法 1. 投票方式 （しきい値付き投票／応援演説付き投票／独立軸方式投票） 2. ガイ ドラインによる判定 これら手法について次の文献でくわしい内容を知ることができる。 ● 「システム技法ハンドブック（著者 」 ：竹村伸一 日本理工出版会） さらに、 問題解決のための一般的な考え方として、 次の本を一読することを勧める。 ● 「ライト、 ついてますか」 （著者：D.C. ゴーズ／G.M. ワインバーグ 共立出版）

アイディア出しの支援

2 -47

設計プロセスを効率よく進めるために

設計の進め方

目的 コンセプト決定、 および実設計での設計の進め方 （戦略） を決める。 設計段階、 特にコンセプト決定では、 アイディアを出し、 それを評価して、 必要ならまたアイディ アを出すことに戻るという繰り返しのプロセスが必要である。 この繰り返しのプロセスの進めかた の代表的なものに、 受け入れ検査／並行設計／Interactive Prototyping の3つの方法が ある。 設計をはじめるにあたって、 限られた人とコストの中で設計をどのように進めるべきかという 設計戦略を、 実際に設計がスタートする前に決定するべきである。 ここでは、 上記の3つの方法についてそれぞれ説明する。 どの方法をとるかは、 商品の性質、 マ ンパワー、 開発期間などによって最適なものを選ぶことになる。

指針

受け入れ検査

受け入れ検査とは、 1つのアイディアに従って設計を進め、 設計したものに対して客観的評価 基準をもってそれに適合しているかどうかを判定し、 不合格の場合は作り直しなどの対策をとる という方法である （図2-20） 。

評価基準 設計

OK

受け入れ検査

NG 図2-20 受け入れ検査。

2-48

設計プロセスを効率よく進めるために

ユーザーインターフェース設計の場合、 客観的な評価基準を設けることそのものが難しいが、 要求仕様書作成時点で何らかの評価基準を決めておくべきである。 評価基準そのものは、 実際 の評価方法により以下のような考え方がある。 ユーザーテストによる評価を行う場合 ユーザーテストによる評価基準を設定する場合は、 学習しやすさ、 憶えやすさ、 エラーのおこし やすさなど測定可能な基準がパフォーマンス測定としての評価基準となる。 これらの評価基準の値は、 要求仕様を設計する段階で決めるべきである。 要求仕様を決定す る際に従来品や競合品のパフォーマンス測定を行い、 要求される品質が値が少なくとも同等か それ以上になるように設定されることになる。 要求仕様書の中で基準値は、 たとえば 「30人の典型的なユーザーに45分間対象システムの 教育を受けさせる。 その後、 添付のベンチマークタスクを15分間行わせた結果、 作業の平均完 了率は80％以上、 平均エラー数が3以下であること」 のように記述する。 まったく新しい商品で、 従来品や競合品に相当するものがないときは、 いくつかのタスクを設定 し、 実行時間はどのくらいであったらいいかをユーザーインターフェース専門家に設定してもらう。 ユーザーに直接聞くという方法もあるが、 この点に関してはユーザーは当てにならないので、 避け た方がよい。 ユーザーインターフェース専門家がチェックを行う場合 ユーザーインターフェース専門家がチェックを行う場合には、 以下のような方法がある。 いずれの 評価方法の場合でも、 できる限りあらかじめ点数化の方法を考えておき合格点を設定することが 望まれる。 または、 専門家に合格判定をまかせる。 ● Heuristic Evaluation ● Cognitive Walkthrough ● ガイ ドラインをもとにしたチェックリスト ● 観察

設計プロセスを効率よく進めるために

2 -49

並行設計 （パートシステム）

並行設計とは、 アメリカが中距離ミサイルを開発するときに使った方法でパートシステムとも呼 ばれる。 この方法は、 ひとつの課題をクリアするために何人かで並行して設計を行い、 どの案が 最も優れているのかを判定する （図2-21） 。 ここで優れていると判定されなかったものの中からで も、 よい部分を取り入れるということはしてもよい。 判定をする際に使える方法としては、 上記受け 入れ検査と同じ方法が利用できる。 ● パフォーマンス測定 （ユーザーテストによる判定） ● Heuristic Evaluation（専門家による判定） ● Cognitive Walkthrough（専門家による判定） ● ガイドラインをもとにしたチェックリスト （専門家による判定） ● 観察 （専門家による判定）

A案 設計Aチーム A案

B案 並 行 設 計

設計Bチーム

C案

B案

C案 設計Cチーム

図2-21 並行設計。 ソニーのトリニトロンの開発でも、 この設計方法がとられた。

2-50

設計プロセスを効率よく進めるために

判定

Interactive Prototyping

この方法は、 ベースとなる有力なプロトタイプ案を１つ決め、 テストをしながら被験者の意見をど んどん容れてプロトタイプを変更していく方法である （図2-22） 。 ソフトウエアなど、 すぐに変更が できるものでないと、 実行がむずかしいという側面もある。

ユーザーテスト

ユーザーテスト

ベースとなる アイディア 図2-22 Interactive Prototyping

方法 上記設計方法に関する参考文献として下記のものがある。 「Usability Engineering」 （著者：J. Nielsen ACADEMIC PRESS 刊） 「ユーザーインターフェースの設計」 （著者：B. Shneiderman 日系BP社）

設計プロセスを効率よく進めるために

2 -51

コンセンサスの形成

目的 設計に関わるすべての人が、 設計プロセスのすべての段階で問題に対しての共通の理解を 形成する。

指針 コンセンサスの形成

○

○

○

○

○

○

○

○

○

○

○

○

設計のプロセスを効率よく進めるポイントは、 設計プロジェクトに関わる人達の間でコンセンサ

例えば、 あなたが今設計している製品のユーザーはどのようなユー ザーか、 頭の中で思い浮かべてみる。 そして次の質問をする 「他の

スをいかに形成するかということである。

メンバーもあなたと同じように考えていますか？」 。

設計プロセスの中で発生する様々な問題とその答えについて、 メンバーが共通の理解をして いない場合、 そのあいまいさを遅い段階で修正すればするほどコストは高く付くことになる。 すな わち、 設計のすべてのプロセスを通して、 あいまいさを無くし、 設計に関わるすべての人のコンセ ンサスが常に形成されるように設計自体を進めることが、 設計プロセス全体を効率よく進めるた めに必要となる。

方法 コンセンサスを形成する方法として次の方策がある。 ● 設計プロジェクトに名前を付ける（ 。本節 「プロジェクト名を付ける」 参照） ● 設計プロセスを通してあいまいさをなくす方策を使用する（ 。本節 「あいまいさの削減」 参 照） ● 問題と決定したことをドキュメント化する（ 。要求仕様作成プロセス／前節 「ドキュメント化」 参照） ● 会議を有効に使う（ 。本節 「会議の方法」 参照）

2-52

設計プロセスを効率よく進めるために

プロジェクト名を付ける

目的 プロジェクト全体に関する共通の理解を形成しやすくし、 設計の結果を良い方向に導く。

指針 設計プロジェクトには、 プロジェクトをあらわす適切な名前を付けるべきである。 それには、 次の 3つの理由がある。 第1の理由は、 名前を付けることによって 「プロジェクトがある」 ということが認識されるからであ る。 プロジェクトを表す名前が付けられないのであれば、 それは、 関係者がプロジェクトを自分の ものにしたくないことの徴候を現しているのである。 第2の理由は、 名前を付けるというプロセスそのものを通して、 プロジェクトの参画者の間で、 プ ロジェクトの全般的な理解に対してのコンセンサスが形成されるからである。 第3の理由は、 設計プロジェクトの名前は、 プロジェクトを進める中で、 繰り返し使用されるから である。 プロジェクトの名前は、 作り出されるアイディアにも、 それを作る人々の行動にも影響を与 える。 例えば、 同じ製品の設計プロジェクトであっても、 次のようなプロジェクト名が、 ユーザーイン ターフェースの設計にどのように影響するか予想してみると良い。 例1：

「ESP-3001プロジェクト」

例2：

「お母さんプロジェクト」

例3：

「軽量化プロジェクト」

このように、 プロジェクトの名前が思考の働きに影響を与えるということは、 逆に考えると、 解決策 を暗示するような名前は避けるべきである。 つまり「 、ボタン一発プロジェクト」 というような名前では、 ユーザーインターフェースの解決策として、 ボタン1つで機能が働かなくてはいけないという解決 策に縛られてしまい、 この解決方法が確かにユーザーの要求を満足するかという検討がされな くなってしまう危険性がある。

方法 適切な名前を決めるために、 次の点を考慮すると良い。 ● 解決策を暗示しないこと。 ● あいまいさがないこと。 ● 気の利いた頭字語 （アクローニム） にとらわれないこと。 ● 副題を付けてみること。 また、 名前を決めるための方法として次の手順がある。 ただし、 完璧な名前は見つけることは 不可能であることを念頭に置いた方がよい。 大切なのは。 「名前」 そのものよりも「 、名前を付けるこ と」 である。 1. 名前を提案する。 2. その名前が不適切だという理由を3つ挙げる。 3. 挙げられた問題を解決する別の名前を提案する。 4. 適切な名前が見つかるまで上記の手順を繰り返す。 設計プロセスを効率よく進めるために

2 -53

あいまいさの削減

目的 設計プロセスの中で発生する設計問題の理解に対するあいまいさをなくす。

指針 あいまいさの削減でまず難しいことは、 あいまいさが存在していることに気が付くことである。 そのためにも、 プロジェクトにあいまいさが存在しているかどうかをまず発見することが必要であ る。 そして、 プロジェクトの中にあいまいさがあることを発見したなら、 そのあいまいさの原因を探 究することがあいまいさをなくすことにつながる。

方法 プロジェクトの中にあいまいさがあるかどうかを、 次の方法で確認してみると良い。 ドキュメント化する そもそも要求仕様書を作るプロセスは、 プロジェクトが解決しなくてはいけない問題の定義の あいまいさをなくすプロセスである。 頭の中にあるだけでは、 そこにあいまいさが潜んでいるかど うかがなかなか認識されない。 頭の中の事柄を 「紙に書く」 ことによって、 他の人と違う理解をして いたことに気が付く。 さらに、 自分の中での考え自体があいまいであったことに気が付くのである。 定量的な尺度を使用してみる 問題に対するしっかりした理解を形成するために、 できうるかぎり定量的な尺度 （達成度、 遂行 時間、 費用） を使用してみる。 それによって、 あいまいな部分が見つかることがある。 あいまいさが発見されたなら、 できるだけ早い時期にあいまいさを解決するプロセスを踏み、 あいまいさをなくすことが必要である。 あいまいさの問題は、 設計のプロジェクトの中にどれだけたくさんあいまいさがあるかという 「量」 の問題ではなく、 あいまいさの 「発生源を特定する」 ことこそが、 あいまいさの解決につながる。 あいまいさの発生源には次の4つの原因があると言われている。 ● 観察の誤り ：見たり聞いたりするときの差異 ● 記憶の誤り ：思い出すときの差異 ● 解釈の誤り ：問題をとのように解釈するかの差異 ● 問題理解：問題をどのように定義するかの差異

2-54

設計プロセスを効率よく進めるために

あいまいさ発見と、 その解決手法として次の手順がある。 1. 設計の参画者個々人に、 問題を正確に記述してもらい （ドキュメント化） 、 その結果をグルー ピングする。 2. それぞれのグループに分けられた意見に対して、 そのグループの人達に何を考えていた のかをたずねる。 3. あいまいさの原因が、 観察の誤りか記憶の誤りかを特定する。 あることを違ったふうに見た のなら観察の誤りで、 見たことを覚えていないのなら記憶の誤りである。 この2つがグルー プ内部での散らばりの原因である。 4. グループ内の散らばりを説明するために、 グループ内の人に、 問題をどのように解釈した かをたずねる。 このプロセスで解釈のあいまいさが発見される。 なお、 観察について議論した後の変化は問題の新しい解釈によるものであって、 記憶が変化 したわけでも、 観察が向上したわけでもない。 あいまいさの解決について次の参考文献がある。 ● 「要求仕様の探索学」 （著者：D.C. ゴーズ／G.M. ワインバーグ 共立出版）

設計プロセスを効率よく進めるために

2 -55

会議の方法

目的 会議を生産的なものにし、 「会議を開く」 というコストに見合ったものにする。

指針 ひとりで設計しない限り、 設計プロセスには会議が必要となる。 会議を開くためにはそのための 準備も必要であるし、 実際に時間がとられる。 設計プロセスを効率よく進めるためには、 この会議 を生産性のあるものにしなければならない。 逆に、 生産性の悪い会議が続くならば、 たぶんそのプ ロジェクト自体のどこかに問題があるのである。 会議を生産性の高いものにするためには、 「会議のルール」 をまず押さえておく必要がある。 ま た、 会議の内容が不確実だと、 もしかすると自分に関係のある会議かも知れないという不安のた めに無駄な時間を過ごす参加者が出てしまう。 また、 本来必要な参加者以外の人達が参加する ことによって、 会議が非効率的になってしまう。 このようなことをなくすには 「会議の内容の不確実 性をなくす」 ことが必要である。

方法 会議を効率よく進めるために以下の方策を用いると良い。 会議の基本ルール 1. 他人の話を中断しない。 2. ひとりの発言時間に制限 （例えば2分） を設ける。 3. 個人的な攻撃はしない。 4. 休憩をとることの提案を認める。 5. 終わる時間を決めそれを守る。

会議の内容の不確実性をなくすための方策 1. 何のための会議かをはっきりさせる。 ・情報伝達の会議 ・情報収集の会議 ・士気を高める会議 ・問題を定義する会議 ・アイディアを出す会議 ・アイディアを絞る会議 2. 議題をあらかじめ公表し、 実際の会議ではそれから外れない。

2-56

設計プロセスを効率よく進めるために

会議を効率よく進める方法 1. 会議の規模はできうる限り小さくする。 2. テーマをひとつに絞る。 3. 念入りに準備する。 4. 熟練した司会者を使う。 会議の運営に関する書籍に次のものがある。 ● 「How to Make Meeting Work: The New Interaction Method」 （著者：Michael Doyle and David Straus Playboy Press, 1976）

設計プロセスを効率よく進めるために

2 -57

UI設計者に求められる資質

ユーザーインターフェース設計の業務は図2-23に示すように、 大きく5つに分けて考えることが できる。

分析 調査

UI設計 デザイン

プロトタイピング

機器 ユーザー

構造のデザイン

構文のデザイン プロトタイプによる シミュレーション

ドキュメンテーション

図2-23 ユーザーインターフェース設計の業務を仕事の流れから分類してみた。

2-58

UI設計者に求められる資質

評価

それぞれの仕事の種類とその内容、 さらに個々の仕事領域で求められる資質を表にした。

仕事の種類

仕事の内容

求められる資質

社会、集団的価値体系の調 査／分析

社会、集団的価値体系分析の知 識と手法

心的情報処理の分析

心的情報処理分析の知識と手法

心理的メカニズム（認知、 感情）の分析

心理的メカニズム分析の知識と 手法

人間工学的（解剖学的）分 析

人間工学的分析の知識と手法

UI設計

ユーザーインターフェース の構造および構文の設計

心的情報処理、心理的メカニズ ム、人間工学からUI設計問題を 見ることができる知識 豊富な解決策を持ち、分析結果 から、適切な解決策を呈示でき 表現できる能力

デザイン

ルックス（概観デザイン） の設計

社会、集団的価値体系に基づい た質の高いデザインができる能 力

プロトタイピング

UIアイディアを評価可能な 形態にするためのプロトタ イピングの作成

適切な表現手法を選択でき、コ ンピューターなどを駆使してプ ロトタイピングを作成する能力

分析、調査

評価のためのプロトタイピング 作成に必要なデザイン能力 評価

ユーザーインターフェース のアイディアが要求仕様を 満足するかを評価する

ドキュメンテーション 決定されたUIアイディアを 他の設計に正しく伝えるた めの仕様書の作成

適切な評価手法を判断でき、実 験計画法などに基づいて評価計 画を立て、評価−分析ができる 能力 文書化能力 状態遷移図などの構造化技法の 知識

表2-6 ユーザーインターフェース設計の仕事の種類とそこで求められる資質。

上記のような仕事の分類から 「人」 ベースで見た場合に、 それぞれの仕事を専門として行う場 合も、 また複数の仕事をひとりが担うことも考えられる。 このパターンとしては、 例えば図2-24（次ペー ジ） のようなパターンが想定される。

UI設計者に求められる資質

2 -59

Type 1 分析 調査

UI設計 ドキュメンテーション

デザイン

分析 調査

UI設計 プロトタイピング ドキュメンテーション

デザイン

分析 調査

UI設計 ドキュメンテーション

プロトタイピング

評価

Type 2 評価

Type 3 プロトタイピング デザイン

評価

プロトタイピング デザイン

評価

Type 4 分析 調査 UI設計 ドキュメンテーション

Type 5 分析 調査 UI設計 プロトタイピング ドキュメンテーション

デザイン

Type 6 分析 調査 UI設計 プロトタイピング ドキュメンテーション 評価

デザイン

図2-24 ユーザーインターフェース設計の業務分担として考えられるパターン。

2-60

UI設計者に求められる資質

評価

D 資料編

付録

A

-1

A-2

付録

パフォーマンス測定

ユーザーインターフェースに対する測定可能な基準としては次のようなものがあり、 想定ユー ザーを被験者にして上記のようなものを測定することをパフォーマンス測定という。 ● 学習しやすさ(Learnability) ● 業務遂行能力(Efficiency of Use) ● おぼえやすさ(Memorability) ● エラーしにくさ(Few and Noncatastrophic Error) ● 満足度(Subjective Satisfaction) それぞれの測定のしかたを以下に示す。 学習しやすさ 学習のしやすさには、 学習の初期における 「とっつきやすさ」 と、 一定レベルのタスクができるよ うになるまでの 「学習しやすさ」 がある。 とっつきやすさ：当該機器に対するまったくの初心者 （想定ユーザーと他の属性は同じ人） を被験 者として、 使い始めてから一定レベルのタスクができるようになるまでの時間を測定する。 学習しやすさ：想定ユーザーを被験者として、 使い始めてから一定レベルのタスクができるように なるまでの時間を測定する。 業務遂行能力 業務遂行能力とは、 当該機器の熟練者が一定のタスクをこなすのにかかる時間である。 これ を測定するには、 当該機器をかなり使って慣れた人を被験者にして、 一定のタスクを実行しても らい、 実行にかかる時間を測定する。 どのくらいのひとを熟練者とみなすのかの基準がむずかしいうえ、 実際問題、 設計中に機器の 熟練者を作ることがむずかしいので、 この基準は測定しにくい。 設計者自身を熟練者と考えるの も1つの方法である。 おぼえやすさ

「たまにしか使わない人」 や長期休暇のあとなどの使いやすさを測る基準である。 実際に 「たまにしか使わない人」 に一定期間使わないでいてもらい、 これを被験者にして一定 のタスクができるまでの時間を測定するのが一番よい方法である。 しかしこの方法は実際上む ずかしいので、 想定ユーザーに使用してもらった後、 記憶テストを行う方法もある。 その際、 テスト と実際の使用では状況がかなり違う （メニュー方式などだと特に） ことに注意しなければならない。 エラーしにくさ タイプ間違いなどのようにすぐ修正できて他への影響もないエラーは、 数えなくてもよい。 この部 分は、 業務遂行能力を測定すればそこに含まれる。 エラーしにくさは、 ある一定のタスクを想定ユー ザーに行ってもらい、 その間におこった上記以外のエラーを数えればよい。 満足度

「気持ちよく使える」 「 、使っていて楽しい」 などといった要素で、 これもユーザーインターフェース の重要な要素である。 上記4つの基準のように物理的に測定するのはむずかしいので、 いくつか の形容詞を出し、 SD法などを用いて測定する。

資料編

D

-1

SD法 心理学などでよく使われる方法で、 自分が感じた度合を５段階評価などで主観的に点数付けし てもらう方法。 複数の人のデータを処理することにより、 主観を客観的な数字に変換することがで きる。 参考文献 「Usability Engineering」 （著者：J. Nielsen ACADEMIC PRESS 刊） 「ユーザーインターフェースの設計」 （著者：B. Shneiderman 日系BP社）

D-2

資料編

Heuristic Evaluation

評価の専門家がガイ ドライン等を使って評価する方法。 評価者、 設計者、 モデレーター （Heuristic Evaluationについてよく知っている人が望ましい） が集まり、 評価者が商品を使って問題点を指摘する。 評価の際はガイ ドラインを参考にし、 なぜ問 題なのかをガイ ドラインに沿って記述する。 設計者は評価者の発言をメモし、 どのように改善する かを判断する。 また、 評価者に質問されたら答えたり、 まだ完全に動かない点などを補う取扱説明 書のような働きをする。 モデレーターは全体の進行を担当するとともに、 設計者が説明しすぎない ように注意する。 以上を評価者の数だけく り返す。 評価者は個人差を相殺するために3人以上である必要があ り、 6人以上となると増やしてもみつかる問題点の数がそれほど増えないことが経験上わかって いるので、 3∼5人が適当である。 また、 すべての評価者の評価が終わるまで、 互いの評価結果 を話し合わないようにする。 全ての評価者の評価終了後、 評価者／設計者／モデレーターの全員が集まって、 デブリーフィ ングを行うと効果的である。 デブリーフィングの席上で問題点の重要度の判定を行うと、 設計者が 改善点を判断するののに有効な手がかりを提供できる。 評価者は、 使用するガイ ドラインに精通しており、 ユーザーインターフェース評価の経験がある 専門家である必要がある。 専門家でない場合はあまりよい結果が得られないので、 3∼5人の人 数のうちに入れることはできない。 しかし、 Heuristic Evaluationの評価を行いデブリーフィン グに参加することが、 専門家になるための訓練になる。 使用するガイ ドライン この評価で使用するガイドラインは、 一般によいとされており、 対象商品に対する視点が網羅 されていると考えられるものなら何でもよい。 評価者が精通しているガイ ドラインを選べばよい。 参 考文献の著者Nielsenは、 10項目からなるのHeuristicsを挙げている。 ガイドラインをもとにしたチェックリスト ユーザーインターフェース設計プロセスを本指針に基づいて行うと、 UIガイ ドラインを作成す ることができる。 後継機種や同種機種のユーザーインターフェース評価はこのガイドラインをもと に行うことができる。 UIガイドラインをもとにチェックリストを作成すれば、 手作り／型物試作確認 会議や出荷判定で他の品質管理項目と同様にチェックすることができる。 チェックリストのもとになるガイ ドラインは上記のUIガイ ドラインでなければならないわけではな いが、 対象機種に密着した、 かなり細かいレベルのガイ ドラインである必要がある。 参考文献 「Usability Inspection Methods」 P.25~（著者：J. Nielsen Wiley社刊）

資料編

D

-3

Cognitive

評価したい機能をユーザーの視点で記述し直し、 あらかじめ用意された２ ０項目をチェックす

Walkthrough

ることで、 仕様書の段階で、 設計者自身でも評価ができるツール。 まず、 ターゲットユーザーを想定しくわしく記述することで、 設計者がユーザーの気持ちになる。 次に、 評価したい機能をユーザーの視点で記述し直す。 記述し直したものに対して、 およそ２ ０の 視点からチェックする。 このチェック項目は、 どんな商品でも使えるような汎用性のあるものである。 また、 ターゲットユーザーの想定や機能の記述のし直しも、 汎用性のあるシートにしたがって行う ことができる。 設計者がユーザーの視点で商品をみることはむずかしいと言われているが、 以上のような手 続きをふむことで、 設計者でも評価ができるようにする。 また、 評価対象が設計仕様書など紙の段 階のものなので、 設計者のように機器にくわしい人が少なく とも一人はいないと評価がむずかしい。 実際の評価は、 評価の妥当性を高めるために２∼３人が組になって行う。 ２∼３人で話し合いな がら評価を行い、 出てきた問題点の重要度の評価も話し合う。 これら全てを一人で行うと、 視点が かたよりがちになるうえ、 発見も少なくなってしまう。 Cognitive Walkthroughのチェック項目 （抜粋） 1-1.

必要なゴールを落とすことはないか。

1-2.

間違ったゴールを付け加えていないか。

2-1.

ユーザーは正しい操作が明確にわかるか。

2-2.

正しい操作にはどんなラベルまたは記述がつけてあるか。

2-3.

その操作にラベルまたは記述がついている場合、 操作との関連は明らかか。

2-4.

操作にラベルまたは記述がついている場合、 このステップのゴールとの関連は

明らかか。 2-5.

操作にラベルがついていない場合、 ユーザーは正しい操作とこのステップのゴー

ルとを結び付けることができるか。 2-6.

ユーザーが正しい操作と混同してしまうような紛らわしい操作はないか。

2-7.

ユーザーが必要な操作を選択／遂行するために十分な時間があるか。

2-8.

求められる操作が物理的にむずかしいということはないか。

3-1.

ユーザーは、 ゴール達成に向かって何らかの進歩があったことがわかるか。

3-2.

各ゴールが達成されたことが、 システムの応答から明らかにわかるか。

3-3.

まだ達成されていないのにシステムの応答から完了されたように見えるサブゴー

ルはあるか。 QUIS QUIS は、 このCognitive Walkthroughをもとにソニーで独自に開発したツールである。 想定ユーザーや機能の記述シートを完備したうえ、 チェック項目を減らすなど、 より簡単に評価が できるように工夫されている。 参考文献 「Usability Inspection Method」 P.105~（著者：P. Polsonら Wiley社刊）

D-4

資料編

観察法

ユーザーのそばについて、 ずっと観察する方法。 わかったことはメモをとる。 また、 同時にビデオ に録画しておくことにより、 あとでの確認ができる。 現在行われているタスクがどんなものか観察して分析する、 特定のタスクを与えて実行してい るところを観察して問題点を出す、 など様々な目的に使えるが、 何を観察するかをあらかじめ明 らかにしておかないと焦点がぼけてしまい、 良い結果が得られなくなる。 また、 特に決まった手順 のようなものもなく、 何をどのように観察するかは観察者の手腕にゆだねられる。 しかし、 同じ趣旨 の観察を数人の被験者を対象に行う場合は、 記録のしかた／チェックポイントなどをあらかじめ 決めておいたほうがよい。 この手法の欠点は、 オフィスなど公共性のある場で使う商品ならばいいが、 家庭で使うものな どの場合観察者がいることでユーザーが緊張してしまい、 普段の様子が観察できないことや、 必 要な情報を得ようと思うと、 長時間観察しなければならないこと、 などである。 想定ユーザーが物 理的にかたまった所にいる特定少数の場合は、 比較的短期間で必要な情報が得られる。

資料編

D

-5

プロトコル分析

特定のタスクを設定し、 実行する際に頭に浮かんだことを口に出してもらうことにより、 被験者の 内的な認知過程を調べる方法。 分析したいタスクにあわせた状況を設定し、 被験者に説明する。 状況はなるべく被験者の日 常に合ったものにしないと、 結果にバイアスがかかってしまうので気をつける。 タスクを行う際、 頭 に浮かんだことは全て口に出すことと、 質問しながらではなく被験者がひとりで問題を解決する つもりで操作してもらうことを説明する。 これは、 実験者に質問しながらの会話の形となると、 結果 にバイアスがかかってしまうからである。 被験者がどうしても先に進めない状態などになったら介 入してもよいが、 なるべく被験者の心理的負担にならないよう気をつける。 以上のような場面をビデオ等に撮り、 発話部分を書き起こして分析する。 発話と行動を対応さ せ、 被験者の内的認知過程を推測する。 被験者が頭で考えたことをたくさん口に出していれば いるほど推測が確実になるので、 なるべく多くの発話を促す必要がある。 被験者の内的認知過程を調べることによって、 問題点が存在するという事実だけでなく、 なぜ それが問題なのかの原因を解明する手がかりが与えられるのが利点である。 また、 小人数の被 験者から豊富なデータが得られる。 しかし、 分析にかなりの時間がかかり、 設定するタスクもあまり 大規模だと被験者が疲労してしまうので制限せざるをえない、 という欠点がある。 また、 熟練者は タスクをほぼ自動的におこなっており、 そういった部分は発話されにくいという欠点もある。 参考文献 「プロトコル分析入門」 （海保博之・原田悦子編 新曜社）

D-6

資料編

インタビュー

調査者が直接相手に面会して質問する方法。 あらかじめ質問項目を用意しておくのはもちろんだが、 実際の場で臨機応変に対応できる。 ま た質問形態も、 Yes／Noで答えられるようなものではなく、 なるべく相手にしゃべってもらうようにし たほうが得られる情報が多い。 聞き漏らしを避けるため、 質問紙と併用することもできる。 質問紙による調査よりも柔軟性があり深い調査も可能であるが、 それほど多人数を対象にでき ない。 また、 プライバシーにかかわる微妙な質問で実態と違うことを答えてしまったり、 実際はどう であるかというよりも回答者がどう思っているかに依存した回答になってしまう。

インタビューのための基本事項

インタビューを開始するにあたって次の2点が重要である。 1. インタビューの目的をはっきりさせ、 相手に理解してもらう。 2. 相手との信頼関係を作る。

インタビューのテクニック

相手の考えを十分に引き出すための質問事項として次のようなものがある。 メタ質問 （質問の途中で必要であれば下記の質問を挟む） ● 私は質問しすぎますか？ ● 私の質問は妥当ですか？ 質問の最後でする質問 ● 何か他に私が聞いておくことがありますか？ ● あなたが私に聞きたいことがありますか？ ● 今回カバーできなかったことがあればまたここへ来るか、 または電話をしても良いですか？ .質問の途中で隠れた問題を引き出すためにする質問 ● この質問に答える前に、 あなたはだいぶ長い間躊躇されたようですが、 何か私達が知っ ておかなくてはならないことはありますか？ ● あなた （がた） は、 回答に合意しているように見えませんが、 そのことについて何か聞いて おくことがありますか？ ● これまでの進め方について満足していますか？ 不満なことがあればその理由は何かで すか？

資料編

D

-7

質問紙 （アンケート） 法

アンケート用紙を作成し、 その質問に答えてもらう方法。 質問紙法で肝心なのは、 質問紙の作りかたである。 まずは回答者が回答しやすいよう配慮す ること。 わかりにくい表現がないかの念入りなチェックが必要であるし、 質問の量が多すぎないよ うにしなければならない。 一般に、 自由回答は得られる情報が多いが回答者への負担が大きく、 回答者はYES／NOの回答や選択肢から選ぶ形式を好む。 また、 質問は回答者にバイアスを与 えないような表現にしなければならないが、 選択肢を示すよりも自由回答の方がバイアスを与え にくい。 YES／NOや選択肢形式の場合は統計処理が可能である。 また、 選択肢形式には単一 回答と複数回答がある。 以上のように様々な方式があるが、 知りたい内容に最も合った形式を選 ぶ必要がある。 質問紙の作成法は市販の本が各種あるので参照のこと。 質問紙法の利点は、 一度に多人数の調査ができることである。 回答を統計処理する場合は一 定以上のサンプル数が必要である。 質問が一定なので互いに比較可能なデータがとれる。 欠点 としては、 回答者の状況に合わせて柔軟に対応することができないので深い調査がむずかしい こと、 回答内容が実際はどうであるかというよりも回答者がどう思っているかに依存してしまうこと などである。

D-8

資料編

グループインタビュー

想定ユーザー数人を集め、 商品についてなどのディスカッションをしてもらう方法。 通常5∼6人を1グループとするが、 1つのグループのなかの人の属性があまりばらつかないよ うに （男女別や年齢別にするなど） しないと、 場が盛り上がらず、 よい結果が得られない。 集まった ら、 自己紹介や会話の練習のための雑談などをしてもらい、 皆がなめらかに話しができるようにす る。 司会者が一人一人に質問するのではなくお互いに会話してもらうところが眼目なので、 司会 者はそういった注意点を述べ、 会話の議題を提示した後はなるべく介入しないようにする。 介入 は、 話がとだえてしまったときや、 会話が議題と関係ない方向にそれてしまったときや、 発言をしな い人がいるときなどだけにする。 記録係が会場でメモをとったり、 後でビデオに収録されたものを見てメモをとったりして、 必要 な情報を抽出する。 集団の成員間の相互作用によって、 短時間に大量のデータが得られ、 個人 ではとても期待できないような新しい考えやアイディアを期待することができる。 また、 会話の中か らユーザーの社会的な状況や無意識を観察することもできる。 しかし一方、 あまり構成的なデータ は得られず、 論理的根拠に乏しい。 参考文献 「グループインタビュー調査 実施と分析の技術」 （梅澤伸喜 ダイヤモンド社） 「実践グループインタビュー入門」 （梅澤伸喜 ダイヤモンド社）

資料編

D

-9

AHP法

比率尺度による一対比較をもとに全体の項目間の比率尺度を決定する方法で、 複雑で曖昧 な状況での意思決定に用いる。 特定の評価の視点から一対比較を行い、 どちらが何倍よいか／悪いかという点数付けをして もらう。 これを数人に行い、 幾何平均をとる。 評価の視点の数だけこの作業を行う。 次に評価の視 点間でのウエイト付けを、 同様な一対比較による比率尺度での点数付けで行う。 この2つを掛け 合わせて総合点を求めればよい。 AHP法には、 一対比較を行った結果の数字さえ入力すれば、 めんどうな計算を行ってくれる ソフトもある。 参考文献 「ゲーム感覚意思決定法ーAHP法入門」 （刀根薫 日科技連出版社）

D-10

資料編

ユーザーの概念モデル

ブランクフェースモデルを使った演技法

の分析手法

被験者にのっぺらぼうの機器を与え、 どのようなボタンがあるかなどを想像しながら課題をこな してもらう方法。 ドローイングインタビュー法 被験者といっしょに課題操作の内容をレビューしながら、 被験者の理解の内容をモデル化し て描くことにより被験者の概念モデルを導き出す方法。 参考文献 「ユーザーの概念モデルの分析手法」 （ER番号：PC1-94-0018）

資料編

D -11

ノーマンのデザインの 7原則

1.

外界にある知識と頭の中にある知識の両者を利用する 選択肢から選ぶ／まわりの環境からの情報など外界にある知識と、 概念モデルなど頭の 中にある知識との間を、 容易に行き来したり統合したりして利用できることが望ましい。

2.

作業の構造を単純化する 有効なフィードバックを与えたり、 自動化を進めることによって、 作業の構造を単純化する ことができる。 が、 ユーザーのコントロール感をなくさないよう気をつけなければならない。

3.

対象を目に見えるようにして、 実行のへだたりと評価のへだたりに橋をかける いま何が実行可能か、 また自分の行った行為がどんな効果を及ぼしたのか目に見える ようにする。 また、 その見えるものが誤った解釈をされないようにする。

4.

対応づけを正しくする 対応づけには、 ユーザーの意図と実際に実行できること／ユーザーの行為とシステムの 反応／システムの内部状態と状態表示／システムの状態とユーザーの意図などがある。

5.

自然の制約や人工的な制約などの制約の力を活用する ある場面で可能な選択肢が少なければ少ないほど、 対処が簡単になる。 制約とは、 選択 肢をせばめるもののことである。 制約には、 物理的なもの／意味的なもの／文化的なもの ／論理的なものなどがある。

6.

エラーに備えたデザインをする エラーがおこる可能性があるなら、 それはおこると考えた方がよい。 ユーザーが行う全て の行為は正しい方向だと考えるべきで、 それと闘おうとしてはならない。

7.

以上の全てがうまくいかないときには、 標準化する デザインをする際に、 どうしても恣意的な対応づけをしなくてはならいときの最後の手段。 標準化はどうしても自然な対応づけができなかったときで、 デザインの欠点をカバーする ために使ってはならない。

参考文献 「誰のためのデザイン？（ 」D.A. ノーマン 新曜社）

D-12

資料編

ユーザーインターフェース設計の指針と方法 1995年6月 初版発行 制作

ヒューマンインターフェースラボ

担当

田中康 E-Mail：yasushi@ptl.sony.co.jp

Copyright©1995 ソニー株式会社

User Interface Guidelines

© 1995 by Sony Corporation All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from the publisher.

Printed in Japan

要求仕様の設計

2

-1

ユーザーインターフェース設計の指針と方法

2-2

要求仕様の設計