株式会社GA technologies 技術顧問に日本人唯一のRailsコミッター松田明氏が就任（就任インタビュー）

12月1日より、日本人で唯一のRailsコミッター兼Rubyコミッターの松田明氏が株式会社GA technologiesの技術顧問に就任しました。

就任にあたり当社若手エンジニアとともにインタビューをしたので、その模様をアップします！（もう少し短くまとめたかったのですが、お話が面白かったのでほぼ丸々載せちゃいます）

── ご自身でも不動産投資をやられているとのことですが、不動産テックに対して興味や、当社顧問として取り組みたいことはありますか？

やれることは無限にあると思ってまして、この業界ってとにかくシステム化が遅れてますよね。

僕自身、2〜3年前の大江戸Ruby会議04っていうRubyのカンファレンスの講演で自分で家を建てた経験を無理やりRubyのプログラミングの話に結びつけて喋ったことがあって(Hacking Home)、そのころから不動産テックには興味はありました。

そのとき話したのが、よくシステム開発って家づくり、建築に例えるじゃないですか。でも逆のことを感じていて、家を作る過程を見て、これってやってることはシステム開発と一緒だなと思ったんですね。なんだけど、逆になんでこういうところはテクノロジーを使わないのか、みたいなところもたくさん目につきました。

たとえば、注文住宅って毎週1回ミーティングして、設計図がアップデートされていくんですけど、差分がわからないんですよ。常に何月何日最新版みたいなのを紙で渡される。データで見せろとかバージョン管理してくれとか思いますよね。

たとえばそういうところに不満があって、技術者の視点からもっといろいろ便利にできるんじゃないかと。

あと、その当時IoTに興味があって、自宅をハイテクにしたかったんですけど、時代が追いついてなくてできなくて。でもやっぱり家そのものがどれだけハックできるかって、不動産自体の価値になるんですよ。1つ1つの家電製品が便利になるとかそういうのよりもっと不動産寄りの観点で、家とテクノロジーを絡めるみたいな。こういう日本のベンチャーみたいなところから出てきてほしいですね。結局GoogleとかAppleとかAmazonあたりに全部持っていかれるみたいな展開になりそうで、そんなのつまんないじゃないですか。

例えば、(GAが)リノベーションをビジネスにしているんだったら、そういうところでよそと差別化してみる、みたいなのができたら面白そうかな、と。

── IoTみたいなハードを絡めた分野も是非やっていきたいですよね。

Ruby on Railsを始めたきっかけ

── Ruby on Railsを始めたきっかけはなんですか？

元々Javaや.NETの職業プログラマだったんですけど、その延長で色んなフレームワークを触ってみるのが好きだったんで、ある日ネットで見つけて興味を持って触りはじめたって感じですね。

バージョン0.13とか1.0ぐらいのころからだったかな。

── そこからRuby, Ruby on Railsに傾倒したきっかけってあるんですか？

自分にとって大きかったのは、Rails勉強会@東京というコミュニティです。月に1度の開催だったんですけど、あの頃は日進月歩で変わっていた時代で、1ヶ月の間にすごいたくさんのニュースや話題がどんどん出てきてました。で、そういうものに対してやたら嗅覚の鋭いハイレベルな人達が集まっていて、彼らに会いに行くだけでも楽しかった。自分はけっこう「だいたいわかった」気分になったらすぐ飽きちゃう性格なんですけど、Ruby/Railsに関しては興味が長続きしたのは彼らのおかげかもしれません。

当時はRails勉強会が東京で一番活発なRubyコミュニティだったんですけど、今はもう立ち消えみたいになっちゃっててちょっと残念です。今はああいう昔ながらの勉強会っていうスタイルの勉強会は無いですよね。「なんとか.rb」みたいなよくわからん感じのものは何やらいっぱりあるみたいですけど。

── Asakusa.rb は松田さんが立ち上げられたんですよね？

はい(笑) Asakusa.rbはメンバー的にはRails勉強会が母体みたいにはなってるところはありますね。やってることは全然違って、勉強会ではないんですけど。

Railsのコミッターになるまで

── Ruby on Railsのコミッターになるまでの過程を教えてください。

