テスト工程で突然バグが増えてくると、現場は「何から直せばいいか」で混乱します。担当者に「全部対応してください」と伝えても、全部が同じ優先度というわけではなく、リリースに影響するバグとそうでないバグが混在しています。
件数だけを見て判断すると、軽微なUIの修正に時間を使っている間に、重要な業務機能の問題が後回しになっている、という状態が起きます。本記事では、バグが多発しているときにPMが使える優先順位づけの5つの観点を整理します。
バグが多いときは件数だけで判断しない
バグが50件あるからリリースできない、というのは正確ではありません。50件のうちリリースに直接影響するバグが何件か、が判断の基準です。
件数が多くても大半が軽微な表示崩れであれば、リリース判断への影響は限定的です。件数が少なくても、主要業務機能に関わるバグが1件残っていれば、それが問題です。
優先順位づけは、「何を先に直すか」だけでなく、「何がリリースを止めるか」と「何を後回しにできるか」を分けることにも使います。
優先順位の5観点
バグの優先順位を判断するための5つの観点を紹介します。
1. 業務影響：このバグが残った場合、ユーザーの業務に何が起きるか。「ログインができない」「金額計算が誤る」「データが消える」は業務影響が最も大きい分類です。「特定の検索条件で結果の並び順が変わる」「ボタンの色が設計と異なる」は影響が軽微です。
2. 再現性：このバグは常に再現するか、特定の条件でのみ発生するか。常に再現するバグは対応優先度が高く、特定の操作順序でのみ発生するバグは条件を明確にした上で判断します。再現しないバグの調査に時間をかけすぎないことも重要です。
3. 発生範囲：このバグはどの機能・モジュールに影響しているか。主要機能に広く影響するバグと、特定のサブ機能にのみ影響するバグでは優先度が異なります。また、データの整合性に影響するバグは範囲が広がりやすいため、早期に対応します。
4. 回避策の有無：このバグに回避策（ワークアラウンド）があるか。回避策がある場合、その回避策が業務上許容できるかを確認します。「この操作順序を避ければ発生しない」という回避策があり、それが業務上現実的であれば、リリース判断に影響しない可能性があります。
5. リリース影響：このバグがリリースされた状態で本番に出た場合、どのような問題が起きるか。データ破損、業務停止、セキュリティ上の問題が起きるバグはリリースを止めます。軽微な表示上の問題であれば、リリース後の修正対応として計画できます。
テスト工程中にやってはいけない対応
バグが多発するテスト工程中、焦った気持ちからやってしまいがちなのが**「修正後の再テスト省略」**です。修正したはずの箇所で再びバグが出ることを恐れるあまり、確認なしに「対応済み」としてしまうケースです。
修正は必ず「修正した箇所と周辺の再テスト」をセットにしてください。「修正完了」と「確認完了」を分けて管理し、チケットシステムがあれば確認チェックを通過したものだけクローズするルールを定めてください。これだけで、修正後の再発率が下がります。
再テストを省略することは、テスト工程全体の信頼性を下げます。短期的な工数削減より、「修正後の再発防止」の方が、最終的にテスト工程全体の完了にかかる時間を短縮します。
バグが多発しているときのPMの精神的負荷への対処
バグが止まらないテスト工程中、PMは顧客からの問い合わせと開発チームへの対応の両方に追われ、精神的に消耗しやすい状況になります。
このような状況で大切なことが2つあります。1つ目は、「自分一人で解決しようとしない」こと。上司やPMOに状況を共有し、顧客対応の文面確認や判断のサポートを受けることは「弱さ」ではなく「正しいエスカレーション」です。
2つ目は、「今日の数字を確認すること」。バグの発生数や残件数を毎日確認することで、「改善している」「悪化している」の判断ができます。数字があると、漠然とした不安が「あと何件まで減れば安心か」という具体的な目標に変わります。
PMは問題を全て自分で解決する役割ではありません。問題を可視化し、関係者が判断できる状態を作り、優先順位をつけて動かすことがPMの仕事です。バグが多発している状況でも、その役割を続けることが、チームとプロジェクトを支えることになります。
対応すべきバグと後回しにできるバグ
5観点で整理したら、3分類に分けます。
リリースを止めるバグ：業務に直接影響・常に再現・回避策なし・リリース後に重大な影響が出る。これを先にゼロにすることが最優先です。
リリースは可能だが対応が望ましいバグ：業務影響はあるが回避策がある・限定的な条件でのみ発生。リリース後に早期対応する計画を立てた上で、リリース判断を顧客と相談します。
後回しにできるバグ：業務影響なし・表示上の軽微な問題・発生条件が極めて限定的。次フェーズのタスクとして管理します。
顧客に説明する整理
「バグが〇件残っています」ではなく、「リリースを止めるバグがX件、リリース後対応可能なバグがY件、次フェーズ対応のバグがZ件です」という形で伝えてください。
顧客にとって重要なのは「自分たちの業務に何が起きるか」です。分類を示すことで、顧客は「Xが解消したらリリースしよう」という判断ができるようになります。
再発防止につなげる
バグが多発している場合、「なぜ多発しているか」という原因確認も並行して行います。
特定の機能・担当者・技術領域に集中していれば、そこに構造的な問題がある可能性があります。テストが終わったはずの箇所で再発が多ければ、修正後の確認プロセスに問題があります。バグの対応が終わった後の振り返りとして、多発の原因を確認してください。
リリース判断に向けた最後の確認
バグが3分類に整理できたら、「リリースを止めるバグ」がゼロになるまで対応を続けてください。ゼロになった時点で、「リリースは可能だが対応が望ましいバグ」について顧客と判断を合わせます。
リリース判断の会議では、3分類の状況と対応計画を表形式で示すことが有効です。「残りX件、内訳はリリース阻害0件・リリース後対応Y件・次フェーズZ件」という数字を示すことで、顧客が判断しやすくなります。
リリース後に「言ってたバグが残ったままだ」という話にならないために、「リリース後対応」として受け入れた件数と対応期限は必ず文書化しておきます。口頭合意だけでは後から「そんな話はしていない」という摩擦が生まれやすいため、メールや議事録に残すことが最低限の対策です。
テスト工程での3分類の判断を積み重ねることで、PMとしての品質管理の判断軸が育ちます。「リリースを止めるバグの条件」を自分の言葉で定義できるようになると、次のプロジェクトでも同じ判断を安定して出せます。品質問題への対処スキルは、経験ごとに精度が上がるものです。今回のプロジェクトで得た判断の型を、記録として残しておくことをおすすめします。
バグ対応の優先順位づけとリリース判断については、炎上予防・立て直しパックで体系的に学べます。品質問題の初動から顧客説明・リリース判断まで、受託開発PMの実務に合わせた内容を揃えています。PJ炎上 初動ナビでは炎上レベルの診断もできます。