リリース判定とは 4つの判定基準と会議の進め方・判定基準書に書くこと

「テストは終わったが、この品質でリリースしてよいのか判断できない」「リリース判定会議はあるが、結局その場の空気で決まっている」。品質保証の仕組みが定まっていない組織で、繰り返し起きる状況です。

リリース判定は、品質基準を満たしているかを審査し、承認を得てからリリースするという関門です。出荷判定、移行判定、稼働判定とも呼ばれます。

この仕組みが機能するには、判定基準と判定の仕組みの両方が具体的に決まっている必要があります。どちらかが曖昧だと、判定は形式的な手続きに終わります。

この記事では、4つの判定基準を整理したうえで、判定基準書に書く項目、会議の進め方、条件付き承認の扱い、そしてよくある失敗までを順に扱います。

確認したいポイント	結論	詳細
リリース判定とは？	出してよいかを判断する関門	品質基準を満たしているかを審査し、承認を得てからリリースする仕組みです。
4つの基準とは？	テスト・残存不具合・工程・製品	テストの十分性、残っている不具合、工程の遵守、成果物そのものの品質です。
誰が判定する？	開発とは別の立場の責任者	作った本人が判定すると甘くなります。品質保証部門や別部署が担います。
最も多い失敗は？	基準がなく空気で決まる	数値の基準がないと、納期の圧力で判断が甘くなります。事前の設定が必須です。

この記事でわかること

• リリース判定の目的と、誰が判定すべきかという役割の考え方
• テスト品質・残存不具合・プロセス品質・プロダクト品質という4つの基準
• 判定基準書に記載する項目と、事前に答えておくべき5つの問い
• 判定会議の開催タイミング、出席者、当日の進め方と記録の残し方
• 条件付き承認の扱い方と、判定が形骸化する原因への対策

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や移行の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。 社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

リリース判定とは

リリース判定は、開発したソフトウェアを本番環境へ出してよいかを審査し、承認する手続きです。品質保証部門が審査を行い、利用者が使用する上で支障がないことが承認された上でリリースが実施されるという形が一般的です。

呼び方は組織によって異なります。出荷判定、移行判定、稼働判定。いずれも本質は同じで、品質の悪いものを出さないための関門という役割です。

何のための仕組みなのか

目的は、品質の悪いソフトウェアの出荷を止めることです。テストで見つかった不具合をすべて直すことが目的ではありません。

どのようなソフトウェアにも不具合は残ります。問題は、残っている不具合が業務に支障を与える水準かどうかです。この判断を、事前に定めた基準に照らして行います。

基準がなければ判定はできません。「だいたい大丈夫そうだ」という判断は、判定ではなく推測です。納期が迫っている状況では、この推測が必ず甘い方向に傾きます。

誰が判定するのか

開発した本人や開発チームだけでは判定できません。自分が作ったものを評価すると、判断が甘くなります。

品質保証部門を持つ組織では、その部門が審査を担います。持たない組織では、開発とは別の部署、あるいは上位の責任者が判定者になります。

重要なのは、リリースを止める権限がある人が判定することです。止める権限のない人が判定役になっている場合、その判定は機能しません。発注側であれば、最終的な検収の判断がこれに相当します。

判定会議の副次的な効果

見落とされやすい観点です。判定会議には、基準を満たしているかを確認する以外の効果があります。

プロジェクトの関係者が判定基準を満たすことを約束し、その実現に向けて努力するという構図が生まれます。判定の場があること自体が、現場に規律をもたらす足がかりになります。

基準が事前に示されていれば、開発側はそれを目標として動けます。「何を達成すればリリースできるのか」が明確になることで、作業の優先順位も定まります。

テスト完了との違い

混同されやすい点です。テストが完了したことと、リリースしてよいことは別の判断です。

テストの完了は、計画したケースを消化し、結果を報告した時点で成立します。そこで判明した品質の水準が、リリースに足るかどうかは別途の判断になります。

