フレームワーク活用ガイドひとことで言うと#
新しい機能やプロジェクトの背景・目的・成功指標・スコープを1ページにまとめるドキュメント。開発に取りかかる前に「なぜ作るのか」「何をもって成功とするか」をチーム全員の共通認識にするための起点になる。
押さえておきたい用語#
- Product Brief（プロダクト ブリーフ）
- 新機能やプロジェクトの目的・背景・成功指標を1ページに集約したドキュメントのこと。日本語では「企画概要書」と呼ばれることもある。
- Success Metrics（サクセス メトリクス）
- 機能リリース後に「うまくいったかどうか」を判断する定量的な指標を指す。DAU、コンバージョン率、NPS変化量などが代表的。
- Scope（スコープ）
- 今回の開発でやること・やらないことの境界線。スコープが曖昧だと、開発途中で要件が膨らむ「スコープクリープ」が起きる。
- Stakeholder（ステークホルダー）
- プロダクトの意思決定に関わる利害関係者。経営層、営業、CS、法務など、開発チーム以外の関係者を含む広い概念である。
プロダクトブリーフの全体像#
こんな悩みに効く#
- 開発が始まってから「そもそも何のために作ってるんだっけ？」と迷子になる
- ステークホルダーごとに機能の期待値がバラバラで、リリース後に揉める
- 仕様書はあるけど「なぜこれを作るのか」が書かれていない
基本の使い方#
最初に「なぜ今、この機能が必要なのか」を整理する。感覚ではなくデータで裏付けるのがポイント。
- 課題: ユーザーが抱えている具体的な問題は何か
- 根拠データ: サポート問い合わせ件数、離脱率、NPS低下など
- タイミング: なぜ今やるべきなのか（市場の変化、競合動向、契約更新時期など）
「この機能が成功した状態」を数字で定義する。定性的な目標だけでは後から評価できない。
- ゴール: ユーザー体験がどう変わるかを1文で書く
- Primary Metric: 最も重要な指標を1つ決める（例: タスク完了率を60%→85%に）
- Secondary Metrics: 副次的に見る指標を2〜3つ（例: サポート問い合わせ数、NPS）
- 計測方法: どのツールで、いつ計測するかまで書く
やることだけでなく「やらないこと」を明記することで、スコープクリープを防ぐ。
- In Scope（やること）: Phase 1で必ず含める機能・体験を箇条書き
- Out of Scope（やらないこと）: 今回は見送る項目を明示する（将来の検討事項として記録）
- リスクと依存関係: 技術的な不確実性、他チームとの連携が必要な箇所を洗い出す
書いたブリーフをステークホルダーに共有し、認識のズレを早期に潰す。
- レビュー参加者: PM、エンジニアリードリード、デザイナー、事業責任者
- 確認ポイント: 目的に同意できるか、指標は妥当か、スコープに漏れはないか
- Go / No-Go: レビューを経て開発着手を正式に判断する
具体例#
背景: ユーザー行動データを分析したところ、月2回以上注文するリピーターの 72% が過去に注文した店舗を再度検索していた。検索から注文完了まで平均 4.2タップ かかっており、離脱率が 23% に達していた。
ゴール: 過去の注文履歴からワンタップで再注文できる機能を提供し、リピーターの注文体験を短縮する。
成功指標:
| 指標 | 現状 | 目標 |
|---|---|---|
| リピーター注文完了率 | 77% | 90% |
| 注文完了までのタップ数 | 4.2 | 1 |
| 月間リピート注文数 | 18万件 | 24万件 |
スコープ: Phase 1は直近5件の注文履歴表示とワンタップ再注文のみ。カスタマイズ（トッピング変更など）はPhase 2に回す。
リリース2週間後、再注文経由のオーダーが全体の 31% を占め、リピーター離脱率は 23% から 9% に下がった。
背景: エンタープライズ顧客（従業員1,000名以上）の商談で、過去6か月間に 14件 が「権限管理が細かく設定できない」を理由に失注していた。失注額は合計 年間4,200万円 のARR。一方、既存の中小企業顧客からは「設定が複雑すぎる」という声もあり、単純に項目を増やせばよいという話ではない。
ゴール: 企業規模に応じて権限テンプレートを選べる仕組みを導入し、大企業には柔軟性を、中小企業にはシンプルさを提供する。
成功指標:
- Primary: エンタープライズ商談の権限起因の失注率を 40% → 10%以下 に
- Secondary: 権限設定の平均所要時間を 45分 → 15分 に短縮
- Guard Rail: 既存中小企業顧客のCSAT（顧客満足度）を現状維持以上
スコープ:
- In: ロールテンプレート3種（管理者・編集者・閲覧者）、カスタムロール作成、監査ログ
- Out: SSO/SAML連携（別プロジェクトで進行中）、APIレベルの権限制御
開発着手前のレビューで、法務チームから「監査ログの保持期間は最低3年必要」という要件が追加された。ブリーフがなければ、リリース後に気づいて手戻りになっていたはずだ。
背景: 人口8万人の市役所で、窓口の待ち時間が平均 47分 に達していた。職員アンケートでは 83% が「定型的な申請業務に時間を取られ、相談対応に手が回らない」と回答。住民からも「平日に仕事を休んで来庁しなければならない」という苦情が年間 620件 寄せられていた。
ゴール: 転入届・住民票交付など利用頻度の高い5手続きをオンライン化し、来庁不要で完結できるようにする。
成功指標:
| 指標 | 現状 | 目標（6か月後） |
|---|---|---|
| 対象手続きのオンライン利用率 | 0% | 30% |
| 窓口平均待ち時間 | 47分 | 30分以下 |
| 住民満足度（5段階） | 2.8 | 3.5以上 |
スコープ: 初期リリースは5手続きのみ。マイナンバーカード認証を前提とし、カード未所持者向けの代替手段はPhase 2で検討する。
リスク: 高齢者のデジタルリテラシー格差が最大の懸念。公民館での操作サポート体制を並行して整備しないと、オンライン化が「使える人だけ便利になる施策」になりかねない。この対策コストもブリーフに含めたことで、予算承認がスムーズに進んだ。
やりがちな失敗パターン#
- ソリューションから書き始める — 「チャット機能を追加する」と手段を先に決めてしまい、背景や目的が後付けになる。ブリーフは必ず「課題」から書くこと
- 成功指標が曖昧 — 「ユーザー体験を向上させる」では何も測れない。必ず数値目標と計測方法をセットで定義する。「何が何%になったら成功か」を言い切る
- スコープの"やらないこと"を書かない — やることだけ書くと、レビューのたびに「これも入れてほしい」と要件が膨らむ。Out of Scopeを明示するだけで、開発中のスコープクリープが激減する
まとめ#
プロダクトブリーフは、新機能の背景・目的・成功指標・スコープを1ページにまとめて、チーム全員の認識を揃えるためのドキュメント。書く順番は「なぜ→何を→どう測る→何をやらないか」の流れが基本になる。手間に感じるかもしれないが、開発着手前に30分かけてブリーフを書くことで、リリース後の「思ってたのと違う」を防げる。まずは次の新機能で1枚書いてみるところから始めてほしい。