launch-readiness

ローンチ準備状況スキル

すべての機能にわたって準備状況を体系的に確認し、明確な根拠に基づく実施可否の推奨を提示することで、ローンチ前の見落としを防ぎます。

必要な入力情報

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

• ローンチ名と目標日
• ローンチのティア（Tier 1 = 大規模ローンチ / Tier 2 = 重要な機能 / Tier 3 = 段階的な更新）
• 完了済みのチェックリスト項目または自己評価（一部でも問題ありません。未対応の項目を洗い出します）
• チーム名と役割名（ブロッカーの担当者を割り当てるため）

機能別の準備状況チェックリスト

プロダクトとエンジニアリング

• ローンチ仕様に対して機能が完成している
• パフォーマンスのベンチマークを達成している
• アクセシビリティ基準を確認している
• エッジケースを文書化し、対処している
• ロールバック計画を策定し、テストしている

マーケティングと広報

• ローンチのメッセージングが承認されている
• ブログ記事 / プレスリリースの草稿が作成されている
• ソーシャルコンテンツが準備されている
• メールキャンペーンが予定されている
• ランディングページが公開され、テストされている

サポートとカスタマーサクセス

• サポートチームが新機能についてトレーニングを受けている
• FAQとヘルプドキュメントが公開されている
• ローンチに関する問題のエスカレーション経路が定義されている
• カスタマーサクセスチームに説明済みである（エンタープライズの場合）

営業とパートナーシップ

• 営業支援資料が準備されている
• 価格が確定し、関係者に伝達されている
• パートナーへの連絡が送信されている（該当する場合）

データとアナリティクス

• トラッキングイベントが実装され、検証されている
• ローンチ指標のダッシュボードが公開されている
• ローンチ前のベースライン指標が取得されている

プロセス

1. 提供されたローンチ概要とチェックリストへの回答を確認します
2. 未完了の項目をブロッカー（必ず解決）またはリスク（監視）として指摘します
3. 全体的な準備状況を評価し、根拠とともに実施可否の推奨を提示します
4. 実施不可の場合は、完了が必要な項目と期限を具体的に示します
5. 検証 — すべてのブロッカーに担当者と解決期限が明記されていること、またロールバック計画が文書化されているだけでなくテスト済みであることを確認します

出力形式

ローンチ準備状況の評価：[機能 / プロダクト名]

ローンチ日： [日付] ローンチのティア： [1 / 2 / 3] 全体ステータス： ✅ 実施可 / ⚠️ 条件付きで実施可 / 🛑 実施不可

ブロッカー（ローンチ前に解決必須）：

• [項目 + 担当者 + 解決期限]

リスク（注意深く監視）：

• [項目 + 緩和計画]

準備完了の領域：

• [機能]：✅ 準備完了

推奨事項： [根拠を示した明確な実施可否の判断 — 3～5文]

品質チェック

• すべてのブロッカーに具体的な担当者が割り当てられている（「チーム」ではなく）、かつ期限が設定されている
• ロールバック計画は、文書化されているだけでなく、明確にテストされている
• アナリティクスイベントは実装されているだけでなく、ステージング環境で検証されている
• Go/No-Go の決定者が明記され、決定期限が設定されている
• ローンチ後の監視チェックが少なくとも1件予定されている（例：T+2時間、T+24時間）

アンチパターン

• 根拠なしに機能を「準備完了」としてはいけません — 緑のステータスは、推測ではなく完了済みのチェックリスト項目に裏付けられている必要があります
• 満たすべき条件と期限を具体的に示さずに条件付きで実施可としてはいけません — 曖昧な条件は条件とは言えません
• ステージング環境でテストされておらず、文書化されているだけの場合は、ロールバック計画を完了済みとして扱ってはいけません
• ブロッカーを「チーム」に割り当ててはいけません — ローンチ前に解決できるよう、すべてのブロッカーに単独の担当者を明記する必要があります
• アナリティクスの検証手順を省略してはいけません — トラッキングイベントが未検証の場合、ローンチの状況を把握できず、評価もできません