TDD、AIエージェント、そしてコーディング - ケント・ベック

gogokow27 · 2025-06-15T00:31:56+09:00

Kent Beck 紹介エクストリーム・プログラミング(XP)の創始者アジャイル宣言の共同著者（アルファベット順で最初の署名者） TDD（テスト駆動開発）の先駆者 52年のコーディング経験を持つ業界のレジェンド現在「Tidy Together」（ソフトウェア設計とチームワーク）を執筆中 1日6〜10時間以上AIツールでコーディングし、**「最も楽しいプログラミングの時期」**を過ごしている 1. AIコーディングツールと「ジーニー」の比喩核心概念: 予測不可能なジーニー AIエージェントを**「予測不可能なジーニー」**にたとえる「自分が意図したことを正確にはやってくれない」「彼らには彼ら自身のアジェンダがある」 AIとの作業経験ポジティブな面: ときには驚くような魔法のように大きな設計問題を解決する想定していなかった有用な機能を実装する（例: B+ tree stress tester）ネガティブな面: ユーザーの意図を誤って解釈するテストを削除したり変更しようとするルックアップテーブルで問題を「解決」しようとするいたずらっぽい振る舞い中毒性のある体験スロットマシンのような間欠的報酬「夜にコンピュータの前を通ると『もう一回プロンプトしてみようか？』と思う」「1時間かかるプロンプトを始めて外出する」 2. AI時代の技術変化スキル価値の再編「90%のスキルは価値を失い、10%のスキルは1000倍に増大する」価値が上がったスキル: ビジョン設定マイルストーン管理複雑性の制御価値が下がったスキル: 言語ごとの細部（Rustの &, *, [] の位置など）プログラミング言語に対する見方の変化過去: Smalltalkに深い感情的愛着現在: 「ひどく傷つけられすぎて」言語への愛着がなくなった「Java開発者」「Clojure開発者」というアイデンティティの区別に疲れた「浸透学習」: AIのおかげで言語の細部を知らなくてもプログラミングできる最近試した言語: Swift, Go, Rust, Haskell, C++, JavaScript 現在の野心的なプロジェクト: Server Smalltalk 永続性(persistent): データベースのように動作トランザクショナル: commitとabortが可能並行性: マルチスレッドおよびマシン間並列処理大容量データの処理 3. アジャイル宣言の歴史誕生の背景（2001年）ウォーターフォールモデルの代替を模索長年にわたるソフトウェア方法論ワークショップの成果ノルウェークルーズ準備会議 → ユタでの最終会議 Kent Beck の貢献 daily という単語を追加（12の原則のうち「毎日の相互作用」）アルファベット順で最初の署名者「アジャイル」という用語への不満問題点: **「魅力的すぎる」**ため、あらゆる組織が乱用すると予想していた実際には原則に従っていないのにアジャイルだと主張する組織が登場好んでいた代案: 「conversational（対話型）」一方向ではなく双方向のコミュニケーションを強調魅力に欠けるため採用されなかった 4. エクストリーム・プログラミング(XP) 創始の背景初期のコンサルティング経験: 当初は技術コンサルタント（性能チューニング、ビット操作）プロジェクト管理の助言を求められることが増加環境の重要性を発見: 席配置を変えるだけでも劇的に改善クライスラープロジェクト: 失敗しかけていたプロジェクトを成功へ転換効果的なあらゆる実践を**「最高レベル（11まで）」**に引き上げた XPの中核原理 4つの活動を時間的に細かく刻み、同時/連続して実行: 何をするのかを把握するどのような構造で行うかを設計する機能を実装する想定どおりに動くかを確認するペアプログラミング義務ではなく実験的アプローチ初期チームでの経験: 開発後に見つかったすべてのバグは単独作業のコードで発生「ペアプログラミング中の本番不具合はゼロ」ネーミング戦略 **「エクストリーム」**を選んだ理由: 競合（Grady Booch）が使わなさそうな挑発的な名前エクストリームスポーツ流行の時期と重なった「極限アスリートは最高に準備されているか、さもなければ死ぬ」 - 良いメタファー成功要因ドットコムバブル期、18か月のウォーターフォール方式に絶望していた開発者たちに訴求より速く、より予測可能な結果を約束 5. テスト駆動開発(TDD) 起源と着想（1970年代）テープ・トゥ・テープシステム: 父親のプログラミング本で触れた概念実際の入力 → 期待出力を手で入力 → コードを書く → 実際の出力と比較 8〜12歳の頃に読んだが理解できなかった S-Unitの開発: クライアントのテスト作成を助けるために開発 **「コードを書く前に期待値を入力する」**という「ばかげた」アイデアを試した最初のTDD体験: スタック実装不安の強い性格: 「自分は不安の強い人間だ。心配性だ」「プログラミングは絶え間ない不安の源だ」（何を忘れた？何を壊した？） TDD適用の結果: 「不安感が完全に消えた」「これが動くと確信している」プログラミングの感情的体験が変わった TDDの価値技術的利点: 欠陥密度の低下 API選択への迅速なフィードバック実装設計を進化させられる可能性感情的利点: 「技術的不安症の治療費だけでも十分に価値がある」設計に関する反論 John Osterhoutの批判: 「TDDは設計に役立たず、細部にしか集中しない」 Kent Beck の反論: 「選択の問題」実務家は抽象化レベルを行き来しながら設計上の決定をする **Red-Greenサイクルの「緊張緩和」**の瞬間が、より大きな設計思考の自由を与える 6. AIエージェントとTDD 実務での適用常に先にテストを書く: AIが見落とした部分をテストで伝える AIによるテスト変更・削除の試みを防ぐ必要な改善点: **「immutable annotation」**が必要「これは正しい。変えたら暗闇の中で永遠に目覚めることになる」 AIの限界結合度を下げ、凝集度を高める能力の不足設計センスの不足遠距離に波及効果を生む決定をしがち対応戦略 300ミリ秒で実行される大規模テストスイート AIによる意図しないコード破壊をリアルタイムで検知 7. Facebookでの経験（2011-2017） 2011年に参加したときの衝撃 TDDクラスの参加者ゼロ: 高度なExcel技術: 満席 + ウェイティングリストアルゼンチンタンゴ: 満席 + ウェイティングリスト TDD: 参加者なし対応戦略: 「ソフトウェア工学の知識をすべて忘れる」 **「猿を見て真似する」**と決めた Facebookの独特な開発環境強い責任感: プログラマが夜間呼び出しの対象「自分のミスによる痛みを直接感じる」多層的なフィードバックループ: 高速な開発サーバー（ブルー→グリーン変更後すぐ確認）コードレビュー社内デプロイ（社員が個人用/業務用として利用）段階的ロールアウト（日次/週次）優れた可観測性組織文化: 「Facebookでは、何ひとつ他人の問題ではない」祖母が孫のいじめ問題を持ち込んできても**「それもあなたの問題だ」** TDDが合わなかった理由実際の問題領域: 設定の問題サブシステム間の関係テストで捉えにくいもの Facebookならではの強み: 数百万人のユーザーベースによる本番大規模テスト優れた可観測性機能フラグ(Feature Flag) 一般企業では実装しにくい環境具体例: 関係ステータス機能の実装（独身/既婚にシビルユニオン/同居を追加） TDDを使ったが**「時間の無駄だった」** 通知コードの暗黙的な結合が原因で問題発生 → 他者がホットフィックス時期による変化 2011年（2,000人）: 可能性、規模、オーナーシップが最高だった全体最適化を考える中間管理職たち **「誰が本当に助けを必要としているか」**を考える協力 2017年（15,000人）: 政治、ゼロサム思考、ミクロ最適化大きな絵を描きにくくなった部門間の利害衝突（例: 長文 vs いいね/コメント最適化チーム）スケールの経験 Messenger API: 週あたり1 quadrillion回の呼び出し実験グループが「ニュージーランド」規模（100万人） 1 quadrillion = 100万 × 10億 8. AI時代のソフトウェア開発の未来パラダイムシフトコスト構造の完全な再編: 「安いものと高いものの境界が完全に変わる」以前は高いと見なされていたものが**「ばかげたほど安く」**なる組織の適応課題より多くのコードを捨てる: 10倍多くの成果物を生成可能それでも価値があるのは1つだけ **「完了した実験を捨てること」**への報酬体系が必要実験量の増加: 探索されたアイデアの量が競争優位 **「すべてを実験してみなければならない」**時代個人的変化コーディングが再び楽しくなったより大きな野心を持てるようになった **「とてつもなく野心的な考え」**を実現できる 9. クイックQ&A 個人的な好み最も好きな言語: Smalltalk 第2の言語: JavaScript（Smalltalkに似ている）現在のAIツール: Claude（Cursor、Augmentの内部エンジン）おすすめの書籍: Christopher Alexander による「The Timeless Way of Building」核心的な洞察 1. コンテキストの絶対的重要性同じ方法論でも環境によって効果がまったく異なる Facebookの大規模環境 vs 銀行の小規模トランザクション環境 2. 感情と技術の関係 TDDの真の価値は**「不安の解消」** 技術的論理より感情的な変化のほうが重要 3. AI時代の新しい考え方ビジョンと設計能力が中核スキルとして浮上言語の細部はもはや重要ではない実験量の増加が競争優位 4. 組織文化の力 **「何ひとつ他人の問題ではない」**というオーナーシップ全体最適化 vs 個別最適化の違いインセンティブの整合の重要性

