shipping-and-launch

出荷とローンチ

概要

自信を持って出荷しましょう。目標は単にデプロイすることではありません。モニタリングを整え、ロールバック計画を用意し、成功の定義を明確にしたうえで、安全にデプロイすることです。すべてのローンチは、取り消し可能で、観測可能かつ段階的に行える必要があります。

使用するタイミング

• 機能を初めて本番環境にデプロイするとき
• ユーザー向けに大規模な変更をリリースするとき
• データやインフラストラクチャを移行するとき
• ベータ版や早期アクセスプログラムを開始するとき
• リスクを伴うあらゆるデプロイ（すべてのデプロイが該当します）

ローンチ前チェックリスト

コード品質

• すべてのテストに合格している（ユニット、統合、e2e）
• 警告なしでビルドが成功する
• リントと型チェックに合格している
• コードレビューが完了し、承認されている
• ローンチ前に解決すべき TODO コメントが残っていない
• 本番コードに console.log によるデバッグ文がない
• 想定される障害ケースを網羅するエラー処理がある

セキュリティ

• コードやバージョン管理にシークレットが含まれていない
• エコシステムの依存関係監査（npm audit、pip-audit、cargo audit、...）で、重大または高リスクの脆弱性が検出されない
• ユーザー向けのすべてのエンドポイントで入力が検証される
• 認証と認可のチェックが実装されている
• セキュリティヘッダーが設定されている（CSP、HSTS など）
• 認証エンドポイントにレート制限が設定されている
• CORS が特定のオリジンに設定されている（ワイルドカードではない）

パフォーマンス

• Core Web Vitals が「Good」のしきい値内にある
• 重要な処理経路に N+1 クエリがない
• 画像が最適化されている（圧縮、レスポンシブなサイズ、遅延読み込み）
• バンドルサイズが予算内に収まっている
• データベースクエリに適切なインデックスが設定されている
• 静的アセットと繰り返し実行されるクエリにキャッシュが設定されている

アクセシビリティ

• すべてのインタラクティブ要素をキーボードで操作できる
• スクリーンリーダーでページのコンテンツと構造を伝えられる
• 色のコントラストが WCAG 2.1 AA を満たしている（テキストは 4.5:1）
• モーダルと動的コンテンツのフォーカス管理が適切である
• エラーメッセージが具体的で、フォームフィールドと関連付けられている
• axe-core または Lighthouse でアクセシビリティに関する警告がない

インフラストラクチャ

• 本番環境に環境変数が設定されている
• データベースのマイグレーションが適用済み（または適用準備ができている）
• DNS と SSL が設定されている
• 静的アセット用に CDN が設定されている
• ロギングとエラー報告が設定されている
• ヘルスチェック用のエンドポイントが存在し、応答する

ドキュメント

• 新たなセットアップ要件があれば、README が更新されている
• API ドキュメントが最新である
• アーキテクチャ上の決定があれば ADR が作成されている
• 変更履歴が更新されている
• ユーザー向けドキュメントが更新されている（該当する場合）

フィーチャーフラグ戦略

フィーチャーフラグを使って出荷し、デプロイとリリースを切り離しましょう。

// Feature flag check
const flags = await getFeatureFlags(userId);

if (flags.taskSharing) {
  // New feature: task sharing
  return <TaskSharingPanel task={task} />;
}

// Default: existing behavior
return null;

フィーチャーフラグのライフサイクル：

1. DEPLOY with flag OFF     → Code is in production but inactive
2. ENABLE for team/beta     → Internal testing in production environment
3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users
4. MONITOR at each stage    → Watch error rates, performance, user feedback
5. CLEAN UP                 → Remove flag and dead code path after full rollout

ルール：

• すべてのフィーチャーフラグに担当者と有効期限を設定する
• 全面的な展開から 2 週間以内にフラグを削除する
• フィーチャーフラグを入れ子にしない（組み合わせが指数関数的に増加します）
• CI でフラグの両方の状態（オンとオフ）をテストする

段階的なロールアウト

ロールアウトの順序

1. DEPLOY to staging
   └── Full test suite in staging environment
   └── Manual smoke test of critical flows

2. DEPLOY to production (feature flag OFF)
   └── Verify deployment succeeded (health check)
   └── Check error monitoring (no new errors)

3. ENABLE for team (flag ON for internal users)
   └── Team uses the feature in production
   └── 24-hour monitoring window

4. CANARY rollout (flag ON for 5% of users)
   └── Monitor error rates, latency, user behavior
   └── Compare metrics: canary vs. baseline
   └── 24-48 hour monitoring window
   └── Advance only if all thresholds pass (see table below)

5. GRADUAL increase (25% -> 50% -> 100%)
   └── Same monitoring at each step
   └── Ability to roll back to previous percentage at any point

6. FULL rollout (flag ON for all users)
   └── Monitor for 1 week
   └── Clean up feature flag

ロールアウトの判断基準

各段階で進行、保留、ロールバックのどれを選択するか、以下のしきい値を使って判断します。

指標	進行（緑）	保留して調査（黄）	ロールバック（赤）
エラー率	ベースラインの 10% 以内	ベースラインを 10～100% 上回る	ベースラインの 2 倍超
P95 レイテンシ	ベースラインの 20% 以内	ベースラインを 20～50% 上回る	ベースラインを 50% 超上回る
クライアント側の JS エラー	新しい種類のエラーがない	セッションの 0.1% 未満で新しいエラーが発生	セッションの 0.1% 超で新しいエラーが発生
ビジネス指標	変化なし、または改善	5% 未満の低下（ノイズの可能性あり）	5% 超の低下

ロールバックするタイミング

以下の場合は直ちにロールバックします。

