xUnitester Hotlinks: 第一回 和田卓人さん(上)

xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。

栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。

編集作業の関係で上下編に分割となりました。ご了承ください。(編集部)

和田卓人（わだたくと）

タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めようと努力している。今日もグリーンバンド（テスト駆動開発者の証。ボブ・マーティンが始めた）を左手に着け、テストと共にコードを書いている。

Blog：http://d.hatena.ne.jp/t-wada Twitter : @t_wada

聞き手

大中(せとあずさ)、杉野

語り手

和田さん

おまけ

おかざわ

好きな言葉

大中 では、ぺけま は るびまをリスペクトしているので、同じ質問を用意していて、まずは好きな言葉から。

和田 オブジェクトの広場のインタビューで言ったかもしれないんですけど、好きな言葉は「穂は実るほど頭を垂れる」です。基本謙虚であるべしという姿勢は、私自身時々逸脱しかねないので、思い出すようにしています。

尊敬する人

和田 尊敬する人は、外国人だとケント・ベック( Kent Beck )、ウォード・カニンガム( Ward Cunningham )、マーチン・ファウラー( Martin Fowler )を尊敬しています。日本人だと石井勝さんと...基本今まで関わった全ての人なんですけど、特にかくたにさんと、伊集院光さんです。

おかざわ 尊敬する人の中で実際に会った人は？

和田 実際に Kent Beck と Martin Fowler とは日本に来た時にお会いしたり見にいったり話したりしたことはあるけど、 Ward Cunningham は見たことなくて、伊集院光さんも見たことはないです。

大中 ラジオで？

和田 深夜ラジオで20年くらいずっと。ファンですね。

Jim Coplien から言われたこと

おかざわ Jim Coplien が来た時に、「 TDD やってる人？」という問いかけに、「はーい」ってやったら「君は早々に死ぬよ」ってありましたね。

和田 去年の新春にCopelien が来た時に「この中に TDD をやっている人はいるか？」と聞かれて手をあげたら「 TDD will kill you.」みたいなことを言われた気がします。TDD やってると死ぬぞみたいな。

杉野 「 TDD Will kill you.」ってどういうような意味で Cope に言われたんですか？

和田 えーと。

大中 三周目に死ぬってやつですか？

和田 それも関係していて、Togetterにまとめたのがあるので、それを見た方がいいと思うんですけど、 Copelien 自身はきちんとした設計をせずにボトムアップでテスト駆動で組み上げていくことに対して、やや懐疑的に思っている。設計が不在になっちゃうとか、大きいアーキテクチャーレベルの設計が無いとか、そういうところを突っ込まれたり、あと、テストのメンテナンスコストを問題視してますね。いまだにカンファレンスとかで定期的に、たとえば「Unit Testing Considered Not Helpful and Maybe Harmful」というタイトルで講演をやってたりして、健在だなあと。

和田 それがgoosのメーリングリストに Copelien がこんなこと言ってるんだけどって講演の概要が貼付けられて、Steve Freeman とか Nat Pryce がもう何周目に過ぎた後だよ、うんざり、みたいなレスをしていたのが印象的でしたね(笑)。何周目の議論だよみたいな。

TDDBC

大中 TDDBC 横浜の基調講演お疲れ様でした。

和田 ありがとうございます。

大中 各地の TDDBC で基調講演担当されていますが、講演の前は緊張されたりするんですか？

和田 します。基本的には直前まで緊張するたちなので、ギリギリまであがいていることが多いですね。TDDBC の基調講演は、毎回講演資料に手は入れていますが、できあがっているので緊張の度合いは強くないんですけど、初めて講演する内容とかは、直前までリハーサルやってたりとか、資料の手直ししたりすることが多いです。デブサミ に登壇するときも直前まで準備をしていました。でもいざ壇上に上っちゃうともう自分の中でモードが変わるので、緊張しないんです。

エナジードリンク

杉野 登壇する時は毎回ドリンク飲まれてるんですか？

