Ruby on Rails: DHHのインタビュー

以下の文章は、Edd Dumbillによる「Ruby on Rails: An Interview with David Heinemeier Hansson」の日本語訳である。

O’Reilly Media, Inc.の許可を得て、ここに掲載する。

プログラミングの世界で誰も無視できない最新のスタープラットフォーム——Ruby on Rails。そして、そのRailsの作者であるDavid Heinemeier Hansson。彼は、今年のOSCONで観衆を大興奮の渦に巻き込んだ。10月にはアムステルダムで開かれるEuropean O’Reilly Opensource Conventionで基調講演を行う予定だ。

Heinemeier Hanssonはデンマークのコペンハーゲンに住んでいる。彼は、革新的な企業37signalsのパートナーであり、プロジェクトマネジメントWebアプリケーション「Basecamp」の作者でもある。O’Reilly Networkは彼にRailsの成功と今後について話を聞いた。

Ruby on Railsの成功について

Edd Dumbill: 現在、Railsは非常にポピュラーになってきていますけども、2004年を振り返ってみて、こんなふうにポピュラーになると思っていましたか？

David Heinemeier Hansson: 「はい」でもあるし「いいえ」でもありますね。Railsがこんなにも恵まれるなんて予言できないですよ。そうなるっていう計画もありませんでしたしね。ただ、イケるんじゃないかっていう感覚はありました。自分でRailsを使ってみて、そう感じていましたから。それに、もしこれを使うことで今までの伝統的な手法よりも楽しく、生産的にできるんだったら、他の人にもそう感じてもらえるんじゃないかって考えていました。

私には2つのプログラミングのバックグラウンドがあるんです。ずっとPHPを使ってきまして、そういうときはなんでもかんでも早く作るんですけど、とにかく結果が重要なんですね。大学ではJavaの勉強をしてまして、J2EEの仕事もたまにやってたんですが、そういうときはパターンやプラクティスを使って、精度の高さだとか保守のしやすさなんていうのを気にするわけです。

私はこの2つのソフトウェア開発手法に挟まれてたんですね。PHPに代表されるような「早いけど汚い」手法と、Javaに代表されるような「遅いけどキレイ」な手法にです。それで、両者を組み合わせたら、究極の目標である「早くてキレイ」になるんじゃないかと思ったわけですよ。まあ、せめて、両方の人たちにアピールするくらいはできるんじゃないかなって。

ED: Railsがポピュラーになった要因は何でしょう？

DHH: 要因はひとつではありません。Railsには大きなイノベーションがいくつもあって、それぞれが特筆すべきものだし、「これがあるから」というものなんです。具体的じゃないですし、一言で言えるものでもないので、Railsの成功要因を説明するのは難しいですね。

ですが、ある要因に注目してみましょう。Railsは、「”こだわりのある”ソフトウェア（opinionated software）」なんです。まず、ソフトウェアの古い考えを無視しています。古い考えとは「柔軟性」のことです——できるだけ多くのことに対応できるようにってやつですね。この考えそのものは批判すべきものではありませんが、Railsではこれを無視しています。だからこそ、Railsはうまくいっているんだと思います。

Railsでは、アプリケーションレベルの柔軟性を得るために、インフラレベルの柔軟性を犠牲にしています。私がRailsの中に組み込んだ「黄金の道」に沿って開発を行えば、ものすごく生産性が向上します。アプリケーションレベルでは、より多く、より早く、より良いものが開発できます。

ただしこれは、タダで手に入るというものではありません。コーディング規約にまつわる長年の争いを考えてみてください。「括弧をどこに置く」などといったキマリにみんなが従えば、コードは読みやすく、整形されたものになるでしょう。ただし通常、これはあまりうまく機能しません。規約に従うことで得られるメリットが、全然魅力的ではないからです。チームのコードが整形されることなんて、プログラマ個人の「自由」に比べたらぜんぜん重要じゃないわけですよ。