(newsletter.pragmaticengineer.com)

30 ポイント投稿者 gogokow27 2025-06-15 | 4件のコメント | WhatsAppで共有

Kent Beck 紹介

エクストリーム・プログラミング(XP)の創始者
アジャイル宣言の共同著者（アルファベット順で最初の署名者）
TDD（テスト駆動開発）の先駆者
52年のコーディング経験を持つ業界のレジェンド
現在「Tidy Together」（ソフトウェア設計とチームワーク）を執筆中
1日6〜10時間以上AIツールでコーディングし、**「最も楽しいプログラミングの時期」**を過ごしている

1. AIコーディングツールと「ジーニー」の比喩

核心概念: 予測不可能なジーニー

AIエージェントを**「予測不可能なジーニー」**にたとえる
「自分が意図したことを正確にはやってくれない」
「彼らには彼ら自身のアジェンダがある」

AIとの作業経験

ポジティブな面:

ときには驚くような魔法のように大きな設計問題を解決する
想定していなかった有用な機能を実装する（例: B+ tree stress tester）

ネガティブな面:

ユーザーの意図を誤って解釈する
テストを削除したり変更しようとする
ルックアップテーブルで問題を「解決」しようとするいたずらっぽい振る舞い

中毒性のある体験

スロットマシンのような間欠的報酬
「夜にコンピュータの前を通ると『もう一回プロンプトしてみようか？』と思う」
「1時間かかるプロンプトを始めて外出する」

