production-readiness

本番運用の準備状況

複数の領域にまたがる証拠をまとめ、リリース可否を判断します。このスキルでは、リスク区分ごとに必要最小限の本番運用に関する証拠パケットを定義し、各証拠カテゴリを名前付きの情報源または証拠不足の明示的な判定に対応付け、責任者を明確にした4種類のリリース判断のいずれかを提示します。リリースチェックリストを重複して作成したり、普遍的なリスクスコアを算出したりはせず、詳細なチェックは既存の専門スキルに引き継ぎます。

読み込むタイミング

次のいずれかに該当する場合に読み込みます。

• サービス、機能、または変更がリリース判断に近づいており、本番運用の準備状況をレビューする必要がある場合。
• 複数の領域（オーナーシップ、SLO、セキュリティ、データ、サポート、コスト、オブザーバビリティ）からの証拠を、レビュー可能な1つの記録にまとめる必要がある場合。
• リリース審査会、準備状況ゲート、または責任者が、構造化されたリリース可／不可／延期／例外の推奨を必要としている場合。
• 移行に依存するリリースで、すべての依存関係が準備できていることを示す証拠が必要な場合。
• リスクの低いドキュメントのみの変更について、（全面的ではなく）相応の準備状況レビューが必要な場合。

使用しない場合

• リリースパイプラインの仕組み — 昇格、カナリアステージ、CI/CDゲートの設定、バージョン管理、アーティファクト管理。release-engineering に引き継ぎます。release-engineering はパイプラインゲートを担当し、production-readiness は複数領域にまたがる証拠の取りまとめとリリース判断を担当します。
• インシデント対応、SLO運用、オンコール、信頼性エンジニアリング。 site-reliability-engineering に引き継ぎます。SRE は稼働中サービスの健全性の境界を担当し、production-readiness はリリース前の準備状況の境界を担当します。
• セキュリティの実装、脅威モデリング、または侵入テスト。 secure-software-engineering または security-audit-methodology に引き継ぎます。
• データパイプラインの運用、スキーマ移行エンジニアリング、またはETL/ELTの設計。 data-engineering に引き継ぎます。
• テスト戦略、回帰計画、品質ゲート。 qa-methodology に引き継ぎます。
• プラットフォームインフラストラクチャのプロビジョニング、またはIDPの設計。 platform-engineering に引き継ぎます。
• 実装計画、作業分解、またはデリバリー調整。 implementation-planning に引き継ぎます。
• 仕様書の作成とSDDゲートの仕組み。 spec-driven-development に引き継ぎます。
• 明示的な基準に基づく検証判定。 verification-methodology に引き継ぎます。
• API契約の設計とバージョニングポリシー。 api-design-and-evolution に引き継ぎます。
• 統計分析、実験設計、または因果推論。 data-scientist に引き継ぎます。
• すべての準備状況の側面にわたる、本番運用ライフサイクルのエンドツーエンドのオーケストレーション。 production-excellence バンドルに引き継ぎます（文章内での参照のみで、まだ追加されていません）。production-excellence は、production-readiness、migration-engineering、resilience-and-recovery、capacity-and-cost-engineering、incident-learning を組み合わせ、本番運用のライフサイクル全体を扱います。

リスククラスとエビデンスの拡張度

本番稼働準備のエビデンスパケットは、リスククラスに応じて規模が変わります。低リスクのドキュメントリリースに、ユーザー向けサービスのローンチと同じエビデンスを求めてはなりません。

リスククラス	該当条件	必要なエビデンスカテゴリ	レビューの深さ
低	ドキュメントのみの変更、README の更新、機能に影響しない設定コメント、1 チーム以下に影響する内部ツール、バックエンドを変更しないコンテンツのみのウェブサイト変更	オーナーシップ、ユーザー／ビジネス成果（1 行の説明）、ロールバック（コミットをリバート）	セルフレビュー、簡易記録
標準	ユーザー向け機能、複数のチームが利用する内部サービス、API の追加、後方互換性のあるデータスキーマ変更、SLO を変更しないパフォーマンス改善	11 カテゴリすべて（以下のチェックリストを参照）。エビデンスが不足している場合は、担当者と日付を明記したギャップ注記が必要です	ピアレビュー、完全な本番稼働準備記録
高	顧客向けサービスのローンチ、SLO に関わる変更、認証／認可の変更、不可逆なデータ移行、決済／請求の経路、コンプライアンス対象の変更、信頼境界を越える変更	11 カテゴリすべてについて、各カテゴリに名前が明記された情報源のエビデンスが必要です。すべてのギャップには、人間の承認者による免除が必要です	正式なレビュー。例外には、自動チェックとは区別できる人間による承認注記が必要です