Railsも基本的にコーディング規約がやってきたことと同じようなことをやろうとしています。ただ、コーディング規約と違ってうまくいってるのは、その規約が甘いからです。コードが整形されるだなんて抽象的だし、グループの目標に過ぎません。一方、アプリケーションが以前の数分の一の時間で出来上がるというのは、非常に具体的だし、やりがいのある目標です。

“こだわりのある”ソフトウェアの特徴のひとつに「conventions over configuration」があります。クラス名は単数形でテーブル名は複数形（personクラスがpeopleテーブルと関連している）といった基本的な規約に従えば、クラスとテーブル間のリンクの設定をする必要がありません。クラスが自動的に永続化のためのテーブルを判別します。Railsにはそのような例がいくつもあります。すべてをまとめると、ものすごい違いになりますね。

ED: 37signals以外で、今までに一番驚いたり面白かったりしたRailsの使用方法は何ですか？

DHH: 43things.comの成功には驚きましたね。Robot Co-op は、おそらくRailsを最初に使った「メジャー」企業でしょう。Railsのリリース直後でしたからね。彼らは、自分達の仕事に対するモチベーションが非常に高かったのです。人々の人生の目標達成の手助けをしてあげるという仕事です。ただ好きというだけじゃ、なかなかそこまではできませんね。

しかも、これ使うとマジで目標達成できちゃうんですよ！

ひとつは、OSCONで基調講演を行ったときのことです。Nat Torkingtonが私の目標リストを見て連絡をくれたんですが、私は目標に「Railsの基調講演を500人以上の観客に聞いてもらう」と書いてたんです（訳注：http://www.43things.com/things/view/5761）。それで、今年の8月にあった OSCONで、実際に2000人の観客の前で基調講演を行うことができたんです。

基本的に、Railsが急速に幅広く受け入れられたというのは非常に嬉しいです。私たちは実経済をフレームワーク中心に回しているんだなぁということが分かりました。Railsで仕事をしている人のリストを作ってるんですけど、40カ国以上3000人もの人がRailsを使っています。なんか、夢でも見てんじゃないかと思いますね。

ED: Railsの機能で好きなところはどこですか？

DHH: Railsがあれこれやらない、というところですかね。Railsにはやらないと決めた機能ですとか、却下した余計な装飾品ですとか、そういうのがたくさんあるんですが、Railsにある20%のソリューションで問題の80%を解決できるようにしています。

細かなところでは、ドメイン特化言語がすごく好きですね。リレーションシップをbelongs_to、has_one、has_many、 has_and_belongs_to_many と書けるのなんて、美しいじゃないですか。validates_presence_of :name とかやって、バリデーションが簡単にできるのもいいですね。

プログラム言語について

ED: Railsを始めたとき、正直、Rubyに触るのをためらったんですよ。あまり聞かない言語ですしね。どうしてRubyを使い始めたんですか？

DHH: Railsの開発を始めたのは2003年の夏なんですが、その頃37signalsでは、Basecampの開発に取り組もうとしていました。コンサルタント会社から開発会社に移ろうとしてたんです。その頃はまだPHPを使っていて、作業が楽になるように再利用可能なフレームワークを作ろうとしていました。実際、Railsの初期段階ではPHPを使って作っていました。だけど、なんか、嬉しくないんです。

その時が続けるかどうか（love it or leave it）の瀬戸際でして、もしWebアプリケーションの開発を今後も続けるのであれば、我慢して使うものじゃなくて、心から愛せるツールを使うべきだって思い立ったんです。ツールを切り替えることに対しては、特に問題はありませんでした。

それから、私は達人プログラマの2人とMartin Fowlerの大ファンなんですけど、それも関係していますね。彼らから何度となくRubyの話を聞くんです。 友達もRubyをちょっと触ってみたらしく、なんでPHPを止めないんだ、なんて言うんです。