和田 飲んでますね。いつ頃だろ、登壇するようになったのっていつ頃からでしたっけ？

大中 2005年、2006年くらいですね。

和田 あの頃も、登壇する前の日は資料つくったり練習したりとかで寝てないことが多くて、体力的に限界に近いときに壇上に行くことが多かったんですね。なのでゼナとかを飲んでたんですよ。壇上で。

おかざわ まだ Red Bull が普及してない。

和田 まだ Red Bull に出会ってない。で、たとえば Seasar Conference に登壇するときもゼナ飲んでから講演に入っていました。いつからかゲン担ぎみたいに講演前に1本飲むということをやりだして、半ばルーチンワークみたいな感じになり、そしてゼナが Red Bull に変わっていった。

大中 TDDBC の講演とかで、「健康」の話をされるときに、 Red Bull の話を小ネタに挟むようになったのっていつぐらいからですっけ？

和田 Red Bull を飲み始めるようになってからですね。「健康」っていうスライドに対する反応が変わってきているというか、割と最初は大まじめに、健康だよドーンってやってたんですけど、なんか...

和田 Red Bull も Twitter から知ったんです。 PFI の若いエンジニアとか Be Proud の若いエンジニアが Red Bull というのを飲んでいるらしいと。で、 Red Bull ってなんだろうと思ったら健康ドリンクだった。健康ドリンクっていうと違うな。なんていうんだ。で飲んでみたら、どうやらこれはそういう飲み物らしいと、それでゼナから乗り換えた感じですね。

おかざわ 若手から学んだ感じですね。

若手に対するリスペクトと Mac/Windows

杉野 和田さんて若手に対するリスペクトを各地で言われてますね。若い人に対して尊敬しているというのを感じますが、そういうエピソードってありますか？

和田 例えば現役の大学院生や学生さんと一緒に研究させてもらったりとか、仕事上のプロジェクトでも若いエンジニアと仕事することが多いんです。それで彼らとペアプロしたりすると、新しい環境を見たり学んだりすることが多い。そのかわりというか、僕も30を越えたので、どちらかというと古いテクを教えたりします。先日の Node 祭りでも、めちゃくちゃ指の動くエンジニアを目撃したことがあったんですけど、若いエンジニアって指が動くのが速くて、補完するより全部打ち込むほうが速いみたいな感じでワーっと書く。あーでもこういうやり方もあるよ、みたいなことをコラボして教えたり、日々の Unix 暮らしについて教えたりするんです。

和田 TDDBC をやっていて気づいたのは、マイクロソフトの戦略は成功しているというべきか、若い人になればなるほど Windows 率が増えるんです。勉強会に行くと Mac ばかり見かけるじゃないですか。それがもうちょっと若い、 20 代前半とかもしくは 10 代後半になると、 Mac を持っている人がそんなにいない気がして、 Windows 層なんですよ。僕の観測範囲ではイベントに来る学生さんは Windows PC にVisual Studio の Academic 版みたいのが入っている、という構成をよく見かけるんです。そうすると実は文化的に断絶があるんですよ。日々の Unix 暮らしを知らないから、 cat して sed して awk してみたいな技は知らない人が多い。そういう断絶があるので、自分が知っていることを教えたりしますね。

大中 そうですね、勉強会なんかだと Mac が一大勢力なんですよね。

和田 同世代だとそうだと思う。

大中 76 世代、たとえば naoya さんの世代。

和田 78, 77, 76...そういえば naoya さんや miyagawa さんとは同じ年、同じ月の生まれなんです。

TDD はキャズムを超えたのか？

大中 前回の TDDBC 横浜も枠に対して倍率 2 倍以上で、この前の 7 月の TDDBC 東京 1.5 だと 120 名ですか。ちょっとあれは異様な盛り上がりだと思ったんですけど、キャズムを越えたのか、バブルなのか、さあどっちだろうと思うところがあるんですけど、和田さんはどう思われますか？

