ユーザビリティの時代──ペルソナ／シナリオ法 理論編：ユーザビリティ研究会より（1）（2/3 ページ）

[生井俊，＠IT]

ペルソナは「神」のような存在

　ここから、ペルソナ／シナリオ法ということで進めていきます。

　「われわれの実例としてこういうペルソナを作り、そのペルソナが反対をしたのでこの機能がなくなりました」という具体的な話は、次回の研究会「実践編」のテーマとしたいと思います。今回は理論編ということで、ペルソナ／シナリオ法の理論に少しだけに触れます。

　ペルソナとは、いわば仮想ユーザーのことです。例えば「Windowsユーザー」と設定しても、あまりにもその幅が広過ぎます。そこで何歳ぐらいで、いままでどういうスキルセットを持ってきた人なのか、どういう経緯なのかを限定することで、求められているユーザビリティがはっきりしてきます。ペルソナにはそういった非常に細かなプロフィールを記述しています。

　このペルソナを使ったときに、「ペルソナが求めていることではなく上司がいったことが結局通ってしまう」とか、「決定権者が2人いるので、ペルソナがどうのこうのではなく、両方の顔を立てるために『50％ずつでいきましょう』というような、ペルソナと独立したところで決定が行われている」といった、実際の運用プロセスの面で問題があると指摘をいただきました。そういう方こそ、今日の研究会に来てよかったといえると思います。なぜなら、ペルソナはいわば「神」のような存在だからです。みんなが合意して、このペルソナのアプリケーションを作るといったなら、それが部長であろうが副社長であろうが社長であろうが、ペルソナには逆らえないのです。

　例えば、現場の人は絶対こんなボタンを付けない方がいいと思っているのに、部長が「このボタンがあった方がいいんじゃない」といってきたときに、私はこう思うといってしまうと立場的に角が立つようであれば、「私がいっているのではなく、ペルソナにとって使いにくいのです」というふうに持っていけます。このように、ペルソナという神を最初に設計してしまうことが、むしろ自由なアプリケーション構築、操作デザインのためにあるといっても過言ではありません。

ペルソナ活用の注意点

　ペルソナはいくらでも作ることができます。先ほどの休み時間に、「人によってペルソナが違う」と悩みをおっしゃった方がいました。これは非常に危険なケースです。

　例えば、僕とあるエンジニアがいたとします。僕にとってこのソフトはこのペルソナで作るべきだと思っているけれども、そのエンジニアのペルソナとが違っていたらペルソナがぶれてしまい、神になりません。僕のペルソナはこういっているといって、要するに自分を代弁させているだけの人形のようになってしまいます。ペルソナというのはいくらあってもいいということではありません。

　この文脈の中で出てくるのが「主要ペルソナ」という概念です。

コンピュータは、むずかしすぎて使えない！
アラン・クーパー著、山形浩生訳
翔泳社
2000年2月
ISBN4-88135-826-X
2200円＋税
※注文ページへ

　『コンピュータは、むずかしすぎて使えない！』という本で非常に強くいっているのが、ペルソナを複数設けては絶対駄目だということです。「たった1人のためにデザインするということを鉄則としなさい」とはっきりいい切っています。もしエンジニア同士、あるいはマネージャと現場の人とでけんかになったら、この主要ペルソナが話すのだからあなたが何をいっても駄目ですよといえるぐらいの神として存在できる、絶対者として主要ペルソナを設定します。

どのように操作を実現するかをまとめる「シナリオ」

　次に、シナリオも重要なポイントです。シナリオとは何かを簡単に整理します。

　ペルソナがどういうアプリケーションをどのような過程で学んでいって、どのように操作を実現していくかをまとめた日記のようなものです。例えば、私たちの会社では「神尾みか」という主要ペルソナを作りました。この神尾みかは私たちの会社のツールを最初に使ったときにインストーラから立ち上げます。

　第1日目のシナリオは、インストールCDをCDトレイに入れ、出てきた画面でダブルクリックする──そして設定項目がないのに［次へ］ボタンが出てきて悩むといったように、ユーザーがツールを体験したり学習したりする過程を事細かに記述しています。そのシナリオには何通りかあり、考えもつかないような使い方をするとか、毎日必ずする操作とか、あるいはインストールのように1回しかしない操作があります。それは同じ操作でもプライオリティが全然違うシナリオなわけです。そこでシナリオをまず3つに分類します。

　1つ目が日常シナリオです。基本的にはペルソナがその日常シナリオをどのようにこなしていくのかをベースにしてデザインしていくものです。

　2つ目が必須利用シナリオです。日常シナリオと比べると頻度が低いのですが、このツールが世の中に出るには絶対になければいけない機能、いつも使う機能ではないけれども必要な機能のことを必須利用シナリオと呼びます。

　一番慎重に考えなければならないのは、3つ目のエッジケースシナリオについてです。これはあまり必要ではないし頻繁に使われるわけでもない機能のことです。なぜこういうことを言葉として定義するかというと、僕も含めたエンジニアが非常に陥りやすい理科系特有の弱点でもあるからです。可能性のパーセンテージは限りなく低くても追求し、理論的な完全さを求めるというのが、理科系の良いところでもあり悪いところでもあります。

　まずエッジケースシナリオについて議論する「エッジケース・オア・ノット」という分類があると、非常にムラのない議論ができます。エッジケースシナリオをコミュニケーションのツールとして組み入れていっていただくと、コミュニケーションが改善するケースがあります。