それからしばらくは自己弁解モードでした。Rubyに変更しないための理由を作っていました。その頃、37singnalsでは、Rubyを知るプログラマを見つけることができませんでしたし、PHPだと多くの良いライブラリがあって、それまで使ってきたわけですし……。ただ、ありがたいことに、そういった状況は長くは続きませんでした。私自身がRubyを試すと決めたからです。

一日経つと「Rubyが本当に好き」になり、一週間経つと「PHPには戻れない」状況になりました。Rubyの熟練度がPHPでのそれを上回るには、一ヶ月もかかりませんでした。Rubyは、それはもう、ものすごくフィットしたんです。私の脳に完璧にフィットしました。それからは楽しく、より良く作業が行えるようになりました。

これだとPHPが悪く聞こえるかもしれませんが、そうではありません。PHPには感謝しています。プログラミングをPHPで始めたのも、PHPの即時性があったからです。長年、よく頑張ってくれました。ただ、私はもう、これまでPHPのスイートスポットだと思っていた場所の「外側」にたどり着いたんです。 Rubyのスイートスポットは、まさに今私が必要としている場所なんです。

ED: RailsをJavaやPythonで書いていたらベターになっていた点はありますか？

DHH: 「ベター」という言葉は曖昧ですし、比較する際に使うもんじゃないですね。Javaがいいか悪いかは別として、RailsがJavaで書かれていたらもっと企業から引き合いを受けていたでしょう。ただ、成功すればいいというものではないのです。Railsを作ったのは、自分の仕事をより良く、より速くするためです。企業に取り入れてもらうためではないのです。企業に取り入れてもらったら、それはそれでいいことではあるのでしょうが、意識的にやってたら、うまくはいかなかったでしょう。

Pythonに関してはあまりよく知らないんですが、Rubyと非常に似ているみたいですね。ただ、作ってる側からすると、少しの違いでも大きな違いに感じられるんです。Pythonにもクールな機能が多くあると思います。Rubyがなかったら、Pythonを使っていたかもしれません。

Railsには、Rubyと同じ感触、同じ匂い、同じ味わいがあるんです。RailsはRubyと密接に絡み合いながら動いています。例えば、ブロック（DSLを簡単に作れる機能）などがそうです。

ED: 今でもWebアプリケーションをPHPやPerlで書こうと思いますか？

DHH: もちろん！ Railsは常にすべての人にとって完璧というものではないんです。動的なコンテンツをババっと仕上げたいときなんかは、今もPHPをよく使ってますよ。 37signalsのマーケティングのページはすべてPHPで書かれています。コンテンツが少ないですからね。

一方、Railsのスイートスポットは非常に大きなWebアプリケーションです。ですから、（Railsで作られた）Basecamp、 43things.com、ODEO、Strongspaceといったアプリケーションを作るのにPHPやPerlがオススメかと聞かれたら、「いいえ」と答えます。

PHPやPerlをどうしても使わなきゃいけないという環境にいる人もいると思います。 ですが、そういった環境が絶対変わらないと考えるのは間違いだと思います。 たとえば、スタッフの中にRubyプログラマがいないからRailsを使用できないとか、 もうすでに別の環境を使ってるから切り替えることができないとか。 そんなのぜーんぶ、ナンセンスです。 良いプログラマというのは、どんな言語を使っていても、やはり良いプログラマなんです。 Railsは、あなたが考えるよりも、今まであなたがやってきたことに似ています——当然、楽チンにはなってますけど。

Webアプリケーションフレームワークについて

ED: Railsで気に入ってるのは、プロダクションと開発環境が区別されている点です（訳注：productionモードとdevelopmentモードのこと）。 こういった機能がスクリプト言語Webツールに組み込まれていることはあまりないように思います。意図的に「エンタープライズ」な機能をRailsに入れたのでしょうか？

DHH: これは自分のために入れました。Railsは、この点については、とても自己中心的なプロジェクトなんです。そこは非常に注力してきました。というのも、私と同じ問題を抱えている人たちを喜ばせたかったからです。プロダクションと開発環境を区別したのは、私にとっての現実的な問題です。だから、できる限り最善の方法で問題を解決したのです。

