"ユーザービリティ"の怪

今回のタイトルを見て「あれ？」と思った人は"正解"です。何とも思わなかった人は、コラムの内容をよく読んでみてください。

ユーザ派 vs. ユーザー派

外国語を日本語で表記する場合、様々な問題が起きます。その中でも悩ましいのは、カタカナ用語の長音表記です。

• ユーザ
• ユーザー

• ユーザエクスペリエンス
• ユーザーエクスペリエンス

• ユーザテスト
• ユーザーテスト

工学系の教育を受けた人は「ユーザ」派が多いと思いますが、新聞や教科書など、一般的には「ユーザー」が多く用いられています。その論争は、なかなか収束しそうにありませんが、私たちユーザビリティ業界で多用する「user interface」の場合はもっと厄介なことになっています。

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

原語の「user」と「interface」をどのように表記するかによって、６種類ものバリエーションが生まれてしまっています。公的なガイドラインはあるのですが、上記６種類はいずれも"間違い"とは言えません。どの表記を使うのかは、執筆者の"主義・主張"によるのです。（ちなみに私は上から３番目の「ユーザインターフェイス」派です。）

では「usability」の場合はどうでしょうか？

• ユーザビリティ
• ユーザビリティー
• ユーザービリティ

「ユーザビリティ」と「ユーザビリティー」はどちらも正解ですが、３番目の「ユーザービリティ」は間違いです。それは、原語の綴りを見れば明白です――「userbility」ではなく「usability」なのですから。

失敗のメカニズム

しかし、ネット上や紙面で実際に「ユーザービリティ」は使われています。なぜ、間違いが通用しているのでしょうか？

私の体験に基づくと、その発生ロジックは以下の通りです。

1. 工学系の筆者は「user」を「ユーザ」と表記する傾向がある。
2. ところが出版社の編集ガイドラインでは「ユーザー」と長音表記することになっていることが多い。
3. そこで編集者は原稿に対して「ユーザ＝ユーザー」という"一括変換"をかける。
4. その結果「ユーザービリティ」という誤表記が生まれる。

「ユーザービリティ」は編集者によるケアレスミスなのです。決して「ユーザ vs. ユーザー」のような執筆者の"主義・主張"の問題ではありません。

ところが、そのミスを再利用してしまうロジックが、さらにあるのです。それは、「ユーザビリティの語源は"user"である」という思い込みです。

人間のユーザーに関する特性だから、ユーザーに接尾語を付けて「ユーザービリティ」である――それなりに理屈が成り立っているように見えますが、残念ながら「usability」の本当の語源は「user（使用者）」ではありません。「use（使う）」です。

use（使う） + able（できる） = usable（使用できる）= usability（使用可能性）

つまり、ユーザビリティとはヒトではなくモノに関する特性なのです。ユーザビリティはモノに中に存在する（作り込む）特性です。だから、私たちユーザビリティエンジニアが扱っているのは、人間ではなく、製品のユーザインターフェイスなのです。

【参考情報】

◆マイクロソフト製品ならびにサービスにおける外来語カタカナ用語末尾の長音表記の変更について
http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3491

◆TC協会：外来語（カタカナ）表記ガイドライン（第2版）
http://www.jtca.org/ai_collaboration/katakana_wg/index.html

◆HCD重要用語のカタカナ表記 ガイドライン
http://www.hcdnet.org/hcd/column/katakana.php

第４回 UXブッククラブ in IRIYA 参加者募集

人机交互論の著者の樽本です。いつもブログを読んでくださって、ありがとうございます。

2010年最初のテーマはズバリ『ドン・ノーマン』です。メインの課題本は『エモーショナルデザイン』ですが、それとどまらず、幅広くノーマンについてディスカッションしたいと考えています。

＜開催概要＞

• 費用：無料
  
• 開催場所：東京・入谷
  
• 日時：２／２７（土）　１４：００～１７：００
  

参加ご希望の方は下記ページの参加者リストの欄にご記入ください。

• UXBC Tokyo 参加者募集ページ
  

皆さんとお会いできる機会を楽しみにしています。

UCDヒストリー

2000年代が終わり2010年代に入りました。次の１０年を展望する前に、少し過去を振り返ってみたいと思います。

