「テストが通ったか」の次の段階
テスト結果だけでリリースを確定してはいけません。テストは特定のバージョン・環境・データ・シナリオで観察した事実を示します。その範囲が実際の変更を十分に覆ったか、本番環境でも同じ結果になるか、失敗がユーザーとデータにどう影響するかまでは判断してくれません。Google SRE も、テスト環境と本番環境は完全には同じでなく、すべてのシナリオを試せないため、一部の欠陥は実トラフィックで初めて現れると説明しています。[4][6]
リリース会議が決めるべきことは「テストが通ったか」の次の段階です。何が確認され何がまだ不確かか、問題が起きたら誰にどんな被害が出るか、その問題に気づいて露出を止めるか復旧できるかを確認しなければなりません。その根拠をもとに、組織が残るリスクを受け入れるかを決めることがリリース判断です。
結論は READY・READY WITH CONDITIONS・HOLD の三つに分けます。このとき複数の項目に点数を付けて合算してはいけません。ユーザーデータ損失の可能性、未確認の中核経路、復旧手段の不在のように、他の結果では相殺できない条件があるからです。リリース準備度は平均点ではなく、遮断条件と証拠の空白を先に見なければなりません。
テスト結果が証拠になるには文脈が要る
「全テストが通った」という一文だけでは判断しにくいものです。最低限、次の文脈が付いていなければなりません。どのバージョンか、何を検証したか、どの環境とデータで実行したか、NOT RUN・BLOCKED・除外の項目は何か、結果はいつ生成されたか、です。[1]
たとえばテストがすべて PASS でも、その後に設定が変わっていれば結果の有効性は変わります。中核のユーザー経路がテスト範囲から漏れていた、外部の決済・認証・メッセージングが正常な時だけ検証した、という場合「通過」が語る範囲も狭くなります。FAIL がないことと、失敗しうる条件を十分に確認したことは同じ意味ではありません。
要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。
Release Evidence Matrix
リリース判断には、テスト報告書のほかに、要求充足、セキュリティとデータ、本番環境、ユーザー影響、復旧可能性、責任者に関する Evidence が必要です。
機能テストの結果だけでセキュリティ準備の代わりにもなりません。NIST SSDF はセキュリティ活動を SDLC に統合する高水準の実践領域を示し、OWASP ASVS は技術的なセキュリティ統制を検証できる要求事項の基準を提供します。[7][8]
下の Matrix は品質点数を計算する表ではありません。判断に必要な証拠があるか、どの空白がリリースを止めるか、どのリスクだけを条件付きで受け入れられるかを確認する表です。すべてのセルを長く埋める必要はありません。ただし遮断条件に当たる空白を、他項目の良い結果で相殺してはいけません。
証拠領域 | 確認する問い | 必要な Evidence | 遮断条件 | 条件付き許容条件 | Owner |
|---|---|---|---|---|---|
| 要求充足と変更範囲 | 今回のリリースが解決すると決めた要求と実際の変更は一致しているか | 承認済みリリース範囲、変更要約、受け入れ基準、除外項目 | 中核の要求や変更範囲についてチームが合意できていない | 非中核項目を明示的に除外し、後続の Owner と期限を記録している | Product Owner |
| テスト結果と限界 | 重要な経路を適切な環境とデータで検証したか | 対象バージョン、実行環境、テスト結果、NOT RUN・BLOCKED・除外項目、Evidence の生成時点 | 中核経路が NOT RUN・BLOCKED、または結果が現在のバージョンと結びついていない | 影響が限定的な検証空白で、露出範囲・観察方法・後続検証が決まっている | QA Lead / Engineering Lead |
| 未解決欠陥と残存リスク | 残った欠陥が実際に起きたら誰にどんな被害が出るか | 未解決欠陥一覧、影響分析、再現条件、回避策、不確実性 | データ・金銭・権限・法的義務、または復旧困難な被害が統制されていない | 影響範囲が限定され、対応方法・Owner・失効時点が記録されている | Product / Engineering |
| セキュリティ・個人情報・データ | 新しい権限、機微情報の処理、データ変更に未確認のリスクがあるか | セキュリティレビュー、適用した要求事項とバージョン、データフロー確認、未解決のセキュリティ課題 | 不正アクセス・情報漏えい・データ破損の可能性が未解決、または承認権限者がリスクを検討していない | 非中核の空白で露出範囲が限定され、補完措置と再検討時点が決まっている | Security / Privacy Owner |
| 本番環境と外部依存 | 本番設定、容量、資格情報、外部サービスは実条件で準備できているか | 本番構成の確認、依存関係の状態、制約条件、支援連絡網、運用担当者 | 中核依存や本番設定が不明確で、障害時の対応主体もいない | 特定のユーザー・時間・機能に露出を限定し、担当者が即時対応できる | Operations / Service Owner |
| ユーザー影響の観測 | リリース後に重要なユーザー失敗をチームが気づけるか | 観察するユーザー影響、確認画面またはシグナル、観察期間、停止トリガー | ユーザーに大きな被害が出てもチームが発見する手段がない | 限定範囲で人が直接確認でき、拡大前に再判定すると決めている | Service Owner / Reliability Owner |
| 復旧可能性 | 問題が起きたら露出を止め、既知の状態に戻すか安全に修正できるか | 検証済みの停止・復旧経路、実行権限、責任者、復旧完了の確認方法 | 戻せない高影響の変更、または復旧経路を検証していない | 影響範囲が限定され、検証済みの代替対応または前進復旧経路がある | Release / Operations Owner |
| 責任と承認記録 | 誰がリリースを決め、残るリスクを誰が受け入れ、問題時に誰が動くか | Release Decision Record、残存リスク Owner、承認権限者、再検討時点 | 決定権者や対応 Owner がおらず、リスク受容主体が不明確 | 条件・Owner・承認者・失効時点をすべて記録した場合のみ条件付きリリース可 | Release Authority |
READY / READY WITH CONDITIONS / HOLD はどう分けるか
READY は、現在のリリース範囲に必要な Evidence が確保され、受け入れられない残存リスクが見つかっていない状態です。READY は「欠陥がない」「障害が起きない」という意味ではありません。通常の運用リスクは残ります。ただし重要な不確実性が把握され、組織が定めた受容範囲内にあり、問題が起きた時に観察して対応できる根拠が必要です。
READY WITH CONDITIONS は、リリースを止める絶対的な遮断条件はないが、未確認の条件や残るリスクがある状態です。誰に、またはどの機能だけに露出するか、何を観察するか、どんな状況で露出を止めるか、問題が起きたらどう対応するか、誰がその決定を実行するか、いつ READY か HOLD を再判定するか、がすべて決まっていなければなりません。「とりあえず出して様子を見る」は READY WITH CONDITIONS ではありません。範囲と停止条件、責任者、失効時点のない条件付きリリースは、事実上記録されていない READY です。
HOLD は次のいずれかに当てはまれば出すのが妥当です。中核の変更範囲や要求事項が不明確。重要なユーザー経路を検証できていない。データ・金銭・権限・個人情報に復旧困難な被害が出うる。残る不確実性の影響範囲を限定できない。ユーザー被害を発見する手段がない。問題が起きても露出を止める、または復旧する根拠がない。リスクを受け入れる権限者と対応 Owner がいない。
復旧可能性はリリース後の運用の便宜のための付録ではありません。Google SRE は段階的適用、進行の中断、巻き戻しの能力を安全な変更の中核属性として説明し、復旧できないデプロイはユーザー被害をより長く続かせると指摘しています。[6][9] 戻せない変更をどう設計しないかは Release It! が扱うテーマでもあります。[5]
判定の順序は五段階です。第一に、相殺できない遮断条件があれば HOLD。第二に、残る不確実性のユーザー・データ・事業への影響を説明できなければ HOLD。第三に、露出範囲を限定し、問題を観察し、停止・復旧できなければ HOLD。第四に、条件と Owner、停止トリガー、再判定時点が記録されていれば READY WITH CONDITIONS。第五に、現在の範囲に必要な Evidence が十分で、受け入れられない残存リスクがなければ READY です。
- READY
- READY は、現在のリリース範囲に必要な Evidence が確保され、受け入れられない残存リスクが見つかっていない状態です。欠陥ゼロではなく、残るリスクが受容範囲内にあるという意味です。
- READY WITH CONDITIONS
- READY WITH CONDITIONS は、絶対的な遮断条件はないが未確認の条件や残るリスクがある状態です。露出範囲・観察シグナル・停止トリガー・対応・Owner・再判定時点がすべて記録されて成立します。
- HOLD
- HOLD は、相殺できない遮断条件がひとつでもあるためリリースを保留する判定です。未検証の中核経路、復旧困難な被害の可能性、復旧根拠の不在、責任者の不在が該当します。
残存リスクは欠陥一覧とは別に記録する
NIST は残存リスクを、統制や対応を適用した後にも残るリスクと定義しています。許容可能なリスクとは、組織が定めたリスク受容範囲内にある残存リスクです。もともとはセキュリティリスク管理の文脈の定義ですが、リリース判断でも有用な区分です。[10]
欠陥一覧には「何が間違っているか」が書かれます。残存リスクの記録には「どんな条件で、誰に、何が起こりうるか、そしてなぜ今受け入れるのか」が書かれていなければなりません。
「中リスク」「Severity 3」「後で修正」のような圧縮したラベルだけを残すと、次の人が判断を再現できません。次の文型を使えば、リスクの条件と責任が一文に残ります。
［原因または未確認条件］のため、［影響対象］で［失敗事象］が発生し、［ユーザー・データ・事業への影響］が生じうる。現在確認された根拠と不確実性は［Evidence］である。リリース時に［露出制限または緩和措置］を適用し、［観察シグナル］で［停止トリガー］が確認されたら［対応または復旧］する。Owner は［役割］、リスク受容権限者は［役割］、再検討時点は［日付または事象］である。
Severity と発生可能性を記録しても構いませんが、それだけでリリース可否を自動計算してはいけません。同じラベルのリスクでも、データの復旧可能性、ユーザー範囲、検知可能性、責任者の有無によって結論が変わります。下の Register フィールドは、その違いを記録に残すための最小構成です。
フィールド | 記録する内容 |
|---|---|
| Risk ID | 変わらない識別子 |
| リスクシナリオ | 原因、失敗事象、結果を一文で記録 |
| 影響対象 | ユーザー種別、データ、業務、外部依存 |
| 確認済み Evidence | テスト、レビュー、運用確認などすでに分かっている事実 |
| 残る不確実性 | まだ確認できていない条件 |
| 影響と可逆性 | 被害の大きさだけでなく戻せるかどうか |
| リリース条件 | ユーザー・機能・時間・地域などの露出制限 |
| 観察および停止トリガー | 何を見て、いつ止めるか |
| 対応または復旧 | トリガー発生時に実行する措置と完了確認 |
| Owner | 観察し行動する担当役割 |
| Acceptance Authority | 残存リスクを受け入れる権限者 |
| Expiry / Review | 条件付き承認が終わる、または再判断する時点 |
Release Decision Record には何を残すべきか
Release Decision Record は承認の署名を集める文書ではありません。どの Evidence を見て、どの不確実性を受け入れたかを記録し、判断を後で再検討できるようにする記録です。
決定記録は長ければ良いものではありません。Evidence を探せること、判断の前提と責任が見えること、条件付き決定がいつ終わるかが明確であること、それだけで足ります。下の 16 フィールドのうち Decision、Rationale、Expiry / Reassessment の三つは空欄にできません。
フィールド | 記録する内容 |
|---|---|
| Release ID | 製品・サービス名、バージョンまたは変更識別子 |
| Decision | READY / READY WITH CONDITIONS / HOLD |
| Decision Time | 判断時点と適用予定時点 |
| Release Scope | 含む機能、除外する機能、対象ユーザー |
| Affected Assets | ユーザー、データ、権限、外部システム |
| Evidence References | Matrix 各領域の根拠文書と生成時点 |
| Known Unknowns | 確認できていない条件と現在の仮定 |
| Hard Blocker Check | 遮断条件の有無と判断根拠 |
| Residual Risks | Risk ID と条件付き受容の内容 |
| Release Conditions | 露出制限、観察期間、拡大条件 |
| Stop Trigger | 停止または再判定を開始する事象 |
| Recovery Evidence | 検証した停止・復旧経路への参照 |
| Owners | 観察、対応、復旧を担う役割 |
| Acceptance Authority | 最終判断とリスク受容の権限者 |
| Expiry / Reassessment | 条件付き決定の失効・再検討時点 |
| Rationale | なぜ他の判定ではなくこの結論を選んだか |
仮想シナリオ：注文状態通知機能のリリース
B2B の注文管理サービスに、外部メッセージング事業者を使った注文状態通知機能を追加すると仮定します。
機能テストと回帰テストはすべて PASS でした。承認済みの連絡先だけを使い、新しい機微情報を別途保存しないというセキュリティ・データレビューも終わっています。通知送信が失敗しても注文状態そのものは正常に保存されます。
ただし実際のピーク時間帯に外部メッセージング事業者の呼び出し制限がどう働くかは十分に確認できていません。問題が起きれば一部のユーザーが通知を遅れて受け取るか、受け取れません。注文データの損失にはつながりませんが、業務の遅延は生じます。
チームは限定した顧客グループにだけ先に機能を露出でき、メッセージ処理の遅延・送信失敗・注文状態と通知状態の不一致を確認できます。問題が確認されたら機能の露出を止められるという Evidence も検証済みです。運用 Owner と再判定時点は、最初の通常ピーク区間が終わった後に指定しました。
この場合の判定は READY WITH CONDITIONS です。Rationale は四つ。中核の注文データの正確性と保存経路は検証済み。外部メッセージング事業者の実際のピーク制限の挙動はまだ不確実。残るリスクは通知の遅延・欠落に限られ、注文処理そのものには影響しない。露出範囲の限定、観察、停止、担当者指定が可能。
Release Conditions も四つ。選んだ顧客グループにだけ露出する。メッセージ処理の遅延と送信失敗を運用担当者が確認する。注文状態と通知状態が不一致なら拡大を止める。最初の通常ピーク区間が終わった後に Evidence を再検討する。Owner は Service Owner と Operations Owner、Reassessment は最初の通常ピーク区間の検討が終わる時点です。
READY でない理由は、実際の運用条件で確認できていない重要な依存が残っているからです。HOLD でない理由は、中核の注文データが損なわれず、影響範囲を限定でき、問題を観察して露出を止められるからです。この違いを説明できないなら、READY WITH CONDITIONS の判定を出してはいけません。
リリース判断でよく起きる誤り
リリース判断で繰り返し現れる誤りは五つです。いずれも原因は同じです。証拠の種類と可逆性を見ずに、件数、ラベル、文書の存在、平均点で判断を代替することです。
- テスト件数や通過率を品質全体と見る
- テストが多くても、変更と無関係な項目を繰り返しただけならリリース Evidence は弱いままです。件数より、今回の変更で重要なユーザー・データ・依存を確認したかが先です。
- 欠陥の Severity だけを見てユーザー影響を見ない
- 同じ Severity ラベルでも、ごく少数の画面の表示不具合と金銭・データの不一致は同じ扱いにできません。発生条件、影響範囲、可逆性を併せて記録します。
- 復旧文書があるから復旧できると見なす
- 文書が存在することと、現在のバージョン・設定・データで実際に実行できることは別です。Release Gate が確認するのは文書の有無ではなく検証済みの Evidence です。
- 条件付きリリースを無期限に放置する
- Owner と失効時点のない条件付き決定は、リスクを次の会議へ先送りする手段になります。条件が満たされれば READY に転換し、満たされなければ HOLD か追加制限を再判断します。
- 総合点で遮断条件を隠す
- セキュリティ Evidence がない、または復旧できないデータ変更があるのに、他項目の高得点で全体を通過させてはいけません。Release Gate は平均より先に相殺不可の条件を見ます。
リリース可否は「欠陥がないか」ではなく「何を知って引き受けるか」の問題
良いテスト結果はリリース判断でとても重要な Evidence です。しかしテスト結果がリリース判定そのものになることはありません。
リリースできる状態とは、すべてのリスクが消えた状態ではありません。現在の範囲に必要な事実が十分に検証され、残る不確実性とユーザー影響を説明でき、問題が起きた時に観察して停止または復旧でき、そのリスクを受け入れる責任者が明確な状態です。
したがってリリース会議の最後の問いは「テストがいくつ通ったか」ではありません。何を確認し、何がまだ不明で、その状態でリリースした時に起こりうる結果を誰が受け入れるのかを問います。その問いに根拠と記録で答えられる時に初めて、READY・READY WITH CONDITIONS・HOLD を区別できます。[2][3]
