リリース判定チェックリスト｜GO/NO-GOで揉めない判断軸

2026 9/18

2026年9月18日

リリース前日の判定会議。「で、これは出していいんですか？」と問われて、自信を持って「出せます」と言い切れたことがどれくらいあるでしょうか。

残バグはまだ数件ある。顧客の確認も一部返ってきていない。テストは「たぶん大丈夫」。この状態で判定が、いちばん声の大きい人の一言や、PMの胃の痛みで決まっていく——受託開発の現場でよく見る光景です。

この記事は、その判定を「揉めない」形にするための判断軸と、判定会議でそのまま使えるチェックリストをまとめたものです。網羅的な理論ではなく、GO・NO-GO・条件付きGOのどれを選ぶかを、感覚ではなく事前に決めた基準で言い切れる状態を目指します。

なぜリリース判定は毎回揉めるのか

判定が揉めるのは、担当者が優柔不断だからではありません。判定の土台が事前に用意されていないからです。土台がなければ、同じ状況でも人によって結論が変わり、最後は立場と声量で決まります。

揉める現場に共通するのは、次の5つのどれかが欠けている状態です。

合格ラインが言語化されていない：「重大バグゼロ」以外の基準が曖昧で、残バグ3件がOKかNGか誰も断言できない
最終決裁者が決まっていない：品質・営業・開発が同席し、誰の一言で決まるのかが曖昧
判定材料が揃っていない：テスト消化率も残課題一覧も、その場で口頭確認になる
二択しか用意していない：出すか止めるかの0か100で、逃げ道がなく感情論になる
判定した記録が残らない：「あのとき出すと決めた」根拠が残らず、事故後に犯人捜しになる

リリース判定が揉めるのは人の問題ではなく、判定の仕組みが用意されていないという構造の問題です。

裏を返せば、この5つを事前に埋めておけば、判定会議は「基準に照らして確認するだけ」の作業に変わります。以下では、その土台を順に用意していきます。

GO・NO-GO・条件付きGOの3択で考える

まず前提を1つ変えます。リリース判定を「出す（GO）／止める（NO-GO）」の二択にしないことです。二択だと、軽微な既知バグが1件あるだけでNO-GOに倒すか、逆に無理にGOに倒すかの両極になり、判断がヒリつきます。

現実の判定は、第3の選択肢「条件付きGO」を持つと格段に扱いやすくなります。

判定	状態	典型的な条件
GO	合格基準をすべて満たす	追加条件なしでリリース
条件付きGO	重大な問題はないが、既知の軽微な問題が残る	回避策の周知／次リリースでの修正期限／監視強化を条件に出す
NO-GO	合格基準の必須項目を満たさない	該当項目が解消するまで延期

判定で本当に難しいのは「GOかNO-GOか」ではなく、「条件付きGOで出せる範囲はどこまでか」の線引きです。

条件付きGOを使うときの鉄則は、条件を口頭で終わらせないことです。「軽微だから次で直す」で流すと、その「次」は永遠に来ません。残す条件は、担当・期限・回避策の3点をセットで記録に残します。

延期そのものの判断軸を掘り下げたい場合は、ソフトウェアリリース延期の判断基準も併せて確認してください。本記事は「延期するか」ではなく「どの判定を選ぶか」の決め方に絞ります。

判定を分ける4カテゴリの判断軸

では、GO・NO-GO・条件付きGOを何で分けるのか。判定材料を4つのカテゴリに整理すると、抜け漏れなく見られます。

カテゴリ1：品質（テストの状況）

テストがどこまで終わり、どんな結果だったか。ここが最も判定の中心になります。

予定したテストが計画どおり消化されているか（未消化があるなら、それは意図的に落としたのか、時間切れか）
未解決の不具合が、重大度別に何件残っているか
残っている不具合に回避策があるか、業務が止まるものか

ポイントは、残バグを件数だけで見ないことです。「残り5件」では判定できません。「業務停止級ゼロ／中程度2件（回避策あり）／軽微3件」まで分解して初めて、条件付きGOで出せるかが見えます。品質を数字で語る土台づくりは、品質を数字で説明できないPMへで具体的に扱っています。

テストの合否や完了の線引きに使う共通用語は、JSTQBのシラバスで整理されています。判定基準を社内で決めるときは、こうした公的な用語を物差しにすると、担当者ごとの解釈のブレを抑えられます。組織や案件ごとの品質水準を客観的に捉える手がかりとしては、IPAが公開するソフトウェア開発の分析データのような公的資料も、合格ラインを議論する際の下敷きになります。

カテゴリ2：残課題（バグ以外のTODO）

バグとして起票されていないが、リリースまでに片付けるはずだった項目です。ここが判定の盲点になりがちです。

ドキュメント・マニュアルの整備は完了しているか
移行データの準備・確認は済んでいるか
未実装のまま「次フェーズ送り」になった機能を、関係者が把握しているか

カテゴリ3：顧客・関係者の合意

技術的に出せても、顧客の合意がなければ出してはいけません。ここを飛ばすと、品質は問題なくても「聞いていない」でトラブルになります。

