本記事は、CodeZine連載「QA to AQ」の副読本として、現場で回る実装手順に寄せて再構成したもの。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。

0. 今回のゴール

品質課題は見つかる。
でも、スプリントが進むと優先度で負けて消える。
今回はそれを防ぐために、次の2つを実装する。

狙いは、品質改善を「単発施策」から「継続施策」に変えること。

1. 品質ロードマップが必要な理由

よくある失敗はこれ。

ロードマップがあると、

やるかが可視化される。
つまり、意思決定の再現性が上がる。

四半期単位で十分。最初はこれだけで回る。

ロードマップは「計画」。
ダッシュボードは「現状」。

この2つを接続すると、

が毎週決められる。

加えて、チームが自分たちの速度を説明できる状態を維持すると、
ロードマップの実現可能性が一気に上がる。バーンダウンと速度の可視化は、計画を守るための基礎体力。

色分けルールを固定する。

## 品質ロードマップ（Qx）
- テーマ:
- 目標:
- 月次マイルストーン:
  - M1:
  - M2:
  - M3:
- 主要品質タスク:
  - [Quality] ...
  - [Quality] ...

品質ロードマップは「忘れない仕組み」。
ダッシュボードは「遅れに気づく仕組み」。

この2つを回すだけで、品質改善は継続しやすくなる。

次回は、異常をもっと早く気づくための
**「システム品質アンドン」**を扱う。