• エラー率がベースラインの 2 倍を超えて増加した
• P95 レイテンシが 50% を超えて増加した
• ユーザーから報告される問題が急増した
• データの整合性に関する問題が検出された
• セキュリティ上の脆弱性が発見された

モニタリングと可観測性

モニタリング対象

Application metrics:
├── Error rate (total and by endpoint)
├── Response time (p50, p95, p99)
├── Request volume
├── Active users
└── Key business metrics (conversion, engagement)

Infrastructure metrics:
├── CPU and memory utilization
├── Database connection pool usage
├── Disk space
├── Network latency
└── Queue depth (if applicable)

Client metrics:
├── Core Web Vitals (LCP, INP, CLS)
├── JavaScript errors
├── API error rates from client perspective
└── Page load time

エラー報告

// Set up error boundary with reporting
class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Report to error tracking service
    reportError(error, {
      componentStack: info.componentStack,
      userId: getCurrentUser()?.id,
      page: window.location.pathname,
    });
  }

  render() {
    if (this.state.hasError) {
      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
    }
    return this.props.children;
  }
}

// Server-side error reporting
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  reportError(err, {
    method: req.method,
    url: req.url,
    userId: req.user?.id,
  });

  // Don't expose internals to users
  res.status(500).json({
    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },
  });
});

リリース後の検証

リリース後の最初の1時間に：

1. Check health endpoint returns 200
2. Check error monitoring dashboard (no new error types)
3. Check latency dashboard (no regression)
4. Test the critical user flow manually
5. Verify logs are flowing and readable
6. Confirm rollback mechanism works (dry run if possible)

エラーバジェットのリリースゲート

サービスのエラーバジェット（SLOで失敗が許容されるリクエストまたは時間の割合）によって、安全にリリースできるかどうかが決まります。交渉の材料ではなく、客観的なゲートとして使用してください。

Budget remaining > 20%  →  Ship normally; monitor closely
Budget remaining 0–20%  →  Slow rollouts only; no high-risk changes
Budget exhausted        →  Freeze feature work; focus entirely on reliability
Budget resets           →  Resume normal pace; bake in the fix that recovered it

カナリアリリース中のバーンレートが高い場合（ベースラインのペースを上回る速さで予算を消費している場合）は、上記のロールアウトしきい値テーブルにおける保留のシグナルです。エラー率の上昇と同様に扱ってください。

ロールバック戦略

すべてのデプロイには、実施前にロールバック計画が必要です。

## Rollback Plan for [Feature/Release]

### Trigger Conditions
- Error rate > 2x baseline
- P95 latency > [X]ms
- User reports of [specific issue]

### Rollback Steps
1. Disable feature flag (if applicable)
   OR
1. Deploy previous version: `git revert <commit> && git push`
2. Verify rollback: health check, error monitoring
3. Communicate: notify team of rollback

### Database Considerations
- Migration [X] has a rollback: <verified command or runbook link>
- Data inserted by new feature: [preserved / cleaned up]

### Time to Rollback
- Feature flag: < 1 minute
- Redeploy previous version: < 5 minutes
- Database rollback: < 15 minutes

関連項目

• このチェックリストの前にすべての変更がクリアする必要がある、プロジェクト全体の完了の定義については、../../references/definition-of-done.md を参照してください
• リリース前のセキュリティチェックについては、../../references/security-checklist.md を参照してください
• リリース前のパフォーマンスチェックリストについては、../../references/performance-checklist.md を参照してください
• リリース前のアクセシビリティ検証については、../../references/accessibility-checklist.md を参照してください
• アラートルールとSLOに連動したしきい値については、observability-and-instrumentation を参照してください

よくある自己正当化

自己正当化	実態
「ステージングで動くなら、本番でも動く」	本番ではデータ、トラフィックのパターン、エッジケースが異なります。デプロイ後に監視してください。
「この機能にフィーチャーフラグは必要ない」	どの機能にもキルスイッチが役立ちます。「単純な」変更でも問題を引き起こすことがあります。
「監視は余計な負担だ」	監視がなければ、ダッシュボードではなくユーザーからの苦情で問題を知ることになります。
「監視は後で追加しよう」	リリース前に追加してください。見えないものはデバッグできません。
「ロールバックは失敗を認めることだ」	ロールバックは責任あるエンジニアリングです。壊れた機能をリリースすることこそ失敗です。
「エラー率は問題なさそうだから、このままリリースしよう」	現在のエラー率だけでなく、バーンレートを確認してください。個々のしきい値がすべて正常でも、ベースラインを上回る速さで予算を消費している場合は保留のシグナルです。

危険信号

• ロールバック計画なしでデプロイする
• 本番環境に監視やエラーレポートがない
• ビッグバンリリース（すべてを一度にリリースし、段階的なリリースをしない）
• 有効期限や担当者が設定されていないフィーチャーフラグ
• 最初の1時間、デプロイを監視する人がいない
• 本番環境の設定をコードではなく記憶に頼って行う
• 「金曜日の午後だけど、リリースしよう」
• エラーバジェットを使い切っているのに、機能開発を変わらず続ける

検証

デプロイ前：

• リリース前チェックリストを完了している（すべてのセクションがグリーン）
• フィーチャーフラグを設定している（該当する場合）
• ロールバック計画を文書化している
• 監視ダッシュボードを設定している
• デプロイについてチームに通知している

デプロイ後：

• ヘルスチェックが200を返す
• エラー率が正常である
• レイテンシが正常である
• 重要なユーザーフローが動作する
• ログが流れている
• ロールバックをテスト済み、またはすぐに実行できることを確認済み

リリースするすべてのサービスについて：

• エラーバジェットポリシーを整備している：予算が20%を下回ったとき、または使い切ったときに取るべきアクションを把握している