事業やサービスを初めて企画するとき、「どこから始めればいいんだろう？」という悩みは誰もが経験する問題です。
さまざまな企画の種類がありますが、特にWeb企画が最近最も一般的なので、これを中心に説明していきますね。
Web企画は各段階ごとに丁寧な準備が必要です。
市場調査とターゲット設定#
企画する対象が必要です。何かを作るなら、経験した問題や不便さから始めるのが良いでしょう。
こうした不便を感じている人々の規模がどのくらいかターゲットを見つければ、目標市場を決めることができます。
コアターゲットの選定：
- 売上を牽引する年齢層と消費パターン、関心事を把握して、目標顧客を明確に決めます
- ターゲット設定によってUI・UX戦略とデザインの方向性が決まるため、非常に重要です
アンケート調査およびユーザー意見の収集：
- 実際の顧客や潜在顧客を対象に、機能要件、改善意見、利用環境などを調査します
- 収集したデータを基に、サービスの方向性をしっかりと定めていく必要があります
サービスの決定：
- 調査結果を基に、実装するサービスのコア機能とコンセプトを確定する必要があります
企画の実行 – 「どう作るか？」#
作るサービスが決まったら、どう作るべきかを決めなければなりません。
どんな形で作るか決めるためには、見た目と、その見た目に基づいた動作を定義する必要があります。
そうすれば、どんな人材が必要なのかがわかります。
UX・UIの定義：
- ユーザー体験（UX）とインターフェース（UI）を細かく計画し、直感的で便利な利用環境を作ります
ペルソナとユーザーシナリオ：
- 具体的なユーザーペルソナを設定し、彼らがどんな行動をするか推測するシナリオを作成します
- このプロセスを通じて、実際の利用ケースを事前に予測し対応できます
プロジェクトリスク管理：
- 初期段階で企画の方向性と具体的な実行計画が不十分だとプロジェクトが迷走する可能性があるため、ここから徹底的な計画策定が必須です
要件定義書の作成#
外注先として顧客のためにサービスを作る場合、こうした成果物が必要になることがあります。
必ずしもそうでなければ不要かもしれません。しかし、記録用としてでも初めてなら一度やってみると良いでしょう。
クライアントおよび社内RFP：
- クライアントが要求する事項（RFP, Request For Proposal）を正確に反映して文書化します
証拠資料の確保：
- 今後発生し得る紛争や変更事項に備えて、修正履歴を丁寧に記録します
機能仕様書の作成#
開発者が実装できるよう、機能についての説明が必要です。スケルトンUIを使って大まかに作られた画面に、機能の説明が詳しく記載されています。
最近ではこの部分をFigmaでも十分に対応できるようです。
詳細機能の整理：
- 各機能の詳細を仕様化し、アウトソーシング時の成果物として活用できるようにします
検証とレビュー：
- 企画段階で導き出された機能が実際の開発と連動するよう、チームメンバー間の継続的なレビューと検証が必要です
ワイヤーフレームとIA構成#
ユーザーがどんな機能を持ち、どんな問題を解決するために必要なステップを実行するフローを確認するのに適しています。
ワイヤーフレーム：
- UIデザインが完全に確定する前に、画面構造と基本フローを視覚化してチーム内外に伝えます
- 「確定」した内容ではなく「初稿」であることを明確にしつつ、理解を助けるツールとして活用します
Information Architecture (IA)：
- ページごとの機能、担当者、スケジュール、ページの実際の数（本数）をExcelなどで整理します
- その後、IAを基にWBS（Work Breakdown Structure）に転換してスケジュール管理に反映します
企画書は単なるドキュメントではなく、チームとクライアント間のコミュニケーションツールです。サービスが完成して終わり！ではなく、開発プロジェクトのように管理されるべきです。
バージョン管理と修正履歴を丁寧に記録し、プロジェクトの透明性を確保すると良いでしょう。Gitのようなバージョン管理システムが必要です。
初期段階から企画、デザイン、開発チーム間のスムーズなレビュープロセスを通じて、不要な修正と時間を減らすことが重要です。企画者だけが行う作業で他の職種が参加できなければ、実行段階で細かい修正が必要になる可能性があります。
Our greatness lies not so much in being able to remake the world as being able to remake ourselves.
— Mahatma Gandhi