受け入れテスト（UAT）の結果に顧客が合意しているか
残す既知の問題について、顧客に説明し了承を得ているか
リリース日時・作業時間帯について合意があるか

カテゴリ4：運用・切り戻しの準備

出した後に問題が起きたとき、戻せるかどうかです。ここが未確認のGOは、最もリスクが高い判定です。

リリース手順書があり、担当と時間が決まっているか
切り戻し（ロールバック）の手順と判断基準があるか
リリース直後に何を見て正常を確認するか（監視項目）が決まっているか

4カテゴリのうち「品質」だけを見て判定するのが、最もよくある失敗です。残課題・顧客合意・切り戻しの3つは、品質が満点でも事故を起こします。

そのまま使えるリリース判定チェックリスト

4カテゴリを、判定会議でそのまま読み上げられるチェックリストにしました。コピーして自分の案件用に項目を足し引きして使ってください。各項目の右に「必須／推奨」を付けておくのがコツです。必須が1つでも欠ければNO-GO、推奨の欠けは条件付きGOの検討対象、と機械的に判定できます。

品質

[ ][必須] 業務停止級・データ破損級の未解決バグがゼロである
[ ][必須] 計画したテストのうち、未消化の範囲と理由が説明できる
[ ][推奨] 残る中程度バグに回避策があり、影響範囲を把握している
[ ][推奨] 主要業務の通しシナリオが最新ビルドで通っている

残課題

[ ][必須] 「次フェーズ送り」の項目を関係者全員が認識している
[ ][推奨] マニュアル・手順書が利用者に渡せる状態になっている
[ ][推奨] 移行・初期データの投入と確認が済んでいる

顧客・関係者の合意

[ ][必須] 顧客がUAT結果に合意している
[ ][必須] 残す既知の問題について顧客の了承を得ている
[ ][推奨] リリース日時・作業帯について合意がある

運用・切り戻し

[ ][必須] リリース手順書があり、担当・時間・順序が決まっている
[ ][必須] 切り戻しの手順と「戻す判断をする基準」が決まっている
[ ][推奨] リリース直後の正常確認項目（監視・目視）が決まっている

このチェックリストは、テスト段階で使う網羅的な確認項目とは役割が違い、判定会議で「出すかどうか」を決めるための最終確認に絞っています。テストをどこまでやれば完了とするかの基準づくりはテストの完了基準の決め方、レビューでバグを漏らさない土台づくりはレビューの形骸化を防ぐで扱っています。テスト段階ではそれらを、判定会議では本記事のリストを、と使い分けると重複しません。

判定会議を揉めさせない事前準備

チェックリストがあっても、会議の場で材料が揃っていなければ結局は口頭確認で崩れます。判定会議の前に、次の3つを用意しておくと会議は驚くほど短く終わります。

決裁者を1人決めておく

品質・開発・営業が同席すると、全員が少しずつ責任を持ち、結局誰も決めない状態になります。最終的にGO/NO-GOを言い切る人を1人決めておくことが、揉めない最大のコツです。他のメンバーは判断材料を出す役、決裁者は基準に照らして言い切る役、と役割を分けます。

判定材料を1枚にまとめておく

テスト消化率、残バグの重大度別件数、残課題一覧、顧客合意の状況を、会議前に1枚のサマリにしておきます。その場で「消化率いくつだっけ」と探し始めると、そこから空気が緩みます。事前に埋めておけば、会議は数字を確認するだけです。

判定表に記録して残す

誰が・いつ・どの基準に照らして・どう判定したかを、簡単な表で残します。特に条件付きGOのときは、残した条件（担当・期限・回避策）を明記します。この記録が、後で「なぜ出したのか」を説明する根拠になり、事故が起きても犯人捜しではなく基準の見直しに向かえます。

記録項目	記入例
判定日・決裁者	◯月◯日／PM 山田
判定結果	条件付きGO
残した条件	帳票の表示崩れ（軽微）を次リリースで修正。担当◯◯・期限◯月◯日・回避策は手動出力
顧客合意	UAT結果に合意済み。既知の表示崩れも了承済み

現場で崩れやすい5つの失敗パターン

最後に、判定の仕組みを作っても崩れやすいポイントを挙げておきます。自分の現場に当てはまるものがないか確認してください。

チェックリストが形骸化する：毎回すべてにチェックが付き、実質「確認したことにする」儀式になる。→ 1項目でも「未確認」を正直に出せる空気を決裁者が作る
声の大きい人が基準を上書きする：営業の「客が待っている」で必須項目が飛ぶ。→ 必須項目を飛ばす判断は、決裁者が明示的に記録に残す（後で誰の判断か分かるように）
残バグを判定前に消す：起票を取り下げて「バグゼロ」にする。→ 判定は起票状況ではなく、実際の挙動で確認する
条件付きGOの条件が守られない：「次で直す」が放置される。→ 条件は次リリースのタスクとして即起票し、期限を持たせる
判定の記録が残らない：口頭で「出そう」と決めて終わる。→ 判定表を1枚残す。これだけで後の説明責任がまったく変わる

仕組みは一度作って終わりではなく、事故が起きるたびに「どの基準が甘かったか」を判定表から見直して育てるものです。