和田 バブルなんだろうか？需要が大きいんだろうなあとは思いました。東京で TDDBC をずっとやってなかったじゃないですか。第1回は東京でやって、その後ずっと地方巡業みたいな感じでやってて、東京は他にもハッカソンがあるけれど、 TDDBC は無かったんですね。TDDBC は主催者がいないと成り立たない、始まらないプロジェクトなので、東京でやろうという人がいなかった状態がずっと続いてたんですね。で、それがバッと立ち上がったら一気にワーと埋まったので、これはニーズがあるらしいという話になった。あと横浜で のハッシュタグ は札幌とか名古屋とか福岡の開催の時とかに盛り上がってたので、それを見聞きして参加したい人が東京で多かったのかなあと思います。開催を宣言したのは東京よりも横浜のほうが先ですよね？

大中 そうですね、で、地震で電力事情とかもあったので、夏から秋に延ばしたんですけど。

和田 横浜に反応した人は結構いたんですよね。横浜なら参加しようと。首都圏で久々なブートキャンプだなと。

和田 勉強会にバブルってあるのかな。バブルというのは何かに対して虚構の需要が生まれるというか、内実以上のものになってしまうことだと思うので、まだバブルにまでは到っていないのかなあという気はします。テスト駆動開発を学びたいというより、むしろ TDDBC というイベントの方に対する需要があるのかなと感じるときは時々あります。基本的にはテスト駆動開発というのは自習できるものですから、そのあたり不思議な構図になっているなあと思います。

TDDBC の持続可能な体制つくり

大中 僕もやってみて、まだニーズはあるなと思っていて、まだ何回か繰り返していけるか、やっていきたいと思ってるんですが、TDDBC の MLとかで、持続可能な体制作りというか、和田さんに依存しない体制作りというのが議論されているので、そのあたりの話をお聞きしたいです。

和田 僕は TDDBC を始めたメンバーの内の一人で、第一回の時に基調講演をやって、その後も縁あってずっと基調講演をやってるんですけど、それはいきがかり上やっている側面があります。初回以降はしばらく東京以外でやってきたからという理由もありますね。東京以外での開催主催者、自分のところでやりたいと手を挙げてくれた @katzchang さんとか、 @bleis さん、@pocketberserker さんのところに行って講演することには大きな意義があると個人的に思っていたので、ずっと私がやってきた側面があります。地方で TDD の講演をするのは今まであまりなかったという事情もあるので、やる意味があると思いました。一方東京はテスト駆動開発の経験者も多いし、今後は TDDBC for C++ の時みたいに、僕以外の人が基調講演や実践的な講演をできる土壌が東京にはあると思うので、任せる方向を進めていきたいと思っています。

大中 t_wada 公認 TDD 伝道師みたいな...まあ、冗談も含んでるんですけど、そういう案が出ているということに対しては、和田さんはどう思われますか？

和田 私はそんな偉い存在じゃないし、公認というのは少なくともやらないと思います。ただ、テスト駆動開発を伝える人が増えるのは大事なことだと考えます。今 TDDBC に対する意見をいくつか頂いているんですけど、教える人と教わる人が分離しすぎているという意見がたまにあるんですね。もうちょっと混ぜていきたいし、教える側も学ぶものがある。 TDD という言葉、アクティビティに対して、個々人が持っている像というのは微妙に異なります。「教える人のロール」が仮にあるとして、その教える側でもやはり一人一人意見は違うんです。その個々人の違い自体を講演のコンテンツとしていけばいいんじゃないかと思っています。例えば井芹さんの講演なんて、まさに井芹さんらしい講演ですよね。

和田 つまり僕が言っているのが TDD だと言うつもりは皆目無いですし、僕自身も我流で学んできたものだから、テストコードを書くことで、開発が駆動されて、自分が書くコードに自信を持つことが出来て、前に進む力になり、一歩一歩進むための支えになるというのがテスト駆動開発の大事なところだと思うので、それが伝えられる人であればいいんじゃないかと思います。

