# バグと変更管理

不具合が見つかったあとも、要求からの一続きで管理できます。直したことが、次の改善の材料として残ります。

バグは専用の別画面ではなく、**タスクと同じカンバンボード**に「不具合」種別のカードとして並びます。見積もり・開発サイクル・PR紐付けも普通のタスクと同じように扱えます。

![PM on Railsのカンバン上のバグ。不具合も同じ列で進む。導入前はバグを別のツールで管理していた。導入後は影響するシナリオと要件へ戻せる。](https://pmonrails.com/docs-img/kanban.png)

## バグ（不具合）

- **バグもタスクとして扱う** — バグは専用の別物ではなく「不具合」の種類のタスク。カンバン・見積もり・開発サイクルで一緒に扱えます（[タスク管理](https://pmonrails.com/docs/tasks.md)）。
- **単独バグ と 紐づくバグ** — どのストーリーにも紐づかない**単独バグ**（横断的な障害・インフラ不具合など）と、特定の**ストーリー／シナリオに紐づくバグ**の両方を起票できます。単独バグはカンバンで別枠（プロジェクト直下）に並び、紐づくバグはそのストーリー配下に表示されます。
- **重大度** — どれくらい深刻かを記録できます。
- **影響範囲を記録（親子とは別軸）** — 親に紐づくかどうかとは別に、そのバグが**どのシナリオ・要件に影響するか**を複数指定して残せます（影響分析に使えます）。
- **解決の記録** — 「修正した / 対応しない / 重複 / 再現せず」の区分と理由を残します。

## 再発防止を要件にする

「仕様として直すべき」バグは、そのバグをきっかけに**新しい要求・要件を提案・起票**できます。場当たりの修正で終わらせず、仕様に反映して再発を防ぎます。

## 変更リクエスト（仕様を安全に変える）

進行中の仕様を変えたいときは、変更リクエストを使います。バグの「修正提案」から、変更案（提案差分）を出し、承認・適用まで一続きで扱えます。

![PM on Railsの変更リクエスト。バグの「修正提案」に、提案差分と「却下」「承認」が並ぶ。導入前は変更理由がチャットに消えた。導入後はなぜ変えたかが履歴として残る。](https://pmonrails.com/docs-img/change-request.png)

- 要件やシナリオの**変更案を出し、承認後に反映**します（上の画像のように、提案差分の下に「却下」と「承認」が並びます）。
- 承認して「**実装開始 (適用)**」すると新しい版が作られ、修正提案は「実装中」になります。
- **回帰テストの結果を記録**します（修正提案の「回帰テスト記録」）。**合格には根拠が必要**です — 観測結果・テスト参照（テスト名やCIの実行URL）・証拠（スクリーンショット / 動画）のどれか。不合格・スキップには理由が要ります。最初の記録で「検証中」になります。
- 記録した回帰テストが**すべて合格**なら「マージ確定」で取り込み、**関連するバグも自動でクローズ**されます。不合格が1件でも残っていると確定できません。
- 「実装中」「検証中」「マージ済み」へは、それぞれ適用・回帰テストの記録・マージ確定の操作でだけ進みます（状態を直接書き換えて回帰検証を飛ばすことはできません）。検証中から実装中への差し戻しはできます。

## 版を切り替える（上書きしない）

仕様を変えるときは、上書きせずに**新しい版**を作り、古い版も履歴として残します（要求・要件・ストーリー・シナリオ・タスクで共通）。「いつ・何を・なぜ変えたか」が後から分かります。着手後に変わったタスクは、PRマージ時に「再確認が必要」とマークされます（[変更の追従と差分チェック](https://pmonrails.com/docs/change-tracking.md)）。

## 次のステップ

- [変更の追従と差分チェック](https://pmonrails.com/docs/change-tracking.md) / [タスク管理](https://pmonrails.com/docs/tasks.md) / [テスト](https://pmonrails.com/docs/test-results.md)

---

https://pmonrails.com/docs/bugs-changes