launch-runbook について
ウェブサイト、製品、大規模リリースの計画と実行を支援する、技術スタックに依存しないスキルです。準備、切り替え、検証、安定化を一つのランブックにまとめ、役割、ロールバック条件、連絡計画を明確にします。
主な機能
- 014段階のローンチ計画
- 02担当者と検証を含む切り替え手順
- 03ロールバック条件と手順
- 04役割分担と連絡計画
- 05初週の安定化チェック
活用シーン
- 01部門横断の製品リリース調整
- 02ウェブサイト移行の計画
- 03反復可能なデプロイ用ランブックの準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/launch-runbookを入力して読み込まれたか確認します。
同梱ファイルREADME.mdreferences/runbook-template.md
詳細
ローンチ手順書
ウェブサイト、製品、または大規模リリースのローンチを計画し、実施します。この手順書は、ローンチ当日に全員が参照するドキュメントです。特定の技術スタックに依存しません。
このスキルはローンチイベント向けです。ローンチ前の QA には qa-testing を、ローンチ後のインシデント対応には incident-response を使用してください。
使用する場面
- 新しいウェブサイトや大規模なリデザインをローンチするとき
- 別のプラットフォームへ移行するとき
- 大規模な製品や機能をリリースするとき
- チーム横断でローンチを調整するとき
- 定期的なデプロイ向けの手順書を作成するとき
使用しない場面
- ローンチ前のテスト（
qa-testingを使用してください） - ローンチ後のインシデント対応（
incident-responseを使用してください） - ローンチ後の振り返り（
after-action-reportを使用してください）
必要な情報
- ローンチの範囲（何をローンチするか）
- ローンチの時間枠（日付、時刻、所要時間）
- チーム（役割、オンコールローテーション）
- ロールバックの基準（いつ中止するか）
- コミュニケーション計画（誰が、いつ、誰に何を伝えるか）
フレームワーク：4 つのフェーズ
ローンチには 4 つのフェーズがあります。手順書では、そのすべてを扱います。
フェーズ 1：ローンチ前（T-30 日〜T-1 時間）
ローンチの時間枠が始まる前に、すべての準備が整っていることを確認します。
T-30 日：
- 最終的な範囲を確定
- チーム横断のコミットメントを確認
- ローンチ前の QA を予定
- コミュニケーション計画の草案を作成
T-7 日：
- ローンチ前の QA を完了
- すべての重大および主要な問題を解決
- パフォーマンスのベースラインを測定
- ロールバック手順を文書化してテスト
- DNS の TTL を引き下げる（ローンチに DNS の変更が含まれる場合）
T-1 日：
- 最終的な実施可否の会議
- 役割を確認
- コミュニケーションチャネルを設定
- 現在の本番環境の状態をバックアップ
T-1 時間：
- チームが共有コミュニケーションチャネルに集合
- ツールとアクセス権を確認
- ステージング環境で最終的なスモークテストを実施
フェーズ 2：切り替え（T-0）
実際のローンチです。担当者と検証を明記した順序付きの手順を実行します。
標準的な切り替え手順：
- 社内チームに開始を告知
- メンテナンスモードを有効化（該当する場合）
- 最終的なデータベースマイグレーションを実行（該当する場合）
- 本番環境にコードをデプロイ
- エラーなくデプロイが完了したことを確認
- 本番環境でスモークテストを実施
- DNS を切り替え（該当する場合）
- DNS の伝播を確認
- メンテナンスモードを無効化
- 本番環境で完全なスモークテストを実施
- 社内チームにローンチを告知
- 監視期間を開始
各手順には、次の項目を含めます。
- 担当者
- 前提条件
- 実施内容
- 検証
- 所要時間の見積もり
- ロールバック手順
フェーズ 3：検証（T+0〜T+24 時間）
ローンチが正常な状態であることを確認します。
最初の 1 時間以内：
- 重要なユーザーフローが機能している（チェックアウト、登録、ログイン）
- エラー率が急増していない
- パフォーマンスが想定範囲内
- アナリティクスのトラッキングが作動している
- メールと通知が機能している
最初の 24 時間以内：
- 主要なビジネス指標に悪化がない
- エラーのパターンが蓄積していない
- Core Web Vitals が安定している
- Search Console に重大な問題が表示されていない（SEO が関係する場合）
フェーズ 4：安定化（T+24 時間〜T+7 日）
長期的な影響を監視します。
- 日ごとのエラー率を追跡
- 日ごとのパフォーマンスを追跡
- 主要なビジネス指標をベースラインと比較して追跡
- 特定された、リリースを阻止しない問題に対処
- AAR（アクションレビュー）の計画を立てる
役割と責任
ローンチでは、役割を明確に割り当てます。曖昧さは、ローンチが混乱する最も一般的な原因です。
| 役割 | 責任 |
|---|---|
| ローンチリード | 手順書を管理します。実施可否を判断し、ロールバックを指示します。 |
| デプロイオペレーター | 技術的なデプロイ手順を実行します。 |
| QA リード | 検証テストを実施し、各マイルストーンを確認します。 |
| コミュニケーションリード | 社内向けの最新情報を投稿し、社外向けのメッセージを管理します。 |
| オンコールエンジニア | ローンチ中およびローンチ後の問題に対応できる状態で待機します。 |
| ステークホルダー代表 | ビジネスステークホルダーを代表して承認します。 |
小規模なチームでは、1 人が複数の役割を担う場合があります。それでも、各役割の責任は明確に定めてください。
ロールバックの基準
ローンチ前に定義してください。プレッシャーがかかっている状況よりも、事前に決めておくほうが判断しやすくなります。
自動ロールバックのトリガー：
- エラー率が通常の X パーセントを超える
- 重要なユーザーフロー（定義済み）が機能しない
- データベースの整合性に問題がある
- デプロイ後にセキュリティ上の脆弱性が見つかる
任意で判断するロールバックのトリガー：
- パフォーマンスが Y パーセントを超えて低下する
- 重要なビジネス指標が大幅に低下する
- 顧客に影響するエラーパターンが発生する
決定権限： ローンチリードがロールバックを決定します。ローンチリードが対応できない場合に代理を務める担当者を、事前に決めてください。
コミュニケーション計画
内部チャネル
- 主要ローンチチャネル： ローンチチーム専用のリアルタイムチャット
- ステータスチャネル： より広い社内向けの最新情報
- 作戦室： 重大なローンチでは任意でビデオ通話を実施
ローンチ中の更新頻度
- 切り替え中は15分ごと
- 検証フェーズ中は1時間ごと
- 安定化フェーズ中は毎日
外部向けコミュニケーション
- 顧客向けのお知らせ： 事前に草案を作成し、成功が確認された時点で公開するようスケジュールします
- ステータスページ： ユーザーに影響がある場合は、先回りして更新します
- サポートチーム： ローンチ内容、よくある質問、エスカレーション先を事前に共有します
ワークフロー
- 30日前に手順書を作成します。 範囲、順序、役割、ロールバックの基準、コミュニケーション計画を定めます。
- ロールバック手順をテストします。 テストされていないロールバックは手順ではなく、期待にすぎません。
- 机上演習を実施します。 チーム全員で手順書を確認し、不足を見つけます。
- ローンチの48～72時間前にDNS TTLを短くします（ローンチにDNSの変更が含まれる場合）。
- 当日： 手順書に沿って、各手順を順番に実行します。次に進む前に、各手順を検証します。
- 監視します。 最初の1時間、最初の1日、最初の1週間にわたって監視し、特筆すべきことはすべて記録します。
- ローンチから1～2週間以内にAARを予定します。
失敗パターン
- 手順書を1人で作成し、レビューしていない。 1つの視点だけでは、さまざまな状況を見落とします。
- ロールバックをテストしていない。 必要なときになって、ロールバックが機能しないと判明します。
- 手順の説明が曖昧。 どのツール、どのコマンド、どの環境を使うのかを指定せずに「本番環境にデプロイする」と書いています。
- 各操作後の検証手順がない。 エラーが連鎖して広がります。
- コミュニケーションに抜けがある。 チームがローンチの実施を知らない、または成功したことを知らない状態になります。
- 金曜日の終業間際にローンチする。 あるいは祝日の前に実施します。対応に使える時間が短くなります。
- 予定日に間に合わせるため、ローンチ前のQAを省略する。 その結果、バグがローンチ当日に発生します。
- ローンチ疲れ。 休憩なしで長時間ローンチを続けると、エラーにつながります。複数日にわたるローンチでは、休息のサイクルを計画してください。
- 最初の24時間にオンコール担当者がいない。 誰かが連絡を受けられる状態にしておく必要があります。
出力形式
デフォルトの出力：launch-runbook-[project].md のMarkdown形式の手順書と、補助チェックリスト。
構成：
- ローンチのメタデータ（内容、日時、担当者）
- 役割と責任
- ローンチ前チェックリスト（T-30、T-7、T-1、T-1hr）
- 切り替え手順（番号付きの手順、担当者、検証）
- ロールバック手順
- ロールバックの基準（自動および任意）
- コミュニケーション計画
- 検証チェックリスト（最初の1時間、最初の1日）
- 安定化計画（最初の1週間）
- 連絡先（エスカレーション先、オンコール担当者）
参考ファイル
references/runbook-template.md- 記入式の手順書テンプレートと、切り替え手順の例です。