そもそもUCDの始まりとは？――。それは第二次世界大戦までさかのぼります。戦時中、アメリカでは戦闘機パイロットの操縦ミスを減らすための研究をしていました。これが後に「人間工学」へと発展します。その研究対象は軍事から民生品へと拡がっていきました。

1950年代～1980年代初頭 ― MMIと人間工学の時代 ―

ひと昔前、UIは「マン・マシン・インターフェイス（MMI）」と呼ばれていました。確かに自動車の計器パネルや生産機械の制御盤は"マシン"と言ったほうがしっくりきます。それに、当時のユーザは必ずしも"お客様"ではありませんでした。MMIを操作するユーザの多くは専門のオペレータや自社の従業員などだったのです。

当然ながら、MMIは必要最小限でOK――。要するに「人に害を及ぼさない」レベルで十分でした。訓練期間の短縮、作業効率の向上、事故の防止などが良いMMIの条件でした。

この時代のユーザビリティ専門家は、まさしく白衣を着た博士のイメージでした。ベル研究所やIBMのワトソン研究所、ゼロックスのPARCなどで、人間工学や心理学などの学位を持った研究者が、主に（先駆的な）基礎研究に携わっていたのです。

1980年代中頃～2000年 ― UIとユーザビリティの時代 ―

1988年にドン・ノーマンは、日常の"使いづらいモノ"について認知心理学的な視点で考察したユニークな著書『誰のためのデザイン？』を発表しました。この本の中でノーマンは「ユーザ中心設計」を提唱しました。

ちょうどその頃、パソコンが本格的な普及期を迎えます。パソコン（およびPC用ソフトウェア）はそれまで人類が手にした道具の中で、最も操作が複雑なものの１つだったかもしれません。ところが、"普通"のユーザはあまり勉強熱心ではありません。そこで、製品をなるべく「初めての人でも使用可能（usable=use+able）」なレベルにするためにユーザビリティが注目されるようになりました。

さらに、1990年代中頃からインターネットが急速に普及します。それまでのPC用ソフトウェアと違ってユーザはウェブサイトを購入・所有しません。使用するだけです。もし使いづらいと感じれば、ユーザは"ワンクリック"で立ち去ってしまいます。そのため、特にウェブユーザビリティの重要性が認識されるようになり、ユーザビリティの黄金期を迎えます。

この時代のユーザビリティ専門家は実務家（兼　実業家）が中心となります。全盛期にあったソフトウェア業界で実務経験を積み、その後、独自の手法を掲げてコンサルタントとして独立するというパターンが多かったと思います。実際、UCDの代表的な手法は全てこの時代に登場しています。（ヨーロッパでISO 13407が制定されたのも1999年です。）

• ヤコブ・ニールセン：ユーザビリティ工学の開拓者。"5ユーザテスト"に代表される「Discount usability」を提唱。ウェブユーザビリティのグル。
• ジャレッド・スプール：UIEの創業者。米国ではニールセンと並び称されるユーザビリティ界の大御所。
• カレン・ホルツブラット：ヒュー・バイヤーと共に「Contextual Design」を開発。"エスノグラフィ"をITに取り入れた先駆者。
• ジョン・キャロル：「Scenario Based Design」の先駆者。ITにおける"シナリオ"の有効性を実証し、普及啓蒙に大きく貢献。
• ラリー・コンスタンチン：ルーシー・ロックウッドと共に「Usage Centered Design」を開発。ソフトウェア開発と相性の良い"UMLライク"なモデリング手法を確立。
• アラン・クーパー："ペルソナ"の父。ペルソナを中核とした「Goal-Directed Design」を提唱。

2000年代初頭～現在 ― インタラクションとUXの時代 ―

1990年代中頃、当時、アップルで副社長を務めていたドン・ノーマンが新たに「ユーザエクスペリエンス（UX）」という概念を提唱しました。個々の製品の使い勝手（ユーザビリティ）の改善にとどまらず、「ユーザの中長期的な利用体験全体をより魅力的なものにしよう」というのです。ただ、あまりに壮大な理念なので、ノーマンの在職中には大きな成果にはつながりませんでした。

21世紀に入ってお手本となる成功事例が現れました――「iPod」です。その優れた工業デザインと操作性に加えて、iTuneによる楽曲の販売という新たなビジネスモデルを構築して、多くのユーザの"音楽体験"をすっかり書き換えてしまいました。この成功をきっかけにして、UXは具体的に目指すべきビジネスゴールとして広く認識されるようになりました。