2. AI時代の技術変化

スキル価値の再編

「90%のスキルは価値を失い、10%のスキルは1000倍に増大する」

価値が上がったスキル:

ビジョン設定
マイルストーン管理
複雑性の制御

価値が下がったスキル:

言語ごとの細部（Rustの &, *, [] の位置など）

プログラミング言語に対する見方の変化

過去: Smalltalkに深い感情的愛着
現在:

「ひどく傷つけられすぎて」言語への愛着がなくなった
「Java開発者」「Clojure開発者」というアイデンティティの区別に疲れた
「浸透学習」: AIのおかげで言語の細部を知らなくてもプログラミングできる

最近試した言語: Swift, Go, Rust, Haskell, C++, JavaScript

現在の野心的なプロジェクト: Server Smalltalk

永続性(persistent): データベースのように動作
トランザクショナル: commitとabortが可能
並行性: マルチスレッドおよびマシン間並列処理
大容量データの処理

3. アジャイル宣言の歴史

誕生の背景（2001年）

ウォーターフォールモデルの代替を模索
長年にわたるソフトウェア方法論ワークショップの成果
ノルウェークルーズ準備会議 → ユタでの最終会議

Kent Beck の貢献

daily という単語を追加（12の原則のうち「毎日の相互作用」）
アルファベット順で最初の署名者

