不具合管理を導入する

前提

そのプロジェクトの管理員だけが導入できます。機能スイッチの「不具合管理」（画面のアドレスは /tasks/defect）をオンにすると使えます。起票・編集などの日々の操作は、参加者以上の権限が必要です（使い方は「不具合管理の使い方」を参照）。

不具合管理は、テストや運用で見つかった不具合を、起票・調査・修正・再テストを経て、クローズするまで追う種別です。標準の入力項目（重要度・優先度・不具合種別・再現性・再現手順・期待結果／実際の結果・発生環境／バージョン・原因区分・修正内容・再テスト結果など）が最初から用意されています。管理員の仕事は、使い始める前の準備と、運用の周知です。

導入の手順

機能スイッチをオンにする: 「設定・マスター」→「機能スイッチ」で、「不具合管理」をオンにします。クリックした瞬間に保存され、メンバーのメニューに「不具合管理」が出ます。管理画面の「プロジェクト管理」にも、「不具合管理」が現れます。
ステータスを確かめる: 「設定・マスター」→「ステータス」の「不具合」タブで、ステータスを用意します（下の「ステータスの準備」）。
管理カテゴリを決める: 「管理カテゴリ」の「不具合」タブで、分類を登録します（任意）。
ステージを決める: 「ステージ」で、工程の名前を登録します（任意。ほかの種別と共通です）。
チームと承認者を整える: 「プロジェクト体制図」にチームを作り、修正や確認の担当を決めます。
必要なら、カスタム項目を足す: 標準の項目に無い欄が必要なときに足します。
メンバーに運用ルールを周知する: 起票の基準、重要度と優先度の付け方、再テストの流れを伝えます。
品質の見える化を確かめる: ダッシュボードに、不具合の集計が出ることを確認します。

ステータスの準備

不具合のステータスは、プロジェクトの作り方によって、最初から入っているものが違います。

プロジェクト	「不具合」タブのステータス
不具合管理の機能が追加されたときにすでにあったプロジェクト	標準の8種が入っています。新規（0）／調査中（20）／修正中（40）／修正済み（60）／再テスト中（80）／クローズ（100）／対応しない（-2）／保留（-1）
「ソフトウェア開発」テンプレートで作ったプロジェクト	5種です。新規（0）／修正中（50）／確認待ち（80）／完了（100）／対応しない（-2）
それ以外のテンプレートや「空」で作ったプロジェクト	何も入っていません。自分で登録します

括弧内の数字は進捗率です。ステータスがひとつも無いと、起票してもステータスが空になります。必ず、使い始める前に登録してください。

進捗率が、集計の意味を決めます 不具合の「未解決」は、進捗率が100（完了）と-2（対応しない）以外のステータスです。保留（-1）は、未解決に含まれます。「完了」に当たるステータスの進捗率は、必ず100にしてください。

「再テスト待ち」は、進捗率60と80で見分けています マイダッシュボードの「再テスト待ち」（自分が起票した、修正済み・再テスト中の不具合）は、進捗率が60か80のステータスを対象にします。独自のステータスを作るときも、「修正が済んで確認を待つ」段階は、60か80にしておくと、この表示が働きます。

ステータスは、使い始めてから変えると、集計や一覧の見え方が変わります。最初に、運用に合った名前と進捗率を決めてください（「ステータスと分類を設計する」を参照）。

管理カテゴリ・ステージ・チーム・承認者

設定	不具合での使いどころ
管理カテゴリ（不具合タブ）	「対象の機能・画面」「対象システム」など、不具合を整理する切り口。カンバンをカテゴリでグループ化できます
ステージ	発見した工程や、対応中の工程を表す名前（例: 単体テスト・結合テスト・受入テスト）。TODOや課題などと共通の一覧です
チーム（主管チーム）	「プロジェクト体制図」のチームを指定します。カンバンをチーム別にグループ化すると、チームごとの残量が見えます
承認者	修正の確認をする人を、1人記録する欄です。承認ワークフローの対象ではありません

不具合には、完了基準の欄はありません。重要度・優先度・再現手順などの項目は、起票・編集画面の「分類」「発生状況」などのまとまりに並びます。

承認ワークフローは、不具合では使えません 承認を順番に回せるのは、変更管理と成果物だけです。不具合の修正確認は、「承認者」の欄と、再テスト結果の記録、ステータスの運用で行います。

品質の見える化

不具合を使い始めると、次のダッシュボードに、不具合の集計が加わります。

マイダッシュボード: 自分が担当する未解決の件数、重要度が高いもの、再テスト待ち。
プロジェクトダッシュボード（管理員向け）: 未解決の重要度別件数、直近の発生数と解決数、原因区分別の件数、長期未解決、平均の解決日数、再テストの不合格率、品質判定。
PgMダッシュボード: 複数のプロジェクトの、同じ集計。

品質判定	条件
危険（赤）	致命的な不具合が、未解決で残っている
注意（黄）	重大な不具合が未解決／発見から14日を超えた未解決がある／直近2週間の発生が解決を上回っている／再テストの不合格率が20%以上（再テスト済みが5件以上あるとき）
良好（緑）	上のどれにも当たらない

この集計は、「発見日」と「完了日」、「重要度」、「原因区分」、「再テスト結果」の入力を元にしています。入力が少ないと、集計の精度が下がります。メンバーには、この4つを入れるように伝えてください。管理画面のダッシュボードには、「不具合管理」の件数のカードも出ます。クリックすると、一覧が開きます。

ほかの機能との関係

関連タスク: 不具合も、ほかのタスクやWBSと、先行・後続・関連の関係を設定できます。
タイムシート・工数: 計画人日と、タイムシートから集計される実績人日が、不具合にも付きます。PgMの工数消化や、バーンダウンの残りの作業量にも、含まれます。
外部連携: 不具合の起票・更新も、Slack・Teamsなどへの通知と、読み取りAPIの対象です（「外部連携を設定する（Slack・Teams・Webhook・読み取りAPI）」を参照）。
データの退避・復元: 不具合のデータは、プロジェクトのデータの退避・復元の対象です。

オフにしても、データは消えません 機能スイッチで「不具合管理」をオフにすると、メンバーは使えなくなりますが、データは残ります。再びオンにすれば、元のとおり見られます。