テスト結果報告書が判定の入力、判定結果が出力という関係です。テストの担当者は事実を報告し、判定者はそれをもとに可否を決める。この役割の分離が、判定を機能させる前提になります。

発注側の立場では、受入テストの完了とその合否判定も別の手続きとして扱います。テストを実施した現場の担当者と、検収を判断する責任者は同一である必要はありません。

4つの判定基準

判定の基準は、4つの観点に分けて設定するのが実務的な整理です。1つの指標だけで判断すると、見落としが生じます。

基準1｜テスト品質

十分にテストしたかを見る観点です。テストが足りていなければ、不具合が少ないという結果は意味を持ちません。

確認するのは、計画したテストケースの消化率、テストケースの網羅性、規模に対するテスト件数の密度です。正常系だけでなく異常系が含まれているかも確認します。

「テストが少ないから不具合も少ない」という状態を検出するための観点です。残存不具合の基準だけでは、この状態を見抜けません。

基準2｜残存不具合

未解決の不具合が、リリースを妨げる水準かを見る観点です。件数だけでなく重要度で判断します。

一般的な基準は、重大な不具合が0件であること、軽微な不具合については対応方針が合意されていることです。すべてを解消するという基準は、現実的ではありません。

あわせて、不具合の検出の推移も見ます。テスト終盤でも新規の検出が減っていない場合、潜在的な問題が残っている可能性が高くなります。

基準3｜プロセス品質

決められた工程を守って作られたかを見る観点です。成果物の品質は、工程の品質に依存します。

確認するのは、設計レビューが実施され指摘が解消されているか、コードレビューが行われているか、変更管理の手順が守られているか、各工程の成果物が承認されているかです。

ここが守られていないと、テストで検出できない問題が残ります。レビューを省略して作ったものは、テストの網羅性にも影響します。

基準4｜プロダクト品質

成果物そのものの性質を見る観点です。テストの結果ではなく、作られたものの構造を評価します。

確認するのは、性能が要件を満たしているか、セキュリティ上の問題がないか、保守できる構造になっているか、ドキュメントが揃っているかです。

この観点が最も抜けやすい部分です。機能が動くことの確認に集中すると、性能やセキュリティ、保守性の評価が漏れます。要件の書き方については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

4つを組み合わせて見る理由

単独の指標では、品質を誤って評価してしまう組み合わせがあります。実際に起こるパターンを整理します。

不具合が少ないのに品質が悪い場合

残存不具合が0件でも、テスト品質が低ければ意味がありません。探していないから見つかっていないだけという状態です。

この状態は、テストケースの密度を見ることで検出できます。規模に対してケース数が極端に少ない、あるいは異常系が含まれていない。テスト品質の基準を併せて設けることで防げます。

逆のパターンもあります。不具合が多く出ているのは、丁寧にテストしているからという場合です。この場合、検出数だけを見て品質が悪いと判断するのは誤りになります。

テストは十分だが構造に問題がある場合

機能はすべて動くが、保守できない、性能が出ない、脆弱性があるという状態です。テストの結果だけでは検出されません。

プロダクト品質の観点が必要になるのはこのためです。成果物そのものの構造を評価するという視点がないと、稼働後に問題が現れます。

プロセス品質も同じ役割を果たします。レビューを省略して作られたものは、テストで問題が出なくても、後の保守で困ることになります。

4象限で状態を把握する

テスト品質と残存不具合を2軸に取ると、状態が4つに分かれます。これは実務でよく使われる整理です。

• テスト十分・不具合少 → 品質良好と判断できる。最も望ましい状態
• テスト十分・不具合多 → 品質に問題がある。原因分析が必要
• テスト不足・不具合多 → テストを続ければさらに出る可能性が高い
• テスト不足・不具合少 → テスト不足の疑い。品質は判断できない

4つ目を良好と誤解しないことが最も重要です。この状態でリリースすると、稼働後に不具合が集中します。

判定基準の設定方法

基準は数値で定めます。「十分にテストされていること」では判定できません。

数値で定める

各観点について、満たすべき水準を数値または明確な条件で書きます。

