仮面のユーザー“ペルソナ”参上！

ユーザーをグループ分けしよう

前回説明したようにユーザーに弟子入りしてていねいに話を聞くという調査を根気強く繰り返していると、ある時点であなたは気づくだろう――「同じような話をしているユーザーが複数いる！」。もちろんまったく同じ話をするユーザーはいない。細部を比べれば個々のユーザーの体験談はすべて異なる。しかしユーザーの目的や行動パターンに注目すれば、赤の他人同士であるユーザーの間にいくつかの共通点が見えてくるのだ。

まずユーザーの情報を1人分ずつ1枚のカードに書き出してみよう。名前、性別、年齢、職業、行動の特徴、一番印象に残った言葉などなど。インタビューしたときのユーザーの雰囲気も思い出そう。そして、そのカードを並べ替えて似たようなユーザーをひとまとめにしよう。

ちょうどいい具合にグループ分けができたら、次はそれらのグループにタイトルを付けよう。たとえば、衣料品サイトのユーザーならば「流行先取り」と「流行追従」かもしれないし、男性誌のサイトならば「メタボ」「ちょいワル」「リーマン」などとなるかもしれない。

ところで、何人のユーザーを調査すればいいのか疑問に思っている人もいるだろう。当然ながら“3人”では共通点は見えてこないし、“30人”もインタビューしていては時間がかかりすぎる。私の経験では“10人”くらいインタビューすれば基本的なパターンが浮かび上がってくることが多い。まず10人調査してみて、それでは足りないと感じたら、さらに5人から10人を追加しよう。

ハイブリッド・ユーザーを作り出そう

グループ分けとタイトル付けが終わったら、改めてカードの情報を見直して、それぞれのグループをもっとも代表しているようなユーザーを探そう。あなたがインタビューしたなかでもっとも「流行先取り」的だったのは誰だろう？「ちょいワル」っぽかったのは？ （なお、このユーザーをベースユーザーと呼ぶ）

ベースユーザーを決めたら、そのユーザーの話を詳しく思い出して1つのストーリーとして書き出してみよう。さらに、同じグループ内の他のユーザーの話から役に立ちそうな情報を引用して、ベースユーザーのストーリーに書き加えよう。このときに、情報をカードに書き出しながら作業してもよい。大きめのポストイットに書いて、ホワイトボードや壁に貼りだして、似たような話をまとめていくのだ。

こうすることで、ベースユーザーは同じグループの他のユーザーの要素も併せ持ったハイブリッドなスーパーユーザーに変身するのだ。

図1　ハイブリッド・ユーザーの作成手順

“ペルソナ”誕生

これで調査データからあらたなユーザーを作り出したことになるが、まだ元のユーザーが持っていた個人情報はそのまま残っている。「ちょいワル」なユーザーの名前が意外と平凡な「田中太郎さん」ではインパクトに欠ける。また、プライバシー保護の観点からも名前や住所、生年月日などの重要な個人情報をそのまま使用することは避けるべきだ。そこで、そのユーザーにもっとも適した架空の個人情報を創作して与えるのだ。名前や職業だけでなく顔写真も用意しよう。

以上が「ペルソナ」の開発手順だ。「ペルソナ」とは設計チームの意志決定を促進するために設定する仮想のユーザー像だ。アラン・クーパーが著書のなかで“プロジェクト成功の鍵”として紹介して以来、少しずつその価値が認められ、現在ではWebサイト開発や製品開発で広く使われるようになっている。

ユーザビリティ人名図鑑（その3）

図3　アラン・クーパー

図2　『コンピュータは、むずかしすぎて使えない！ 』（翔泳社、著：アラン・クーパー、訳：山形浩生）

アラン・クーパー

ペルソナの父。Visual Basicの開発者としても有名であるが、著書『コンピュータは、むずかしすぎて使えない！ 』（翔泳社、著：アラン・クーパー、訳：山形浩生）のなかで、世界で初めてペルソナを使った設計手法を公開した。Cooper Consultingを設立して会長を務めている。

ペルソナの使い方

1つのプロジェクトでは3人から6人のペルソナを定義するのが標準的だ。ペルソナを作ったら必ず順位を付けよう。各ペルソナの市場規模の大きさ、競合との差別化、成長力などさまざまな要因を関係者で十分に検討して順位を付けるのだ。

優先順位1位のペルソナは特別なペルソナだ。これをプライマリーペルソナと呼ぶ（なお、2位以下のペルソナはセカンダリーペルソナと呼ぶ）。これ以降、設計チームはプライマリーペルソナのニーズを実現するために全力を傾けることになる。

ペルソナの原則は「みんなのためにデザインするのではなく、1人のためにデザインする」である。もし、プライマリーペルソナとセカンダリーペルソナの要求が相反する場合は、プライマリーペルソナの要求を優先する。こうすることによって、Webサイトの機能や構造が無秩序に拡大して混乱することを防げるのだ。

読者のなかには「1人のユーザーのためにデザインすると、1人のユーザーのニーズしか満たせないのでは？」と心配する人もいるかもしれないが、これは誤解だ。設計チームはセカンダリーペルソナを含んだ幅広いユーザーニーズの実現を目指すべきだ。あくまで要求が対立する場合に限り、プライマリーペルソナの要求を優先するだけなのだ。

ペルソナの落とし穴

ペルソナは決して架空のユーザーではない。架空とは「事実に基づかず想像で作る」ことだが、ペルソナは実際のユーザーのデータに基づいて開発するものだ。ユーザー調査をまったく行わず、設計チームの知識や経験だけに基づいてペルソナを作り上げても意味はない。

ユーザーのデータに基づいて開発するとしても、過去のマーケティングデータを引っ張り出してきて、いくつかに分類されたユーザーセグメントに名前と写真をくっつけただけでは、それはペルソナとは言えない。マーケティングのデータは製品やサービスを売るためのものだが、ペルソナの開発では利用に焦点を当てたデータが必要だからだ。

また、せっかく開発したペルソナが、実際の設計プロセスではあまり利用されず、過去のドキュメントの一部として書類棚で埃をかぶってしまうことは少なくない。多くの日本企業のなかでは「サユリ」や「ケイスケ」をミーティングで登場させづらい雰囲気がある。ましてやシリコンバレーのIT企業に倣ってペルソナのポスターやTシャツを作るという社内キャンペーンを実施すると完全に浮いてしまうだろう。

ペルソナは目的ではなく手段だ。アラン・クーパーは、設計チームの個々のメンバーが描く勝手なユーザー像に振り回されず、「1人のユーザーのため」に製品をデザインできるようにするツールとしてペルソナを考案した。決して、ペルソナを開発すればプロジェクトの成功が約束されるという訳ではない。「ペルソナを作って、それからどうするのか」という確かな戦略を持っていないと、宝の持ち腐れに終わるだろう。