SKILL.md
civicship-api 段階的デリバリー計画
大きな機能を段階的にリリース可能な単位に分割し、リスクを最小化したデリバリー計画を策定します。フィーチャーフラグ、ロールバック計画、成功指標を含む実行可能なプランを生成します。
使用方法
# 要件定義書から段階的計画を生成
/phased-delivery-plan docs/requirements/point-expiration.md
# 衝突レポートを踏まえた計画生成
/phased-delivery-plan "ポイント有効期限機能" --with-conflicts引数:
$ARGUMENTS: 要件定義書のパス、または機能名--with-conflicts:/check-requirement-deltaの結果を考慮
デリバリー計画プロセス
ステップ1: 機能の分解（Feature Decomposition）
大きな機能を独立してリリース可能な小さな単位に分割:
## 機能分解
### 最終ゴール
「ポイント有効期限機能」を完全に実装
### 分解単位（Vertical Slices）
#### Phase 1: データ基盤（Infrastructure）
**目的:** 有効期限データを保存できるようにする
**スコープ:**
- Prismaスキーマ変更（`t_wallets.expiresAt` 追加）
- マイグレーション実行
- GraphQL型追加（`GqlWallet.expiresAt`）
**価値:**
- ユーザーには見えない（内部変更のみ）
- 次フェーズの前提条件
**リスク:** 🟢 Low
- 既存機能への影響なし
- ロールバック容易（カラム追加のみ）
---
#### Phase 2: 読み取り機能（Read-Only）
**目的:** 有効期限を表示できるようにする
**スコープ:**
- GraphQL Query に `expiresAt` フィールドを追加
- フロントエンドでの表示対応
**価値:**
- ユーザーがポイント有効期限を確認できる
- 運営が手動で有効期限を設定し、効果を確認できる
**リスク:** 🟢 Low
- 読み取りのみ（データ変更なし）
- 既存機能に影響なし
---
#### Phase 3: 手動設定機能（Manual）
**目的:** 管理者が手動で有効期限を設定できるようにする
**スコープ:**
- GraphQL Mutation `walletSetExpiration` 追加
- 管理画面での設定UI
**価値:**
- 特定のキャンペーンで有効期限を試験運用
- 小規模でのフィードバック収集
**リスク:** 🟡 Medium
- 手動設定による人為ミスの可能性
- ロールバック可能（設定を削除すればOK）
---
#### Phase 4: 自動付与機能（Automated）
**目的:** ポイント付与時に自動的に有効期限を設定
**スコープ:**
- WalletService に有効期限ロジック追加
- デフォルト有効期限の設定（例: 付与から1年）
**価値:**
- 全ポイントに自動的に有効期限が付与される
- 運用コストの削減
**リスク:** 🟡 Medium
- ビジネスロジックの変更
- 既存のポイント付与フローに影響
---
#### Phase 5: 失効通知機能（Notification）
**目的:** 有効期限切れ前にユーザーに通知
**スコープ:**
- バッチ処理で有効期限7日前のポイントを検出
- LINE通知送信
**価値:**
- ユーザーエクスペリエンスの向上
- ポイント失効の不満軽減
**リスク:** 🟢 Low
- 通知のみ（データ変更なし）
- 失敗しても本質的な機能に影響なし
---
#### Phase 6: 自動失効機能（Expiration）
**目的:** 有効期限切れポイントを自動的に失効
**スコープ:**
- バッチ処理で有効期限切れポイントを検出
- ポイント残高から減算
**価値:**
- 完全な有効期限機能の実現
- 運用の自動化
**リスク:** 🔴 High
- ポイント残高の変更（不可逆）
- ユーザーの資産に直接影響
- ロールバック困難ステップ2: フェーズ間の依存関係
各フェーズの依存関係を明確化:
graph TD
P1[Phase 1: データ基盤] --> P2[Phase 2: 読み取り機能]
P2 --> P3[Phase 3: 手動設定機能]
P3 --> P4[Phase 4: 自動付与機能]
P4 --> P5[Phase 5: 失効通知機能]
P4 --> P6[Phase 6: 自動失効機能]
P5 -.optional.-> P6依存関係ルール:
- Phase N は Phase N-1 が完了するまで開始不可
- Phase 5 と Phase 6 は並行実装可能
- Phase 6 は Phase 5 なしでも実装可能（推奨はセット）
ステップ3: フィーチャーフラグ戦略
各フェーズをフィーチャーフラグで制御:
## フィーチャーフラグ設計
### 環境変数ベースのフラグ
**ファイル:** `src/config/features.ts`
\`\`\`typescript
export const FEATURE_FLAGS = {
// Phase 2: 有効期限の表示
WALLET_EXPIRATION_DISPLAY: process.env.FEATURE_WALLET_EXPIRATION_DISPLAY === "true",
// Phase 3: 手動設定
WALLET_EXPIRATION_MANUAL_SET: process.env.FEATURE_WALLET_EXPIRATION_MANUAL_SET === "true",
// Phase 4: 自動付与
WALLET_EXPIRATION_AUTO_SET: process.env.FEATURE_WALLET_EXPIRATION_AUTO_SET === "true",
// Phase 5: 失効通知
WALLET_EXPIRATION_NOTIFICATION: process.env.FEATURE_WALLET_EXPIRATION_NOTIFICATION === "true",
// Phase 6: 自動失効
WALLET_EXPIRATION_AUTO_EXPIRE: process.env.FEATURE_WALLET_EXPIRATION_AUTO_EXPIRE === "true"
} as const;
\`\`\`
---
### GraphQLスキーマでのフラグ制御
\`\`\`typescript
// Resolver でフラグチェック
Query = {
wallet: async (_, { id }, ctx) => {
const wallet = await this.usecase.getWallet(id, ctx);
// Phase 2 のフラグが OFF の場合、expiresAt を除外
if (!FEATURE_FLAGS.WALLET_EXPIRATION_DISPLAY) {
delete wallet.expiresAt;
}
return wallet;
}
};
Mutation = {
walletSetExpiration: async (_, { input }, ctx) => {
// Phase 3 のフラグチェック
if (!FEATURE_FLAGS.WALLET_EXPIRATION_MANUAL_SET) {
throw new Error("FEATURE_NOT_ENABLED");
}
return this.usecase.setExpiration(input, ctx);
}
};
\`\`\`
---
### フラグの段階的有効化
| Phase | 開発環境 | ステージング | 本番（10%） | 本番（50%） | 本番（100%） |
|-------|---------|------------|------------|------------|-------------|
| Phase 1 | Week 1 | Week 2 | - | - | Week 2 |
| Phase 2 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 |
| Phase 3 | Week 3 | Week 4 | Week 5 | Week 6 | Week 7 |
| Phase 4 | Week 5 | Week 6 | Week 7 | Week 8 | Week 9 |
| Phase 5 | Week 6 | Week 7 | Week 8 | - | Week 9 |
| Phase 6 | Week 7 | Week 8 | Week 9 | Week 10 | Week 11 |
**ロールアウト戦略:**
1. **開発環境:** 即座に有効化
2. **ステージング:** 1週間後に有効化
3. **本番（10%）:** カナリアリリース、特定コミュニティのみ
4. **本番（50%）:** 問題なければ半数に展開
5. **本番（100%）:** 全ユーザーに展開ステップ4: リスク評価とロールバック計画
各フェーズのリスクとロールバック手順を定義:
## リスク評価とロールバック計画
### Phase 1: データ基盤
**リスク:** 🟢 Low
- マイグレーション失敗の可能性: 5%
- 既存データへの影響: なし
**ロールバック手順:**
1. マイグレーションのロールバック
\`\`\`bash
pnpm db:migrate-rollback
\`\`\`
2. Prisma Client の再生成
\`\`\`bash
pnpm db:generate
\`\`\`
3. アプリケーション再起動
**ロールバック所要時間:** 5分
---
### Phase 2: 読み取り機能
**リスク:** 🟢 Low
- GraphQLスキーマの破壊的変更: なし（フィールド追加のみ）
- パフォーマンス影響: なし
**ロールバック手順:**
1. フィーチャーフラグを OFF
\`\`\`bash
export FEATURE_WALLET_EXPIRATION_DISPLAY=false
\`\`\`
2. アプリケーション再起動（またはホットリロード）
**ロールバック所要時間:** 1分
---
### Phase 3: 手動設定機能
**リスク:** 🟡 Medium
- 管理者の誤操作: 30%
- 意図しない有効期限設定: 20%
**ロールバック手順:**
1. フィーチャーフラグを OFF
2. 誤って設定された有効期限をクリア
\`\`\`sql
UPDATE t_wallets SET expiresAt = NULL WHERE expiresAt < NOW();
\`\`\`
**ロールバック所要時間:** 10分
**リスク軽減策:**
- 管理画面に確認ダイアログを追加
- 有効期限設定の監査ログ記録
- 設定前にプレビュー機能
---
### Phase 4: 自動付与機能
**リスク:** 🟡 Medium
- ビジネスロジックのバグ: 25%
- 全ポイントに影響: High Impact
**ロールバック手順:**
1. フィーチャーフラグを OFF
\`\`\`bash
export FEATURE_WALLET_EXPIRATION_AUTO_SET=false
\`\`\`
2. 誤って設定された有効期限をクリア
\`\`\`sql
UPDATE t_wallets SET expiresAt = NULL WHERE createdAt > 'YYYY-MM-DD';
\`\`\`
**ロールバック所要時間:** 15分
**リスク軽減策:**
- ステージング環境で十分なテスト
- カナリアリリース（10% → 50% → 100%）
- リアルタイム監視（有効期限設定数のメトリクス）
---
### Phase 5: 失効通知機能
**リスク:** 🟢 Low
- 通知送信失敗: 10%
- 過剰な通知: 15%
**ロールバック手順:**
1. フィーチャーフラグを OFF
\`\`\`bash
export FEATURE_WALLET_EXPIRATION_NOTIFICATION=false
\`\`\`
2. バッチ処理の停止
**ロールバック所要時間:** 5分
**リスク軽減策:**
- 通知送信のレート制限
- ユーザーごとの通知頻度制御（1日1回まで）
- オプトアウト機能
---
### Phase 6: 自動失効機能
**リスク:** 🔴 High
- ポイント残高の誤減算: 15%
- ユーザー資産への影響: Critical Impact
- ロールバック困難: 失効したポイントは復元困難
**ロールバック手順:**
1. **即座にフラグOFF**
\`\`\`bash
export FEATURE_WALLET_EXPIRATION_AUTO_EXPIRE=false
\`\`\`
2. **バッチ処理の緊急停止**
3. **影響調査**
\`\`\`sql
SELECT userId, SUM(amount) as expiredPoints
FROM t_point_expiration_logs
WHERE executedAt > 'YYYY-MM-DD HH:MM:SS'
GROUP BY userId;
\`\`\`
4. **ポイント復元（可能な場合）**
\`\`\`sql
-- 失効ログから復元
INSERT INTO t_point_transactions (userId, amount, type, reason)
SELECT userId, amount, 'REFUND', 'Expiration rollback'
FROM t_point_expiration_logs
WHERE executedAt > 'YYYY-MM-DD HH:MM:SS';
\`\`\`
**ロールバック所要時間:** 30分〜2時間
**リスク軽減策:**
- **失効ログの記録:** 失効前に別テーブルにログ保存
\`\`\`prisma
model t_point_expiration_logs {
id String @id @default(cuid())
userId String
amount Int
expiresAt DateTime
executedAt DateTime @default(now())
}
\`\`\`
- **ドライラン:** 本番実行前にシミュレーション
- **段階的実行:** 1日100ユーザーずつなど、少数から開始
- **手動承認:** 最初の1ヶ月は自動実行せず、管理者が確認後に実行ステップ5: 成功指標（KPI）の設定
各フェーズの成功を測定する指標:
## フェーズごとの成功指標
### Phase 1: データ基盤
**技術指標:**
- [ ] マイグレーション成功率: 100%
- [ ] TypeScriptコンパイルエラー: 0件
- [ ] テストカバレッジ: 変更なし
**判断基準:**
- 全ての指標が基準を満たせば Phase 2 へ進む
---
### Phase 2: 読み取り機能
**技術指標:**
- [ ] GraphQLクエリエラー率: < 0.1%
- [ ] レスポンスタイム劣化: < 5%
- [ ] N+1クエリ: 検出されない
**ビジネス指標:**
- [ ] ユーザーからの問い合わせ: 0件
- [ ] クライアントアプリのクラッシュ: 0件
**判断基準:**
- 1週間の本番運用で問題なければ Phase 3 へ進む
---
### Phase 3: 手動設定機能
**技術指標:**
- [ ] Mutationエラー率: < 1%
- [ ] 有効期限設定の成功率: > 99%
**ビジネス指標:**
- [ ] 管理者の操作ミス: < 5%
- [ ] ユーザーからの問い合わせ: < 10件/週
**判断基準:**
- 2週間の運用で問題なければ Phase 4 へ進む
- 操作ミスが多い場合はUIを改善
---
### Phase 4: 自動付与機能
**技術指標:**
- [ ] 有効期限自動設定の成功率: > 99.9%
- [ ] ポイント付与のエラー率: < 0.1%
**ビジネス指標:**
- [ ] ユーザーからの苦情: < 5件/週
- [ ] 有効期限に関する問い合わせ: < 20件/週
**判断基準:**
- カナリアリリース（10%）で1週間問題なければ 50% へ
- 50% で1週間問題なければ 100% へ
---
### Phase 5: 失効通知機能
**技術指標:**
- [ ] LINE通知送信成功率: > 95%
- [ ] バッチ処理の実行時間: < 10分
**ビジネス指標:**
- [ ] 通知のオプトアウト率: < 10%
- [ ] ユーザーエンゲージメント: 通知後のアプリ起動率 > 20%
**判断基準:**
- オプトアウト率が高い場合は通知内容を見直し
- 問題なければ Phase 6 へ進む
---
### Phase 6: 自動失効機能
**技術指標:**
- [ ] 失効処理の成功率: 100%（エラー許容なし）
- [ ] 失効ログの記録率: 100%
**ビジネス指標:**
- [ ] ユーザーからの苦情: < 10件/週
- [ ] ポイント失効に関する問い合わせ: < 30件/週
- [ ] ポイント復元リクエスト: < 5件/週
**判断基準:**
- 最初の1ヶ月は手動承認制
- 問題なければ完全自動化へ移行ステップ6: デリバリースケジュール
具体的なスケジュールとマイルストーン:
## デリバリースケジュール
### 全体スケジュール（11週間）
| Week | Phase | タスク | 環境 | マイルストーン |
|------|-------|--------|------|---------------|
| 1 | Phase 1 | データ基盤実装 | 開発 | スキーマ変更完了 |
| 2 | Phase 1 | マイグレーション実行 | 本番 | 🎯 データ基盤リリース |
| 2-3 | Phase 2 | 読み取り機能実装 | 開発 | GraphQL対応完了 |
| 3-4 | Phase 2 | フロントエンド対応 | ステージング | UI実装完了 |
| 4-6 | Phase 2 | カナリアリリース | 本番 | 🎯 読み取り機能リリース |
| 3-4 | Phase 3 | 手動設定実装 | 開発 | 管理画面実装完了 |
| 5-7 | Phase 3 | 試験運用 | 本番 | 🎯 手動設定リリース |
| 5-6 | Phase 4 | 自動付与実装 | 開発 | ロジック実装完了 |
| 7-9 | Phase 4 | カナリアリリース | 本番 | 🎯 自動付与リリース |
| 6-7 | Phase 5 | 失効通知実装 | 開発 | バッチ処理実装完了 |
| 8-9 | Phase 5 | 通知配信開始 | 本番 | 🎯 失効通知リリース |
| 7-8 | Phase 6 | 自動失効実装 | 開発 | 失効ロジック実装完了 |
| 9-11 | Phase 6 | 手動承認期間 | 本番 | 🎯 自動失効リリース |
---
### 週次の詳細スケジュール
#### Week 1-2: Phase 1 データ基盤
**Day 1-2:**
- [ ] Prismaスキーマ変更
- [ ] マイグレーションファイル作成
- [ ] GraphQL型定義追加
**Day 3-4:**
- [ ] 開発環境でマイグレーション実行
- [ ] ユニットテスト作成
- [ ] コードレビュー
**Day 5:**
- [ ] ステージング環境へデプロイ
- [ ] 統合テスト実行
**Week 2 Monday:**
- [ ] 🚀 本番環境へマイグレーション実行
- [ ] 監視開始
**判断ポイント:**
- マイグレーション成功 → Phase 2 へ進む
- 失敗 → ロールバック、原因調査
---
#### Week 2-6: Phase 2 読み取り機能
**Week 2-3:**
- [ ] GraphQL Resolver実装
- [ ] フロントエンド対応
- [ ] E2Eテスト作成
**Week 4:**
- [ ] 🚀 カナリアリリース（10%）
- [ ] メトリクス監視
- [ ] ユーザーフィードバック収集
**Week 5:**
- [ ] 🚀 50% ロールアウト
- [ ] パフォーマンス監視
**Week 6:**
- [ ] 🚀 100% ロールアウト
- [ ] 🎯 Phase 2 完了
**判断ポイント:**
- エラー率 < 0.1% → 次へ進む
- エラー率 > 1% → ロールバック
---
[Week 7-11: Phase 3-6 の詳細スケジュール...]
---
### マイルストーン一覧
| # | マイルストーン | 完了条件 | 予定日 |
|---|---------------|---------|--------|
| 1 | データ基盤リリース | マイグレーション成功 | Week 2 |
| 2 | 読み取り機能リリース | 100%ロールアウト完了 | Week 6 |
| 3 | 手動設定リリース | 管理者が使用可能 | Week 7 |
| 4 | 自動付与リリース | 全ポイントに自動設定 | Week 9 |
| 5 | 失効通知リリース | 通知配信開始 | Week 9 |
| 6 | 自動失効リリース | 完全自動化 | Week 11 |ステップ7: チーム間の調整
各フェーズでの関係者とコミュニケーション:
## チーム間の調整
### Phase 1: データ基盤
**関係者:**
- バックエンドチーム（実装担当）
- インフラチーム（マイグレーション実行）
**コミュニケーション:**
- Week 1 Monday: キックオフミーティング
- Week 1 Friday: コードレビュー
- Week 2 Monday: 本番マイグレーション立ち会い
---
### Phase 2: 読み取り機能
**関係者:**
- バックエンドチーム
- フロントエンドチーム（iOS, Android, Web）
- QAチーム
**コミュニケーション:**
- Week 2: GraphQL API仕様の共有
- Week 3: フロントエンド実装進捗確認
- Week 4: カナリアリリース前のリハーサル
---
### Phase 3-6: 以降のフェーズ
**関係者:**
- 全開発チーム
- プロダクトオーナー
- カスタマーサポート
**コミュニケーション:**
- 週次の進捗報告
- リリース前のステークホルダーレビュー
- リリース後の振り返りステップ8: 監視とアラート
各フェーズの監視項目:
## 監視とアラート設定
### Phase 1: データ基盤
**監視項目:**
- マイグレーション実行時間
- データベース接続エラー
**アラート:**
- マイグレーション失敗時に即座通知
---
### Phase 2: 読み取り機能
**監視項目:**
- GraphQLクエリエラー率
- `wallet.expiresAt` フィールドのnull率
- レスポンスタイム（P50, P95, P99）
**アラート:**
- エラー率 > 1% で警告
- エラー率 > 5% で緊急通知（自動ロールバック検討）
---
### Phase 4: 自動付与機能
**監視項目:**
- 有効期限自動設定数（時間別）
- 設定失敗数
- 平均有効期限日数
**アラート:**
- 設定失敗率 > 1% で警告
- 平均有効期限が異常値（< 1日 or > 5年）で緊急通知
**ダッシュボード:**// Datadog / Grafana metrics.increment("wallet.expiration.autoset", { status: "success", durationdays: expirationDays });
---
### Phase 6: 自動失効機能
**監視項目:**
- 失効処理実行数
- 失効ポイント総額
- 失効ユーザー数
**アラート:**
- 失効ユーザー数 > 100/日 で警告（異常値の可能性）
- 失効処理失敗で即座緊急通知
- 失効ポイント総額 > 100万pt/日 で確認通知
**ダッシュボード:**metrics.increment("wallet.expiration.executed", { usercount: expiredUserCount, totalpoints: totalExpiredPoints });
ステップ9: ドキュメント更新計画
各フェーズでのドキュメント更新:
## ドキュメント更新計画
### Phase 1: データ基盤
**更新対象:**
- [ ] `prisma/schema.prisma` のコメント
- [ ] `docs/database/schema.md` にテーブル仕様追加
- [ ] `CHANGELOG.md` にマイグレーション記録
---
### Phase 2: 読み取り機能
**更新対象:**
- [ ] GraphQLスキーマのdescription
- [ ] `docs/api/graphql.md` にフィールド説明追加
- [ ] フロントエンド向けAPI仕様書
---
### Phase 4: 自動付与機能
**更新対象:**
- [ ] `README.md` に機能説明追加
- [ ] `docs/handbook/FEATURES.md` に詳細仕様追加
- [ ] 運用マニュアル（有効期限の設定方法）
---
### Phase 6: 自動失効機能
**更新対象:**
- [ ] ユーザー向けFAQ
- [ ] カスタマーサポート向けマニュアル
- [ ] 利用規約（ポイント有効期限に関する条項）ステップ10: デリバリープランサマリー
全体像を1ページにまとめたサマリー:
# デリバリープランサマリー
**機能名:** ポイント有効期限機能
**総工数:** 11週間
**総リスク評価:** 🟡 Medium
---
## フェーズ一覧
| Phase | 期間 | リスク | 依存関係 | ロールバック |
|-------|------|--------|----------|-------------|
| 1. データ基盤 | Week 1-2 | 🟢 Low | なし | 5分 |
| 2. 読み取り機能 | Week 2-6 | 🟢 Low | Phase 1 | 1分 |
| 3. 手動設定 | Week 3-7 | 🟡 Medium | Phase 2 | 10分 |
| 4. 自動付与 | Week 5-9 | 🟡 Medium | Phase 3 | 15分 |
| 5. 失効通知 | Week 6-9 | 🟢 Low | Phase 4 | 5分 |
| 6. 自動失効 | Week 7-11 | 🔴 High | Phase 4 | 30分〜2時間 |
---
## リスク緩和策
### 🔴 High Risk: Phase 6 自動失効
- 失効ログの記録（復元用）
- ドライラン（シミュレーション）
- 手動承認期間（1ヶ月）
- 段階的実行（100ユーザー/日から開始）
### 🟡 Medium Risk: Phase 3-4
- フィーチャーフラグによる制御
- カナリアリリース（10% → 50% → 100%）
- リアルタイム監視とアラート
---
## 成功の定義
### 技術的成功
- [ ] 全フェーズで本番エラー率 < 1%
- [ ] ロールバック実行回数: 0回
- [ ] パフォーマンス劣化: < 5%
### ビジネス的成功
- [ ] ユーザーからの苦情: < 50件（全期間）
- [ ] ポイント失効に関する問い合わせ: < 100件/月
- [ ] 機能利用率: 有効期限付きポイント > 80%
---
## 中止・延期の判断基準
以下の条件に該当する場合、次フェーズへの進行を中止:
- [ ] エラー率 > 5% が24時間継続
- [ ] Critical な障害発生
- [ ] ユーザーからの苦情 > 100件/週
- [ ] ロールバック失敗
**中止時のアクション:**
1. 即座にフィーチャーフラグOFF
2. 全ステークホルダーへの通知
3. 原因調査と対策会議
4. 再開判断（修正後に再審査）
---
## 承認
**プランレビュー担当者:**
- [ ] プロダクトオーナー
- [ ] テックリード
- [ ] インフラリード
- [ ] QAリード
**承認日:** YYYY-MM-DD活用例
例1: ポイント有効期限機能
/phased-delivery-plan "ポイント有効期限機能"生成される計画:
- 6フェーズ、11週間のデリバリープラン
- フィーチャーフラグ設定
- 各フェーズのロールバック手順
- 監視・アラート設定
例2: 複数ウォレット対応
/phased-delivery-plan docs/requirements/multi-wallet.md --with-conflicts生成される計画:
/check-requirement-deltaで検出された衝突を考慮- 破壊的変更を最小化する段階的移行
- 非推奨化期間の設定（6ヶ月）
- クライアント移行のスケジュール
注意事項
デリバリープランの原則
- ✅ 小さく始める: 最初のフェーズは最小機能
- ✅ 価値を早く届ける: 各フェーズでビジネス価値を提供
- ✅ リスクを分散: High Riskは最後のフェーズに
- ✅ ロールバック可能: 各フェーズで後戻り可能に
- ✅ 測定可能: 成功指標を明確に
よくある失敗
- ❌ 大きすぎるフェーズ: 1フェーズ > 2週間は分割検討
- ❌ 依存関係の無視: Phase N が Phase N+1 に依存
- ❌ ロールバック不可: 不可逆な変更を最初に実施
- ❌ 監視なし: メトリクスを取らずにリリース
参考資料
以下については @CLAUDE.md を参照してください:
- フィーチャーフラグの実装
- カナリアリリースの方法
- 監視・アラート設定
- ロールバック手順