リリース判定基準チェックリスト｜Go/No-Goの項目と会議資料の型

リリース判定とは、作ったシステムを本番に出してよいかを、あらかじめ決めた基準と照らして Go（出す）か No-Go（出さない）かに決めることです。判定がその場の印象に左右されるのは、基準が数値になっていないか、当日に初めて基準を話し合っているときです。

この記事では、判定基準を5分類22項目のチェックリストにし、数値の例と根拠資料の列を付けて全文を載せました。判定会議の資料テンプレートと記入例、項目の結果から判定を出すPythonの例も付けています。例は架空の「備品予約システム」のリリースです。数値はすべて例なので、自分たちのシステムに合わせて置き換えてください。

確認環境：Ubuntu 24.04、Python 3.11.15（標準ライブラリのみ）。掲載した判定結果は、2026-10-05に実行した出力です。

この記事の結論

• 判定基準は数値で事前に合意し、当日は基準との差だけを見ます。
• 必須項目が1つでも未達なら No-Go。例外を作ると、次回から基準が基準として働かなくなります。
• 推奨項目の未達は、期限と担当を付けた「条件付きGo」。期限か担当が決まらないものは、条件として成り立たないので No-Go に倒します。
• 会議の資料は判定サマリー・未達項目・条件・決裁欄の4つがあれば足ります。

リリース判定の早見表

Go・条件付きGo・No-Goの決め方

条件付きGoを「何となく出す」ための抜け道にしないために、条件には次の4つを必ず書きます。

リリース判定基準チェックリスト（5分類22項目）

「判定基準（数値例）」の値は例です。「根拠資料」は、会議で「達成」と言うときに示す資料の名前です。根拠資料を示せない項目は、未達として扱います。

必須と推奨を分ける質問

残バグの基準の決め方

「残バグは何件までか」は、件数を1つ決めるより、重要度ごとに決めるほうが判定しやすくなります。次は例です。

表計算ソフトに貼れるタブ区切り版（記入例つき）

結果・未達の内容・期限・担当の4列を加えた10列です。記入例は、推奨の2項目が未達の状態です。

No  分類  確認項目    区分  判定基準（数値例）   根拠資料    結果  未達の内容   期限  担当
Q1  品質  テストケースの消化率  必須  100%（対象外にしたケースは理由つきで合意済み）   テスト進捗管理表    達成          
Q2  品質  テストケースの合格率  必須  98%以上、かつ不合格の全件にバグ票がある   テスト進捗管理表    達成          
Q3  品質  重要度「致命的」「重大」の未解決バグ  必須  0件  バグ管理表   達成          
Q4  品質  重要度「中」の未解決バグ    推奨  3件以下、かつ全件に回避策がある    バグ管理表   未達  中が4件（回避策は全件あり）  2026-10-23  井上
Q5  品質  性能テストの応答時間  必須  主要5画面の95パーセンタイルが2.0秒以内  性能テスト報告書    達成          
Q6  品質  脆弱性診断の指摘    必須  重要度「高」以上が0件 診断報告書   達成          
R1  残課題 未完了の課題  必須  リリースを止める課題が0件   課題管理表   達成          
R2  残課題 仕様の未決事項 必須  0件（見送る場合は見送りの合意が記録にある）  課題管理表、議事録   達成          
R3  残課題 既知の制約の周知    推奨  利用者向けのお知らせに全件を記載    リリースノート案    達成          
M1  移行・切り戻し 移行リハーサル 必須  本番相当のデータ量で1回以上完了し、所要時間が作業枠の80%以内    リハーサル記録 達成          
M2  移行・切り戻し 移行後のデータ照合   必須  件数と合計値の差異が0 照合結果    達成          
M3  移行・切り戻し 切り戻し手順のリハーサル    必須  1回以上完了し、所要時間が30分以内  リハーサル記録 達成          
M4  移行・切り戻し 切り戻しを決める基準と期限   必須  判断者・判断時刻・基準が手順書に書いてある   リリース手順書 達成          
M5  移行・切り戻し バックアップからの復元確認   推奨  直近1か月以内に復元を1回確認 復元確認の記録 達成          
O1  運用体制    監視とアラートの設定  必須  監視項目一覧の全項目が設定済みで、通知の到達を確認済み 監視設定一覧  達成          
O2  運用体制    運用手順書と問い合わせ窓口   必須  手順書がレビュー済みで、窓口と受付時間が周知済み    運用手順書   達成          
O3  運用体制    リリース当日と翌営業日の体制  必須  連絡網が確定し、各役割に代理がいる   体制表 達成          
O4  運用体制    利用者向けマニュアル  推奨  変更した画面の全てについて更新済み   マニュアル   未達  12画面のうち2画面が未更新  2026-10-16  森田
A1  合意  受入テストの結果への合意    必須  発注側の責任者の承認が記録にある    受入テスト報告書    達成          
A2  合意  リリース日時と停止時間の告知  必須  利用者への告知が5営業日前までに完了  告知文、送信記録    達成          
A3  合意  残バグの扱いへの合意  必須  残す全件について修正予定の版と期限に合意済み  バグ管理表、議事録   達成          
A4  合意  リリース後の観察期間と完了条件 推奨  観察期間（例：5営業日）と完了条件に合意済み  議事録 達成          

