name: e2e-first-planning description: | E2Eファースト開発計画策定ガイド。 Walking Skeleton、MVP計画、縦割りタスク分割をサポート。 allowed-tools: Read, Grep, Glob
E2Eファースト計画策定スキル
目的
E2E（End-to-End）ファーストの開発計画を策定し、リスクを早期発見し、価値を段階的に提供する。
E2Eファーストとは
定義
E2Eファースト: ユーザーの視点から始めて終わりまで動作する最小限の機能を最優先で実装するアプローチ。
重要な原則
- 価値の早期提供: ユーザーが触れる機能を優先
- リスクの早期発見: インテグレーション問題を早期に検出
- 継続的なフィードバック: 動くものを見せて方向性を確認
- 技術的実現可能性の検証: 最初から本番環境を意識
なぜE2Eファーストが重要か
| 利点 | 説明 |
|---|---|
| 🎯 ユーザー価値重視 | 常に動作する機能を提供 |
| 🚨 早期リスク発見 | 統合の問題を早期に検出 |
| 🔄 継続的フィードバック | ステークホルダーとの早期合意 |
| 🏗️ 技術的実現可能性 | アーキテクチャの妥当性を検証 |
| 📊 進捗の可視化 | 動作する機能 = 進捗 |
アンチパターン: 横割り開発
❌ 避けるべき開発順序
Phase 1: UI全体を作る
Phase 2: API全体を作る
Phase 3: DB全体を作る
Phase 4: 統合（← ここで大量の問題発見）
問題点:
- 統合まで動作する機能がゼロ
- リスクが最後に集中
- ユーザーフィードバックが遅い
- 見積もりの精度が低い
✅ 推奨: 縦割り開発（E2Eスライス）
Phase 1: ログイン機能（UI + API + DB）← 動作する
Phase 2: ダッシュボード（UI + API + DB）← 動作する
Phase 3: データ編集（UI + API + DB）← 動作する
利点:
- 各フェーズで動作する機能を提供
- リスクを段階的に管理
- 継続的なフィードバック
- 見積もりの精度向上
計画策定フレームワーク
フェーズ1: Skeleton（骨組み）
目的: プロジェクトの基本構造を定義
成果物:
- システムアーキテクチャ図
- 主要コンポーネントの識別
- 技術スタックの決定
- 開発環境のセットアップ
期間: 1-3日
チェックリスト:
- プロジェクト構造が明確か
- 技術スタックが決定したか
- 開発環境が構築できたか
- チーム全員が構造を理解したか
フェーズ2: Walking Skeleton（歩く骨組み）
目的: 最小限のE2E機能を実装
成果物:
- ユーザーから見て動作する最小機能
- CI/CD パイプラインの構築
- 本番環境へのデプロイ
- 監視・ログの基本設定
期間: 1-2週間
例: Webアプリケーション
ユーザー → ログイン → 簡単なダッシュボード表示 → ログアウト
（UI + API + DB + デプロイ）
チェックリスト:
- E2Eで動作するか
- 本番環境にデプロイできるか
- CI/CDが機能するか
- 監視が動作するか
フェーズ3: MVP（Minimum Viable Product）
目的: 実際のユーザーに価値を提供できる最小限の機能セット
成果物:
- コア機能の実装
- ユーザーが実際に利用できる状態
- フィードバック収集の仕組み
- ドキュメント
期間: 4-8週間
チェックリスト:
- ユーザーが価値を感じるか
- フィードバックを収集できるか
- スケールするアーキテクチャか
- 運用可能な状態か
タスク分割の原則
縦割り（推奨）
定義: 機能単位でUI→API→DBまで完結させる
例:
タスク1: ユーザー登録機能
- UI: 登録フォーム
- API: POST /api/users
- DB: usersテーブル作成
- Test: E2Eテスト
タスク2: ログイン機能
- UI: ログインフォーム
- API: POST /api/auth/login
- DB: sessionsテーブル
- Test: E2Eテスト
利点:
- 各タスク完了時に動作する機能ができる
- 統合の問題を早期発見
- 進捗が可視化しやすい
横割り（非推奨）
定義: レイヤー単位で全機能を作る
例:
タスク1: UI全画面作成
タスク2: API全エンドポイント作成
タスク3: DB全テーブル作成
タスク4: 統合（← ここで問題発覚）
問題点:
- 最後まで動作する機能がゼロ
- 統合時に大量の問題
- 進捗が見えにくい
E2Eスライスの特定方法
Step 1: ユーザーストーリーから始める
ユーザーストーリー:
「ECサイトの管理者として、商品を登録したい」
E2Eスライス:
1. 商品登録フォームを表示（UI）
2. 入力データを受け取る（API）
3. データベースに保存（DB）
4. 成功メッセージを表示（UI）
Step 2: 最小限の実装を定義
Phase 1 (Walking Skeleton):
- 商品名のみ登録可能
- 画像・説明・価格は後回し
- バリデーションは最小限
Phase 2 (MVP):
- 画像アップロード追加
- 価格・在庫管理追加
- 詳細なバリデーション
Step 3: 依存関係を整理
優先度1: ログイン機能（他の機能の前提）
優先度2: 商品一覧表示（データ確認のため）
優先度3: 商品登録（メイン機能）
優先度4: 商品編集（登録の拡張）
マイルストーン設計
マイルストーン1: Walking Skeleton
目標: 基本的なE2E動作を確認
成果物:
- ログイン → ダッシュボード表示 → ログアウト
- CI/CDパイプライン
- デプロイ自動化
期間: 1-2週間
完了条件:
- 本番環境にデプロイ済み
- E2Eテストが通る
- CI/CDが動作する
マイルストーン2: MVP
目標: ユーザーに価値を提供
成果物:
- コア機能3つ
- ユーザードキュメント
- フィードバック収集の仕組み
期間: 4-6週間
完了条件:
- ユーザーが実際に利用できる
- フィードバックを収集できる
- パフォーマンステスト済み
マイルストーン3: 機能拡張
目標: ユーザーフィードバックを基に機能追加
成果物:
- 追加機能
- パフォーマンス最適化
- セキュリティ強化
期間: 継続的
計画ドキュメントフォーマット
E2E計画テンプレート
# プロジェクト名 - E2E計画
## 概要
- プロジェクトの目的
- ターゲットユーザー
- 提供価値
## Walking Skeleton（1-2週間）
### 目標
最小限のE2E機能を動作させる
### E2Eスライス
1. ログイン機能（UI + API + DB）
2. ダッシュボード表示（UI + API + DB）
### 技術的準備
- [ ] CI/CDパイプライン構築
- [ ] デプロイ自動化
- [ ] 監視設定
## MVP（4-6週間）
### 目標
ユーザーに価値を提供できる最小機能セット
### E2Eスライス（優先順）
1. ユーザー登録（UI + API + DB）
2. データ一覧表示（UI + API + DB）
3. データ編集（UI + API + DB）
### 完了条件
- [ ] ユーザーが実際に利用できる
- [ ] フィードバック収集可能
- [ ] パフォーマンステスト済み
## リスク管理
| リスク | 対策 | 担当 |
|--------|------|------|
| 外部API統合の遅延 | モックAPIを先行実装 | チームA |
| パフォーマンス問題 | 早期負荷テスト | チームB |
## タイムライン
Week 1-2: Walking Skeleton Week 3-4: MVP Core機能 Week 5-6: MVP追加機能 Week 7+: フィードバック対応
チームへの共有方法
キックオフミーティング
-
E2Eファーストの説明（15分）
- なぜ横割りではなく縦割りか
- 各フェーズの目標
-
Walking Skeletonのデモ（10分）
- どこまで動くものを作るか
- 技術的な準備作業
-
タスク分割の確認（15分）
- 各E2Eスライスの説明
- 依存関係の確認
定期レビュー
- 毎週: E2Eスライス単位でデモ
- 隔週: マイルストーン進捗確認
- 月次: ユーザーフィードバック共有
よくある質問
Q1: すべてを最初から完璧に作る必要はないか？
A: 不要です。Walking Skeletonは最小限の実装で十分。重要なのは「E2Eで動作すること」。
Q2: 横割りの方が効率的では？
A: 短期的には効率的に見えますが、統合時の問題で結果的に遅延します。E2Eファーストは早期リスク発見により全体効率を向上します。
Q3: レガシーシステムでもE2Eファーストは可能か？
A: 可能です。まず新機能を小さなE2Eスライスで実装し、段階的に既存システムと統合します。
Q4: チームメンバーがフルスタック対応できない場合は？
A: ペアプログラミングや知識共有で対応。または、E2Eスライス単位でフロント/バック担当を決めて密に連携。