- XPとTDDの父、ケント・ベックのProgramnatic Engineerインタビューで特に印象に残ったいくつかの部分を要約
- ケント・ベックが好きな方にはフルバージョンの視聴をおすすめ
Q. XPの核心は何か？
次の4つの活動を行うこと。
- 何をすべきかを把握する
- 1を自分たちが実行できるようにする構造を把握する
- 2を使って1を実装する
- 3が期待どおりに動作するかを確認する
これがすべてだ。そして時間を非常に細かく区切り、毎時間この4つの活動を少しずつ、しかしすべて行う。
Q. では、ペアプログラミングはXPで必須ではないのか？
最初にXPチームを運営していた頃、3週間に一度リリースしていたが、当然バグはあった。
「リリース後に発見された」バグのパターンを分析してみると、そのすべてが1人で開発したコードで発生していた。逆に言えば、ペアで開発したコードでは本番環境で報告された欠陥は存在しなかった。
Q. では必須ではなく、強く推奨する程度？
それも違う。実験しろ、ということだ。もともとやっていたやり方で開発してもいい。ただし、意識的な状態で。
継続的設計、継続的検証、継続的実装、あるいは顧客との継続的なインタラクション、何であれそこから利益を得たい。なのに、いつもどおりにやっていてうまくいかないのなら、やり方を変えるべきだ。
誰かが私のところに来て「ケント、私はTDDをやっていません」と言ったら、私はこう答える。「それで？」
今の自分のコードにおける欠陥密度や、設計上の意思決定に対するフィードバックの水準に満足しているなら問題ない。しかし満足していないなら、ペアでもTDDでも試してみろ、ということだ。
Q. その話が出たついでに、なぜTDDを作ったのか？
私は心配性で不安になりやすい人間で、私にとってプログラミングは絶え間ない不安の源だった。何を忘れた？ 何を壊した？
だがTDDで開発すると、この不安が消える。失敗しそうなテストケースがもう思い浮かばない？ なら自分のプログラムが動くと確信できる。少しでも不安が生まれる？ なら次のテストケースを書けばいい。
もちろん、欠陥密度の低減、設計上の意思決定に対するフィードバックを早く得ること、実装設計を進化させることなど、TDDには技術的な利点も多い。しかし、プログラミングに対する不安から解放されたこと、プログラミングがもたらす感情的な体験が完全に変わったこと。私にとって最も重要なのはこれだ。これが私がTDDを作った理由だ。
Q. TDDをやると良い設計が入り込む余地がないというJohn Ousterhoutの批判についてはどう思うか？
（訳注：John Ousterhoutは名著Philisophy of Software Designの著者であり、数か月前にProgrammatic Engineerポッドキャストに出演し、TDDに対して批判的な見方も示していました）
彼には誤解している面がある。それは単に意思決定の結果だ。もしTDDをただRed-Greenの反復としてしか扱わないなら、当然そこに設計が入り込む余地はない。
TDDの実践者として、私は常に抽象化のレベルを行き来しながら作業している。たとえば：
- 今はRed状態だ。次のテストケースを成功させる（Greenにする）にはどう実装すべきか？
- 何だか難しい。なぜ難しいのか？
- Greenにするための実装をもっと簡単にするには、設計をどう変えるべきか？
- そのアイデアはいつ導入すべきか？ 今か、後か？
- 今導入するなら、どの程度までか？ 今すぐできる範囲で少しだけやるのか、もっと大きなチャンクでやるのか？
つまりテストを書く前に、私は常に設計の瞬間を持っている。
実装する前にインターフェースに関する意思決定を行い、Redテストを作り、私はRed状態が嫌いだから、できるだけ早くGreenにする。Greenになれば不安はしばらく消えるので、考える余裕が生まれる。「うーん、通りはしたが、これは別のケースではだめだな。実装をもっと一般化しよう」
Redか？ Greenにする。Greenか？ ひと息ついて考える。これが私のTDDサイクルだ。
Q. 実装があまりにも自明に感じられて、実装を先にしてからRed-Greenテストをやってみることがある。このやり方をどう思うか？
それは「この実装方法が正しい」という仮定を置いているからだろうし、その仮定が正しいほど、当然テストを先に書くやり方の利点は小さくなる。
だが私は常にこう考えている。「私はこれからも学び続け、経験を積み続ける。そして今この瞬間が、自分が最も無知な瞬間だ」
つまり私は、自分が学び続けることを前提にし、状況が変わることも前提にしている。自分がもっと学ぶ必要があり、状況がもっと変わるほど、私はできる限り意思決定を後ろにずらしたい。これは一般原則だ。デートでも料理でも同じだ。
より多くを予測できるなら、より大きなジャンプができる。だが私がプログラミングで最も好きな瞬間は、全部わかっていると思ってどんどん進めていたのに、突然もっと良い実装方法があったと気づく瞬間だ。私はこういう瞬間をできるだけ頻繁に経験したい。だからTDDをやる。
頭の中に絵がはっきり描けていて、どんな入力がどんな出力を生むか確信できるなら、そのまま実装すればいい。だが、ミスが多いほど、学ぶことが多いほど、世界がより予測不能に変わるほど、今すぐ約束せず後に回すほうが有利だ。
Q. AIと一緒にコーディングしていても、以前のようにTDDで開発しているのか？
単純には答えにくい。
私はAIとのコミュニケーション手段として、主にAIが何を間違えたのかを伝える手段としてテストを活用している。こいつはしょっちゅう私のテストを削除したり修正したりしようとするが、そのたびに叱る。私のテストが正しいのだから、ちゃんとやれと。
AIは長期的には良くない意思決定をすることが多い。結合度を下げて凝集度を高めることも本当に苦手だ。何をすべきかを非常に明確に伝えればやれることもあるが、一般的には設計がうまくないと見るべきだ。
だから私はテストを非常に多く用意しておく。これを、AIが何かを壊していないかを検知する手段として使う。
（訳注：Kent BeckがバイブコーディングでTDDをどう使っているかについてはこの記事を参照してください）
Q. テストは絶対に直すな、テストが通らなければ通るまで実装コードだけを修正しろ、といったエージェントルールが一般化するともっと楽になりそうだ。今は2000年代に重要だったものを再発見している時期のようにも感じる。どう思うか？
実験を続けなければならない。可能なことはすべて試してみるべきだ。今、本当に何が最善なのかがわからないからだ。
何が「安く」、何が「高い」かについての地平が完全に変わった。以前は高価だったり難しかったりすると考えられていてやらなかった多くのことが、あきれるほど安くなった。
もしある日突然、自動車が無料になったらどうなると思う？ 当然何かは変わるだろう。だが、それによる二次的・三次的な変化はどうなるのか？ 誰にも予測できない。だから今は、ただいろいろ試してみるしかない。
Q. 50年以上プログラミングをしてきたが、今がいちばん楽しいと言っていたが、それはどういう意味か？
自分の大きなアイデアを実現するのが、これまでになく簡単になった。このアイデアをAIが実装できるのか、どうすれば実装するのかを見守って調整するのは、非常に中毒性がある。いつうまくいくのかよくわからず、魔法のようにうまくいくときは恍惚とするという点で、スロットマシンにも似ている。散歩に行ったり昼食を食べに行ったりする前に、こいつを遊ばせておきたくて、プロンプトを一つでも書いてから行こうという欲望にいつも駆られる。
2年前、私は「ChatGPTを使うことに抵抗があったが、なぜなのかわかった。自分の持つスキルの90%は今や$0になった。そして残り10%のレバレッジは1000倍になった。自分のスキルを再調整する時が来た」とするツイートを残していた。
> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023
（訳注：当時このツイートが話題になると、Kentはもう少し長い文章も残していました。）
当時は90%が何で10%が何なのか、まだ探っているところだと言っていたが、今ではある程度答えられる。大胆なビジョンを持ち、そのビジョンへ向かうマイルストーンを設定でき、設計を継続的に調整しながら前進して複雑性を制御するスキル。 これが、特定言語の文法知識（例：Rustで&, *, [をどこに置くか）よりも、はるかに重要なスキルだ。
まだコメントはありません。