リリース可否判定パターン

定義

リリース可否判定とは、ソフトウェアを本番環境に展開（リリース）してよいかを、事前に定義した基準と実績を照合して意思決定するプロセス。「品質目標を達成しているか」だけでなく「リリース後の準備が整っているか」まで含めて判断する。

なぜ重要か

リリース判定を「バグがなければOK」という単純な条件で行うと、本番での障害対応体制が整っていない状態でリリースされるリスクがある。また、利用者が新システムの操作を習熟していないままリリースすると、操作ミスや問い合わせ急増が発生する。

リリース判定はゲートであり、通過すれば以降の問題はすべてリリース後の運用問題として扱われる。したがって、判定基準の設計がリリース後の品質を大きく左右する。

リリース判定の2軸

軸1：製品品質の充足

品質指標が基準値内か（不具合件数・重大度分布・カバレッジ等）
既知の未解決不具合のリスク評価
テスト完了基準の達成（→品質指標）

軸2：リリース後の準備状況

運用手順書の整備
サポート体制の確立（問い合わせ窓口・障害対応フロー）
ロールバック計画の準備
利用部門の新システム習熟度（教育・トレーニングの完了）
監視・アラートの設定

判定基準の事前定義

リリース判定基準はプロジェクト開始時に定義する。リリース直前に基準を作ると、現状に合わせて基準を緩めるバイアスが働く。

リリース可否チェックリスト（例）
品質面：
  □ 重大不具合（P1）件数：0件
  □ 高優先不具合（P2）件数：3件以下
  □ テストカバレッジ：80%以上
  □ 性能テスト合格

準備面：
  □ 運用手順書レビュー完了
  □ 監視アラート動作確認完了
  □ ロールバック手順確認済み
  □ 利用部門トレーニング完了（受講率90%以上）
  □ サポート窓口の開設確認

利用部門の習熟度をリリース条件に含める理由

新システムへの移行で発生する問題の多くは、システムの欠陥ではなく操作ミス・理解不足に起因する。利用部門の習熟度を条件に含めることで、リリース直後のサポート負荷急増と利用者起因のデータ破損を予防できる。

適用場面

プロジェクト計画時：リリース判定基準をプロジェクト計画書に記載し、ステークホルダー合意を得る
リリース直前：チェックリストを用いて判定会議を実施し、判定結果と根拠を記録する
段階的リリース設計：カナリアリリース・フィーチャーフラグを使い、リスクを段階的に開放する

出典

ソフトウェア品質保証の極意 — 第4章 4.8「リリース可否判定」（極意42）、Column「利用部門の新システム習熟度はリリース判定条件とせよ」

release criteria