BtoBサービスですぐに使えるペルソナテンプレート（解説付き）
こんにちは、rootのmasaです。
いきなりですが、皆さんはペルソナに何を書けばいいかわかりますか？
私は最近までちゃんとわかっていませんでした。わかっていなかったので、「ペルソナ テンプレート」「ペルソナ 作り方」でググったり、本に書いてある項目をそのまま使ったりしていました。でも、理解が浅いまま作っていたので、PdMの方から「この項目は本当に必要なの？」と聞かれても、説得力のある説明をできませんでした。「だって本に書いてあったから！」とは言えません。苦い思い出です。
そんな私ですが、2年半ほどプロダクト開発のためにペルソナやカスタマージャーニーマップを作ってきてわかったことがあります。それは、「すべてのペルソナに使える万能なテンプレートは存在しない」ということです。まずBtoB向けかBtoC向けかによって最適な項目は大きく変わりますし、サービスのドメイン領域によっても変わります。この点を理解しないまま、他のペルソナに書かれている項目をただ真似するだけだと、作っただけで活用されないままになってしまいます。もったいない。
ただ、「万能なテンプレートは存在しない」とは言ったものの、toB領域に限定すればある程度ペルソナに必要な項目の共通項はあると思っています。（ちなみにtoBに限定するのは、私がtoCよりtoB用のペルソナを作った経験の方が多いからです）
今回の記事では、普段私がtoBサービスのペルソナに使っている項目を理由とともに書いていきます。もちろん、この記事に書かれていることも絶対ではないので、あくまで参考として読んでください。
ペルソナの目的
まず、ペルソナの目的を整理しておきます。ペルソナの目的に関する言及は様々な本でされていますが、サービス設計においては、関係者間での「ユーザー視点」の共通理解を作ることがメインだと個人的には考えています。
「ユーザー視点でいうと〜」という発言が開発の中ではよく出てきますが、ユーザーイメージがそれぞれバラバラだと議論が噛み合わないので、意思決定の基準を作るということです。この辺も掘り下げていくとそれだけで記事がもう一本書けそうなので、一旦このぐらいにしておきましょう。
ペルソナ作成の前提
作成期間が短い、プロトペルソナ（リサーチを行う前の仮説的なペルソナ）としてクイックに作りたい等の状況を除き、基本的には一つのサービスに対して複数のペルソナを作るのが望ましいです。年齢や役職、立場などによってリテラシーや価値観、使い方が異なるためです。開発の優先順位も複数のペルソナを見比べながらつけていきます。
ちなみに、ABOUT FACE4という本では、Primary personasやSupplemental personasといった名前で複数ペルソナを作るときの分類方法を書いてくれています。分厚いし高いし英語ですが、名著なので興味ある方はぜひどうぞ。（日本語版出てくれないかな）
BtoBサービスで使うペルソナ項目
ユーザー属性
名前
ペルソナに人格を与え、みんなの共通認識とするために必要です。ちなみに、年齢を先に決めて、その生まれ年で多い名前から選ぶのが私の決め方です。ちなみに、名字を決める時は、インタビュー対象者に出身地を聞いておいて、その地域で多い苗字にします。
性別
toCほどではないですが、ジェンダーが利用状況に影響することもあります。決める時は対象サービス業界の男女比率を一応参考にしますが、インタビュー対象者の性別で決めてしまうことも多いです。ペルソナを複数作る場合は、ペルソナごとに性別を分けバランスをとります。
年齢
ITリテラシー、仕事のステージ、価値観などに影響を与える大事な要素です。「29歳」のように具体的な年齢まで決めてしまうことがほとんどです。複数作る場合はペルソナごとで年齢層を分けますが、一つしか作らない場合はコアユーザーの年齢をインタビュー結果を踏まえ絞ります。
業種・従業員規模
顧客のターゲットセグメントに直接的に関わってきます。この項目に関してはインタビューではなく、ビジネスサイドが設定しているメインターゲットをベースに設定することが多いです。具体的な企業をイメージしながら決めたりもします。
所属部署
ユーザーがどんな環境で働いているかについて示唆を与えてくれます。実際のデータを元にしながら、部署の人数まで記載できると理想的です。
職種
この項目の必要性は言うまでもないかなと思います。サービスのターゲットに合わせて決めます。
役職
toBでは権限管理の設計が往々にして途中から入ってくるので、役職なしや部長など、ペルソナのロールを決めておく必要があります。ペルソナの年齢やサービスのターゲットから決めます。当然、複数ペルソナが居る場合はそれぞれ分けます。
職場エリア
働き方のイメージに影響を及ぼします。
居住エリア
都心なのか地方なのか、職場からの距離はどのぐらいなのか等でその人の生活環境の解像度がグッと上がります。特にリモートワーク主体のイメージであれば、それを加味したプロダクト設計をする必要があります。
ITリテラシー
業務上で利用しているサービス
SlackやOffice365など、仕事で中心的に使っているサービスを定義しておくと、サービス連携を考える時の基準になります。
プライベートで利用しているサービス
普段使っているサービスがわかると、大体のリテラシーのイメージが付きやすいです。また、どのようなUIに慣れ親しんでいるかの目当てをつけることもできます。
仕事内容
具体的な業務内容
職種だけでは具体的に普段何をやっているかイメージしづらいので、普段行っている業務の種類を定常業務と非定常業務に分けて書くとよいです。
一日の仕事の流れ
普段どんな流れで仕事をしているかの解像度が上がると、「ユーザーはこんなタイミングでプロダクトを使いそうだな」というイメージがしやすくなります。
ユーザーゴール
全体ゴール
ここでは、ペルソナが担当業務領域の中で達成したいゴールを書きます。（ペルソナが追っているKPIや定性目標などのイメージ）ここを定義しておけると、プロダクトの既存ソリューションに囚われずユーザーにとって大事なことが議論できるようになります。
プロダクトドメインゴール
プロダクトが扱っている業務領域におけるゴールです。例えば、経費精算という経理にとって一部の業務領域に関するプロダクトの場合、「経費精算を最小限のコミュニケーション量で迅速かつ正確に終わらせたい」といった感じになります。ここで大事なのは、プロダクトドメインゴールが全体ゴールにどう貢献しているのかの関係性を明らかにしておくことです。
課題
全体ゴール、プロダクトドメインゴールに対して、ペルソナがどんな課題を抱えているかを書きます。書き出すときには、課題の粒度を揃える、ゴール達成に対する重要度で優先順位をつけるなどができると認識が揃いやすくなります。
感情
ここでは、業務の中でペルソナのモチベーションが上がる所と下がる所を定義するのをおすすめします。ペルソナが喜ぶ体験や避けたい体験の共通認識が得られると、UXを考える大きなヒントになるためです。
終わりに
BtoBのペルソナに使える項目を私なりに書いてみましたがいかがでしたでしょうか。いろいろ書いておいてなんですが、私の経験上ペルソナは作るより運用し続ける方が100倍難しいと思っています。ペルソナをチームの中で共通認識として運用していくにはどうしたらいいのか、そもそもペルソナを継続的に運用する必要があるのかなど、今後考えがまとまったら書いてみたいなぁと思います。
この記事が気に入ったらサポートをしてみませんか？