e2e-first-planning

# E2Eファースト計画策定スキル

## 目的

E2E（End-to-End）ファーストの開発計画を策定し、リスクを早期発見し、価値を段階的に提供する。

## E2Eファーストとは

### 定義

**E2Eファースト**: ユーザーの視点から始めて終わりまで動作する最小限の機能を最優先で実装するアプローチ。

### 重要な原則

1. **価値の早期提供**: ユーザーが触れる機能を優先
2. **リスクの早期発見**: インテグレーション問題を早期に検出
3. **継続的なフィードバック**: 動くものを見せて方向性を確認
4. **技術的実現可能性の検証**: 最初から本番環境を意識

### なぜ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テスト
```

**利点:**