待望の ユーザビリティ実務の解説書! 優れたユーザインタフェース 実現の鍵がここにある！ 樽本 徹也 著 A5判・208頁 定価 2625円【税込】 Web，ケータイ，デジタル家電――現代の生活は高機能・高性能なコンピュータ技術に支えられて います．その一方で，それらが提供する機能・性能を「使えない」「使いこなせない」というユーザ の不満の声が多く聞かれます．そうした状況の中で，重要な品質要素としてユーザビリティに関心が 集まっていますが，残念ながらデザインのテクニック，あるいはガイドライン的なとらえ方にとどま る事例が多く見受けられるのも事実です． 本書は，ユーザビリティはプロセスから生まれるという立場のもと，ユーザビリティエンジニアリ ングのテクニックを設計の現場で活かし，実践できる書籍として発行するものです．ユーザビリティ の概念，考え方といった理論的背景の解説はもちろん，手法や手順を具体的に公開し，実務に役立つ 内容となっています． 本書の主な内容 第1章 ユーザビリティとユーザ中心設計 第2章 ユーザ調査法 第3章 プロトタイプ 第4章 ユーザビリティ評価法 第5章 ユーザテスト実践編 1 1- 1 1 ユーザビリティの訳語として「使いやすさ」がよく使われます。アンケート調 査などでも、製品購入時の重視点として機能・性能・価格などと並んで「使いや すさ」があげられることが多く、その重要性はだれの目にも明らかであるといえ そうです。 ただ、ユーザビリティを「使いやすさ」であると理解していると、 ユーザに対 する思いやり や ユーザフレンドリ といった感性的な概念と混同してしまい ます。その結果、設計チームは、ユーザビリティとはユーザにとって「あればう れしいけれど、なくても困らない」というプラスαの要件であると誤解してしま います。 実際のプロジェクトでは、 「コスト」 「納期」 「品質」の厳格な要件が課せられて います。それらの要求水準は非常に高く、モノ作りの現場は、企画・設計・実 装・品質保証・マーケティングといった関係者が入り乱れた 修羅場 と化しま す。そんな極限状態に陥ったときに、 「ユーザビリティ＝使いやすさ」ととらえて いる設計チームは、ユーザビリティ問題の優先順位を下げてしまいがちです。 しかし、ユーザビリティには本当はもっと重大な意味が含まれています。それ は「使える」ことです。もし、製品が 使用不可能 になってしまうとすれば、 設計チームはもっと真剣にユーザビリティ問題を解決しようとするでしょう。 ユーザビリティエンジニアが参加していない設計チームは、往々にして深刻な ユーザビリティ問題を抱えたインタフェースを生み出してしまいます。完成後に ユーザテストを実施して、初めて、そのインタフェースは使用不可能であること が明らかになってしまうことも少なくありません。 このような失敗を繰り返さないためにも、ユーザビリティは「使いやすさ」で はなく「使用可能性」であると理解すべきです。 2 2 皆さんは、インタフェースが多少使いづらいことはあるとしても、使用不可能 というのは極端な事例ではないかと考えるかもしれません。しかし、 使いやす く することを目的にスタートしたプロジェクトであっても、テスト結果があま りにもひどくて、実質的には 使用可能 にすることが目的になってしまうこと は珍しくありません。 皆さんは、インターネットを使っていて、次のような経験はありませんか？ ＜おバカな検索エンジン＞ ある家電メーカのウェブサイトでは、製品名で検索すると、マスコミ向け のニュースリリースのPDFファイルばかり表示する。なお、アルファベット が含まれた製品名の場合、1 文字でも大文字と小文字を間違えると「検索結 果0件」になってしまう。 ＜注文の多い注文フォーム＞ ある電子商店の注文フォームは20 項目の入力フィールドを持つ。さらに、 各フィールドの入力規則は厳密に指示されている。 「郵便番号は ない」「姓と名の間に全角スペースを入れる」「電話番号は - を入れ を入れる」 「日付はすべて2桁（例：09/11） 」などなど。そして、入力ミスを犯すと、送 信ボタンを押すたびに1項目分ずつエラーメッセージが表示される。 ＜一方通行のサイト＞ ある金融機関のウェブサイトでは店舗検索専用のミニウィンドウを開く。 ところが、そのミニウィンドウには 戻る 機能を持ったボタンやリンクは 用意されていない。もしユーザが検索プロセスでなんらかのミスを犯すと、 ゼロから検索をやり直さなければならない。 「おバカな検索エンジン」を使ったユーザは、あまりにも見当違いな結果ばかり 表示されるので、すっかり意欲を失ってしまい、製品情報を閲覧することをあき らめてしまいました。 3 「注文の多い注文フォーム」と「一方通行のサイト」では、ユーザは何度もやり 直して、なんとかタスクは完了しました。しかし作業が終わってから「こんなサ イトは二度と使いたくない」と強い不満を表明しました。 上記の事例は、制作者から見れば「ちょっと使いづらい」というレベルに見え るかもしれませんが、ユーザの実体験としては「使いモノにならない」レベルだ ったのです。ユーザビリティを制作者の視点で判断するのは危険です。実際には、 他にいくらでも代替品はあるので、インタフェースが 使用不可能 だと感じた らユーザはたちまち他に移っていってしまいます。だから、ヤコブ・ニールセン 博士は著書の中で「インターネット経済を左右するのはユーザビリティである」 とまでいったのです。 ユーザビリティが使用可能性にとどまっていることは、ユーザビリティエンジ ニアやインタフェースデザイナにとって不名誉なことだと思います。同じデザイ ンの専門家でも、プロダクトデザイナは安全性や使用可能性を保証したうえで、 もっと 魅力的 なデザインの実現を目指しているのですから。 ただ、インタラクティブシステムのユーザインタフェース設計は非常に複雑な 作業です。現状では、少なくともインタフェースが「使用可能」であることを保 証できる水準に引き上げることが急務だと思います。 3 国際規格 ISO 9241 では、ユーザビリティを「特定のコンテキストにおいて、 特定のユーザによって、ある製品が、特定の目標を達成するために用いられる際 の、効果・効率・ユーザの満足度の度合い」と定義しています。 この定義の前半部分では「特定の」という言葉が何度も出てきます。実は、あ る製品やウェブサイトを対象に、それが一般的にユーザブルであるといえるかど うかは評価できません。まずユーザ、利用状況、目標を特定しなければなりませ ん。そのうえで、効果・効率・満足度という尺度を用いて評価するのです。 効果（effectiveness） ユーザが目標を達成できるかどうかです。例えば、オンライン書店で欲しい書 籍を購入できることです。もし、ユーザが書籍を購入できないとすれば、そんな 4 書店に存在価値はありません。ですから、効果問題はなんとしても解決しなけれ ばならない課題になります。 効率（efficiency） ユーザが目標を達成できるとして、その間にむだな手順を踏まず、なるべく最 短経路で目標を達成できるかどうかです。オンライン書店でショッピングカート の操作に手間取って、何度もやり直してやっと購入できたとすれば、そのサイト には効率問題があることになります。なお、深刻な効率問題は、事実上の効果問 題になります。ユーザが作業完了をあきらめてしまうからです。 満足度（satisfaction） 効果や効率に大きな問題がなかったとしても、さらにユーザに不愉快な思いを させていないかどうかです。会員登録時にむやみにプライベートな情報を要求し たり、一方的な内容の使用規約の許諾を求めたり、また、システムのレスポンス が非常に遅かったりすると、ユーザは不満を表明します。満足度問題も程度によ っては深刻な結果を招きます。ユーザが二度と使ってくれなくなるからです。 ISO 9241の定義に従えば、これら3要素を すべて 満たして、初めてそのイ ンタフェースはユーザブルであるといえることになります。しかし、実際にはそ れは容易なことではありません。そこで、問題の深刻さを考慮しながら、原則と してまず効果問題から解決に取り組んで、後は時間とコストの制限の中で、なる べく多くの効率問題や満足度問題を解決するというのが現実的なアプローチにな ります。 効果 効率 満足度 ユーザビリティとは、効果・効率・満足度の いずれの要素も阻害しないこと。 5 1- 2 私が出会ったインタフェースデザイナやソフトウェアエンジニアは、皆、真剣 にユーザのことを考えていました。決して、販売優先や技術中心ではなく、なん とかユーザの役に立つインタフェースを作ろうと努力していました。しかし、ど んなにユーザのことを考えてデザインしても、彼らはあまり成果をあげられませ んでした。残念なことに、彼らはエネルギーの大半を、的外れな議論や活動に費 やしてしまっていたのでした。 1 インタフェースが使用不可能になってしまう原因の一つとして「ユーザ定義の 失敗」があげられます。皆さんは「コンバーチブルのバンでオフロード仕様のク ルマ」と聞くとどう思いますか？ 1台ですべてのユーザニーズにこたえようとす れば、そんなデザインになってしまうかもしれません。もちろん、そんな車は存 在しないし、存在したとしてもだれも買わないでしょう。すべてのユーザを対象 にインタフェースをデザインするというのは同様の間違いを犯しているといえま す。 では 想定ユーザ を決めれば事足りるのでしょうか。例えば「流行と自分ら しさの調和を大切にする大人のユーザ」という定義をしたとします。しかし、こ れでは設計チームメンバーが自分かってなユーザ像を思い描くことができてしま うので、何も定義していないのと同じなのです。このようなユーザ定義を、アラ や ゆ ン・クーパー氏はゴムのユーザ（elastic user）と揶揄しています。設計者の都 合に合わせて伸縮自在のユーザという意味です。 実際のプロジェクトでも、初回のミーティングで想定ユーザを尋ねると、しば らくとまどいを見せた後に「すべてのお客様」と真顔で返答する設計チームは少 なくありません。しかし、何も制約条件がなければ、無数のユーザ像を作り出す ことができてしまいます。 6 設計チームの都合に合わせてくれる 伸縮自在 の便利なユーザ。 当然ながら，本来は設計者がユーザの都合に合わせるべき。 プロジェクト開始当初は、設計チームは時間もエネルギーも十分に持っていま す。より優れたユーザ体験を提供するために、メンバーは新しい機能やインタフ ェースの改善案についてさまざまなアイディアを出し合います。ところが、どん なにすばらしいアイディアであっても、設計チームのだれかが一つでも 反対す るユーザ像 を思いついてしまうと、そのアイディアはお蔵入りになってしまい ます。そんなことを繰り返していると、創造的な情熱は感情的な泥仕合の様相を 呈してきます。 このような不毛な議論を続けているうちに、設計チームには危機が訪れます。 納期 が迫ってくるのです。そうすると、今度は 声の大きい メンバーが主導 して、今のインタフェースでも なんとか 使ってくれそうなユーザ像を作り上 げます。崖っぷちに立たされ、また不毛な議論に辟易していた他のメンバーには、 もはや反論の気力はありません。それまで自分が主張してきたユーザの形を少し 変えて（ ゴム製 なので簡単） 、その案に賛成します。このようにして、使用不 可能なインタフェースは生み出されるのです。 2 ユーザビリティに関する本やウェブサイトを見るとコンテキスト（context）と いう用語がよく出てくると思います。一般には「文脈」と訳すことが多いですが、 7 英語の文章や会話の中では 物事 の「前後関係」や「状況」といった意味でも よく用いられます。 コンテキストとは、お芝居の場面設定のようなものです。例えば、同じ旅行情 報サイトを使うとしても、 「女子大生のAさんが、大学のコンピュータルームで友 達といっしょに卒業旅行の計画を立てている」場面と、 「商事会社の営業マンBさ んが、自席のパソコンで来週の出張の手配をしている」場面では、状況はずいぶ ん異なります。その結果、ユーザがサイト内で利用する機能や情報も大きく異な るのは想像に難くないでしょう。 コンテキストは ユーザビリティのキーコンセプト といっても過言ではあり ません。コンテキストが異なると、同じシステムや製品が使用不可能になったり、 逆にすごく便利に使えたりします。 私の職場では社内電話としてPHSを使用しています。私たちの仕事は来客やミ ーティング、またユーザテストなどで自席を離れることが多いので、普通の卓上 ビジネスフォンでは不便なのです。PHSならば会議室や実査会場でも使用できま す。 ただ、このPHS電話機には深刻な問題があります。それは 転送 がしづらい ことです。社内電話ですので、同僚宛にかかってきた電話を私がとって、それを 同僚に転送するという場面は少なからずあります。もちろん、正しい手順を踏め ば正常に転送できます。しかし、もし一つでも操作を間違えると、困ったことに 電話は切れてしまうのです。お客様からの電話を切るというのは非常に失礼なこ とで、これはビジネスの現場では本来あってはいけないことです。では、これは 設計ミス なのでしょうか。 ところで、皆さんは 個人 の携帯電話で 転送 をした経験はあるでしょう か？ ほとんどの人は1 回も経験がないと思います。実は、上記のPHS 電話機は 普通の携帯電話として設計された製品でした。極端にいえば、このPHS電話機は 転送などできなくてもよかったのです。つまりミスを犯したのはデザイナではな く、個人用に設計された携帯電話端末を、不注意にオフィスに持ち込んだ私たち のほうなのです。 8 1990年代の前半から中ごろにかけて、高校生の間でポケットベルを使ったメッ セージのやりとりがブームになったことがあります。1996 年には、NHK で『ベ ル友・12 文字の青春』と題したドキュメンタリーが放映されたくらいでしたが、 そのブームは長くは続かず、1990年代後半には消え去りました。 本来、ポケベルはビジネスの現場で効率よく情報を配信するためのツールです。 例えば上司が外勤の営業マンに指示を出したり、病院や工場内の情報伝達には適 しています。しかし、高校生が友人とたわいのないメッセージをやりとりするた めには最も重要な機能が欠けていました。それは 発信機能 です。ポケベルは 受信専用端末だったのです。受信しかできないポケベルは、そもそもコミュニケ ーションツールといえる代物ではなかったのです。 では、高校生はどうやってメッセージを発信していたのでしょうか？ 答えは 固定電話機です。彼らは家庭にある電話機を使ったり、わざわざ公衆電話まで行 ってメッセージを発信していたのです。当時は携帯電話が非常に高価だったので、 高校生には他に選択肢はありませんでした。不便ではあったけれども、受信しか できないポケベルと固定電話を組み合わせることで、なんとか自分たちの目的を 達成していたのです。 その後、本格的なコミュニケーションツールである携帯電話の価格が下がって、 高校生でも手が届くようになると、ポケベルはその役割を終えたのです。 チャップリンの『モダンタイムス』では「人間が機械に振り回される姿」が皮 肉たっぷりに描かれています。ユーザインタフェースの設計原則の一つにも「ユ ーザがいつでも作業を止められるような 非常出口 が必要である」というもの があります。 例えば、Windowsのアプリケーションではすべてのダイアログボックスに キ ャンセルボタン が用意されていて、ユーザが行った変更をいつでも取り消すこ とができます。OKボタンを押さないかぎり、ダイアログボックスで行ったどんな 変更も実行されることはないので、ユーザは安心してシステムを使用できます。 このように、インタフェース上にOKボタンとキャンセルボタンを組み合わせて配 置するのは、とても良いことだといえそうです。 9 しかし、それはウィンドウを基本としたシステムの場合の話です。ウェブペー ジでは、取消しのボタンは必ずしも必要ではありません。注文や登録を行うため の入力フォームに送信ボタンとクリアボタン（リセットボタン）を並べて配置す ると悲劇を生みます。間違ってクリアボタンを押してしまうと、それまでユーザ が苦労して入力したデータが水の泡になってしまうのです。 紙ならば、修正液や取消線で修正するよりも、書き損じた用紙を廃棄して、最 初から書き直したほうが早い場合もあるでしょう。しかし、ウェブサイト上でフ ォームに入力しているときに、いったいだれがすべてを白紙に戻して、最初から 入力をやり直すというのでしょう？ 入力ミスした箇所だけを修正するほうがず っと簡単ですし、入力作業そのものをとりやめるのならば、ブラウザのバックボ タンで前のページに戻ればよいだけです。 どんなに設計原則を知っていても、その使用場面を誤ると意味がないだけでな く、有害ですらあるのです。 3 ユーザインタフェースを改善するときに、従来のマーケティング的アプローチ を使おうとする人が少なくありません。例えば、アンケートやインタビューを行 って、ユーザに「あなたがこの製品（やウェブサイト）を使っていて、最も使い づらいと思った点をお知らせください」と質問するのです。 もちろん、このアプローチでも問題点は見つかります。十分な人数を調査すれ ば、インタフェース上の重大な問題点は、ほとんど全部見つけ出すことができる でしょう。しかし、発見された重大な問題点を取り除いたとしても、ユーザの不 満はあまり改善しません。なぜなら、まだ 重要な経路 に問題点がたくさん残 っているからです。 ユーザインタフェースの役割は、ユーザをゴールまで導くことです。そして、 ユーザがゴールに到達する経路は、必ず1本の線になります。その経路上に1か所 でも通過できない箇所があればユーザはゴールに到達できませんし、通過しづら い箇所があれば余分な労力を使うことになります。 インタフェース全体から重大な問題点を優先して取り除いたとしても、ユーザ がよく通る経路上に問題点が残っているかぎり、ユーザ体験はあまり改善できま 10 せん。つまり、ユーザインタフェースの設計では、経路上の問題点を すべて 取り除けるようなアプローチが必要なのです。 重大な問題 スタート 中程度な問題 軽微な問題 ゴール 全体から重大な問題を取り除いたとしても、重要な経路には、まだ問題がいくつも残っている。 11 1- 3 技術は私たちの生活を便利で豊かなものにしてくれましたが、新機能や高性能 が必ずしもユーザの利益につながるわけではありません。どんなに技術的に優れ ていても、ユーザがそれを使いこなせないとすれば全く意味はありません。 1 例えば、パソコン用ソフトウェアのユーザ調査をすると、既に実装されている 機能が 要望 の上位にランクされることは少なくありません。ユーザが機能の 存在に気づいていなかったり、機能を使いこなせていないのです。また、AV機器 の使いがっての悪さは多くの笑い話を生んできましたし、携帯電話はいまだに中 高年層のユーザを悩ませています。 製品の機能・性能が要求を満たしていなければ、ユーザは目的を達成すること はできませんが、たとえ要求どおりの品質であったとしても、それらの機能・性 能を使いこなせなければ、やはりユーザは目的を達成できません。 つまり、機能・性能といった製品そのものの品質に加えて、実際にユーザが製 品を利用する際の品質も保証しなければ、ユーザの本当の満足は得られません。 この利用の品質（quality in use）を保証しようという考え方がユーザビリティ の本質です。 それを実現するための手法がユーザ中心設計（UCD：user centered design） です。ユーザ中心設計では、技術優先の考えや作り手のかってな思い込みを排除 して、ユーザの視点に立って設計を行います。 2 システムや製品を設計するプロセスは対象によっても異なりますし、組織や環 境によっても異なるので、実務者や研究者は独自の工夫を凝らしたユーザ中心設 12 ●ユーザ調査 ＊観察 ＊インタビュー など ●ユーザニーズ分析 ＊シナリオ ＊ペルソナ など ●プロトタイプ ＊ペーパープロトタイプ ＊パワーポイント など フィードバック ●ユーザビリティ評価 ＊インスペクション ＊ユーザテスト など UCDの特徴は、ユーザビリティ評価の結果を上流工程に フィードバックして、プロセスを繰り返すことにある。 計のプロセスを構築しています。しかし、そこには骨格となるような共通したパ ターンがあります。それは以下のようなものです。 ① ユーザの 利用状況 を把握する。 ② 利用状況から ユーザニーズ を探索する。 ③ ユーザニーズを満たすような 解決案 を作る。 ④ 解決案を 評価 する。 ⑤ 評価結果をフィードバックして、解決案を 改善 する。 ⑥ 評価と改善を 繰り返す 。 ユーザ中心設計の第一歩はユーザ調査から始まります。ユーザ中心設計とは、 ユーザから出される「こんな機能が欲しい」 「この部分を変更してほしい」といっ た要求や不満に対応することではありません。設計者自身がユーザを観察したり インタビューしたりして、ユーザの具体的な利用状況を把握したうえで、潜在的 なユーザニーズまで探索します。 次に、それらのユーザニーズを実現する方法を考えます。そのときに、設計チ ームのアイディアは、いきなり実装するのではなく、まず簡単なプロトタイプを 13 作成します。そして、ユーザにプロトタイプを使ってもらって、そのアイディア の有効性を評価します。 評価の結果、ユーザニーズを満たしていない箇所が明らかになればプロトタイ プを修正します。そして、改めてユーザにプロトタイプを使ってもらって、改善 案が有効であったかどうか評価します。その後も、評価と改善を繰り返しながら、 徐々にインタフェースの完成度を上げていきます。 3 ユーザ中心設計をうまく運用するためのポイントが三つあります。 ユーザインタフェースの設計に 秘伝書 はありません。どんなにテクニック やガイドラインを知っていても、それだけでは不十分です。優れたインタフェー スはプロセスから生まれます。 しかし、単に「プロセスに従えばよい」というわけではありません。どんなイ ンタビューを行って、どう分析して、どんなプロトタイプを作って、どんなテス トを行って、どう改善を施すのか。すべてのステップで 腕前 が問われます。 ユーザ中心設計では評価と改善を繰り返し（反復デザイン）ますが、これは 手戻り ではありません。ウォータフォールモデルに代表されるような、従来の 直線的な設計プロセスでは、前のステップに戻ることは原則として許されません が、ユーザ中心設計では最初から スパイラル（らせん状） な手順を想定してい ます。 時間とコストをかけずに反復デザインを行うためには、例えば 手書き のイ ンタフェースから始めて、徐々に完成度の高いインタフェースを作成しながら評 価と改善を繰り返します。 ユーザの視点で考える場合に 想像上 のユーザの視点では無意味です。それ 14 ユーザニーズ テスト プロトタイプ テスト プロトタイプ テスト プロトタイプ 反復は 手戻り ではない。評価と改善を繰り返しながら、徐々に完成度を上げていく。 では、従来の設計となんら変わりはありません。そこで、ユーザ中心設計のイン タビューやテストには、必ず 本物 のユーザに参加してもらいます。 そのため、設計チームはインタフェースを設計する技術だけでなく、 生身 の 人間を取り扱う技術も併せ持っている必要があります。ただ、それは心理学や人 間工学の知識や技術というよりも、顧客のニーズを把握するのがうまい営業マン やマーケッタが持っている技能に近いものです。 Column 1999年に『ISO 13407：人間工学―インタラクティブシステムの人間中心設計 プロセス』という国際規格がリリースされました。2000年には翻訳されて『JIS Z 8530』という国内規格（JIS規格）にもなりました。構成は以下のようになって います。 1章：適用範囲 2章：定義 3章：この規格の構成 4章：人間中心設計プロセスを適用する根拠 5章：人間中心設計の原則 6章：人間中心設計の工程計画 15 7章：人間中心設計活動 8章：人間中心適合条件 一見すると8 章立てでおおげさな感じがしますが、附属文書を除いた本文は12 ページ（JIS Z 8530の場合）しかありません。 主な内容 ISO 13407 は、その名のとおり「人間中心設計（HCD ：human centered design） 」について定義しています。重要な章について、概要をご紹介しておきま しょう。 まず、 「4章：人間中心設計プロセスを適用する根拠」には、人間中心設計を導 入するメリットがあげられています。ユーザビリティに投資する効用についての 一般的な回答になっています。 ● ユーザに対する訓練およびサポート費用を削減する ● ユーザの満足度を向上させ、不満およびストレスを緩和する ● ユーザの生産性および組織の運用効率を改善する ● 製品の品質を改善し、ユーザにアピールすることで商品競争力を有利にする 次に、 「5章：人間中心設計の原則」では、人間中心のアプローチが備えている 四つの特徴を定義しています。ユーザの関与や繰返し設計（反復デザイン）があ げられています。 ● ユーザの積極的な参加、およびユーザならびに仕事の要求の明解な理解 人間中心設計の 必要性の特定 利用の状況の 把握と明示 要求事項に対する 設計の評価 システムが特定の ユーザおよび組織の 要求事項を満足 設計による 解決策の作成 16 ユーザと組織の 要求事項の明示 ● ユーザと技術に対する適切な機能配分 ● 設計による解決の繰返し ● 多様な職種に基づいた設計 そして、 「7章：人間中心設計活動」がISO 13407の中心となる章です。人間中 心設計プロセスの中で行う四つの活動が定義されています。この章で提示されて いる図は、ユーザビリティ関係の書籍などでよく引用されています。 ● 利用状況の把握と明示 ● ユーザと組織の要求事項の明示 ● 設計による解決策の作成 ● 要求事項に対する設計の評価 ちんぷんかんぷん 初めてISO 13407を読んだ人の多くは「具体的に何を行えばよいのか、さっぱ りわからない」と感じると思います。実は、1章で「この規格は人間中心設計に必 要となる方法および技術（技法）の詳細を提供するものではない」と明言してい るとおり、ISO 13407は人間中心設計のマニュアルや指南書ではありません。 また、規格としての一般性を維持するために抽象的な表現を多用しています。 例えば、7章で示されている四つの活動の中の「利用状況の把握と明示」とは、具 体的には「インタビューとシナリオ作成」といいかえてみればわかりやすいでし ょう（もちろん、他のユーザ調査手法にいいかえてもかまいません） 。 ISO 13407は世界中で研究されたさまざまな人間中心のアプローチの集大成で す。個別の手法を解説するのではなく、プロセスの 骨格 だけを定義していま す。そのため、ユーザビリティエンジニアリングに関して具体的な知識・経験が ない人がこの規格を読んでも、さっぱり訳がわからないと思います。ある程度ユ ーザビリティの実務を経験してから読めば、規格の作成者がいいたいことは理解 できるはずです。 ところで、 『人間中心設計』と『ユーザ中心設計』はどこが違うのでしょうか？ 結論をいえば同義語です。ISO 13407に書かれている内容はユーザ中心設計その ものです。ただ、ISO 13407は労働者の安全や健康を守る「労働科学」の背景も 含んでいるので、商業的な意味合いが強い「ユーザ」よりも、より大きい概念で ある「人間」を使ったのだと思います。 17 ◆「ISO 9241-11:1998 第11部：使用性の手引」日本規格協会 ◆「ISO 13407:1999 インタラクティブシステムの人間中心設計プロセス」日本規格協会 ◆ドナルド・A . ノーマン（著）、野島久雄（訳）：「誰のためのデザイン？」新曜社 （1990） ◆ヤコブ・ニールセン（著）、篠原稔和（監訳）：「ユーザビリティエンジニアリング原 論」東京電機大学出版局（1999） ◆アラン・クーパー（著）、山形浩生（訳）：「コンピュータは、むずかしすぎて使えな い！」翔泳社（2000） ◆ヤコブ・ニールセン（著）、篠原稔和（監修）：「ウェブ・ユーザビリティ」エムディ エヌコーポレーション（2000） ◆ドナルド・A. ノーマン（著） 、岡本明（訳）：「パソコンを隠せ、アナログ発想でいこ う！」新曜社（2000） ◆黒須正明、他：「ISO 13407がわかる本」オーム社（2001） ◆三菱電機株式会社デザイン研究所（編集）：「こんなデザインが使いやすさを生む」工 業調査会（2001） ◆トム・ケリー（著） 、鈴木主税（訳）：「発想する会社！」早川書房（2002） ◆山崎和彦、他：「使いやすさのためのデザイン」丸善（2004） ◆I B M ユーザーエクスペリエンス・デザインセンター：「U s e r c e n t e r e d d e s i g n 」 http://www-6.ibm.com/jp/design/eou/2center/index.html ◆ J a k o b N i e l s e n 博 士 の A l e r t b o x （日 本 語 版 ）：「ユーザビリティの基 礎 知 識 」 http://www.usability.gr.jp/alertbox/20030825.html 18 この注文書は書店では扱えませんのでご注意ください。 割 引 購 入 申 込 書 株式会社オーム社 出版部 担当：藤沢 行 FAX 03-3293-2824 〒101-8460 東京都千代田区神田錦町3-1 電話 03（3233）0641（代表） ◆必要事項をご記入の上、 この用紙にてオーム社にFAXまたは郵便にてお送りください。 ◆価格には、消費税5％が含まれています。 ◆なお、 この申込書は書店ではご利用できません。直接オーム社宛にお申し込みください。 ◆配送手数料（税込）は次のようになります。 ① 代金引換払いの場合：525円（送料315円＋代金引換手数料210円） ② カード決済の場合：315円 ただし、2冊以上お申し込みの際はサービスとさせていただきます。 ◆下記申込書の太枠にお申し込み冊数をご記入ください。 記入欄 書 名 割引前 ユーザビリティエンジニアリング −ユーザ調査とユーザビリティ評価実践テクニック− フ ◆お リ ガ 名 割引価格【税込】 お申込冊数 2362円 2625円 冊 ナ 前 ◆配送先（ご自宅またはご勤務先のいずれかをご記入ください） ●ご自宅住所・ご勤務先所在地 （いずれかに◯印をつけてください） 〒 - TEL ●ご勤務先名 - 部署名 ◆お支払い方法（◯印をつけ、②の場合は必要事項をご記入ください） ① 代金引換払い ② カード決済 □Visa 会員番号 ヤマト便でお送りします。商品受け渡し時に、その場で代金をお支払いください。 下記マークの付いているクレジットカードはすべてご利用いただけます。 ご利用のカード会社に 印をつけ、会員番号、有効期限を明記の上、お申し込みください。 □MasterCard □JCB □American Express 有効期限 ③ 後払い（企業購入） 請求書、納品書、振替用紙を同封いたしますので、1ヶ月以内にお支払いをお願いします。 ◆その他連絡事項 ※個人購入の方は、代金引換えまたはカードでお願いします。 ※ご注文時に記載していただいた個人情報は、書籍の配送、それに伴うご請求、お支払い確認、及び、当社の出版案内を目的に利用し、それらの目的以外での利用はいたしません。
© Copyright 2026 Paperzz
