xUTP Magazine - 0003/Hotlinks Diff
- Added parts are displayed like this.
- Deleted parts are displayed
like this.
! はじめに
xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。
栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。
こちらは後編となります。[[前編はこちら|0002/Hotlinks]]
! 和田卓人さんのプロフィール
""和田卓人（わだたくと）
""
""タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めようと努力している。今日もグリーンバンド（テスト駆動開発者の証。ボブ・マーティンが始めた）を左手に着け、テストと共にコードを書いている。
""
""Blog：http://d.hatena.ne.jp/t-wada
""Twitter : [[@t_wada|http://twitter.com/t_wada/]]
http://devtesting.jp/image/t_wada.jpg
!! TDDBC の波及効果
'''大中''' TDDBC の参加者から聞いた話で、「ウォーターフォールだとテストファーストくらいしかできないけど、設計時点でテストしやすさを意識するようになった」という話があるんですね。
おかざわさんは「プラクティスとしての TDD からは外れているんだけど、TDDBC を通じて得られるものは TDD 以外にも影響するんだな」と言っていました。和田さんは参加者から得られる感想などで印象に残ったことはありますか？
'''おかざわ''' 参加者から直接フィードバックを得られる機会はあるのかなぁと。
'''和田''' 一番多いのは Twitter とか Blog ですね。 #tddbc のタグ付きでも無しでも。あとは TDDBC でグリーンバンドを配っているじゃないですか{{fn('2010 年の TDDBC 名古屋で「テストを書くのはつらい。 Bob Martin もグリーンバンドを身につけて、自分を戒めてるんだ」というエピソードが紹介されたことから、TDDBC 参加者で共同購入する活動が始まった。')}}。参加された方が後日グリーンバンドを付けているところを見ると嬉しいですね。すごく。
みんな現場に帰ってやってるのは『レガシーコード改善ガイド』{{fn('[[http://www.amazon.co.jp/dp/47981168311/|http://www.amazon.co.jp/dp/47981168311/]]')}}の世界だったりするので、そういう現実に対する立ち向かい方も含めて、学ぶポインタになる、きっかけになるイベントとしてやっていけるといいなと思っています。
TDDBC の理念、やりたいこととしては、テスト駆動開発だけじゃなくて、ペアプログラミングと、一つの課題を他の人はどう解くのかというのを見てもらうコードレビュー。この 2 つはすごく重要かつ強力で、しかし現場ではなかなか導入されないプラクティスだと思っていて、コードレビュー、ペアプログラミングを強制的にでも体験できる場を作りたかった。
でも参加者一人一人は月曜日に現場に戻ると個人戦の世界になってしまう。
テスト駆動開発はやはり個人のプログラミングスキルだと思っているので、『テスト駆動開発入門』{{fn('[[http://www.amazon.co.jp/dp/48947171151/|http://www.amazon.co.jp/dp/48947171151/]]')}}とか『レガシーコード改善ガイド』とか、一人で成立し得るスキルとして学ぶためのきっかけを掴んでもらう場にしたいと思ってやっています。
参加後に『レガシーコード改善ガイド』とか『テスト駆動開発入門』を買って勉強していたり、グリーンバンドを左手に付けているところを見るとすごく嬉しいですね。
!! TDD "Boost" Camp
'''大中''' 話は変わるんですが、"Boost Camp"という話があるじゃないですか。
'''和田''' TDDBC に参加した人が、その後でもう少し実践的なイベントをやりたい、という話ですよね。
'''大中''' はい。
'''和田''' 札幌ですでに Web アプリを TDD でつくるという実践的なテーマをやっていて、これは東京でもやりたいと思っています。それが Boost になるかどうかは分からないですけど。
イベントとしての TDDBC についてですが、テスト駆動開発は未だに啓蒙段階だと思っています。ペアプログラミングも、TDDBC で初めてやったという方が圧倒的に多数ですしね。 TDD やペアプロの初心者の方々に体験できる場を提供するのは、Boot Camp として続けたほうがいいんじゃないかと思います。
たとえそこで僕が講演をしなくても、イベントとしての TDDBC はまだニーズがあるし、続けていけたらと思います。
その後の応用編としては、母体となるコミュニティがある場合は、そこでやれば良いのではないかと思います。
'''和田''' TDDBC が他のイベントと違ってやや特殊なのは、プログラミング言語を跨ぐ傾向が強いところですね。実はこれは第一回から折り込み済みでやっているんです。
同じ問題を別の言語でどうやって解くのかを知ることは体験としてすごく面白いので、大事にしたいなと思っています。
'''和田''' 最近では TDDBC for <言語> も開催されていて、あれは良いところもあったし、本当は別の言語も見てもらいたいなと思うところもあって、個人的には悩ましいところです。でも、例えば「PHP のイベントだから参加した」「C++ のイベントだから参加した」という人が明らかにいるんですね。
'''一同''' うんうん。
'''和田''' 言語しばりのほうが参加しやすい人もいるし、そこはこれからも考えていきたいなと思っています。
'''杉野''' カフェでペアプロするとか、ちょっとしたものが欲しいですね。
勉強会をばーんと立ち上げるんじゃなくて、僕はまだ行ったことがないんですけど、Asakusa.rb{{fn ('東京下町を拠点とする地域Rubyistコミュニティ。[[http://qwik.jp/asakusarb/|http://qwik.jp/asakusarb/]]')}} みたいに、まずは定期的に集まるというような。
'''和田''' とりあえず場だけあると。
'''杉野''' そういうふうにやったほうが面白いんじゃないかって少し案を考えています。
'''和田''' Boost Camp もそうやったらいいかもしれませんね。各々分かれて研鑽を積むために。
東京でまだ TDDBC に人がたくさん集まるのは、そういう「場に集まる」性質があるのかなって思います。
長く主催者がいなかったというのも関係してるのかな。
'''大中''' TDDBC Tokyo 1.5 の主催者の大塚さん{{fn('[[http://hiroki.jp/|http://hiroki.jp/]]')}}とはどういうきっかけで？
'''和田''' あれは、「東京で TDDBC 2 をやる企画はあるんですか？」というのを何かで聞かれたのがきっかけです。
TDDBC 東京 2 はまだ実現していないんですけど、冬か来春にやろうみたいな企画はあったんですね。
それで、「あるんだけどかなり先なんですよ」と返事をしたら、「小規模でいいからやることはできますか？」と質問されたんです。
'''和田''' 「主催者の言ったもの勝ちだからどんどんやりましょう」と話をしていたら、1.5 という謎のバージョン番号が始まったんです。
'''大中''' TDDBC の緩い合意として、やろうとする人がいればそれを支援するよ、というのがありますが、それが伝わっているのかどうか。
'''和田''' 伝わりが甘いですかね、やっぱり。
'''大中''' どうなんですかね。
'''和田''' それはやはり問題点ですね。ポータル{{fn ('[[http://devtesting.jp/tddbc/|http://devtesting.jp/tddbc/]]')}}も大中さんの力でやっとできたくらいだし。
参加したいという人はいるけど、主催できると思っている人が少ないんじゃないかという思いはありますね。
'''大中''' うーん。
'''和田''' 地方に行くと、基本的にコミュニティの大きさ自体は小さくなるので、気心が知れて勉強会をやりやすいというか、勉強会に出やすいというのはあると思うんです。
東京は圧倒的に人が多いので、むしろ分散化の傾向が強いような気がします。
'''大中''' コミュニティとしてもそうなんですけど、都市としての規模も桁違いなので。
都市部で公的施設を押さえるとなると半年くらい前から予約が必要なんですよ。
'''和田''' 会場の問題はありますね。自社開催とか、会社を休日に貸してくださるとか、そういった支援がないと。
公的施設を借りるとなると東京は早めに準備しないといけないし、しかも料金は高い。札幌は非常に安くてびっくりしましたもん。それはあるなぁ。
そうすると、1.5 の時もそうでしたが、どこかの会社の会場を借していただいた場合には、相対的に箱は狭く小さくなるので、参加倍率はどうしても高くなってしまう。
でも、あんまり人を増やしすぎてもイベントとしての質を保ちにくいだろうなぁとも思っています。
'''和田''' ただ、開催を焦る必要は無いとも思っていて、まだ待ってる人がたくさんいるからもっと頻繁にやらなきゃとか、そんなに思い詰めなくてもいいんじゃないかと考えています。待てないなら自分で勉強すればいいだけだし。
'''おかざわ''' 勉強というところで出てくるのが、『テスト駆動開発入門』についての評判が分かれるところがある。
'''和田''' はい。
'''おかざわ''' 原文も独特だという。
'''和田''' 原文はかなり独特ですね。
'''おかざわ''' 2000 年くらいに出版されたんでしたっけ。
'''和田''' 2002 年くらいだったかな。{{fn ('「テスト駆動開発入門」の原著は2002年出版')}}
'''大中''' そうですね、2002 年か2003 年か。
'''おかざわ''' やはり2010 年代の入門本が必要というか。
'''和田''' それが goos{{fn('[[Growing Object Oriented Software Guided by Test|http://www.growing-object-oriented-software.com/]]。[[jMock|http://www.jmock.org/]] の開発者である Nat Price と Steeve Freeman による、テスト駆動開発によるシステム開発について論じた書籍')}} ですよ、という話になるとは思うんですけどね。
'''大中''' ぺけまも元々は出版プロジェクトだったわけで。
'''和田''' まぁね。本、本なぁ。
'''杉野''' 出版と言えば、5年ぐらい前になるんですが、Web+DB PRESS の和田さんの記事をまとめたものが出るとか出ないとかいう話が。
'''和田''' あれは忙しすぎてまったく文章を書けなくてポシャってしまいました……。
本を書くにはものすごい集中力を必要とするので、本業をやりながらだとかなり負荷がかかりますね。
もっと Web 媒体とかで小出しにできるインフラが無いとつらいかなぁと思いました。
まあ、僕に力が無いだけなんですけど。
'''大中''' いやいやいや。
!! TDDの記事を書くのは難しい
'''和田''' TDD のことを本に書こうとすると結構難しいんですね。
Kent Beck の TDD 本でも、「 Money とか現実には使わないよね」という意見も良く聞きます。
基本的に TDD 本は置き換え可能なパターンの話、TDD の原理・原則といったひとつひとつの所作をどうやって自分の目の前の問題に翻訳して適用していくのかという話なので。
'''大中''' うんうん。
'''和田''' 現実の自分たちが作っている Web アプリであるとか、組み込みソフトなどで TDD をどう実践するかという話を本にしようとすると、分量としては圧倒的に増えてしまう。すると、本質的ではない記述が増えてしまうので悩ましいんです。 Maven の pom.xml を書くだとか、データベースをセットアップするだとか。
'''和田''' TDD のエッセンスに絞って書こうとすればするほど、サンプルは小さくなる必要がある。
そのサンプルが例えばスタックとかになると、まるでオブジェクト指向を哺乳類で説明するみたいな、こんなのは現場では必要とされてない、という話になってしまう。
リアルな方向、データベースとかネットワークとかファイルとか Web とかに行こうとすると、今度はモックとかスタブの話が出てきてしまう。
そういうのは基本的に TDD の、例えば Kent Beck の本であった原則を応用して戦っていくところなんですけどね。
小さいサンプルと現実の世界を結びつけるところがミッシングリンクになっちゃっているという面はありますね。
'''和田''' 生きたサンプルとして Web で公開されているソースコードはたくさんあるし(例えばGithub とか)、洋書ではある現実に即したアプリケーションを TDD で開発するものがあります。
だから、 TDD を分かっている人は日々の開発に応用していけるけど、これから入門する人の間には大きなギャップがある、とは思います。
'''おかざわ''' この前『テスト駆動開発JavaScript』{{fn('[[http://www.amazon.co.jp/dp/4048707868/|http://www.amazon.co.jp/dp/4048707868/]]')}}って本が出ましたよね。
'''和田''' はいはい。
'''おかざわ''' 実際のニーズとしては Java が多いんだけど、Java による TDD の本は 2002 年から出版されていないように思います。
'''和田''' そう言われれてみればそうかなぁ。どうかなぁ。
'''大中''' ソフトウェアテストの本で JUnit を取り上げてるっていうのは何冊かありますが。
'''和田''' それはありますね。
'''大中''' あと、[[@kanu_|http://twitter.com/kanu_]] さんが Togetter でまとめた「TDD の本は売れない」っていうのがありますね。{{fn('[[http://togetter.com/li/139936|http://togetter.com/li/139936]]')}}
'''和田''' なんかそんなのありましたね。どんな結論なんでしたっけ？
'''大中''' 結局「TDD がなぜ受け入れられないか」という話になってしまってましたね。
'''和田''' 本が売れない時代なんですよね。そもそも。
!! 見られるということ
'''和田''' やはり TDD を学ぶにはプロセス、過程が大事なんです。
TDD で開発された Java のオープンソースのコードはたくさんあります。でも開発されたものを見ても TDD を学べるわけではない、というのが大きいのかなと思ってます。
僕が Web+DB PRESS でゼロから TDD で書いたのは、そういう思いがあったからなんです。
ブログの RSpec の記事{{fn('[[http://d.hatena.ne.jp/t-wada/20100228/p1|http://d.hatena.ne.jp/t-wada/20100228/p1]]')}}でもゼロから始めていて、差分をひたすら見せるというスタイルです。これも過程を追体験してもらいたいな、という思いからきています。
Web+DB PRESS の記事も、ブログに書いた RSpec の記事も、書き方のスタンスは基本的には変わらないんです。
まず、頭の中で伝えたいことのプロットを引いて、その順番になるように、一回一回シナリオごとにブランチ切りながらサンプルコードを書いてみる。
一番うまく説明できるサンプルになったとき、起点になるところから最後までを、git log とか svn log とかで一本につないで、その間の差分を diff 形式でばーっと取っていく。
そうすると基本的にコミットコメント・diff・コミットコメントという構成になるから、そのコミットで伝えたいことを本文に埋めていく。
説明したいことに対してきちんと対応付いているサンプルコードとその差分から整理する、という見せ方をすることが多いですね。
'''大中''' 関連する話なんですけど、テストを駆動させてテストを成長させていく動機付けになるのって、やっぱり Jenkins とかでテストケースが増えてるとか、カバレッジが順調に増しているとか、そういうテストが育っていることが分かる、というのがあるのかなと。
'''和田''' テストコードを書いていくモチベーション、なるほど。
'''大中''' 紙とか文書ベースだとそういうところを見せていくのが難しいので。
'''和田''' たしかに。
'''大中''' 例えば Jenkins とかで 100 件テストがあって 2 件 RED があったら、なんとか潰して全部 GREEN にしたい、となりますよね。
'''和田''' TDD というものを伝えることに関して、紙の本という媒体があまり向いていない、という側面はあるかもしれません。
僕が Web+DB PRESS の Vol.35 で動画企画をやったじゃないですか。
「TDD をどういう順番でやっていて、どういうことを考えて、どういう書き順でコードを書きました、というのを動画で見てもらう」企画を立てたんですね。Vol.35 と Vol.37 で。
Vol.35 のとき{{fn('[[http://gihyo.jp/magazine/wdpress/information/2006/vol35-tdd|http://gihyo.jp/magazine/wdpress/information/2006/vol35-tdd]]')}}はスクリーンキャストを録った後で、声を別録りしたのですごい大変でした。
Vol.37 のとき{{fn('[[http://gihyo.jp/dev/serial/01/tdd|http://gihyo.jp/dev/serial/01/tdd]]')}}は、逆にしゃべりながらライブコーディングなのでミスができない一発録り、どっちもどっちで大変でした。
Vol.35 の時は映像編集の方がすごい頑張ってくださったんですけど、もう一回は難しいから Vol.37 ではしゃべりながらやることになったんです。
'''大中''' ペアプロとか TDD とか結構デモって難しいですよね。
'''和田''' デモは難しい。やっぱり経験とか、練習とか、度胸とか、いろいろ必要なのでやっぱり一発でデモって大変ですよ。すごく緊張します。
'''大中''' ペアプロのデモで、ペアプロを実践している人でもうまくいかない場合がありますからね。
'''和田''' そうですね。デモは難しい。人前でコードを書くという経験はすごい強烈なので、練習をしないで壇上に立つと頭真っ白になりがちですね。
'''おかざわ''' それのミニマムがペアプロですよね。
'''和田''' そう。だからペアプロですら、すごく緊張する。
自分がコード書いてるところは、人に見られるものではないという感覚はすごく強い。
プライベートなものなので、それが常に見られているのはプレッシャーを感じますよね。
見られてないと人間真面目に仕事しないというところもあるので、ペアプロの経験はすごい成長の元になると思います。
講演もそうだし、ブログもそうですね。
!! 「主催者始めました」
'''おかざわ''' 和田さん自身地方で講演して回ったりとか、デブサミで発表したりというのは糧になっていますか？
'''和田''' 糧になっています。アウトプットするとインプットが増えますし、人からの反応もたくさん来ます。
'''おかざわ''' 懇親会などで直接会話された中で印象に残っているお話などありますか？
'''和田''' 福岡の主催者の [[@pocketberserker|http://twitter.com/#!/pocketberserker]] さんは、佐賀から名古屋に来ていて。
勉強会初参加が TDDBC 名古屋だったらしいのですけど、それがすごい強烈な体験になったと聞いています。
名古屋には関数型の人はいるし、ペアプロはやるし、夜はホテル借り切って修学旅行みたいにハッカソンやるしで。
地方の TDDBC は 2 日間コースなので、基本宿を借り切ってやるパターンが多いんですね。
そうすると、夜も普通にみんな集ってプログラミングしたりするので、2 日間構成ならではの体験ができます。
東京でもできたら面白そうですけど、そういう土地柄でもないのかなと思わなくもありません。
'''大中''' 横浜でやったときも考えたんですけど、2 日間コースだとやはり参加費とかが跳ね上がってしまうのが。
あと、土日両方やるとなると敷居が上がるというか。
'''和田''' 上がります。上がりますね。
!! TDDはユーザの価値に寄与するか？
'''杉野''' 「TDD がユーザーにとっての価値を提供できているのか実感できているか」という質問があるのですが。
'''和田''' 基本的に TDD が寄与するのは「内部の質」に関するものです。
直接お客様にフェイスするところかというと、そういうところもあるけど、それよりは、書いてきたものに対して自信を持つことができるということのほうが重要ですね。
TDD はリファクタリングが常にセットじゃないですか。
一定速度、自分達が予測できるスピードで価値を提供し続けることができるところに、お客様に対する TDD の価値があります。
基本的には、お客様に「テスト駆動開発やってます」と胸を張って言うことではないんですよね。
どちらかというと「プロだから当然やってますよ」という話です。
自分達が書くコードに対して技を尽くしてますよ、という話なのだと思います。
お客様 (エンドユーザ、受託開発) に対して、「テスト駆動開発やってます」ということを売りにするということは、そんなにありません。
でも、言われることはあるんです。僕に仕事がくる場合「テスト駆動開発でやってください」と言われるのは多いんです。僕宛てに来た仕事なので、構図としてそうなっている側面はありますね。
'''大中''' 自分の感想ですと、シビアな仕様変更とかがあっても、デグレ無しでスパンといけちゃうとかは。
'''和田''' テストコードがあってよかったなと。
'''大中''' そうですね。TDD によって価値を提供できているなと。
'''和田''' そうですね。
急激な仕様変更、急激なリリースであるとか、プレッシャーがかかる局面になると、人間は視野がぐっと狭くなって、自分の頭でチェックできる領域がすごく狭くなってしまいます。そのようなときに、それまでにやってきたことを機械が実行して助けてくれるというのが、テスト駆動開発を行って、テストコードを用意してきたことの大きい御利益が得られる瞬間ですよね。
また、開発期間が長くなったりすると隅々の仕様やテストコードについて覚えていなくても、何かを変えてどこかのテストコードが落ちれば、これまでと動きが変わったというのがはっきり Yes/No で分かるのも、自信、安心に繋がりますね。
!! Microsoft が TDD でバグ9割減
'''杉野''' 「Microsoft が Visual Studio の開発 に TDD を適用したらバグが 9 割減った{{fn('[[http://www.tdd-net.jp/2009/12/tdd-boot-camp-3.html|http://www.tdd-net.jp/2009/12/tdd-boot-camp-3.html]]')}}」という話についてのは正直どう思いますか？
'''和田''' あとで調べてみたんですけど、Visual Studio のアーキテクチャの大規模な立て直しのプロジェクトだったらしくて、割と本腰を入れてやってたらしいんですね。
バグ 9 割減ったというのは相対値の話なので、それまでみっちりテストをやっていて出ていたバグ数が、そもそも出なくなったって話なのかとか、そのへんをちゃんと考える必要はあります。
あとは、対象が複雑ということもあります。開発ツールなのでたくさん状態を持っているだろうし、たくさん振る舞いをもっているだろうし。
そういうものに対してボトムアップでひとつひとつの部品の完成度を高めて、それらの組み合わせ自体のエラーの混入率を一気に減らした、という効果なのではないかと思います。
'''おかざわ''' 9 割っていうのが、どこの数字を拾って 9 割なのかっていうのがあるかもしれないですね。
'''和田''' そうそう。
'''大中''' ある意味でいうと出てるんだけど、いわゆるテストフェーズ前のコーディング時点でもう潰しちゃっているかもしれない。
'''おかざわ''' 今言われた、単体レベルの数字も含めて 9 割だよっていうのと、結合レベルで 9 割減ってるっていうのは違いますよね。まぁ、そこは邪推なので。
!! テスト駆動開発者は三周目に死ぬのか
'''おかざわ''' それで、2009 年のオブラブ{{fn('[[http://www.objectclub.jp/event/2009summer/session.html|http://www.objectclub.jp/event/2009summer/session.html]]')}}で発表されてた資料{{fn('[[http://www.slideshare.net/t_wada/emergent-design-oblove-2009-summer|http://www.slideshare.net/t_wada/emergent-design-oblove-2009-summer]]')}}を見せて頂いて疑問に思ったのですが、TDD で開発したシステムが死ぬというのは、アーキテクチャ的に死ぬということでしょうか？
'''和田''' ボトムアップで設計したものがアーキテクチャ的にどん詰まりになるということを言っています。
例えば、小さい部品を組み合わせてテストコードもちゃんと動いてるんだけど、テストコードは基本的にシングルスレッドの世界として書いてしまうことが多いですよね。
マルチスレッドで動かないとか、いざ本番で実際のリクエストに晒してみるとパフォーマンスが悪い、といったことが出てきてしまうので、「ちゃんとアーキテクチャを事前に設計すべし」という意見が出てきたりするんです。
テスト駆動開発やアジャイル開発、オブジェクト指向設計の文脈でよく話題になったり、批判されることでもあるんですけど「高いレベルのメンバーじゃないとできません」という意見がありますよね。
ペアプロ時もそうなんですけど「暗黙の設計」は、あります。
どうしても、個々人の差とか、どのぐらい設計のゴールが見えて TDD やっているのかというところは、やはり経験の差だとか能力の差が出てくるところではあります。
その上で、ではなぜ TDD をやっているかというと、作っていくうちに最初思い描いていたゴールから微調整が必要だとか、やってみて初めてわかることが多いんですね。
最初からきちんと設計してその通りに実装すれば上手くいくかというと多分そうではないし、でも無から完全にボトムアップで組み上げていったら、たぶん全然違うところへたどり着いてしまう。その中間に良い設計というのがあるんじゃないんですかね。
'''大中''' TDDBC 横浜のときにちょっと失敗したことなんですけど、課題を小出しにしたんですよ。
それはそれで、一つの問題に集中するという効果はあるんだけど、その上で、実際の仕事で何を作るかというところを、その場その場で小出しにして判断していくというデザインの仕方が本当に正しいのかどうかというと、ちょっとそれも違うなというのがあって。
'''和田''' はい。
'''大中''' 何を作るのかというのが見えているんだったら、それはそれでオープンにしておいた上で、進んでいくところで見つかるズレをどうやって調整していくか、という対応がよいのかなと思ったんですよね。
'''和田''' そう。横浜のときと C++ のときは課題を小出しにするスタイルで、それは目の前のことに集中できるという良い効果と、全体像が見えにくいという良くない効果と、その二つの効果があったと思っています。
別のイベントを開催をするときは別のやり方でやってみればよい、という有用なフィードバックだと思うんですよ。
僕がよく TDD の講演の中で言っているように、現実の問題は複雑でデカイじゃないですか。
それに対して一気に立ち向かおうとすると敵が大きすぎてやっぱり手が止まるんですよね。
だから、ある大きいゴールを達成するためには、小さいゴール。
これとこれとこれとこれができれば大きいゴールに到達できる、というように、はしごを掛けていかないといけない。
大きい問題を小さい問題に分解するというのは、ストーリーをタスクに分割するという話や、タスクをさらに小さいタスクに分割することや、 GTD {{fn('Getting Things Doneのこと。[[http://ja.wikipedia.org/wiki/Getting_Things_Done|http://ja.wikipedia.org/wiki/Getting_Things_Done]]')}}の世界にも通じる汎用的な話ですよね。
問題の分割には練習が必要です。
大きいゴールを提示するとそれを小さいゴールの連続に分解できない人はやはり多いです。
というか、訓練しないとなかなかできるようにならない。
'''おかざわ''' C++ のときは、最終的に経路探索をして路線の料金計算ができちゃうような主題に対して、そこから問題をだんだん分割しててそれぞれに課題をつけていくというやり方をされていました、途中で井芹さん{{fn('[[http://d.hatena.ne.jp/goyoki|http://d.hatena.ne.jp/goyoki/]]')}}が講演資料を作ったら、各課題とテストの設計が課題として設定されるようになって、結局 10 段階ぐらいになったんですっけ？
'''和田''' 10 問ぐらいになってますね。
'''おかざわ''' タスクとしては分割されていて、かつテストの観点も同時に含まれていたのですが、最後のゴールが見えず途中でアルゴリズム大会になってしまった。
'''和田''' そうですね。現実問題としては、全体を見ながらという、複眼視が必要ですね。
全体を逃さないようにしながら、でも目前のものに集中してやっていった方が効率がよい。
だから、遠くのゴールを片目で見ながら、そこにたどり着くために近くのものを小さく設定して倒していく。
'''大中''' それにどうやって立ち向かっていけばいいのかって考えるときにたどり着くのって、やっぱり Kent Beck の『テスト駆動開発入門』のタスクリストを出して、ひとつひとつ立ち向かっていくっていうやり方に近づいていく。
'''和田''' 近づいていきますよね。
大きな講演の度に、『テスト駆動開発入門』や『リファクタリング』を読み直すんですけど、いっぱい走っても結局 Kent Beck の手のひらから出ていない、 Ward Cunningham の手のひらの上を出ていない、という感覚になります。
なんかこう、お風呂の中で TDD 本を読み直していて、「ああ、結局ここに書いてあるじゃん」ってなりますね。
TDD 本と『リファクタリング』の最後の一章（第 15 章）は Kent Beck が書いているんだけど、そこにだいたいすべてのことが書いてあるので、「ああ、また俺は手のひらの上か」みたいな感じがすごく出てしまいます。
'''おかざわ''' xUTP 本{{fn('書籍 "xUnit Test Patterns" の略称。[[http://www.amazon.co.jp/dp/0131495054/|http://www.amazon.co.jp/dp/0131495054/]]')}}の中にパターンとして記載のあった INSIDE OUT と OUTSIDE IN についてさんざん議論したじゃないですか。{{fn('xUTP本の読書会でとりあげていた重要ポイントに触れずに、xUTP本の前の世代の本になる『テスト駆動開発入門』まで遡っていることを指摘している。')}}
'''大中''' それ、俺に言ってる？（苦笑）うん、でも確かに、 OUTSIDE IN と INSIDE OUT の考え方は重要。あれでテストに対する考え方が変わった。
'''和田''' ほう。
'''大中''' 僕の場合、あれ読んでからしばらくは INSIDE OUT に寄り過ぎていて、テストは書いたんだけど、コンポーネントとして組み合わせると動きませんとかそういうのがあって。ようやっと、この前のプロジェクトで方向転換できたかなというとこなんですけど。
'''和田''' 画面に近い、要するにユーザに近いところから作り始めるやりかたですね。例えば受け入れテストとか、いわゆる MVC でいうとコントローラやビューから作って、内側をモックにして、要求の方から作っていって中に攻めていく方針が OUTSIDE IN というテスト戦略。
そうじゃなくて、抽象的な部品とかモデルレイヤから作っていってボトムアップで攻めていくのが、INSIDE OUT 戦略。
Kent Beck や Fowler がやってた 2000 年ぐらいの TDD の姿と、その後の Steve Freeman とか Nat Pryce とか goos の人たちがやりだした TDD との大きな違いというのは、「向き」が出てきたということですね。
Kent Beck がやっていたのは、抽象的な話で、「テストの向き」という概念は基本的に無かった。
それに対して、モックオブジェクトを作った Steve Freeman と Nat Pryce は、モックオブジェクトを使うことで、テスト駆動開発自体は、開発する要求や対象の世界を自分たちが理解していく上での設計ツールになり得るし、設計の時間を制御できることに気づいたんですね。
最初から全部を理解するのではなくて、その人たちのソフトウェアに対する理解をだんだんと、見えている外側の界面から中側に向かって攻めていくことができる。
それまでは、実装がないとテストができない、実装がないとインテグレーションもできない、という状況でした。
それが、オブジェクト指向言語とモックオブジェクト (テスト用の偽物) という道具を組み合わせてテストに使うことで、決まっているところはともかく、決まっていないところでも実装のことを考えずに外側から決めていくことができるようになったことに、テスト駆動開発をやっている一部の人たちが気がついたんです。
それが OUTSIDE IN 戦略。
システムに対してテストする方向もそうだし、時間でもあるんですね。
外側から先に作っていくという話なんです。学びと時期をテストで制御する。
!! パターン厨のはしか
'''和田''' モックオブジェクトには良いところも悪いところもあります。モックオブジェクト自体はメンテナンス対象になるから、例えばモックオブジェクト自身がリファクタリングを妨げてしまうような状況を避けるための設計をしなければならない。
デザインパターンが出たときに、みんなデザインパターンを学んでデザインパターンを可能な限り使おうとしたじゃないですか。
シングルトンパターンを憶えたらみんなシングルトンオブジェクトにしちゃったりとか。なりましたよね？
'''大中''' なりますね。（苦笑）
'''和田''' だから、あれは麻疹なんですよ。デザインパターンもそうだし、モックも。
大事なのは、モックをすごいと思ったら、一度モックをばあーっと使ってみるということ。
そうするとモックのメンテナンスコストとか、モックは結局自分の妄想に過ぎないという現実に直面して、元の世界に戻ってくる。
RTP、"Refactoring to Patterns"（邦訳『パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法』）の中に patterns happy という、「パターン大好き」みたいな言葉が出てきて、かくたにさん{{fn('角谷信太郎さん [[http://kakutani.com|http://kakutani.com]]')}}と「これどうやって訳す？」って話してて、「これやっぱり"厨"じゃないか？」って話をしていたんですけど。「パターン厨」。
'''一同''' わははは。
'''和田''' モック厨。中二病っぽい。強い技術というのは人をぐっと引きつけるし、オーバーユースするときがある。
それで、これは使いすぎたなぁといって元の場所に戻ってくる。
その真ん中ぐらいにちょうどいいバランスがある。
だから、早めに羅漢しましょうという話なんですよ。
厨を呼ぶ技術は良い技術であることが多いし、早めに触れて、早めにちょうど良いバランスを見つけましょう。
『パターン指向リファクタリング入門』はすごくいい本ですよ。著者の Joshua Kerievsky はよくわかっている人です。（手元の iPad を見つめて）ああ、「パターン魔」って訳されてますね。なるほど。
'''大中''' ここでいう「ハッピー」って、どっちかっていうと「ハイテンションになる」っていう意味でしょうか。
'''おかざわ''' 『アドレナリンジャンキー』的な{{fn('[[http://www.amazon.co.jp/dp/4822284018/|http://www.amazon.co.jp/dp/4822284018/]]')}}。
'''和田''' そうそうそうそう。
!! お風呂で本を読む
'''杉野''' さっきちょっと言われてましたけど、お風呂の中でも本読まれるんですね。
'''和田''' 読んだりしますよ。iPad で読むことも多いんですけど、疲れてくると画面から離れてみたくなります。紙と鉛筆で考えたい。いいアイデアって散歩中とかお風呂に入っているときとかに浮かびがちですよね。
!! TDDBC にこれから参加する人と既に参加した人へ向けて
'''おかざわ''' TDDBC にこれから参加しようと思っている人と、もう参加した人に伝えたいこと、目標としてもらいたいことをお願いします。
'''和田''' 参加したい人は、怖くないので気軽に来てくださいと言いたいです。まぁ、未だに倍率が高いのが悩ましいんですけど…。
でも、体験からしか学べないというわけではないです。
僕は TDD は基本的に自習できる{{fn('和田さんによる技術書の写経の仕方 [[https://twitter.com/#!/t_wada/statuses/9000231741|https://twitter.com/#!/t_wada/status/9000231741]]')}}と思っています。ですけど、コードレビューやペアプロは他者がいないと成立しないので、そういう空間、非日常の異空間を用意するというのが、TDDBC のひとつの舞台装置としての効果であると思っています。そういう体験はとても強烈なので、ぜひ体験して欲しい。
参加したいと思って確実に参加できる手段は「自分で主催する」ことなので、小規模でもいいので、何かいろいろやってみるというのがいいんじゃないでしょうか。ぜひ気軽に相談してください。
TDDBC に参加した人に対して伝えたいのは「自分で咀嚼して自分の言葉にして伝える」ということ。
実際、人に伝えようとして初めてわかることがすごく多いんです。
コンサルティングの現場でも、お客さんの話を聞いてから自分で言い直して返す、というのが基本テクニックじゃないですか。
人に対して説明してみようと思うときに、初めて自分の中で再構築されて理解が進むのだと思います。
自分の会社に戻って、TDDBC で体験したことを隣の人に伝えてみるとか、部署内で勉強会をやってみるとか、そういう機会をつくって自分が教える立場になると、自分が一番学ぶことができます。
自分が何を学んだのか、ということを、今度は人に伝える側になっていただけたら嬉しいなと思っています。
まとめると、これから参加する人は怖がらないで来てみてね、というのと、参加した人は学んだことを日々の行動に還元するとどうなるかを考え、人に伝えてほしいということですね。
あと最後に、テスト駆動開発は自分ひとりで続けていけるものであり、こつこつと練習することが上達につながります、と重ねて言いたいです。
!! 好きな女性のタイプ
'''おかざわ''' 好きな女性のタイプは？
'''和田''' 奥さんです。
'''杉野''' どんなところが？
'''和田''' 好奇心が強いところですかね。奥さんが自分がやってることに興味を持ってくれるところです。
!! xUTP読書会が2年続いた理由
'''おかざわ''' xUTP読書会{{fn('xUnit Test Patterns(xUTP)読書会 [[http://www.fieldnotes.jp/xutp/|http://www.fieldnotes.jp/xutp/]]')}}ってなんで 2 年間も続いたんですかね？
'''和田''' 本が分厚いからじゃないですかね。
'''おかざわ''' 他にも分厚い本を前に自然消滅した読書会を知っているので、そこが不思議に思っています。。
'''大中''' xUTP 読書会って何で最後まで終わったかというと、一番大きな原因っておかざわさんが加わったからでしょ？
'''和田''' そう。そうだと思う。
xUTP 読書会がなぜ完遂できたかというと、おかざわさんが途中で「おかざわブースター」として入ったというのが大きい。
やっぱり一定出力でアウトプットをし続けられる人が会の存続に必要ですよね。
'''おかざわ''' へえー。
'''大中''' 僕、けっこうムラっけあるんで。
'''和田''' ムラっけ、あるある。
後は、継続するのに月イチぐらいがよいテンポなのかもしれないですね。xUTP 読書会の母体となった『RESTful Webサービス』{{fn('[[http://www.amazon.co.jp/dp/4873113539/|http://www.amazon.co.jp/dp/4873113539/]]')}}の読書会{{fn('RESTful勉強会 - RESTful読書会 [[http://kunit.jp/restful/wiki/|http://kunit.jp/restful/wiki/]]')}}からですかね？
'''大中''' 母体では無いけど、そうか、きっかけはそうなんですね。
'''和田''' きっかけにはなったけど、メンバーは母体にはなってないか。
'''大中''' 『RESTful Webサービス』の読書会に僕が参加して、帰り道に和田さんに「レガシーコード本の読書会をやろうと思うんですよ」って言ったのがきっかけなんですけど。
'''和田''' おおー、そうだった。
'''おかざわ''' たしか和田さんのブログでコメント欄が燃え上がった{{fn('[[http://d.hatena.ne.jp/t-wada/comment?date=20080224#c|http://d.hatena.ne.jp/t-wada/comment?date=20080224#c]]')}}のが。
'''和田''' あー、ブログもきっかけかもしれないですね。「読書会フラグですね」みたいな。
'''大中''' コメントが 40 個以上ついたのが。あれひどかったよなぁ。
'''和田''' レガシーコード本のときはサイボウズ・ラボの中谷さんに会場をお世話になったし、勉強会/読書会には定期的に場所を提供してくださる方と定期的にアウトプットしてくれる方、その二人が大事ですね。
'''大中''' その二人が揃えば、まぁ、勝利ですね。
'''和田''' レガシーコード本のときも xUTP のときもそうだったけど、毎回場所を探すのは結構きついですよね。
毎月開催できる場所を手に入れるのが、定期的に開催する読書会に必要なパターンですよね。
で、僕が参加し続けてたのはなぜかというと、まぁ、基本的に好きなことだったからだと思いますよ。
'''おかざわ''' 一通り読んだ上でやっぱり参加されてるじゃないですか。
'''和田''' ざっくりとは読んでいるんですけどね。読書会はもっと深く読み込むからやっぱり理解も違ってくる。
goos本の読書会もみんな訳してきてくれたりするので、怖がらずに来てくださいねというのは言いたいです。怖くないです。
!! ぺけま Vol.1 はぶっちゃけ何点？
'''おかざわ''' 最後にひとつだけ。初回のぺけま、とりあえず xUTP の裏表紙にあるパターンを全部概略付きで、手抜きなんですけど（笑）、載せてたりとかするんですけど、 5 点満点で何点？
'''和田''' えー。
'''おかざわ''' 「俺はこんなもん求めてねえよ、俺が求めてたのはこのぐらいだよ」とか。
'''和田''' 5点満点でいうと…。じゃあ、 4 点。
'''大中''' おおー。
'''和田''' 5点満点というと、これがマックスなのかみたいな話になっちゃうから。
巻頭言もかなり熱い感じになってたし、xUTP 本を概覧するという最初のまとめ記事もすごい力が入ってましたよね。
有志のクオリティでこれを続けるのは難しいところなので、どうやって人を巻き込んでいくかとか、読者を増やすかといったことが、定期的に、不定期でもいいと思うんだけど、これだけのアウトプットを続けるために重要になりますね。
やはり Web 媒体って、紙媒体と違って編集しやすいし、修正しやすいし、フィードバックが得やすいし、技術的な情報を発信するのに向いている媒体だと思います。さっき言われていたように、Java の情報が足りないのであれば、 Java の情報をぺけまでやっていけばいいだろうし、ニーズのあるものを書いていく、そういう媒体として育てばすごいなぁと思います。
実際今日(収録日)もたくさん反応がありました。今日僕がはてぶを Twitter に投げたら多くの方に RT されたんです。{{fn('[[https://twitter.com/#!/t_wada/status/137084843103223809|https://twitter.com/#!/t_wada/status/137084843103223809]]')}}
'''杉野''' されてましたね。
'''和田''' 僕がはてぶ投げ忘れてて、今日がちょうどいいタイミングだと思って投げたらバーンと 22 RT。
!! ぺけま公開の裏側
'''和田''' ぺけま第一回出たのって 4 日ぐらいですよね。
'''大中''' だって、あれ TDDBC 横浜当日( 2011 年 11 月 5 日)ですよ。和田さんが基調講演している最中に公開したという（笑）。
'''和田''' あれでタイミングを失っちゃったんですよ（笑）。はてぶで 1 ゲットしようかとしていたら、俺が喋ってるところで公開。
'''一同''' 爆笑。
'''大中''' あれ、僕が朝イチで公開しようと思ってたら、編集がまだ終わっていなくて（笑）。
'''和田''' そういうことだったのかぁ。
'''おかざわ''' 間違いを指摘してくれる人がいて、ちゃんと読んでくれてる人がいて嬉しかったです。
!! フィードバック募集してます
'''和田''' フィードバック募集をどうするかですね。
'''大中''' メールアドレス作るのはできるんだけど、さて、どこに流せばいいんだろう。
'''和田''' [[#xutpハッシュタグ|https://twitter.com/#!/search/%23xutp]]をつかってもらうとか、 公式ハッシュタグってどうしますか？
'''大中''' あと、イイネボタンとかも押せるようにしたいんだけど、あれどうやればいいんだろう。
!! お友達を紹介
'''和田''' これで次の人にバトンタッチするとかあったりするんですか？
'''大中''' なんも決めてないです。
'''杉野''' 指名するんですか？
'''和田''' どうなんだろ？誰のインタビューをやりたいとかあったりします？
'''大中''' 僕がぼんやり思っているのはこんぴろさんなんですけど。
'''和田''' ああー、それは面白いな。
'''大中''' オンラインのインタビューになりますけどね。福井なので。
'''和田''' そうか、最近物理的に見ないと思ったら福井にいるのか。
'''大中''' 福井で TDDBC を開催して福井に行くって手はありますけどね。発行がイベント駆動なので。
'''和田''' 締め切り駆動は大事ですよね。アジャイルにやるというかデリバリは決まっているからスコープを落としていくっていう。
'''一同''' 笑。
'''和田''' 今回は二本しかありませんっていう。それは面白いかもしれないですね。
僕がこれまで書いた文章とか色々ぺけまに寄稿していければなって思います。
!! インタビュアーも募集してます
'''おかざわ''' 誰がインタビュアーをやるかっていうのもあるんですけどね。
'''和田''' 僕がインタビュアーの側にまわっても面白いかもしれませんね。
'''おかざわ''' 和田さんがインタビューしたい人ってのもいいかもしれませんね。
'''大中''' 僕が Twitter に「和田さんにインタビューしたい人いませんか？」と書いたら、おかざわさんが「それ群がってきたらどうすんですか」って言ってたけど、僕はまぁ、なんとかなるさと思っていたら、ちょうど杉野さんが。
'''杉野''' 僕が釣れたっていう。
'''大中''' ちょうどいい感じになった。
'''和田''' katzchang さんとか bleis さんとか、最初に TDD Boot Camp のきっかけを作ってくださった人達とか、goyoki さんたちの話が聞きたいなと思いますね。
'''おかざわ''' そのあたりは調整させていただいて。
'''和田''' はい。
'''おかざわ''' というわけで、ありがとうございました。
'''一同''' ありがとうございました。
xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。
栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。
こちらは後編となります。[[前編はこちら|0002/Hotlinks]]
! 和田卓人さんのプロフィール
""和田卓人（わだたくと）
""
""タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めようと努力している。今日もグリーンバンド（テスト駆動開発者の証。ボブ・マーティンが始めた）を左手に着け、テストと共にコードを書いている。
""
""Blog：http://d.hatena.ne.jp/t-wada
""Twitter : [[@t_wada|http://twitter.com/t_wada/]]
http://devtesting.jp/image/t_wada.jpg
!! TDDBC の波及効果
'''大中''' TDDBC の参加者から聞いた話で、「ウォーターフォールだとテストファーストくらいしかできないけど、設計時点でテストしやすさを意識するようになった」という話があるんですね。
おかざわさんは「プラクティスとしての TDD からは外れているんだけど、TDDBC を通じて得られるものは TDD 以外にも影響するんだな」と言っていました。和田さんは参加者から得られる感想などで印象に残ったことはありますか？
'''おかざわ''' 参加者から直接フィードバックを得られる機会はあるのかなぁと。
'''和田''' 一番多いのは Twitter とか Blog ですね。 #tddbc のタグ付きでも無しでも。あとは TDDBC でグリーンバンドを配っているじゃないですか{{fn('2010 年の TDDBC 名古屋で「テストを書くのはつらい。 Bob Martin もグリーンバンドを身につけて、自分を戒めてるんだ」というエピソードが紹介されたことから、TDDBC 参加者で共同購入する活動が始まった。')}}。参加された方が後日グリーンバンドを付けているところを見ると嬉しいですね。すごく。
みんな現場に帰ってやってるのは『レガシーコード改善ガイド』{{fn('[[http://www.amazon.co.jp/dp/47981168311/|http://www.amazon.co.jp/dp/47981168311/]]')}}の世界だったりするので、そういう現実に対する立ち向かい方も含めて、学ぶポインタになる、きっかけになるイベントとしてやっていけるといいなと思っています。
TDDBC の理念、やりたいこととしては、テスト駆動開発だけじゃなくて、ペアプログラミングと、一つの課題を他の人はどう解くのかというのを見てもらうコードレビュー。この 2 つはすごく重要かつ強力で、しかし現場ではなかなか導入されないプラクティスだと思っていて、コードレビュー、ペアプログラミングを強制的にでも体験できる場を作りたかった。
でも参加者一人一人は月曜日に現場に戻ると個人戦の世界になってしまう。
テスト駆動開発はやはり個人のプログラミングスキルだと思っているので、『テスト駆動開発入門』{{fn('[[http://www.amazon.co.jp/dp/48947171151/|http://www.amazon.co.jp/dp/48947171151/]]')}}とか『レガシーコード改善ガイド』とか、一人で成立し得るスキルとして学ぶためのきっかけを掴んでもらう場にしたいと思ってやっています。
参加後に『レガシーコード改善ガイド』とか『テスト駆動開発入門』を買って勉強していたり、グリーンバンドを左手に付けているところを見るとすごく嬉しいですね。
!! TDD "Boost" Camp
'''大中''' 話は変わるんですが、"Boost Camp"という話があるじゃないですか。
'''和田''' TDDBC に参加した人が、その後でもう少し実践的なイベントをやりたい、という話ですよね。
'''大中''' はい。
'''和田''' 札幌ですでに Web アプリを TDD でつくるという実践的なテーマをやっていて、これは東京でもやりたいと思っています。それが Boost になるかどうかは分からないですけど。
イベントとしての TDDBC についてですが、テスト駆動開発は未だに啓蒙段階だと思っています。ペアプログラミングも、TDDBC で初めてやったという方が圧倒的に多数ですしね。 TDD やペアプロの初心者の方々に体験できる場を提供するのは、Boot Camp として続けたほうがいいんじゃないかと思います。
たとえそこで僕が講演をしなくても、イベントとしての TDDBC はまだニーズがあるし、続けていけたらと思います。
その後の応用編としては、母体となるコミュニティがある場合は、そこでやれば良いのではないかと思います。
'''和田''' TDDBC が他のイベントと違ってやや特殊なのは、プログラミング言語を跨ぐ傾向が強いところですね。実はこれは第一回から折り込み済みでやっているんです。
同じ問題を別の言語でどうやって解くのかを知ることは体験としてすごく面白いので、大事にしたいなと思っています。
'''和田''' 最近では TDDBC for <言語> も開催されていて、あれは良いところもあったし、本当は別の言語も見てもらいたいなと思うところもあって、個人的には悩ましいところです。でも、例えば「PHP のイベントだから参加した」「C++ のイベントだから参加した」という人が明らかにいるんですね。
'''一同''' うんうん。
'''和田''' 言語しばりのほうが参加しやすい人もいるし、そこはこれからも考えていきたいなと思っています。
'''杉野''' カフェでペアプロするとか、ちょっとしたものが欲しいですね。
勉強会をばーんと立ち上げるんじゃなくて、僕はまだ行ったことがないんですけど、Asakusa.rb{{fn ('東京下町を拠点とする地域Rubyistコミュニティ。[[http://qwik.jp/asakusarb/|http://qwik.jp/asakusarb/]]')}} みたいに、まずは定期的に集まるというような。
'''和田''' とりあえず場だけあると。
'''杉野''' そういうふうにやったほうが面白いんじゃないかって少し案を考えています。
'''和田''' Boost Camp もそうやったらいいかもしれませんね。各々分かれて研鑽を積むために。
東京でまだ TDDBC に人がたくさん集まるのは、そういう「場に集まる」性質があるのかなって思います。
長く主催者がいなかったというのも関係してるのかな。
'''大中''' TDDBC Tokyo 1.5 の主催者の大塚さん{{fn('[[http://hiroki.jp/|http://hiroki.jp/]]')}}とはどういうきっかけで？
'''和田''' あれは、「東京で TDDBC 2 をやる企画はあるんですか？」というのを何かで聞かれたのがきっかけです。
TDDBC 東京 2 はまだ実現していないんですけど、冬か来春にやろうみたいな企画はあったんですね。
それで、「あるんだけどかなり先なんですよ」と返事をしたら、「小規模でいいからやることはできますか？」と質問されたんです。
'''和田''' 「主催者の言ったもの勝ちだからどんどんやりましょう」と話をしていたら、1.5 という謎のバージョン番号が始まったんです。
'''大中''' TDDBC の緩い合意として、やろうとする人がいればそれを支援するよ、というのがありますが、それが伝わっているのかどうか。
'''和田''' 伝わりが甘いですかね、やっぱり。
'''大中''' どうなんですかね。
'''和田''' それはやはり問題点ですね。ポータル{{fn ('[[http://devtesting.jp/tddbc/|http://devtesting.jp/tddbc/]]')}}も大中さんの力でやっとできたくらいだし。
参加したいという人はいるけど、主催できると思っている人が少ないんじゃないかという思いはありますね。
'''大中''' うーん。
'''和田''' 地方に行くと、基本的にコミュニティの大きさ自体は小さくなるので、気心が知れて勉強会をやりやすいというか、勉強会に出やすいというのはあると思うんです。
東京は圧倒的に人が多いので、むしろ分散化の傾向が強いような気がします。
'''大中''' コミュニティとしてもそうなんですけど、都市としての規模も桁違いなので。
都市部で公的施設を押さえるとなると半年くらい前から予約が必要なんですよ。
'''和田''' 会場の問題はありますね。自社開催とか、会社を休日に貸してくださるとか、そういった支援がないと。
公的施設を借りるとなると東京は早めに準備しないといけないし、しかも料金は高い。札幌は非常に安くてびっくりしましたもん。それはあるなぁ。
そうすると、1.5 の時もそうでしたが、どこかの会社の会場を借していただいた場合には、相対的に箱は狭く小さくなるので、参加倍率はどうしても高くなってしまう。
でも、あんまり人を増やしすぎてもイベントとしての質を保ちにくいだろうなぁとも思っています。
'''和田''' ただ、開催を焦る必要は無いとも思っていて、まだ待ってる人がたくさんいるからもっと頻繁にやらなきゃとか、そんなに思い詰めなくてもいいんじゃないかと考えています。待てないなら自分で勉強すればいいだけだし。
'''おかざわ''' 勉強というところで出てくるのが、『テスト駆動開発入門』についての評判が分かれるところがある。
'''和田''' はい。
'''おかざわ''' 原文も独特だという。
'''和田''' 原文はかなり独特ですね。
'''おかざわ''' 2000 年くらいに出版されたんでしたっけ。
'''和田''' 2002 年くらいだったかな。{{fn ('「テスト駆動開発入門」の原著は2002年出版')}}
'''大中''' そうですね、2002 年か2003 年か。
'''おかざわ''' やはり2010 年代の入門本が必要というか。
'''和田''' それが goos{{fn('[[Growing Object Oriented Software Guided by Test|http://www.growing-object-oriented-software.com/]]。[[jMock|http://www.jmock.org/]] の開発者である Nat Price と Steeve Freeman による、テスト駆動開発によるシステム開発について論じた書籍')}} ですよ、という話になるとは思うんですけどね。
'''大中''' ぺけまも元々は出版プロジェクトだったわけで。
'''和田''' まぁね。本、本なぁ。
'''杉野''' 出版と言えば、5年ぐらい前になるんですが、Web+DB PRESS の和田さんの記事をまとめたものが出るとか出ないとかいう話が。
'''和田''' あれは忙しすぎてまったく文章を書けなくてポシャってしまいました……。
本を書くにはものすごい集中力を必要とするので、本業をやりながらだとかなり負荷がかかりますね。
もっと Web 媒体とかで小出しにできるインフラが無いとつらいかなぁと思いました。
まあ、僕に力が無いだけなんですけど。
'''大中''' いやいやいや。
!! TDDの記事を書くのは難しい
'''和田''' TDD のことを本に書こうとすると結構難しいんですね。
Kent Beck の TDD 本でも、「 Money とか現実には使わないよね」という意見も良く聞きます。
基本的に TDD 本は置き換え可能なパターンの話、TDD の原理・原則といったひとつひとつの所作をどうやって自分の目の前の問題に翻訳して適用していくのかという話なので。
'''大中''' うんうん。
'''和田''' 現実の自分たちが作っている Web アプリであるとか、組み込みソフトなどで TDD をどう実践するかという話を本にしようとすると、分量としては圧倒的に増えてしまう。すると、本質的ではない記述が増えてしまうので悩ましいんです。 Maven の pom.xml を書くだとか、データベースをセットアップするだとか。
'''和田''' TDD のエッセンスに絞って書こうとすればするほど、サンプルは小さくなる必要がある。
そのサンプルが例えばスタックとかになると、まるでオブジェクト指向を哺乳類で説明するみたいな、こんなのは現場では必要とされてない、という話になってしまう。
リアルな方向、データベースとかネットワークとかファイルとか Web とかに行こうとすると、今度はモックとかスタブの話が出てきてしまう。
そういうのは基本的に TDD の、例えば Kent Beck の本であった原則を応用して戦っていくところなんですけどね。
小さいサンプルと現実の世界を結びつけるところがミッシングリンクになっちゃっているという面はありますね。
'''和田''' 生きたサンプルとして Web で公開されているソースコードはたくさんあるし(例えばGithub とか)、洋書ではある現実に即したアプリケーションを TDD で開発するものがあります。
だから、 TDD を分かっている人は日々の開発に応用していけるけど、これから入門する人の間には大きなギャップがある、とは思います。
'''おかざわ''' この前『テスト駆動開発JavaScript』{{fn('[[http://www.amazon.co.jp/dp/4048707868/|http://www.amazon.co.jp/dp/4048707868/]]')}}って本が出ましたよね。
'''和田''' はいはい。
'''おかざわ''' 実際のニーズとしては Java が多いんだけど、Java による TDD の本は 2002 年から出版されていないように思います。
'''和田''' そう言われれてみればそうかなぁ。どうかなぁ。
'''大中''' ソフトウェアテストの本で JUnit を取り上げてるっていうのは何冊かありますが。
'''和田''' それはありますね。
'''大中''' あと、[[@kanu_|http://twitter.com/kanu_]] さんが Togetter でまとめた「TDD の本は売れない」っていうのがありますね。{{fn('[[http://togetter.com/li/139936|http://togetter.com/li/139936]]')}}
'''和田''' なんかそんなのありましたね。どんな結論なんでしたっけ？
'''大中''' 結局「TDD がなぜ受け入れられないか」という話になってしまってましたね。
'''和田''' 本が売れない時代なんですよね。そもそも。
!! 見られるということ
'''和田''' やはり TDD を学ぶにはプロセス、過程が大事なんです。
TDD で開発された Java のオープンソースのコードはたくさんあります。でも開発されたものを見ても TDD を学べるわけではない、というのが大きいのかなと思ってます。
僕が Web+DB PRESS でゼロから TDD で書いたのは、そういう思いがあったからなんです。
ブログの RSpec の記事{{fn('[[http://d.hatena.ne.jp/t-wada/20100228/p1|http://d.hatena.ne.jp/t-wada/20100228/p1]]')}}でもゼロから始めていて、差分をひたすら見せるというスタイルです。これも過程を追体験してもらいたいな、という思いからきています。
Web+DB PRESS の記事も、ブログに書いた RSpec の記事も、書き方のスタンスは基本的には変わらないんです。
まず、頭の中で伝えたいことのプロットを引いて、その順番になるように、一回一回シナリオごとにブランチ切りながらサンプルコードを書いてみる。
一番うまく説明できるサンプルになったとき、起点になるところから最後までを、git log とか svn log とかで一本につないで、その間の差分を diff 形式でばーっと取っていく。
そうすると基本的にコミットコメント・diff・コミットコメントという構成になるから、そのコミットで伝えたいことを本文に埋めていく。
説明したいことに対してきちんと対応付いているサンプルコードとその差分から整理する、という見せ方をすることが多いですね。
'''大中''' 関連する話なんですけど、テストを駆動させてテストを成長させていく動機付けになるのって、やっぱり Jenkins とかでテストケースが増えてるとか、カバレッジが順調に増しているとか、そういうテストが育っていることが分かる、というのがあるのかなと。
'''和田''' テストコードを書いていくモチベーション、なるほど。
'''大中''' 紙とか文書ベースだとそういうところを見せていくのが難しいので。
'''和田''' たしかに。
'''大中''' 例えば Jenkins とかで 100 件テストがあって 2 件 RED があったら、なんとか潰して全部 GREEN にしたい、となりますよね。
'''和田''' TDD というものを伝えることに関して、紙の本という媒体があまり向いていない、という側面はあるかもしれません。
僕が Web+DB PRESS の Vol.35 で動画企画をやったじゃないですか。
「TDD をどういう順番でやっていて、どういうことを考えて、どういう書き順でコードを書きました、というのを動画で見てもらう」企画を立てたんですね。Vol.35 と Vol.37 で。
Vol.35 のとき{{fn('[[http://gihyo.jp/magazine/wdpress/information/2006/vol35-tdd|http://gihyo.jp/magazine/wdpress/information/2006/vol35-tdd]]')}}はスクリーンキャストを録った後で、声を別録りしたのですごい大変でした。
Vol.37 のとき{{fn('[[http://gihyo.jp/dev/serial/01/tdd|http://gihyo.jp/dev/serial/01/tdd]]')}}は、逆にしゃべりながらライブコーディングなのでミスができない一発録り、どっちもどっちで大変でした。
Vol.35 の時は映像編集の方がすごい頑張ってくださったんですけど、もう一回は難しいから Vol.37 ではしゃべりながらやることになったんです。
'''大中''' ペアプロとか TDD とか結構デモって難しいですよね。
'''和田''' デモは難しい。やっぱり経験とか、練習とか、度胸とか、いろいろ必要なのでやっぱり一発でデモって大変ですよ。すごく緊張します。
'''大中''' ペアプロのデモで、ペアプロを実践している人でもうまくいかない場合がありますからね。
'''和田''' そうですね。デモは難しい。人前でコードを書くという経験はすごい強烈なので、練習をしないで壇上に立つと頭真っ白になりがちですね。
'''おかざわ''' それのミニマムがペアプロですよね。
'''和田''' そう。だからペアプロですら、すごく緊張する。
自分がコード書いてるところは、人に見られるものではないという感覚はすごく強い。
プライベートなものなので、それが常に見られているのはプレッシャーを感じますよね。
見られてないと人間真面目に仕事しないというところもあるので、ペアプロの経験はすごい成長の元になると思います。
講演もそうだし、ブログもそうですね。
!! 「主催者始めました」
'''おかざわ''' 和田さん自身地方で講演して回ったりとか、デブサミで発表したりというのは糧になっていますか？
'''和田''' 糧になっています。アウトプットするとインプットが増えますし、人からの反応もたくさん来ます。
'''おかざわ''' 懇親会などで直接会話された中で印象に残っているお話などありますか？
'''和田''' 福岡の主催者の [[@pocketberserker|http://twitter.com/#!/pocketberserker]] さんは、佐賀から名古屋に来ていて。
勉強会初参加が TDDBC 名古屋だったらしいのですけど、それがすごい強烈な体験になったと聞いています。
名古屋には関数型の人はいるし、ペアプロはやるし、夜はホテル借り切って修学旅行みたいにハッカソンやるしで。
地方の TDDBC は 2 日間コースなので、基本宿を借り切ってやるパターンが多いんですね。
そうすると、夜も普通にみんな集ってプログラミングしたりするので、2 日間構成ならではの体験ができます。
東京でもできたら面白そうですけど、そういう土地柄でもないのかなと思わなくもありません。
'''大中''' 横浜でやったときも考えたんですけど、2 日間コースだとやはり参加費とかが跳ね上がってしまうのが。
あと、土日両方やるとなると敷居が上がるというか。
'''和田''' 上がります。上がりますね。
!! TDDはユーザの価値に寄与するか？
'''杉野''' 「TDD がユーザーにとっての価値を提供できているのか実感できているか」という質問があるのですが。
'''和田''' 基本的に TDD が寄与するのは「内部の質」に関するものです。
直接お客様にフェイスするところかというと、そういうところもあるけど、それよりは、書いてきたものに対して自信を持つことができるということのほうが重要ですね。
TDD はリファクタリングが常にセットじゃないですか。
一定速度、自分達が予測できるスピードで価値を提供し続けることができるところに、お客様に対する TDD の価値があります。
基本的には、お客様に「テスト駆動開発やってます」と胸を張って言うことではないんですよね。
どちらかというと「プロだから当然やってますよ」という話です。
自分達が書くコードに対して技を尽くしてますよ、という話なのだと思います。
お客様 (エンドユーザ、受託開発) に対して、「テスト駆動開発やってます」ということを売りにするということは、そんなにありません。
でも、言われることはあるんです。僕に仕事がくる場合「テスト駆動開発でやってください」と言われるのは多いんです。僕宛てに来た仕事なので、構図としてそうなっている側面はありますね。
'''大中''' 自分の感想ですと、シビアな仕様変更とかがあっても、デグレ無しでスパンといけちゃうとかは。
'''和田''' テストコードがあってよかったなと。
'''大中''' そうですね。TDD によって価値を提供できているなと。
'''和田''' そうですね。
急激な仕様変更、急激なリリースであるとか、プレッシャーがかかる局面になると、人間は視野がぐっと狭くなって、自分の頭でチェックできる領域がすごく狭くなってしまいます。そのようなときに、それまでにやってきたことを機械が実行して助けてくれるというのが、テスト駆動開発を行って、テストコードを用意してきたことの大きい御利益が得られる瞬間ですよね。
また、開発期間が長くなったりすると隅々の仕様やテストコードについて覚えていなくても、何かを変えてどこかのテストコードが落ちれば、これまでと動きが変わったというのがはっきり Yes/No で分かるのも、自信、安心に繋がりますね。
!! Microsoft が TDD でバグ9割減
'''杉野''' 「Microsoft が Visual Studio の開発 に TDD を適用したらバグが 9 割減った{{fn('[[http://www.tdd-net.jp/2009/12/tdd-boot-camp-3.html|http://www.tdd-net.jp/2009/12/tdd-boot-camp-3.html]]')}}」という話についてのは正直どう思いますか？
'''和田''' あとで調べてみたんですけど、Visual Studio のアーキテクチャの大規模な立て直しのプロジェクトだったらしくて、割と本腰を入れてやってたらしいんですね。
バグ 9 割減ったというのは相対値の話なので、それまでみっちりテストをやっていて出ていたバグ数が、そもそも出なくなったって話なのかとか、そのへんをちゃんと考える必要はあります。
あとは、対象が複雑ということもあります。開発ツールなのでたくさん状態を持っているだろうし、たくさん振る舞いをもっているだろうし。
そういうものに対してボトムアップでひとつひとつの部品の完成度を高めて、それらの組み合わせ自体のエラーの混入率を一気に減らした、という効果なのではないかと思います。
'''おかざわ''' 9 割っていうのが、どこの数字を拾って 9 割なのかっていうのがあるかもしれないですね。
'''和田''' そうそう。
'''大中''' ある意味でいうと出てるんだけど、いわゆるテストフェーズ前のコーディング時点でもう潰しちゃっているかもしれない。
'''おかざわ''' 今言われた、単体レベルの数字も含めて 9 割だよっていうのと、結合レベルで 9 割減ってるっていうのは違いますよね。まぁ、そこは邪推なので。
!! テスト駆動開発者は三周目に死ぬのか
'''おかざわ''' それで、2009 年のオブラブ{{fn('[[http://www.objectclub.jp/event/2009summer/session.html|http://www.objectclub.jp/event/2009summer/session.html]]')}}で発表されてた資料{{fn('[[http://www.slideshare.net/t_wada/emergent-design-oblove-2009-summer|http://www.slideshare.net/t_wada/emergent-design-oblove-2009-summer]]')}}を見せて頂いて疑問に思ったのですが、TDD で開発したシステムが死ぬというのは、アーキテクチャ的に死ぬということでしょうか？
'''和田''' ボトムアップで設計したものがアーキテクチャ的にどん詰まりになるということを言っています。
例えば、小さい部品を組み合わせてテストコードもちゃんと動いてるんだけど、テストコードは基本的にシングルスレッドの世界として書いてしまうことが多いですよね。
マルチスレッドで動かないとか、いざ本番で実際のリクエストに晒してみるとパフォーマンスが悪い、といったことが出てきてしまうので、「ちゃんとアーキテクチャを事前に設計すべし」という意見が出てきたりするんです。
テスト駆動開発やアジャイル開発、オブジェクト指向設計の文脈でよく話題になったり、批判されることでもあるんですけど「高いレベルのメンバーじゃないとできません」という意見がありますよね。
ペアプロ時もそうなんですけど「暗黙の設計」は、あります。
どうしても、個々人の差とか、どのぐらい設計のゴールが見えて TDD やっているのかというところは、やはり経験の差だとか能力の差が出てくるところではあります。
その上で、ではなぜ TDD をやっているかというと、作っていくうちに最初思い描いていたゴールから微調整が必要だとか、やってみて初めてわかることが多いんですね。
最初からきちんと設計してその通りに実装すれば上手くいくかというと多分そうではないし、でも無から完全にボトムアップで組み上げていったら、たぶん全然違うところへたどり着いてしまう。その中間に良い設計というのがあるんじゃないんですかね。
'''大中''' TDDBC 横浜のときにちょっと失敗したことなんですけど、課題を小出しにしたんですよ。
それはそれで、一つの問題に集中するという効果はあるんだけど、その上で、実際の仕事で何を作るかというところを、その場その場で小出しにして判断していくというデザインの仕方が本当に正しいのかどうかというと、ちょっとそれも違うなというのがあって。
'''和田''' はい。
'''大中''' 何を作るのかというのが見えているんだったら、それはそれでオープンにしておいた上で、進んでいくところで見つかるズレをどうやって調整していくか、という対応がよいのかなと思ったんですよね。
'''和田''' そう。横浜のときと C++ のときは課題を小出しにするスタイルで、それは目の前のことに集中できるという良い効果と、全体像が見えにくいという良くない効果と、その二つの効果があったと思っています。
別のイベントを開催をするときは別のやり方でやってみればよい、という有用なフィードバックだと思うんですよ。
僕がよく TDD の講演の中で言っているように、現実の問題は複雑でデカイじゃないですか。
それに対して一気に立ち向かおうとすると敵が大きすぎてやっぱり手が止まるんですよね。
だから、ある大きいゴールを達成するためには、小さいゴール。
これとこれとこれとこれができれば大きいゴールに到達できる、というように、はしごを掛けていかないといけない。
大きい問題を小さい問題に分解するというのは、ストーリーをタスクに分割するという話や、タスクをさらに小さいタスクに分割することや、 GTD {{fn('Getting Things Doneのこと。[[http://ja.wikipedia.org/wiki/Getting_Things_Done|http://ja.wikipedia.org/wiki/Getting_Things_Done]]')}}の世界にも通じる汎用的な話ですよね。
問題の分割には練習が必要です。
大きいゴールを提示するとそれを小さいゴールの連続に分解できない人はやはり多いです。
というか、訓練しないとなかなかできるようにならない。
'''おかざわ''' C++ のときは、最終的に経路探索をして路線の料金計算ができちゃうような主題に対して、そこから問題をだんだん分割しててそれぞれに課題をつけていくというやり方をされていました、途中で井芹さん{{fn('[[http://d.hatena.ne.jp/goyoki|http://d.hatena.ne.jp/goyoki/]]')}}が講演資料を作ったら、各課題とテストの設計が課題として設定されるようになって、結局 10 段階ぐらいになったんですっけ？
'''和田''' 10 問ぐらいになってますね。
'''おかざわ''' タスクとしては分割されていて、かつテストの観点も同時に含まれていたのですが、最後のゴールが見えず途中でアルゴリズム大会になってしまった。
'''和田''' そうですね。現実問題としては、全体を見ながらという、複眼視が必要ですね。
全体を逃さないようにしながら、でも目前のものに集中してやっていった方が効率がよい。
だから、遠くのゴールを片目で見ながら、そこにたどり着くために近くのものを小さく設定して倒していく。
'''大中''' それにどうやって立ち向かっていけばいいのかって考えるときにたどり着くのって、やっぱり Kent Beck の『テスト駆動開発入門』のタスクリストを出して、ひとつひとつ立ち向かっていくっていうやり方に近づいていく。
'''和田''' 近づいていきますよね。
大きな講演の度に、『テスト駆動開発入門』や『リファクタリング』を読み直すんですけど、いっぱい走っても結局 Kent Beck の手のひらから出ていない、 Ward Cunningham の手のひらの上を出ていない、という感覚になります。
なんかこう、お風呂の中で TDD 本を読み直していて、「ああ、結局ここに書いてあるじゃん」ってなりますね。
TDD 本と『リファクタリング』の最後の一章（第 15 章）は Kent Beck が書いているんだけど、そこにだいたいすべてのことが書いてあるので、「ああ、また俺は手のひらの上か」みたいな感じがすごく出てしまいます。
'''おかざわ''' xUTP 本{{fn('書籍 "xUnit Test Patterns" の略称。[[http://www.amazon.co.jp/dp/0131495054/|http://www.amazon.co.jp/dp/0131495054/]]')}}の中にパターンとして記載のあった INSIDE OUT と OUTSIDE IN についてさんざん議論したじゃないですか。{{fn('xUTP本の読書会でとりあげていた重要ポイントに触れずに、xUTP本の前の世代の本になる『テスト駆動開発入門』まで遡っていることを指摘している。')}}
'''大中''' それ、俺に言ってる？（苦笑）うん、でも確かに、 OUTSIDE IN と INSIDE OUT の考え方は重要。あれでテストに対する考え方が変わった。
'''和田''' ほう。
'''大中''' 僕の場合、あれ読んでからしばらくは INSIDE OUT に寄り過ぎていて、テストは書いたんだけど、コンポーネントとして組み合わせると動きませんとかそういうのがあって。ようやっと、この前のプロジェクトで方向転換できたかなというとこなんですけど。
'''和田''' 画面に近い、要するにユーザに近いところから作り始めるやりかたですね。例えば受け入れテストとか、いわゆる MVC でいうとコントローラやビューから作って、内側をモックにして、要求の方から作っていって中に攻めていく方針が OUTSIDE IN というテスト戦略。
そうじゃなくて、抽象的な部品とかモデルレイヤから作っていってボトムアップで攻めていくのが、INSIDE OUT 戦略。
Kent Beck や Fowler がやってた 2000 年ぐらいの TDD の姿と、その後の Steve Freeman とか Nat Pryce とか goos の人たちがやりだした TDD との大きな違いというのは、「向き」が出てきたということですね。
Kent Beck がやっていたのは、抽象的な話で、「テストの向き」という概念は基本的に無かった。
それに対して、モックオブジェクトを作った Steve Freeman と Nat Pryce は、モックオブジェクトを使うことで、テスト駆動開発自体は、開発する要求や対象の世界を自分たちが理解していく上での設計ツールになり得るし、設計の時間を制御できることに気づいたんですね。
最初から全部を理解するのではなくて、その人たちのソフトウェアに対する理解をだんだんと、見えている外側の界面から中側に向かって攻めていくことができる。
それまでは、実装がないとテストができない、実装がないとインテグレーションもできない、という状況でした。
それが、オブジェクト指向言語とモックオブジェクト (テスト用の偽物) という道具を組み合わせてテストに使うことで、決まっているところはともかく、決まっていないところでも実装のことを考えずに外側から決めていくことができるようになったことに、テスト駆動開発をやっている一部の人たちが気がついたんです。
それが OUTSIDE IN 戦略。
システムに対してテストする方向もそうだし、時間でもあるんですね。
外側から先に作っていくという話なんです。学びと時期をテストで制御する。
!! パターン厨のはしか
'''和田''' モックオブジェクトには良いところも悪いところもあります。モックオブジェクト自体はメンテナンス対象になるから、例えばモックオブジェクト自身がリファクタリングを妨げてしまうような状況を避けるための設計をしなければならない。
デザインパターンが出たときに、みんなデザインパターンを学んでデザインパターンを可能な限り使おうとしたじゃないですか。
シングルトンパターンを憶えたらみんなシングルトンオブジェクトにしちゃったりとか。なりましたよね？
'''大中''' なりますね。（苦笑）
'''和田''' だから、あれは麻疹なんですよ。デザインパターンもそうだし、モックも。
大事なのは、モックをすごいと思ったら、一度モックをばあーっと使ってみるということ。
そうするとモックのメンテナンスコストとか、モックは結局自分の妄想に過ぎないという現実に直面して、元の世界に戻ってくる。
RTP、"Refactoring to Patterns"（邦訳『パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法』）の中に patterns happy という、「パターン大好き」みたいな言葉が出てきて、かくたにさん{{fn('角谷信太郎さん [[http://kakutani.com|http://kakutani.com]]')}}と「これどうやって訳す？」って話してて、「これやっぱり"厨"じゃないか？」って話をしていたんですけど。「パターン厨」。
'''一同''' わははは。
'''和田''' モック厨。中二病っぽい。強い技術というのは人をぐっと引きつけるし、オーバーユースするときがある。
それで、これは使いすぎたなぁといって元の場所に戻ってくる。
その真ん中ぐらいにちょうどいいバランスがある。
だから、早めに羅漢しましょうという話なんですよ。
厨を呼ぶ技術は良い技術であることが多いし、早めに触れて、早めにちょうど良いバランスを見つけましょう。
『パターン指向リファクタリング入門』はすごくいい本ですよ。著者の Joshua Kerievsky はよくわかっている人です。（手元の iPad を見つめて）ああ、「パターン魔」って訳されてますね。なるほど。
'''大中''' ここでいう「ハッピー」って、どっちかっていうと「ハイテンションになる」っていう意味でしょうか。
'''おかざわ''' 『アドレナリンジャンキー』的な{{fn('[[http://www.amazon.co.jp/dp/4822284018/|http://www.amazon.co.jp/dp/4822284018/]]')}}。
'''和田''' そうそうそうそう。
!! お風呂で本を読む
'''杉野''' さっきちょっと言われてましたけど、お風呂の中でも本読まれるんですね。
'''和田''' 読んだりしますよ。iPad で読むことも多いんですけど、疲れてくると画面から離れてみたくなります。紙と鉛筆で考えたい。いいアイデアって散歩中とかお風呂に入っているときとかに浮かびがちですよね。
!! TDDBC にこれから参加する人と既に参加した人へ向けて
'''おかざわ''' TDDBC にこれから参加しようと思っている人と、もう参加した人に伝えたいこと、目標としてもらいたいことをお願いします。
'''和田''' 参加したい人は、怖くないので気軽に来てくださいと言いたいです。まぁ、未だに倍率が高いのが悩ましいんですけど…。
でも、体験からしか学べないというわけではないです。
僕は TDD は基本的に自習できる{{fn('和田さんによる技術書の写経の仕方 [[https://twitter.com/#!/t_wada/statuses/9000231741|https://twitter.com/#!/t_wada/status/9000231741]]')}}と思っています。ですけど、コードレビューやペアプロは他者がいないと成立しないので、そういう空間、非日常の異空間を用意するというのが、TDDBC のひとつの舞台装置としての効果であると思っています。そういう体験はとても強烈なので、ぜひ体験して欲しい。
参加したいと思って確実に参加できる手段は「自分で主催する」ことなので、小規模でもいいので、何かいろいろやってみるというのがいいんじゃないでしょうか。ぜひ気軽に相談してください。
TDDBC に参加した人に対して伝えたいのは「自分で咀嚼して自分の言葉にして伝える」ということ。
実際、人に伝えようとして初めてわかることがすごく多いんです。
コンサルティングの現場でも、お客さんの話を聞いてから自分で言い直して返す、というのが基本テクニックじゃないですか。
人に対して説明してみようと思うときに、初めて自分の中で再構築されて理解が進むのだと思います。
自分の会社に戻って、TDDBC で体験したことを隣の人に伝えてみるとか、部署内で勉強会をやってみるとか、そういう機会をつくって自分が教える立場になると、自分が一番学ぶことができます。
自分が何を学んだのか、ということを、今度は人に伝える側になっていただけたら嬉しいなと思っています。
まとめると、これから参加する人は怖がらないで来てみてね、というのと、参加した人は学んだことを日々の行動に還元するとどうなるかを考え、人に伝えてほしいということですね。
あと最後に、テスト駆動開発は自分ひとりで続けていけるものであり、こつこつと練習することが上達につながります、と重ねて言いたいです。
!! 好きな女性のタイプ
'''おかざわ''' 好きな女性のタイプは？
'''和田''' 奥さんです。
'''杉野''' どんなところが？
'''和田''' 好奇心が強いところですかね。奥さんが自分がやってることに興味を持ってくれるところです。
!! xUTP読書会が2年続いた理由
'''おかざわ''' xUTP読書会{{fn('xUnit Test Patterns(xUTP)読書会 [[http://www.fieldnotes.jp/xutp/|http://www.fieldnotes.jp/xutp/]]')}}ってなんで 2 年間も続いたんですかね？
'''和田''' 本が分厚いからじゃないですかね。
'''おかざわ''' 他にも分厚い本を前に自然消滅した読書会を知っているので、そこが不思議に思っています。。
'''大中''' xUTP 読書会って何で最後まで終わったかというと、一番大きな原因っておかざわさんが加わったからでしょ？
'''和田''' そう。そうだと思う。
xUTP 読書会がなぜ完遂できたかというと、おかざわさんが途中で「おかざわブースター」として入ったというのが大きい。
やっぱり一定出力でアウトプットをし続けられる人が会の存続に必要ですよね。
'''おかざわ''' へえー。
'''大中''' 僕、けっこうムラっけあるんで。
'''和田''' ムラっけ、あるある。
後は、継続するのに月イチぐらいがよいテンポなのかもしれないですね。xUTP 読書会の母体となった『RESTful Webサービス』{{fn('[[http://www.amazon.co.jp/dp/4873113539/|http://www.amazon.co.jp/dp/4873113539/]]')}}の読書会{{fn('RESTful勉強会 - RESTful読書会 [[http://kunit.jp/restful/wiki/|http://kunit.jp/restful/wiki/]]')}}からですかね？
'''大中''' 母体では無いけど、そうか、きっかけはそうなんですね。
'''和田''' きっかけにはなったけど、メンバーは母体にはなってないか。
'''大中''' 『RESTful Webサービス』の読書会に僕が参加して、帰り道に和田さんに「レガシーコード本の読書会をやろうと思うんですよ」って言ったのがきっかけなんですけど。
'''和田''' おおー、そうだった。
'''おかざわ''' たしか和田さんのブログでコメント欄が燃え上がった{{fn('[[http://d.hatena.ne.jp/t-wada/comment?date=20080224#c|http://d.hatena.ne.jp/t-wada/comment?date=20080224#c]]')}}のが。
'''和田''' あー、ブログもきっかけかもしれないですね。「読書会フラグですね」みたいな。
'''大中''' コメントが 40 個以上ついたのが。あれひどかったよなぁ。
'''和田''' レガシーコード本のときはサイボウズ・ラボの中谷さんに会場をお世話になったし、勉強会/読書会には定期的に場所を提供してくださる方と定期的にアウトプットしてくれる方、その二人が大事ですね。
'''大中''' その二人が揃えば、まぁ、勝利ですね。
'''和田''' レガシーコード本のときも xUTP のときもそうだったけど、毎回場所を探すのは結構きついですよね。
毎月開催できる場所を手に入れるのが、定期的に開催する読書会に必要なパターンですよね。
で、僕が参加し続けてたのはなぜかというと、まぁ、基本的に好きなことだったからだと思いますよ。
'''おかざわ''' 一通り読んだ上でやっぱり参加されてるじゃないですか。
'''和田''' ざっくりとは読んでいるんですけどね。読書会はもっと深く読み込むからやっぱり理解も違ってくる。
goos本の読書会もみんな訳してきてくれたりするので、怖がらずに来てくださいねというのは言いたいです。怖くないです。
!! ぺけま Vol.1 はぶっちゃけ何点？
'''おかざわ''' 最後にひとつだけ。初回のぺけま、とりあえず xUTP の裏表紙にあるパターンを全部概略付きで、手抜きなんですけど（笑）、載せてたりとかするんですけど、 5 点満点で何点？
'''和田''' えー。
'''おかざわ''' 「俺はこんなもん求めてねえよ、俺が求めてたのはこのぐらいだよ」とか。
'''和田''' 5点満点でいうと…。じゃあ、 4 点。
'''大中''' おおー。
'''和田''' 5点満点というと、これがマックスなのかみたいな話になっちゃうから。
巻頭言もかなり熱い感じになってたし、xUTP 本を概覧するという最初のまとめ記事もすごい力が入ってましたよね。
有志のクオリティでこれを続けるのは難しいところなので、どうやって人を巻き込んでいくかとか、読者を増やすかといったことが、定期的に、不定期でもいいと思うんだけど、これだけのアウトプットを続けるために重要になりますね。
やはり Web 媒体って、紙媒体と違って編集しやすいし、修正しやすいし、フィードバックが得やすいし、技術的な情報を発信するのに向いている媒体だと思います。さっき言われていたように、Java の情報が足りないのであれば、 Java の情報をぺけまでやっていけばいいだろうし、ニーズのあるものを書いていく、そういう媒体として育てばすごいなぁと思います。
実際今日(収録日)もたくさん反応がありました。今日僕がはてぶを Twitter に投げたら多くの方に RT されたんです。{{fn('[[https://twitter.com/#!/t_wada/status/137084843103223809|https://twitter.com/#!/t_wada/status/137084843103223809]]')}}
'''杉野''' されてましたね。
'''和田''' 僕がはてぶ投げ忘れてて、今日がちょうどいいタイミングだと思って投げたらバーンと 22 RT。
!! ぺけま公開の裏側
'''和田''' ぺけま第一回出たのって 4 日ぐらいですよね。
'''大中''' だって、あれ TDDBC 横浜当日( 2011 年 11 月 5 日)ですよ。和田さんが基調講演している最中に公開したという（笑）。
'''和田''' あれでタイミングを失っちゃったんですよ（笑）。はてぶで 1 ゲットしようかとしていたら、俺が喋ってるところで公開。
'''一同''' 爆笑。
'''大中''' あれ、僕が朝イチで公開しようと思ってたら、編集がまだ終わっていなくて（笑）。
'''和田''' そういうことだったのかぁ。
'''おかざわ''' 間違いを指摘してくれる人がいて、ちゃんと読んでくれてる人がいて嬉しかったです。
!! フィードバック募集してます
'''和田''' フィードバック募集をどうするかですね。
'''大中''' メールアドレス作るのはできるんだけど、さて、どこに流せばいいんだろう。
'''和田''' [[#xutpハッシュタグ|https://twitter.com/#!/search/%23xutp]]をつかってもらうとか、 公式ハッシュタグってどうしますか？
'''大中''' あと、イイネボタンとかも押せるようにしたいんだけど、あれどうやればいいんだろう。
!! お友達を紹介
'''和田''' これで次の人にバトンタッチするとかあったりするんですか？
'''大中''' なんも決めてないです。
'''杉野''' 指名するんですか？
'''和田''' どうなんだろ？誰のインタビューをやりたいとかあったりします？
'''大中''' 僕がぼんやり思っているのはこんぴろさんなんですけど。
'''和田''' ああー、それは面白いな。
'''大中''' オンラインのインタビューになりますけどね。福井なので。
'''和田''' そうか、最近物理的に見ないと思ったら福井にいるのか。
'''大中''' 福井で TDDBC を開催して福井に行くって手はありますけどね。発行がイベント駆動なので。
'''和田''' 締め切り駆動は大事ですよね。アジャイルにやるというかデリバリは決まっているからスコープを落としていくっていう。
'''一同''' 笑。
'''和田''' 今回は二本しかありませんっていう。それは面白いかもしれないですね。
僕がこれまで書いた文章とか色々ぺけまに寄稿していければなって思います。
!! インタビュアーも募集してます
'''おかざわ''' 誰がインタビュアーをやるかっていうのもあるんですけどね。
'''和田''' 僕がインタビュアーの側にまわっても面白いかもしれませんね。
'''おかざわ''' 和田さんがインタビューしたい人ってのもいいかもしれませんね。
'''大中''' 僕が Twitter に「和田さんにインタビューしたい人いませんか？」と書いたら、おかざわさんが「それ群がってきたらどうすんですか」って言ってたけど、僕はまぁ、なんとかなるさと思っていたら、ちょうど杉野さんが。
'''杉野''' 僕が釣れたっていう。
'''大中''' ちょうどいい感じになった。
'''和田''' katzchang さんとか bleis さんとか、最初に TDD Boot Camp のきっかけを作ってくださった人達とか、goyoki さんたちの話が聞きたいなと思いますね。
'''おかざわ''' そのあたりは調整させていただいて。
'''和田''' はい。
'''おかざわ''' というわけで、ありがとうございました。
'''一同''' ありがとうございました。