印象深かった TDDBC

大中 今まで札幌ですとか福岡ですとか北陸とか名古屋とか、色々回られてると思うんですけど、一番印象深かったTDDBCというか、印象深かったことってありますか？

おかざわ よかったこととして。印象深いという意味合いでいいと思うんですけど。

和田 印象が強かったのは、 2 回目と 3 回目、北陸と名古屋。第 1 回目を東京でやったときは、お祭りというか本当に origin の世界だから、こういうイベントをやったらどうなるだろうとやってみたら、ボーンと集まった。でも、それで日本全国に広がるとは思っていなかったし、広げる意図は無かったんですね。

和田 最初の TDDBC の意図はどちらかというと「 TDD でイベントやろう! 外国人タレントも来るし」という勢い。唯一外国人タレント来てるイベントでしょ？ 第 1 回目のやつが。第 1 回目だけ性質が違うんですよ。ゲストがいて、 Oracle さんの会場を借りて、ドーンと賑わったイベントになった。で、それを自分のところでやってほしいと @katzchang さんが言ってくれて、北陸でやることになった。 2ch のスレも 2 番が大事じゃないですか。

大中 かくたにさんの、「石のスープの石」の話とか。

和田 そうですね、つながってくる。だから 2 番、 3 番目。北陸に行って開催したら @bleis さんが名古屋から参加していて、自分のところでやりたいと言ってくれて、名古屋に行って開催。そうしたら名古屋では福岡から参加した @pocketberserker さんが自分のところでやりたいと言う。実は @katzchang さんは 1 回目の TDDBC に参加してるんですよ。だから参加者が自分の地元で開催する、それに参加した人が自分のところでやるというチェーンがバチッと、福岡までつながったんですね。それが強い印象に残っています。だからどちらが上というのはないけど、北陸・名古屋・福岡とつながったのは、印象深かったですね。

TDDBCの 言語別参加希望に見る傾向

大中 この前に横浜の時の言語毎の申込者の分布っていうのがあって、感想をいただきたいと思うんですが...全部で 65 名で、こんな感じです。

1. Java 25 名
2. Ruby 15 名
3. PHP 11 名
4. C++ 6 名
5. JavaScript 4 名
6. CとGroovy 2 名

@shishi4twさんは、PHP 健闘してるな、という感想をもっていたんですが、

和田 基本的にこれまで開催してきた TDDBC で、参加者の希望言語は常にJavaが1位でした(言語縛りで開催した TDDBC を除く)。これはもう全然変わらない。やっぱりシェアを大きく持っている言語だからというのがあります。2 位 3 位は割と地方色が現れることが多いんですが、 Ruby が 2 番目な事が多い気がしますね。 PHP は TDDBC が東京に帰ってきてから参加者が増え出しました。第 1 回の TDDBC の時は、あまりいなかった。最近 PHP のコミュニティが TDD とか CI に興味を持ちだしているので、動きが活発なんです。

和田 地方と東京開催で違うのは、 Web 系の人は首都圏に集中しているということですね。だから東京以外で TDDBC やるときは、もうちょっと PHP の比率は下がる。名古屋はやはり名古屋っぽい感じというか、 C とか C++ が多いことに加えて、 OCaml や Scala が多い。 2 つの名古屋臭さがすごくある。組み込みが強い土地柄であることと、もうひとつは大学が中心になっているんですけど、関数型言語を学ぶ土壌がある。その2つで、名古屋はすごく印象深い言語構成になってましたね。あと横浜で C# がいないのが不思議ですね。

大中 横浜は C# が公式サポートに入ってなかったので。これは第 1 希望でとってます。第 2 希望だと Perl が 2 名いたんですよ。

和田 そうか、 Perl の参加者があまりいない。 Perl 自体には強いテスト文化があるんだけど…

テストコードとプロダクトコードが別の言語がいいのか同じ言語がいいのか

