Orcha

Output

ペルソナ

ターゲットユーザーの代表的な人物像を定義したドキュメント。デモグラフィック、行動パターン、ゴール、ペインポイントを含む。

AI進化方向性

AIが行動データ・デモグラフィック・心理データからペルソナを自動生成。リアルタイムデータに基づく動的ペルソナが静的ペルソナを補完し、予測精度が向上

作成ツール

Notion / Figma / PDF

フォーマット明記

ペルソナドキュメントの標準フォーマット

ペルソナは「実在の人物ではないが、ユーザーリサーチに基づいて構築された架空の原型(アーキタイプ)」である(Alan Cooper, 1999)。

必須要素(Core Elements)

構成要素説明目的
名前架空だがリアリティのあるフルネーム記憶性の向上、チーム内の共通言語
写真/イラスト背景に文脈を含むリアルな画像共感の促進、ペルソナの人格化
タグラインペルソナの核心を表す一文迅速な特徴把握
デモグラフィック情報年齢、性別、職業、居住地、学歴基本的な文脈の提供
ゴール(目標)機能的・感情的・人生的ゴール設計判断の最重要指針(Cooper方式の中核)
ペインポイント現在の障壁、フラストレーション解決すべき問題の明確化
行動パターン利用頻度、デバイス、文脈利用シナリオの設計

推奨要素(Recommended Elements)

構成要素説明
引用文(Quote)ペルソナの態度を象徴する一人称の発言
シナリオ製品を利用する具体的な状況の記述
スキル・経験レベルテクノロジーや当該分野での習熟度
利用コンテキスト自発的/業務上の利用、頻度、デバイス
態度・価値観仕事やテクノロジーに対する姿勢

B2B特有の追加要素

構成要素説明
ファーモグラフィック情報会社規模、業種、売上、組織構造
購買における役割ユーザー/推薦者/意思決定者/予算承認者
KPI/成果指標その人物が評価される指標
テクノグラフィック情報使用ツール、技術スタック、IT成熟度

ペルソナの3タイプ(NN/g分類)

タイプデータソースコスト推奨場面
リーン(Proto)チームの仮説初期段階、スタートアップ
定性5〜30人のインタビュー大半の組織(最も推奨)
統計調査+統計分析大規模組織

構成要素の取捨選択の原則

「各情報は、それが含まれている目的を持つべきである。最終的な設計に影響を与えないか、意思決定を容易にしないなら、省略せよ。」 — Aurora Harley, Nielsen Norman Group

サンプル

サンプル: B2Bソフトウェア製品のペルソナ

ペルソナ: 佐藤 真紀(さとう まき)

タグライン: 「チームの生産性を数字で証明したい、データ駆動型の開発マネージャー」


基本情報

項目内容
年齢36歳
性別女性
居住地東京都品川区
最終学歴早稲田大学 理工学部 情報学科 卒業
現職株式会社テクノブリッジ(従業員280名、BtoB向けSaaS企業)
役職開発部 マネージャー(8名のエンジニアチームを統括)
勤続年数現職4年目(前職はSIerで6年)

引用文(Voice of the Persona)

「スプリントレビューのたびに、"今回も予定通り進みました" だけじゃ経営陣は納得しない。ベロシティの推移とか、ブロッカーの発生パターンとか、もっと定量的に見せたいんです。でも今のツールだと、そのデータを集めるだけで毎週2時間以上かかるんですよね。」


ゴール(目標)

機能的ゴール:

  • チームの作業進捗をリアルタイムで可視化し、ボトルネックを早期発見する
  • スプリント計画の精度を向上させ、納期遵守率を80%から95%以上に引き上げる
  • 経営層への報告レポートを自動生成し、報告準備時間を週2時間から15分に短縮する

感情的ゴール:

  • チームメンバーから「このマネージャーのもとなら成長できる」と思われたい
  • 数字に基づいた冷静な判断ができる自分でありたい

人生的ゴール:

  • 2年以内に開発部門の部長に昇進する
  • 仕事と家庭(5歳の娘)のバランスを保つ

