不具合管理表テンプレート｜項目設計と運用の決め方

2026 10/02

2026年10月2日

テスト期間の後半、不具合管理表を開いて「この行、結局どうなったんだっけ」と手が止まったことはないでしょうか。

ステータスは「対応中」のまま2週間。担当者の欄は空。コメント欄に「確認します」とだけ書かれて、その後の記録がない——受託開発の現場で、かなりの頻度で見る光景です。

この記事は、そうならないための不具合管理表テンプレートを、列の設計と運用ルールの両面からまとめたものです。表の枠を配るだけでは不具合管理表は機能しません。どの列を、いつ、誰が埋めるかまで決めて初めて、表は生きた管理台帳になります。

なお、不具合1件ごとの「票」の書き方（再現手順の書き方や期待結果の表現）は、バグ票の書き方｜再現手順が伝わる項目とテンプレートで扱っています。本記事はその1件1件を束ねる一覧表の側に絞ります。

不具合管理表が機能しなくなる3つの瞬間

不具合管理表が死ぬのは、作った瞬間ではありません。運用の途中で、決まったタイミングで壊れます。

テスト代行として他社の管理表を引き継ぐ機会が多くありますが、崩れ方にはほぼ共通の型があります。

起票が増えた瞬間：件数が増えると一覧の見通しが落ち、重要なものが埋もれる。並べ替えや絞り込みができる列設計になっていないと、ここで破綻します
担当が分かれた瞬間：開発・テスト・顧客の3者が触り始めると、「今これは誰のボールか」が表から読み取れなくなります
再テストが始まった瞬間：修正済みと再テスト済みの区別がないと、直したつもりの不具合が未確認のままクローズされます

不具合管理表の設計で本当に効いてくるのは、件数が増えて担当が分かれた後半戦です。

逆に言えば、この3つの瞬間に耐えられる列とステータスを最初に入れておけば、表は最後まで使えます。以下では、その具体的な中身を決めていきます。

そのまま使える不具合管理表テンプレートの必須列

不具合管理表テンプレートの核になるのが列の設計です。ポイントは、列を「起票時に埋まるもの」と「対応の過程で埋まるもの」に分けて考えることです。

この2段階を分けずに1つの表としてだけ眺めると、「空欄が多い＝サボっている」ように見えてしまいます。実際には、まだ埋まる段階に来ていないだけ、ということが少なくありません。

起票時に埋める列

発見した人が、その場で埋め切る列です。ここが欠けると、後工程の全員が確認コストを払うことになります。

列	役割	記入のポイント
管理番号	一意の識別子	連番でよい。会話とチャットで参照する鍵になる
起票日	発見した日	滞留日数の計算に使う
起票者	発見した人	詳細を聞く相手を特定する
検出工程	結合／システム／UATなど	どの工程で漏れたかの分析に効く
検出環境	環境名とビルド・バージョン	「開発環境では直った」の食い違いを防ぐ
対象機能・画面	影響箇所	絞り込みと担当割り当ての軸になる
事象（表題）	一覧で内容が分かる1行	「エラーが出る」では識別できない
再現性	毎回／時々／1回のみ	修正可否と優先度の判断材料になる
重要度	不具合そのものの影響度	業務停止級か軽微かを事実として記録

対応の過程で埋まる列

起票後、担当者とPMが更新していく列です。ここを設計しておかないと、表は「報告の置き場」で止まり、進行管理の道具になりません。

列	役割	記入のポイント
優先度	いつ直すかの判断	重要度とは別の軸。PMが決める
ステータス	現在の状態	次節で設計する。ボールの持ち主が分かる名前にする
担当者	今のボールの持ち主	空欄を許さない。空欄は「全員の責任＝誰の責任でもない」
期限・修正予定	いつまでに／どのビルドで	「次のリリースで」は期限ではない
原因・対応内容	何をどう直したか	再発防止と顧客説明の根拠になる
再テスト結果	OK／NG	修正済みとは別の列にする
確認者・確認日	誰がいつ確認したか	クローズの正当性を担保する

重要度と優先度を同じ列にまとめたくなりますが、分けて持つのが鉄則です。重要度は事象の性質で決まり、優先度はビジネス都合で決まるため、両者はしばしばねじれます。この切り分けの判断基準はバグ修正の優先度決定プロセスで詳しく扱っています。

用語の定義そのものを社内で揃えたい場合は、JSTQBが公開するシラバス・用語集を物差しにすると、担当者ごとの解釈のブレを抑えられます。

任意列は「後から聞かれたこと」から決める

必須列に何を足すかは、プロジェクトによって変わります。迷ったときの決め方はシンプルです。前の案件で「それ、どうなってる？」と後から聞かれた項目を列にする、これだけで十分に実用的になります。

よく追加されるのは次のような列です。

顧客共有可否：社内検討中のものを誤って顧客に出さないための安全弁
仕様判断の要否：不具合か仕様かの判断待ちを明示する。この待ちは最も滞留しやすい
関連チケット・関連不具合：同一原因の束ねに使う。重複起票の発見にも効く
回避策の有無：条件付きでリリースできるかの判断に直結する
流出原因・作り込み工程：振り返りで使う。テスト中は空欄でよい

一方で、増やしすぎると更新されなくなります。列を足すときは「誰がいつ埋めるか」を同時に決め、答えられない列は作らないでください。

埋まらない列が並んだ表は、見た目こそ精緻ですが、実態は信用できない表です。

ステータス設計で滞留を防ぐ

不具合管理表で最も設計が甘くなりやすいのがステータスです。「未対応／対応中／完了」の3つだけで始めてしまい、後半で機能しなくなるパターンが典型です。

問題は「対応中」です。この名前は、調査中なのか、修正中なのか、顧客の返事待ちなのかを区別しません。結果として、動いていない行が「対応中」の中に積み上がります。

