バグ管理表の項目とテンプレート｜優先度・重要度とステータス遷移

バグ管理表（不具合管理表）とは、見つかったバグを1件1行で記録し、「いま何件が、どの状態にあるか」をチーム全員が同じ数字で見られるようにする台帳です。1件ごとの詳しい内容を書くバグ票（バグ報告）に対して、管理表は全体を見渡して順番と担当を決めるためのものです。

この記事は、1件の書き方ではなく台帳の設計と運用に絞っています。全22項目の一覧、貼り付けて使えるタブ区切りのテンプレートと記入例10件、優先度と重要度の判定マトリクス、ステータス遷移図、集計の数式までを載せました。例は架空の「備品予約システム」のテストを題材にしています。

確認環境：COUNTIFS の数式は LibreOffice Calc 24.2.7 のヘッドレス実行で計算し、掲載した結果と一致することを確かめています（COUNTIFS の書式は Microsoft サポートのページを2026年10月5日に開いて確認）。累積件数の計算は Python 3.11 で実行しました。Mermaid の状態遷移図は @mermaid-js/mermaid-cli 11.14.0 と Chromium で描画できることを確かめています。

バグ管理表の早見表

管理表の全22項目（必須・任意と入力値）

「いつ必須になるか」を3段階に分けると、起票の手間を増やさずに、後から集計に必要な項目もそろいます。列の記号（A〜V）は、後半の数式でそのまま使います。

設計のポイントは3つです。

• 選択肢のある項目は、自由入力にしない。「対応中」「対応中 」「着手」のように表記がそろわないと、COUNTIFS の件数が合わなくなります。表計算ソフトの、決まった選択肢から選ばせる機能を使います。
• 担当者は1人だけにする。2人書くと、どちらも相手が動くと考えがちです。
• 再現手順などの長い文章は管理表に書かず、バグ票へのリンクにする。1行が画面に収まり、全体を見渡せます。

タブ区切りテンプレートと記入例10件

見出し行だけのテンプレート

次の1行をコピーして、表計算ソフトのセル A1 に貼り付けると、A〜V 列の見出しになります。

ID  起票日 起票者 件名  機能  発生環境    検出工程    重要度 優先度 ステータス   担当者 対応期限    原因区分    対応内容    修正日 確認者 クローズ日   差し戻し回数  関連ID    却下理由    詳細  備考

記入例10件（主な列）

10件の中には、次の場面が入っています。

記入例10件（全22列・タブ区切り）

シート名を「台帳」にして A1 に貼り付けると、後半の数式がそのまま使えます。

ID  起票日 起票者 件名  機能  発生環境    検出工程    重要度 優先度 ステータス   担当者 対応期限    原因区分    対応内容    修正日 確認者 クローズ日   差し戻し回数  関連ID    却下理由    詳細  備考
BUG-001 2026-09-14  田中  予約登録で、終了時刻が開始時刻より前でも登録できる   予約登録    検証  結合テスト   S2  P2  完了  佐藤  2026-09-18  実装の誤り   時刻の前後を確かめる入力チェックを追加 2026-09-16  田中  2026-09-17  0               
BUG-002 2026-09-14  鈴木  ログイン画面の組織名の表記が誤っている ログイン    検証  結合テスト   S4  P1  完了  高橋  2026-09-15  実装の誤り   文言を修正   2026-09-15  鈴木  2026-09-15  0               利用者向け説明会の前に修正
BUG-003 2026-09-15  田中  予約一覧で、101件目以降が表示されない    予約一覧    検証  結合テスト   S2  P2  完了  佐藤  2026-09-22  設計の誤り   ページ送りの設計を見直して修正 2026-09-18  田中  2026-09-22  1               1回目の修正では200件目以降が出ず差し戻し
BUG-004 2026-09-16  伊藤  年度切替の処理が途中で異常終了する   年度切替    検証  結合テスト   S2  P3  保留  高橋  2026-10-30                      0               次に使うのは翌年3月。次の版で対応と決定
BUG-005 2026-09-17  鈴木  検証環境で、予約登録がすべてエラーになる    予約登録    検証  総合テスト   S1  P1  完了  佐藤  2026-09-17  環境・設定   データベース接続数の上限設定を修正   2026-09-17  鈴木  2026-09-18  0               
BUG-006 2026-09-18  伊藤  予約を取り消しても、空き状況が「予約済み」のまま    予約取消    検証  総合テスト   S2  P1  再発  佐藤  2026-09-25  実装の誤り   取消時の空き状況の更新処理を修正    2026-09-21  伊藤      0               2026-09-22 に完了、2026-09-29 に再発
BUG-007 2026-09-22  田中  予約一覧の並び順が登録順になっている  予約一覧    検証  総合テスト   S3  P3  却下  高橋                      2026-09-24  0       仕様どおり       画面設計書の記載どおり。要望として別管理
BUG-008 2026-09-24  鈴木  通知メールの件名に備品名が入らない   通知  検証  総合テスト   S3  P2  確認待ち    高橋  2026-10-02  実装の誤り   メールのテンプレートを修正   2026-09-29          0               
BUG-009 2026-09-28  伊藤  備品名に絵文字を入れると、検索結果が0件になる 備品検索    検証  総合テスト   S3  P4  対応中 佐藤  2026-10-09                      0               
BUG-010 2026-09-30  田中  予約変更画面で「戻る」を押すと入力内容が消える 予約変更    検証  受入テスト   S3      新規                              0               