僕は運が良くて、仕事でRailsやりたいって言ってたら、ちょうどRailsをやってる会社との出会いがありました。バージョン1.1ぐらいのときから業務でRailsアプリを書いていたことになるんですけど、やっぱりその頃からずっと触っているっていうアドバンテージが大きいのかな。「OSS開発者になるぞ！」みたいなモチベーションがあったわけじゃないんですけど、とにかく仕事で使っていくうちに色々バグを踏むし、足りない物はあるしで、適宜自分で解決していくうちにいつの間にか…ですかね。

コミッターになるまでに、250コミットぐらいしてるんですけど、最初の頃はGitHubがまだ無かったので、Subversionでパッチ書いてBTSのチケットに添付して、っていうスタイルの昔のOSSでしたね。

何しろ、GitHub自体がRailsで作られてるんでそりゃそうなんですが(笑)

で、とにかく、それぐらいコミットしているうちにみんなに覚えてもらえて、何かをきっかけに、おまえは直接コミットしろ、と。

それから、アメリカで毎年RubyConf, RailsConfというカンファレンスがありますよね。どちらも年1回なのでつまり半年おきぐらいにアメリカで大きなイベントがあるわけで、ここ10年くらいは自費で参加してます。チケットだけでも750ドルとかかかるので、けっこうな負担なんですが、最近はスピーカーになることが多いからチケット代はあまり払ってないかな。

で、そこで、特にRailsConfでは他の色んな国から来てるRailsコミッターの連中と年に1回リアルで顔を合わせてみんなで飲みに行くわけです。コミッターになったきっかけのもう一端が、DHH(David Heinemeier Hansson: Ruby on Railsの作者)はじめ、コミッターが全員顔見知りだったのが大きいと思います。

要はなんでもそうだと思うんですけど、結局、ある人間が何かのグループの仲間になるかどうかって、積み重ねたコミュニケーションの量で決まると思うんですよね。OSSコミュニティの場合は、まずはオンラインでコミットを積んでプレゼンスを出すこと。それと同時に、僕にとってはオフラインの人間関係はものすごく大事で、色んな国の色んなプログラマーに会いに行ったりしてるのが生きてるように思います。

── DHHってどんな人ですか？

なんだろう、とても強い人ですね。とにかくケンカが大好きなんですよ(笑)。そして絶対にケンカに負けない。僕も長年ウォッチしてるけど、彼の負け戦はみたことがありません。

でも、外には喧嘩売りまくってますけど、身内にはめちゃめちゃ優しくて、ファミリーを守る意識が強いというか。一度味方とみなされると守ってもらえます。そのあたりが、団結力のあるコミュニティを長年運営してきている秘訣かもしれません。

── 今でもRailsの機能に関してはDHHが決めるんですか？

はい。そうですね。Railsの転換点で重要なところは全部DHHが鶴の一声で決めてますね。

手数だけで言うとDHHより多い人は居るんですけど、大事なことはやっぱりDHHが決めるし、リリースの直前にDHHが突然でてきて、一番最後の仕上げはやっぱりDHHがやるんですね。そこで他の人が命名したイケていないAPIも彼がちょっと手を加えたりすると、グッとRailsっぽくなったり。最後の最後に魔法の粉を彼がふりかけるみたいなそのプロセスが僕は大好きです。

僕はDHHの信者なので、基本的にDHHのやることは全て正しいと思ってます。

── DHHってまだ若いですよね。

今36~7ぐらいですかね。Rails作ったときは25歳でしたからね。

今、Ruby on Railsを選択するメリット

── 最近他の言語や新しいフレームワークもどんどん出てきていると思うのですが、今企業やプログラマーがRailsを選択するメリットってどういうところにありますか。

逆にRailsと同じレベルのものってまだないんじゃないですか？Railsに影響を受けた世代のフレームワークは他の言語でも無数にありますけど。

Railsの良さはRubyの言語が持っている良さを引き継いでWebの世界に展開しているところです。なので、同じことをたとえばPHPやJavaでやろうとしても、なんかこう、手触りが違うんですよね。

