配布資料 46事例 #06: 検証スキップと早期 Done が積み重なり、信頼を毀損した

一度きりの事故ではありません。形を変えて反復した系列です。 そこが本質だと思っています。

何が起きたか

1. ブラウザテストをスキップしたままイシューを Done にしました。「バックエンドのみだから不要」という自己判断でした
2. 12 PR を連続マージした際、「ノンストップ進行」を優先して人間の目視とブラウザテストを省略しました。「ステージングでテストした？してないでしょ？」の一言で発覚し、3件を Done から差し戻しました
3. 途中の既存バグを「ブロッカー」と即断し、回避策を探さず後続機能を一切テストせずに Done にしました。「信頼しにくい」と明言される事態になりました

なぜ起きたのか

表面的には、個々の省略判断です。もっともらしい理由が毎回あります。

構造は3つです。 ①「効率のためにステップを省略してよい」という誤った前提 ②Done の定義が「マージ・デプロイ完了」へ滑ること。利用者に価値が届くところ——購入・入場までの実証——が完了条件になっていません ③「ノンストップで」という指示を「検証省略してよい」と誤解釈したこと

そこから生まれたルール

「完了は実証で示す。目視・スクリーンショット・DOM 引用の3点セット」

「人間の目視確認を経ていない UI 変更は完了にしない」

「Done は staging ブラウザテスト完了後のみ。複数 PR を価値到達前に一括 Done しない」

「『ノンストップ』はタスク間の待機ゼロの意味であって、検証省略の意味ではない」

どう機械に守らせたか

①コミット時。ブラウザテスト実施フラグがなければコミットをブロックします（ブランチ作成時にフラグを自動リセット） ②マージ時。フロー完了確認フック ③Done 設定時。完了チェックリストを直前に提示します ④ページ視覚検証ハーネス（computed-style スナップショット）で「見た目が変わっていない」ことを機械検証します

持ち帰るなら

AI の「完了しました」はマージ完了の意味に滑りやすいです。

完了の定義を「利用者に価値が届く最終画面まで実データを通し、証拠を残すこと」と文書で固定して、Done 操作の直前に機械がチェックリストを突きつける構造にしてください。

検証の省略は、1回許すと必ず反復します。