【判定基準の設定例】

テスト品質

　・計画したテストケースの消化率　100%

　・異常系のケースが全体の30%以上を占める

残存不具合

　・重要度A（業務停止級）　　0件

　・重要度B（回避策あり）　　0件

　・重要度C（軽微）　　　　　対応方針が合意済み

プロセス品質

　・設計レビューの指摘がすべて解消済み

　・変更管理の記録が残っている

プロダクト品質

　・主要処理の応答時間が3秒以内

　・脆弱性診断で高リスクの指摘が0件

この一覧が判定のチェックリストになります。会議では、各項目を満たしているかを順に確認するだけで済みます。

実績データを参照する

社内に基準がない場合、公開されている実績データを出発点にできます。

IPA（情報処理推進機構）のソフトウェア開発分析データ集では、累計5,546プロジェクトの定量データが分析されています。2022年版では、リリース後6か月間の発生不具合密度が、新規開発で中央値0.010件/KSLOCという実績が示されています。

IPAはこれを「不具合は10万行で1個（中央値）、1万行で1個（平均値）」という相場観として要約しています。自社の実績がこの水準から大きく外れていないかを確認する材料になります。

中央値をそのまま合格ラインにするのは適切ではありません。分布の幅を確認し、自社の要求水準に応じて設定します。

リリースの種類で基準を分ける

すべてのリリースに同じ基準を当てると、運用が回らなくなります。種類によって基準と手続きを分けます。

• 新規リリース：全項目を満たすことを求める。判定会議を開催する
• 機能追加：影響範囲に応じた基準。関係者による書面での承認
• 不具合修正：修正内容と影響範囲の確認のみ。担当責任者の承認
• 緊急対応：事後の報告を条件に、簡易な手続きで実施

4段階程度に分けておくと現実的です。すべてに会議を求めると、軽微な修正が出せなくなります。逆にすべてを簡易にすると、大きな変更を止められません。

判定基準の設定や体制づくりからご相談いただけます 観点は分かっても、自社でどの水準を基準にすべきかの判断は別の問題です。 品質管理の設計からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

判定基準書に書く項目

基準と手続きを1つの文書にまとめます。判定基準書、リリース判定基準書といった名称で作成します。

記載項目の一覧

次の項目を埋めれば実用に足ります。A4で数ページに収まります。

1. 対象システムとリリース内容

2. リリース予定日時

3. 判定会議の開催日時と出席者（予備日も設定）

4. 判定者と承認者

5. 判定基準（4つの観点ごとに数値で）

6. 判定の根拠となる資料（テスト結果報告書など）

7. 各基準の充足状況（会議前に記入）

8. 承認時・否決時の対応

9. 判定結果と承認者の署名

3の予備日を設定しておくのが実務上の配慮です。テストの遅れで判定会議が延期になることは頻繁に起こります。予備日がないと、リリース日全体が押します。

7は会議前に記入します。テスト結果の報告を受けてから記入できる項目です。会議の場で集計を始めると、時間内に終わりません。

5つの問いに答えておく

判定の仕組みを設計する際、次の5点を決めて合意しておくことが求められます。

• いつ判定するのか：どの工程が完了した時点か
• 誰が判定するのか：判定者と、最終の承認者
• 何を判定するのか：どの観点で評価するのか
• どのような条件で判定するのか：基準となる数値と条件
• どのように判定するのか：会議形式か書面か、記録の方法

この5点が決まっていれば、判定の仕組みは成立します。逆に、どれか1つでも曖昧なら、その場の判断に委ねられることになります。

セキュリティの観点を含める

プロダクト品質の一部として、セキュリティを明示的に含めることが近年求められています。

一般社団法人ソフトウェア協会（SAJ）はソフトウェア出荷判定セキュリティ基準チェックリストを公開しています。セキュリティを品質の一環として捉え、開発現場での仕様策定や出荷テストの際の評価項目として利用できるよう構成されたものです。