じゃあRubyで第2のRailsを作ればいいかというと、あまりにもRailsのエコシステムが育ち過ぎているという話があって。Railsの良さってRails本体もよくできてるけど、プラグインやノウハウの蓄積など10年の歴史があるっていうところが大きいです。そこをかなぐり捨ててまで第2のRailsを作るっても、それってどこまで使えるのかなぁと。

普通10年やってるとレガシーになって腐るんですけどね。Railsの凄さは、そうならないように常に変化させ続けているところですね。というわけで、良いものは蓄積されていって、良くないものはきちんと浄化されていくシステムになっていて、今のところなかなか弱点が見当たらないですね。

── Railsも完成度が上がってきましたよね。Ver.4からVer.5のバージョンアップってVer.3からVer.4や、Ver.2からVer.3に比べてもそこまで大きな変化は無いように見えますが、今後Railsはどのように進化していきますか？

最初から一貫していて、DHHが Basecamp を作ったときに、その土台になったものをオープンソースにしちゃおうというところから始まって、そのリアルなプロダクトで現場の本当の問題を解決するために使っているソリューションをそのままパッケージにしたものがRailsなんです。

今後も、時代に即していて、世の中で実際に使われている技術を使って、みんなの現場の問題を解決するツールでありつづけると思います。

たとえば、PrototypeっていうJSのフレームワークがあったじゃないですか。あれってそもそもRailsのかなり初期の頃にRailsでAjaxだ！っていってRailsに組み込まれたものなんですけど、作者のSam Stephensonは37signalsの社員なんですよね。つまり、Basecampを作るためにJavaScriptライブラリというものを発明して、それをRailsに載せて広めて、その後のインターネットに大きな影響を与えました。それまでああいうJavaScriptのライブラリという発想は無かったので、すごくセンセーショナルでしたよね。

かと思いきや、その成功に固執せず、jQueryが流行ってきたらRails 3.0あたりでサクッと乗り換えたりして、というあたりの現実主義というか現場主義がRailsの真骨頂です。そのあたりに関しては、これからはReact.jsが主流になっていく流れなんでしょうかね、よくわかりませんが。

CapybaraもRailsの次のバージョンから標準で入ってきますよね。それもどうせみんなそうやってテストしてるんでしょ？っていう現実を踏まえてですね。

── 単体テストは今のところminitestですよね。

minitestですね。なんでRSpecじゃないかというと、DHHがRSpecの文法が嫌いだからです(笑)

RSpecは2.xの頃が全盛期で、猫も杓子もRSpecという時代があったんですが、3系になって2代目メンテナーのDavid Chelimskyが引退しちゃってからは当時の勢いがなくなってしまったので、これからRSpecが巻き返すことは無いんじゃないかなぁ、と個人的には思ってます。

── どう違ったんですか？

作ってる人が違うんですよ。そこに尽きます。

dchelimskyの世界観に僕らは夢を見ていたんです。Rubyで作るTesting DSLの理想形を彼は突き詰めようとしていて。

BDD(Behavior-driven development)ってそもそもJava方面から出てきたんですけど、JavaではBehaviorを自然言語のように記述するのって限界があったんです。でもこれRubyならできるんじゃね？ってところでRSpecってものが出てきて、かなりいい線まで行ったんだけど、残念ながらdchelimskyが興味を失ってしまって…。彼はもうやり尽くしたと。それで違う人が引き継いだらもう全然違っていて。やることなすこと間違ってて、手を加えれば加えるほど悪くなっていくので、僕は見限りました。

RSpec 2は本当に面白いプロジェクトだったんですけど。残念です。ああ、でも、今RSpec 3系のメンテを頑張っているMyronとかを個人攻撃とか批判する気はまったく無くて、つまり「僕は」dchelimskyのファンでした、という、そういう個人的な話です。そして、こうなってみると、RSpecが一番盛り上がってた当時にそれに飛びつかなかったDHHの判断力みたいなのがやっぱりすごかったんだな、やっぱり彼は正しかったな、と。

コミッターとしての、企業とOSSコミュニティとの関わり

── Ruby/Railsのコミッターをやりながら、企業に対してコンサルティングをする立場として、OSSコミュニティと企業との関わりがこうなってほしいってありますか？

