リリース判定とは｜出してよいかを決める基準と会議

リリース判定の会議を任されたものの、何を基準に「出してよい」と言えばよいのか分からない。そんな立場で検索した人に向けて、この記事では、リリース判定とは何か、判定の観点、基準の作り方、会議の進め方、チェックリストの例、否認になったときの動き方までを順に説明します。先に結論を言えば、リリース判定で一番大切なのは、会議の前に「こうなっていたら出さない」という条件を書き出し、関係者全員と合意しておくことです。判定の材料は表計算のシートでもそろえられます。複数人で残りの作業の担当と期限と進み具合を共有したい場合は、プロジェクト管理ツールのPinatecaを使う方法もあり、後半で使い方に触れます。

リリース判定とは何か

リリース判定とは、開発したシステムやサービス、機能の追加などを、利用者が使う本番の環境に出してよいかを決める判断のことです。製品を世に出す判断という意味で「出荷判定」と呼ぶ会社もあります。テストが終わった時点で自動的に公開されるのではなく、責任を持つ人が材料を見て「出す」か「出さない」かを決める、最後の関所だと考えてください。

国の情報システムの作り方を定めたデジタル庁の「デジタル・ガバメント推進標準ガイドライン」では、この判断を2段階に分けています。本番の環境へ移す作業を始めてよいかを決める「移行判定」と、新しいシステムに切り替えて利用を始めてよいかを決める「稼働判定」です。移行判定については、次の条件をすべて満たす場合に限って本番移行を始めると定めています。

3. 移行判定 ＰＪＭＯは、以下の条件を全て満たす場合に限り、本番移行を開始するものとする。 [1] 受入テストにおいて、要件定義に添った内容で、かつ、設定した品質基準を全て満たしたと認められる。 [2] ＰＭＯが指定したプロジェクトにあっては第三次工程レビューにおいて問題なく妥当なものと判断される。 [3] 移行計画書の内容及びリハーサルの結果が適正であると判断される。 出典: digital.go.jp

PJMO はプロジェクトを進める発注側の担当組織、受入テストは発注した側が自分で行う最終の確認テストのことです。言い換えると、移行判定では「発注側の確認テストで品質の基準を満たしたか」「本番へ移す手順と予行演習の結果に問題がないか」を確かめます。稼働判定については、本番環境へ移した結果が適正で、新しいシステムに切り替えても業務に支障が出ないと判断できる場合に、本番の利用を始めるとしています。

民間のWebサービスやアプリでは、移行と切り替えを同時に行うことが多く、2つの判定を1回の「リリース判定」にまとめるのが普通です。同じガイドラインの実践ガイドブックでも、リリース判定と稼働判定が同じになるパターンが最も多いとしたうえで、システムの刷新のように、先に新しい環境へ配置し、後から古いシステムを止めてデータを移す場合は、2つを分けて考えるよう勧めています。自分の案件がどちらの形かを、最初に確かめておきましょう。

なぜ判定の会議が必要なのか

テストが全部終わっているなら、判定の会議は要らないのではないか。そう感じる人もいるはずです。しかし実際の現場では、判定の会議が形だけのものになり、問題を抱えたまま公開して利用者に迷惑をかける例が後を絶ちません。デジタル庁の実践ガイドブックは、この点をはっきり書いています。

リリース判定、稼働判定はとかくシャンシャン会議になりがちです。特に、制度改正や機器更改でリリース日が延伸できない場合の判定会議はそのような場となります。 出典: digital.go.jp

シャンシャン会議とは、結論が最初から決まっていて、形式的に承認するだけの会議のことです。公開日が動かせない案件ほど、「ここまで来たら出すしかない」という空気になり、残っている問題が小さく見積もられます。実践ガイドブックは、判定の会議が必要な理由を、最後の最後で誤った判断をしないよう、発注者側と開発側の双方の責任者が自ら振り返るためだと説明しています。

判定の会議には、もう1つの役割があります。責任の所在をはっきりさせることです。誰が、どの材料を見て、出すと決めたのかが記録に残っていれば、公開後に問題が起きたときも、何を見落としたのかを振り返れます。逆に、なんとなく公開した案件では、原因の追及が担当者の責め合いになりがちです。

判定の会議は、立派な会議室で開く必要はありません。小さなWebサービスなら、責任者と開発の担当者と運用の担当者が15分集まり、チェックリストを1つずつ確かめるだけでも十分に機能します。大切なのは、会議の形ではなく、決まった基準で判断し、その結果を残すことです。

