InfoQ

http://www.infoq.com/jp/interviews/coplien-martin-tdd_ja
みた．
TDDの反論は興味深い．

契約による設計が出たときは、表明をProductionCodeに配置するかTestCodeに配置するかの違い程度じゃね？と言いたくなったが、

TestCode-ProductionCodeのどちらに表明を配置したら、よりシンプルに書けるか？みたいな話は、うーんと思った．
時々、良い方法が思いつかず、トリッキーにテスト可能な構造にした経験はある．
表明をProductionCodeに埋め込んだ方が、よりシンプルになるのかなと．

ここでは、私は、TDDの反対の立場をとってみる．
「TDDが強調されすぎると、ビジネス価値とソースコード関係が不透明になる」と少なくとも私は感じている．

Domainをプログラマ脳内パーサーを通して、SpecCode/TestCodeに変換し（変換できないものはどんどん質問する）、それからTestCode/SpecCodeとProductionCodeと同期を取る感覚は、わかる．
ただ、プログラマ視点をいったん置いといて、ユーザ視点でシステムが運用されるドメインを深く理解するんだの意識を持ちながら、TDDを使ってDomainをソースコードに練り込んで行く感覚まで至っていない．（みんなもってるのかな？）

そこは、イテレーション、バックログ、ユーザストーリー（に近いBDD）、デモ、継続的リリースと関連が強くなると言いたくなる自分がいるが、それは事実なのか？仮説なのか？推論のはしごを上りすぎていないか？
普通に時間を取って、ミーティングして、Spec/Desginを書いてレビューした方が、チーム全員でDomainに対する共通の理解が進み、良いコードを書く近道では？と反論したくなる自分がいるのも確か．

おっとだんだん、私の思考がこんがらがってきたが、自分が気になるテーマは次
「ビジネス価値とソースコードの２つをいかにして同期化していくか？」

InfoQって異なる意見をMix-inする場になっていて、刺激的．（つまんない記事もあるがw）
主張と探求のバランスがとれて、建設的な意見の対立が思いっきりできる安全なフィールドが、日本にもあるといいなぁ．