いや、もう使っていただいてるだけでもありがたいですよ。というのがひとまず模範解答でしょうか(笑)

せっかく作ったものを誰も使ってくれなかったら寂しいじゃないですか。使ってますよ、と一声くれるだけでも勇気づけられるというのはありますね。

その上で、やはりフィードバックをいただけるとありがたいですね。積極的に新しいバージョンを使ってもらえて、気持ちよくバグを踏んでくれて、それを即座に報告していただけると。

作っている側はすべてのユースケースを想定してから作るわけではなくて、ある程度見切り発車で出しちゃって、ユーザーに何か言われてから考えるみたいなことがよくあるので、リアルな現場からフィードバックをいただけるのは本当に助かります。

企業からOSS開発者側に出せるものとしては、たとえばプログラミング言語の開発をしていると、ある機能がリアルデータ、たとえば300万件のレシピが登録されているWebサイトだとか、100万件の不動産情報が蓄積されているような実際のデータを食わせてみてもちゃんと動くかって、やってみないとわからないみたいなところがあって、そういう共同研究みたいなことをやっていけると面白いかもしれないですね。

たとえば新しいGCのアルゴリズムをテストしたくて、暴力的な数のRailsアプリのリクエストに曝してみたいので、おたくの本番システムにちょっと入れさせてください、みたいな。

あとは、最新のRubyを使って、弊社のサービスが止まりましたみたいな、生々しいスタックトレースが欲しいみたいです。なんか動かないからいいや、バージョン下げておこうじゃなくて。それをIssueに投げて貰えるとありがたい。

── 実際使ってみるとわかる問題ってありますよね。うちの開発者も文句言ってるし(笑)

そういうの大歓迎です(笑) ただ毒吐くだけじゃダメですよ。建設的なフィードバック、まさかり大歓迎です(笑)

── 最近あるGemにPR送ったらマージされてうれしかったです（当社若手エンジニア）

そうそう。そうやって現場で直面した問題を手元だけじゃなくてプルリクエストで問題の根源から解決していくのが王道ですね。貢献っていうとあんまり好きじゃないけど、なんか世界と繋がってる感じが味わえて楽しいですよね。

── ActiveRecordのwhereにRangeを渡すときに、「未満」はRangeで表せるんだけど、「より大きい」クエリがRubyで書けなくてイラッとします

あー、それまさに最近Ruby開発合宿で話題になりました！それをやりたかったらRangeの新しいリテラルが欲しくなるんですが、でもRubyの処理系開発者たちにはそのユースケースが見えてないので、「そんなの書けても誰が使うの？」っていうところで止まっちゃうわけです。そういう現場の要望とかもっとうまく集められると良いですよね。

エンジニアの理想の環境

── エンジニアにとって、働きやすい環境ってなんだと思いますか？

人それぞれだとは思います。そういうのってシリコンバレーやアメリカの会社が色々開拓しているのであちらから学ぶことは多いと思います。

例えば最近の傾向でいうと、リモートワークですかね。

もっと言うと、本質的に必要じゃないことをどこまで省けるか という話だと思うんですよね。成果物がコミットでいいんだったら、インターネットがつながっていれば、プログラマーは会社に来なくていいわけで。

その逆で行くなら、オフィス環境にこだわるってところでしょうか。広さとか椅子とか机とかインテリアとか。

── 椅子はいいもの使ってますよ(笑)

なるほど。このオフィスは眺めも良いですよね。箱としてのオフィスとしては良い場所だと思います。

あと、個人的には街がすごく重要ですね。周りにうまい飯が食えるところがあるって。通勤の義務が生じても、モチベーションになりますね。もちろん銀座が最高なんですが、恵比寿も悪くないと思いますよ。

技術的にチャレンジする余地が常に与えられていると、エンジニアにとってはやりがいになりますね。成長とか勉強とかっていう日本語は好きじゃないんですけど、まだやったことないことをアグレッシブに試させてくれるプロジェクトだとやる気がでますね。ただ、これも人による差が大きい部分で、むしろ真逆の人もいます。知ってることだけやっててそれで給料もらえていいじゃんって人もいますし。Railsとかやってるような人は前者のほうが多いんじゃないかな。

