これは何か
障害管理表は、テストなどで見つかった不具合を1件ずつ記録し、重さ・状態・担当・直した結果を追いかける成果物です。
不具合を見つけることより、見つかった不具合を漏れなく最後まで追いかけることが、この表の役割です（10-01 テストは何のためにするのか）。
なぜ作るか
- 見つかった不具合を、忘れずに直す
- どの不具合から直すかを、重さで判断できる
- テストの終了判断の材料になる（10-06 テストをいつ終了してよいのか）
- 同じ場所で繰り返し起きる不具合に気づける
誰が使うか・いつ作るか
- 書く人：テストの担当（見つけた人）
- 使う人：開発の担当、テスト・品質管理の責任者、終了を判断する人
- テストの開始から使い、不具合が見つかるたびに記録します
- アステリア案件の不具合の件数・内容は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
テストに関係する記載
- P-010 宮田 直人 — テスト・品質管理リーダー
- Unit 10-05 のタイトルは「障害の重大度をどう決めるのか」
- 関連する成果物：TST-004 品質状況ダッシュボード、TST-006 利用者受入テスト・終了判定報告書
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 障害管理表の行
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
| 番号 | 見つかった内容 | 再現の手順 | 重大度 | 関係する要件 | 状態 | 担当 | 直した結果の確認 |
|---|---|---|---|---|---|---|---|
| DEF-EX-001 | 請求データの合計が画面と帳票で違う（例） | 条件Aで帳票を出す（例） | 高（例） | REQ-FUNC-0123 | 修正中（例） | 開発担当（例） | — |
| DEF-EX-002 | 入力欄の説明文の誤字（例） | 画面Bを開く（例） | 低（例） | REQ-FUNC-0124 | 確認済み（例） | 開発担当（例） | 再テストで確認（例） |
番号・内容はすべて教材上の例です。
何を書いてはいけないか
- 再現の手順がない記録（直す人が確かめられない）
- 見た目の印象だけで決めた重大度
- 直したことを、確かめずに「完了」にする
どこを見るか
- 重大度の基準が決まっていて、その基準で付けられているか
- 再現の手順と、関係する要件が書かれているか
- 状態が、「見つかった → 修正 → 再テスト → 確認済み」のように追えるか
- 長く止まっている不具合がないか
- 同じ機能・同じ原因らしき不具合が、繰り返していないか
赤信号
- 重大度「高」の不具合が、長く「修正中」のまま
- 「仕様どおり」で閉じた不具合に、誰が判断したかの記録がない
- 再テストの結果がないのに「確認済み」
- 同じ内容の不具合が、別の番号で何件も登録されている
関係するUnit
- Unit：10-01 テストは何のためにするのか、10-06 テストをいつ終了してよいのか、10-05 障害の重大度をどう決めるのか
- 成果物：TST-004 品質状況ダッシュボード、REQ-004 要件追跡表
AI WORKFLOW
「この障害管理表を確認し、①再現の手順がない記録、②重大度の付け方が基準と合っていない可能性がある記録、③同じ内容と思われる記録、④長く状態が変わっていない記録、を挙げてください。重大度を変更したり、原因を断定したりしないでください。」
AIは、似た不具合をまとめたり、傾向を集計したりする作業に役立ちます。
REVIEW
- 「同じ内容」とされた記録が、本当に同じ不具合か
- AIが原因を推測で書き足していないか
- 集計に使った表が、最新の状態か
人間が判断すること
- 不具合の重大度
- 直す順番、または直さずに受け入れるか
- 「仕様どおり」として閉じてよいか
いつ使うか
この教材では STAGE 10｜本当に動くことを証明する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この表から、今いちばん先に直すべき不具合がどれか、根拠をもって言えますか？