判定会議の資料テンプレート

資料は1〜2ページに収めます。チェックリストの全項目は添付に回し、本体には未達の項目だけを書きます。

# リリース判定会議 資料

- 対象：（システム名・版）
- リリース予定日時：
- 判定会議の日時：
- 判定の基準：（合意した基準の文書名と合意日）

## 1. 判定サマリー

- 提案する判定：Go ／ 条件付きGo ／ No-Go
- 必須項目：　/　達成
- 推奨項目：　/　達成

| 分類 | 必須（達成/全体） | 推奨（達成/全体） | 状態 |
|---|---|---|---|
| 品質 | | | |
| 残課題 | | | |
| 移行・切り戻し | | | |
| 運用体制 | | | |
| 合意 | | | |

## 2. 未達項目

| No | 確認項目 | 区分 | 判定基準 | 現在の値 | 差 | 根拠資料 |
|---|---|---|---|---|---|---|

## 3. 条件（条件付きGoの場合）

| No | 条件の内容 | 期限 | 担当 | 間に合わなかったときの扱い |
|---|---|---|---|---|

## 4. 切り戻しの判断

- 判断する人：
- 判断の期限：
- 切り戻す基準：

## 5. 決裁欄

| 役割 | 氏名 | 判定 | 日付 | コメント |
|---|---|---|---|---|
| 決裁者 | | | | |
| 開発の責任者 | | | | |
| 品質の責任者 | | | | |
| 運用の責任者 | | | | |

## 添付

- チェックリスト（全項目）
- 根拠資料の一覧

記入例（架空の備品予約システム 2.0）

# リリース判定会議 資料

- 対象：備品予約システム 2.0
- リリース予定日時：2026-10-10（土）22:00〜24:00
- 判定会議の日時：2026-10-08（木）15:00〜15:30
- 判定の基準：リリース判定基準書 第1.0版（2026-09-01 合意）

## 1. 判定サマリー

- 提案する判定：条件付きGo
- 必須項目：17 / 17 達成
- 推奨項目：3 / 5 達成

| 分類 | 必須（達成/全体） | 推奨（達成/全体） | 状態 |
|---|---|---|---|
| 品質 | 5/5 | 0/1 | 推奨1件が未達 |
| 残課題 | 2/2 | 1/1 | 達成 |
| 移行・切り戻し | 4/4 | 1/1 | 達成 |
| 運用体制 | 3/3 | 0/1 | 推奨1件が未達 |
| 合意 | 3/3 | 1/1 | 達成 |

## 2. 未達項目

| No | 確認項目 | 区分 | 判定基準 | 現在の値 | 差 | 根拠資料 |
|---|---|---|---|---|---|---|
| Q4 | 重要度「中」の未解決バグ | 推奨 | 3件以下、全件に回避策 | 4件（回避策は全件あり） | +1件 | バグ管理表 |
| O4 | 利用者向けマニュアル | 推奨 | 変更した12画面すべて更新済み | 10画面が更新済み | −2画面 | マニュアル |

## 3. 条件（条件付きGoの場合）