そして、その担い手としてデザイン会社とデザイナ（特にインタラクションデザイナ）が注目されるようになっています。そのためか、欧米の既存のユーザビリティ専門家は自分自身のことを、あまりユーザビリティエンジニアと名乗らなくなってきています。彼らは「ユーザエクスペリエンス専門家」や「ユーザリサーチャ」といった肩書きをよく使っています。

• デビッド・ケリー：IDEOの創業者。その後スタンフォード大学でd.schoolを立ち上げて現在も教鞭を執っている。
• ビル・モグリッジ：IDEOの創業者。1980年代に「インタラクションデザイン」という言葉を発明した。
• ジェス・ジェームス・ギャレット：Adaptive Pathの創業者。現在最もよく知られているUXの基本概念「Elements of User Experience」を2000年に提唱。またAjaxの提唱者としても有名。
• ダン・サファー：元Adaptive Pathのインタラクションデザイナ。DESIGN IT! 2008で基調講演を行った。現在は、ジェスチャー操作専門のデザイン会社を運営している。
• ルイス・ローゼンフェルド：図書館学をウェブデザインに取り入れた「情報アーキテクチャ」の先駆者。最近はRosenfeld MediaというUX専門の出版社も運営している。

そして未来は...

上記の「インタラクションとUXの時代」とほぼ同時期に、アジャイル開発のムーブメントが起こりました。ケント・ベックなどによって2001年にアジャイル・マニフェストが宣言されて以来、欧米では急速にアジャイル開発が普及しています。

当初は「アジャイルとUXは相反する」との議論もありましたが、開発現場で試行錯誤を繰り返す中から"アジャイルUX"または"アジャイルUCD"が徐々に認められるようになってきています。実際、2008年のAgile conferenceからはAgile UXが独立したトラックとして開催されるようになっています。

アジャイルUXはまだ発展途上の分野ですが、後から振り返れば、2010年代は「アジャイルとUXの時代」と呼ばれるようになるかもしれません。

• ジェフ・パットン：アジャイルUCDのトップランナー。アジャイル開発のコンサルティングで有名なThoughtWorks社の出身。
• リン・ミラー：AutoDesk社の社内エンジニア。自社の製品開発に積極的にアジャイルUCDを取り入れ、その成果を公表している。
• トッド・ザキ・ウォーフェル：今、注目のUIデザイナ。特にアジャイルなプロトタイピング手法で有名。

【参考情報】

◆Alertbox：ユーザビリティ25周年に寄せて
http://www.usability.gr.jp/alertbox/20080421_25-years-usability.html

◆HCD-Net黒須理事長コラム：「ユーザビリティ前史1～3」
http://www.hcdnet.org/hcd/column_01/12.php
http://www.hcdnet.org/hcd/column_01/13.php
http://www.hcdnet.org/hcd/column_01/14.php

ペーパープロトタイピング

先日、UXブッククラブを開催しました。今回の課題本にはキャロリン・スナイダーの『ペーパープロトタイピング（原題：Paper Prototyping）』を取り上げました。

実は、本書については５年前の発売直後にも一度記事を書いています。

その当時、もうペーパープロトタイプは目新しい手法ではありませんでした。古くはヤコブ・ニールセンの『ユーザビリティエンジニアリング原論』（1994年）に記述がありましたし、ネット上でも実践ガイドを目にする機会が多くありました。本書の中にも1970年代にNCR社やゼロックス社で行われたプロジェクト例が紹介されています。

さて、そんな"枯れた"手法を、今になってわざわざUXブッククラブで取り上げたのは、私が懐古趣味だからではありません。実は、この５年くらいの間に、ペーパープロトタイプはその利用場面がかなり変化しているのです。

従来の使い方

名詞の「ペーパープロトタイプ」は紙でできたUIモデルを指しているに過ぎませんが、動詞形の「ペーパープロトタイピング」はペーパープロトタイプを使った設計活動を意味します。

本書も書名を動詞形にしており、「ペーパープロトタイプを使ってユーザテストを行う」という大きな文脈に基づいて構成されています。それは著者自身が最終章で「この本はユーザビリティテスティングの入門書でもある」と記していることからも明らかです。

