本記事は、CodeZine連載「QA to AQ」の副読本として、現場で回る実装手順に寄せて再構成したもの。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。
0. 今回のゴール
ダッシュボードがあっても、誰も見なければ意味がない。
今回は、異常に即時気づくためのシステム品質アンドンを実装する。
アンドンの狙いはシンプル。
- 状態を直感的に共有
- 異常時の初動を標準化
1. アンドンとは何か
工場のアンドンと同じで、
- 緑: 正常
- 黄: 注意
- 赤: 異常
を全員が一目で分かる形で表示する仕組み。
ソフトウェアでは、メトリクスとアラートをこの3色に落とす。
2. 何をアンドン化するか
最初は3つで十分。
- 可用性
- エラーレート
- 主要ユースケースの応答時間
これ以上増やすと、現場が色疲れする。
3. 色判定ルール（例）
- 可用性
- 緑: >= 99.95%
- 黄: 99.90%〜99.95%
- 赤: < 99.90%
- エラーレート
- 緑: < 0.5%
- 黄: 0.5%〜1.0%
- 赤: > 1.0%
ルールは事前合意して固定する。
4. 赤になった時の初動手順
アンドンで一番大事なのは表示じゃなく手順。
- 5分以内に担当アサイン
- 15分以内に一次切り分け
- 30分以内に暫定対応方針
- 24時間以内に再発防止タスク化
この時に重要なのは、初動の標準化と同時に、スプリント中の無秩序な割り込みを抑えること。
外乱を放置すると、アンドンが鳴っても改善が積み上がらない。
この流れをRunbookに書いておく。
5. 失敗パターン
失敗1: 常に黄色
- 閾値が厳しすぎる
- 対策: 現実値に合わせて再調整
失敗2: 通知疲れ
- アラート過多
- 対策: 重大指標に絞る
失敗3: 赤でも放置
- 初動責任が曖昧
- 対策: 当番制と責任者を固定
6. 2週間導入プラン
Week 1
- 指標3つを選定
- 色閾値を合意
- 通知チャネルを統一
Week 2
- 赤発生時の訓練（ゲームデイ）
- 初動手順を改善
- 品質バックログへ改善項目追加
7. KPI
- 赤状態の平均継続時間
- MTTA（初動開始までの時間）
- 同種アラート再発率
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