ラフスケッチの正当化

紙ベースのプロトタイプとインターフェイスのラフスケッチを用いることは、初期段階における機能とインタラクションデザインに関するフィードバックを得るための良い方法と言われているようです。（これはあなたが前回のコラムで触れた建築家・設計士によるものでしょう。）

鉛筆によるスケッチと簡易制作によるモックアップは、志願してくれたユーザに対して“明らかに未完成”だという印象を与えることになります。そういったイメージを持ったユーザは、完成に近いサンプルを利用するユーザにくらべて、より熱心に批評し、建設的な意見を多く述べてくれるようです。

しかし、そのような仮説を裏付ける、きちんと実験によって立証された調査結果は少ししか存在しないようです。Jutta Schumann による CHI'95 は、私がこれまで目にした中で唯一の本格的な調査（54人の設計士）資料です ─ 他のほとんどの著者は、データではなくモデルと方法論に主題を置いていました。

でもなぜこれがそんなに重要なのでしょうか？

私は、身体情報システムやプロセスコントロールセンターといった、高い安全性が必要とされるシステムに関わっています。それらのインターフェイスでは、“伝統的な”コンピュータの UI を持つ必要のない場合もあります。こういったシステムにおいては製品のデザインプロセスの各段階において厳重な品質管理が必要とされ、長期におよぶ研究が行われます。事故が起きた場合には、非常に広範囲な調査が実行されるのです。

それはつまり、極めて精確で信頼性の高いプロトタイプとユーザテストの素材を作成することの重要性を意味します。しかしそれこそが一番困難なことなのです！本当にうんざりする問題 ─ プロセスの他の段階に起因する問題が非常に多いのです。ラフスケッチによって決定されてしまった無謀な仕様や技術的な原因がその根本にあるのです。

きちんと数値で表された調査結果は、ビジネスにおけるラフスケッチ法の適切な予算配分に役立ちます。この分野については、更に詳しく見ていきたいと思っています。

John Murray
Managing Engineer, Human Factors
Exponent Failure Analysis Associates, Menlo Park, CA
jxm@exponent.com

John の考え方はめずらしい。たぶん彼の会社は他社の失敗に遭遇し、そのため彼は品質問題について過度に敏感になっているのだろう。もちろんほとんどのソフトウェア開発会社 ─ あなたや私の会社を除く ─ では、ソフトウェアというものはバグが一定の数、例えば 1000 とかそこらを下回ればリリースできると考えている。

しかしこのプロトタイプのあり方は、企業の品質管理についての無頓着さを浮き彫りにするのだ。

いきなり複雑で完成されたプロトタイプを作成することは、恐らく開発チームにとって最大の間違いだろう。John は、モックアップが完成から遠いほどユーザ（またはクライアント）から多くの指摘を得られるだろうと言っているが、これには逆の面もある：デザイナーと開発者は、簡単で粗雑なプロトタイプや不確定要素の多いストーリーボードを使って多くの問題点を見つけだしたいと考えるのである。

子どものための（あるいは大人のための）ロゴ言語の父と言われる Seymour Papert がアフリカで開催された会議で講演した際、まもなく会場は混乱しはじめ、多くの参加者が退出してしまったという。Seymour がアフリカ人の一人に何が問題なのかと尋ねると、彼は「あなたたちアメリカ人は思っていることをはっきり言い過ぎる」と言ったそうである。

つまり彼らの文化は我々のものよりもずっと温厚なのである。人々ははじめから自分の立場を主張して結果的に不本意な妥協をしたりしないのである。彼らはまず問題の一番外側から話し始め、お互いに同意できる部分を議論する。そして意見が一致する点を確認しながら徐々に問題の中心に移っていく。このやり方を守らない議論は不作法で侮辱的と見なされるのである。

ユーザとクライアントの両方を納得させる方法として、私はこのアフリカのやり方に従っている。ユーザとクライアントを最も初期のデザインプロセスに組み込んでしまうのである。彼らから何らかの解決策を得ようと期待してはいけない。それよりも問題点を明確にする作業をしてもらうのだ。そして初期段階におけるあなたの考えを共有する。役に立たないこともあるが、大抵は、全員で袖まくりし、一人では解決できなかった問題を解決できるようになるのである。

ラフスケッチを見せることで問題が起きたという私の唯一の経験は、クライアントが完成されたプロトタイプを求めていた時である。もしあなた自身がユーザやクライアントの期待を早い段階で形成してやることができれば、ラフなスケッチを受け入れてもらえるのである。（うまくコンセプトを売り込むことができれば、彼らは受け入れるだけでなく、それを要求するようになる。）

次の段階に移行する場合にも、ものごとをシンプルに保つこと。システム全体を通しての見た目、特に主要な見せかけの部分だけを作り上げれば、中身は必要ない。その後、重要なあるいは典型的な部分に関していくつかの“作り込み”を行う。これらの部分についてユーザテストやクライアントミーティングを行い、できる限りのことを学習する。そして、その知識を残りのデザイン開発に反映させるのだ。

私はこれまで、“理想的に”作り込んだデザインを主張したこともある。だがそれはうまくいかなかった。だからあなたが同じ失敗を繰り返す必要はない。どういうことか教えてあげよう：リリース直前、クライアントがあなたのオフィスに座ってこう言うのだ「2週間以内にこのプロジェクトを全てやり直してくれ」。いや、訂正。クライアントが座っているのはあなたのオフィスではない。あなたの上司のオフィスだ。

John はこの分野に関する調査をしていきたいと言っている。来年には本当に SIGCHI（Special Interest Group on Computer-Human Interaction）な議論ができるだろう。

プロトタイピングやテスティングについて更に探求したければ、Jakob Nielsen の素晴らしい本「Usability Engineering」をお薦めする。

また来週会おう。

tog@asktog.com