彼女が経験を積んだ1990年代から本書を執筆した2000年台前半くらいまでは、通常、ペーパープロトタイプとユーザテストは組み合わせて使われる手法でした。例えば以下のような感じです。

◆paper prototype usability test:
http://www.youtube.com/watch?v=ppnRQD06ggY

ここではCorel社のユーザビリティラボで行っているペーパープロトタイプを使ったユーザテストの様子が紹介されています。これが、最もオーソドックスなペーパープロトタイプの使い方と言えるでしょう。

新しい使い方

皆さんは、以下の映像をご覧になったことはないでしょうか？

◆Google Docs in Plain English:
http://www.youtube.com/watch?v=eRqUE6IHTEA

◆Twitter in Plain English:
http://www.youtube.com/watch?v=ddO9idmax0o

これらはGoogle DocsとTwitterの宣伝用の映像で、一時期、各サイトのトップページで公開されていました。いずれも映像の中盤以降にUIのペーパープロトタイプが登場していますが、明らかに、これらはユーザテストを目的にしていません。目的はプレゼンテーションです。

次の映像では、イタリア人の学生（？）がPDA用の新しいアプリケーションに関するアイデアを実演しています。

◆Ciao PDA application:
http://www.youtube.com/watch?v=c4-A-9hGn0U&feature=related

インタラクティブなシステムであっても、ペーパープロトタイプならば１行のコードを書く必要もありません。そしてパワーポイントのスライドよりもはるかに"伝わり"ます。

さらに、ペーパープロトタイプのほうが本物よりも効果的な場合もあります。上記のGoogle DocsとTwitterでは、敢えて（デジタルを紙に）ダウングレードすることで、余分な情報を排除してコンセプトを明快に提示しています。

このように、現在では「企画段階」でもペーパープロトタイプが大活躍するようになりました。

古くて新しい手法

キャロリン・スナイダーは本書の中で事例をいくつも紹介しています。その多くは、もちろんペーパープロトタイプを使ったユーザテストの事例なのですが、１つだけ毛色の異なる事例が含まれています。それは「逆オークション特許」で有名なPriceLine.comです。

プライスラインはプロジェクトの初期段階で、技術的な課題以前の課題――そのユニークなアイデア（逆オークション）がユーザに受け入れられるのか？――という根本的な課題を抱えていました。そこで、彼らはシステム開発に多大な投資をする前に、ペーパープロトタイプでユーザに逆オークションを仮想的に体験してもらったのです。

その結果、いくつもの重大な結果が明らかになりました。それらはUIの問題と言うよりも、ビジネスルールに係わるような問題でした。

ペーパープロトタイプのお陰で、プライスラインはシステムを開発するずっと前に、ユーザニーズとビジネスモデルの根本的な相違点を発見して修正できたのです。それが成功の大きな要素であったことは疑いないでしょう。

これは1997年の話です。つまり、今から１０年以上前に、既に、企画段階でペーパープロトタイプが活躍していたことになります。ですから、前節で紹介した「新しい使い方」は必ずしも新しくはないと言わざるを得ません。

ただ、従来の使い方も新しい使い方も、１つの共通点があります。それは、紙を使ってアイデアを素早く形にして、実際の利害関係者と共有するということです。言葉や仕様書とは異なり、ペーパープロトタイプは目に見えて触れるので、利害関係者とのコミュニケーションはより深まります。

ペーパープロトタイプの使い方は変化するとしても、これからも、ずっとペーパープロトタイピングは優れたコミュニケーション手法として利用され続けるでしょう。

スケッチボード法

米Adaptive Path社では『スケッチボード法（Sketchboards）』と呼ぶユニークなデザイン手法を編み出して活用しています。この手法は彼らの"売り"の１つで、自社開催のカンファレンスの中でも恒例企画として３日間にわたるワークショップを開催しています。

先月、日本でもこのスケッチボード法をテーマとした勉強会（日本初？）が開催されました。（※貴重な機会を提供してくれた加納豪氏に感謝！）

勉強会に参加して非常に興味が湧いたので、さらにスケッチボード法を調べてみました。おおよそ全容が把握できたのでご紹介します。

スケッチボードとは

これはデザイナのJason Robb氏が公開しているスケッチボードの実例です。

参照元：
http://www.flickr.com/photos/jasonrobb/sets/72157621808437656/