| No | 条件の内容 | 期限 | 担当 | 間に合わなかったときの扱い |
|---|---|---|---|---|
| Q4 | 4件のうち1件以上を修正し、3件以下にする | 2026-10-23 | 井上 | 月次利用一覧の出力を一時的に止め、利用者に告知する |
| O4 | 残り2画面のマニュアルを更新する | 2026-10-16 | 森田 | 該当画面の操作手順をお知らせに掲載する |

## 4. 切り戻しの判断

- 判断する人：開発の責任者（佐藤）
- 判断の期限：2026-10-10 23:15
- 切り戻す基準：23:15 の時点で移行後のデータ照合に差異がある、または確認項目に1つでも不合格がある

## 5. 決裁欄

| 役割 | 氏名 | 判定 | 日付 | コメント |
|---|---|---|---|---|
| 決裁者 | 山本 | 条件付きGo | 2026-10-08 | 条件2件の結果を各期限の日に報告のこと |
| 開発の責任者 | 佐藤 | 条件付きGo | 2026-10-08 | |
| 品質の責任者 | 高橋 | 条件付きGo | 2026-10-08 | |
| 運用の責任者 | 田中 | 条件付きGo | 2026-10-08 | |

判定会議の進め方（30分の例）

資料は前日までに配り、会議では達成した項目を読み上げません。達成の根拠に疑問がある人は、会議の前に資料の担当へ問い合わせておきます。

項目の結果から判定を出すPythonの例

タブ区切りのチェックリストを読み、Go／条件付きGo／No-Go を出します。判定のルールを文章ではなくコードにしておくと、当日に解釈が分かれません。

import csv
import sys
from collections import Counter

def judge(rows):
    """必須の未達が1つでもあれば No-Go。
    推奨の未達は、期限と担当がそろっていれば条件付き Go、欠けていれば No-Go。"""
    must_ng = [r for r in rows if r["区分"] == "必須" and r["結果"] != "達成"]
    rec_ng = [r for r in rows if r["区分"] == "推奨" and r["結果"] != "達成"]
    no_plan = [r for r in rec_ng if not (r["期限"] and r["担当"])]
    if must_ng:
        return "No-Go", must_ng, rec_ng, no_plan
    if no_plan:
        return "No-Go（条件が決まっていない）", must_ng, rec_ng, no_plan
    if rec_ng:
        return "条件付きGo", must_ng, rec_ng, no_plan
    return "Go", must_ng, rec_ng, no_plan

def report(path):
    with open(path, encoding="utf-8", newline="") as f:
        rows = list(csv.DictReader(f, delimiter="\t"))
    result, must_ng, rec_ng, no_plan = judge(rows)
    total = Counter(r["区分"] for r in rows)
    done = Counter(r["区分"] for r in rows if r["結果"] == "達成")
    print(f"判定: {result}")
    for kind in ("必須", "推奨"):
        print(f"  {kind}: {done[kind]}/{total[kind]} 達成")
    for r in must_ng:
        print(f"  [必須の未達] {r['No']} {r['確認項目']}: {r['未達の内容']}")
    for r in rec_ng:
        plan = f"期限 {r['期限']} / 担当 {r['担当']}" if r["期限"] and r["担当"] else "期限・担当が空欄"
        print(f"  [推奨の未達] {r['No']} {r['確認項目']}: {r['未達の内容']}（{plan}）")

for p in sys.argv[1:]:
    print(f"== {p}")
    report(p)

4つの状態で実行しました。checklist.tsv は先ほどの記入例、case_go.tsv は全項目を達成にしたもの、case_noplan.tsv は O4 の期限と担当を空欄にしたもの、case_nogo.tsv は必須の Q3 を未達にしたものです。

$ python3 judge.py case_go.tsv checklist.tsv case_noplan.tsv case_nogo.tsv
== case_go.tsv
判定: Go
  必須: 17/17 達成
  推奨: 5/5 達成
== checklist.tsv
判定: 条件付きGo
  必須: 17/17 達成
  推奨: 3/5 達成
  [推奨の未達] Q4 重要度「中」の未解決バグ: 中が4件（回避策は全件あり）（期限 2026-10-23 / 担当 井上）
  [推奨の未達] O4 利用者向けマニュアル: 12画面のうち2画面が未更新（期限 2026-10-16 / 担当 森田）
