システム活用法
不具合管理を回す
この記事でわかること
テストや運用で見つかった不具合は、「起票して終わり」にすると、直したかどうかが分からなくなります。本システムの不具合管理は、起票から調査、修正、再テスト、クローズまでを1つの流れで追い、品質を数字で見られるようにします。この記事では、その回し方を紹介します。
前提：プロジェクトの機能スイッチで「不具合管理」がオンになっていること。メニューの「不具合管理」から使います（ソフトウェア開発のテンプレートでは、最初からオンです）。
不具合の流れ
標準のステータスは、次の流れです。
| ステータス | 進捗率 | この状態にするとき |
|---|---|---|
| 新規 | 0% | 不具合を起票した |
| 調査中 | 20% | 再現確認・原因を調べている |
| 修正中 | 40% | 修正を進めている |
| 修正済み | 60% | 修正が終わり、再テスト待ち |
| 再テスト中 | 80% | 修正内容を確認している |
| クローズ | 100% | 確認して、対応が完了した |
| 対応しない／保留 | -2%／-1% | 再現しない・仕様どおり・重複など／一時保留 |
ステータスの名前は、管理画面の「ステータス」で変えられます。ただし、「修正済み」と「再テスト中」の進捗率（60%・80%）は、起票者の再テスト待ちの表示に使われます。名前を変えても、進捗率は変えないでください。
1. 起票：直す人が迷わない書き方
起票者は、次の項目を埋めます。
| 項目 | 書き方のポイント |
|---|---|
| タイトル | 「【画面名】起きていること」。例：「【受注入力】保存を押すと画面が固まる」 |
| 重要度 | 不具合そのものの影響の大きさ。致命的・重大・軽微・些細から選ぶ |
| 優先度 | 対応を急ぐ度合い。緊急・高・中・低から選ぶ。重要度とは別に決める |
| 不具合種別・再現性 | 機能不良、画面・表示、性能など／常に再現、時々再現、一度のみ、再現不可 |
| 発見者・発見日・発生バージョン・発生環境 | OS・ブラウザ・端末など。「どこで起きたか」が分かるように |
| 再現手順・期待結果・実際の結果 | 手順は番号付きで。期待と実際の差を、1行ずつ書く |
| 影響範囲 | 他に影響しそうな画面や業務 |
重要度と優先度は別物です たとえば「誤字」は重要度が些細でも、リリース前の画面なら優先度は高いことがあります。逆に、致命的でも、使われない機能なら優先度は低いこともあります。2つを分けて決めると、議論が噛み合います。
2. 調査・修正：原因を残す
- 担当者を決めます。ステータスを「調査中」にします。
- 原因が分かったら、「原因区分」（要件・仕様、設計、実装、テスト不足、環境・設定、データ、その他）と「原因」を書きます。
- 修正に入ったら「修正中」にし、終わったら「修正内容」「修正バージョン」を書き、「修正済み」にします。修正完了日も入れます。
- 工数は、「修正工数見積（時間）」と「修正工数実績（時間）」で残せます。計画人日を入れ、タイムシートに時間を入れる運用もできます（記事「タイムシートで実績を残し、見積の精度を上げる」）。
3. 再テスト：確認する人を決める
- 起票者（または確認する人）が、ステータスを「再テスト中」にして確認します。確認日と、再テスト結果（合格・不合格）を記録します。
- 合格なら「クローズ」にします。
- 不合格なら、ステータスを「修正中」などに戻し、不合格の内容をコメントに書きます。再度、修正から繰り返します。
- 「修正済み」「再テスト中」の不具合は、起票者のマイダッシュボードの「私の不具合」に、「あなたの再テスト（確認）待ち」として出ます。確認の抜けを防げます。
4. 品質を数字で見る
プロジェクトダッシュボード（管理員向け）の「品質（不具合管理）」には、次が出ます。PgMダッシュボードにも、プロジェクトごとの品質判定が並びます。
| 表示 | 読み方 |
|---|---|
| 品質判定 | 危険：致命的な不具合が未解決。注意：重大が未解決、14日を超える長期未解決あり、直近2週間で発生が解決を上回る、再テスト不合格率が20%以上（再テストが5件以上あるとき）。良好：どれにも当てはまらない |
| 重要度別の未解決 | 致命的・重大がゼロになっているか |
| 発生と解決の推移（週ごと） | 解決が発生を上回れば、収束に向かっている |
| 平均解決日数、再テスト不合格率 | 直し方の質と速さ |
| 原因区分別の不具合数 | どの工程で不具合が混入したか。再発防止の優先順位づけに使う |
運用のコツ
- 原因区分は必ず入れる：入れておかないと、振り返りで「どの工程が弱いか」を言えません。たとえば「要件・仕様」が多ければ、要件レビューを強化します。
- 定例会は、致命的・重大から：品質判定が危険・注意の理由を、そのまま議題にします。
- 長期未解決を放置しない：14日を超えたものは、担当替え、「保留」「対応しない」の判断、変更管理への切り出しを決めます。
- 関連設定でつなぐ：原因の成果物、直すWBSの作業、環境の課題と関連付けます。
- 定番の絞り込みを保存する：「重要度が致命的・重大で未解決」など（記事「保存した絞り込みでチームの定番ビューを作る」）。
まとめ
不具合管理は、直すための記録であり、品質を振り返るためのデータです。重要度と優先度を分け、原因区分を残し、再テストまで確認する。この3つを守れば、「直したつもり」を減らし、品質を数字で説明できるようになります。