判定の3つの観点：品質、移行と切り替え、運用の準備

リリースしてよいかを判断するときに見る観点は、大きく3つです。実践ガイドブックは稼働判定について、開発したシステムの正しさ、移行と切り替え作業の確からしさ、稼働後の運用の準備状況の3つの観点が必要だとし、テストを重ねてきた1つ目に比べて、2つ目と3つ目は軽んじられやすいと注意しています。

観点	確かめること	材料の例
品質	計画したテストをすべて実施し、見つかった不具合が直っているか	テスト結果の報告、不具合の一覧
移行と切り替え	本番へ移す手順が正しく、予行演習で問題が出ていないか	移行の手順書、予行演習の記録、データ件数の照合結果
運用の準備	公開後に問題が起きたとき、誰がどう対応するか決まっているか	運用の手順書、連絡先の一覧、元に戻す手順

品質の観点で気をつけたいのは、数字だけで判断しないことです。実践ガイドブックは、テストの項目の多さや不具合の出た割合のような数字は目安の1つにすぎず、それだけで判断してはいけないとしています。見つかった不具合は字句どおりすべて直すべきで、「応急処置ができているので次のリリースまで」「致命的なものは手当てしたので軽いものはこのまま」といった扱いは認めないことが必要だとも書いています。操作性の改善のように次回に回してよいものは、不具合ではなく課題として別に管理するよう勧めています。

移行と切り替えの観点では、「問題ありませんでした」という報告だけで済ませず、証拠を求めることが大切です。データを移す場合は、移す前と後で件数を照らし合わせるといった機械的な確認をしたうえで、本番環境でつながりを確かめる簡単なテストまで終えておきます。

運用の準備の観点は、最も見落とされやすい部分です。公開した直後に問い合わせが来たら誰が受けるのか、障害が起きたら誰に連絡するのか、どうなったら元のシステムに戻すのか。これらが決まっていないまま公開すると、問題が起きた瞬間に現場が混乱します。元に戻す判断の基準と手順は、判定の前に必ず用意しておきましょう。

判定基準の作り方：「出さない条件」を先に書く

リリース判定の基準は、会議の当日に話し合って決めるものではありません。開発やテストが始まる前、遅くともテストの計画を立てる時点で決め、関係者と合意しておきます。実践ガイドブックは、移行判定と稼働判定のそれぞれについて、「いつ」「誰が」「何を判定するために」「どのような条件で」「どのように」判定するかを事前に定めて合意しておくよう求めています。

基準を作るときのコツは、「出してよい条件」よりも「出さない条件」を具体的に列挙することです。実践ガイドブックは、「重要な障害が未解決でないこと」のような書き方は厳密な基準ではなく、判定の直前に残った不具合の重要度を軽く付け直そうとする交渉が起きると指摘し、否認の条件を並べて、1つでも当てはまれば否認すると宣言しておくべきだとしています。

否認条件の書き方の例を挙げます。

区分	否認条件の例
品質	計画したテストのうち、実施していないものが1件でもある
品質	直っていない不具合があり、その扱いを責任者が承認していない
品質	お金、個人情報、ログインに関わる機能で、確認できていない動きがある
移行	予行演習で、手順書にない作業が発生した
移行	移す前と後のデータ件数が一致していない
運用	元に戻す手順と、戻すかどうかを決める人が決まっていない
運用	公開日に問い合わせと障害の連絡を受ける担当者がいない
合意	発注者の確認（検収）が済んでいない、または条件付きの承認の条件が満たされていない

この表のように書いておけば、会議では「当てはまるものがあるか」を1つずつ確かめるだけで判断できます。主観で「大丈夫そう」と言う余地が小さくなるため、公開日が迫っている案件でも、冷静に判断しやすくなります。

基準は開発する側とも共有します。実践ガイドブックは、判定の基準を前もって示し、どこで「だめ」を出すかを知らせておけば、開発する側がそれを満たしたうえで会議に来ることを期待できるとしています。基準が後出しにならないことは、発注する側と受ける側の信頼関係にも関わります。

判定基準書に書く項目

否認条件やチェックリストは、1つの文書にまとめて「リリース判定基準書」として残しておくと、案件をまたいで使い回せます。判定基準書という名前の決まった様式があるわけではなく、会社によっては「出荷判定基準」「移行判定基準」などと呼びます。中身は、次の6つの項目があれば実務では足ります。

