不具合管理で管理するべき内容

用途ごとにバグ管理する項目を作成してみました。
用途に合わせ、記載粒度やかける工数を決めると、なお効率が良くなります。

バグ修正を効率的に回す

バグ修正をチームで効率的に修正するためには、以下の管理項目が有効です。

項目	説明
題名	バグ一覧に表示される項目。将来的に検索しやすいように名は体を表すようにする
説明	・バグの内容説明 ・再現手順 期待する動作 ログ など
ステータス	新規、再現待ち、解析中、解析済み、修正中、承認待ち、終了
優先度	高、中、低
担当者	不具合修正におけるアクションアイテムを持っている人
対象バージョン	リリースしたプログロムの版
期日	修正の期日(クリティカルパスまでのフロート）
試験項番	試験項目の番号
直接的原因	不具合発生の具体的な原因

ナレッジの蓄積

１年たつと当時何をおもってそうしたのかわからなくなります。コードは具体的な動作は明確に示しますが、何を目的としているかは表現できないからです。当時の思い・狙いを蓄積しておくことで将来的に安心して修正することができます

項目	説明
概要	どんなバグか。
直接的原因	本当に具体的な原因
処置内容	どんな処置をしたのか、なぜそのような手段をとったのか
水平展開・影響範囲確認 観点	水平展開を行った観点

プロセス改善の評価

プロセスの改善評価では以下の項目が使用できます。

項目	説明
工程	発見工程
バグ種別	自責（新規）、自責（修正不十分）、自責（デグレ）、自責（潜在）、他責（別PJ）、その他（非バグ）
作りこみ工程	PJで計画した理想的な開発計画に沿って設計を行うことができなかった工程。どの工程に改善余地があるのかがわかります。
作りこみ原因	PJで計画した理想的な開発計画に沿って設計を行うことができなかった原因。開発プロセスで問題のある観点がわかります。
本質的原因（作りこみ）	不具合をなぜ作りこんだのか？を考えます。開発プロセスの設計工程の問題点を判断することができます
見落とし工程	PJで計画した理想的な開発計画に沿って検出を行うことができなかった工程。どの工程に改善余地があるのかがわかります。
見落とし原因	PJで計画した理想的な開発計画に沿って検出を行うことができなかった原因。開発プロセスで問題のある観点がわかります。
本質的原因（見落とし）	どのレビュー・テストで見つけるべきだったのに見つけられなかったのかを考えます。開発プロセスのテスト工程の問題点を判断することができます
不具合発生個所	機能・モジュール・　などを記載しておくと、品質が悪い機能やモジュールが浮き彫りになり、技術的負債がどこにあるかが判断しやすくなります
バグ混入バージョン	どのバージョンでバグが作り込まれたか。品質の悪い版が判明します。

代表的な作りこみ原因

設計漏れ:インプット情報の確認不足
設計漏れ：インプット情報不良
設計漏れ:影響範囲確認不足
設計漏れ:流用元の確認不足
設計漏れ:検討不足
設計誤り:インプット情報の確認不足
設計誤り:インプット情報不良
設計誤り:影響範囲確認不足
設計誤り:検討不足
設計誤り:流用元の確認不足
ケアレスミス：単純な人為的ミス
作業ミス：PJルール違反
作業ミス：レビュー指摘事項反映漏れ
作業ミス：情報共有のミス
スキル不足
業務（ユーザー運用）の理解不足
前回開発時からの潜在不良
流用元からの潜在不良
該当なし

代表的な見落とし原因

項目漏れ（正常系・準正常）
項目漏れ（異常系）
項目漏れ（境界値）
項目漏れ（競合）
項目漏れ（連続・負荷）
項目漏れ（設定組み合わせ）
項目漏れ（リグレッション）
項目漏れ（その他観点）
項目誤り（判定結果）
項目誤り（実施手順）
試験実施誤り（結果判定）
試験実施誤り（実施手順）
レビュワーのスキル不足
レビュー未実施（全部）
レビュー未実施（一部）
レビュー観点不足
レビューメンバの不足
該当なし（本質的原因欄に記載）
見落としではない（本質的原因欄に理由）