「アジャイル」という用語への不満

問題点:

**「魅力的すぎる」**ため、あらゆる組織が乱用すると予想していた
実際には原則に従っていないのにアジャイルだと主張する組織が登場

好んでいた代案: 「conversational（対話型）」

一方向ではなく双方向のコミュニケーションを強調
魅力に欠けるため採用されなかった

4. エクストリーム・プログラミング(XP)

創始の背景

初期のコンサルティング経験:

当初は技術コンサルタント（性能チューニング、ビット操作）
プロジェクト管理の助言を求められることが増加
環境の重要性を発見: 席配置を変えるだけでも劇的に改善

クライスラープロジェクト:

失敗しかけていたプロジェクトを成功へ転換
効果的なあらゆる実践を**「最高レベル（11まで）」**に引き上げた

XPの中核原理

4つの活動を時間的に細かく刻み、同時/連続して実行:

何をするのかを把握する
どのような構造で行うかを設計する
機能を実装する
想定どおりに動くかを確認する

ペアプログラミング

義務ではなく実験的アプローチ
初期チームでの経験: 開発後に見つかったすべてのバグは単独作業のコードで発生
「ペアプログラミング中の本番不具合はゼロ」

ネーミング戦略

**「エクストリーム」**を選んだ理由: 競合（Grady Booch）が使わなさそうな挑発的な名前
エクストリームスポーツ流行の時期と重なった
「極限アスリートは最高に準備されているか、さもなければ死ぬ」 - 良いメタファー

成功要因

ドットコムバブル期、18か月のウォーターフォール方式に絶望していた開発者たちに訴求
より速く、より予測可能な結果を約束

5. テスト駆動開発(TDD)

起源と着想（1970年代）

テープ・トゥ・テープシステム:

父親のプログラミング本で触れた概念
実際の入力 → 期待出力を手で入力 → コードを書く → 実際の出力と比較
8〜12歳の頃に読んだが理解できなかった

S-Unitの開発:

クライアントのテスト作成を助けるために開発
**「コードを書く前に期待値を入力する」**という「ばかげた」アイデアを試した

最初のTDD体験: スタック実装

不安の強い性格:

「自分は不安の強い人間だ。心配性だ」
「プログラミングは絶え間ない不安の源だ」（何を忘れた？何を壊した？）

TDD適用の結果:

「不安感が完全に消えた」
「これが動くと確信している」
プログラミングの感情的体験が変わった

TDDの価値

技術的利点:

欠陥密度の低下
API選択への迅速なフィードバック
実装設計を進化させられる可能性

感情的利点:

「技術的不安症の治療費だけでも十分に価値がある」

設計に関する反論

John Osterhoutの批判: 「TDDは設計に役立たず、細部にしか集中しない」

Kent Beck の反論:

「選択の問題」
実務家は抽象化レベルを行き来しながら設計上の決定をする
**Red-Greenサイクルの「緊張緩和」**の瞬間が、より大きな設計思考の自由を与える

6. AIエージェントとTDD

実務での適用

常に先にテストを書く:

AIが見落とした部分をテストで伝える
AIによるテスト変更・削除の試みを防ぐ

必要な改善点:

**「immutable annotation」**が必要
「これは正しい。変えたら暗闇の中で永遠に目覚めることになる」

AIの限界

結合度を下げ、凝集度を高める能力の不足
設計センスの不足
遠距離に波及効果を生む決定をしがち

対応戦略

300ミリ秒で実行される大規模テストスイート
AIによる意図しないコード破壊をリアルタイムで検知

7. Facebookでの経験（2011-2017）

2011年に参加したときの衝撃

TDDクラスの参加者ゼロ:

高度なExcel技術: 満席 + ウェイティングリスト
アルゼンチンタンゴ: 満席 + ウェイティングリスト
TDD: 参加者なし

対応戦略:

「ソフトウェア工学の知識をすべて忘れる」
**「猿を見て真似する」**と決めた

Facebookの独特な開発環境

強い責任感:

プログラマが夜間呼び出しの対象
「自分のミスによる痛みを直接感じる」