不具合のステータス遷移と、仕様確認中・再テストNG・対応しないへの分岐、および各状態のボールの持ち主を示した状態遷移図

ボールの持ち主が分かる名前にする

おすすめは、状態名に誰が動くべきかを含めることです。

ステータス	意味	ボールの持ち主
起票	登録直後、未着手	PM（トリアージ待ち）
調査中	原因を特定している	開発
仕様確認中	不具合か仕様かの判断待ち	顧客・業務側
修正中	原因が特定され、着手済み	開発
修正済（再テスト待ち）	修正完了、未検証	テスト担当
再テストNG	検証して直っていない	開発（差し戻し）
クローズ	再テストOK、確認者記録済み	—
対応しない	仕様・次期対応として合意済み	—（合意記録が必須）

「保留」という名前のステータスは置かないことをおすすめします。保留は例外なく滞留の墓場になります。

止めるなら「仕様確認中（顧客）」「次期対応（合意済み）」のように、なぜ止まっていて誰が動かすのかが読める名前にしてください。

滞留を可視化する

ステータスを分けたら、滞留を見つける仕組みを1つだけ入れます。起票日と現在日の差から「経過日数」を出し、ステータス別に見るだけで十分です。

「仕様確認中」が1週間を超えている行は、顧客側のボールが落ちています
「再テスト待ち」が溜まっている場合は、テストの手が足りていません
「調査中」が長い行は、原因不明であることを早めに表に出す必要があります

ここで見えた数字は、そのまま進捗報告の材料になります。報告書の章立てへの落とし込みはテスト結果報告書の書き方が参考になります。

運用ルールは3つだけ決める

列とステータスを整えても、運用ルールがなければ表は腐ります。とはいえルールを増やすと守られません。最初に決めるのは次の3つで足ります。

1行1不具合を徹底する：「ついでに似た事象も」と相乗りさせると、片方だけ直ってクローズされます
更新責任者を決める：担当者が自分で更新するのが理想ですが、徹底できないならPMが毎日まとめて反映する運用でも構いません
週1回の棚卸しをする：全件は見ません。経過日数の長い行と、担当者が空欄の行だけを見ます

棚卸しは「全部を見る会」にした瞬間に続かなくなります。見る対象を滞留と空欄だけに絞ってください。

この3つが回り始めると、表の更新が個人の記憶に依存しなくなります。担当者が休んでも状況が読める状態は、属人化を解く第一歩でもあります。関連する考え方はテスト業務の属人化を4層で解く現実的な対処法で整理しています。

顧客共有用と社内用を分ける

受託開発では、不具合管理表を顧客にも見せる場面が出てきます。このときに失敗しやすいのが、1つの表を列の非表示でやりくりすることです。

非表示列は、並べ替えやコピーの操作で簡単に露出します。社内の見積工数や、原因欄に書いた率直な記述が顧客の目に触れる事故は、実際に起こります。

用途	載せる情報	載せない情報
社内用	原因、想定工数、担当者の作業メモ、流出工程	—
顧客共有用	事象、影響範囲、対応方針、対応予定日、回避策	原因の詳細、工数、社内の責任分析

顧客共有用は「隠した表」ではなく、共有する項目だけで作り直した別の表にしてください。

共有の頻度も先に決めておきます。毎日更新するのか、週次でスナップショットを出すのかが曖昧だと、顧客が古い情報を見たまま議論が進みます。

スナップショットを出す曜日と、その時点で「対応予定日が未定の行をゼロにする」ことをセットで決めておくと、顧客との認識ずれがほぼ起きなくなります。

Excelを続けるか、ツールに移すか

不具合管理表はExcelやスプレッドシートで始めるのが現実的です。導入コストがなく、誰でも触れます。少人数で、短期間のプロジェクトであれば、最後までこれで問題ありません。

一方で、表計算ソフトには構造的な限界があります。判断の目安として、次のサインが2つ以上重なったら移行を検討する時期です。

同時に表を更新する人が3名を超えた（上書き事故と「どれが最新か」問題が起きます）
不具合の件数が数百件規模になった（絞り込みと集計が手作業では追いつきません）
誰がいつ何を変えたかの履歴が必要になった（表計算では追跡が困難です）
添付ファイル（スクリーンショット・ログ）が増えてきた
複数案件を横断して傾向を見たくなった

これは件数が多いから偉い、という話ではありません。手作業の確認コストが、ツール導入の手間を上回った時点が分岐点です。

逆に、1案件・少人数・短期であれば、ツール移行はむしろ速度を落とします。移行を検討する段階に来たら、おすすめテストケース管理ツール徹底比較で選択肢を確認してください。

なお、工程ごとの品質の捉え方や、組織としての基準づくりの参考資料としては、IPAが公開するソフトウェア開発分析データのような公的データも下敷きになります。

まとめ：不具合管理表テンプレートは運用とセットで配る

不具合管理表テンプレートを配っただけでは、表は機能しません。この記事で決めたのは、次の4点です。

決めること	要点
列	起票時に埋める列と、対応過程で埋まる列を分けて設計する
ステータス	ボールの持ち主が読める名前にする。「保留」は置かない
運用	1行1不具合・更新責任者・週1の棚卸しの3つだけ決める
共有	顧客共有用は非表示列でなく、別の表として作る

まず次の案件で、担当者の空欄をなくすことと、再テスト結果を修正済みと別の列にすることの2つだけでも試してみてください。この2つは手間がほとんどかからないわりに、終盤の混乱がはっきり減ります。

テスト工程の人手が足りず、管理表の更新まで手が回らない状態が慢性化している場合は、体制そのものの見直しが必要なサインかもしれません。テスト体制の見直しについてのご相談はお気軽にどうぞ。