ユースケース、ユースケースマップ、ページフロー、ワイヤーフレーム、コメントなどが１枚の大判の用紙に貼り付けられているのが分かります。この用紙全体をスケッチボードと呼びます。

つまりスケッチボードとは全てのドキュメントやアイデアやフィードバックが１カ所（１枚）で「見える化」されていて、さらに容易に「持ち運び可能」というものです。

スケッチボード法のプロセス

上記のような巨大な用紙を中心としたデザイン手法がスケッチボード法です。

1. 発想を拡げる：ワードプレイ、6-upテンプレート、インスピレーションライブラリなどを使って、可能な限りアイデアを出す。
2. アイデアを集約する：一番良さそうなアイデアを選んだり、アイデアを組み合わせたり、さらにブラッシュアップしたりしてアイデアを１枚（1-upテンプレート使用）にまとめる。
3. スケッチボードを作る：ボードの左３分の１くらい（インプットエリア）にペルソナやシナリオなどを貼り付ける。残り３分の２のエリアに各自のアイデアを貼り付ける。似たようなアイデアをまとめたり、アイデアを追加したり、順序関係を検討して配置しなおす。ひとまとまりのアイデアのグループに見出しをつける。
4. プレゼンテーションする：関係者（経営者、開発者、マーケティングなど）の元へ出向く。自分たちのアイデアをスケッチボードを"持参"して説明する。随時フィードバックを受けて、それをスケッチボードに追記する。
5. スケッチボードを改訂する：フィードバックを考慮して、改めてアイデアを追加・整理してスケッチボードをバージョンアップする。有効なアイデアが出なくなるまでプレゼンテーションとバージョンアップを繰り返す。
6. プロトタイプを制作する：「重要度＊複雑さ」という２軸で分類して、プロトタイプを作る範囲を決める。スケッチボードから直接、HTML/CSS+JavaScriptベースの"動的"なプロトタイプを作る。

ところで、スケッチボード法には大切な前提条件が１つあります――それはペルソナとシナリオ（解決すべき課題）です。事前にペルソナとシナリオが定義されていないと議論を始めることができません。スケッチボード法は"ある課題"を解決するために、発想とコラボレーションをチームで効率良く行う方法なのです。

超特急のデザイン

スケッチボード法は基本的に紙とペンしか必要としない"超アナログ"な手法ですが、同時に"超特急"です。実際、Adaptive Path社の場合は最終デザインまでを１週間（５日間）で完了するようです。

• 月曜日：ブレストとスケッチ作成
• 火曜日：スケッチボード作成とレビュー
• 水曜日：デザイン案作成
• 木曜日：デザインレビューと改善
• 金曜日：デザイン完了

これを３週間連続で"スプリント"するそうです。どうです、ついて行けそうですか？

いずれにせよ、今後、アジャイル開発が主流になると、これくらいのスピード感でUIをデザインしないと、とても間に合わないことは確かだと思います。

【参考情報】

◆第 6 回 すくすくスクラム勉強会：『デザイナー気分でAgileUX』
http://www.microsoft.com/japan/powerpro/developer/agile/article/nov_09.mspx
スケッチボード法の勉強会の開催レポートです。

◆Sketchboards: A Technique for Better + Faster UX Solutions
http://www.youtube.com/watch?v=iVFTBj_BYy0
スケッチボード法の概要をわずか "1 分 30 秒" で理解できるビデオ映像です。

◆Sketchboards: Discover Better + Faster UX Solutions
http://www.adaptivepath.com/ideas/essays/archives/000863.php
Adaptive Pathのスタッフが書いたスケッチボード法の解説です。

◆Sketchboards + Prototypes
http://www.slideshare.net/ugleah/sketchboards-prototypes-presentation
Agile 2008 のワークショップで使用されたスライドです。

◆Good design faster
http://www.slideshare.net/whatidiscover/good-design-faster
UX Week 2009のワークショップで使用されたスライドです。

追加情報（2009/12/24）

Adaptive Pathの発想法に関するスライドがありました。

◆UX Team Of One @ IA Summit 2008
http://www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one

• まず一次元で発想。次に平面、そしてグリッド形式に発想を広げる。
• 臨時のデザインワークショップを行う。アイデアを記述するためのテンプレート使用。
• デザイン原則（＝ビジネスニーズ＋ユーザニーズ）を使って判定する。