フレームワーク活用ガイドひとことで言うと#
プロダクトの**ビジョン（なぜ作るのか）・ターゲット（誰のためか）・ニーズ（何を解決するか）・主要機能（どう解決するか）・ビジネスゴール（どう儲けるか）**を1枚のボードに集約するフレームワーク。チーム全員が「自分たちは何を作っていて、なぜそれが重要なのか」を共有できる。
押さえておきたい用語#
- プロダクトビジョン（Product Vision）
- プロダクトが実現したい未来を一文で表したチームの北極星のこと。具体的すぎず抽象的すぎないバランスが重要。
- ターゲットグループ（Target Group）
- プロダクトが最も価値を届けたい主要なユーザーセグメントのこと。1〜2つに絞り込むことでボードの焦点が定まる。
- ニーズ（Needs）
- ターゲットが抱える課題・痛み・満たされていない欲求のこと。技術用語ではなくユーザーの言葉で記述する。
- ビジネスゴール（Business Goals）
- プロダクトがビジネスとして達成すべき売上・ユーザー数・収益性の目標のこと。ビジョンとの整合性が求められる。
プロダクトビジョンボードの全体像#
こんな悩みに効く#
- プロダクトの目的や方向性がチーム内で揃っていない
- 機能追加の判断基準がなく、場当たり的になっている
- ステークホルダーにプロダクトの全体像を端的に説明できない
基本の使い方#
プロダクトが実現したい未来を一文で表す。
- このプロダクトが成功したら、世界はどう変わるか？
- なぜ今これを作る必要があるのか？
- チームの誰もが共感できる言葉か？
ポイント: ビジョンは具体的すぎず抽象的すぎず。「すべての人を幸せに」は抽象的すぎ。「中小企業の経理を10分で完結させる」くらいが良い。
「誰の」「どんな課題」を解決するのかを明確にする。
- ターゲット: 主要なユーザーセグメントは誰か？（ペルソナ1〜2人分）
- ニーズ: そのユーザーが抱える最大の課題・痛みは何か？
- 現在の代替手段: 今はどうやって解決している（または放置している）か？
ポイント: ニーズはユーザーの言葉で書く。技術用語やビジネス用語ではなく、「月末の経費精算に毎回2時間かかって辛い」のように。
ニーズに対する解決策と、ビジネスとしての成功指標を決める。
- 主要機能: ニーズを解決する核となる機能は何か？（3〜5個に絞る）
- 差別化ポイント: 競合にはない自社独自の価値は何か？
- ビジネスゴール: 売上・ユーザー数・市場シェアなど、ビジネス面での目標
ポイント: 機能は「全部入り」にしない。ビジョンとニーズに直結するものだけを選ぶ。
5つの要素を1枚に整理し、チーム・ステークホルダーと共有する。
- ビジョンを中央に置き、ターゲット・ニーズ・機能・ビジネスゴールを周囲に配置
- 定期的（四半期ごと）に見直す機会を設ける
- 新しい機能リクエストが来た時、ボードと整合するか確認する
ポイント: ビジョンボードは**「生きたドキュメント」**として更新し続ける。壁に貼って毎日目にする場所に。
具体例#
| 要素 | 内容 |
|---|---|
| ビジョン | 「社会人が1日15分で、実務に使えるスキルを身につけられる世界を作る」 |
| ターゲット | 25〜35歳のビジネスパーソン。スキルアップしたいが時間がない |
| ニーズ | まとまった学習時間が取れない / 学んだことが実務で活かせない / 何を学べばいいか分からない |
| 主要機能 | (1)15分の短尺レッスン (2)実務テンプレート付き (3)AIによるスキル診断＆レコメンド |
| 差別化 | 「学ぶ」で終わらず「実務で使えるテンプレート」がセット |
| ビジネスゴール | 1年後: MAU 5万人 / 有料会員1万人 / 月商1,500万円 |
活用場面: 新機能の要望「コミュニティ機能が欲しい」が来た時、ビジョンボードと照合。「1日15分」のコンセプトとの整合性を確認し、コミュニティは次フェーズに回す判断ができ、開発リソースの分散を防いだ。
従業員30名のSaaS企業。機能追加の要望が月20件以上あり、何を優先すべきか分からなくなっていた。
Before（ビジョンボードなし）:
- 「大口クライアントが言うから」で機能追加を決定
- エンジニアが「何のために作っているのか分からない」と不満
ビジョンボード作成ワークショップ（2時間）:
| 要素 | 合意内容 |
|---|---|
| ビジョン | 「中小企業の経理担当が、請求業務を月末の1日で完結できる世界」 |
| ターゲット | 従業員10〜100名の中小企業の経理担当（1〜2名体制） |
| ニーズ | 請求書作成に毎月3日かかる / 入金消込が手動でミスが多い / 会計ソフトへの転記が二重作業 |
| 主要機能 | (1)テンプレート請求書の自動生成 (2)入金消込の自動マッチング (3)会計ソフト連携 |
| ビジネスゴール | ARR 2億円 / 契約社数 500社 / NPS +40 |
After（3ヶ月後）:
- 月20件の機能要望をビジョンボードで選別 → 対応は平均5件に絞り込み
- エンジニアが「ビジョンに沿っているか」で自発的に判断できるように
- 開発のスループットが変わらないのに、ユーザー満足度（NPS）が+18から+32に向上
地方自治体と共同で観光アプリを開発する際に、ステークホルダー（市の観光課、商工会、開発チーム）の認識を揃えるためにビジョンボードを作成。
| 要素 | 内容 |
|---|---|
| ビジョン | 「初めて訪れる観光客が、地元の人しか知らない体験に出会える」 |
| ターゲット | 20〜40代の国内旅行好き。SNSで旅行記録を共有する層 |
| ニーズ | ガイドブックにない体験がしたい / 現地での移動手段がわからない / 地元の人のおすすめを知りたい |
| 主要機能 | (1)地元住民が投稿するスポット情報 (2)モデルコースの自動生成 (3)バス・レンタサイクルの予約連携 |
| ビジネスゴール | 年間DL 3万件 / アプリ経由の観光消費額 年1.2億円 |
効果: 市の観光課が「お知らせ機能を追加してほしい」と要望。ビジョンボードと照合し、「観光客向けか、住民向けか」を議論。結果、住民向け機能は別アプリに分離する判断に至った。ステークホルダーが異なる組織でも、1枚のボードで「何を作らないか」を合意できた。
やりがちな失敗パターン#
- ビジョンが抽象的すぎる — 「世界を変える」では判断基準にならない。ターゲットと提供価値を含む具体的なビジョンにする
- 作って終わりにする — 市場も顧客も変わるのに、ビジョンボードだけ更新されない。四半期ごとに見直すルールを設ける
- 機能を詰め込みすぎる — ビジョンボードに10個も機能を書くと焦点がぼやける。核となる3〜5個に絞り込む勇気を持つ
- ビジョンボードと日常の意思決定が切り離される — 壁に飾るだけでは意味がない。機能要望が来たら必ずボードと照合する運用ルールを設け、判断の根拠として日常的に参照する
まとめ#
プロダクトビジョンボードは、プロダクトの「なぜ・誰に・何を・どうやって・どう儲けるか」を1枚で語る最もシンプルなツール。チーム全員が同じ方向を向き、機能追加の判断基準を持つために欠かせない。作るのは簡単、維持するのが大変。だからこそ定期的に見直し、常に「今の自分たちの北極星」として活用し続けることが大切。