1. 目的と対象。何を、どの環境に、いつ出すための判定なのか。対象の機能や版を書きます。
2. 判定会議の日時と予備日。基準を満たさなかったときに備えて、再判定の予備日も決めておきます。
3. 出席者と承認する人。最終的に「出す」と決める人の名前と役割を書きます。
4. 判定の条件。否認条件の表と、確認に使う材料の一覧です。
5. 否認や条件付きになったときの対応。延期、範囲の縮小、利用者への連絡の決め方を書きます。
6. 承認した後の手順。公開の作業の順番、公開後に確かめること、元に戻す基準と手順です。

この6項目のうち、5と6は抜けやすい部分です。承認されることだけを前提にした基準書は、否認になった瞬間に何をすればよいか分からなくなります。また、承認した後の手順がないと、公開の作業そのものが担当者任せになり、手順の抜けによる事故が起きます。

基準書は、テストの計画書と一緒に作るのが効率的です。テストの計画で「何をどこまで確かめるか」を決めるときに、「どの結果なら出さないか」も同時に決めておけば、判定の直前になって基準を考える必要がありません。基準書は判定の材料と同じ場所に保存し、承認した日付と承認した人を表紙に書いておきます。

判定の材料のそろえ方

判定会議の質は、そろえた材料の質で決まります。材料ごとに、何が書かれていれば判断できるかを押さえておきましょう。

テスト結果の報告には、計画したテストの件数、実施した件数、合格した件数、見つかった不具合の件数と、そのうち直った件数を並べます。件数だけでなく、実施していないテストがあれば、その理由と扱いを書きます。「時間が足りず実施できなかった」のか「対象の機能を今回の公開から外したので不要になった」のかで、判断は変わります。

不具合の一覧には、1件ごとに内容、重要度、直したかどうか、直した後に確かめたかどうか、担当者を書きます。直っていないものが残っている場合は、なぜ残すのか、利用者にどんな影響があるのか、いつ直すのかを添えます。重要度の付け方は、前もって決めた基準に沿っているかを確かめます。

移行の予行演習の記録には、手順書のとおりに進んだか、かかった時間、途中で起きた問題と対処を書きます。本番の作業が予定の時間内に終わるかどうかは、この記録から判断します。予行演習で時間がかかりすぎた場合は、本番の作業の時間帯や担当者の数を見直します。

運用の準備の状況は、手順書がそろっているか、担当者が手順を確かめたか、連絡先の一覧が最新かを1行ずつ確かめる形で十分です。実践ガイドブックは、運用の手順書や報告の様式、保守の連絡先に加え、移行直後の切り戻しの手順、情報セキュリティの事故への対応手順、事業を続けるための緊急時の計画の準備も確かめるよう挙げています。手順書に沿って実際に操作してみるテストも有効だとしています。

発注者の合意と検収の扱い

外部に開発を頼んでいる案件では、品質や運用の準備に加えて、発注者の合意が判定の大事な材料になります。検収とは、納品されたものが契約や要件のとおりにできているかを発注した側が確かめ、受け取ることです。受入テストの結果を発注者が確かめ、検収の手続きを終えているかどうかは、否認条件の表にも入れておきましょう。

ここで起きやすいのが、検収とリリース判定の順番が曖昧になることです。開発した側は「公開したのだから検収済み」と考え、発注した側は「公開後に問題がなければ検収する」と考えている、というずれは珍しくありません。このずれは、公開後に不具合が見つかったときに、直す費用をどちらが持つかの争いにつながります。判定の前に、検収の手続きをいつ終えるのか、条件付きの承認にした場合に検収をどう扱うのかを、双方で文字にして確かめておくことが大切です。

利用者に使ってもらう条件も合意しておきます。たとえば「最初の1週間は一部の利用者だけに公開する」「古い画面も1か月は残す」といった条件です。これらは発注者の業務や利用者への案内に関わるため、開発する側だけで決めず、判定の前に合意して判定基準書に書いておきます。

判定会議の進め方

判定会議は、準備、当日、記録の3段階で進めます。

準備の段階では、会議の数日前までに判定の材料を集め、出席者に配ります。材料は、テスト結果の報告、不具合の一覧と扱い、移行の予行演習の記録、運用の準備の状況、残っている課題の一覧の5つが基本です。当日にはじめて資料を見る形では、その場で質問が出ても答えを確かめる時間がありません。

