このユニットの結論
テストで見つかった不具合の重大度は、担当者の印象や声の大きさで決めるものではありません。
「業務にどんな影響があるか」を軸にした基準を、テストを始める前に決め、その基準に照らして1件ずつ付けるものです。重大度（どれだけ深刻か）と、優先度（どの順に直すか）は分けて考えます。
1. 何の話か
このユニットは、テストで見つかった不具合（テストの世界では「障害」とも呼びます）の重大度の付け方の話です。
大きなプロジェクトでは、テストで多くの不具合が見つかります。すべてを同時には直せないため、どれが深刻で、どれから直すかを決める必要があります。その土台になるのが重大度です。
本番で起きた障害の重大度の判断は、13-02 障害の重大度を判断するで扱います。
2. なぜ必要か
重大度の基準がないと、
- 同じような不具合に、担当者ごとに違う重大度が付く
- 報告の見た目が派手な不具合が優先され、業務に深刻な不具合が後回しになる
- 「重大な不具合が残っているか」が分からず、テストを終えてよいか判断できない（10-06）
ということが起きます。
3. このユニットで分かること
- 重大度と優先度の違い
- 重大度の基準の作り方
- 重大度を付けるときに確かめること
- 重大度の判断で、AIに任せてよいことと人間が決めること
4. 重大度と優先度は違う
| 言葉 | 意味 | 決める軸の例 |
|---|---|---|
| 重大度 | その不具合が、どれだけ深刻か | 業務への影響、データへの影響、回避策の有無 |
| 優先度 | どの順番で直すか | 重大度に加えて、直す手間、次の工程の予定、関係する機能の数 |
たとえば、画面の文字の誤りは、重大度は低くても、利用者全員が毎日見る画面なら、早めに直すこともあります。逆に、重大度が高くても、その機能を使い始めるのがずっと先で、先に直すべきものがあれば、直す順番を後にすることもあります。どちらも、その判断を記録に残します。
5. 重大度の基準の作り方
一般的には、業務への影響を軸に、3〜4段階の基準を作ります。
教材用サンプル基準の書き方を学ぶための例
| 重大度 | 基準（教材上の例） |
|---|---|
| 重大 | 業務の重要な処理ができない。データが壊れる・失われる。回避策がない |
| 高 | 業務の処理はできるが、手作業などの大きな回避策が必要 |
| 中 | 回避策があり、業務への影響は限られる |
| 低 | 見た目・表示の問題など、業務の処理に影響しない |
段階の数・名前・基準は教材上の例で、アステリア案件の基準ではありません。
基準には、判断に迷ったときの例（「この場合は高」など）を添えると、担当者ごとのばらつきが減ります。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 約1,500件の要件
- P-010 宮田 直人 — テスト・品質管理リーダー
- 成果物に TST-003 障害管理表、TST-004 品質状況ダッシュボードがある
アステリア案件の重大度の段階・基準、重大度を最終的に決める人は、正本に記載がありません。未確定
6. THINK — 報告した人が「重大」と書いた
利用部門の担当者から、次の不具合が「重大」として報告されました。
「一覧画面で、並び順が登録の順ではなく、名前の順になっています。とても見づらいので重大です。」
調べると、並び替えのボタンで登録の順に直すことができ、表示されるデータ自体に誤りはありませんでした。
問題
報告のとおり「重大」として扱うべきでしょうか。
判断例を開く
判断
基準に照らして付け直します。
確認すること:
- 業務の処理ができないか。データに誤りや欠けがあるか
- 回避策はあるか。回避策で業務が回るか
- 影響を受ける利用者・業務は、どの範囲か
- 報告した人の困りごとは何か（重大度とは別に、使いやすさの改善として扱う道もある）
基準で付け直した場合は、報告した人に理由を伝え、記録に残します。報告した人の困りごとを軽く扱うのではなく、重大度と優先度を分けて扱うということです。
7. 重大度を付けるときに確かめること
- 何が起きたか（再現の手順と、実際の結果・期待した結果）
- どの業務・どの利用者に影響するか
- データに影響するか（誤り・欠け・重複）
- 回避策があるか。その回避策は業務で続けられるか
- 同じ原因で、ほかの場所にも起きていないか
8. よくある失敗
- 報告した人が付けた重大度を、確かめずにそのまま使う
- 重大度と優先度を1つの欄で管理し、どちらの意味か分からなくなる
- テストの途中で基準を変え、前に付けた重大度と比べられなくなる
- 重大度を下げる判断を、理由を残さずに行う
- 件数の合計だけを見て、重大度ごとの内訳を見ない
9. 成果物との接続
- TST-003 障害管理表：不具合ごとに重大度・状態・担当を管理する
- TST-004 品質状況ダッシュボード：重大度ごとの件数と推移を示す
- SEC-005 セキュリティ評価報告書：見つかった弱点を、決めた基準で重大度を付けて報告する
危機演習 CR10 重大な脆弱性が発見される では、稼働の前に重大な問題が見つかった場面を体験します（学習上の接続です。正式な対応関係ではありません）。
10. AI WORKFLOW — 基準に照らした確認を手伝わせる
AIは、たくさんの不具合の記録を、基準に照らして見直す下書きに役立ちます。
指示例:
「次の重大度の基準と不具合の一覧を比べ、①基準と合っていない可能性がある記録、②回避策の有無が書かれていない記録、③影響する業務が書かれていない記録、を挙げてください。重大度を変更しないでください。」
11. REVIEW — AIの指摘を確認する
- AIが挙げた記録を、人が基準と元の記録で確かめたか
- AIが重大度を付け直したり、「問題ない」と判断したりしていないか
- AIが見落としている記録がないか（特に、データに影響する不具合）
12. 人間が判断すること
- 重大度の基準
- 個々の不具合の重大度（特に、重大・高の判断）
- 重大度を下げる、または例外として扱う判断
AIは、基準に照らした確認の下書きまでを手伝います。本番で起きた障害の重大度の判断は 13-02 で扱います。
13. 判断演習
あなたは、テストで見つかった不具合の重大度を付ける担当です。
次の2つの不具合のうち、重大度が高いのはどちらだと考えますか。判断のために、さらに確かめたいことも挙げてください。
- A：月に一度だけ使う画面で、保存するとデータの一部が消える
- B：毎日全員が使う画面で、ボタンの表示が崩れているが、操作はできる
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
重大度は、業務への影響を軸にした、事前に決めた基準で付けます。
重大度（深刻さ）と優先度（直す順番）を分け、付け直した判断は理由と一緒に残します。