product-launch-checklist

製品ローンチチェックリストスキル

すべてを確認せずにローンチしてはいけません。ローンチ前の準備、ローンチ当日の実行、ローンチ後のモニタリングを網羅し、担当者を割り当てた完全なチェックリストを作成します。

アクションを提案します

チェックリストが承認されると、実行できます。項目をaction-runnerに渡すと、接続されたアクション MCP（GitHub／Linear／Slack）を通じて、プレビュー（ドライラン、リスク評価付き）したうえで、承認されたものだけを実行し、実行内容をbrainに記録します。通常は、指定されたリポジトリ／プロジェクトでチェックリストの項目ごとに課題を作成（🟡）し、ローンチ概要をSlackに投稿（🔴 — 個別に承認）します。このスキルは提案を行い、action-runnerが承認を確認して実行します。黙って実行することはありません。

必要な入力

以下の情報が提供されていない場合は、ユーザーに尋ねてください。

• ローンチ名と予定日
• ローンチのティア（1 = 大規模な製品ローンチ、2 = 重要な機能リリース、3 = 段階的な更新）
• チームメンバーとその役割（エンジニアリングリード、PM、マーケティング、サポートなど）
• 機能の説明（ローンチするもの）
• ロールバック機能（機能フラグで制御できるか、すぐに元に戻せるか）

Brainから読み取り／Brainに書き込み

professional-brain（brain/）がある場合は、質問する前に使用してください。

• 先に読み取る: ローンチ対象のentities/の機能と、関連するdecisions/（スコープ、日付、担当者）。
• 後で書き込む: ローンチの決定事項と担当者をdecisions/に記録します。このスキルはチェックリストをaction-runnerに渡してチケットを作成することもでき、実際に行われたことをBrainに記録して一連の流れを完結させます。

このスキルの使い方

以下を指定してください。

• ローンチ名と日付
• ローンチのティア（1 = 大規模、2 = 機能、3 = 段階的）
• チームメンバーとその役割

このスキルは、ティアに応じたチェックリストを作成します。ティア3のローンチでは「必須項目」セクションのみを使用します。ティア2では「マーケティングと広報」を追加します。ティア1ではすべてのセクションを使用します。

---

出力形式

ローンチチェックリスト — [Feature/Product Name] — 目標日: [Date]

ローンチティア: [1 / 2 / 3] ローンチ責任者: [PM Name] エンジニアリングリード: [Name] Go／No-Goの決定日時: [Date and time — typically 24 hours before launch]

---

🔧 ローンチ前 — エンジニアリングとプロダクト（T-2週間）

• 機能フラグを作成し、ステージング環境でテスト済み
• すべての受け入れ基準をPMが承認済み
• コードレビューを完了し、mainにマージ済み
• QA承認を完了（リグレッションテスト＋新機能テスト）
• パフォーマンステストを完了（負荷、レイテンシ）
• セキュリティレビューを完了（データまたは認証に変更がある場合）
• ロールバック手順を文書化し、テスト済み
• モニタリングとアラートを設定済み
• 適切な重大度レベルでエラーログを記録
• 本番環境と同等のデータ量を使って、ステージング環境でデータベース移行をテスト済み

📢 ローンチ前 — マーケティングと広報（T-1週間）

• ブログ記事を作成し、レビューを完了して公開予約済み
• アプリ内告知またはツールチップを設定済み
• メールキャンペーンを作成し、QAを完了
• ソーシャルメディア投稿を作成し、公開予約済み
• ランディングページまたは機能紹介ページをステージング環境で公開済み
• メディアへのアプローチを実施（ティア1のみ）
• Product Hunt／コミュニティへの投稿を準備済み（ティア1のみ）

🎓 ローンチ前 — 営業とサポート（T-1週間）

• 営業向けイネーブルメント資料（1ページ）を完成
• FAQドキュメントを営業チームとサポートチームに共有済み
• ヘルプセンターの記事を作成し、公開済み
• サポートチーム向けのデモ／トレーニングを完了
• カスタマーサクセスチームに主要アカウントについて共有済み
• 価格を更新（該当する場合）
• 契約書／利用規約を更新（該当する場合）

📊 ローンチ前 — アナリティクス（T-1週間）

• ステージング環境でアナリティクスイベントが正しく発火することを確認済み
• ローンチ指標用のダッシュボードを設定済み
• ベースライン指標を文書化済み
• 成功基準を文書化し、チームに共有済み
• A/Bテストを設定（該当する場合）

---

✅ GO / NO-GO の判断 — T-24 時間

条件	ステータス	担当者
重大なバグがすべて解決済み	🟢 / 🔴	Eng Lead
QA 承認が完了	🟢 / 🔴	QA
ロールバックのテスト済み	🟢 / 🔴	Eng Lead
ヘルプセンターの記事が公開済み	🟢 / 🔴	Support
モニタリングが有効	🟢 / 🔴	Eng Lead
PM 承認	🟢 / 🔴	PM

Go / No-Go の判断： [GO / NO-GO] 判断責任者： [PM + Eng Lead が共同で担当]

---

🚀 ローンチ当日

• [X%] のユーザーにフィーチャーフラグを有効化（低い割合から開始 — 5～10%）
• チームの Slack／チャンネルでローンチを確認
• メトリクスダッシュボードを開き、モニタリングを開始
• T+15 分、T+1 時間、T+4 時間にエラー率を確認
• ブログ記事を公開／メールを送信
• ソーシャル投稿を公開
• 最初の 4 時間はサポートチームが待機
• PM は終日対応可能な状態にする
• T+2 時間の確認を通過した場合、フィーチャーフラグを 50% に拡大
• T+4 時間の確認を通過した場合、フィーチャーフラグを 100% に拡大

---

📈 ローンチ後（D+7、D+30）

• D+7 のメトリクスレビュー：導入率、エラー、サポートチケット
• D+7 の顧客フィードバックを統合
• 振り返りを予定に設定
• 学びを文書化
• D+30 に目標に対する成功指標をレビュー
• コードベースからフィーチャーフラグを削除（クリーンアップ）
• フィードバックに基づき、フォローアップ機能をバックログに追加

---

品質チェック

• チェックリストを作成する前にローンチのティアを確定する（範囲によって必要な詳細度が決まります）
• Go/No-Go の判断に、明確な責任者と具体的な判断時刻を設定する
• ロールバック手順を文書化し、テストする（計画するだけでは不十分です）
• フィーチャーフラグの拡大は段階的に行う（5% → 50% → 100%）。一度に全ユーザーへ展開しない
• ローンチ時にローンチ後の振り返りを予定に設定する

アンチパターン

• 段階的な更新に Tier 1 のチェックリストを適用しない — チェックリストを作成する前に、ローンチに適したティアを設定する
• 週末のエンジニアリング対応体制を確認せずに、金曜日にローンチしない
• Go/No-Go の判断責任者を「チーム」のままにしない — 個人名を指定する必要があります
• Tier 1 および 2 のローンチでロールバック計画を省略しない — 公開前に復旧所要時間を把握する
• ローンチ後の振り返りを予定に設定せずにローンチを完了しない — ローンチ後ではなく、ローンチ時に予定を確保する必要があります

ガイドライン

• Go/No-Go の判断には、明確な責任者を指定する必要があります。「チーム」は責任者ではありません
• 週末のエンジニアリング対応体制がない限り、金曜日にローンチしないでください
• 簡単な機能でも、すべてのローンチでトラフィックの 10% 未満から開始することを推奨します
• ロールバック所要時間を文書化してください。「X 分で元に戻せる」ことをローンチ前に把握しておく必要があります