誰のためのデザイン？
ユーザは何らかの仕事を処理するために製品を使用します。裏を返せば、誰が何のためにその製品を使用するのかを事前に定義しなければ、正しい設計はできないということです。ところが、想定ユーザを尋ねられると、しばらく戸惑いを見せた後に「すべてのお客様」と真顔で返答するプロジェクトマネージャや開発チームは少なくありません。
残念ながら、すべてのユーザのニーズを満たそうとすれば、結局、誰のニーズも満たさない製品――例えれば「コンバーチブルのバンでオフロード仕様のクルマ」のような――が出来上がってしまうでしょう。
では、想定ユーザを決めれば事足りるのでしょうか。例えば、「流行に敏感で、自分らしく、生活をより楽しくしたいと望むアクティブなユーザ」ならばどうでしょうか？
この定義では開発チームメンバーが、それぞれ自分勝手なユーザ像を思い描くことが出来てしまいます。その結果、開発者は自分のアイデアを正当化するために"ユーザ"を振りかざし始めます。「ユーザは○○を好むはずだ」「いや、△△のほうがユーザには重要だ」「○○なんてユーザには邪魔じゃないのか」…それはまさしく"宗教論争"――決して終わることのない議論に陥るのです。
このような曖昧なユーザ定義を『ゴムのユーザ』といいます。開発者の都合に合わせてくれる伸縮自在の便利なユーザという"皮肉"な意味を含んでいます。もちろん、そんなユーザを定義しても何の役にも立たないのですが...
一人のユーザのために
成功の秘訣は、実はとても単純です。「すべてのユーザではなく、一人のユーザのために製品を設計する」のです。それも"具体的"な一人のユーザのために――それが『ペルソナ』です。
ペルソナとは設計を支援するために定義する仮想のユーザ像のことです。名前や顔写真も用意して、実在の人物であるかのように描きます。アラン・クーパーが著書の中で紹介して以来、徐々にその価値が認められ、現在ではウェブサイト開発からマーケティングまで幅広く用いられるようになっています。
通常、１つの製品に対して複数のペルソナを定義します。ユーザは多様だからです。ただし、それらのペルソナには必ず順位をつけます。優先順位１位をプライマリーペルソナ、２位以下をセカンダリーペルソナと呼びます。
そして、プライマリーペルソナの要求を"完全"に満たすように製品を設計します。議論する際には必ず「それは誰の（どのペルソナの）要求なのか」を明らかにします。多様なユーザニーズに場当たり的に対応しようとしても、相反する要求が出されると行き詰まってしまいますが、ペルソナを使えばユーザの要求に優先度を付けられるので、開発チームは意志決定を正しく迅速に行えるようになります。
十人三色
ペルソナは"仮想"であって、決して"架空"ではありません。仮想とは事実に基づいて仮に想定すること（ただし事実そのものではない）ですが、架空とは事実に基づかず想像だけで作ることです。ここでいう"事実"とはユーザの体験のことです。つまり、ペルソナとは開発者がユーザに弟子入りして把握した具体的なデータに基づいて作るものなのです。
しかし、ユーザの体験は多種多様です。そんな雑多なデータからどうやってペルソナを作るのかと疑問に思うかもしれません。
確かに、異なるユーザが全く同じ体験することはありません。細部を比べれば個々のユーザの体験は全て異なります。しかし、体験全体を俯瞰すれば、赤の他人であるユーザの間に不思議なことにいくつかの共通点が見えてくるのです。
同じ"仕事"についてユーザ１０人に話を聞けば、おおよそ３～４種類のパターンが浮かび上がるはずです。そして、もし１００人に話を聞いたとしても７±２パターンくらいに収束することが経験上分かっています。このパターン（これを「ユーザ行動モデル」といいます）を"骨格"として、そこに"肉付け"を重ねてペルソナは構築されます。
なんちゃってペルソナの悪戯
データに基づかず、開発者の知識や経験だけに基づいて"架空"のペルソナを作ることは可能です。そのようなペルソナは『臨時ペルソナ』と呼ばれています。ただし、一般的に言えば臨時ペルソナは使うべきではありません。
ペルソナは開発プロセスの中で要求開発の基盤になったり、要求の妥当性を検証するという重要な役割を果たします。例えば、アジャイル開発ではペルソナを利用してユーザストーリーを導き、その優先順位を決めます。もし、このような重大な意志決定を"架空"の情報に基づいて行うとすれば、そのリスクがどれくらい大きいかは言うまでもないでしょう。
「ペルソナはでっち上げるものではない。調査で発見するものである」――ペルソナの"父"であるアラン・クーパーが明言しています。ペルソナを利用するのならば、この大原則だけはお忘れなく！
