リリース判定で「なんとなくOK」を言ってしまっていませんか
受託開発のPMをしていると、こんな場面に遭遇することがあります。
リリース判定会議の最中、進行役が「このままリリースして問題ないですよね？」と切り出す。残バグの一覧が画面に並んでいるのに、誰も「ちょっと待ってください」と言い出せない。「スケジュールがあるから」「顧客も承知しているから」——そんな空気に流されてリリースボタンを押した結果、翌日から怒涛のクレームが始まる。
リリース判定の失敗は、多くの場合「判断基準がない」ことから起きます。「どれだけバグが残っていたらNGか」「誰の承諾を取れば顧客合意になるのか」が言語化されていないまま、その場の空気や上司の一言で可否を決めてしまう。
後になって「あのとき止めればよかった」と悔やんでも、すでに顧客は怒っています。大クレームになってしまえば、鎮火に費やす工数はリリース延期の比ではありません。
この記事では、リリース判定会議で必ず確認すべき3観点と、その場で使える構造化チェックリストを紹介します。「感覚」や「勢い」で判断するのではなく、品質・残課題・顧客合意という3つの軸で客観的にGO/NO-GOを決めるプロセスを身につけてください。
リリース判定の3観点
リリース可否の判断は、以下の3観点をもとに行うことで、感覚依存から脱却できます。
- 品質観点：バグ残量と優先度
- 残課題観点：判断待ちと対応中タスク
- 顧客合意観点：検収サインと使用条件
3つのどれか1つでもNGであれば、リリースは原則として見送るか、NGの内容とリスクを全員が理解した上で意思決定者が判断する必要があります。
観点1：品質（バグ残量・優先度）
何を確認するか
品質観点では「バグ残件数」そのものより、「バグの重大度分布」を重視します。バグが10件残っていても、全て軽微な表示崩れであればリリース可能な場合もあります。一方、1件であっても「特定条件でデータが消えることがある」という深刻度の高いバグがあれば、即座にNGです。
品質チェックリスト
| チェック項目 | 判定基準 | 判定 |
|---|---|---|
| 致命的バグ（Critical）が0件か | 0件でなければNG | □ |
| 高優先度バグ（High）が事前合意の上限以下か | プロジェクト開始時に基準を決めておく | □ |
| バグ修正によるリグレッションが発生していないか | 修正後の再テスト完了確認 | □ |
| テスト消化率が合意した基準値に達しているか | 通常は95%以上 | □ |
| バグ発生率のトレンドが直近1週間で下落傾向か | 増加中の場合は原因を確認する | □ |
よくある失敗
「バグは多いけど、みんな軽微なものばかり」と口頭で説明して通してしまうケースがあります。重大度の定義があいまいだと担当者によって判断がバラつき、後から「高優先度だったのに放置された」という認識齟齬を生みます。バグ管理票に重大度の定義を記載し、リリース判定前に顧客とも合意しておくことが重要です。
バグ傾向の読み方については、バグ票を改善につなげる｜不具合傾向の3軸読みで品質を立て直すPM実務も参考にしてください。
観点2：残課題（判断待ち・対応中タスク）
何を確認するか
バグ以外にも、「誰かが判断しないと進められない課題」と「現在対応中の作業」がリリース判定に影響します。特に危険なのは「判断待ち」の課題です。誰かの意思決定を待っている間にリリースしてしまうと、その判断が「リリース後のシステム」に適用されることになり、仕様不整合を引き起こします。
残課題チェックリスト
| チェック項目 | 判定基準 | 判定 |
|---|---|---|
| 「判断待ち」ステータスの課題が0件か | リリース前に全て解決または延期合意 | □ |
| 「対応中」の作業がリリース範囲外であると確認できているか | 対応中タスクが本番環境に影響しないか確認 | □ |
| 次バージョン持ち越しとした課題一覧を顧客と合意しているか | 持ち越し合意書または議事録の存在 | □ |
| インフラ・設定変更の作業が完了しているか | 手順書とチェック済み記録の確認 | □ |
| データ移行がある場合、移行データの検証が完了しているか | データ移行を含むリリースのみ | □ |
よくある失敗
「あの課題はリリース後に対応予定」と認識しているつもりが、顧客は「リリース前に解決してくれると思っていた」という認識齟齬。課題の対応時期を口頭で伝えるだけでなく、議事録やメールで書面に残すことが後々のトラブルを防ぎます。
観点3：顧客合意（検収サイン・使用条件）
何を確認するか
最もトラブルになりやすいのが顧客合意の確認不足です。「了解してもらった」「説明した」という口頭の記憶は、後になって「聞いていない」と言われるリスクをはらんでいます。顧客合意は「誰が・何を・どのような形で」承認したかを記録することで初めて成立します。
顧客合意チェックリスト
| チェック項目 | 判定基準 | 判定 |
|---|---|---|
| ユーザー受け入れテスト（UAT）が完了し、顧客担当者のサインがあるか | 書面またはメールで確認 | □ |
| 本番リリース日時を顧客が承認しているか | 承認メールまたは議事録への記録 | □ |
| 本番リリース後の運用開始条件を合意しているか | 「何ができたら運用開始か」の定義 | □ |
| 持ち越しバグの一覧を顧客が認知・承認しているか | リリース判定資料への署名または確認メール | □ |
| リリース後のサポート体制を顧客に説明しているか | 問い合わせ窓口・対応SLAの説明完了 | □ |
よくある失敗
UAT で「操作の確認はした」が、顧客側は「本番リリースのOKサインを出した」とは思っていなかったというケースは珍しくありません。UATの完了と本番リリースの承認は別物として扱い、明示的に本番リリースへの「承認」を取得するステップをプロセスに組み込んでください。
リリース判定会議でチェックリストを活用する方法
会議前に準備すること
チェックリストを会議の場で初めて埋めようとすると、確認作業に時間がかかり議論が深まりません。前日までに担当者がチェックリストの各項目を確認し、「OK/NG/確認中」を記入した状態で共有することが基本です。
会議前の準備：
- リリース判定資料にチェックリストを含める
- NGまたは確認中の項目を事前に洗い出す
- リリース判定の権限者を明確にする（NGがあっても「それでもリリースする」と言える人を決めておく）
会議中の進め方
リリース判定会議は、単に全項目がOKか確認する場ではありません。NG項目がある中でどう判断するかを決める場なのです。以下の順序で進めると議論が迷走しにくくなります。
- 品質の確認（10分）：残バグの重大度と件数を確認
- 残課題の確認（10分）：判断待ち課題の解決状況を確認
- 顧客合意の確認（5分）：承認取得状況を確認
- 総合判断：GO/NO-GOの決定（10分）：全員で共有した上で権限者が判断
NGの項目があっても、リスクを受け入れてGOにする判断もあります。その場合は「誰が・何のリスクを・どんな条件で受け入れるか」を議事録に残してください。これが後のトラブル発生時の根拠となります。
NGが出たときの対応パターン
品質観点でNGが出た場合
- クリティカルバグが残っている：リリース延期を選択するか、修正完了の目処を明確にして再判定日を設定する
- テスト消化率が基準未達：未消化テストのリスク評価を行い、リリース後のモニタリング強化を代替条件として提示する
残課題観点でNGが出た場合
- 判断待ち課題がある：判断者を今すぐ会議に巻き込み、その場で解決するか、次バージョン持ち越しの合意を取る
- 対応中タスクがリリース範囲に影響する：タスクの完了確認後に再判定する日程を設定する
顧客合意観点でNGが出た場合
- UATサインが取れていない：リリース延期が最も安全。急ぐ場合は顧客の責任者から書面承認を取得する
- 持ち越しバグの合意がない：リリース判定会議に顧客担当者を同席させ、その場で内容を確認してもらう
まとめ：リリース判定は「感覚」から「基準」へ
リリース判定の失敗は、多くの場合、その場の空気や「きっと大丈夫」という感覚判断から起きます。この記事で紹介した3観点（品質・残課題・顧客合意）の構造化チェックリストを使えば、判断の属人性を排除し、誰が見ても同じ基準でGO/NO-GOを決められるようになります。
チェックリスト活用のポイント：
- 会議前に各項目を確認し、NGを洗い出した状態で臨む
- NGがあっても「どう判断するか」を決める場として会議を使う
- GO/NO-GOの判断と根拠を必ず議事録に残す
リリース判定のプロセスを整えることは、単発のトラブル回避にとどまらず、プロジェクト全体の品質意識の底上げにつながります。品質管理の体系的な知識を身につけたい方には、受託開発の品質管理が形骸化したPMへ｜欠陥発見・是正判断・記録の3点で動かす最小ルールもあわせてご覧ください。
リリース判定の判断力をさらに鍛えたい方には、テックエイドの以下の講座が直結します。
FFF-103（品質ゲート設計）では、リリース判定の基準設計と品質ゲートの実践手法を学べます。IPJ-105（品質マネジメントケース）では、炎上プロジェクトにおける品質判断の実務事例を豊富に扱っています。
炎上プロジェクトへの対処を総合的に学びたい方は、炎上案件の症状別｜今あなたに効く鎮火講座を選ぶ完全ガイドもあわせてご覧ください。