ペルソナとユーザーストーリーは、プロダクトやサービスを「誰のために、どんな体験として作るのか」を要件定義の前にそろえるための道具です。ペルソナは典型的な利用者像を具体化し、ユーザーストーリーはその利用者が何をしたいのか、なぜ必要なのかを短い文章で表します。
ただし、年齢や職業を細かく書くだけのペルソナや、「私はユーザーとして機能がほしい」といった曖昧なユーザーストーリーでは、開発範囲の判断には使いにくくなります。大切なのは、調査や現場の声をもとに利用者の状況を整理し、初回開発に残す機能、後回しにする機能、検証すべき仮説へつなげることです。
この記事では、ペルソナとユーザーストーリーの違い、作り方、要件定義や外注前準備へ落とし込む手順を、初めてサービス開発を進める担当者向けに整理します。
この記事のポイント
- ペルソナは属性表ではなく利用者の状況・課題・判断基準をそろえる道具
- ユーザーストーリーは機能名ではなく誰が何をなぜ行うかを表す要件の入口
- 作成時は調査根拠、利用シーン、受け入れ基準、優先順位をセットで残す
- 外注前はペルソナ設計とユーザーストーリーを資料化して見積もり前提をそろえる
ペルソナ設計・ユーザーストーリー作成のワークシートに空欄を作っておくと、社内レビューや開発会社との初回相談で、何が決まっていて何が未確定なのかを説明しやすくなります。
目次
ペルソナとユーザーストーリーの役割
ターゲットとの違い
ペルソナは、ターゲットユーザーを細かくしただけのものではありません。ターゲットは「中小企業の管理部門」「20代の新規アプリ利用者」のように、属性や市場規模を把握するための集団です。ペルソナは、その集団の中から代表的な一人を置き、仕事の状況、行動パターン、困っている場面、意思決定の理由まで具体化したものです。
たとえば業務システムを作る場合、「営業担当者向け」と書くだけでは、外出先でスマートフォンから入力したい人なのか、月末にまとめて申請する人なのか、承認者に差し戻されることが多い人なのかが分かりません。ペルソナを置くと、画面で優先すべき入力項目、通知のタイミング、後回しにしてよい機能を判断しやすくなります。
一方で、名前、年齢、趣味、家族構成を埋めても、開発判断に使えない情報ばかりなら意味がありません。要件定義に使うペルソナでは、属性よりも「どの業務で、何を達成したくて、何に詰まっているか」を優先します。
| 項目 | ターゲット | ペルソナ |
|---|---|---|
| 粒度 | 属性で区切った集団 | 状況まで描いた一人の利用者像 |
| 主な用途 | 市場や配信先の把握 | 体験設計と要件判断 |
| 見る情報 | 業種、年代、役職、規模 | 行動、課題、目的、制約、判断基準 |
| 開発への効き方 | 対象範囲を決める | 機能の優先順位を決める |
思い込みで作らない
ペルソナ設計で最も避けたいのは、社内の都合に合わせて「こういう人がいるはず」と作ってしまうことです。検索上位の記事でも、ペルソナは調査データやインタビューをもとに作るべきだという点が共通しています。現場でよく見る失敗は、営業資料や企画書に都合のよいユーザー像を作り、そのまま機能要件へ流してしまうケースです。
調査といっても、最初から大がかりなリサーチをする必要はありません。既存顧客へのヒアリング、問い合わせ履歴、利用ログ、営業メモ、サポートの記録、現場担当者へのインタビューなど、すでにある情報から仮説を置けます。重要なのは、ペルソナが仮説なのか、実際の声で裏付けられているのかを分けて書くことです。
新規事業やMVPの段階では、仮説ペルソナから始めても構いません。ただし、仮説のまま完成版の要件にしないことが大切です。初回リリース後の問い合わせ、利用行動、離脱理由を見て、ペルソナとユーザーストーリーを更新する前提を置きましょう。初期検証の考え方は、MVP開発の進め方とも相性があります。
ユーザーストーリーは要件の入口
ユーザーストーリーは、ユーザー視点で要件を表す短い文章です。基本形は「私は〇〇として、△△したい。なぜなら□□だから」です。英語圏では「As a user, I want to... so that...」の形で説明されることが多いですが、日本語で書くときも役割、行動、理由を分ける考え方は同じです。
悪い例は「利用者として、検索機能がほしい」です。これは機能名しか分からず、何を探したいのか、どんな場面で必要なのか、できたら何が変わるのかが曖昧です。要件に使える形にするなら、「営業担当者として、訪問前に顧客の直近問い合わせを確認したい。なぜなら、前回の不満や未対応事項を踏まえて提案したいから」のように、利用場面と価値まで書きます。
ユーザーストーリーは詳細仕様書ではありません。むしろ、開発会社やデザイナーと対話するための入口です。そこから画面、データ、権限、通知、例外処理、受け入れ基準へ展開していくことで、要件定義書の作り方に必要な材料がそろいます。
開発範囲への接続
ペルソナとユーザーストーリーを作る目的は、きれいな資料を作ることではありません。初回開発で何を作り、何を後回しにするかを決めるために使います。ペルソナが「管理画面で毎日承認状況を確認する責任者」なのか、「月に数回だけ申請する現場担当者」なのかで、必要な一覧、通知、検索、権限、入力補助の優先順位は変わります。
ユーザーストーリーを並べたら、すべてを同じ重さで扱わないことが重要です。ユーザー価値が高く、初回検証に必要で、代替手段がないものは先に作ります。価値はあるが手動運用で一時的に代替できるもの、利用頻度が低いもの、将来フェーズでよいものは後回しにします。
| 分類 | 判断基準 | 例 |
|---|---|---|
| 初回に作る | 主要ペルソナの価値判断に直結する | 登録、検索、申請、承認、結果確認 |
| 後で作る | 便利だが初回検証には必須でない | 詳細レポート、細かな通知設定、CSV出力 |
| 手動で代替する | 頻度が低く初回は運用で吸収できる | 個別リマインド、例外的なデータ修正 |
| 検証が必要 | 価値もコストも高く不確実性が残る | 外部連携、AI判定、複雑な権限管理 |
この分類を発注前に作っておくと、見積もりの前提がそろいやすくなります。開発会社に「このユーザーストーリーは初回で検証したい」「これは次フェーズでよい」と伝えられるため、提案範囲の比較もしやすくなります。
ペルソナとユーザーストーリーの作り方
ペルソナ設計の項目
ペルソナ設計では、まず利用者の役割と利用場面を決めます。サービス開発なら「初回利用者」「継続利用者」「管理者」「承認者」のように、プロダクトとの関わり方で分けると使いやすくなります。BtoBの業務システムなら、部門、権限、利用頻度、業務上の責任、ITリテラシー、現行業務の制約を入れると、要件へ落とし込みやすくなります。
項目を増やしすぎると、見た目は詳しいのに判断に使えないペルソナになります。要件定義で使うなら、プロフィールよりも、目的、困りごと、利用シーン、成功条件、失敗時の影響、代替手段、意思決定の基準を優先しましょう。たとえば「45歳の部長」より、「承認遅れが月末処理に影響するため、未承認の申請をすぐ把握したい」の方が、機能設計には効きます。
ペルソナ設計で残す項目
- 役割と利用頻度
- 達成したい目的と業務上の責任
- 現在の困りごとと代替手段
- 意思決定の基準と成功条件
- 開発で配慮すべき制約
複数のペルソナを作る場合は、最初から多く作りすぎない方が扱いやすいです。まず主要ペルソナを一人置き、必要に応じて管理者や承認者などの補助ペルソナを足します。すべての人に最適化しようとすると、初回開発の範囲が膨らみます。
ストーリーを一文にする
ペルソナが決まったら、ユーザーストーリーを一文で書きます。書き出しでは、機能名よりも利用者の行動を優先します。「通知機能がほしい」ではなく、「承認者として、未処理の申請に気づきたい。なぜなら、締め日に処理漏れを起こしたくないから」と書くと、通知の目的が分かります。
この段階では、完璧な文章を目指す必要はありません。むしろ、関係者が違和感を出せるくらいの粒度で書き、会話の中で修正していく方が実務では進めやすいです。営業、運用、開発、デザインのメンバーが同じストーリーを見ながら、「この人は本当に毎日使うのか」「この理由なら通知より一覧の方がよいのではないか」と話せる状態を作ります。
ユーザーストーリーを作るときは、ユーザーの言葉に近づけます。社内用語や開発用語だけで書くと、利用者の価値が見えにくくなります。たとえば「ステータス管理をしたい」ではなく、「依頼がいま誰の確認待ちなのかを知りたい」と書くと、画面や通知の要件に展開しやすくなります。
| 悪い書き方 | 使いやすい書き方 | 理由 |
|---|---|---|
| 検索機能がほしい | 営業担当者として、訪問前に過去の問い合わせを確認したい | 利用場面と目的が分かる |
| 通知を出したい | 承認者として、未処理の申請に気づきたい | 通知の条件を議論できる |
| 管理画面が必要 | 運用担当として、登録内容の誤りを自分で修正したい | 権限と操作範囲を決められる |
受け入れ基準まで決める
ユーザーストーリーは、受け入れ基準とセットにすると要件定義へつながります。受け入れ基準とは、そのストーリーが満たされたと判断する条件です。「訪問前に過去の問い合わせを確認したい」なら、顧客名で検索できる、直近の問い合わせが新しい順に表示される、未対応の問い合わせが分かる、権限のない顧客情報は見えない、といった条件が候補になります。
受け入れ基準がないと、実装後に「思っていた検索と違う」「通知は来るがタイミングが合わない」という認識違いが起きやすくなります。発注者側は細かな実装方法をすべて決める必要はありませんが、利用者がどの状態なら目的を達成できるのかは言語化しておくべきです。
画面や操作のイメージが文章だけで伝わりにくい場合は、ユーザーストーリーから画面ラフやクリックできる試作品へ展開します。主要な導線を見ながら確認したい場合は、プロトタイプの作り方を先に押さえると、要件定義前の認識合わせがしやすくなります。
受け入れ基準の確認項目
- 誰が操作しても同じ結果を確認できるか
- 正常時だけでなく例外時の動きが分かるか
- 権限や表示条件が利用者ごとに分かれているか
- 完了したと判断する状態を説明できるか
優先順位と更新ルール
ペルソナとユーザーストーリーは、作った時点で固定する資料ではありません。新規サービスや業務システムでは、社内レビュー、ユーザーテスト、初回リリース後の利用データによって前提が変わります。だからこそ、作成時に「いつ、誰が、何を見て更新するか」を決めておくと、古い資料が残り続けるのを防げます。
優先順位は、ユーザー価値、業務影響、実装コスト、検証の必要性で見ます。声の大きい関係者の要望だけで決めると、主要ペルソナにとって重要な行動が後回しになることがあります。ユーザーストーリーごとに、初回に作る理由、後回しにする理由、検証後に見直す条件を残しましょう。
更新ルールを決めるときは、作成者だけでなく、利用部門、承認者、運用担当、開発会社の誰がレビューするかも残しておきます。担当が曖昧なままだと、リリース後に得た学びが資料へ戻らず、次の追加開発で同じ前提確認を繰り返すことになります。
外注する場合は、ペルソナ設計、ユーザーストーリー、受け入れ基準、優先順位を一つの資料にまとめておくと、見積もり前提の説明がしやすくなります。開発会社も「何を作るか」だけでなく、「なぜその機能が必要か」を理解できるため、代替案や段階的な開発計画を提案しやすくなります。
