バグ管理の基礎と実務ガイド：Severity・Priorityの違い、ライフサイクル、指標、ベストプラクティスまで
エバープレイ編集部バグ管理とは
バグ管理（バグトラッキング、欠陥管理）は、ソフトウェア開発において発見された不具合（バグ）を記録・分類・優先付け・割り当て・修正・検証・クローズまで一貫して管理するプロセスと仕組みを指します。単に「バグを直す」だけでなく、発生原因の追及、再発防止、品質改善、顧客／利用者への影響最小化を目的とした組織的な活動です。
バグ管理の目的
- 発見された不具合を確実に追跡し、対応漏れを防ぐ。
- 不具合の影響度や優先度を明確にして、限られたリソースを有効に配分する。
- 修正履歴や状況をドキュメント化して再現性・監査性を担保する。
- 原因分析（Root Cause Analysis）を行い、プロセスや設計の改善につなげる。
- 品質指標を用いて改善効果を測定する。
バグの基本概念：重大度（Severity）と優先度（Priority）
バグ管理でよく混同されるのが「重大度」と「優先度」です。簡潔に言うと：
- 重大度（Severity）：不具合が製品や機能に与える技術的・業務的影響の大きさ（例：クラッシュは高、表示崩れは低）。
- 優先度（Priority）：その不具合をいつ修正すべきかの緊急度やビジネス上の優先順位（例：リリース前に必須で修正するか後回しにするか）。
プロジェクトによって定義や運用方法は異なりますが、トリアージの際に両者を明確に分けることが重要です。
バグのライフサイクル（代表的なワークフロー）
典型的なライフサイクルは次のようになります（ツールや組織により名称は変わります）：
- 新規（New / Open）— 報告された状態。
- 確認（Confirmed / Triaged）— 再現性や優先度を判定し、担当を決める。
- 対応中（In Progress / Assigned）— 修正作業中。
- 修正済み（Fixed / Resolved）— コード上で修正が完了した状態。
- 検証（Verified / QA）— QA が修正を確認する。
- クローズ（Closed）— 検証が成功し、問題が解決されたと判断された状態。
- 再発（Reopened）— 修正が不十分で再度問題が発生した際に戻る。
実務的な記録項目（バグ報告テンプレート）
良いバグ報告は迅速な解決につながります。以下は一般的なテンプレート項目です。
- タイトル（短く要点を）：何が問題か一目で分かるように。
- 再現手順（Steps to Reproduce）：手順を順番に、環境とともに。
- 期待される挙動と実際の挙動（Expected / Actual）。
- 環境情報：OS、ブラウザ、アプリバージョン、データセット、ネットワーク状況など。
- スクリーンショット／ログ／スタックトレース：証拠を添付。
- 重大度／優先度、モジュール、担当者、バージョン、回帰フラグ（regression）などのメタデータ。
- 再現性（常に起きる／時々起きる／一度だけ）。
ツールと技術
バグ管理には専用ツールが多く使われます。代表的なもの：
- 商用／企業向け：Atlassian Jira（Jira Software / Jira Service Management）、YouTrack。
- コードホスティング付属：GitHub Issues、GitLab Issues。
- オープンソース：Bugzilla、Redmine、MantisBT。
- セキュリティ特化：脆弱性管理ツール（Nessus等）やバグバウンティプラットフォーム（HackerOne, Bugcrowd）。
また、CI/CD パイプラインやソース管理と連携して、コミットやプルリクエストにバグチケットを紐付ける運用は標準的です。静的解析（SAST）、動的解析（DAST）、自動化テスト、ファジング（例：OSS-Fuzz）などの自動検出ツールと統合することで、早期発見・自動登録も可能になります。
トリアージと運用ルール
トリアージ会議（定期的またはオンデマンド）は、バグの優先順位付けと適切な担当付けを行う場です。実務上の注意点：
- ビジネスインパクト（顧客への影響）を常に意識する。
- 再現可能性が低いものは環境情報やログの追加を依頼する。
- 重複チケットは統合し、履歴を残す。
- 修正までの目標 SLA（サービスレベル）を定義することが有効。
- 重大インシデントはインシデント管理フロー（オンコール、ポストモーテム）で扱う。
測定すべき指標（メトリクス）とその意味
- MTTR（Mean Time To Repair / Recovery）— 平均復旧時間。インシデント対応力の指標。
- 平均検出時間（Mean Time To Detect）— 問題を検知するまでの時間。
- 欠陥密度（Defect Density）— KLOC（千行）当たりの欠陥数など、コード品質の相対指標。
- エスケープ率（Escape Rate）— テスト工程をすり抜けてリリースされた不具合の割合。
- バックログサイズ、未対応バグの年齢分布— 技術的負債の可視化。
- DORA 指標との連携（デプロイ頻度、リードタイム、MTTR、チェンジ失敗率）— 開発・運用の健全性を測る。
セキュリティ脆弱性の扱い
セキュリティは通常の機能バグと扱いが異なります。公開前に公表すると悪用される恐れがあるため、取り扱いは機密レベルが高く、特別なトリアージが必要です。脆弱性はCVSSスコア等で評価し、パッチ管理や責任ある開示（responsible disclosure）ポリシーに従って対応します。バグバウンティや外部セキュリティ監査の結果もチケットとして管理することが一般的です。
良いバグ管理のためのベストプラクティス
- 報告は必須情報（再現手順、環境、ログ）を揃えて簡潔に。曖昧な報告は戻される原因になる。
- 優先度と重大度を明確にし、経営・プロダクト・技術の合意を取る。
- 「一目で状況が分かる」ダッシュボードを用意して可視化する。
- テスト自動化と静的解析を早期から導入し、受け入れ基準（Definition of Done）に「既知の重大バグがないこと」を含める。
- 根本原因分析（5 Why、魚骨図等）とポストモーテムを行い、再発防止策を実施する（blameless postmortem）。
- 個人攻撃や責任押し付けを避け、チーム全体で品質を改善する文化を作る。
- 個人情報（PII）や機密情報をバグ報告内に含めない、もしくはマスキングする方針を定める。
アジャイル／ウォーターフォールでの違い
ウォーターフォールではテスト工程での発見・修正が中心となるのに対し、アジャイルでは短いイテレーション内での早期検出・修正、継続的なデプロイと素早いフィードバックループが重視されます。アジャイルではバグは通常バックログアイテムとして扱い、優先度に応じてスプリントに組み込まれます。ただし重大インシデントは即時対応が必要です。
まとめ
バグ管理は単なる欠陥の一覧管理ではなく、発見から解決、原因分析、予防までを含む継続的な品質改善プロセスです。適切なツールと明確なルール、メトリクスの運用、文化としての「責任を個人ではなくプロセスに帰す」姿勢が重要です。早期検出（Shift Left）と自動化、CI/CDや静的解析との統合が現代の高品質開発には不可欠です。
参考文献
- Atlassian — What is bug tracking?
- GitHub Docs — About issues
- Wikipedia — Software bug
- OWASP — Top Ten (脆弱性管理の参考)
- Wikipedia — Defect density
- SonarSource — 静的解析（SAST）の代表例
- OSS-Fuzz — 自動ファジング（Google）
- HackerOne — バグバウンティプラットフォーム
- Wikipedia — Root cause analysis
- Google Cloud — Understanding postmortems（blameless postmortem）
投稿者プロフィール
