不具合管理表のテンプレート
テスト工程に入ると、不具合管理表は一気に行が増えます。100件、300件、500件。件数が増えるほど「誰が何をどこまで直したか」が分からなくなり、毎日の会議が状況確認だけで終わるようになります。
この記事では、そうならないための不具合管理表のテンプレートを紹介します。ポイントは列を増やすことではなく、1件ごとに重要度・優先度・本来見つかるべき工程の3つを必ず付けること。3つめの欄が、テストそのものが機能しているかどうかを教えてくれます。記入例は、事例集の「セイワ医科器械（架空）の保守サービス管理システム刷新」に当てはめています。
■ 1. 背景・よくある課題
よくある状態 | 何が起きるか |
|---|---|
現象が「エラーが出る」としか書かれていない | 開発側が再現できず、「再現しません」で差し戻される |
重要度と優先度が同じ列になっている | 軽微だが件数の多い不具合が、いつまでも後回しになる |
原因の分類欄がない | 不具合が減らないとき、何を直せばいいか分からない |
状態が「対応中」のまま何週間も動かない | どこで止まっているのか（修正待ちか、確認待ちか）が見えない |
修正したが再テストの記録がない | 直ったつもりのものが、後の工程で再発する |
件数だけを毎日報告している | 「今日は12件出ました」だけでは、良いのか悪いのか判断できない |
セイワ医科器械の案件では、結合テストを始めて8週間、不具合が毎週55〜63件のペースで出続け、未解決が214件まで積み上がりました。ここで問うべきは「どう増員するか」ではなく「なぜ減らないのか」です。直す速度が足りないのか、それとも出続ける理由が別にあるのか。前者なら人を増やせば解決しますが、後者なら人を増やしても同じことが続きます。
■ 2. テンプレート作成の目的
目的 | 具体的にどうなることか |
|---|---|
開発側が再現できる形で伝える | 「再現しません」の差し戻しをなくす |
直す順番を客観的に決める | 重要度と優先度を分け、声の大きさで順番が決まらないようにする |
テストが機能しているかを判定する | 原因分類の集計で、入ってくる量の問題かどうかが分かる |
止まっている場所を見えるようにする | 状態を細かく分け、修正待ちと確認待ちを区別する |
同種の不具合を先回りして潰す | 横展開の欄を置き、1件から芋づる式に探す |
■ 3. テンプレートの全体像
シート | 役割 | 更新の頻度 |
|---|---|---|
① 不具合一覧 | 1件1行。検出から再テスト完了までを追う中心のシート | 随時（検出者・修正者が直接入力） |
② 集計ダッシュボード | 週別の発生件数と未解決件数、サブシステム別の不具合密度、原因分類の内訳 | ①から自動集計 |
③ 判定基準表 | 重要度S〜C、優先度1〜4、原因分類の定義 | テスト開始前に作り、途中で変えない |
③を先に作らずにテストを始めると、1週間後には重要度の付け方が人によってばらばらになります。基準表はテスト開始前の必須作業だと考えてください。
■ 4. 各項目の説明
① 不具合一覧の列構成
列 | 記入する内容 | 書き方のコツ |
|---|---|---|
ID | BUG-0001 のような通し番号 | 会議で「312番の件」と呼べるようにする |
検出日／検出工程 | 日付と、単体・結合・総合・受入のいずれか | 工程別の密度を出すために必須 |
サブシステム／機能 | 部品在庫／発注候補リスト など | 偏りを見つけるための軸になる |
現象 | 何が、どうなるか | 「エラーが出る」ではなく、画面名とメッセージまで書く |
再現手順 | 操作の順番と、使ったデータ | ここが空欄の行は受け付けない。差し戻しの最大の原因 |
期待する動作 | 本来どうなるべきか | 仕様書のどこに書いてあるかも添える |
重要度 | S／A／B／C（影響の大きさ） | 検出者が付ける |
優先度 | 1／2／3／4（直す順番） | PMまたは品質担当が付ける。重要度とは別に決める |
原因分類 | 本来どの工程で見つかるべきだったか | 修正者が原因を特定したときに付ける |
修正者／修正日 | 直した人と日付 | ― |
修正内容 | どこを、どう直したか | 1〜2行。横展開の判断材料になる |
再テスト日／結果 | 確認した日と、OK／NG | 検出者本人が確認する |
状態 | 起票／受付／修正中／修正済／確認中／完了／取下げ／保留 | 「対応中」の一語にまとめない |
横展開 | 同じ原因の箇所を探したか、結果は何件か | 1件から10件見つかることがある |
このうち再現手順は、テンプレートの中でいちばん省略されがちで、いちばん効く欄です。「発注点を下回っても発注候補リストに出ない」だけでは開発側は動けませんが、「型番A-2280（発注点20・在庫15）で6/12の夜間バッチ後にリストを開くと表示されない」まで書けば、その日のうちに原因にたどり着けます。
3つの分類を必ず付ける
重要度と優先度を分けるのは、この2つが一致しないからです。表記ゆれ（重要度C）でも、同じ画面に40か所あって利用者の混乱を招くなら優先度は上がります。逆に業務が止まる不具合（重要度S）でも、確実な回避策があって発生条件が稀なら、稼働後の改善に回せます。分けて書いておくと、なぜその順番にしたのかが後から分かります。
そして3つめの「本来見つかるべき工程」が、この記事でいちばんお伝えしたい欄です。1件ごとに見ると意味が薄いのですが、集計するとテストそのものが機能しているかを教えてくれます。
■ 5. 記入例（架空企業：セイワ医科器械）
医療機器メーカーのセイワ医科器械（年商142億円・従業員780名・取引先1,900施設）が、保守サービス管理システムを刷新したプロジェクトです。期間14か月、規模112KStep（5サブシステム）、承認予算枠2億2,000万円。
結合テストが8週間たっても収束せず、3月の第1週を使って、それまでの455件を1件ずつ「本来ならどの工程で見つかるべき不具合だったか」で分類しました。
本来見つかるべき工程／原因 | 件数 | 割合 |
|---|---|---|
単体テストで見つかるべきもの | 196件 | 43% |
仕様の解釈違い（設計書のあいまいさ） | 118件 | 26% |
テストデータの不備（テスト側の問題） | 82件 | 18% |
環境・設定の問題 | 41件 | 9% |
本当の結合不具合（モジュール間の連携） | 18件 | 4% |
合計 | 455件 | 100% |
この表を見た瞬間に方針が決まりました。結合テストで結合の不具合が4%しか出ていないということは、このテストは結合テストとして機能していないということです。単体テストの代わりをさせられている状態でした。人を増やして直す速度を上げても、196件の後ろに控えている単体レベルの不具合が次々に出てくるだけです。直す速度の問題ではなく、入ってくる量の問題でした。
さらに、サブシステム別に見ると偏りがありました。
サブシステム | 規模 | 検出件数 | 不具合密度（件/KStep） | 単体テストのケース密度 |
|---|---|---|---|---|
点検予定管理 | 24KStep | 68件 | 2.83 | 21ケース/KStep |
修理受付 | 31KStep | 74件 | 2.39 | 22ケース/KStep |
部品在庫 | 28KStep | 231件 | 8.25 | 6ケース/KStep |
請求連携 | 19KStep | 52件 | 2.74 | 19ケース/KStep |
共通基盤 | 10KStep | 30件 | 3.00 | 18ケース/KStep |
全体 | 112KStep | 455件 | 4.06 | ― |
部品在庫だけが、他の3倍近い密度で不具合を出していました。理由もはっきりしています。部品在庫だけ、別のチームが担当していたのです。9月の増員時に加わった要員で構成され、そのチームには単体テストのケース作成基準が共有されていませんでした。他が18〜22ケース/KStepなのに対し、部品在庫は6ケース/KStepしか作っていません。悪意でも手抜きでもなく、単に伝わっていなかっただけです。こういうことは、増員のタイミングでよく起きます。
この2つの表は、どちらも不具合管理表に原因分類とサブシステムの欄があったから作れたものです。逆にいえば、その2列が無ければ、いくら件数を数えても打ち手にはたどり着けません。
■ 6. 収束しているかどうかの見方
②集計ダッシュボードでいちばん大事なのが、週別の発生件数と未解決件数のグラフです。
健全なテストは、前半に山ができて、後半に向かって減っていきます。毎週同じくらい出続けるのは、テストが見つけている層と、テスト対象の作り込みの層が合っていないサインです。
セイワ医科器械では、3月7日で結合テストをいったん止め、4週間で次の4つを行いました。
やったこと | 内容 |
|---|---|
部品在庫の単体テストをやり直す | 他と同じ20ケース/KStepの水準まで引き上げる。28KStep×20＝560ケースに対し既存が168ケースなので、392ケースを追加作成。この4週間で187件を検出し、結合テストに出る前に潰した |
設計書のあいまい箇所を確定させる | 118件の原因になった記述を洗い出し、仕様確認票にまとめて業務部門と64項目を確定した |
テストデータを本番同等に差し替える | 82件の原因だった、件数不足・パターン不足のテストデータを入れ替えた |
移行リハーサルを前倒しする | テストが止まっている間、インフラ担当と業務部門の手が空くため、6月予定のリハーサルを3月に実施した |
4つめが、この事例の工夫です。止めるという判断は、止めている間に何をするかとセットで出す。「止めます」だけでは関係者は不安になりますが、「止めて、その間にこれとこれをやります」なら話が通ります。結果として、4週間止めたにもかかわらず稼働日は動きませんでした。
■ 7. 運用ルール
ルール | 内容 | 理由 |
|---|---|---|
再現手順が無い行は受け付けない | 起票時にPMまたは品質担当が点検し、足りなければ差し戻す | 差し戻しのやり取りが、いちばん時間を食う |
重要度は検出者、優先度はPMが付ける | 2つの列を別の人が付ける | 同じ人が付けると、どうしても一致してしまう |
原因分類は修正時に必ず入れる | 原因が分かった時点で、修正者が入力する | 後からまとめて分類するのは、非常に手間がかかる |
完了は検出者が確定する | 修正者は「修正済」までしか進められない | 直したつもりを防ぐ |
毎日の集計は3つだけ見る | 今日の発生件数／未解決件数／優先度1の残件数 | 全件を眺めると、会議が長くなり形骸化する |
週次で原因分類を集計する | 内訳の変化を見る。特定の分類が増えていないかを確認する | 収束しないときに、打ち手を決める材料になる |
状態の遷移を決めておくのも効きます。起票 → 受付 → 修正中 → 修正済 → 確認中 → 完了。この6段階にしておくと、「修正済だが確認されていないもの」が何件あるかが一目で分かります。「対応中」という一語にまとめてしまうと、この滞留が見えません。
■ 8. 活用シーン
場面 | 使い方 |
|---|---|
単体・結合テスト期間 | 毎日の朝会で3つの数字（発生／未解決／優先度1の残）を確認する |
不具合が収束しないとき | それまでの全件を原因分類で仕分け、入ってくる量の問題かを判定する |
工程完了の判定 | 不具合密度が基準内か、未解決が優先度別にゼロかを確認する |
受入テスト | 業務部門が起票するため、再現手順の書き方をテンプレート化して配る |
稼働判定 | 優先度1・2の未解決がゼロであることを、稼働の必須条件にする |
稼働後の振り返り | 工程別の検出件数から、どの工程を強化すべきかを次の案件に引き継ぐ |
■ 9. よくある失敗と直し方
失敗 | 起きること | 直し方 |
|---|---|---|
件数だけを毎日報告している | 良いのか悪いのか判断できない | 発生件数と未解決件数をグラフにして、形で判断する |
重要度と優先度が同じ列 | 軽微だが多発する不具合が放置される | 2列に分け、付ける人も分ける |
原因分類の欄がない | 減らないときに、何を直せばいいか分からない | 「本来見つかるべき工程」の欄を足し、修正時に入力する |
「対応中」が何週間も続く | どこで止まっているか分からない | 状態を6段階に分け、滞留している段階を見えるようにする |
横展開をしていない | 同じ原因の不具合が、後の工程で次々に出る | 横展開の欄を置き、修正時に同種の箇所を探して件数を記録する |
収束しないのに人を増やす | 直す速度は上がるが、出てくる量は変わらない | まず原因分類で仕分け、入ってくる量の問題かを確かめる |
■ 10. 導入効果
観点 | 分類欄が無かったとき | 3つの分類を付けたとき |
|---|---|---|
収束しない原因の特定 | 「直す速度が足りない」としか言えない | 単体レベルが43%と分かり、打ち手が決まる |
偏りの発見 | 気づかない | 部品在庫の密度が他の3倍（8.25件/KStep）と分かる |
打った手 | 増員して直す速度を上げる | 4週間止めて、単体テストを392ケース追加。187件を先に潰した |
再開後の収束 | ― | 再開1週目42件から毎週減り、7週で未解決ゼロ |
稼働日 | ― | 2025年7月1日の予定どおり（4週間止めても動かなかった） |
受入テストの不具合密度 | ― | 基準0.25件/KStep以下を達成 |
4週間止めても稼働日が動かなかったのは、止めている間にやることを用意していたからです。移行リハーサルを前倒ししたことで、後工程の作業が先に片づきました。不具合管理表そのものの効果ではありませんが、原因分類の集計があったからこそ「何を止めて、何を前に出すか」を決められました。
■ まとめ
不具合管理表は、件数を数えるための表ではありません。テストが機能しているかどうかを判定するための表です。そのために必要なのが、重要度・優先度・本来見つかるべき工程の3つの分類でした。
いま運用している管理表に原因分類の欄が無ければ、次のテスト工程が始まる前に1列足してみてください。集計しはじめて2週間もすれば、「どこを直すべきか」がはっきり見えてきます。