#“曖昧”の正体
QA学園とは
QA学園は、QAのことを教えてくれる学校で、そこで学習する子供たちの物語（フィクション）です。
アヤは“違和感”を拾う人、ユウタはそれを形にする人。
そして僕、テラは、ロジカルQAとして動きます。
ロジカルQAが一番嫌うのは、バグでも仕様変更でもない。曖昧だ。
僕は“曖昧”を見ると、まずテスト設計じゃなく観測点と責任の所在を見に行く。
「多分こう」
「ケースバイケース」
「ユーザーによる」
「想定では」
こういう言葉が出た瞬間、僕の頭の中では警報が鳴る。
曖昧は、ふわっとしているから嫌なんじゃない。再現できない世界を作るから嫌なんだ。
僕の中では、曖昧には種類がある。
曖昧① 観測できない（Observability不足）
動いたかどうかは分かる。
でも「なぜそうなったか」が分からない。
- エラーになったのに理由コードがない
- 失敗したのにログが残らない
- 失敗したのに、UIは同じ顔をしている
このタイプの曖昧は、テストを増やしても解決しない。
観測点がないから、再現しても原因に辿り着けない。
僕はこう言う。
それ、テストの問題じゃない。設計の問題だ。
曖昧② 境界がない（分類できない）
仕様の文がこういう形だと、僕は止まる。
- 「適切な場合」
- 「必要に応じて」
- 「なるべく早く」
- 「不正と思われる操作」
この文章の問題は、正しいかどうかじゃない。分類できないこと。
分類できないと、同値分割も境界値も作れない。
テスト観点図も描けない。結果、議論が感想戦になる。
だから僕は紙に書く。
- 「適切」の定義は？
- 誰の視点で？
- 入力空間はどう分ける？
曖昧③ 責任が移動する（意思決定が消える）
これが一番ヤバい。
- 「ユーザーが悪い」
- 「運用でカバー」
- 「仕様担当に確認します」
- 「とりあえずこのまま」
曖昧が残ると、判断が“どこか”へ逃げる。
最終的に、障害のときだけ現れる責任者が生まれる。
僕はこうまとめる。
曖昧は、仕様の穴じゃない。意思決定の穴だ。
じゃあ、どうするか
僕がやるのは、感情的に「明確にして」と言うことじゃない。
曖昧を、テストできる単位に落とす。
- 観測点を決める（ログ、理由コード、イベント）
- 境界を決める（値クラス、状態、時間）
- 決める人を決める（誰が最終判断するか）
ロジカルQAが欲しいのは、“正しさ”じゃなくて、再現できる世界だ。
曖昧は悪じゃない。
ただ、放置すると「誰も勝てないゲーム」になる。
- 観測できない
- 分類できない
- 意思決定が消えている
あなたの現場で一番多いのはどれですか？そして、最初に直すなら“観測点／境界／決裁者”のどれからにしますか？