このチェックリストはクリエイティブコモンズライセンスにもとづき、誰でも自由に利用でき、改変や商用利用も可能とされています。企画から運用までのライフサイクルの中で、管理対象項目と管理手法が定義されています。

自社の判定基準にセキュリティの項目がない場合、こうした公開資料から必要な項目を取り込めるため、ゼロから作る必要はありません。

判定会議の進め方

会議の運営方法も、あらかじめ決めておきます。手探りで進めると時間内に結論が出ません。

開催のタイミングと出席者

テスト結果の報告が出た後、リリース日の数日前に開催します。当日や前日では、否決になった場合に対応できません。

出席者は、判定者、開発の責任者、テストの責任者、業務部門の代表、運用の担当者です。承認の権限を持つ人が出席していることが必須条件になります。

権限者が欠席する会議では、結論が持ち帰りになります。代理での承認を認めるかどうかも、事前に決めておきます。

事前に配布する資料

会議の場で資料を読み始めると、時間内に終わりません。数日前に配布し、各自が目を通した状態で臨みます。

配布するのは、判定基準書（充足状況を記入済み）、テスト結果報告書、未解決の不具合一覧、リリース手順書です。未解決の不具合一覧には、重要度と対応方針を必ず記載します。

質問は事前に受け付ける運用にすると、会議が効率化します。事実確認に類する質問は、会議前に解消しておけます。

当日の進め方

判定基準の一覧に沿って、上から順に充足状況を確認します。議論を先にせず、事実の確認から入ります。

満たしていない項目があれば、そこで初めて議論します。なぜ満たせなかったのか、リリースへの影響はどの程度かを確認し、条件付きで承認するか否決するかを判断します。

時間は30分から1時間に収めます。それ以上かかる場合は、事前の資料が不足しているか、基準が曖昧です。

記録の残し方

判定の結果はチェックリストの形で記録に残します。口頭での承認だけでは、後から根拠を示せません。

記録するのは、実施日、出席者、各基準の充足状況、判定結果、条件付き承認の場合はその条件、承認者です。

この記録が、稼働後に問題が起きた際の根拠になります。どの基準で承認したのか、どのリスクを認識した上でリリースしたのかが追えます。

条件付き承認と否決時の対応

すべての基準を満たさないままリリースする判断もあり得ます。ただし条件が必要です。

条件付きで出すという判断

基準を満たしていないが、事業上の理由でリリースするという決定です。特別採用という呼び方もされます。

法改正への対応、契約上の期限、競合の動き。リリースを遅らせることの損失が、品質リスクを上回る場合に検討されます。

判断の材料は3点です。テストの状況、潜在している不具合の見込み、残存している不具合の内容。この3つを踏まえて、許容できるリスクかを評価します。

条件付き承認の要件

「とりあえず出す」との違いは、条件が明記されているかです。次の4点を必ず定めます。

• どのリスクを認識しているか：何が起こりうるかを明記する
• 回避策：問題が起きた場合、運用でどう回避するか
• 対応期限：いつまでに解消するか
• 承認者：誰がこの判断の責任を負うか

4つ目が最も重要です。責任者が明示されていない条件付き承認は、事実上の責任回避になります。問題が起きたときに誰も責任を取らない状態を作ってしまいます。

あわせて、利用者や業務部門への周知も条件に含めます。既知の問題があることを知らされていない現場が、その問題に遭遇するのは避けるべき事態です。

否決した場合の進め方

否決の場合、次のリリース日を決めるところまでが会議の役割です。「延期」で終わらせると、いつリリースできるのか分からなくなります。

決めるのは、解消すべき項目、対応の期限、再判定の日程です。再判定で何を確認するかも明確にします。全項目を再確認するのか、解消した項目だけを見るのか。

否決を否定的に扱わないことも重要です。否決できる仕組みがあること自体が、品質保証が機能している証拠です。一度も否決されたことがない判定会議は、機能を疑う余地があります。

よくある失敗

判定の仕組みがあるのに機能しないというケースには、共通の原因があります。

基準がなく空気で決まる

