あなたは自分が他人と一緒だと思っていませんか。思考、意見、価値観、癖が他人と同じものであると。心理学では、実際よりも共通点が多いと思い込むことを「偽の合意効果」と呼びます。
偽の合意効果はソフトウェアをデザインする際に間違った決定をする原因になります。
Alan Cooper氏は、頭が良く、才能ある人が度々くだらないソフトウェアを作ってしまう原因を検証する中で、この効果に言及しました。彼はデザイナーの偏見を取り除き、ユーザーの深層心理を反映するべく、ペルソナベースドデザインという手法を生み出しました。1998年に著した名著「The Inmates are Running the Asylum.」の中でこの手法について記述しています。
チームメンバーのひとりが次のように言うのを聞いたことはないでしょうか。
「もし顧客が〇〇という機能を求めていたとしたらどうする？」
Cooper氏はこのような、稀なケースをすべて網羅するような、形やニーズが自由に変わる仮想のユーザーを「エラスティック（変幻自在の）ユーザー」と呼びました。良い決断はエラスティックユーザーからは生まれません。
ホテルで使われるソフトウェアを想像してください。会計係、フロントデスク、ギフトショップの店員向けのソフトです。会計係は集中して数字を追いかけます。フロントデスクは素早くタスクを切り替える必要があり、ゲストが現れた際にはフレンドリーで役立つ対応を求められます。ショップ店員はコンピューターを全く使わないかもしれません。ペルソナはこのような異なるユーザーの細かな違いやニーズを理解し、それぞれに合ったソフトウェアを開発するのに役立ちます。
ペルソナとは何か、なぜ必要なのか？
ペルソナとは典型的なユーザー像を反映した１人の仮想の人間です。開発・デザイン・プロダクトマネージメントチームはペルソナを実在の人物のように感じなければいけません。ペルソナは名前、デモグラフィック、写真、仕事内容、希望、不安、目標などを設定することでより人間らしくなります。
組織によってはペルソナを個人として扱いますが、個人と混同してはいけません。どんなユーザーも想定せずにデザインをするよりはましですが、個人に焦点を当ててしまうとデザイナーはより広いユーザー層からのニーズを見落としてしまいます。１つのペルソナは広い層の特性を反映し、似通ったユーザー全体の象徴なのです。
ペルソナはマーケットセグメントでもありません。年齢「層」やその他１人の人間として持ち得ない特徴は持っていません。
ソフトウェア開発は時間と資金に限りがあります。パレートの法則（または80対20の法則）によると、あるプロセスにおける結果のおよそ80％は20％の原因から生じます。UXの世界で言うと、100％のユーザーを満足させることを目指すより、80％を対象にした機能を持つソフトウェアの方が喜ばれます。ペルソナは、80％の重要な事項と20％のほとんどのユーザーにとって不要な事項をあぶりだす助けになります。それは、ステークホルダーと話す際、ペルソナを実在するユーザーとして感情移入することで可能になるのです。ペルソナによって、顧客のニーズについての共通認識を作り出すことができます。
ペルソナの作り方
UXデザイナーは、どうやってペルソナをベースとしたデザイン手法を作成し、活用するのでしょうか？
１. メインとなるペルソナの特定
ペルソナが多すぎると関係者はその情報量にパンクしてしまいます。George A. Miller氏は、７±２が人間の処理できる情報の数であると突き止めました。そして、たとえエンタープライズソフトウェア開発であっても、この数字は適切なペルソナの数と言えます。ソフトウェアは通常多くの副次的ユーザーがいますが、ペルソナはメインユーザーに絞るべきです。
２. 事前調査
フィールドリサーチの前に、ペルソナの職業について調査しましょう。社内ステークホルダーにインタビューしましょう。求人を探し、業務内容、給与レンジ、募集条件を確認しましょう。どんな学歴が求められているのでしょうか？ 社内ステークホルダーや専門家にペルソナに関することを聞きましょう。調査対象の人間が書いているブログがないか見てみましょう。次のステップに進む前に、できる限りの情報を集めましょう。
３. フィールドリサーチ
実際に外に出て、ユーザーと話します。彼らが働く様子を見てみます。彼らが新人をトレーニングするように話してもらえないか頼んでみましょう。そうすることで、彼らの行動に対して自然な解説をしてくれるでしょう。
４. インタビュー
仕事で夜眠れなくなるほど考え込むことはあるか聞いてみます。仕事で一番つらいことは何でしょう？ 好きなことは？ 中長期目標は？ 組織においての自分たちの役割をどう考えているのでしょう？ パフォーマンスはどう評価されているのでしょうか？
５. 観察
職場環境を観察します。顔を伏せているでしょうか？ しょっちゅう話しかけられているでしょうか？ 雑音は大きいでしょうか？ 照明はどうでしょう？ 近くに誰かいるでしょうか？ 誰かと話しながら協力しているでしょうか、ひとりで仕事を進めているでしょうか？ ひとつの業務に集中しているのでしょうか、マルチタスクでしょうか？ 困ったら同僚に助けを求めるのでしょうか、ネットで調べるのでしょうか？
６. 備品を観察する
デスクやパソコンモニターにポストイットを貼っているでしょうか？ そこには何が書いてあるでしょうか？ バインダーにはさんだ情報に目を通しているでしょうか？ もしそうだとしたら、彼らの業務は現状のソフトウェアではサポートしきれていないということです。
７. パターンを見つける
別会社で同職種のユーザーを４人程度観察すると、パターンが見えてきます。
パターンが見えてきたら、ペルソナ作成に取りかかれます。
詳細設定されたペルソナを作るためには、細かな調整が必要です。詳細が甘いと、ペルソナは実在の人間には見えません。チームがその人物に関してよく理解していると感じられる程度の設定が必要なのです。「２匹の猫と３歳の娘がいる」という情報まではいらないかもしれませんが、「24歳の女性で、どこかの大学を中退しており、現在の会社で３年働いており、基本的なパソコンスキルを習得しており、長期的なキャリア目標は立てていない」などといった情報は必要かもしれません。
ペルソナのサンプル
ホテル業界のフロントに絞ってペルソナのサンプルを見てみましょう。まず、この仕事に就く人間の人物像を特定しましょう。ペルソナは以下のような調査結果から導き出されます。
- 属性：典型的には20歳～28歳の高卒の女性。
- 業務領域：ゲストを出迎え、チェックイン・チェックアウト業務や精算業務を行い、近所のレストランや観光地の情報を提供する。
- 付随する義務：ゲストに歓迎されていると感じてもらわなければいけない。
- 給与：時給制で、＄９～＄15の時給。
- ニーズ：ゲストを歓迎するため、アイコンタクトができなければいけない。
- 課題：現在のソフトウェアは文字が小さいため、スクリーン上の特定の文を探すのが難しい。また、スクリーンに注意を向けなければいけないため、ゲストに集中し、歓迎することが難しい。
- ゴール：主にアンケートによって評価されるため、ゲストとのやり取りを（たとえ問題が発生したり受付に長い列ができたとしても）極力気持ち良いものにすることが非常に重要。
- 中期目標：大学に戻ってビジネスの学位を取りたい。
- コメント：「私はホテルの顔で、ゲストの第一印象を素晴らしいものにすることが仕事です。最高のホスピタリティを提供します！」
巷にはペルソナのテンプレートがあふれており、ペルソナを作ったことのないデザイナーからしたらどのテンプレートを使えばいいのか、また、どの項目が重要なのかを見極めるのは難しいでしょう。ペルソナや業界によっても変わります。たとえば、医者のペルソナは修士を持っていることに言及する必要はないでしょう。しかし、業務領域やゴール、中長期目標、不安、課題などは重要な情報です。
チーム全体がペルソナを覚えやすくするために、いくつかコツがあります。「コメント」はペルソナに命を吹き込んだり、ユーザーの個人的なミッションステートメントとしての役割があります。また、お仕事の役職などにちなんだ名前を付けると覚えやすいかもしれません。
ペルソナを活用する
ペルソナは利用されてこそ活きます。最大限活かすために、チームはペルソナを知り、会議などでも言及しなければいけません。５～７個以上のペルソナがあると、それぞれの特色を把握するのが大変です。
実際の生活で１時間に７人の人と会ったら、名前やバックグラウンドを覚えるのが大変でしょう。また、部屋の中の生きている人間の方が、パソコンの中のドキュメントに特徴を羅列された人間より現実感があるし覚えやすいでしょう。その意味で、ペルソナに命を吹き込むのはただでも難しいですが、数が多いと不可能と言えるでしょう。
ペルソナは変えないようにしましょう。しかし、時にはカスタマー調査やアンケート結果からペルソナがうまく反映されていないと分かることもあるでしょう。ペルソナに変更を加えることには多大な認知的負荷がかかります。チームは特徴を覚えなおさなければいけないからです。もし今のペルソナの延長線（たとえば、昇進や転職のような）でまかなえないようであれば、変更を加えるためのキックオフミーティングの開催も考えましょう。
1990年代、Cooper氏はひとつのプロダクトにつきメインとなるペルソナをひとつ、１ページにまとめ掲示することを推奨しました。チームメンバーが出勤時に毎日参照できるからです。今日（こんにち）、メンバーが違うオフィスで働くチームが多数存在し、チームの思考プロセスにペルソナを刷り込むことが難しくなっています。
難しいですが、不可能ではありません。以下はその助けになるでしょう。
- チームにペルソナを紹介します。実施したリサーチやどのようにペルソナを組み上げたのかを時間を取って話します。写真を見せ、ペルソナのニーズ、希望、不安、性格、その他関係する事柄を話し合います。
- ペルソナを次のように要件ミーティングに活用します。「フロントデスクのFionaさんにはその機能は必要かな？ ゲストとの会話が減っちゃう気がするけど。」
- もしスクラムによるアジャイル開発をするのであれば、ユーザーのストーリーにペルソナを使いましょう。「私がフロントデスクのFionaさんだとしたら、音にうるさいお客様に静かな部屋を提供できるよう、どの部屋がエレベーターから遠いのか一目でわかるようにしたいと思います。」
- デザイン時には、ペルソナの業務で使われているシーンをイメージしましょう。照明を考慮したり、仕事中に起こり得ることをイメージしたりします。先ほどの例で言うと、ソフトウェアではなくゲストに集中しながらエレベーターから遠い部屋を探しているシーンを考慮するべきでしょう。
まとめると、ペルソナは開発側のニーズや目標ではなく、実際のユーザーの気持ちや思考に入り込むための助けとなります。開発者がユーザーの仕事に馴染みがない、エンタープライズソフトウェアの開発にはより役立ちます。ペルソナは使われてこそ活きます。チームが口に出すほどに、ペルソナは現実のユーザーに近付くのです。
