>>543
どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
より良い設計というのはバグが無いという意味ではなくて、費用対効果の面で妥当な設計、と言い換えても良いけど。

新規の何らかのクラスを設計するときに、シーケンス図を書いて複数人でレビューしてから実装には入った方が費用対効果が高いのか、TDDで実装してから本体とテストコードをレビューした方が費用対効果が高いのか？
もし、TDDの方が高いとき、それは何故なのか？

っという観点の話にすれば、俺の主張は以下になる。

TDDはテストによってより早くフィードバックが得られるから費用対効果が高いが、そのフィードバックを解釈するのにも経験が必要で、テストが通りさえすれば良い、という考え方では効果は発揮できない。
また、レビューアにもフィードバックを解釈する能力が要求されるうえ、ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
シーケンス図の方も書けば良い設計になるわけじゃないし、シーケンス図から問題点を読み解く能力が必要だが、おそらくTDDよりはレビューが易しい気がする。
だが、TDDのテストは実行可能ということが利点であり、レビューアが疑問があればテストを追加して実行することが出来る。これを利用すれば、費用対効果を更に高めることが出来るのではないか？