2025 年 7 月初旬に収録され、同年 8 月に公開されたこの対談は、日本で 20 年ほどテスト駆動開発の普及に努め、Kent Beck によるその書籍を翻訳した和田卓人と、アジャイルコーチの安井力の組み合わせである。すでにエージェントを大規模に運用している人々ではなく、まだコーディングエージェントを導入しておらず、テストカバレッジがほとんど、あるいはまったくないコードベースで作業しているチームに向けて、意図的に語られている。
最初の論点は、生成 AI が自動テストにまつわる長年の 2 つの障壁を同時に下げたということである。1 つは学習コストで、別のプログラムを検証するプログラムを書くことは独自のスキルであり、多くの開発者はそれを身につけないままでいる。もう 1 つは実装コストである。モデルが生み出すものは必ずしも高品質ではないが、最初の一歩を踏み出してフィードバックサイクルを回し始めるには十分である。2 人は、既存のコードがどう振る舞うべきかではなく、いまどう振る舞っているかを捉えるテストである仕様化テストを、AI が最も力を発揮する領域として挙げる。現在の振る舞いを捉えることは事後的な依頼であり、狭いコンテキストを与えることができるからである。
タイトルにもなっている 2 つ目の論点は、TDD がエージェントが書くコードに対するガードレールになったということである。和田の説明では、エージェントは解決策を探す過程で動いていたコードを壊してしまうものであり、動いていたものを動くまま保つようエージェントに伝えるには、自動テストスイートこそが適切な道具である。しかし、テストが通るだけでは保守しやすいコードにはならない。「テスト駆動開発」という言葉が有用なのはまさに、動くことと保守しやすいことという両方の側面を、モデルがすでに知っている 1 つのワークフローの中に含んでいるからである。
要点
- 和田は転換点を 2024 年末から 2025 年初頭とし、日本での Claude Code の登場、とりわけ 5 月からの定額制での利用が決定的だったと述べる。一方で、企業での導入はまだ遅いと見ており、その主な理由として、エンタープライズ向けプランが少なく、企業が代わりに個人向けプランを配っていたことを挙げる。
- 彼は、チームがコーディングエージェントを受け入れる準備ができていないことが多いと主張する。モデルから良い生成結果を得るには、開発ドキュメント、リポジトリ、CI/CD がすでにそれなりに整っていることが前提となるからである。
- 生成 AI は自動テストの学習コストと実装コストの両方を下げた。和田の主張は、それによって自動テストを書く人の数が明らかに増えたというものである。
- 安井は、AI が書いたテストには現実の欠陥があると指摘する。至るところにモックがあって何をテストしているのかがわからない、フィクスチャやセットアップが長すぎる、といったものである。それでも、人間が最初の一歩を踏み出すには十分だという。
- 安井は逆方向の受け止め方にも警鐘を鳴らす。AI がコードを書けるのだからテストは不要だ、と考えてしまうことである。AI が生成したコードがどこでずれてしまったかを見抜くには人間側のスキルが必要であり、それがなければ問題は気づかれないまま進む。
- 和田は、TDD が必要とし、人間のスキルかソフトウェア考古学を要する「To-Be」のテスト（システムがどう振る舞うべきか）と、「As-Is」の仕様化テストとを区別し、後者については AI が極めて効果的だと述べる。
- 安井は、仕様化テストこそが運用保守フェーズで求められるものだと付け加える。このフェーズのチームはより小さく、テストコードを書くことにもあまり習熟していない。
- テスト設計について安井は、単にモデルにテストを書くよう頼んでも論理的に考えてはくれないが、境界値分析、デシジョンテーブル、同値クラスといった技法の名前を挙げると、それなりの結果が得られると報告する。人間が論理的に考えるために使う道具を AI に与えれば、AI も論理的に考えるようになるということである。
- 和田は、テストに裏打ちされた丁寧な開発が、作っては壊す開発を追い越す時点を、AI 以前はおよそ 1 か月、2025 年 7 月時点ではおよそ数日と見積もる。これは明示的に、カンファレンスの聴衆に尋ねて得た印象であり、計測されたデータではない。
- 彼は、Claude Code に「TDD で進めて」と伝えると「まずテストをたくさん書く」だけになりがちだったと報告する。そして、より厳格な TDD と結びついた人物の名前を使うと、テストを 1 つ書いて失敗させ、それから通すという古典的なサイクルが伝わるという報告もあるという。
- 和田はこれをデザインパターンやパターンランゲージと結びつける。問題に名前を与え、短い言葉で解決策全体を伝えられるようにすることこそ、1990 年代のあの取り組みが目指したものであり、人間同士では決してうまくいききらなかったことが、モデルとの間では機能していると彼は見ている。
- 安井は、TDD によってコードと、それに対する人間の理解とのギャップ、すなわち Ward Cunningham が本来意味した技術的負債を抑えられると主張する。AI が書くコードはこのギャップを急速に広げる。
- 和田は、自律的に動くエージェントに任せることは、TDD で進めるよう指示する理由を減らすどころか、むしろ増やすと主張する。放置されたエージェントは、動くかもしれないが保守できない大量のコードを生み出すからである。
- スクラムについて安井の立場は、ロールは誰がどのタスクを行うかではなく、誰がどの責任を持つかを定義するものであり、したがってその構造は AI 時代にも残るが、各ロールの働き方は変わる、というものである。彼は、非常に小さく生産性の高いチームへの移行を予想している。
- 2 人とも、ソフトウェアエンジニアリングのボトルネックはコードを書くことではなかったと主張する。ドキュメントがソースコードから乖離すること、何を変更すべきかを見つけること、テストを書かなければならないことこそがボトルネックであり、コーディングエージェントが本当の効果を発揮するのはそこだという。
- エンジニアが不要になるかという問いに対して、2025 年 7 月時点の和田の率直な答えは「わからない」であり、両方の未来に備えていると述べる。残る難しさはシステムを作ることではなく維持し続けることにあり、やりたいことを要件に落とし込むことこそ、エンジニアでない人に主に欠けているスキルだと彼は主張する。
- 和田は、差をつけるものは経験年数ではなく、ネガティブ・ケイパビリティ、すなわち不確実さへの耐性、好奇心、柔軟性だと位置づけ、自由に使える時間が多い分、ジュニアエンジニアのほうが有利かもしれないと示唆する。
背景
この記事は研究ではなく対話であり、2 人とも自分の主張を繰り返し印象として位置づけている。「数日」という数字は明示的に聴衆への問いかけから得た感触であり、人物名がプロンプトとして機能するという観察も、計測したものではなく他者からの報告として伝えられている。和田はまた、ベンダーのエンジニアリングガイダンスが TDD はエージェントによって強化されると述べるとき、そこで説明されている実践が自分の意味する厳密な意味での TDD なのかどうかは確信が持てないとも述べている。
2 人ともこのテーマに利害関係を持っており、対談はそれを明らかにしている。和田は Kent Beck の『テスト駆動開発』を日本語に翻訳し、20 年にわたってこの実践を提唱してきた人物であり、自分の知識はいまやモデルの中に入っていて、コンサルタントとしてはモデルと競合する立場にあると率直に語っている。安井は、ワークショップ用のゲームを設計・販売しているアジャイルコーチである。エージェントの時代に TDD がより重要になったという構図は、和田自身の説明によれば、彼が予測しておらず、主張してもいなかった展開である。
この対談は、同じ論点を扱う日本語の実践者による他の記事と並ぶものである。AI に t-wada の TDD を頑張らせる は、和田の定式化した TDD に従うよう指示したエージェントとともにツールを作った経験を報告しており、どの部分が人間の手に残るかについて、これと整合する結論に至っている。