優先度と重要度の違いと判定マトリクス

重要度（重大度、Severity）は「バグそのものの影響の大きさ」、優先度（Priority）は「直す順番」です。重要度は、誰が見てもほぼ同じ値になる事実の評価で、優先度は、期限や影響する人数などの事情を加えた判断です。

重要度の基準

優先度の基準

重要度×優先度の判定マトリクス（16マス）

多くのバグは左上から右下への対角線（S1 なら P1、S4 なら P4）に並びます。対角線から外れるマスこそ、重要度と優先度を分けて持つ意味が出る所です。

マトリクスを使うときの決まりごとを3つ挙げます。

• 重要度を、優先度の都合で書き換えない。「急がないから S3 にしておく」をすると、あとで品質を数えるときに実態が見えなくなります。急がないなら、重要度はそのままで優先度を下げます。
• 対角線から2マス以上離れるときは、理由を備考に書く。BUG-004 の「次に使うのは翌年3月」のような一言で十分です。
• S1・S2 を P4 にしない。時期を決めないまま置くと忘れられやすいので、保留にして見直す日を備考に入れます。

ステータス遷移図（Mermaid の stateDiagram）

9つのステータスと、差し戻し・再発・却下を含む遷移です。Mermaid に対応したエディタやWikiに貼ると、そのまま描画されます。

stateDiagram-v2
    [*] --> 新規: 起票
    新規 --> 受付済: 内容を確認し担当者を決定
    新規 --> 却下: 仕様どおり・重複・再現せず
    受付済 --> 対応中: 調査・修正を開始
    受付済 --> 保留: 次の版で対応と決定
    保留 --> 受付済: 対応を再開
    対応中 --> 修正済: 修正を取り込み
    対応中 --> 却下: 調査の結果、対応しないと判断
    修正済 --> 確認待ち: 検証環境に反映
    確認待ち --> 完了: 起票者が修正を確認
    確認待ち --> 対応中: 差し戻し（直っていない）
    完了 --> 再発: 同じ現象がもう一度発生
    再発 --> 対応中: 調査を再開
    却下 --> 受付済: 却下に異議あり（再検討）
    完了 --> [*]
    却下 --> [*]

遷移ごとの「動かす人」と条件

図の矢印1本ごとに、誰が・何を満たしたら動かしてよいかを決めておきます。

差し戻し・再発・却下の使い分け

却下は「なかったこと」にするのではなく、判断の記録として行を残します。同じ内容がまた起票されたときに、関連IDで前回の判断をすぐ示せます。

COUNTIFS で状態別・原因別に集計する

集計用のシートを別に作り、台帳の列を COUNTIFS で数えます。Microsoft サポートのページによると、書式は「COUNTIFS(条件範囲1, 検索条件1, [条件範囲2, 検索条件2], …)」で、追加する範囲は、最初の範囲と同じ行数・列数にそろえる必要があります。

次の数式は、前の章の10件を「台帳」シートの A1 から貼った状態（データは2〜11行目）で計算した結果です。行が増えたら、範囲の「11」を最終行に合わせて変えます。

状態別の件数

A列にステータス名を縦に並べておけば、=COUNTIFS(台帳!$J$2:$J$11,A2) を下へコピーするだけで同じ表になります。

原因別の件数

定例で見る件数

期限を過ぎた2件は BUG-006（期限 9月25日）と BUG-008（期限 10月2日）です。毎日の確認に使うときは、DATE(2026,10,5) を TODAY() に置き換えます。日付で比べる数式は、起票日やクローズ日が文字列ではなく日付として入っていることが前提です。貼り付けたあとにセルが左寄せのままなら、日付として認識されていないので、表示形式を確かめます。

バグ収束曲線用の累積件数を Python で計算する

バグ収束曲線は、横軸に日付、縦軸に累積起票数と累積クローズ数を取った折れ線グラフです。2本の線の差が、その日の未解決の件数になります。起票の線の伸びがゆるやかになり、クローズの線が追いついてくれば、テストが落ち着いてきたと読めます。

台帳をタブ区切りで保存したファイル（bugs.tsv、見出しは前の章と同じ）から、日ごとの件数を求めます。標準ライブラリだけで動きます。

# バグ収束曲線用に、日ごとの累積起票数・累積クローズ数・未解決数を求める
# 使い方: python3 convergence.py bugs.tsv
import csv
import sys
from collections import Counter
from datetime import date, timedelta