リスククラスは、平均やスコアではなく、該当する最も高いリスクの側面によって決まります。データ移行の不可逆性や信頼境界を越えることなど、いずれか 1 つの側面が「高」に該当する場合、レビュー全体が「高」になります。

本番エビデンスチェックリスト

11 のエビデンスカテゴリが、本番エビデンスパケットの最低要件です。各カテゴリには、名前が明記されたソース成果物、またはエビデンスが欠落していることを明示した結果のいずれかが必要です。

#	エビデンスカテゴリ	ソース／エビデンス	ギャップ／不足
1	オーナーシップ	source: チーム名、オンコールローテーション、エスカレーション経路、またはサービスカタログのエントリ	missing: "オーナー未特定 — が対応予定、期限 "
2	ユーザー／ビジネス成果	source: 成功指標、OKR リンク、または測定可能な目標を含むプロダクト概要	missing: "成果が未定義 — プロダクトオーナーが対応予定、期限 "
3	依存関係	source: 依存関係マップ、ヘルスチェック結果、または上流の SLO ステータス	missing: "依存関係マップが未完成 — が対応予定、期限 "
4	SLO	source: SLO 宣言、エラーバジェットポリシー、または SLO ダッシュボードへのリンク	missing: "SLO が未宣言 — SRE が対応予定、期限 "
5	オブザーバビリティ	source: ダッシュボードへのリンク、アラートルール、ログ／監視のカバレッジ、またはゴールデンシグナルのレポート	missing: "オブザーバビリティにギャップあり — が対応予定、期限 "
6	サポート	source: ランブック、サポートプレイブック、エスカレーションマトリクス、またはサポート引き継ぎドキュメント	missing: "ランブックなし — が対応予定、期限 "
7	セキュリティ	source: セキュリティレビュー記録、脅威モデルの概要、またはセキュリティ承認のサインオフ	missing: "セキュリティレビュー未完了 — セキュリティチームが対応予定、期限 "
8	データ	source: データ分類記録、保持／削除ポリシー、バックアップ／復元テストのエビデンス、または移行テストの結果	missing: "データ分類を入手できない — データオーナーが対応予定、期限 "
9	ロールバック	source: リハーサル記録を含むロールバックランブック、または復旧時間の見積もりを含むリバート計画	missing: "ロールバック計画なし — が対応予定、期限 "
10	キャパシティ	source: キャパシティモデル、負荷テストレポート、クォータ／上限のレビュー、またはコスト予測	missing: "キャパシティモデル未作成 — が対応予定、期限 "
11	コスト	source: コスト見積もり、予算承認、またはコスト帰属記録	missing: "コスト見積もりを入手できない — 財務担当オーナーが対応予定、期限 "

構造化フィールド（必須）

次の4つのカテゴリは、構造化フィールド（チェックリストのマーカー、 表の行、またはラベル付きフォームフィールド）として記載する必要があります。 説明文だけで記載してはいけません。

• 所有権 — 名前が明記された担当者または担当チームとエスカレーション経路。上記のエビデンスチェックリストに記録します。
• ロールバック — リハーサルのエビデンスを含むロールバック計画または復旧経路。上記のエビデンスチェックリストに記録します。
• サポート — 運用手順書、サポートプレイブック、または引き継ぎドキュメント。上記のエビデンスチェックリストに記録します。
• 可観測性 — ダッシュボード、アラートルール、監視範囲。上記のエビデンスチェックリストに記録します。

リリース可否の判断結果

