deliver-launch-checklist

リリースチェックリスト

リリースチェックリストは、機能や製品のリリース前に、すべての機能が準備できていることを確認する包括的な検証ドキュメントです。エンジニアリング、QA、デザイン、マーケティング、サポート、法務、運用の各チーム間で連携し、リリース当日の予期せぬ事態を防ぎます。優れたリリースチェックリストは、ブロッカーを早期に明らかにし、リリース準備に対する共通の責任意識を生み出します。

使用するタイミング

• 重要なリリースの1〜2週間前
• リリース計画のキックオフミーティング中
• 部門横断のリリースを調整するとき
• メジャーバージョンのリリースや機能のロールアウトの前
• リリースプロセスを改善するために、インシデント発生後

使用しないタイミング

• 実験を通じてリリースすべきかどうかを検証する場合 → measure-experiment-design を使用
• リリース内容を顧客向けに告知する必要がある場合 → deliver-release-notes を使用
• リリースがすでに完了しており、結果の確認や振り返りを行いたい場合 → measure-experiment-results または iterate-retrospective を使用
• 部門横断の影響がない、小規模で単一チーム内の変更の場合：リリースチェックリストを作成しても価値がなく、手続きが増えるだけです。代わりにスプリント内で管理してください

手順

リリースチェックリストの作成を依頼された場合は、次の手順に従ってください。

1. リリースの背景を定義する 何を、いつリリースするのか、主要な関係者は誰かを記録します。チェックリストの範囲に影響するため、リリースの区分（メジャーリリース、マイナー機能、実験）を明確にします。

2. 各機能領域の要件を集める エンジニアリング、QA、マーケティングなど、各機能領域について、リリース前に完了、検証、または準備が必要な事項を特定します。ブロッカー（必須事項）と、あると望ましい事項を区別します。

3. 担当者と日付を割り当てる すべてのチェック項目に担当者と目標完了日が必要です。担当者を決めることで責任の所在が明確になり、日付を設定することで進捗を追跡できます。

4. 依存関係とブロッカーを特定する 他の作業を妨げている項目や、外部要因によって妨げられている項目に印を付けます。チームが早期にブロッカーを解消できるよう、これらを早めに明らかにします。

5. Go／No-Go の基準を定義する リリースを判断するための明確な基準を定めます。どのような条件を満たす必要があるのか、最終判断を誰が下すのかを明確にします。

6. ロールバック計画を記録する すべてのリリースにロールバック戦略が必要です。リリース後に重大な問題が発生した場合の復旧方法を記録します。

7. 進捗確認の頻度を決める チームがいつチェックリストの進捗を確認するかを定めます（日次スタンドアップ、リリース2日前のレビュー、リリース当日の同期など）。

出力形式

references/TEMPLATE.md のテンプレートを使用して出力を構成してください。完全なチェックリストでは、テンプレートのすべてのセクションを記入します：リリース概要、エンジニアリングの準備状況、QA とテスト、デザインと UX、マーケティングとコミュニケーション、カスタマーサポート、法務とコンプライアンス、運用とインフラストラクチャ、分析とモニタリング、Go／No-Go の基準、ロールバック計画、進捗確認スケジュール、未解決の課題。

品質チェックリスト

最終版を作成する前に、次の点を確認してください。

• すべての機能領域が含まれている
• すべての項目に担当者と目標日が設定されている
• ブロッカーと、あると望ましい事項が明確に区別されている
• Go／No-Go の基準が具体的で測定可能である
• ロールバック計画が記録され、テストされている
• 進捗確認の頻度が設定されている

例

記入済みの例については、references/EXAMPLE.md を参照してください。