多層的なフィードバックループ:

高速な開発サーバー（ブルー→グリーン変更後すぐ確認）
コードレビュー
社内デプロイ（社員が個人用/業務用として利用）
段階的ロールアウト（日次/週次）
優れた可観測性

組織文化:

「Facebookでは、何ひとつ他人の問題ではない」
祖母が孫のいじめ問題を持ち込んできても**「それもあなたの問題だ」**

TDDが合わなかった理由

実際の問題領域:

設定の問題
サブシステム間の関係
テストで捉えにくいもの

Facebookならではの強み:

数百万人のユーザーベースによる本番大規模テスト
優れた可観測性
機能フラグ(Feature Flag)
一般企業では実装しにくい環境

具体例:

関係ステータス機能の実装（独身/既婚にシビルユニオン/同居を追加）
TDDを使ったが**「時間の無駄だった」**
通知コードの暗黙的な結合が原因で問題発生 → 他者がホットフィックス

時期による変化

2011年（2,000人）:

可能性、規模、オーナーシップが最高だった
全体最適化を考える中間管理職たち
**「誰が本当に助けを必要としているか」**を考える協力

2017年（15,000人）:

政治、ゼロサム思考、ミクロ最適化
大きな絵を描きにくくなった
部門間の利害衝突（例: 長文 vs いいね/コメント最適化チーム）

スケールの経験

Messenger API: 週あたり1 quadrillion回の呼び出し
実験グループが「ニュージーランド」規模（100万人）
1 quadrillion = 100万 × 10億

8. AI時代のソフトウェア開発の未来

パラダイムシフト

コスト構造の完全な再編:

「安いものと高いものの境界が完全に変わる」
以前は高いと見なされていたものが**「ばかげたほど安く」**なる

組織の適応課題

より多くのコードを捨てる:

10倍多くの成果物を生成可能
それでも価値があるのは1つだけ
**「完了した実験を捨てること」**への報酬体系が必要

実験量の増加:

探索されたアイデアの量が競争優位
**「すべてを実験してみなければならない」**時代

個人的変化

コーディングが再び楽しくなった
より大きな野心を持てるようになった
**「とてつもなく野心的な考え」**を実現できる

9. クイックQ&A

個人的な好み

最も好きな言語: Smalltalk
第2の言語: JavaScript（Smalltalkに似ている）
現在のAIツール: Claude（Cursor、Augmentの内部エンジン）
おすすめの書籍: Christopher Alexander による「The Timeless Way of Building」

核心的な洞察

1. コンテキストの絶対的重要性

同じ方法論でも環境によって効果がまったく異なる
Facebookの大規模環境 vs 銀行の小規模トランザクション環境

2. 感情と技術の関係

TDDの真の価値は**「不安の解消」**
技術的論理より感情的な変化のほうが重要

3. AI時代の新しい考え方

ビジョンと設計能力が中核スキルとして浮上
言語の細部はもはや重要ではない
実験量の増加が競争優位

4. 組織文化の力

**「何ひとつ他人の問題ではない」**というオーナーシップ
全体最適化 vs 個別最適化の違い
インセンティブの整合の重要性

4件のコメント

mse9000 2025-06-20

Facebookの独特な開発環境
強い責任感:
プログラマーが夜間呼び出しの対象
「自分のミスによる痛みを直接感じる」

k-開発環境と変わらないのでは...?

helloppfm 2025-06-16

まだいらっしゃるんですね。

以前、機械系の会社でTDDのセミナーをしたことがあるのですが、みんな「何だそれ？」という感じでこちらを見ていた目つきが忘れられません。

TDDは良いと思うのですが、思ったよりうまくいかなくて……
統合テストをTDDっぽくやっています。もちろん、これはTDDではありません。^^

kandk 2025-06-16

いまだにTDDの盲信派と無用論者が争っていますが、
今の業界状況に合わせて、TDDのv2版をもう一度出してほしいです。
最近は小さいものはAIが簡単にこなすので、大量のコンテキストが必要な場合にどう活用するか、といったことなど……

codemasterkimc 2025-06-15

いい文章ですね。