杉野 じゃあ、今、言語の話が出たんで、ここ数日盛り上がった話で、テストコードとプロダクトコードは違う言語がいいのか、同じ言語がいいのかという議論なんですけど、それに関して和田さんはどういう考えを持たれていますか？

和田 すごく難しい議論です。テストコードというのは、まず初めに見るサンプルコードであるべきだという考え方、つまりテストコードは自分たちが書くコードの実行可能な使用例であるべきだという考えかたがあります。もう一つの意見は、テストコードはプロダクトコードとともに成長していくメンテナンス対象である、だからテストコードの行数は短いほうがよくて、表現力の強い言語、要するにテストを書く効率が高く、より少ないコード量で同じ意味を示せる言語で書いた方がメンテナンス効率が良いという考え。はっきりと分かれているんです。だから例えば Java のコードを書くときに、 Java でテストコードも書くのか、それとも Groovy とか、 JRuby でテストコードを書くのかで大きく変わってくる。

和田 この議論でもう一つ関わってくるのがリファクタリングです。リファクタリングをする際の環境の話になってくるんですけど、例えば Java は IDE が強力で、 IDE 抜きでは語れない言語になってますよね。だから例えばクラスのリネームとかメソッドのリネームをするときに、 Eclipse を使っていて Java でテストコードを書くのであれば、プロダクトコードのメソッドをリネームしたらテストコードの方は特にメンテナンスしなくても Eclipse がバっとリネームしてくれる。テストのメンテナンスコストは、機械がある程度肩代わりしてくれるという構図がなりたちます。テストコードとプロダクトコードの間を行ったり来たりするとか、定義にジャンプする等も同一言語のほうが簡単だったりしますね。

大中 ただあれって発端はbleisさんですけど、もとをたどってくと、 TDDBC 横浜の時の 「Groovy すげえ」という話で、 Java のテストコードを Groovy で書くというところから出てきた話なんですよね。

杉野 Java と Groovy の関係が Ruby on Rails と RSpec みたいな関係にあるんじゃないかと。

和田 まさにそういう関係が想起できるわけですよね。 RSpec って、はっきりと言語内言語というか Ruby で書かれた Testing DSL みたいになってますよね。Rails のテストに RSpec を使うか、 Test::Unit を使うのか Ruby コミュニティでも議論になります。 Ruby のコードを書いて、 Ruby のコードでテストコードを書きたいという意見と、 RSpec はもはや Ruby なんだけど Ruby じゃないような、独自な言語になっているけれどとても強力なので、どちらを取るかという議論が常にあります。

和田 僕自身は Ruby で書く時は RSpec でテストを書いています。それは RSpec の表現力が強いということを自覚している、認識しているからですかね。あと、リファクタリングの過程でテストをメンテナンスするのは、それは普通に自分でやるべきことだろうと割り切っている、本当にそれだけのことなんです。 Ruby で IDE の補完とかはまだあまり期待できないので、 find して grep する世界なんですよ、ざっくりと言うと。それでもテストコードの表現力が高くて、簡単に言うとノイズが少なく、やりたいことだけが書いてあって、縦にグっとコンパクトなテストコードになっているほうが好みだからなんです。

和田 人間がメンテナンスできる量ってやっぱり限界があると思っていて、 1 人が書くコードの量にも限界があるという話があったりするじゃないですか。言語毎の表現力の話になるとよく宗教戦争になっちゃうんですけど、それはそうとして、やっぱり近年テストコードもメンテナンス対象であると認識されてきているので、メンテナンスしやすいテストコード、重複が少ないとか、すぐ意味が分かるとか、そういうところの重要性が高まっているのだと思います。メンテナンスを機械が肩代わりできる言語は機械の力を活かしやすい構成にするでしょう。例えば JUnit とかがそうです。機械に頼れず人間がメンテナンスしていくのであれば、表現力が高くてコンパクトに記述できるテストコードを書くという流れもあるんだろうと思います。

(次号に続きます)