「観測点を増やせ」じゃなく「最小観測点セット」を定義する
QA学園とは
QA学園は、QAを教えてくれる学校で学習する、
生徒たちの物語（フィクション）です。
登場人物は、今回は僕（テラ）。
ロジカルQAの立場で「再現できる世界」を作るろうとしています。
「ログを増やせば安心だよね」
この言葉を聞くたびに、僕は少しだけ首をかしげる。
観測点は、多ければいいわけじゃない。
ロジカルQAが本当に欲しいのは、
**原因に辿り着ける“最小セット”**だ。
なぜ「増やす」は失敗するのか
観測点を闇雲に増やすと、だいたいこうなる。
- ログは大量にある
- でも、どれを見るべきか分からない
- 障害時、結局「それっぽいところ」を眺める
- 原因は「推測」で終わる
これは観測点不足ではなく、設計不足だ。
僕が考える「最小観測点セット」
考え方は単純。
状態遷移 × 判断ポイントだけを押さえる。
たとえば、パスワード再設定フロー。
① 状態が変わる瞬間
状態が変わる場所には、必ず観測点を置く。
- リクエスト受付
- トークン発行
- トークン検証
- パスワード更新完了
→ 「どこまで進んだか」が分かる
② 判断が分かれる瞬間
成功／失敗が分岐する場所には、理由が必要。
- なぜ失敗したのか
- expired
- invalid
- reused
- policy_violation
→ 「なぜ止まったか」が分かる
③ ユーザーに見えた結果
内部ログだけじゃ足りない。
- UIに出たメッセージ
- 同一文言か、分岐した文言か
→ 「ユーザー視点で何が起きたか」が分かる
これだけで何が変わるか
この最小セットがあると、QAはこう言える。
- 再現できる
- 分類できる
- 議論できる
逆に言うと、これがないと、
- テストを増やす
- ログを眺める
- 気合で原因を探す
になる。
観測点は「安心のため」じゃない
観測点は、安心材料じゃない。
意思決定の材料だ。
- どこで失敗したか
- 仕様通りか
- 想定外か
- 次に直すべきはどこか
これを判断できる最小限があればいい。
まとめ（テラ視点）
- 観測点は増やさない
- 状態と判断にだけ置く
- 「なぜ」と「どこまで」を残す
僕にとって観測点とは、
あとで責任を押し付け合わないための構造だ。
あなたの現場の観測点、
「多い」のか「足りない」のかじゃなく、
**“意味のある最小セット”になっていますか？