障害管理表（バグ管理表）のExcelテンプレート｜項目と原因分類の決め方

障害管理表（バグ管理表）のExcelテンプレートを無料で配布しています。テストで検出した障害を記録するだけでなく、原因を分類して再発を止めるところまでを前提にした項目構成にしています。内部テストやユーザ受け入れテスト（UAT）でそのままお使いいただけます。 呼び方について。「障害管理表」「障害管理表」「不具合管理表」「バグ管理表」「障害管理台帳」は、現場によって呼び名が違うだけで、指しているものはほぼ同じです。本記事ではテンプレートのファイル名に合わせて故障という語を使っていますが、障害・不具合と読み替えていただいて差し支えありません。

障害管理表に入れる項目とテーラリング

選択リスト（重要度・障害判定・障害分類）の定義

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

参考

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

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

障害管理表の項目定義

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

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

品質分析指標（障害の傾向分析）の更新

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

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

障害の原因分類と根本原因の決め方

障害管理表でいちばん設計が難しいのが、原因の扱いです。ここが曖昧なままだと、表は埋まっていくのに「結局どこが弱いのか」が最後まで見えません。原因は1列にまとめず、役割の違う3列に分けて持つのが実務的です。

列	何を書くか	分析でどう使うか
障害分類	起きた事象の種別（画面表示・計算結果・性能・権限・連携など）	偏りを見て、設計や実装のどこが弱いかを判断する
根本原因	なぜ作り込まれたか（仕様漏れ・仕様の誤解・実装ミス・考慮不足など）	再発防止の打ち手を決める
本来検出すべき工程	どの工程で見つけられたはずか	テストケースが不足している工程を特定する

この3つが分かれていると、たとえば「障害分類はバラバラだが、根本原因はどれも仕様の誤解」という状態が見えるようになります。そうなれば打ち手は、テストの強化ではなく仕様の伝え方の見直しになります。分類を1列で済ませていると、この判断ができません。 分類の粒度は、最初に決めて途中で変えない。プロジェクトの途中で値を増やすと、それ以前に登録した障害と集計が合わなくなります。迷ったら粗めに始めて、傾向が見えてから列を足すほうが安全です。 「その他」を作らない。作った瞬間に、判断に迷ったものがすべてそこへ流れ込みます。当てはまる分類が無いなら、それは分類定義そのものを見直す合図です。なお、レビューの段階で検出した指摘は障害管理表ではなくレビュー指摘表で管理し、実装後に障害として顕在化したものをこちらへ引き継ぐと、工程ごとの検出状況が正しく集計できます。

ここまでは分類をどう設計するかの話です。実際に溜まった障害を分類し直し、傾向から打ち手を導くところまでは障害の原因分類をAIに整理させる手順で解説しています。

障害管理表（Excel）テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

ダウンロード前に利用規約を必ずお読みください。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

障害管理表（Excel版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

障害管理表をスプレッドシートで開く

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。皆様の役に立つように改善していきたいと思います。

テンプレート関連の記事

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村