受入基準とリリース準備チェックリスト：ストーリーの準備からGO/NO-GO判断まで

このガイドは、プロダクトオーナー、エンジニアリングリード、および外部委託開発の調達担当者を対象に、自信だけに頼らないリリース判断を行うために作成されています。ソフトウェア品質ガバナンスガイドでは品質の責任者とゲートがベンダー関係にどう組み込まれるかを説明しています。このページでは、各項目ごとに実用的なチェックリストを提供します。

このガイドの内容

• 2つのチェックリスト、2つのタイミング
• チェックリスト1：ストーリーはビルドの準備ができているか？
• ストーリータイプ別の基準パターン
• チェックリスト2：リリースは本番公開の準備ができているか？
• リスクに応じたゲートのサイズ設定
• NGトリガー
• GO/NO-GO判断を実施する
• 受入とリリース作業におけるAI
• 代替手段：リリースのゲート方法
• Netbase JSCにおける受入とリリース準備の進め方
• 存在するデリバリー記録と存在しないもの
• このガイドの限界
• よくある質問
• 次のステップ

2つのチェックリスト、2つのタイミング

受入基準はストーリーのビルド前に合意されます。リリース準備はビルド後、出荷可能な候補に対して判断されます。両者を混同すると、最終週になって「完了」の定義が誰にも書かれていなかったことが発覚します。前者をバックログに、後者をリリース記録に保管し、最初のチェックリストが2番目に活きるようにしましょう。合格したすべての受入基準がリリース証拠の1行になります。

チェックリスト1：ストーリーはビルドの準備ができているか？

スクラムガイドでは、完了の定義を満たさない成果物はインクリメントに含められず、リファインメントによって項目をより小さく明確に分解するとされています。ストーリーがビルドの準備完了となる条件は以下の通りです：

• 成果が観察可能であること。 計画会議に参加していないテスターが、画面・データ・ログの表示から合否を判断できる。
• 制限が明記されていること。 ファイルサイズ、件数、必要なレスポンスタイム、対応ブラウザとデバイス、操作が許可されているロール。
• 失敗ケースが記述されていること。 無効な入力、タイムアウト、ダブルクリック、セッション切れ、決済拒否時の動作。
• テストデータが特定されていること。 テストに必要なロール、レコード、エッジケースがテスト環境に存在する。
• 非機能要件が添付されていること。 アクセシビリティ、パフォーマンス、セキュリティの要件が基準または共通の完了定義に含まれている。
• 依存関係が把握されていること。 ストーリーが待つ他のチーム、システム、決定事項が担当者とともにリストアップされている。
• サイズが1イテレーションに収まること。 基準が1ページ分のテキストになる場合は、ストーリーを分割する。
• プロダクトオーナーが文言を承認していること。 承認はストーリーがスプリントに入る前に行われ、テスト中ではない。

ストーリータイプ別の基準パターン

各基準はgiven・when・thenの形式で記述し、上の表はテンプレートを埋めるためではなくヒントとして活用してください。重要なのは、コードが存在する前に失敗ケースが記述されていることです。

チェックリスト2：リリースは本番公開の準備ができているか？

Googleのローンチコーディネーションチェックリストは自社サービス向けに作成されたもので、アーキテクチャ、キャパシティ、障害モード、モニタリング、セキュリティ、ロールアウト計画をカバーしています。同じ観点は多くのプロダクトに適用でき、いずれも開示可能な証拠が必要です：

• スコープ。 リリースノートには含まれるストーリーと担当者付きの既知の問題が記載されている。
• 機能品質。 受入テストとリグレッションスイートがリリース候補で合格しており、作成者以外の者によって確認されている。
• セキュリティ。 スキャンが実施され、指摘事項が確認され、すべての未解決指摘に受け入れた担当者が明記されている。
• パフォーマンス。 主要なユーザージャーニーが基準で合意した上限に対して計測されている。
• データと移行。 各マイグレーションが実データに近い形のコピーでリハーサルされ、変更前にバックアップが取得されている。
• ロールバック。 ロールバックがテストされているか、フィーチャーフラグによってデプロイなしで変更をオフにできる。
• 運用。 モニタリングとアラートが新しい動作をカバーし、ランブックが更新され、サポートが変更内容を把握している。
• 依存関係と設定。 環境設定、サードパーティキー、スケジュールジョブがテスト環境と本番環境で一致している。
• コミュニケーション。 ユーザーが変更に気づく箇所で、顧客への通知、ヘルプページ、社内アナウンスが準備されている。
• 決定記録。 誰が、いつ、どの証拠に基づいて決定し、どのリスクを受け入れたかが記録されている。