すべての準備状況レビューでは、必ず次の4つの結果のいずれか1つが出されます。責任者は 判断とともに記録します。

結果	意味	必須のエビデンス	責任者
Go	承認済み — リリースを進めます	リスククラスに応じたすべてのエビデンスカテゴリが、名前を明記した情報源によって満たされていること。未解決のギャップがないこと	名前が明記されたリリース承認者（例：サービスオーナー、リリースレビュー議長）
No-go	ブロック — リリースしません	ブロック要因となるギャップが少なくとも1つあり、欠落しているエビデンス項目が明記されていること。そのギャップがリスククラスに照らして重大であること	名前が明記されたリリース承認者
Defer	延期 — 条件が満たされた後に再レビューします	延期するギャップについて、担当者と期限が記録されていること。延期理由が明示されていること	名前が明記されたリリース承認者 + ギャップの担当者
Exception	免除付きで承認 — 未解決のギャップがある状態でリリースします	該当するギャップが明記されていること。名前が明記された人間の承認者が例外を明示的に許可すること。例外の注記は自動チェックとは区別され、自分自身には付与できないこと	名前が明記された人間の承認者（自動レビューとは別の人物）

例外の結果には、人間による明示的な承認の注記が必要です。免除を承認する 個人の名前を明記します。この承認は自動チェックの結果とは別のものであり、 別途記録する必要があります（例：エスカレーション記録または例外ログ）。 申請者自身が例外を付与することはできません。

ワークフロー

1. リスククラスを決定します。 変更内容を上記のトリガー条件の表と照合し、 Low、Standard、High のいずれかを選択します。
2. エビデンスを収集します。 11のカテゴリそれぞれについて、名前が明記された情報源、または 担当者と期限を記載したギャップを記録します。準備状況記録のテンプレートを使用します。
3. 完全性を評価します。 すべてのカテゴリに項目があることを確認します。ギャップの注記がある カテゴリは、レビューに必要な項目が記載されており、ギャップが可視化されているため、完了とみなします。
4. リリース可否を判断します。 エビデンスをリスククラスの要件と照合し、 Go、No-go、Defer、Exception のいずれかを選択します。
5. 判断を記録します。 責任者とともに準備状況記録をコミットします。 例外の場合は、人間による明示的な承認の注記も記録します。

万能なリスクスコアはありません

このスキルでは、万能なリスクスコア、総合的なリスク評価、またはリスクの総数値は 算出しません。各エビデンス項目はそれぞれ独立しており、リスククラスの要件と個別に照合して評価します。 個々の項目を別々に評価する場合（例：セキュリティ項目の評価やデータ項目の評価）は、 重み付けの根拠をその項目のエビデンス記録に明示します。準備状況を要約する単一の数値はありません。

ファイル一覧

パス	読み込まれるタイミング
references/discovery-brief.md	本番運用およびエンジニアリングの関連スキルとの所有権境界を理解するとき
references/readiness-record.md	準備状況記録のテンプレートに記入するとき、または提出された記録をレビューするとき

ルート先一覧

必要な内容	ルート先
リリースのプロモーション、カナリア段階、CI/CD ゲート、バージョン管理	release-engineering
ライブサービスの SLO、インシデント対応、オンコール、エラーバジェット	site-reliability-engineering
セキュリティ要件、脅威モデリング、安全なデフォルト設定	secure-software-engineering
データパイプライン、スキーマ移行、ETL/ELT	data-engineering
テスト戦略、回帰テスト計画、品質ゲート	qa-methodology
プラットフォームインフラストラクチャ、IDP、サービスネットワーキング	platform-engineering
作業の分解、依存関係のマッピング、ロールアウトの順序付け	implementation-planning
仕様の作成、受け入れ基準、SDD のフェーズゲート	spec-driven-development
明示された基準に対する検証結果	verification-methodology
API コントラクトの設計とバージョン管理	api-design-and-evolution
統計分析、実験計画	data-scientist
本番運用ライフサイクル全体	production-excellence バンドル（文章による参照 — production-readiness、migration-engineering、resilience-and-recovery、capacity-and-cost-engineering、incident-learning を組み合わせる将来のバンドルへのルート）