授業 観測点を二つ持て（UIだけで合否を言わない）
言坂先生『“たまに起きる”の正体はね、
観測点が一つしかないことが多い。
今日は、受入基準（AC）を 観測点2つで固定する』
0) 今日の題材：ログイン/セッション「UIはログイン中に見えるのに、裏で401」
現象（ありがち）：
- 画面上はログイン状態っぽい
- でもAPIは401（未認証）
- 「たまに勝手にログアウト」扱いで揉める
言坂先生『この手の事故は、UIだけ見てる限り “雰囲気” になる。
中級者は、観測点を二つ持って合否を固定する』
1) 観測点とは何か（中級の定義）
観測点（Observation Point）：合否判定に使う「証拠の出どころ」。
- 観測点A：ユーザに見えるもの（画面、遷移、トースト、ボタン状態）
- 観測点B：システムが返すもの（API応答、ステータスコード、トークン、サーバログ）
合否は「Aだけ」では決めない。AとBが一致して合格。
2) なぜ“二つ”必要か：UIは嘘をつく（というより遅れる）
UIが「ログイン中」に見えても、裏でこういうズレが起きる：
- トークン期限切れ（UIは古い状態を保持）
- リフレッシュ失敗（UI側の更新が止まる）
- 時刻ズレ（端末時計とサーバ判定が不一致）
- 複数タブ/複数端末で状態が競合
- キャッシュで画面だけ残る（戻るで見える）
言坂先生『だから、UI（見た目）とAPI（真実）をセットで観測する』
3) 観測点2つを設計する「観測マトリクス」
まず、題材に対して観測点を定義しておく。
| 事象 | 観測点A（UI） | 観測点B（API/ログ） | 合格判定 |
|---|---|---|---|
| ログイン成功 | トップ遷移／ユーザ名表示 | 認証必須APIが200／トークン発行 | AもBも成功 |
| セッション継続 | 画面操作が継続できる | 認証必須APIが200 | AとBが一致 |
| セッション失効 | 再ログイン導線表示 | 認証必須APIが401（理由＝timeout等） | AとBが一致 |
| 例外（発行失敗等） | 失敗表示＋復帰導線 | ログに失敗理由／APIは明示的エラー | 例外として仕様化 |
言坂先生『観測マトリクスを先に作ると、
“たまに”が どのズレなのか切り分けできる』
4) 受入基準（AC）は「観測点A×B」を1セットで書く
4.1) ログイン成功（基本）
AC-AUTH-01
- When 正しいID/パスワードでログインする
- Then 観測点A：トップへ遷移し、ログイン状態が表示される
- And 観測点B：認証必須APIが200で応答する（401にならない）
4.2) 無操作失効（境界×観測点）
失効時間 T=30分（例）で、境界値を仕様化しておく（中級）。
AC-AUTH-02（t=T-1秒：継続）
- Then A：操作が継続できる
- And B：認証必須APIが200
AC-AUTH-03（t=T：境界点は仕様固定）
- Then “継続/失効” を仕様でどちらかに固定
- And AとBが必ず整合する（UIだけ継続、APIだけ失効を禁止）
AC-AUTH-04（t=T+1秒：失効）
- Then A：再ログイン導線を出す
- And B：認証必須APIが401（理由が判別できる）
5) 中級技法としての位置づけ：境界値分析／状態遷移は「観測点2つ」を強くする
言坂先生『技法は単体で使わない。“観測点2つ”と組み合わせると効く』
- 境界値分析：t=T周辺でズレが出る（UI更新とAPI判定のズレが露呈する）
-
状態遷移：S0未認証→S1認証→S2失効→S3再認証要求
- “勝手にログアウト”を S1→S2 の遷移として言い換えできる
「現象」→「状態×遷移」→「A/B観測点で合否固定」
ここまでが中級の型。
6) よくある“ズレ”パターン（この授業の狙い）
観測点が1つだと、以下が全部「たまに」になる。
- UIはログイン中／APIは401（UIが古い）
- UIは未ログイン／APIは200（UIが先に落ちた）
- UIは失効表示／APIは200（失効判定がクライアント依存）
- タブAはログイン／タブBは未ログイン（状態競合）
言坂先生『“たまに”を分類できれば、修正方針が決まる。
分類のカギが 観測点2つだよ』
7) まとめ（今日の1枚）
- 受入基準（AC）は 観測点A（UI）×観測点B（API/ログ） のセットで書く
- 境界（t=T）と状態（S1→S2）を技法で言い換えると、未確定要件が確定する
- “たまに”はバグの性格じゃない。観測の不足で増える
（後ろの席）
キョウスケ「……ロールバック」
テラ「今日は“観測点2つ”が主役だ」
美桜「でも締めのロールバックは気持ちいい」
アヤ「空気、締まった」
