Skip to content
Indigo Works
Blog

第17章 エンビジョニング（プロダクトプランニング）

本章では、プロダクトのアイデアを具体的な開発に落とし込む前段階として、プロダクトの目的と方向性を定義する「エンビジョニング（構想）」のプロセスについて解説します。

17.1 概要

Section titled “17.1 概要”

エンビジョニングとは、関係者全員が「何を、なぜ作るのか」について共通理解を持つための活動です。

  • いつ行うか: プロダクトの立ち上げ時に集中的に行われますが、一度きりのイベントではありません。市場の変化や学習に合わせて、プロダクトのライフサイクルを通じて継続的に見直し、洗練させていきます。
  • 成果物: エンビジョニングの主な成果物は以下の3つです。
    1. プロダクトビジョン
    2. 概要レベルのプロダクトバックログ
    3. プロダクトのロードマップ

17.2 プロダクトビジョン

Section titled “17.2 プロダクトビジョン”

プロダクトビジョンは、プロダクトの「エレベーターピッチ（短い時間で魅力を伝える説明）」のようなものであり、開発の羅針盤となります。

  • 目的: 「誰のためのプロダクトか」「どんな課題を解決するのか」「ビジネス的にどのような価値があるのか」を明確にします。
  • 共有の重要性: ビジョンはドキュメントに書いて終わりではなく、開発チームやステークホルダー全員の頭の中に共有され、日々の意思決定の拠り所として機能しなければなりません。
  • ビジョンの形式: Geoffrey Mooreの『Crossing the Chasm』で紹介されているフォーマットなどがよく用いられます。
    • 「 （ターゲット顧客） 向けの、 （ニーズ・課題） を解決する、 （プロダクト名） というプロダクトは、 （重要な利点・理由） を提供する （プロダクトのカテゴリー） である。 （代替手段） とは異なり、 （主要な差別化要因） が備わっている。」

17.3 概要レベルのプロダクトバックログ

Section titled “17.3 概要レベルのプロダクトバックログ”

ビジョンが定まったら、それを実現するための大きな機能群（エピックやフィーチャー）を洗い出します。

  • 詳細化しすぎない: この段階では、細部まで完璧な要件定義（スプリント可能なストーリー）を作成しようとしてはいけません。あくまで「全体像」を把握することが目的です。
  • 見積りと優先順位: 洗い出した大きなアイテムに対し、Tシャツサイズ（S, M, Lなど）で大まかな見積りを行い、ビジネス価値に基づいてざっくりとした優先順位をつけます。これが後続のリリース計画の基礎となります。

17.4 プロダクトのロードマップ

Section titled “17.4 プロダクトのロードマップ”

ロードマップは、プロダクトが時間の経過とともにどのように成長し、ビジョンを実現していくかを示す視覚的な計画です。

  • リリースの道筋: 概要レベルのバックログアイテムを、将来の複数のリリース（例：Q1、Q2、Q3…）にどのように割り当てていくかを描き出します。
  • 柔軟性を持たせる: ロードマップは確定した「約束（コミットメント）」ではなく、現時点での「最良の予測（ガイド）」です。先のリリースになるほど不確実性が高まるため、状況の変化に応じて柔軟に変更されるべきものです。

17.5 その他のアクティビティ

Section titled “17.5 その他のアクティビティ”

プロダクトビジョン、概要レベルのバックログ、ロードマップの作成に加えて、エンビジョニングの段階でよく行われる重要なアクティビティが3つあります。

ペルソナ（Personas）

Section titled “ペルソナ（Personas）”
  • ターゲットとなる顧客やユーザーの典型的なプロフィールを具象化したものです。
  • 「システム管理者」といった抽象的な役割ではなく、「忙しくてマニュアルを読む暇がない、30代のIT担当者」のように具体的な人物像として描きます。
  • これにより、開発チーム全員が「誰のために作っているのか」を明確にイメージでき、要件やUIの優先順位付けがしやすくなります。

デザインの探索（Design Exploration）

Section titled “デザインの探索（Design Exploration）”
  • プロダクトの見た目や操作感（UI/UX）について、初期段階のアイデアを視覚化します。
  • ホワイトボードへのスケッチや、簡単なワイヤーフレーム、ペーパープロトタイプなどを作成し、ユーザーエクスペリエンスの方向性をチームで共有します。ここでも「作り込みすぎない」ことが重要です。

アーキテクチャの探索（Architecture Exploration）

Section titled “アーキテクチャの探索（Architecture Exploration）”
  • プロダクトを実現するための技術的なアプローチや、アーキテクチャの基本方針を検討します。
  • 未知の技術要素や大きな技術的リスクがある場合は、短い期間（タイムボックス）で「スパイク（技術的な調査や概念実証）」を実施し、実現可能性を検証してリスクを低減させます。

17.6 経済的に妥当なエンビジョニング

Section titled “17.6 経済的に妥当なエンビジョニング”

エンビジョニングは重要ですが、それ自体が目的化してしまい、際限なく時間とお金をかけてしまうのはアジャイルのアンチパターンです。

  • やりすぎに注意: 完璧なビジョンや詳細なロードマップを作ろうとして、何ヶ月も開発を始めない「分析麻痺（Analysis Paralysis）」に陥ってはいけません。
  • 判断の閾値（Confidence Thresholds）: エンビジョニングの目的は「このプロダクトに投資して開発を進めるべきか（Go/No-Go）」を判断することです。その判断を下すのに「十分に確信が持てる」だけの最低限の情報が集まった時点で、エンビジョニングを終了し、実際のスプリント（構築と検証）へと移行すべきです。

17.7 終わりに

Section titled “17.7 終わりに”

第17章では、プロダクトの方向性を定め、共通理解を構築する「エンビジョニング」のプロセスについて学びました。ビジョン、概要レベルのバックログ、ロードマップ、そしてペルソナやアーキテクチャの探索を「経済的に妥当な範囲」で行うことが成功の鍵です。

次章（第18章）では、このエンビジョニングで描いたロードマップを、より具体的な直近の開発計画に落とし込む「リリースプランニング」について解説します。