== case_noplan.tsv
判定: No-Go（条件が決まっていない）
  必須: 17/17 達成
  推奨: 3/5 達成
  [推奨の未達] Q4 重要度「中」の未解決バグ: 中が4件（回避策は全件あり）（期限 2026-10-23 / 担当 井上）
  [推奨の未達] O4 利用者向けマニュアル: 12画面のうち2画面が未更新（期限・担当が空欄）
== case_nogo.tsv
判定: No-Go
  必須: 16/17 達成
  推奨: 3/5 達成
  [必須の未達] Q3 重要度「致命的」「重大」の未解決バグ: 重大が1件（予約の二重登録）
  [推奨の未達] Q4 重要度「中」の未解決バグ: 中が4件（回避策は全件あり）（期限 2026-10-23 / 担当 井上）
  [推奨の未達] O4 利用者向けマニュアル: 12画面のうち2画面が未更新（期限 2026-10-16 / 担当 森田）

未達の内容が同じでも、期限と担当が空欄になるだけで条件付きGoから No-Go に変わります（checklist.tsv と case_noplan.tsv の違い）。条件付きGoの「条件」は、期限と担当がそろって初めて条件になる、という決まりをそのまま表したものです。

リリース判定・出荷判定・受入判定・カットオーバー判定の違い

これらの語は組織によって指す範囲が異なります。次は一般的な使い分けの例です。自分たちの計画書でどう定義しているかを先に確かめてください。

確かめて分かったこと

• 22項目のうち必須は17項目（77%）になりました。必須と推奨を分ける質問に沿って振り分けると、推奨に残るのは「出したあとでも直せるもの」だけになります。
• 判定を分けたのは未達の件数ではなく、区分と期限・担当の有無でした。推奨が2件未達の同じ状態から、期限と担当の2セルを空にしただけで判定が変わります。
• 必須の未達があるときも、推奨の未達を一緒に出力しておくと再判定が1回で済みます。No-Go の出力に推奨の未達2件が並ぶので、解消する範囲を一度に決められます。
• 合格率の基準は、数値だけだと判定できませんでした。「98%以上」に「不合格の全件にバグ票がある」を足して、残り2%の中身を確かめられる形にしています。
• 判定基準の列に数値を書けない項目は、根拠資料の有無を基準にすると判定できます（例：「判断者・判断時刻・基準が手順書に書いてある」）。

つまずきやすい点と直し方

よくある質問

Q. リリース判定とは何ですか？ A. 本番に出してよいかを、事前に合意した基準と照らして決めることです。結果は Go／条件付きGo／No-Go のいずれかで、決裁者が承認して記録に残します。

Q. Go/No-Go判定と条件付きGoの違いは何ですか？ A. 条件付きGoは、必須の基準はすべて満たし、推奨の未達に期限と担当を付けたうえで出す判定です。必須の未達がある場合は条件を付けても Go にはせず、No-Go とします。

Q. 残バグが何件までならリリースできますか？ A. 決まった件数はなく、重要度ごとに上限を決めます。この記事の例では、致命的・重大は0件、中は回避策つきで3件以下、軽微は修正予定の版が決まっていれば上限なしとしています。

Q. リリース判定会議の資料には何を書けばよいですか？ A. 判定サマリー、未達項目、条件、決裁欄の4つです。全項目のチェックリストと根拠資料は添付に回し、本体は1〜2ページに収めます。

Q. No-Goになったときはどうすればよいですか？ A. 未達を解消する日と再判定の日をその場で決めます。再判定では全項目をやり直さず、未達だった項目と、延期によって値が変わる項目（告知、体制など）だけを確かめます。

まとめ

• 判定基準は数値で事前に合意し、当日は基準との差だけを見る。
• 必須の未達が1つでもあれば No-Go。推奨の未達は、期限と担当を付けて条件付きGo。
• チェックリストは品質・残課題・移行／切り戻し・運用体制・合意の5分類で、項目ごとに根拠資料を決めておく。
• 残バグの基準は重要度ごとの上限と条件で決める。
• 会議の資料は判定サマリー・未達項目・条件・決裁欄。本体には未達だけを書く。
• 判定のルールをコードや表にしておくと、当日に解釈が分かれない。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。