語ること、行うことは、あるコンテキストの中でそうすることであると同時に、あるコンテキストを構成するという二重の行為である。川床靖子『学習のエスノグラフィー』
これだけだとわかりにくいのですが、ここで言われていることは、日常の生活において誰かと何か話をしたり、仕事である成果物を依頼主に受け渡したりする場合でも、そこでアウトプットとして相手に受け渡される具体的な発話や成果物は、会話の流れや契約という文脈が最初から存在する状態で受け渡しが行われるというだけでなく、発話や成果物が相手に受け渡されるということ自体により会話の流れや契約という文脈が成立するということを意味しています。
つまり、会話や契約のルールは、ルールが守られて（あるいは破られて）はじめてルールとなるのだということです。
これはいわゆるエスノメソドロジー的な視点ですが、人間の行動や認知というものを理解するうえでは非常に大事な視点だと思います。特に、ユーザー中心デザイン、人間中心設計を行う場合にはこの「状況・コンテキストに埋め込まれた認知的行為」ということをきちんと理解しておかなくては、いくらユーザーの行動を観察やインタビューにより調査しても、その行為や認知の構造を正しく理解するための構造＝状況・コンテキストの分析を行うことはできないでしょう。まさに「隠れた繋がりを見つけることも･･･」ですね。
調査結果をいきなり切り刻んでKJ法をすることの危険性
これはペルソナをつくる際にもいえることです。一般的にはペルソナをつくる方法として、ユーザー調査で集めた情報をいきなりバラバラに切り取って、その要素をKJ法（親和図法）を使って分類しましょうと説明されています。しかし、実際にやってみるとわかるんですが、この方法だとそれぞれのユーザーの行動のコンテキストがその時点ですっかり抜け落ちてしまうんです。
それぞれのユーザーの行動や発話のコンテキストを理解しないまま、行動や発話の要素を抜き出して、抜き出した言葉のニュアンスのみで分類してしまうので、異なるコンテキストにおける行動がおなじカテゴリーに分類されてしまうことになります。つまり、ユーザー行動を間違って理解してしまう危険があるのです。
それが危険なのは、昨日の「業務システムのユーザビリティ」で紹介した小学生のかけ算の例をみても想像することができます。日常のコンテキストと算数のコンテキストでは同じ表現が異なる意味を持ちえるからです。
それぞれのユーザーの発話・行動とそのコンテキストの分析なしに、行動や発話の要素だけを切りだしてKJ法による分類を行ってしまえば、まるでユーザーの行動の背景を理解していないペルソナやシナリオができてしまい、デザインをする上でまったく役に立たないもの（いや、むしろデザインを間違えさせる原因）になってしまう可能性さえあります。
それなのに、実際のデザイン・プロセスにおいては、この分析が抜けてしまうことが多々あります。
別の言い方をすれば、業務システムを設計する際にSIerさんは基本的にエンドユーザーへのヒアリングを通じた業務分析や現状システムの分析からデザイン＝設計をはじめるのに、なんで、ほかの分野のデザインはそれが実際に利用される場面の利用目的や利用の背景、実際の使い方を把握しようともしないし、それをきちんと分析しようともしないのか？ってことですよ。
ビジネスや実際の業務を理解できなきゃ、役に立つ業務システムなんて作れないってことはSIerさんなら普通にわかってらっしゃる。でも、それ以外のデザインの分野では、利用者がどんな目的でどんな風にそれを利用するかなんてことはまったく考えずにデザインするのが当たり前になっちゃってる。この「当たり前」ってどうかしてますよね？
まぁ、その「当たり前」がおかしいって思う人は、ユーザー調査をしてみようと思うんですけど、そこでもう1つ落とし穴があって、調査してみた表面的な行動のみで満足してしまう。これだと調査をした意味がほとんど発揮されないケースもあります。SIerさんが業務分析するように、ユーザーの行動分析をしなければ、ユーザーの仕事とそのコンテキストは見えてこないということを理解する必要があるでしょう。
統合の過程を間違えるとペルソナはむしろデザインの邪魔になる
ですので、ユーザー調査で得られたユーザーの行動に関する情報は、個別にそれぞれの行動の構造を状況・コンテキストという視点でしっかり分析、理解したうえで、その行動を扱わないとまったくトンチンカンなユーザーモデルをペルソナやシナリオとして表現してしまう恐れがあります。よくあるペルソナ／シナリオ法の説明で抜け落ちているのはまさにこの部分でしょう。結果としてできたペルソナやシナリオの文書がそれらしければOKみたいな判断では、デザインを混乱させるだけです。
そういうペルソナをつくるくらいなら、むしろ、ユーザー調査の結果を統合せずに最後まで個別のユーザーデータに基づいてデザインを進めるほうがよっぽどマシだと思います。ペルソナ／シナリオ法には統合の際にそうした落とし穴があることをちゃんと理解していないと、せっかくのユーザー調査さえ無駄になります。
これが昨日の「業務システムのユーザビリティ」で、ペルソナ／シナリオ法をデザイン・プロセスのなかで紹介しなかった理由です。業務システム開発など、比較的、システムを利用するエンドユーザーの層が絞り込まれている場合、中途半端な理解でペルソナをつくるくらいなら、調査対象にしたエンドユーザーの個別の情報を対象にその行動を分析して、それをベースにユースケースなり業務分析を行う方が正しい業務理解ができると思うからです。もちろん、コンテキストと行動の関係を理解した上でペルソナ／シナリオを作成するなら、それは強力な武器にもなりえるんですけど。
5つのワークモデルで、行動が行われる状況・コンテキストを可視化する
『ペルソナ作って、それからどうするの？ ユーザー中心デザインで作るWebサイト』でも詳しく説明していることですが、ユーザー調査を通じて得たユーザーの行動に関するデータは、5つのワークモデルを使って、その行動をそれが埋め込まれたコンテキストとともに構造的に分析しないと意味はないと思っています。分析という言葉に論理的で堅苦しいイメージをもたれる方もいるかもしれませんが、本来、分析という作業は非常に創造的なものです。そのままでは見えなかったあるものを、分析を通じて見えるようにする。もともと存在していたという意味では発明ではありませんが、いままで見えていなかったものを陽の目に晒すという意味では発見であり、創造です。多くのデザインの現場ではこの作業を怠ってしまっているので、創造的なデザインができなくなっています。問題は定義した。調査も行った。でも、できたものは別に普通と代わり映えのしないものになってしまった。それは分析の作業を通じて、当たり前を「当たり前」に変換する作業を行っていないからです。
5つのワークモデル分析に関しては、前に「ユーザー行動を構造的に分析するための5つのワークモデル」でも紹介していますので詳しく説明しませんが、「フローモデル」「シークエンスモデル」「アーティファクトモデル」「文化モデル」「物理モデル」の5つの視点で、ユーザーの行動を分析してみることで、ユーザーの行動とそのコンテキストの相互作用を理解することを目的として行う作業になります。
つまり、デザイン・プロセス上で、ユーザー調査と統合のあいだに以下のような形で「ワークモデル分析」をはさむことで、ユーザーの行動がどのようなコンテキストに埋め込まれたものかを把握した上で、個別のユーザー行動の理解からユーザーグループごとの統合に向かうわけです。実際、個別の行動コンテキスト理解が行われていなければ、どのユーザーを同一のグループとして統合すべきかというところすら間違える可能性があるわけです。
今回の著書でも紹介していますが、この分析は誰か1人が行うというよりも、デザインに関わるメンバー全員が参加する「インタープリテーション・セッション」と呼ばれるワークショップにおいて、ユーザー調査の結果を個別のユーザーごとに、5つのワークモデルを使って図示しながら、行動が行われる状況・コンテキストを可視化していく作業になります。
ユーザー個別にワークモデル分析を通じて、その行動の状況・コンテキストを把握するかしないかで、行動や発話の要素を切り抜いてKJ法を行う際の分類の精度がまるで違ってきます。この過程を経るか経ないかでペルソナ／シナリオはまるで別物になってしまうといってもいいでしょう。
ペルソナ／シナリオ法も決して完成された道具じゃない
それほど、重要なワークモデル分析ですが、残念ながら、あんまりペルソナ／シナリオ法について紹介した書籍や記事などにはそのことに対する言及がないんですよね。それって人間の認知や行動をちょっと甘く見てるんじゃないかと感じます。
ほんとにワークモデル分析のないペルソナをつくるなら個別のユーザー調査データを最後まで重視するほうがマシだと思います。だって、そっちのほうが議論は混乱するかもしれませんが、間違ったユーザー理解をせずに済みますから。
とにかくユーザー調査をしてペルソナをつくればいいと考えるのは、あまりに安易すぎます。なぜ、ユーザー調査をするのか？ なぜ、それをペルソナ／シナリオという形で統合するのか？ 統合を行う際にはどこに注意すればよいのかをしっかり理解したうえで作業を行わなければ、せっかくのデザインの手法も単に間違った使い方で誤った成果を生み出すだけのものになってしまいます。それではあんまりですよね。
まぁ、いうなれば、ペルソナ／シナリオ法ってのも決して完成された道具じゃないってことです。不完全で使う人それぞれが工夫して使わないとやっかいなことにもなる道具だってことです。だいたい、道具ってのは一般的にそういうものですけどね。
やっぱり道具を使うならそれがどんな道具なのか、道具を使って行う作業の対象がどんなものかを理解しないとだめですよね。それが職人ですよね。
関連エントリー
- 業務システムのユーザビリティ
- ユーザー行動を構造的に分析するための5つのワークモデル
- ISO13407：人間中心設計
- 人間中心設計（Human Centered Design＝HCD）で使う主な手法
- 『ペルソナ作って、それからどうするの？ ユーザー中心デザインで作るWebサイト』：amazonにて予約開始
この記事へのコメント