TDD信者が増えてきてるのでこの辺で一言言っとくか。

TDDは良いか？

とりあえず、過去に色々TDDについて記事を書きましたのでそれを掲載します。
仕事が出来ない人ほど横柄なのは何故？（2007年05月12日）
リファクタリング、テスト、開発速度など（2007年08月01日）
テストファースト（2007年08月21日）

まぁ、この中で一番参考になるのは最後に書いたテストファーストかな。今の僕の考えと合わせると心情が良く分かる。
TDDはプログラムを書く前に仕様の詳細まで把握する事が出来て、なおかつテストコードまで作ってくれる優れものだ。しかし、局面によってはTDDは不要になる。僕も数年前はTDDやテストファーストを実践していた。効率的だと思った所もあるが、大体はマンネリに陥ったり冗長なテストコードが作成されたりした。

結局のところ「プロトタイププロジェクトや仕様が変わるもの」に関してはTDDはさほど有効に働かない。その理由としては大抵はどちらも早めのリリースを求められるからである。そして今のビジネスは日々形を変えるためスピードを要求される。
なので、テストコードを書くくらいならまずは動くものを作ってビジネスと（要件と）合っているかを確認したい場合が多い。昔のように要件を詰めてからじゃないとプログラムを書けない時代は終わったのだ。
そうなるとTDDをしている余裕などなく、まずはビジネスのイメージを形にする事が先決になる。これの訓練を（特にマネージャーが）しているとTDDをしていなくても要件通りのプログラムをミスが少なく早く書けるようになる。

そして、要件が固まった所からテストコードを書いていけばいいのだ。初めから要件が決まっていて、変わりませんと言う現場は基本的に少ない。そんな現場は古臭いシステムを作っている所や開発部隊の権力が強くて実際のビジネスに迷惑をかけている所くらいだと思う。（SIerが殆ど満足されていないのは有名な話である。）


なので、僕の結論としてはTDDは以下の場合に使える。

・スピードが求められない開発
・要求が変わらない開発（そんな開発は存在しないと思う）←念のため、ウォーターフォールを指してます。
・チームとしてまだ確立されていなく、メンバーが信頼できない場合

また新しいチームを率いるような事があったら、序盤は使うかもしれないが・・・それ以外では使う事は無いな。
世の中で何故これだけ信者を作っているのか謎である。（といっても、僕もやるまでは信者のようにTDDを信仰してたな～。。。）