出席者は、判定する責任者、開発の担当者、テストの担当者、運用の担当者、発注者の代表が基本です。営業や顧客対応の担当者が公開の影響を受ける場合は、その人にも出てもらいます。誰が最終的に「出す」と決めるのかは、会議の前に決めておきます。

当日の進め方の例は次のとおりです。

1. 会議の目的と、判定する責任者を確認する（2分）
2. 否認条件の表を1行ずつ読み、当てはまるかを担当者が答える（15分）
3. 当てはまるものがあれば、その扱いを話し合う（10分）
4. 判定の結果を決める（3分）
5. 決まったことと宿題を読み上げて確認する（5分）

判定の結果は、承認、条件付きの承認、否認の3つのどれかにします。条件付きの承認とは、「公開日の前日までに残り2件の不具合が直り、テストで確認できたら公開する」のように、満たすべき条件と期限と確認する人を決めて承認する形です。条件付きにする場合は、条件が満たされなかったときにどうするかまで決めておきます。ここを曖昧にすると、結局は条件を満たさないまま公開することになりがちです。

会議の後は、判定の結果、根拠になった材料、条件と宿題、出席者を記録に残します。公開後に問題が起きたときの振り返りに使えるよう、どの版の資料を見て判断したのかも分かるようにしておきましょう。

記録は、次のような短い型で十分です。

• 判定の対象：会員登録の画面の改修（版の番号）
• 判定の日時と出席者：判定する責任者、開発、テスト、運用、発注者の代表
• 判定の結果：条件付きの承認
• 条件：残っている不具合2件を公開日の前日17時までに直し、テストの担当者が確認する。満たさない場合は公開を1週間延ばす
• 根拠にした材料：テスト結果の報告、不具合の一覧、予行演習の記録（それぞれの版）
• 宿題：利用者へのお知らせの文面を責任者が前日までに確定する

この形で残しておけば、会議に出ていなかった人も、何が決まり、誰が何をするのかをすぐに確かめられます。

リリース判定のチェックリストの例

否認条件の表とは別に、会議で上から順に確かめるチェックリストを用意しておくと、確認の漏れが減ります。小さなWebサービスの機能追加を想定した例を示します。

項目	確認する内容	確認する人
テストの実施	計画したテストをすべて実施した	テストの担当者
不具合	見つかった不具合はすべて直したか、扱いを承認した	開発の担当者、責任者
受け入れ	発注者や利用部門の確認が済んだ	発注者の代表
移行の手順	手順書があり、予行演習で手順どおりに進んだ	開発の担当者
データ	移す前と後の件数を照らし合わせた	開発の担当者
元に戻す手順	戻す条件、手順、判断する人が決まっている	責任者
運用	手順書、連絡先、障害時の連絡の流れがある	運用の担当者
問い合わせ	公開日の問い合わせ窓口と担当が決まっている	顧客対応の担当者
告知	利用者へのお知らせの文面と出す時期が決まっている	責任者
公開の時間	利用者が少ない時間帯で、担当者がそろっている	責任者

最後の公開の時間は軽く見られがちですが、問題が起きたときに担当者がそろっているかどうかで、被害の広がり方が大きく変わります。休日の前日の夕方に公開して、問題が起きたのに誰も対応できない、という形は避けてください。

チェックリストは、一度作れば案件をまたいで使い回せます。公開のたびに、起きた問題や見落としを1行ずつ加えていくと、チームの経験が詰まったリストに育っていきます。

否認や条件付きになったときの動き方

判定で否認になっても、それは失敗ではありません。問題を抱えたまま公開するのを止められたのですから、判定の仕組みが正しく働いた結果です。否認になったときは、次の順で動きます。

1. 否認の理由になった項目と、直すのに必要な作業と日数を洗い出す。
2. 公開日を延ばすか、公開する範囲を絞るかを決める。問題のある機能だけを外して公開できるなら、その案も比べます。
3. 関係者と利用者への連絡を決める。公開日を告知していた場合は、延期のお知らせの文面と出す時期を決めます。
4. 次の判定の日を決める。再判定では、否認の理由になった項目を中心に確かめます。

公開する範囲を絞るのは有効な選択肢ですが、外した機能がほかの機能とつながっている場合は、外したこと自体が新しい不具合を生むことがあります。範囲を絞るときは、その形でもう一度テストすることを条件にしてください。

