最初に
ちょっと最近，ドタバタしてて twitter だと腰を据えて話せないなと感じたので，ちょっと最近のTDD 議論についてちゃんと僕の気持ちを書いてみようと思います．
これは僕が"今"感じてる事とか考えている事を書いているだけですので，誰かを論破したいとか，誰かを説得したいという意思は無いです．
本当に裏とかはなく，純粋に「"庄司嘉織"という人間は"今この時"にこういう事を感じてこういう事を考えた」というだけです．
もちろん明日には考えが変わるかもしれないし，逆に過去の発言とは違うかもしれませんが，「最近はこう感じている」という事をちゃんと書いておこうと思いました．
デブサミでの発表について
id:babie さんにちゃんと返事をしていなかったので，まずちゃんと返事をしておこうと思います．(遅くなってしまってすいません)
@kakutani は興味なくても、あのスライドだと @yoshiori の誤った考え方（である可能性がある）に、権威付けを与えている。「@kakutani @t_wada 直伝だ」と見える。この議論いかんであの言が偽だったら、@yoshiori はスライドを訂正した方が良い。
http://twitter.com/babie/status/9468960884
これは権威付けをしたいという気持ちは本当になく，感謝とリスペクトを含めて出していました．
また，もう一点，僕でもそうやって発表者に聞いて教えてもらったりしてるので，みんなも恐れないで聞いてみると親切に教えてもらえるよというのを伝えたくて入れています．
(本当に悩んだので両人にいちおう承諾を得ました)
もう、俺の師匠として @kakutani と @t_wada の名前を出さない方がいいのかなぁ…… リスペクトしてるから感謝の意味も含めて出すようにしてるんだけど、二人の名前を出して二人に迷惑かかっちゃってもアレだしなぁ
http://twitter.com/yoshiori/status/9109219107
@yoshiori 別に構わないですよ。名誉なことです。
http://twitter.com/t_wada/status/9109350418
@yoshiori なんのことわりもなく書籍のあとがきに書かれたこともあるので平気:-)
http://twitter.com/kakutani/status/9116364567
と，言ってもらえたので資料に入れさせていただきました．
次に
@yoshiori 「オレオレTDD」を広めるなら、但し書きを付けるなどの、誠実な対応を望みます。
http://twitter.com/babie/status/9470015080
ですが，副題に「"僕"(とドワンゴ)のXP」と入れている事で僕は僕自身が理解した XP や TDD について話しをするという事になると感じていました．
さらに発表の最初で
方向を示し(一周目)，道を通す(二周目)の人たちがいた
僕ら(三周目)がすべきは高速道路の設置であって，車輪の再開発では無い
先人が学んだ事や感じた事は本やブログにいっぱいあるので，
僕らはさらにそれを読み実践し，感じた事や起った事をまた残そう
という話しをしました．
で，「今日は僕がこの一年でやった事，感じた事を話します」と．
僕が僕の言葉で僕の感じた事や学んだ事を話しているので間違った理解があるかもしれません(むしろいっぱいあると思います)．
プレゼンの時は「と感じます」とか「と思います」と発表したのですが，資料にそれを書いてしまうと冗長なので書いていません．すいません．
ただ，"僕"が"僕"の言葉で"僕"の理解した事，感じた事，考えた事を発表するとそれはある意味すべて「オレオレxxx」になってしまうと思うのですがどうでしょうか？
逆に「オレオレxxx」にならない為には自分の主観を入れずに引用だけで話すしかなくなってしまうと思うのですが……
で，TDD がテスト手法かどうかについて
"僕は" TDD は開発手法であって，テスト手法では無いと感じています．
テスト手法としては不十分だと思います．
ここでちょっと言葉の難しいところなのですが，
「TDD はテスト手法としては不十分だけどテスト手法である」
「TDD はテスト手法としては不十分だからテスト手法ではない」
どちらでも良いと思っているのですが，今まで僕自身で経験したり人に話したり相談された経験から"僕は"「テスト手法ではない」と言ってしまった方が良いと感じました．
まずテストに何を書いていいかわからない
僕が一番最初に id:kakutani に相談したのもこの台詞だったと思いますし，また僕も一番聞かれる質問なのですがどうしても最初は UnitTest で網羅的なテストを書こうとしてしまって手が止ってしましました．
品質管理のテストとしての価値はどうなのか
TDD の話しをしていると，どうしても言われるのが，
「TDD やってたらテストの工程はいらないんですね？」
「テスト計画もなくていきなりテストを書くのか？」
的な事を言われます．
"僕は" TDD をやっていてもテストの工程は別に必要だと思ってますし，その工程ではちゃんとテスト計画もすべきだと思っています．
TDD は開発手法であって，テスト手法では無い
というような経験や考えから"僕"は「テスト手法ではない」と言ってしまった方が良いと感ています．
むしろ，TDD で開発するのは，
「emacs で開発するのか vim で開発するのか？」
「Eclipse で開発するのか NetBeans で開発するのか？」
くらいの違いだと思っています．
チーム内では揃えたほうが良いという事も含めて．
(エディタや開発環境もチーム内で揃っていた方がペアプロとかしやすい)
品質管理のテストを一緒にしてはいけないのか？
品質管理のテストを一緒にしたらいけないのかどうかも聞かれた事があるのですが，"僕"は一緒にすべきでは無いと思います．
UnitTest 的なものが一緒になってしまうとどうしても仕様変更時のメンテナンスコストが高くなってしまいます．
(もちろん，テストの工程ではメンテナンスしなくてはいけませんがそれは上記でのべたように別に設けるべきだと思っています)
また，特に DB と連携する部分などで如実に SlowTest の問題が発生してしまいます．
メンテナンスコストの肥大化や SlowTest のせいで逆に TDD がやりにくくなっては本末転倒だと思います．
デブサミで「TDD は テスト手法では無い」と発表すべきだったか？
完全に結果論なのですが，id:babie をはじめ色々な方の意見を聞く事が出来たので僕にとってはとても良かったと思っています．
僕はそもそも，
「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。
http://twitter.com/yoshiori/status/9102087388
という考えから「テスト手法ではない」という発表をしたので，
逆にこの「テスト手法ではない」という考えが広まってしまって凝り固まってしまってしまうような事になってしまったら，
「ヨシオリはああ言っているけど，言いすぎだ!!間違っている!!」
と発表してもらえればなぁと思います．
(もしも世間がそれで凝り固まるくらい開発のための TDD になってくれると個人的には嬉しいのですが)