ただ、みなさんの問題をうまく解決するのは難しいと思います。 他人の問題を解決しようとするのは面倒なことですし、ほぼ無理です——ソリューションに興味があればやりますが。

だから我々は、親愛なるRailsコミュニティにおいて「frameworks are extractions（フレームワークは抽出されたものである）」と掲げたのです。 フレームワークは事実より先に設計されたものではありません。 その中でアプリケーションが動くことを証明したときに抽出されるものです。 先に行き過ぎて抽出プロセスを飛び越えてしまうと、 あとで後悔することになります。

多くの人がRailsを正しいと感じているのは、実際の案件に使われてきたことで、他の人でも再利用しやすくなっているからだと思います。

ED: リレーショナルデータベースは使用方法の90%をカバーしていますが、他のバックストアを使った方が扱いやすい場面もあります。他のバックストアを追加する考えはありますか？例えば、オブジェクトデータベースやRDFデータストアなどがありますが？

DHH: Railsはどんなモデルでもサポートしますよ。Instikiという私が作ったWikiがあるんですが、これを最近Railsにポートしたんですけど、まだMadeleine（PrevaylerのRuby実装。オブジェクトデータベースみたいなもの）をバックエンドに使っています。

ですから、Active Record以外のバックエンドを使うというのは簡単です。 最近では、SOAPやSAPやLDAPなんかを使ってるユーザーもいます。 プレインテキストファイルでもOKです。なんでも大丈夫です。

Active Recordがオブジェクトとリレーショナルのミスマッチらへんの面倒な作業をある程度軽減してくれていますので、代替案を探そうという気はないんですが、SQLiteのようなデータベースなんかは、SQLを使うんだけど、まるでテキストファイルを使っているかのような感じで、いいですね。

個人的にはActive Recordが改良されるにつれ、Madeleineのようなプロジェクトへの熱意が少し弱まってきています。これは、他のアプローチがクールじゃないということでもありませんし、他のアプローチだから熱意を持てないということでもありません。

ED: Webフレームワークの多くが、巨大になったり、管理しきれなくなろうとしています——Zopeなどがそうですが。それについて、Railsに何か戦略はありますか？

DHH: インフラの下に隠れる。ビジネスロジックをバックドアに入れない。などですかね。コンテンツマネジメントやアクセスコントロールリスト、フォーラムやチャットなどというのは、Railsの対応範囲ではありません。Railsは一般的な構造を持っていますので、どんなアプリケーションにも使えます。

ですから、ZopeやOpenACS、その他、ビジネスロジックの沼にハマって抜けられなくなったフレームワークのようにはなりません。

どんなアプリケーションにも、多くの人が多くの時間を使っていることがあります。我々はそういった仕事をより簡単にしたいと思っています。例えば、 Railsの次期バージョンに向けて、SwitchTowerというサブプロジェクトを準備中です。 これはアプリケーションをサーバにデプロイする際の問題を解決してくれます。 デプロイの問題はほぼすべてのアプリケーションが抱えている問題ですが、 初期段階のデプロイはそれほど難しくはなく、開発プロセスも複雑ではありません。 ただ、後で問題となるときをじっと待ち構えているのです。

ED: Railsの今後についてお聞かせください。

DHH: ヒント：SwitchTower。これは新しい主な変更点になると思います。ただ、もうすぐ1.0をリリースしなければなりません。今は最終調整に入っています。

その後にもいろいろ計画があります。Conductorなどがそうですね。ただ、”彼”についてはもうしばらく秘密にしておこうと思います。

編集者注：このインタビューの韓国語版 と日本語版があります。

Edd DumbillはO’Reilly Networkの編集者で、『Mono: A Developer’s Notebook』の共著者です。 GNOMEのフリーソフトウェアや、Debian GNU/LinuxのBluetooth関連のソフトウェアの作者でもあります。Behind the Timesというウェブログも書いています。