あかさたさんの「TDD は新規性の高いサービス開発には適さない」にとても同意。
What(何を作るかっていうゴール) が決まっているかどうかに依存するってことだよね。つまり、naoya さんが言う「新しい機能を作っているときや、新しいサービスを作っているとき」は設計でも実装でもなく、本質的に企画の状態だから TDD とか関係ないと。たまたまコードで表現できる人だから企画をコードで検証している(プロトタイプ作りながら取捨選択してサービスや機能をデザインしている)だけなんでしょう。
個人的に今まで一番「BDD/TDD すばらしい!」と感じたのは、ある機能用のライブラリを書いているとき。開発時の制約で VB6.0 を使っていたんだけど、Collection にイライラしたので Ruby の Array を移植した。
まず、要素の追加とか要素へのアクセスとかの基本機能についてこつこつとテストを書いて、それだけクラスへ実装し、その後、少しずつメソッドを増やしていくという方法で書いていった。
本当にふつうの手順で順を追っただけなのだけど、最終的に完成間際の状態での開発スピードは気持ちがいいくらい速くて(当社比 5 倍くらい自分が凄腕に思えた。)、気にいらない部分のインタフェースを変更したり、実装を多少変えたりした場合にもあっという間に影響範囲の修正が終わっていく。
この時に、本当に「開発を駆動するためのテスト」なんだなぁと実感した。
最初の話から考えると、このケースもゴール(やりたいこと)は決まっていて、そこへ至る道筋がいくつかあるという場合だったからピタッとはまった。
一方、そのときには「ある機能」自体も BDD/TDD で進めたのだけど、これはあまりうまい結果にならなかった。簡易ルールエンジンのようなものを作りたくて、フレームワークのなんとなくのイメージに従って必要な機能を書いていった。
でも、あっちへ行き、こっちへ行きとふらふらした結果、全体としてあまりうまい構成ではないことに気付き、パーツをばらして再構成というようなことが何度かあり、けっきょくテスト主導での設計は諦めてトップダウンに設計をしてしまった。
Kent Beck 本はざっと読んだだけなので、根本的に誤解があるかもしれないんだけど、自分の体験からもあかさたさんの主張はとても納得が行く。上手に適材適所で使うようにしよう。(「いやいや、誤解しているよ。そういうケースもこうすれば TDD(もしくは別の何か) でうまくいくんだって!」という反論があるとうれしいなー。)