ペルソナとユーザーストーリーの作り方
はじめに
ユーザーインタビューを終えたら、次に何をすればいいのか。多くの初心者がここで立ち止まる。
ノートにはユーザーの発言が記録されている。だが、そのままでは設計判断に繋がらない。必要なのは、断片的な情報を整理し、設計チームが共通認識として使える形に変換することだ。
ペルソナとユーザーストーリーは、この変換のためのツールである。別々に作るドキュメントではなく、インタビューから設計へ繋ぐ連続した流れとして捉えるべきだ。
この記事では、インタビュー結果からペルソナを導出し、ペルソナからユーザーストーリーを書くまでの流れを解説する。定義を説明するだけでなく、実務で陥りやすい崩れを避けながら、設計判断に使える形へ落とし込む方法を示す。
2. ペルソナとは
ペルソナは、架空の人物像だが、作り物ではない。実在のユーザーの行動パターンを集約した「代表像」である。
インタビューとペルソナの違い
インタビューでは、個別のユーザーの詳細な文脈が見える。Aさんは時間に余裕があり、Bさんは急いでいる。だが、設計する際に「Aさんのためにこうしよう」では通じない。チーム内で共通の参照点が必要だ。
ペルソナは、その参照点となる。複数のインタビュー対象から共通する行動パターンを抽出し、1人の「人物」としてまとめることで、設計判断の際に「この人のためにどうすべきか」という議論が可能になる。
ペルソナが設計に役立つ理由
ペルソナがあると、議論の軸が変わる。「若いユーザーは」という曖昧な話ではなく、「タローは子供がいて、通勤中に片手で操作する必要がある」という具体的な文脈で判断できる。この人物像は複数のインタビューから見えた共通パターンから作られており、この名前は単なる便宜ではなく、人物として記憶しやすくし、設計判断の際に「この人の文脈」を再現しやすくするためだ。
この具体性が重要だ。機能を追加する際も、「タローにとって本当に必要か」という問いに置き換えられる。結果として、不要な機能を減らし、本当に必要な体験に集中できる。
崩れやすいポイント
ペルソナは便利なツールだが、実務でよく崩れる。理由は「作りたい像」と「見つかったパターン」の緊張関係を見失いやすいことだ。
初心者が陥りやすいのは、「理想のユーザー」を作ってしまうことだ。プロダクトを使ってくれそうな人物を想像で描き、実在のユーザーの行動から逸脱することがある。
ペルソナは「作りたい像」ではなく「見つかったパターン」である。インタビュー結果から無理やり導出したものでなければ、設計判断の基盤として機能しない。逸脱していないかは、実ユーザーの発言と定期的に照らし合わせることで確認できる。
3. ユーザーストーリーとは
ペルソナができたら、次はそれを設計判断に繋げるためにユーザーストーリーを書く。ユーザーストーリーは、機能の要件を「誰が」「何のために」「何をしたいか」という形で表現したものだ。開発チームと設計チームの共通言語として機能する。
ユーザーストーリーの基本形
一般的な形式は「〜として、〜したい、なぜなら〜」である。
まず状況をイメージしてほしい。朝の慌ただしい時間、子供が隣で起きてきて、ながら操作でタスクを確認したい場面を思い浮かべてほしい。
「在宅勤務者として、短時間でタスクを確認したい、なぜなら子供の世話と両立させる時間が限られているから」
この形式の価値は、機能そのものではなく「文脈」を含めて記述できる点だ。「タスク確認機能が必要」という要件リストと比べ、なぜその機能が重要かが含まれている。
ユーザーストーリーが設計に役立つ理由
ユーザーストーリーがあると、「これを作ればいい」という議論から、「この人の課題を解決するにはどうすべきか」という議論に移行できる。
同じ「タスク確認機能」でも、文脈が違えば設計が変わる。子供と両立させる場合と、オフィスで集中して使う場合では、UIの優先順位が異なる。ユーザーストーリーは、その文脈を設計判断に引き継ぐ役割を持つ。
崩れやすいポイント
ユーザーストーリーも実務でよく崩れる。理由は「ユーザーの文脈」と「開発側の都合」の区別がつきにくいことだ。
初心者が陥りやすいのは、形式にこだわりすぎて本質を見失うことだ。「〜として、〜したい」の形は満たしているが、実際には「機能を作りたい」という開発側の都合を言い換えただけになっているケースがある。
ユーザーストーリーの核心は「ユーザーの文脈」である。形式は手段であって目的ではない。ペルソナの課題やゴールから自然に導出される内容でなければ、設計判断の材料として機能しない。迷ったときは、書いたストーリーをペルソナに読み返してもらうことを想像し、違和感がないか確認する。
4. ペルソナとユーザーストーリーの違い
ペルソナとユーザーストーリーは、どちらもユーザーを中心に据えた設計ツールだが、役割が異なる。混同すると、設計判断の流れが曖昧になりやすい。
目的の違い
ペルソナは「誰のために作るか」を定める。ユーザーストーリーは「その人のために何を作るか」を定める。
ペルソナが「タロー」のような人物像を提示すれば、チームは「この人の文脈で判断しよう」と共通認識を持てる。だが、それだけでは何を作るかは決まらない。ユーザーストーリーが「タローが短時間でタスクを確認したい」という具体的な欲求を言語化することで、設計に進める。
粒度の違い
ペルソナは「人物」としての文脈を持つ。年齢や職業、生活状況、ゴールや課題など、複数の属性が複合的に絡む。
ユーザーストーリーは「状況」と「行動」に焦点を絞る。「〜として〜したい」という形で、特定の場面における欲求が抽出される。
この違いを理解すると、使い分けが明確になる。人物全体を見るときはペルソナ、特定の場面の欲求を整理するときはユーザーストーリー、という使い分けだ。
連続した流れとして捉える
実務では、ペルソナが先でユーザーストーリーが後、という順序で進む。だが、独立した作業ではなく、同じ文脈を持ち越す連続した流れだ。
「タロー」という人物像があってこそ、「短時間でタスク確認」というストーリーが意味を持つ。逆に、ストーリーがペルソナの文脈から逸脱していれば、設計判断の基盤が崩れる。
この連続性を意識することで、ペルソナとユーザーストーリーがそれぞれ独立したドキュメントではなく、設計判断を支える一本の流れとして機能する。
5. ペルソナの作り方
ここからは、インタビュー結果からペルソナを導出する具体的なステップを解説する。理想像ではなく、実在のパターンから作るという意識を持ちながら進める。
5-1 インタビュー結果の整理
まず、インタビュー記録を見返し、行動や文脈に関する発言を抽出する。価値観や感想ではなく、「いつ」「どこで」「何を」「なぜ」といった行動の記述に注目する。
分類の仕方は、時系列でもよいし、テーマ別でもよい。重要なのは、個人の発言がバラバラのままでは見えにくい共通点を、並べて見られるようにすることだ。
実務で崩れやすいのは、すぐに「こういう人物像がいそう」と結論に飛びつくことだ。整理の段階では、まだ仮説を持たず、事実を事実として並べることに集中する。
5-2 行動パターンの抽出
整理した発言から、複数のインタビュー対象に共通する行動パターンを探す。AさんもBさんも「通勤中にスマホで確認している」などと言っている。
パターンを見つける際のポイントは、頻度だけでなく文脈の共通性も見ることだ。単に「タスク管理を使う」ではなく、「時間が限られている場面でサクッと確認したい」という文脈が共通していれば、それは強いパターンとなる。
この段階で「理想のユーザー」に寄せようとすると、選択的に都合の良いパターンだけを拾ってしまう。すべてのインタビュー対象を平等に見渡し、本当に共通しているかを確認する。
5-3 ペルソナシートの作成
見つけたパターンを、1人の人物としてまとめる。名前、属性（年齢や職業など）、ゴール、課題、よく使うツール、よくいる場面などを記述する。
記述する際の心がけは、架空の小説のキャラクターを作るのではなく、「複数人の共通パターンを集約した代表像」として描くことだ。プロダクト都合で便利な属性を付け加えるのではなく、インタビューから見えた属性を素直に反映する。
ペルソナシートは、チーム内で参照する共通言語となる。だからこそ、実在のパターンから逸脱していないか、チーム内で相互に確認し合うことが重要だ。
5-4 優先順位の設定
ペルソナが複数見つかる場合、主要なペルソナを1〜2名に絞る。この選択基準は、プロダクトのゴールとの関連性や、影響を受けるユーザーの規模などを考慮する。
優先順位をつける理由は、リソースが有限だからだ。すべてのユーザーのニーズを同時に満たすことはできない。主要ペルソナの文脈で最適化し、そのあとで二次ペルソナの課題も検討する流れが現実的だ。
ただし、優先順位をつけたからといって、二次ペルソナを無視していいわけではない。主要ペルソナの設計が、二次ペルソナにとって致命的な課題を生んでいないか、最低限のチェックは必要だ。
6. ユーザーストーリーの作り方
ペルソナができたら、次はその人物像からユーザーストーリーを導出する。ここも理想ではなく、ペルソナの文脈から自然に導かれる流れを意識する。
6-1 ペルソナからニーズを抽出
まず、ペルソナの課題やゴールを見返し、そこから具体的な行動欲求を引き出す。「タローは時間がない」という課題があれば、「短時間でタスクを確認したい」という欲求が抽出できる。
ニーズを抽出する際のポイントは、「解決策」を混ぜないことだ。「通知機能がほしい」は解決策であってニーズではない。「気づかずにタスクを忘れるのが怖い」という課題から、「確実に気づける仕組みがほしい」というニーズを導く。
実務で崩れやすいのは、プロダクト側の都合で「この機能を入れたい」という想いが先に入ることだ。ペルソナの文脈から「本当にこれが必要なのか」を問い直す姿勢を持つ。
6-2 ユーザーストーリーの形式
導出したニーズを、「〜として、〜したい、なぜなら〜」の形で記述する。「在宅勤務者として、短時間でタスクを確認したい、なぜなら子供の世話と両立させる時間が限られているから」などと書く。
形式にこだわりすぎると、「〜として」が主語の代わりになってしまうことがある。「管理者として」はペルソナの文脈よりも役割を示しやすく、文脈が薄れてしまう。ペルソナの名前や属性を意識しながら、「この人物が〜したい」という感覚で書く。
ストーリーが長くなりすぎないよう、1つに絞った行動欲求を書く。複数の欲求を詰め込むと、設計判断が曖昧になる。分けた方が良い場合は、別々のストーリーにする。
6-3 受け入れ条件の設定
ユーザーストーリーの後に、「これが完成したと言える基準」を設ける。「タスクを確認」というストーリーに対し、「一覧表示されればOK」なのか、「各タスクの期限も見える必要がある」のかを明確にする。
受け入れ条件は、設計チームと開発チームの認識合わせとして機能する。「この程度で十分だ」と思っていたが、実は詳細まで必要だった、といった齟齬を防ぐ。
ただし、受け入れ条件を詰めすぎると設計の自由度が失われる。ユーザーにとって必要な結果を定義し、その実現方法までは規定しないバランスが重要だ。
6-4 優先順位の整理
書き出したユーザーストーリーを、実現する価値と実現コストのバランスで整理する。どちらか一方だけで判断せず、価値が高くコストも抑えられるもの、価値が高くコストも高いもの、などを整理して優先順位をつける。
価値を見極める際は、ペルソナとの関連性を確認する。「このストーリーはタローの課題を解決するのか」という問いが軸となる。ペルソナと乖離したストーリーは、価値が低いか、あるいは別のペルソナ向けかを見直す。
優先順位をつけた後も、ペルソナの文脈との整合性は継続的に確認する。実装を進める中で、ストーリーがペルソナの課題からずれていかないか、振り返りを設けるとよい。
7. まとめ
ペルソナとユーザーストーリーは、それぞれ独立したドキュメントではなく、インタビューから設計判断へ繋ぐ一本の流れだ。
インタビュー結果を整理し、共通する行動パターンからペルソナを作る。ペルソナの課題からニーズを抽出し、ユーザーストーリーとして言語化する。この流れの中で、実在のユーザーの文脈が設計判断に引き継がれる。
実務で崩れやすいのは、どの段階でも「理想像」や「プロダクト都合」に寄りすぎることだ。インタビュー結果に素直に立ち返り、ペルソナとストーリーが実ユーザーの文脈から逸脱していないかを確認し続けることが重要だ。
この流れを習得すれば、インタビューで得た断片的な情報が、チーム内で共通認識となる設計判断の材料へ変換できる。次のステップは、この記事で学んだ流れを、自社のプロダクトやサービスに応用してみることだ。まずは1つのペルソナと1つのユーザーストーリーを作り、チーム内で議論するとよい。