Buzzwordによる設計 の TDD編です。(NotebookLMを利用しました)
2003年、Kent Beckは『テスト駆動開発』を出版しました。彼が向き合っていた問いは、単に「テストを自動化する」ことではなく、「プログラミングという不確実な作業において、いかにして一歩ずつ着実に理解を深め、自信を持って設計を導き出すか」というワークフローの構築でした。
Beckが提示した核心は、分析と設計、そして実装を時間軸で切り離し、それらを小さな歩幅で繰り返すことにありました。
- 分析のステップ（テストリスト）: いきなりコードを書くのではなく、まず解決すべき問題を「期待される振る舞い」としてリストアップします。これはプログラミング対象の純粋な「分析」のフェーズです。
- インターフェースの設計（テストを1つ書く）: リストから一つ選び、それを具体的なコードに翻訳します。このとき、「この機能はどう呼び出されるのが理想か」というインターフェースの設計判断が行われます。
- 実装（テストを成功させる）: 設計の良し悪しは一旦脇に置き、まずはその振る舞いを実現することだけに集中します。
- 実装の設計（リファクタリング）: 動作が保証された状態で、初めて内部構造を整え、設計を洗練させます。
このサイクルを回すことで、開発者は一度に一つのことに集中でき、問題を解きながら設計を創発させていく（インクリメンタルな設計）ことが可能になります。TDDは、設計のやりすぎ（オーバーエンジニアリング）も、やらなさすぎも防ぐための高度な知的なリズムだったのです。
しかし、「TDD」がバズワードとして普及する過程で、この「ステップバイステップの探求プロセス」という側面が抜け落ちてしまいました。 多くの現場では「実装の前にテストコードを書く（テストファースト）」という手法的な側面ばかりが強調され、最初の「分析（テストリスト）」や最後の「設計の改善（リファクタリング）」が軽視されました。
結果として、「設計が固まっていないのにテストは書けない」「テストを書くのがただの苦行になり、設計の質も上がらない」という不満が蓄積しました。これは、分析と設計のステップを飛ばして「テストという名の重荷」だけを背負い込んだ結果生じた悲劇でした。
Beckは、自分の意図したワークフローが「コードを書く前にすべてのテストを書く」といった誤った形で批評されている現状を嘆き、こう述べています。
「もしもあなたがTDDを批評しようとしていて、かつ、私のワークフローを批評対象としていないのであれば、あなたは藁人形論法を使っていることになる」。 https://t-wada.hatenablog.jp/entry/canon-tdd-by-kent-beck
これもまた、「問題をどう解くか」という動的なプロセスが、単なる「先にテストを書く」という静的なルールに摩り替わってしまった、バズワード化の典型的なパターンです。