本記事は、CodeZine連載「QA to AQ」の副読本として、現場で回る実装手順に寄せて再構成したもの。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。
0. 今回のゴール
「品質は高い」「レスポンスは速い」みたいな表現は会話になりにくい。
今回は、品質を計測可能にして合意形成しやすくする。
扱うのはこの2つ。
- 測定可能なシステム品質
- 着陸ゾーン（最低値・目標値・優良値）
1. なぜ“着陸ゾーン”が必要か
アジャイルでは要件が更新される。
固定の単一点基準だけだと、現実に追従しにくい。
そこで、品質基準をレンジで持つ。
- 最低値（Must）
- 目標値（Target）
- 優良値（Stretch）
この形だと、変化への適応と品質統制を両立しやすい。
2. 指標の選び方（3ステップ）
Step1: ユーザー影響から逆算
- 遅いと離脱する
- 障害で取引が止まる
- 誤表示で信用を失う
Step2: 技術指標に落とす
- p95応答時間
- エラーレート
- 可用性
- 変更失敗率
Step3: 着陸ゾーンを置く
例:
- p95応答時間
- Must: <= 500ms
- Target: <= 300ms
- Stretch: <= 200ms
3. 品質シナリオの書き方（実践手順）
[品質シナリオ]
利用者が検索を実行したとき、通常負荷（同時100ユーザー）下で
p95応答時間が300ms以下であること。
[着陸ゾーン]
- Must: 500ms
- Target: 300ms
- Stretch: 200ms
ここまで書くと、仕様・実装・テスト・運用が同じ数字を見れる。
4. 合意形成の流れ
- POが事業優先度を示す
- 開発・QA・SREが測定方法を定義
- ステークホルダーで着陸ゾーンに合意
- スプリントごとに再調整
ここで効くのが、反復のタイムボックスを崩さないこと。
Scrum and XP from the Trenches でも示される通り、時間枠を守って計測と学習を繰り返す方が、基準は現実に寄っていく。
「合意したかどうか」を明文化するだけで、終盤の揉め方が減る。
5. 失敗パターン
失敗1: 指標が多すぎる
- 20指標以上で誰も追えない
- 対策: まず3〜5指標に絞る
失敗2: 計測不能な指標を置く
- ログがない、データが取れない
- 対策: 計測基盤を先に整備
失敗3: 目標が高すぎる
- 常に未達で形骸化
- 対策: Must/Target/Stretchで段階化
6. ダッシュボード最小セット
最低でも次を1画面で見えるようにする。
- p95応答時間
- エラーレート
- 主要APIの可用性
- 直近リリースの変更失敗率
色分けは着陸ゾーンに合わせる。
- 緑: Target達成
- 黄: Mustは達成
- 赤: Must未達
7. 2スプリント導入プラン
Sprint 1
- 指標3つを選定
- 着陸ゾーン仮置き
- 計測パイプラインを接続
Sprint 2
- 実測値で再調整
- 未達原因を1つ潰す
- 品質バックログへ反映
8. まとめ
品質を強くする近道は、精神論じゃなく計測設計。
今回の要点はこれ。
- 指標を絞る
- 着陸ゾーンで合意する
- スプリントごとに再調整する
これで「品質は高い」の空中戦を卒業できる。
次回予告
次は、ここまでの指標をチームで共有し続けるための
**「品質ロードマップ + システム品質ダッシュボード」**を扱う。
参考文献
- 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