要約：私たちはウェブを「わかっていない人」をわかっていない人です。彼らをわかるための手法としてのユーザ中心設計手法、特にユーザ調査におけるコンテキスト調査法に少し触れてみます
この記事は続き物です。「わかっていない人」をわかる方法（前）ーユーザ中心設計についてがこの前の記事にあたります。
どうやって「一般人」をわかるのか
「わかっている人」によって考えられた「これがニーズだろう」という思いこみをベースにしたような開発志向の手法では、一般人を理解しようとするのは困難です。ですので、そのようなアイデアありきではなく、まずターゲットする一般人が日常的にウェブにおいてどういう行動・利用をしているのか把握するところから始めないといけないよねということを述べました。アイデア発ではなくユーザ発で考えるという感じでしょうか。
マーケティングはこの辺、理論と数字によって一般人を理解しようとしていると感じるのですが（もちろん、それも重要ではあって一概に否定するわけではないですが）、どうもそこからは「一般人」の実際の利用シナリオは具体的には浮かび上がってきません。
そこで、ユーザ中心設計という方法を用います。ユーザ中心設計手法（UCD）はユーザの利用状況に注目し、観察し、それに基づいて解決策を提示しながら改善を図るプロセスです。
樽本氏の『ユーザビリティエンジニアリング』という本では、このユーザ中心設計手法のポイントの1つとしてユーザの参加を挙げています。
- ユーザの参加
- ユーザの視点で考える場合に”想像上”のユーザの視点では無意味です。それでは、従来の設計となんら変わりはありません。そこで、ユーザ中心設計のインタビューやテストには、必ず”本物”のユーザに参加してもらいます。
ユーザ中心設計（正確には人間中心設計）はISO13407で定義されていますが、具体的なプロセスはこんな図で説明されます。
先の”本物”のユーザに参加してもらうユーザ中心設計のインタビューやテスト
というのは、この図で言う「ユーザ調査」や「ユーザビリティ評価」の段階で行う手法にあたります1 。
例えば「ユーザ調査」ですが、これはインタビューを行ったり、アンケートをとったりするわけではありません。そうした手法は様々な観点からあてにならないということが言われていて、実際それを役に立つツールにするためには結構な経験が必要になるようです。ではなく、むしろユーザの行動を観察することによって、その利用状況をあぶり出すというのがユーザ調査の本質です。
具体的にはコンテキスト調査法などの手法が使われますが、詳しくは無料公開されている件の本の第1章2 や棚橋さんの記事などで確認できます。
UCDの実践にあたって
ただ実際のところ、未経験な人がいきなりこれをできるかというと少し留保をつけざるを得ません。
というのも、こうしたユーザ設計手法を行う上で必要な経験やノウハウ、あるいは根底にある考え方が（日本の）ウェブや私たちにまだ蓄積されていないと感じるからです。
例えば、先のユーザの利用状況を調査するコンテキスト調査にしても、生データを得るのが目的であるのにそれを要約してしまうとか、あるいはその調査の意図を鑑みないで手法ありきで行ってしまったがために質問方法自体がまずく、役に立たない生データを量産しちゃったり。ユーザテストなんかでも同じ事は起こりえますね（参考：ユーザーテストはこうやります、およびユーザーテストはテスト設計が大事）。
考え方が浸透していなかったり、経験が蓄積していないがゆえに結果の善し悪しに非常にバラツキのある手法になってしまう。これが実際に役に立つようなユーザデータを生み出すことが難しくなっている要因なのではないかなと思います。
それゆえに体系だったUCDの手法は一部の専門家が行うものになってしまって、私たちはヒューリスティック評価手法のようなプロの一般論をありがたがるくらいしかできない、そんな状況があるように思います。
最初はみんな初心者
とはいえ、それで終わっていては何の進展もありません。
最高は適切の敵である
という言葉があります。ユーザビリティ工学の先達であるヤコブ・ニールセン氏が著書の中で、最高・最善（専門家の求める厳密な手法など）を求めるとコストが高くなって取るべき方法が無くなってしまう状況を憂慮して引いた言葉です（ニールセン氏はこういう現実的な話し方が非常に上手な方です）。
ですので、トライ&エラーを重ねつつ習得していくしかないでしょう。
先に挙げたユーザ調査法である「コンテキスト調査法」ですが、具体的には以下のようになっています。
（略）インタビューアが弟子、ユーザが師匠となって、師匠の体験を弟子に”継承”しようとします。基本プロセスは以下のようになります。
- インタビューアはユーザに”弟子入り”する。
- ユーザ（師匠）は仕事を見せながら説明する。
- インタビューア（弟子）は、不明な点があればその場でどんどん質問する。
- ひと通り話を聞いたら、インタビューア（弟子）は理解した内容をユーザ（師匠）に話して、間違っていないかどうかチェックしてもらう
（略）
この手法の最大のポイントは、ユーザが”教える”つもりになることです。いったん教えるつもりになれば、ユーザは結論だけを話すのではなく、自分の体験を始めから終わりまで、なるべく順序立てて詳しく説明してくれます（実際には、話の順序が入れ替わったり、途中が抜けたりするので、インタビューアが適切な質問をして補正する必要があります）。
この時の基本テクニックとして、樽本氏は3つのポイントを挙げています。
- 教えを請う
- 何を教えて欲しいのかハッキリさせて、ユーザに伝える。正確にはだんだんとフォーカスを絞るという感じ
- 根掘り葉掘り
- ユーザの行動がはっきり理解できるように、またその行動に自分の憶測・解釈を交えないために、少しでもわからないところがあったらそのままにせずきちんと質問する
- 確認する
- 誤解しないためにもユーザにその理解した内容をきちんと確認する
例えば、学生の人であれば身近な人（「一般人」的な友達）と話すときに、この手法をこっそり用いて、どんな利用形態をしているのか観察してみてはいかがでしょうか。そこから何か新たな知見が得られるのではないかと思います。
おまけ
とはいえ、僕自身それほどこうした手法に精通しているわけではありません。むしろ今も、本当にこの手法を行っていけばわかるのかどうか確認しつつという感じです。
このユーザ中心設計というのはウェブデザインに限らず、もっと大きいくくりで考えたほうが良い気がして、最近はこの本を読んでいます。すぐにとはいきませんけど、この本を読んで発見したことがまとまったらまたレビューとしてまとめたいと思います。
ちなみに以前に次世代OPACの話をしましたが、これもアイデアありきの開発志向で突っ走ってしまうような気がして、今見直し中です。うーん、ウェブサービスってちゃんと考えてみると大変だなぁ。
関連エントリ
- もちろん、わかりやすくいっているだけで、その他の段階でユーザが登場しないと言うことではありません。その他のプロセスでも必要によって、ユーザを登場させて調査・評価・ニーズの探索などをする必要があるでしょう[戻る]
- 具体的な手法が展開されているのは2章なんですが[戻る]
Popularity: 3% [?]
- キーワード：
サイト内
サイト外
読者のコメント
0件