バグの優先度

バグの優先度は、欠陥を修正する順番を表します。ユーザーへの影響、期限、顧客との約束、評判、修正コストを比較して判断するビジネス上の決定です。テスターが優先度を提案することはありますが、最終判断は通常プロダクトオーナーが下し、多くの場合は開発・QA とのトリアージ会議で決まります。

一般的な段階

優先度	意味
P1 / 緊急	すぐに修正する。通常のリリースとは別にホットフィックスが必要になることもある
P2 / 高	現在のスプリント内、または次のリリースまでに修正する
P3 / 中	今後のスプリントに計画する
P4 / 低	都合のよいときに修正するか、許容してクローズする

優先度と重要度（Severity）の違い

重要度は影響を測ります。つまりプロダクトがどれだけひどく壊れているかです。優先度は緊急性を測ります。つまりどれだけ早く修正しなければならないかです。両者はしばしば食い違うため、別々に評価します。

• 重要度は低いが優先度は高い： 明日開始するキャンペーンのバナーに誤った価格が表示されている。何もクラッシュしませんが、開始前に必ず正しくする必要があります。
• 重要度は高いが優先度は低い： 11 か月先の年度末にしか実行されない管理者向けレポートでのクラッシュ。

また、重要度は通常変わりませんが、優先度は時間とともに変わります。同じ年度末のクラッシュも、12 月になれば P1 になります。

優先度の決め方

トリアージで役立つ質問：

• 影響を受けるユーザーは何人で、誰なのか（有料顧客、社内スタッフ、特定の 1 テナント）？
• 回避策はあるか、サポートが説明できるか？
• リリース、デモ、法的・契約上の期限はあるか？
• 修正そのもののコストとリスクはどうか？ リリース直前のリスクの高い修正は、意図的に後回しにすることもあります。

よくある間違い

• 1 つの項目で両方を兼ねる。 「優先度」だけを管理するチームは影響に関する情報を失います。これはリリースリスクやメトリクスにとって重要な情報です。
• すべてが P1。 ほとんどのバグが緊急なら、どれも緊急ではありません。最上位のレベルは少数に保ち、明確に定義します。
• 優先度を見直さない。 リリース計画や顧客の状況が変わったら、未解決のバグを再評価します。