「結合テストは通ったはずなのに、受入で次々とバグが出てきてリリースが2週間延期になった」。こんな苦い経験は、受託開発のPMなら一度はあるのではないでしょうか。
延期の原因をたどると、たいてい「受入基準が曖昧だった」「品質ゲートの通過判断が属人化していた」という2点に行き着きます。テストケースは消化したものの、何を満たせば合格なのかが言語化されておらず、発注者と「これで完了」という合意ができていなかった。だからこそ、リリース直前の受入で揉めてしまうのです。
本記事では、受入基準を「誰が・何を・どこまで満たせば合格か」という観点で書き起こすテンプレートと、3段階の品質ゲートの設計・運用方法を、現場で使える形で整理します。
なぜ受入基準は曖昧になるのか
受入基準が曖昧になる構造的な理由は、ほぼ次の3つに集約されます。
- 要件定義書の言葉をそのまま受入基準に流用しているため、「正しく動作する」「想定通りに表示される」といった、検証が難しい記述になっている
- 受入の主語、つまり誰がチェックするのかが決まっていないため、開発側は「動いたからOK」、発注者側は「業務で使えないからNG」と判断が食い違う
- どこまで満たせば合格かの線引きがないため、軽微なバグの扱いをめぐって都度交渉が発生する
リリース延期の責任を問われがちなPMの多くは、実はテストの実行段階ではなく、その手前にある合格条件の設計でつまずいています。会議の場で論点がブレるパターンとも近く、まずは判断軸を文書で固めるのが先です（参考：会議で対立を収束させるPMの論点整理術｜決まらない議論を終わらせる5ステップ）。
受入基準は「誰が・何を・どこまで」で書く
受入基準の言語化は、難しいテンプレートを使う必要はありません。次の3つの項目を埋めるだけで、合否判定が一気に客観的になります。
| 項目 | 記述例（ECサイトの注文機能の場合） |
|---|---|
| 誰が（検証主体） | 発注者側の業務担当者2名（受注担当とカスタマーサポート担当） |
| 何を（検証対象の振る舞い） | 在庫切れ商品の注文時に、エラーメッセージが画面とメールで同一文言で表示されること |
| どこまで（合格水準） | 主要5ブラウザで同一表示／文言は事前合意した「在庫切れ通知文言一覧」と一字一句一致／ログにエラーコードE-OOS-01が記録されている |
この3つの項目を、機能単位ではなく業務シナリオ単位で書くのがコツです。発注者が業務で行うことを順に並べ、各ステップにこの3項目を当てはめます。こうすることで、「動くかどうか」という技術的な視点から、「業務が回るか」というビジネス視点で会話できるようになります。
書き終えたら、必ず発注者にレビューしてもらい、合格水準の具体的な数字や文言について合意を取りましょう。このひと手間を省くと、受入段階で「思っていたのと違う」という問題が必ず噴出します。
3段階の品質ゲートをどこに置くか
受入基準だけ整えても、リリース直前まで合格判定が後ろ倒しになると延期は防げません。手前で止める仕組みが品質ゲートです。受託開発では、最低でも次の3段階を置きます。
ゲート1. 単体テスト通過ゲート（開発フェーズ末）
開発担当者がコミットする前に通すゲートです。判定責任は開発リーダーが持ちます。通過条件は「カバレッジ80%以上」「重大度がHighの未修正バグがゼロ」「コードレビュー完了」など、定量的に設定します。ここを甘くすると後工程のテストが破綻しかねません。PMとしては、数値目標について安易な妥協は禁物です。
ゲート2. 結合テスト通過ゲート（テストフェーズ中盤）
機能間の連携が業務シナリオ通りに動くかを確認するゲートです。判定責任はQAリードとPMが担います。通過条件は「全業務シナリオの主経路（ハッピーパス）が完走する」「重大度がHighまたはMediumのバグが残件ゼロ」「性能要件のしきい値をクリアする」などです。
ここで重要なのは、「残件ゼロ」の定義です。例えば、修正済みでも再テストが未実施なら未通過とする、といったルールを決めておかないと、受入テストでバグが再発する原因になります。
ゲート3. 受入テスト通過ゲート（リリース直前）
最初の章で書いた受入基準を、発注者主体で消化するゲートです。判定責任は発注者の業務責任者です。通過条件は「全シナリオが合格水準をクリアしている」「軽微なバグは、リリース後の改修計画について発注者の承認を得ている」といった項目になります。
この最終ゲートで揉めないためには、ゲート2を通過した時点で発注者に進捗状況を見せておくことが有効です。受入テストで初めて成果物を見せると、手戻りが増え、ほぼ確実にスケジュールは延びてしまいます。
品質ゲートを止血ツールとして使う
ゲートは「通過させるための儀式」ではなく、「意図的にプロセスを止めるための仕組み」と捉えるべきです。通らない時に無理に通すと、リリース後に障害となって戻ってきます。障害対応の現場の段取りについてはPMの修羅場を救うAI障害クレーム対応プロンプト術も参考にしてください。
PMがやるべきことは、ゲートを通過できない事実をいち早く発注者に伝え、リリース範囲の縮小（スコープアウト）か日程延期か、といった経営判断を引き出すことです。判断材料として、各ゲートの通過状況をダッシュボードで見える化しておくと交渉がスムーズになります。
迷ったらこの講座から始める
受入基準のテンプレートと3段階の品質ゲートは、本記事だけでも明日から書き始められます。ただし、実際の案件では「ゲート2が通らない時の発注者交渉」「軽微バグの線引き合意」「リリース後改修の責任分担」など、合意形成と撤退判断が論点になります。ここはテンプレートだけでは越えられません。
迷ったら、まず「PJM-104 実行管理の進め方」から始めてください。受入基準・品質ゲートを実行管理サイクル（計画→実行→検査→是正）に組み込む手順を、受託案件の具体例で学べます。続けて「FFF-103 品質ゲートと受入基準」で、止血と撤退判断のパターンまで踏み込むと、本記事の内容を案件に展開できる状態になります。
まとめ
- 受入基準は「誰が・何を・どこまで」の3つの観点で、業務シナリオ単位に書く
- 品質ゲートは単体・結合・受入の3段階で設け、判定責任者と通過条件を定量的に決める
- ゲートは「止めるための仕組み」と心得る。通過できない時こそ、PMが次の意思決定を引き出す重要な局面となる
リリース延期の多くは、テスト不足が原因なのではなく、その前段階にある「合格条件の設計不足」に起因します。受入の2週間前ではなく、要件定義の直後にこのテンプレートを埋めることから始めてみてください。