アクセプタンス基準とリリース判定チェックリスト：ストーリー準備からリリース判断まで

このガイドは、プロダクトオーナー、エンジニアリングリード、およびアウトソース開発の購買担当者を対象としており、リリース可否の判断を根拠のある証拠に基づいて行いたい方のためのものです。ソフトウェア品質ガバナンスガイドでは品質の責任者とゲートがベンダー関係にどう組み込まれるかを説明しています。このページでは、チェックリストの各項目を具体的に解説します。

このガイドの内容

• 2つのチェックリスト、2つのタイミング
• チェックリスト1：ストーリーはビルドの準備ができているか？
• ストーリータイプ別の基準パターン
• チェックリスト2：リリースは本番公開の準備ができているか？
• リスクに応じたゲートの規模設定
• ノーゴー条件
• ゴー／ノーゴー判断の実施手順
• アクセプタンスとリリース作業におけるAI
• 代替手法：リリースをゲートする方法
• Netbase JSCのアクセプタンスとリリース判定の進め方
• 存在する納品実績とそうでないもの
• このガイドの限界
• よくある質問
• 次のステップ

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

アクセプタンス基準はストーリーのビルド前に合意するものです。リリース判定は、ビルド後にリリース候補に対して行う評価です。この2つを混同すると、最終週になって誰も「完了」の定義を明文化していなかったという事態を招きます。前者はバックログに、後者はリリース記録に保管し、前者が後者に繋がるようにしてください。合格したすべてのアクセプタンス基準が、リリースの証拠として記録されます。

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

スクラムガイドでは、完了の定義を満たさない作業はインクリメントの一部にはなれないとされており、リファインメントはアイテムをより小さく、より精緻な単位に分解するとされています。ストーリーがビルド可能な状態とは、以下を満たしている場合です：

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

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

各基準は「given（前提）、when（操作）、then（結果）」の形式で記述し、上の表はあくまで参考として使用してください。機械的に埋めるテンプレートではありません。重要なのは、コードが存在する前に失敗ケースを記述しておくことです。

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

Googleが自社サービス向けに作成したLaunch Coordination Checklistは、アーキテクチャ、キャパシティ、障害モード、モニタリング、セキュリティ、ロールアウト計画をカバーしています。これらの領域はほとんどのプロダクトに当てはまり、それぞれについて開いて確認できる証拠が必要です：

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

リスクに応じたゲートの規模設定

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

• ルーティン変更。小規模な修正は、テスト合格・レビュー完了・再デプロイによるロールバックという自動化された証拠のみで通過できます。
• 標準リリース。上記の全項目を、証拠をリリース記録に添付した上で実施します。
• 高リスクリリース。データマイグレーション、決済、権限、または多くの顧客が気づく変更。本番に近い環境でのリハーサル、段階的ロールアウト、リリース後に監視する担当者の指定を追加します。

ノーゴー条件

締め切りのプレッシャー下で交渉されないよう、会議の前に合意しておいてください：

• アクセプタンス基準が不合格、またはテストが存在しない。
• 重大またはハイレベルのセキュリティ検出事項が、担当者の受け入れなしに未対応のまま残っている。
• オフにできない変更に対して、テスト済みのロールバックが存在しない。
• マイグレーションがリハーサルされていない。
• モニタリングで新しい動作が正常に機能しているか確認できない。
• 署名が必要な担当者が不在、または証拠を確認していない。

代替手法：リリースをゲートする方法

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の変更失敗率（即時対応が必要なデプロイの割合）などの指標は、ゲートが長期的に機能しているかを示します。これらはチェックする項目ではなく、結果として得られるアウトカムです。
• チェックリストは証拠を記録するものです。弱いテストスイートを強くすることはできません。

よくある質問

リリース判定チェックリストには誰がサインするのですか？各項目には固有の担当者がいます。例えばテスト証拠はQAリード、検出事項はセキュリティ担当者、スコープはプロダクトオーナーです。最終決定と記録を行うのは一人のリリースオーナーです。

アクセプタンス基準はどの程度詳細にすべきですか？計画会議に参加していないテスターが合否を判断できる程度に詳細であり、かつ1イテレーション分の作業量を超えないようにしてください。基準が1ページに及ぶ場合は、ストーリーを分割してください。

未解決の不具合があってもリリースできますか？はい、それぞれが把握され、評価され、リリース記録内で担当者が受け入れていれば可能です。未把握または担当者不明の不具合はノーゴーです。

全項目を確認する時間がない場合はどうすればよいですか？小規模な変更にはルーティン区分を適用し、ノーゴー条件はすべてのリリースに適用してください。高リスクな変更で証拠を省略することが、障害が顧客に届く原因になります。

次のステップ

最近のリリース、そのアクセプタンス基準、サインオフした担当者を共有していただければ、ソリューションレビューのご予約を通じて両チェックリストをチームに合わせた形に調整します。品質エンジニアリングとテスト、またはNetbase JSCのインサイトもご覧いただけます。

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