with open(sys.argv[1], encoding="utf-8", newline="") as f:
    rows = list(csv.DictReader(f, delimiter="\t"))

opened = Counter(date.fromisoformat(r["起票日"]) for r in rows)
closed = Counter(date.fromisoformat(r["クローズ日"]) for r in rows if r["クローズ日"])

day = min(opened)
last = max(list(opened) + list(closed))
cum_open = cum_close = 0
print("日付        起票  クローズ  累積起票  累積クローズ  未解決")
while day <= last:
    cum_open += opened[day]
    cum_close += closed[day]
    if day.weekday() < 5:        # 土日は行を出さない（件数は累積に含める）
        print(f"{day}  {opened[day]:>4}  {closed[day]:>8}  {cum_open:>8}"
              f"  {cum_close:>12}  {cum_open - cum_close:>6}")
    day += timedelta(days=1)

実行結果（記入例の10件）：

日付        起票  クローズ  累積起票  累積クローズ  未解決
2026-09-14     2         0         2             0       2
2026-09-15     1         1         3             1       2
2026-09-16     1         0         4             1       3
2026-09-17     1         1         5             2       3
2026-09-18     1         1         6             3       3
2026-09-21     0         0         6             3       3
2026-09-22     1         1         7             4       3
2026-09-23     0         0         7             4       3
2026-09-24     1         1         8             5       3
2026-09-25     0         0         8             5       3
2026-09-28     1         0         9             5       4
2026-09-29     0         0         9             5       4
2026-09-30     1         0        10             5       5

9月22日の行は、累積起票 7・累積クローズ 4 で、前の章の COUNTIFS の結果と一致します。出力を表計算ソフトに貼り、「累積起票」と「累積クローズ」の2列で折れ線グラフを作れば収束曲線になります。

曲線の読み方（目安の例）

この例では、9月28日から未解決が 3 → 4 → 5 と増えています。終盤に起票が続いているので、原因別でいちばん多い「実装の誤り」（4件）に絞って、同じ種類の見落としがないかを確かめる、という動きにつながります。

なお、再発した BUG-006 はクローズ日を空欄に戻しているため、この計算では「まだクローズしていない1件」として数えています。過去の時点の件数をそのまま残したい場合は、毎日の出力を別のシートに貼り足していきます。

運用ルール：台帳を保つための決まりごと

定例の進め方（15分の例）

表計算ソフトから専用ツールへ移る目安

道具を変えても、22項目・9つのステータス・遷移ごとの「動かす人」はそのまま持っていけます。ツールの項目や状態の設定に写すだけです。

よくある質問

Q. 重要度と優先度を、1つの項目にまとめてもよいですか？ A. 小さなチームでは1つにまとめる運用もあります。ただ、BUG-002（軽微だが急ぐ）や BUG-004（重大だが急がない）のような行が出てくると、1つの値では表しきれません。件数が20件を超えるころから、分けておくほうが順番を決めやすくなります。

Q. ステータスが9つは多く感じます。減らせますか？ A. 「修正済」と「確認待ち」を1つにまとめ、「受付済」を省いて、新規・対応中・確認待ち・完了・保留・却下・再発の7つにする形がよく使われます。減らす場合も、差し戻し（確認待ちから対応中へ戻る矢印）と却下は残しておくと、件数の説明がしやすくなります。

Q. バグか仕様変更かで意見が分かれたら、どう記録しますか？ A. 行は消さずに、判断がつくまで新規または受付済のまま備考に論点を書きます。仕様どおりと決まったら却下（仕様どおり）にし、変えたい内容は要望の一覧に移して関連IDでつなぎます。

Q. 原因区分は、どこまで細かく分けるとよいですか？ A. 最初はこの記事の7区分で十分です。集計して特定の区分に件数が集まってきたら、その区分だけを2〜3個に分けます（例：「実装の誤り」を「入力チェックのもれ」「条件分岐の誤り」などに）。最初から細かくすると、選ぶ人によって分け方がそろいにくくなります。

まとめ

• バグ管理表は全体を見渡して順番と担当を決める台帳。1件の詳しい内容はバグ票に書き、リンクでつなぐ
• 項目は22個を「起票時・受付時・対応とクローズ時」の3段階で必須にすると、起票の手間が増えない
• 重要度は影響の大きさ（起票者が付ける）、優先度は直す順番（管理者が決める）。重要度を優先度の都合で書き換えない
• 16マスのマトリクスで、対角線から外れる行は理由を備考に残す
• ステータスは9つ。遷移ごとに「動かす人」と条件を決め、完了は起票者が付ける
• 状態別・原因別は COUNTIFS、収束の様子は累積起票数と累積クローズ数の差で見る
• 行は削除せず、却下・保留も判断の記録として残す

参考・出典

• Microsoft サポート「COUNTIFS 関数」https://support.microsoft.com/ja-jp/office/countifs-関数-dda3dc6e-f74e-4aee-88bc-aa8c2a866842

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。