故障管理表（バグ管理表）（Excelテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した故障管理表（バグ管理表）のテンプレートをご提供しております。内部テストやユーザ受け入れテスト（UAT）の際は、ぜひ本テンプレートをご活用ください。

1.テーラリングガイド

1.選択リストの更新

故障管理表で利用する以下の選択リスト値を更新します。

参考

工程定義：要件定義や基本設計など工程名称を記入します。プロジェクトで使用する工程コード（RD、SS、UTなど）の定義があれば、あわせて登録しておきましょう。※工程コードは本テンプレートでは利用していないため、必要があれば工程コードの欄を追加してください。
重要度：検出した故障の重要度を定義します。故障が大量にある場合は、この重要度に応じて優先度をつけて対応することになります。
故障判定：報告された故障の内容を判断し、バグなのか非バグなのかを判断します。バグの種類についてはプロジェクトの品質管理で定義されている内容に従って変更してください。
故障原因：故障原因については本テンプレートでは利用していませんが、故障原因を分類したい場合は故障管理表に列を追加してご利用ください。
故障分類：故障の種別を定義します。故障の傾向を把握するたために分類します。プロジェクトの品質管理の定義に合わせて分類を定義してください。分析の際に例えば、故障の内容がガバナ制限エラーに偏っている場合は、ガバナの考慮が足りない設計やコーディングになっていると判断できるため、横展開して全体的に同じ観点で再度設計やコードレビューを実施する必要があります。
根本原因：故障が発生した根本原因を定義します。こちらも分析の際に利用する項目となります。どうしてその故障（バグ）が発生したのか、根本原因は何かを特定し、根本原因を取り除くための施策を検討します。
対応状況：故障報告に対する対応状況を定義します。こちらもプロジェクトの故障管理フローに基づき、ステータスを定義してください。

画像はクリックすると拡大表示されます。

2.レビュー票の項目定義

画像はクリックすると拡大表示されます。プロジェクトの内容に合わせて、以下の内容を更新してください。

お客様名：顧客名を記入してください。
プロジェクト名：プロジェクトの名称を記入してください。
システム機能名称：故障報告対象のシステム機能を定義してください。※複数システムある場合には、システムを定義する列を追加してください。
報告者：報告者は選択リスト形式ではなくテキスト入力しているためプロジェクトで担当を選択リストとして定義したい場合は変更してください。
故障分析（故障判定、故障分類）：選択リストの値は事前に定義しておいてください。具体例を示してどういった事象の場合にどの種別を利用するのか明記したほうがよいでしょう。
故障検出工程：故障（バグ）を検出した工程を選択します。単体テストや結合テストなど。
本来検出すべき工程：故障検出工程に対して、本来どの工程で検出すべき故障（バグ）だったのかを定義します。
本来検出すべき工程で検出できなかった理由：たとえば、プログラムの条件判断ロジックが逆になっていたような故障があった場合に、プログラムの単体テストの段階で検出すべき内容が、UATで検出されたすると、単体テストのテストケースが不足していたことや仕様の理解が誤っていたなど根本原因は何かを明確にする必要があります。また原因によっては、横展開し同じような故障が発生する可能性がある機能について同様の観点でチェックします。
根本原因/原因説明：故障が発生した根本原因のカテゴリと詳細な説明を記入します。
対応方針：こちらもプロジェクトの故障管理フローに則って変更してご利用ください。

3.品質分析指標の更新

故障管理サマリーシートでは、システム機能単位での故障分類や発生原因の集計結果を一覧化し、それぞれの故障（バグ）摘出密度を算出します。バグ密度は以下の計算式で算出してます。バグ密度 = [バグ検出件数 / ソースコード行数] ※Salesforce標準機能だけで実現しているようなシステムの場合にはソースコードでのバグ密度を定義することでは品質管理できないため、ソースを機能数に置き換えてプロジェクト独自の品質管理指標を定義してください。品質を評価するにあたり、事前にバグ密度の指標値を定義しておきましょう。指標値を定義しておくことでエラー摘出密度が高いか低いか判断することができます。指標は過去同様のプロジェクトをベースに定義することをお勧めします。バグ摘出密度が低すぎる場合は、テストケースが不足していたり、テスターのスキルが低い可能性があります。原因を把握して、対策を実施したうえで再度テストを実施しましょう。逆にバグ密度が高すぎる場合は、成果物の品質が非常に低い可能性があります。こちらも原因分析を行い、対策を練る必要があります。