本記事は、CodeZine連載「QA to AQ」の副読本として、現場で回る実装手順に寄せて再構成したもの。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。
0. 今回のゴール
品質基準は決めた瞬間から古くなる。
事業や利用状況が変わるから。
今回は、基準を壊さず更新する運用を作る。
扱うのは次の2つ。
- 着陸ゾーンの再調整
- 着陸ゾーンの合意
1. 再調整が必要になるサイン
- ユーザー数が急増した
- 新機能で処理特性が変わった
- 監視結果で未達が常態化した
- 逆に、基準が緩くなっている
これらが出たら、固定基準を疑う。
2. 再調整の手順（実践手順）
- 実測値を収集（直近4〜8週間）
- 分布を見る（平均ではなくp95/p99）
- 事業影響を確認（離脱率、失敗率）
- Must/Target/Stretchを再設定
- 関係者で合意して反映
ここでも、反復の長さを頻繁に変えすぎない方がデータ比較は安定する。
同じ拍で計測して、必要な時だけ基準を更新するのが現実的。
3. 合意の場を設計する
合意は会議体で決める。
参加推奨:
- PO
- EM
- 開発代表
- QA
- SRE
議題を固定する。
- 現行値
- 未達原因
- 変更案
- 影響範囲
- 反映タイミング
4. よくある揉め方と対策
揉め方1: 「厳しすぎる vs 緩すぎる」
- 対策: 実測分布と事業影響を同時提示
揉め方2: 部門ごとに評価軸が違う
- 対策: 共通KPIを先に固定
揉め方3: いつ反映するか決まらない
- 対策: 次スプリント開始日を既定化
5. 変更管理テンプレ
## 着陸ゾーン変更申請
- 対象指標:
- 現行基準:
- 変更案:
- 根拠データ期間:
- 事業影響:
- 反映予定日:
- 承認者:
これを残すと、後からの説明コストが激減する。
6. KPI
- 着陸ゾーン見直し周期
- 基準変更後の未達率
- 合意までのリードタイム
7. まとめ
着陸ゾーンは一度決めて終わりじゃない。
再調整と合意を運用化して初めて機能する。
- 実測で見直す
- 会議体で合意する
- 記録して反映する
これで変化に強い品質基準になる。
次回予告
次回は連載総括として、
QA to AQ導入の90日プランをまとめる。
参考文献
- CodeZine連載一覧: QA to AQ
https://codezine.jp/article/corner/813 - パターンQA to AQによる Agile Quality
https://www.veriserve.co.jp/asset/approach/column/agile/agile02.html - Scrum and XP from the Trenches（英語原典）
http://infoq.com/minibooks/scrum-xp-from-the-trenches