── 与えられたことだけをこなしていてもそれ以上のものにはならないので、うちとしてもそういう人がほしいですね。うちもすでにアグレッシブにやってくれているメンバーは多いですが。

既存のソリューションにはどこかで疑問を持っていて、もっといいやり方はないかなぁって常に考える。

新しいことをやると8割がた失敗するものですけど、そこで出戻りになっても無駄ではないので、そこで試したことがきちんと評価される職場環境であって欲しいと思いますね。

── リモートワークもいいのですが、生のコミュニケーションも必要では？

それに関しては面白いプロジェクトの例があって、Rubyの開発プロジェクトは20年ずっとオンラインでやっているんですが、ここ数年定例オフラインミーティングを取り入れつつあります。今年は開発者合宿もやりました。

OSSってLinuxを始めオンラインで完結するモデルで回ると思われているのに、Rubyは今はそうではないやり方にシフトしてきているわけですね。

企業のシステム開発的な現場にもOSSの開発モデルから学んで現代的な手法が取り入れられているじゃないですか。分散リポジトリやCIやChatOps的なものだったり。

そこに逆行して、20年やってきたRubyが近年アナログ的な手法を取り入れているのは面白くて。ホワイトボード大事だわーみたいな(笑)

オンライン上のチケットだと細かいニュアンスが伝わらなかったりして、実際喋ったほうが早いことも多いんですよね。

エンジニアは足りていない

── まだまだ世界的にRailsエンジニアが不足している状態だと思いますが、今後どうなっていくと思いますか？新しくRailsを始めようという人は世に増えていると思うのですが、それに対して需要がものすごく多いというか。

シリコンバレーとかサンフランシスコでも、よほどこだわりがない限りはRailsがスタートアップの第1の選択肢ですね。そして慢性的にRubyプログラマーが不足している状況で。日本でもそんな流れは感じます。

そこでRubyプログラマーを増やすしかないんですけど、まず、Rubyって他言語には見られない特徴があって、Rubyを使う人に対して名前がついているんですよね。"Rubyist"って。それって僕が知るかぎりRubyしかなくて。Rubyistって言葉を1997年にまつもとさんが作って、定義も明確に決められています。

Rubyに対して、「単なるお客さん」以上の気持ちを持っている人のこと。技術レベルの高さが基準ではなくて、Rubyはいいものだから、人に教えたい、広めたりという気持ちを持っていて、実際にアクションを取ったことがある人はRubyistですということになっています。

おそらくそのへんが根っこにあって、不思議な拡散力があるんです。伝統的にコミュニティが強くて、コミュニティベースで人から人に広まっていく雰囲気があります。

RailsGirlsって何年か前からヘルシンキで始まったイベントがあるんですけど、暖かさみたいなのが特徴的ですごくRubyっぽいなぁっていうムーブメントで、今や世界中で毎週のようにやってますよね。

あれは僕らから見るとLindaがやりたくてやってるだけなんですけど、もう少しメタな見方をすると、Railsプログラマ不足問題を解消しようとする大きな力が働いているとも言えます。

RailsGirlsが出てきたとき、色んな企業がちゃんとそこに飛びついて、金銭的にも場所的にもサポートをどこの国でもしていく流れがあります。

そういうところでうまくWin-Winの関係を作りながら広まっていってますよね。

── Railsってとりあえず深くわかってなくても、レールに乗せてしまえばなんとなく物がつくれるじゃないですか。それまでは黒いコンソールを見て拒絶反応を示していた人に門戸を開いたというか。弊社でもそういう人にRailsを教えて育てるというのをやっていきたいと思っています。全く未経験からRailsを使ってソフトウェア開発に興味を持ってもらって、そこから職業プログラマーに入っていく流れってできないかなって。

一昔前の常識からいえば、RailsGirlsって結構無謀なことやってますよね。

PCとか全く触ったことありませんみたいな女性に、一日でscaffoldでCRUD機能を実装して、画像をアップロードして、Herokuのアカウントを取って、インターネットに公開して、ブラウザでスマホから見れましたってところまで持っていっちゃうんですけど。結構すごい意欲的なプログラムになっています。