リスクに応じたゲートのサイズ設定

すべてのリリースがすべての項目を必要とするわけではありません。3段階のティアにより、チェックリストは無視されることなく機能し続けます：

• ルーティン変更。 小さな修正は自動化された証拠で合格します：テストグリーン、レビュー完了、再デプロイによるロールバック。
• 標準リリース。 上記のフルリストを証拠とともにリリース記録に添付します。
• 高リスクリリース。 データ移行、決済、権限、または多くの顧客が目にする変更。本番に近い環境でのリハーサル、段階的ロールアウト、リリース後に監視する担当者を追加します。

NGトリガー

締め切りのプレッシャー下で誰も交渉できないよう、会議前に合意しておきましょう：

• 受入基準が失敗しているか、テストが存在しない。
• クリティカルまたは高いセキュリティ上の指摘が、担当者の受け入れなしに未解決のまま。
• オフにできない変更に対してテスト済みのロールバックが存在しない。
• マイグレーションのリハーサルが実施されていない。
• モニタリングで新しい動作が機能しているかを確認できない。
• 承認すべき担当者が不在か、証拠を確認していない。

代替手段：リリースのゲート方法

4つの基準で選択します：リリース頻度、顧客への失敗コスト、既に自動化されている証拠の割合、そして契約上の承認責任者。多くのチームは最初の2〜3行を組み合わせます。

Netbase JSCにおける受入とリリース準備の進め方

Netbase JSCはデリバリーの中に品質保証を組み込んでいます：プロダクトオーナーと共に記述する受入基準、自動化されたリグレッション、パフォーマンスバジェット、リリース準備ゲートは、品質エンジニアリングとテストサービスで説明しています。デリバリーは、週次レビュー、KPIダッシュボード、専任のアカウントおよびプロジェクトマネージャーによって管理され、アナリスト・開発者・QA・デザイナーを組み合わせた3〜30名のチームで行われます。セキュリティプラクティスには、セキュアコードレビュー、脆弱性スキャン、ペネトレーションテストが含まれます。Netbase JSCの認定情報はNetbase JSCの働き方に関するものであり、顧客のプロダクトに関するものではありません。コミュニケーションは英語で行われ、サポートは月曜から土曜（日曜は休み）です。Netbase JSCのプロジェクトの多くはディスカバリー後に合意された請負契約で納品されており、記述された受入基準がスコープの基礎となります。詳しくはラボ型開発 vs 請負をご覧ください。リリース証拠と並べるベンダーのセキュリティ回答についてはソフトウェア開発パートナーへのセキュリティ質問をご参照ください。SaaS MVPロードマップには初回リリースのローンチ準備リストが掲載されています。

存在するデリバリー記録と存在しないもの

• 存在するもの。 UStickerとPrintLeoの記録には、パフォーマンスと安定性の改善を伴うコマース作業が記載されており、Netbase JSCの公開されたガバナンスモデルには週次レビューとクライアントダッシュボードが含まれています。
• 存在しないもの。 Netbase JSCの記録には不具合率、リリース頻度、ロールバック件数、またはリリースゲートの結果を公開したものはなく、いずれのケースも特定のチェックリストが失敗を防ぐことの証拠として提示されていません。ここに掲載するチェックリストは一般的な実践であり、実績ではありません。

このガイドの限界

• リストは出発点です。規制対象プロダクトには変更記録や監査証跡などの独自の承認が追加されますので、専門家のアドバイスを求めてください。
• DORAの変更失敗率（即時対応が必要なデプロイの割合）などの指標は、ゲートが機能しているかを時系列で示します。これらはチェック項目ではなく、成果指標です。
• チェックリストは証拠を記録するものです。弱いテストスイートを強くすることはできません。

次のステップ

最近のリリース、その受入基準、承認者をお知らせいただければ、ソリューションレビューを予約して両チェックリストをチームに合わせて適応します。リリースがこのゲートを通過したら、エンジニアリングデリバリーの健全性計測でリリース間に監視すべき継続的な指標をご確認ください。品質エンジニアリングとテストやNetbase JSCのインサイトもご覧いただけます。

関連サービスとソリューション