「直して終わり」がバグを増やす

バグレポートが届くと、多くのチームは再現確認 → 修正 → クローズという流れで処理します。この流れ自体は正しいのですが、クローズした瞬間にそのバグの情報が失われるのが問題です。同じ原因のバグが3ヶ月後にまた別の画面で報告される、というのはよくある話です。

原因は、バグの「直し方」だけを見て「なぜ生まれたか」を見ていないことにあります。実装を直すだけで終わらせず、仕様のどこに穴があったのかまで遡って初めて、同じ原因の再発を止められます。

バグを3つに分類する

報告されたバグは、修正前に次の3種類のどれかに分類できます。分類先によって、直す場所も再発防止の打ち手も変わります。

1. 実装バグ

仕様通りに作れていない状態です。仕様書やチケットには正しく書かれているのに、実装がそれを満たしていません。

例: 「削除は確認ダイアログを出す」という仕様があるのに、確認なしで即削除されてしまう。

戻し先: コードレビュー・テストケースの拡充。仕様自体は直さない。

2. 仕様バグ

実装は仕様通りだが、その仕様自体が現実の業務やユーザー行動に合っていない状態です。「仕様通りに動いているのにバグとして報告される」パターンで、これを実装側だけで対処しようとすると、次の類似機能でまた同じ問題が起きます。

例: 「在庫0でも注文できる」仕様のまま作ったが、実際の運用では欠品時にキャンセル対応の工数が発生し続けている。

戻し先: SPEC.md やチケットの受入条件を修正し、次のリリースサイクルで実装を追従させる。

3. 期待値バグ

仕様にも実装にも問題はなく、報告者の期待とシステムの設計思想がずれているだけの状態です。バグではなく、UI文言や説明不足が原因のことが多いです。

例: 「保存ボタンを押しても何も起きない」→ 実際は自動保存されているが、その旨が画面に表示されていない。

戻し先: 仕様は変えず、UIのフィードバック表示やヘルプ文言を追加する軽微な改善タスクとして扱う。

分類ごとの戻し先チェックリスト

実装バグ → 該当コードの担当エンジニアにアサイン、再発防止はテストケース追加
仕様バグ → PM/POが受入条件を修正し、SPEC.mdまたは仕様書を更新してから再実装をチケット化
期待値バグ → デザイナー/フロントエンド担当がUIフィードバックを改善、仕様変更は不要

分類に迷ったら「仕様書に書いてある通りに動いているか」を最初の分岐点にすると判断が速くなります。書いてある通りなら仕様バグか期待値バグ、書いてない・違う動きなら実装バグです。

四半期ふりかえりテンプレート

分類したバグは、四半期ごとに集計すると仕様の「弱い場所」が見えてきます。ふりかえりでは以下の3項目を確認します。

分類別の件数比率(実装バグ/仕様バグ/期待値バグ)
仕様バグのうち、実際にSPEC.mdや仕様書へ反映できた件数
反映できなかった仕様バグの理由(優先度が低い/影響範囲が大きく次期に持ち越し等)

仕様バグの比率が高い機能領域は、次の設計フェーズで受入条件のレビューを厚くする対象として扱います。逆に実装バグばかりの領域は、テストカバレッジ強化が効きます。

Bugoon での実践

Bugoon はウィジェット経由でスクリーンショット・アノテーション・操作ステップ付きのバグレポートを収集し、そのままGitHub Issueへ連携できます。3分類の判断材料になる「再現手順」「実際の挙動」「報告者の期待」は、ウィジェットのフォーム項目としてレポートに残るため、あとから見返しても分類の根拠を追いやすい状態になります。

カンバンボードで進行中のバグを俯瞰しながら、仕様バグと判断したものだけを別ラベルで管理すれば、四半期ふりかえり時の集計もそのまま流用できます。原因分類そのものをタグとして扱えると、この集計作業はさらに省力化できるかもしれません。

バグ報告を仕様修正に変える3分類法