アジャイル開発は、変化に対応しながら価値を提供していく開発手法です。
しかし、ウォーターフォール型に慣れた組織では、計画性や文書化された成果物が不足しているように感じることがあります。
この記事では、ウォーターフォール型の成果物も取り入れたアジャイル開発の企画段階で作成すべき成果物についてまとめます。
アジャイル開発経験のない筆者の学習メモでもありますので、ご了承ください。
インセプションデッキと他項目が一部重複しますが、重要なものやインセプションデッキで概要を作成し、その後より詳細な検討をすべきものをイメージしています。
MVP（Minimum Viable Product）
MVPとは、最小限の機能で構成されたプロダクトを指します。
目的は、ユーザーのニーズや反応を早期に確認し、フィードバックを得ることです。
いきなり本格的な開発を始めると、ユーザーニーズに合わない場合の損失が大きくなります。
MVPを使ってユーザーからのフィードバックを得ることで、開発の方向性を早期に修正可能です。
作成するもの
- シンプルな画面
必要最低限のUI。 - 基本機能
コアとなる1〜2つの機能に絞り込む。 - 計測手段
ユーザー行動を分析するためのトラッキング設定（Google Analyticsなど）。
インセプションデッキ
インセプションデッキは、プロジェクトの方向性を明確にするための10項目からなる資料です。
インセプションデッキの10項目
- 我われはなぜここにいるのか
- 目的
プロジェクトの背景やビジネス上の課題を整理し、なぜこのプロジェクトが必要なのかを明確にします。 - 具体例
「競合との差別化を図り、売上を10%向上させるため」や「現行システムの維持コストを30%削減するため」。 - 作成するもの
問題提起とゴールを簡潔にまとめたドキュメント。
- 目的
- エレベーターピッチを作る
- 目的
短い時間でプロジェクトの価値を伝えるための説明を準備します。 - 形式の例
「このプロジェクトは【対象ユーザー】向けの【製品やサービス】であり、【ニーズや課題】を解決します。他の方法とは異なり、【独自の価値】を提供します。」 - 具体例
「営業担当者向けの訪問管理アプリで、煩雑な報告業務を自動化します。競合アプリと異なり、音声入力で記録が完了します。」 - 作成するもの
2〜3行の簡潔な説明文。
- 目的
- パッケージデザインを作る
- 目的
プロジェクトの全体像を視覚的に表現し、関係者に分かりやすく伝えます。 - 具体例
- システム構成図
- ユーザーフロー図
- UIのワイヤーフレーム
- 作成するもの
サービスやプロダクトの特徴をビジュアルで示す資料や図。
- 目的
- やらないことリストを作る
- 目的
スコープを管理し、優先順位の低い機能や項目を排除します。これにより、チームが集中すべきタスクを明確にします。 - 具体例
- SNS連携は初期リリースでは行わない
- 多言語対応は優先度を下げる
- 作成するもの
実施しない機能や業務のリスト。
- 目的
- 「ご近所さん」を探せ
- 目的
プロジェクトに影響を与えるステークホルダーを特定し、協力関係を築きます。 - 具体例
- 社内の営業部門やサポートチーム
- 外部の協力企業やパートナー
- 作成するもの
ステークホルダーマップや影響度マトリックス。
- 目的
- 解決案を描く
- 目的
具体的な解決策を洗い出し、検討します。技術的なアプローチや機能設計も含めます。 - 具体例
- API連携によるデータ統合
- 自動化ツールによる業務効率化
- 作成するもの
フローチャート、データモデル、ワイヤーフレーム。
- 目的
- 夜も眠れなくなるような問題は何だろう
- 目的
プロジェクトの最重要課題やリスクを洗い出します。対応策を考えておくことで、スムーズな進行が可能になります。 - 具体例
- セキュリティリスク
- 法規制への対応
- 作成するもの
リスク一覧と優先度、対応策を記載したリスク管理表。
- 目的
- 期間を見極める
- 目的
プロジェクトに必要な期間を見積もり、無理のないスケジュールを作成します。短すぎると品質が低下し、長すぎるとコストが膨らみます。 - 具体例
- スプリントは2週間単位で実施
- MVPリリースは3ヶ月以内
- 作成するもの
ガントチャートやスプリント計画。
- 目的
- 優先順位は？
- 目的
開発すべき機能の優先度を決めます。 - 具体例:
- Must: ユーザー登録とログイン機能
- Should: 通知機能
- Could: カスタムテーマ設定
- Won’t: 初期リリースでのチャット機能
- 作成するもの
優先度を分類したプロダクトバックログ。Must／Should／Could／Won’t Have this time（M/S/C/W）の分類を使うと便利。
- 目的
- 何がどれだけ必要なのか
- 目的
必要なリソース（人員、技術、予算）を見積もり、過不足なく配分します。 - 具体例
- 開発者5名、デザイナー2名、テスト担当2名
- 月額50万円のクラウドコスト
- 作成するもの
リソース見積もり表や予算計画書。
- 目的
プロジェクト体制図
プロジェクト体制図は、役割と責任、報告経路を明確にします。
作成するもの
- 役割
プロダクトオーナー、スクラムマスター、開発チーム、QAなど。 - 権限
意思決定権や承認フローの明記。 - コミュニケーション経路
ステークホルダーへの報告手順。
ステークホルダーマップ
ステークホルダーマップは、関係者の影響力と関心度に応じた配置図です。
作成するもの
- 影響度と関心度のマトリックス
4象限で整理。 - アクションプラン
重要ステークホルダーへの対応方法。 - 情報共有の頻度
定例会や報告資料のスケジュール。
トレードオフドライバー
トレードオフドライバーは、品質、コスト、スコープ、スピードの優先順位を決めます。
作成するもの
- 優先順位リスト
最も重視すべき項目の選定。 - 妥協点の明示
遅延や品質低下を許容する条件。 - バランスシート
トレードオフの理由を文書化。
ペルソナ
ペルソナは、具体的なユーザー像を描くための架空の人物です。
作成するもの
- 基本情報
年齢、職業、趣味、スキル。 - 目標と課題
解決したい問題やニーズ。 - 利用シナリオ
どのような状況で使うか。
ユーザーストーリー
ユーザーストーリーは、ユーザー視点で機能を表現します。
具体的な形式
「〇〇として（役割）、私は〇〇がしたい（機能）。なぜなら〇〇だからだ（理由）。」
例
「営業担当者として、私は訪問履歴を簡単に記録したい。なぜなら、商談準備を効率化したいからだ。」
作成するもの
- AC（受け入れ条件）
実装の完了条件。 - ユーザーフロー
利用時の操作手順。
ウォーターフォール型要件定義資料
アジャイル開発でもウォーターフォール型の要件定義は有効です。
作成するもの
- フローチャート
業務の流れと処理手順。 - ER図（データモデル）
データの関係性。 - ワイヤーフレーム
画面構成のイメージ。 - 状態遷移図
システムの動き。
プロダクトバックログ
プロダクトバックログは、開発すべき項目の一覧です。
作成するもの
- PBI（Product Backlog Item）
ユーザーストーリー、テスト、マニュアル作成タスク。 - 優先度
Must／Should／Could／Won’t Have this time（M/S/C/W）。 - 見直しと更新
スプリントごとのリファインメント。
バーン・ダウン・チャート
バーン・ダウン・チャートは、進捗を管理するためのグラフです。
作成するもの
- 縦軸
残作業量。 - 横軸
スプリント期間。 - トレンド線
計画との差異。
ウォーターフォール型スケジュール・タスク管理資料
ウォーターフォール型の資料は、依存関係が多いタスク管理に有効です。
作成するもの
- ガントチャート
作業の順序と期間。 - マイルストーン
重要な節目の定義。 - タスクの依存関係
前提条件と担当者。
まとめ
アジャイル開発の企画段階では、MVPを早期に作り、インセプションデッキやプロダクトバックログ、ユーザーストーリーを用いて方向性を決めていきます。また、ウォーターフォール型に慣れた組織のために要件定義やガントチャートも併用し、スムーズな移行を目指します。
