総合テスト・UATの炎上を防ぐ「トリアージ」実践術｜終わらないバグ修正を止める交渉テンプレ
「もう間に合わないかもしれない……UATでバグが多発して出口が見えない」
「リリース直前なのに、『出たバグは全件直せ』と迫られて現場が崩壊しそう……」
「直しても直してもバグが減らない……」
プロジェクト終盤、このままでは「間に合わない」と分かっていながら、無理な残業や精神論で乗り切ろうとしていませんか？
この状態を放置して、「モグラ叩き」のように、直しても直しても新たなバグが発生し続ける状況に陥ると、修正によるデグレ（エンバグ）が連鎖し、いつまでも品質は安定しません。最終的にはスケジュールが破綻し、現場が極限まで疲弊した結果、致命的な本番障害を引き起こすリスクすらあります。
本記事では、多くの炎上プロジェクトの現場で培われた「プロジェクトを確実に終わらせるためのトリアージ術」と、顧客から合意を勝ち取る「選択肢提示型の交渉テンプレート」を解説します。
なお本記事では「トリアージ」を、バグを優先度だけでなく“修正するかどうか”まで含めて判断することとして扱います。
なぜ総合テスト〜UATでプロジェクトは炎上・崩壊するのか？
システム開発において、要件定義の迷走や設計の手戻りなど、トラブルの種は各フェーズに潜んでいます。しかし、現場が最も疲弊し、デスマーチに陥りやすいのは間違いなく「総合テストからUAT」の終盤戦です。
このフェーズでプロジェクトが崩壊する真の原因は、「バグの数が多いから」ではありません。
最大の問題は、「どうなったらこのテストは終わるのか（＝収束の定義）」が決まっていないことです。
「全部直す」という前提が引き起こす炎上パターン
収束ラインが決まっていないと、PMも顧客も「見つかったバグはすべて直さなければならない」という強迫観念に囚われます。一見正しいように見えますが、これが炎上の引き金になります。
- 総合テストが単なる「バグ修正フェーズ」化する
本来の「システム全体を通した確認」という目的を見失い、目の前のバグを直すだけの期間になります。無理な修正がデグレを生み、品質が泥沼化します。 - UATで品質問題が爆発する
総合テストでの全体確認が不十分なままUATに突入するため、顧客が実際の業務シナリオを通した瞬間に、クリティカルな問題が多発します。 - スケジュールと共に現場が破綻する
リリース日が迫る中、物理的に全件修正が不可能になります。ここで初めてパニックに陥り、PMは顧客との板挟みに苦しみ、現場は休日出勤や無理な残業でカバーしようとして崩壊していきます。
総合テストとUATの「本来の役割」の違いを再認識する
炎上を防ぐ第一歩は、各フェーズの「本来の目的」を整理し、ステークホルダー間で認識を合わせることです。総合テストとUATでは、目的も判断基準も全く異なります。
| 項目 | 総合テスト（結合後期〜総合） | UAT（ユーザー受け入れテスト） |
|---|---|---|
| 主目的 | システムが仕様通りに動き、全体として破綻なく連携できるかの確認 | 本番環境にリリースして、実際の業務が回るか（ビジネス的許容）の確認 |
| 視点 | 開発側（技術的視点） | 顧客・ユーザー側（ビジネス的視点） |
| 判断基準 | 仕様を満たしているか、非機能要件（性能・セキュリティ）に問題ないか | 日々の業務が滞らないか、運用でカバー（回避）できるか |
目的が違うということは、「どこまで直すべきか」という判断基準も違うということを、PMは強く認識しなければなりません。
トリアージの本質は「優先順位付け」ではなく「収束させる意思決定」
医療現場で使われる「トリアージ」という言葉を開発現場でもよく使いますが、多くのPMが誤解しています。
トリアージとは、「バグを直す順番（優先順位）を決めること」ではありません。 プロジェクト終盤におけるトリアージの本質は、「プロジェクトを終わらせるための意思決定」です。
限られた時間とリソースの中で、すべてのバグを直すことは不可能です。「全部直して完璧な状態でリリースする」という幻想を捨て、「どこで止めるか（どこまでなら許容してリリースするか）」という現実解を選ぶことがPMの最大の責務です。
【フェーズ別】終わらせるためのトリアージ実践手法
では、具体的にどのように判断を下していくのか。フェーズ別に実践手法を解説します。
総合テストにおけるトリアージ（収束ラインの定義）
総合テストでバグ発生曲線が減らず、新規発生数がクローズ数を上回る状態が続いた場合、通常の修正対応では収束しないと判断します。
この段階では、直ちに「直すバグ」と「直さない（後回しにする）バグ」の選別に入る必要があります。
- 修正対象を絞る
「業務に影響しない軽微な画面のズレ」「月に数回しか発生しない特定条件のレアケース」などは勇気を持って後回しにします。 - テスト観点を整理する
そもそも不要なテストをしていないか、網羅率にこだわりすぎていないかを見直します。 - 現実的な収束ラインを再定義する
「バグ0」ではなく、現実的なゴールを設定します。- 例：「業務を停止させるクリティカルバグ（Severity High）が0件であること」
- 例：「回避策のない重大バグが〇件以下であること」
注意点・前提条件
- これらの判断は、現場のエンジニア任せにするのではなく、PM（または品質責任者）が主体となって行う必要があります。
- 後回しとしたバグについては、決して放置するのではなく、リリース後対応や運用での回避策をセットで整理しておくことが大前提です。
UATにおけるトリアージ（リリース可否の判断軸）
UATでは、視点を「技術」から「ビジネス」へと切り替えます。バグを洗い出すこと自体が目的ではなく、「この状態で業務に耐えられるか」を判断するフェーズです。
そのため、以下の3点を判断軸とします。
- 業務影響： そのバグが存在することで、日々の業務がどれほど滞るか。
- 運用回避可否： システムを修正しなくても、運用ルールや手作業でカバー（回避）可能か。
- リリース後対応の許容： 本番稼働後に修正パッチを適用することで、許容できる範囲か。
「未修正バグがある＝リリースNG」ではありません。業務影響が小さく、運用回避が可能であれば、それは「既知の課題」としてリリース後に対応する前提で合意すべきものです。
注意点・前提条件
- これらの判断は、最終的には顧客（業務部門）が意思決定します。開発側は、その判断に必要な情報と選択肢を提示する役割を担います。
- ただし、業務停止や重大なデータ不整合につながる不具合は、原則としてリリース不可とします。
顧客交渉で失敗する理由と、合意を勝ち取る「交渉テンプレート」
トリアージの判断を下しても、顧客と合意できなければ意味がありません。
顧客から「バグが残っているのにリリースするのか！」と詰められた時、「……はい、全部直します。頑張ります」と答えてしまうPMがいます。これは顧客想いなのではなく、PMとしての思考停止です。 技術の話（バグの原因や修正の難易度）ばかりを説明し、顧客に「どうするか」の選択肢を与えないから交渉が行き詰まるのです。
顧客と合意するための鉄則は、「選択肢を提示し、それぞれのビジネス的影響を説明して、顧客に選ばせる（判断させる）」ことです。
最終的な意思決定は顧客側に委ねられますが、その判断材料を提示することがPMの役割です。
【コピペOK】「選択肢×影響」で選ばせる交渉テンプレート
導入トーク例： 「現在、未修正の課題が〇件残っています。リリースに向けて、以下の3つの選択肢をご提案します。ビジネスへの影響をご考慮いただき、どの方針で進めるかご判断をお願いいたします。」
| 選択肢 | 対応プラン | 具体的な対応内容 | ビジネスへの影響 （メリット・デメリット） |
|---|---|---|---|
| ① | 全件対応プラン (スケジュール影響大) | すべての課題を修正し、再テストを行ってからリリースする。 | 【メリット】 すべてのバグが解消された状態でリリースでき、稼働後の運用負荷がかかりません。 【デメリット】 リリース時期が最低でも〇週間延期となります。 |
| ② | 優先対応プラン (★推奨) | 業務影響が高い（運用回避不可）Aランクの課題〇件のみ修正し、残りは次期フェーズに回す。 | 【メリット】 当初の予定通り〇月〇日にリリース可能です。本番業務は開始できます。 【デメリット】 Bランク以下の課題については、当面は手作業（運用回避手順）でカバーしていただく必要があります。 |
| ③ | 一部機能見送りプラン | 問題が多発している「〇〇機能」のリリースを見送り、安定機能のみを先行リリースする。 | 【メリット】 予定通り主要機能はリリース可能です。 【デメリット】 〇〇機能については当面、現行システム（または手作業）を残していただく必要があります。 |
※状況に応じて、これらのプランを組み合わせることも可能です。
「選ばせる設計」にすることで、顧客も「品質・納期・コストはトレードオフである」という現実に向き合うことになります。
崩壊しかけた現場を立て直す「運用ルール」と「最終手段」
すでに現場が炎上し始めている場合、即座に以下の運用ルールを導入して「止血」を行ってください。
- デイリートリアージの実施
毎日夕方に15〜30分、PM・PL・顧客担当者で集まり、その日発生したバグの「対応要否」をその場で判断します。持ち帰って悩む時間をなくし、意思決定のスピードを上げます。 - バグ流入制御（フリーズ）
修正に伴う新たなバグ（エンバグ）を防ぐため、影響範囲の大きい修正は一旦凍結（フリーズ）します。※ただし、業務停止に関わる重大バグについては例外とし、対応を継続します。 - テスト範囲の戦略的割愛
リスクの低い機能のテストは思い切って割愛し、重要機能にリソースを集中させます。
それでも間に合わない時の「最終手段」
運用ルールを徹底してもスケジュールに間に合わない場合、PMは以下のような「重い決断」を顧客に提案しなければなりません。
- スコープ削減： リリース予定だった機能の一部を完全に切り捨てる。
- 段階リリース： 必須機能のみをPhase1としてリリースし、残りをPhase2とする。
- フェーズ分割（リスケ）： 稼働日そのものを見直し、無理なリリースによる本番障害を防ぐ。
これらの選択肢も、「選択肢×影響」の形で提示し、顧客と合意形成を行います。
これはPMにとって非常に苦しい決断ですが、品質の低いシステムを無理に本番稼働させ、業務を停止させる「最悪の事態」を回避するための重要な責務です。
まとめ：PMの最大の仕事は「意思決定」と「合意形成」
総合テスト以降の終盤戦において、「見つかったバグを全部直す」というアプローチは必ず破綻します。
- 目的を混同しない： 総合テスト（技術的確認）とUAT（ビジネス的判断）の違いを理解する。
- 収束ラインを引く： トリアージは優先順位付けではなく、「どこで終わらせるか」の意思決定である。
- 顧客に選ばせる： 「全部直す」思考を捨て、「選択肢×影響」を提示して合意形成を図る。
プロジェクトマネージャーの仕事は、自らコードを書くことでも、徹夜でテストをすることでもありません。 「現実的な意思決定」を下し、ステークホルダーとの「合意形成」をやり抜くことです。
そして、炎上しかけた現場で求められるのは、完璧さではなく「終わらせる勇気」です。この2つをやり切れるかどうかが、プロジェクトの成否を分けます。
おわりに：それでも「毎回炎上する理不尽な環境」が変わらないなら
ここまで、PMとしての意思決定と交渉術をお伝えしてきました。しかし現実には、どれだけ正しい選択肢を提示しても聞く耳を持たない顧客や、「気合で全部やれ」としか言わない上層部が存在するのも事実です。
もしあなたが、真っ当な交渉すら成り立たない環境で毎回疲弊しているのなら。それは、あなたの問題ではなく環境の問題である可能性が高いです。
あなたのPMとしてのスキルは、本来もっと価値を発揮できるはずです。環境を変えることも、一つの正しい「意思決定」です。
例えば、社内SE（社内システム企画・推進）という選択肢があります。ビジネス部門と直接対話しながら、リリースや優先度の判断に主体的に関われる環境です。
今の環境で消耗し続ける前に、「他にどんな選択肢があるのか」を一度見てみてください。【PM・リーダー向け】UATでデグレ連発は撤退のサイン？炎上現場を生き抜いたあなたが社内SEで無双できる理由