公開した後に深刻な問題が見つかった場合に備えて、元に戻す基準も判定の時点で決めておきます。「公開から1時間以内に決済の失敗が一定数を超えたら元に戻す」のように、数字や状況で決めておけば、担当者が迷わずに動けます。実践ガイドブックも、大規模なシステムの更改などでは、稼働の直後に深刻な障害が起きた場合の切り戻し手順が要らないかを検討しておくことが大切だとしています。切り戻しとは、新しいシステムをやめて元のシステムに戻すことです。

公開した後に確かめること

リリース判定は、公開した瞬間に終わるわけではありません。公開の直後は、テストの環境では見えなかった問題が出やすい時間です。判定の時点で、公開後に誰が何をどのくらいの間確かめるかを決めておきます。

公開の直後に確かめることの例は次のとおりです。

• 主な画面が表示され、ログインや申し込みなどの大事な操作が本番の環境で動くか
• エラーの記録が急に増えていないか
• 問い合わせの窓口に、普段と違う内容の連絡が来ていないか
• データの件数や金額の集計に、おかしな動きがないか

確かめる時間の長さは案件によって違いますが、公開から数時間は担当者がすぐ動ける状態にしておき、翌営業日にもう一度確認する形が一般的です。問題が見つかったら、判定のときに決めた元に戻す基準に照らして、戻すか、直して進めるかを決めます。

公開から数日たったら、短い振り返りの場を持つことも勧めます。判定のときに見落としていたこと、チェックリストに足りなかった項目、予行演習と本番で違ったことを出し合い、チェックリストと判定基準書に反映します。この振り返りを続けることで、次の判定はより短く、確実になっていきます。

会社の規模や案件の形による違い

リリース判定のやり方は、会社の規模や案件の形によって変わります。どの形でも、基準を先に決め、結果を記録するという原則は同じですが、重さは調整してかまいません。

大きな会社や、国や自治体の案件では、判定が2段階に分かれ、資料も会議も正式なものになります。発注者、開発会社、運用会社など複数の組織が関わるため、誰が承認するのかを契約や計画書の段階で決めておく必要があります。判定の記録は、監査や後の検証の材料にもなります。

中小企業では、責任者が開発の担当者を兼ねていることも多く、判定が1人の判断になりやすいのが弱点です。少なくとも、開発した本人とは別の人がチェックリストを確かめる形にするだけで、思い込みによる見落としは減ります。社内に別の人がいなければ、発注者の担当者に一緒に確かめてもらうのも1つの方法です。

スタートアップや、頻繁に機能を追加するWebサービスでは、毎回会議を開くと公開の速さが落ちます。その場合は、自動のテストが通ること、レビューを受けたこと、元に戻す手順があることなどを公開の条件として決め、条件を満たしたものは会議なしで出し、影響の大きい変更だけ判定の場を設ける、という使い分けが現実的です。判定を省くのではなく、判定の基準を仕組みに組み込む考え方です。

よくある失敗と防ぎ方

リリース判定でよく見かける失敗と、その防ぎ方を整理します。

失敗	起きる理由	防ぎ方
形だけの承認になる	公開日が動かせず、止める空気がない	否認条件を事前に合意し、当てはまれば止めると宣言する
不具合の重要度を直前に下げる	基準が曖昧で交渉の余地がある	重要度の付け方も事前に決め、変える場合は責任者の承認を要る形にする
運用の準備が抜ける	品質の確認だけに目が向く	3つの観点をチェックリストに分けて入れる
資料が当日に配られる	準備の期限が決まっていない	材料は数日前までに配ると計画に書く
条件付き承認の条件がうやむやになる	条件を満たさなかったときの扱いがない	条件、期限、確かめる人、満たさなかったときの扱いを記録する
結果が残らない	議事録を書く人が決まっていない	判定の結果と根拠を残す人を会議の前に決める

失敗の多くは、会議そのものではなく、会議の前の準備で決まります。基準、材料、出席者、記録の担当の4つを前もって決めておけば、判定の会議は短く、確実なものになります。

判定の材料をそろえる道具の選び方

判定の材料は、表計算のシートでそろえられます。否認条件の表、チェックリスト、不具合の一覧を1つのファイルのシートに分けて作り、会議の数日前に共有すれば、小さな案件なら十分に回ります。新しい道具を入れる手間をかけるより、決まった型を使い続けることのほうが大切です。

一方で、残っている作業や不具合が多く、複数の人が並行して直しているような案件では、表計算だけだと「今どれが終わっていて、誰が何を抱えているか」を追い切れなくなります。こうした場面では、作業を1件ずつカードにして、担当、期限、進み具合をチームで共有できるプロジェクト管理ツールを使う方法があります。