ペインポイント(課題・不満)

  1. ツールの分散: Jira、Slack、Confluence、Googleスプレッドシートに情報が散在しており、全体像の把握に時間がかかる
  2. 手動のレポート作成: 経営層向けの週次レポートを毎回手作業で作成。データ集約だけで2時間以上
  3. 見積もりの不正確さ: チームのベロシティが安定せず、リリース日のコミットが困難
  4. メンバーの状況が見えにくい: リモートワーク中心のため、誰が何に詰まっているかの把握が遅れる
  5. ツール導入の社内承認: 新ツールの導入にはIT部門とセキュリティ部門の承認が必要。過去に3ヶ月以上かかった経験あり

行動パターン

一日の流れ:

  • 08:30 — 出社(週3日オフィス、週2日リモート)。Slackの未読確認、Jiraのボード確認
  • 09:00 — デイリースタンドアップ(15分、Zoom)
  • 09:30〜12:00 — 個別のタスク確認、PRレビュー、1on1(週2回)
  • 13:00〜15:00 — 社内ミーティング(プロダクトオーナーとの優先順位調整、他部署連携)
  • 15:00〜17:00 — 自身のタスク(レポート作成、中長期計画策定)
  • 17:30 — 退社(保育園のお迎え)

情報収集行動:

  • 新しいツールはまずGoogle検索とQiitaで日本語のレビュー記事を探す
  • 同規模の企業事例を重視する(「うちと同じくらいの規模で使ってるか?」が判断基準)
  • 無料トライアルがあれば自分で試し、その後チームに1週間使わせて反応を見る

テクノロジープロフィール:

  • 技術的素養: 高い(元エンジニア、コードレビューも行う)
  • 現在のツールスタック: Jira, Confluence, Slack, GitHub, Google Workspace, Figma
  • デバイス: MacBook Pro(業務用)、iPhone 15(モバイル確認用)

購買における役割

役割詳細
購買ポジション推薦者(Champion) — 自ら製品を評価し、上長に推薦する
意思決定者開発部 部長(最終承認)およびIT部門(セキュリティ承認)
予算権限月額5万円以下は自身で承認可。それ以上は部長決裁
評価基準1. 既存ツールとの連携容易性 2. データ可視化の質 3. 導入・学習コストの低さ 4. 日本語対応

このペルソナが製品に「雇う」ジョブ(JTBD統合)

ジョブステートメント: チームの開発パフォーマンスを可視化・分析して、データに基づいた改善提案と経営報告を、最小限の手間で行えるようになりたい。

ジョブの種類内容
機能的ジョブ複数ツールのデータを統合し、レポートを自動生成する
感情的ジョブ「チームをちゃんとマネジメントできている」という自信を持つ
社会的ジョブ経営層から「開発組織の状況を定量的に把握している人」として信頼される

設計へのインプリケーション

  1. Jira / GitHub連携は必須機能: 既存のワークフローを壊さず、データを吸い上げる形であること
  2. ダッシュボードの自動更新: 手動でのデータ集約は最大の離脱理由になる
  3. レポートのエクスポート機能: 経営層向けにPDFまたはスライド形式での出力が必要
  4. 日本語UI: 英語UIだとチームメンバーの定着率が下がる
  5. 段階的なオンボーディング: まず自分が試し、次にチームに展開する流れを想定した設計

参考文献・出典

参考文献・出典

書籍

  • Cooper, A. (1999). The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Sams Publishing.(邦訳『コンピュータは、むずかしすぎて使えない!』翔泳社)
  • Cooper, A., Reimann, R., Cronin, D., & Noessel, C. (2014). About Face: The Essentials of Interaction Design, 4th Edition. Wiley.
  • Pruitt, J. & Adlin, T. (2006). The Persona Lifecycle: Keeping People in Mind Throughout Product Design. Morgan Kaufmann.
  • IDEO.org (2015). The Field Guide to Human-Centered Design. IDEO.org.

Web記事・リソース