受入条件を先に書くTDD実践：AI実装の手戻りを減らすチェック設計

TL;DR

• 受入条件はレビュー後付けでは遅い。
• Exampleベースで条件を書くと実装の迷いが減る。
• Red→Green→Refactorの短サイクルがAI実装に有効。

はじめに

全体像は親記事で扱っています。 👉 AI時代の仕様品質マネジメント

1. 受入条件を先に定義する理由

先に判定基準を置くことで、AIの探索空間を狭められます。

2. Exampleベース記述

• 正常系1〜2例
• 境界条件1〜2例
• エラー条件1例

3. 運用の落とし穴

受入条件が多すぎると実装停止を招くため、最小十分に絞ることが重要です。

意思決定ログの残し方は兄弟記事へ。 👉 意思決定ログと証拠管理の型

まとめ

受入条件先行は、AI時代の品質担保の最短ループです。 全体像に戻る: 親記事はこちら