刊行記念：諸橋さんインタビュー 第１回
『はじめる！Cucumber』の刊行を記念して、著者である諸橋さんにお話をうかがいました。
（2010年11月8日、聞き手：高橋征義）
Ruby、Rails、テストとの出会い
── 諸橋さんはRails勉強会@東京の世話役や、『Railsレシピブック』の執筆などでもよく知られていると思いますが、まず、諸橋さん自身の、RubyやRailsとの出会いについて聞かせてください。
諸橋 Railsというか、まず一番最初にRubyとの出会いまでさかのぼると、大学時代にiMacを買ったのがきっかけです。ちょうどMac OS Xとかのパブリックβが出た頃で、よく分かんなかったんですけど、画面がかっこよかったから、パブリックβを申し込んで。
iMacには重すぎるOSだったんですが、ある日コマンドラインで暮らせば重くないんじゃないかと（笑）思いついてコマンドラインを使い始めました。現実はぜんぜんこう、パソコンも触り始めて数ヶ月だったのでさっぱりわからなかったんですが。
その時に，白山さんっていう人がNeXT方面でやってて、Web日記のようなものをよく見ていました。ちなみに白山さんにはニアミスはしているらしいんですが、まだ実際にあったことはありません。当時、白山さんのWeb日記みたいなのを読んでて、『今からやるんだったらPerlとかじゃなくてRubyでいいんじゃない』という趣旨のことがなんかのきっかけで書いてありまして、それが「自分の中ですごい人の発言」としてずっと記憶に残ってました。Public betaが出てみんなが喜んでいた頃。2000年とかじゃないですかね。OmniWebっていうブラウザがキレイだったんですが、それが日本語のエンコードを自動判別できなくて、ローカルでdelegateをたててEUC-JPに変換するとか、そんなことを見よう見まねでやっていた時期です。
それからまた時間が空いて、新卒で入った会社では新人研修でJavaをやりました。
大学時代は文系だったのでシェルスクリプトを頑張って書いていて、あとは文系らしくVBScriptとか。心理学系だったんですけど、心理学実験でアンケートのようなもの順番に表示していくだけのアプリなどをVBScriptで書きました。Windowオブジェクトの中のテキストラベルだけ書き換えるだけでいいのにWindowsオブジェクトごと捨てて、もう一回新しくオブジェクトを作ったりしてて。クリックしたらこのWindowをとじて、また新しいWindowを立ち上げたり。中のテキストだけ変わってるのとか、そういうのを書きました。いまみたら気絶しそうなひどいコードです。でもそんなんでも、面白かったので、コンピュータ関係のところに就職して、で、Javaをやったんですよ。
そういう意味でJavaは、まともに触った初めての言語なんですけど、まあ、Javaはイイ言語ですよね……。シェルスクリプトに比べればすごくいい言語で(笑)、その時はJavaは使いやすく感じてました。
で、就職して配属されて、現場でツールみたいなのを作る、っていう時にRubyを思い出しました。新人研修で「オブジェクト指向」なるものを勉強したから、もしかして、あの時聞いたRubyというのも分かるんじゃね？という感じで。じゃあせっかくだからRubyっていうのをやってみようかと思ったのがRubyとの出会いですね。
REXMLでXMLをいじったり、Net::Telnetとかを使って、で、初めて買ったRubyの本が『Rubyレシピブック』でした。忘れもしない、蒲田駅の本屋でRubyレシピブックを買って。その頃からはずっと、隙あればRubyみたいな感じで社内でこっそり使ってました。
あとExerbですよ。社内でツールを作ってたんで、Exerbはもう超大活躍してて。Exerbがなかったら、たぶんツールをRubyで作りますよって言えなかったと思うのです。小物ツールとかだとWindowsでexeでダブルクリックで起動するようにしてっていう与件があると思うんですけど、それがexerbでできますよ、みたいなのがあった。あとVisuaruRubyとか。Rubyを使い始めるにあたって、あれがなかったらたぶん、今の私はないですね。
そんな時にRailsが出てきたので仕事中にこっそり試してみました。当時SQLとかもよく分かんなくて、なんかActiveRecord使うとSQL書かなくていいらしいよ(笑)という噂を聞いたのが引きつけられたポイントです。今同じことを言う若者がいたら痛烈にdisるんですけど。で、社内のプログラミングコンテストみたいなのがあったんで、じゃあRailsで作るかと思って使い始めたのがRailsとのつきあい始めです。
まぁそのときのコードもひどくて。なんだったかなあ、すごい恥ずかしいんですけど、合計を求めたい場面で、ふつうにやればSELECT SUM(value)ですむようなものです。そこをActiveRecordのattributesでとったHashをHash#mergeで足し込んでいくというこれまた卒倒しそうなコードを書きました。まあでもお客さんに納品するようなコードじゃなくてよかったです(笑) それが2005年くらいですかねえ。
そんなので国内でRailsで盛り上がるよりもちょっと早く、機会があって触ってたんで、意気揚々とRails勉強会に行きはじめたりしました。ほんとにそこでいろんな人と会って、いろいろ人生が変わりました。
このへんがRubyやRailsとの出会いですね。
── では、テストについてはいかがでしょう。
諸橋 Railsでテストを書くというのを意識し始めたのは、転職するちょっと前ですね。角谷さんがRSpecの記事を訳していたのを見て、おー、なんかTDDとかBDDとかいうものがあるらしいと。
その後、Rails勉強会でいろんな人にお会いして、で、角谷さんとかと話して今のところに来ることにしたんですけど、テストを書き始めたのはそれがもう最初ですね。それまではかっこいい人達がかっこよく書いてるんだと思ってた(笑) 僕に書けるとは思っていませんでした。
ちょうど転職したときに、角谷さんと2人プロジェクトでRubyを使うという案件がありました。それでこう、角谷さんに最初に会ったときに、「テスト書かない人と一緒に仕事したくないから」といわれまして。それが最初です。それだけだと怖い人みたいですが、氏の名誉のためにちゃんと説明すると、そう言うだけではなくてみっちりとTDDを教えてくれました。2週間くらい付きっきりペアプロで教えてもらって、それがいまも基本になっています。札幌Ruby会議でもやったボーリングですか、あれを仕事前に1時間くらいペアプロして、で仕事中も基本的にペアプロで進めるみたいな感じのみっちりテストを仕込まれましたね。
さらに、その時に「なんかRSpecっていうのがいい感じだからこれ使おうぜ」っていう感じでRSpecも使い始めています。
当時まだAPIがぜんぜん固まってなくてですね、ある日会社に来たらRSpecの新しいバージョンがリリースされてて、テストが全部動かないみたいなことがありました。いまだとshouldがあってmatcherみたいな構造になってますよね。あれがmatcherと全部くっついていて、should_be_なんとかみたいな、Rspecがそういう感じのバージョンですか。だから、いくつだろう、0.7とか0.9とか、それくらいですね。それが、TDDとの出会いです。
Railsもちょうどプロジェクトが1.0にするかしないかみたいな感じで、最終的にそのプロジェクト自体がプロトタイプ作りみたいな奴だったので、1.0にしないで納品したような気がしました。2006年の12月くらいですね。
Rails勉強会始まって、ちょうど一周年くらい。Rails勉強会第0回って、11月か12月くらいか、ああ、じゃあ1年たってないですね。
あの時のRails勉強会は、高橋さんとか角谷さんとか怖い人で(笑) 最初話しかけられなかったもんなあ……。ダイビルに行った後、万世橋の方に歩いて行って、あれが2005年かあ……。そっからしばらくドリコムになったんですよね。瀧内さんに協力していただいて場所を借りて。
「Cucumberは雰囲気で分かる、ちらっと見ても意味がつかめる、語彙が育てていける」
── そしてその後に、本書のテーマであるCucumberに出会うわけですね。
諸橋 Cucumberとの出会いは……これも角谷さんの紹介です。
もともとRSpecの機能の一部だったんですよね。RSpecにStory Runnerっていう機能があったんですけど、それがCucumberっていう形でリリースされたはずです。そのときに角谷さんが、お、これすごい、すげーよ、って紹介してくれました。で、最初ぼくは( ´_ゝ｀)ﾌｰﾝという反応をしたらしいです(笑)。覚えていないんですけど。
その後、倉貫さんのソニックガーデンの人たちと一緒に仕事をさせていただいて、僕はSKIPと連携するような小アプリを作るというミッションでした。そこでアプリの大きさも手頃だったので、Cucumbeを試してみたのが使い始めです。それがすごい良くて。気持ちよく書けるし、難しいところも力業で解決してオレすげーみたいな(笑)気持ちになりつつ使ってました。それが最初。
ソニックガーデンさんとの仕事では、機密情報に当たらない技術ネタはどんどん発信しようというスタンスでやらせてもらったので、仕事しながら調べたノウハウとかも日記なんかに書かせてもらって「Cucumberはじまったな」となってきたのが最初ですね。
Cucumberの何に感動したかというと、まず最初はWebratがすごいと思ってたんですよ。visit()とか書くと勝手にタグを探していくとか、フォームのラベルを勝手に探していくのがすごいとか思っていて、それがたぶん使い始めて2、3ヶ月です。Webratすげーなーすげーなーとか思ってたんですよ。
でも、ある時それだけじゃないということに気がつきました。何回かいろんなところでしゃべったんですけど、Cucumberはやっぱり日本語で書けるのが一番良いというのがいまのスタンスです。日本語で書くと何がいいかって、書いてあることがだいたい雰囲気で分かるんですよ。やっぱり日本語だと流し読みっていうか、ちらっと見ても意味がつかめるので。そこはすごい。RSpecでだーっといっぱい書いてあるのに比べてすごく見やすいし、ぱっと見の意味がとりやすいっていうのが。
プログラマの実利で言うと、Cucumberのいいところとして「一番外側からテストができる」っていうのを喧伝していたこともありました。ただそれだけなら、いまはsteakとかSpec Requestsでも出来ますよね。それに比べてCucumberは何がいいかっていうと、日本語で書いて語彙を育てていけるところです。やっぱ母語で書いてあると１行を読むスピードがぜんぜん違う。これがすごい。ほんとにおすすめです。騙されたと思ってやってみてほしい。
あと、出力もちゃんとわかる言葉で出てくるのが気持ちいいですね。RSpecでも読みやすくっていうのもできるんだけど、ある程度まとめて実行したときにそれを読むかって言われると、みんな読まないこともおおいでしょうし。RSpecはこう、細かく、どう美しく、小さく作るかの妙なんですよね。だからcustom matcherとか、あとsubjectとかを作りつつ、どうやれば自然言語で補ったりする部分を減らして、テストコード自体に仕様を述べさせるかを工夫するのがRSpecの妙味だと思います。逆にCucumberは、それをどう自然な日本語で実行させるかみたいな楽しさがあると思っています。
本書と絡めて言うと、Cucumberにはステップ定義をネストさせるっていう機能があります。あれは機能的には全然大したことじゃないんですけど、でも、ステップ定義をネストしたり、別名をつけてこれをして、あれをして、ああするとこうなる、っていうのはつまり何なんだ、っていうのを１行でまとめるっていうところが、Cucumberをずっと育てていくときにとても大事です。
確かそのためだけに１章近く割いていると思うんですけど、その章はこういう気持ちで書いてます。「読んで分かる」っていうのは、実利的にも気持良さでも、そこが一番のポイントだと思います。
「TDDは、難しいお題目でも額縁に入れて飾っておくものでもない」
── この原稿を書かれたきっかけ、それとそれに先立って、RubyKaigi2010でのCucumberセッションを行われたきっかけ、理由といったことを教えてください。
諸橋 この原稿を書いた一番の理由は、Cucumberこわくないよ、というのを伝えたいというものですね。Cucumberは、見た目がRubyとまったく違うので、やっぱり心理的なハードルは高いと思うんですよ。ぼくも、最初に角谷さんに勧められたときに( ´_ゝ｀)ﾌｰﾝっていうリアクションでしたし。RubyでもりもりプログラミングをしているところからCucumberでテストを書くというのがシームレスにつながる気がしなくて。
要するにすごく難しそうなんですよ。すごい大変なことをしないとCucumberできないんじゃないかっていうのがイメージとしてあって。でも使ってみるとそんなことはないんです。本にも書いた通り、ある程度慣れて、プロジェクトの語彙が育ってくると使ってみると嘘みたいに簡単に書けるようになってきて非常にいいんです。ですけど、そこに行くまでもステップが確かに長いっていうのは確かにそうなので、それを「実は簡単でしょ」って言うためにRubyKaigiでハンズオンしたりこの本を書いたりしました。
本書の一番最初、2章では、ちょっとわざとらしいシナリオを考えています。それで、scaffoldするだけでテスト通った。仕様が実装できた。よかったね。という流れにしています。それは、実際にやってみると実は簡単なんだっていうのを体感してほしかったのでそうしています。
あとはまあ、中盤にかけて毎回ステップ定義をちょっと追加するのが多少めんどくさいんですけど、後半で全体をウォークスルーするようなテストになると、もう前に作ったステップ定義だけであたらしい観点での検証シナリオを全部かけてしまったりするのもキモチイイですね。Cucumberを育てていくと、いろんなことを表現できるようになっていくので、そうなるとほんとに楽しいですよっていうのが伝わればいいなって思いながら書いています。
あとは何で書こうかっていう意味だと、なかなかこう、テストの入門書みたいなのってあんまりないですよね。技術的に難しいのも多いですし、あとは「TDDとは」というテイストもちょっとやっぱりひるむなあという感じなので。基本的には手を動かしてもらいたい。
TDDってのは、難しいお題目でも額縁に入れて飾っておくものでもないわけです。実際に手を動かしながらやってもらうと、何となくテスト書いたほうがプロダクトコード書くのが楽だなっていう風になると思うので、そういう風になってもらえればいいなと思って書きました。僕も始める前は、TDDってすごい難しいものだというイメージがあって。でも、実は簡単に始められるんだよというのが伝わればいいなと思っています。
（「諸橋さんインタビュー第２回」に続く）