バグトリアージ（欠陥トリアージ）とは、新しく報告された欠陥を確認・判定・割り当てるプロセスです。限られた開発リソースを、影響の大きい問題の修正に優先的に振り向けることが目的です。 効率的なトリアージプロセスが保証すべきは 2 つのこと：すべての欠陥が決まった時間内に確認されること、そして一度確認されれば行き先が決まる（修正・予定に入れる・降格・クローズ）ことです。
なぜトリアージが必要か
トリアージ機構のないチームの欠陥処理は、たいてい次の 2 つの病態のどちらかを示します：- 声の大きい者勝ち：声の大きい人の問題が先に直され、P0 と P2 が同じキューに並ぶ；
- ブラックホール型：欠陥がチャット、メール、口頭のフィードバックに散らばり、相当数が誰にも「決定」されたことがない。
トリアージの役割分担
| 役割 | 責務 |
|---|---|
| トリアージ進行者（通常は QA リード） | トリアージ会議の運営、キューのゼロ維持、意思決定の推進 |
| QA / テスター | 再現性の確認、再現手順の補完、暫定判定 |
| 開発リード | 技術的影響範囲の評価、修正コストの見積もり、割り当ての引き受け |
| プロダクトオーナー（PM/PO） | ビジネス観点での優先度決定、「直すか直さないか」の裁定 |
標準トリアージフロー（5 ステップ）
1. 受け入れと重複排除
すべてのチャネル（社内テスト、ベータユーザー、本番フィードバック）のレポートを同じ台帳に入れ、「モジュール＋症状」で重複確認してから統合します。入口が分散していることがトリアージ失敗の根源です——チャットで報告されたバグとツールで報告されたバグは、1 つの表に集まらなければなりません。2. 確認（Validate）
- 再現するか？ レポートの手順に沿って一度通す；
- 再現しない：環境情報を記録して報告者に補完を依頼——レポートに環境コンテキストが最初から付いているチームは、ここでほとんど詰まりません（下記参照）；
- 欠陥ではない（仕様どおりの動作/使い方の質問）：サポート質問やドキュメント改善項目に転換し、クローズして報告者に通知。
3. 判定（深刻度 × 優先度）
深刻度（Severity、技術視点）と優先度（Priority、ビジネス視点）は別の次元です。混同しないこと：| 高優先度 | 低優先度 | |
|---|---|---|
| 高深刻度 | 即修正（トップページが真っ白） | 今スプリントで修正（ニッチな機能がクラッシュ、回避策なし、ただしユーザーの到達は極めて稀） |
| 低深刻度 | 早めに修正（ログインボタンのずれ。全ユーザーに影響） | バックログへ（隅のページの誤字） |
4. 割り当てと予定化
- P0：当日ホットフィックスまたはロールバックし、関係者全員に通知；
- P1：現スプリントへ（計画会で確保した 20% のバッファを使用。詳細はスプリントプランニングガイド）；
- P2/P3：プロダクトバックログへ。通常どおり並べ替え。
5. 返信とクローズ
修正後：報告者（特に外部テスター）に再確認を依頼 → 検証通過 → クローズし、根因分類を記録（振り返りの統計用）。外部報告者へのステータス返信が、次回以降の報告意欲を直接左右します。トリアージ会議の進め方
- 頻度：イテレーションが速いチームは毎日 1 回、15〜30 分、新規キューのみ。ゆるいチームは週 2〜3 回；
- 形式：台帳ボードを流す。1 件 3〜5 分。5 分で決まらないものは「保留」にして、退勤前に個別相談；
- 規律：会議では意思決定のみ。技術方針の議論はしない。新規のみを扱い、判定済みのものは再検討しない。
高速トリアージの前提：レポートがコンテキスト付きで届く
トリアージ会議で最も時間を無駄にする場面：QA がレポートを読み上げる——「ユーザーが言うには、ボタンを押しても反応がない」——そして全員が質問攻め：どのページ？ どのブラウザ？ Console にエラーは？ もう一度押せますか？ 本来 2 分で判定できるはずのレポートが、15 分の探偵ドラマになります。 根源はレポートにコンテキストがないことです。比較してみましょう：| 情報項目 | 手動レポート（ユーザーが記憶で語る） | 自動収集のレポート |
|---|---|---|
| 再現手順 | 「そのボタンを押したら反応がなくなりました」 | 注釈付きスクリーンショット/録画が場所と操作を指し示す |
| ページ URL | しばしば欠落、または言い間違い | 自動添付 |
| ブラウザ/デバイス | たいてい欠落 | 自動添付 |
| Console / Network エラー | ほぼあり得ない | ERROR スタックトレースと失敗リクエストが自動添付 |
トリアージ品質のセルフチェック指標
| 指標 | 健全値 | 意味 |
|---|---|---|
| レポートの初回応答時間 | < 24 時間 | 送信からトリアージ判定まで |
| 「保留」の滞留 | < 5 % | 保留が長引くのは判定基準が曖昧な証拠 |
| 重複レポート率 | 低下傾向 | 台帳と重複排除の仕組みが機能している |
| P0 数 | 低下傾向 | 高止まりは上流の品質活動不足 |
| 報告者の再確認フィードバック率 | 高い | 外部テスターの満足度と定着 |