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