最も多い失敗です。判定会議は開かれるが、数値の基準がないという状態です。

結果として、「大きな問題は出ていないので進めましょう」という判断になります。納期が迫っていれば、その圧力が判断を左右します。

対策は、基準を事前に文書化することです。テストが始まる前に基準を決めておけば、結果を見てから基準を作るという事態を避けられます。

判定が形式的になる

基準はあるが、確認が形だけという状態です。チェックリストに機械的に丸を付けて終わります。

原因は2つあります。基準が実態に合っていない、あるいは判定者が内容を理解していない。どちらも、判定に意味がなくなります。

対策は、基準を定期的に見直すことです。過去のリリースで問題が起きた項目を基準に追加し、機能していない項目は削ります。

判定日が動かせない

リリース日が先に決まっていて、判定は通過儀礼という状態です。否決という選択肢が実質的に存在しません。

この場合、判定は品質保証の仕組みとして機能しません。基準を満たしていなくても出すことが前提になっているためです。

対策は、リリース日に余裕を持たせることです。判定日とリリース日の間に数日の余裕があれば、軽微な修正には対応できます。あわせて、延期の判断ができる体制を整えます。

条件付き承認が常態化する

毎回条件付きで承認され、条件が守られないというパターンです。対応期限を過ぎた課題が積み上がります。

この状態が続くと、基準そのものが意味を失います。守られない基準は、設定していないのと同じです。

対策は、条件の履行を追跡することです。次回の判定会議で、前回の条件が解消されたかを最初に確認します。未解消の課題が一定数を超えたら、新規のリリースを止めるというルールも有効です。

中小企業での現実的な運用

大企業と同じ体制を作る必要はありません。規模に見合った形で十分に機能します。

品質保証部門がない場合

専門の部門を置けない組織では、判定を2部署の会議や個別の判断で行うという方法があります。

開発担当と業務担当が同席して確認する、あるいは上位の責任者が1人で判断する。開発した本人以外が判定するという条件を満たせば、形式は問いません。

発注側の立場であれば、受入テストの合否判定がリリース判定に相当します。この判定を自社が主体的に行うことが、実質的な品質保証になります。

簡易な様式で始める

A4で1枚のチェックリストでも成立します。凝った文書を作ろうとすると、作成段階で止まります。

最低限必要なのは、4つの観点それぞれについての基準と充足状況、判定結果、承認者の欄です。これだけあれば、判定の記録として機能します。

表計算ソフトで1件1行として管理する方法も実用的です。リリースごとに行を追加していけば、履歴がそのまま蓄積されます。

記録を蓄積して基準を育てる

最初から適切な基準を設定することはできません。実績を積みながら調整していきます。

記録すべきは、判定時の状況とリリース後に実際に起きた問題です。「この水準で承認したら、稼働後に問題が出た」という対応関係が見えてくれば、基準を厳しくする根拠になります。

年に1度は基準を見直します。技術も体制も変わるため、固定したままでは実態と合わなくなります。委託時の役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

まとめ

リリース判定は、品質基準を満たしているかを審査して承認する関門です。判定基準と判定の仕組みの両方が具体的に決まっていることが、機能する条件になります。

基準は4つの観点で設定します。テスト品質、残存不具合、プロセス品質、プロダクト品質。1つの指標だけでは、テストが少ないから不具合も少ないという状態を見抜けません。

判定の仕組みを設計する際は、いつ、誰が、何を、どのような条件で、どのように判定するのかという5点を決めて合意しておきます。どれか1つでも曖昧なら、その場の判断に委ねられます。

条件付きで承認する場合は、認識しているリスク、回避策、対応期限、責任者の4点を必ず明記します。これがない条件付き承認は、事実上の責任回避になります。

まずは直近のリリースについて、4つの観点それぞれの基準を数値で書き出してみてください。書けない項目があれば、そこが判定できていない部分です。

開発と品質管理の進め方から、無料で相談できます リリースしてよいか判断に迷っている、社内に品質管理の知見がなく不安があるといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