その選択肢の1つがPinatecaです。公式サイトによると、カンバン、ガントチャート、カレンダー、リストなど8種類のボードとチャットが無料プランから使えます。判定の前に残っている作業や不具合を1件ずつカードにし、「未着手」「対応中」「確認待ち」「完了」の列に並べれば、会議の場で残りの件数と担当がひと目で分かります。カードにはチェックリストを付けられ、進み具合がカードの表に出るほか、終了日を過ぎると赤く表示されます。文字、数値、日付、選択肢などの項目を自分で追加できるカスタムフィールドがあるので、「重要度」や「判定への影響」といった項目を加えて、不具合の一覧として使うこともできます。

公式の料金ページによると、5人までのチームなら期限なしで無料で、ボードは10個まで、クレジットカードの登録は要りません。6人目、または11個目のボードからはスタンダードプランになり、料金は1人あたり月額500円（税抜、年払いなら1人あたり月額400円）です。ただし、Pinateca はリリースしてよいかを判定する道具ではありません。判定の基準と結果は会議で決めて記録し、判定に向けて残りの作業を片付ける進み具合の共有に Pinateca を使う、という使い分けになります。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

外部の専門家としてリリース判定に関わる

リリース判定は、社内の人だけで行うものとは限りません。最近は、開発の一部を業務委託の技術者に任せたり、品質の確認やプロジェクトの進行を外部の専門家に頼んだりする会社が増えています。在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、発注する側と受ける側の関係が長く続く案件ほど、着手の前に「何をもって完成とし、何があったら公開を止めるか」を双方で文字にしています。基準が先にあると、受ける側は何を目指せばよいかが分かり、発注する側は検収のときに迷いません。中間の手数料がかからない直接のやり取りでは、こうした取り決めを双方で直接詰められる分、認識のずれも起きにくくなります。

判定の基準づくりやチェックリストの整備は、それ自体が外部の専門家に依頼される仕事にもなります。システムやアプリを作る案件の中身はアプリケーション開発のお仕事で、AIの導入を支援する案件で求められる進め方はAIコンサル・業務活用支援のお仕事で紹介しています。セキュリティの確認が判定の重要な材料になる案件についてはAI・マーケティング・セキュリティのお仕事が参考になります。

福祉や介護の事業所が記録の仕組みを新しくするときのように、補助金を使ってシステムを入れる場面でも、公開の前に現場で使えるかを確かめる判断は欠かせません。その流れは介護・福祉事業所のDX化2026｜IT導入補助金で介護記録を完全デジタル化で紹介しています。経営の立場からプロジェクト全体を見る力を体系的に身につけたい人には、企業の経営を診断し助言する国家資格の中小企業診断士も選択肢になります。どの立場で関わる場合でも、まずは次の公開で、否認条件を5行だけ書き出して関係者に見せるところから始めてください。

よくある質問

Q. リリース判定と出荷判定は違うものですか？

どちらも、作ったものを利用者に出してよいかを決める判断で、ほぼ同じ意味で使われます。製品を出荷する製造業の言い方が出荷判定、システムやWebサービスで使われる言い方がリリース判定です。国のガイドラインでは、本番へ移す作業を始める移行判定と、利用を始める稼働判定の2段階に分けて呼んでいます。

Q. リリース判定の基準はいつ決めればよいですか？

開発やテストが始まる前、遅くともテストの計画を立てる時点で決め、関係者と合意しておくのが基本です。会議の当日に決めると、公開日に合わせて基準が甘くなりがちです。「こうなっていたら出さない」という否認条件を具体的に並べておくと、判定の場で迷わずに判断できます。

Q. 直っていない軽い不具合があっても公開してよいですか？

国のガイドラインの実践ガイドブックでは、見つかった不具合はすべて直すべきで、軽いものをそのまま残すことは認めないよう勧めています。操作性の改善のように次回に回すのが妥当なものは、不具合ではなく課題として別に管理します。公開してよいかは、事前に決めた基準と責任者の判断に従ってください。

Q. 小さなチームでもリリース判定の会議は必要ですか？

立派な会議でなくてかまいませんが、判定の場はあったほうが安全です。責任者と開発と運用の担当者が15分ほど集まり、チェックリストを1つずつ確かめて結果を残すだけでも十分に機能します。頻繁に公開するサービスなら、自動のテストや元に戻す手順を公開の条件として決め、影響の大きい変更だけ会議を開く方法もあります。