Railsはそれが可能なプラットフォームなんです。動作するアプリケーションが最短で作れる道具立てが揃っている。とりあえず動いたという成功体験を植え付けて、興味がある人はそこから戻って深掘りもできる。

昔のプログラムの教え方って逆なんですよね。Hello, world!からはじめて、制御構造を習って、アルゴリズムの勉強して、ってボトムアップに進んでいくじゃないですか。途中で挫折する人は多いですよね。

RailsGirlsを卒業してプロになってる人も居るんですよ。東京でも何度も開催してるからだいぶ増えてきましたね。それに限らず、今の若いRailsプログラマの人って、最初のプログラミング経験がRailsだったって人も多くなってきましたね。

最初は難しいことを知らなくても、知的好奇心があれば、後追いでも遡って深掘りはできるんですけど、その段階でちゃんとメンターやコーチが居るほうが望ましいですね。

── 興味を引くところまでscafflodで持って行って、そこから興味のある人はRails Tutorialをやってもらうとか

今はRails Tutorialみたいな完成度の高いものが無料で公開されていて、本当にすごいことなんですけど、あれはコミュニティの産物っていうよりは単にMichael Hartlっていうバケモノが一人で書き上げた超大作だったりします。

そういう強烈なキャラクターが登場してくるところもRubyコミュニティの懐の深さではあります。

それよりも初学者にとっての問題は、Googleっていうとても良くない道具があって(笑) 自分がわからないことを日本語で適当にググると、絶対に間違った答えに辿りつくんですよね。そこは普通に一次ソースをちゃんと見てくださいっていう習慣を最初につけておくことが大事です。

── 弊社に今Rails Tutorialをやらせている新卒のエンジニアがいますが、1週間で終わらせてきました

新しい技術を覚えるときってそういう瞬間がありますよね。すごいスピード乗っちゃうときって。もう最高に楽しい瞬間ですね。是非そのまま突っ走ってもらえれば良いかと思います。

エンジニアの価値を高めること

── エンジニアとしての自分の価値を高めるにはどうしたらいいでしょう。

やっぱり僕の知ってる範囲では、コードを晒すことですかね。コミュニティでプレセンスを作って。その場合すでにあるものと同じものを作っても無価値なので、他人がやってないことができると良いですね。

僕の場合は、それが運良くなぜかあまりみんながやってなかったRuby on Railsでした。日本人全然やってなかったんですよ。もっとみんなRailsの開発やればいいのにと思うんですけど。自分が好きで飛びついたらそれが流行っちゃって（笑）

まつもとさんがちょうど Twitter で言ってましたけど、

ベイエリアで話してたスーパーエンジニアになる方法
1. オープンソースソフトウェアを開発する
2. 世界中で使ってもらう
3. それをてこに知名度を上げる
わずか3ステップ

つまりそれです(笑)

僕らOSSエコシステム側の人間としてはその道を推したいですね。

── 当時会社に所属しながらOSSを作っていたんですよね

作っていたというか、Railsでアプリ作っててRailsのバグを踏んだら、それを直さないとお客さんが困るじゃないですか。プラグインとかも同じで、kaminari に関しては、当時リリース直後のRails 3.0をプロダクションに投入して作ってたアプリがあって、そこで誕生しました。

当時 ERR THE BLOG っていう、Railsプログラマーならみんな読んでるブログがあったんですけど、まぁそのブログを書いてるChrisっていう人とPJっていう人が作ったRails 2時代のページネーションプラグインがwill_paginateってやつですね。

ところが、彼らが自分たちの会社を立ち上げてすごい忙しくなって、世間ではもうRails 3.0をみんな使いたがってるのにそのあたりのプラグインとかのメンテが完全に止まっちゃっててユーザーたちがめちゃめちゃ困ってた時期があったんです。

で、僕もそこでどうにかしなきゃいけなかったので、じゃあ作るか、って思って作ったのがkaminariですね。

ちなみにwill_paginateのほうは、だいぶ後になって彼らの自社プロダクトをRails 3に上げるときにRails 3対応を果たしました。ちなみにその彼らのプロダクトっていうのがご存知GitHubです。つまり、GitHubの創業期とRails 3対応の時期とwill_paginateが腐った時期が重なってるんですよね。