Chad Fowler on Ruby

本記事は PragPub Issue 18, December 2010 に掲載された Michael Swaine によるインタビュー記事 “Chad Fowler on Ruby” を原著者の許可を得て翻訳・公開するものです。

訳した人: O-Show, かくたに

Chad Fowler on Ruby

Ruby のパイオニアへのインタビュー

インタビュアー： Michael Swaine

Ruby に夢中になった人びとが出始めた頃から、Ruby がシリコンチップに載り、携帯電話で使われるようになる将来まで。Ruby コミュニティの伝説的人物がこれまでをふりかえり、その見識とこれからの期待を私たちに語ってくれます。

――色付きの球体をおかしなテキストやひどい「音楽」と共に画面上に飛ばす。そんな子どもらしい事を Commodore 64 上でやったのが、Chad Fowler のプログラミングのはじまりでした。それから何年かして、彼はプログラミングこそが自分の思いを実現してくれる存在だと気づいたのです。

彼の人となりはどうでしょう。Chad と出会って人生が豊かになったという人は皆、彼のさまざまな手腕を強調します。教師として (Pragmatic Studio での Dave Thomas との共同講習、いくつかの素晴らしい書籍の著者、数多くの講演やカンファレンスでの基調講演) 、ひっぱりだこのコンサルタントとして (毎年たくさんの国からコンサルタントとして招かれます) 、熟練のソフトウェア開発者として (現在は InfoEther の CTO であり、それ以前もいくつかの世界的大企業で開発者やマネージャを務めていました) 、Ruby コミュニティへの惜しみなき貢献者として (RubyConf の主催者であり、RubyGems の共同開発者でもあります)。Memphis のバーでのサキソフォン奏者としてのキャリアについて言及する人もいます。

Chad がいかに寛大であるかは、私たちの素朴な質問への回答からもよくわかります。彼は、Rubyという、いま最もエキサイティングな言語にまつわる彼自身のあざやかな記憶と深い洞察を惜しみなく私たちと分かちあってくれるのです。それでは Chad、よろしくお願いします。

Rubyとの出会い

――いつ、どうやって Ruby と出会ったのでしょうか？

世紀の変わり目の頃 (今となっては、こんな風に言えるのが気に入ってるんだよね) 、僕は土曜日の午前中は新しいプログラミング言語を学ぶようにしていたんだ。Dava と Andy が『達人プログラマー』で書いてた「毎年一つの新しい言語を学ぶ」の僕なりの拙速なバージョンだ。いつも新しい言語の実行環境やらコンパイラをダウンロードしてドキュメントを読んで、その日のうちに何かしら使えるプログラムを書いていたんだ。試すのは、まだ僕が使ったことのないメインストリームの言語だったり、Befunge とか Ook、Malbolge といったまったくもって奇妙な、わけのわからない言語だったりした。Lojban みたいな「人工言語」のことを調べたこともあった。どれを試すときも、今までと違った見方を与えてくれたり、自分では考えもしなかった表現の仕方を求めて取り組んでいたんだ。

それと同時に、これから自分はどのプログラミング言語に最大限に専念すべきかという意思決定のプロセスも進めていた。それまでの数年間、僕は Java を使っていて、付き合いもだいぶ深くなっていた。JVM そのものもかなりいじっていたし、自分独自の小さな言語を JVM のバイトコードへコンパイルしたりもした。いよいよ Java から学べる限りのことは学んだと思うようになった。Java は大好きだったけど、でもそろそろ新天地に向かうべきだ、ってね。

ちょっと余談になるけど、僕が副業を探している若いミュージシャンとしてIT産業で働きはじめた頃、幸運にも僕は自分を導いてくれるメンターに出会えたんだ。当時僕はシステム管理に力を注いでいたんだけど、彼は僕に魔法のアドバイスを授けてくれた。今の僕があるのはこのアドバイスのおかげだと確信してる。彼は僕に三つのテクノロジを学ぶように言ったんだ。お互いに大きく異なっていて、違った考えかたをさせるようなもので、しかも職務経歴書で見栄えがするようなものを学ぶように、と。僕の場合、これが当初からとてもうまくいったから、まさに文字通りの「成功するキャリアのつくりかた」のレシピを与えられたみたいだった。だから当然の帰結として、僕はプログラマとして自分のキャリアを重ねていくことにしたんだ。

そして僕は全力で Smalltalk に飛び込むことに決めた。動的な言語だったし、イメージを永続化するという、当時の僕には馴染みのない妙なコンセプトを備えていたし、すごく小さな文法しかなかったから、言語のスペクトラム上で Smalltalk が Java から遠く離れたところにいるというのは皆にも同意してもらえると思ったんだ。理由はそれだけじゃない。Smalltallk は新進気鋭のアジャイル開発コミュニティ (当時は誰も「アジャイル」だなんて言ってなかったけど) の、僕がとても尊敬するプログラマたちが使ってたんだ。これを決めたのは、平日の仕事も落ち着いた金曜日の午後だった。

翌日の土曜日の朝、僕の気持ちはまだ Smalltalk の中心を目指す旅を始める気満々ではあったんだけど、いつもどおりのことをした。ウェブブラウザを起動して「今週の言語」を探しはじめたんだ。いちばん最初に僕が Ruby のことを知ったのはどこでだったかのはよく覚えてないんだけど、この土曜日の朝、『達人プログラマー』の Dave Thomas がエクストリーム・プログラミングのメーリングリストに投稿したメールがきっかけで、僕は「今週の言語」に Ruby を選ぶことにした。

僕はすぐに文法を調べて、ERb (“Embedded Ruby”) を見つけた。そして、 MySQL をバックエンドにした CGI フレームワークとして Ruby を使って、自分のブログシステムを書き直してデプロイした。お昼ごはんを食べる頃にはだいたいできていたかな。このときまでにそれなりの数の「今週の言語」をこなしていたんだけど、こんなに早く進められたことはなかった。どうかしてると思ったよ。日曜日になって、僕はまた Ruby を使った。月曜日の夜、仕事が終わったあとも。次の日も。また次の日も。

Ruby と出会って良くなかったのは、結局 Smalltalk が上達しなかったことだね。

黎明期

――日本以外ではごく限られた人しか知らなかった頃に、あなたは Ruby と関わりはじめました。当時の Ruby の世界はどんな様子だったのでしょうか？

2000年に僕はケンタッキー州ルイビルというイノベーションの不毛地帯にいた。そこで僕は、ひらめきを得られるようなクリエイティブなソフトウェア開発者のプロフェッショナルなコミュニティを探し求めて、よくインターネットを見てた。Ruby の状況も僕の境遇と似たようなものだった。僕は当時ルイビルで Ruby を使っている唯一の人間だと確信したよ。同僚たちに Ruby を紹介してはみたものの、僕が Ruby に言及するとよくクスクス笑ってたよ。彼らはたぶん、シートに「Ruby」としか書いてないバズワード・ビンゴで遊んでたんじゃないかな。Chad はどうかしちゃったか、ふざけてると思ってたんだろう。僕は彼らを責めたいわけじゃないけど、西洋での最初期の Ruby の受容のされかたがどんなだったかという雰囲気は伝わるんじゃないかな。その後も僕のいたチームでは相変わらず僕だけが「誰よりも賢くなれる特別招待券」を持ったままだったよ。他のみんなは僕がどうかしてると思ってたね。

それで僕はたくさんの時間を IRC やメーリングリストで色んなことを話すのに費しながら、いつの日か Ruby が幅広く受け入れられて自分の仕事に使える言語になることを夢みてた。freenode の IRC チャンネル、#ruby-lang にはいつも 10〜15人ぐらいいたね。英語の Ruby メーリングリストは流量は少ないながらも高品質なやりとりが交わされてた。この頃が最初の一歩だった。僕はメインストリームの IT プログラマの世界から遠く離れて、ソフトウェアのパイオニアたちの領域へ足を踏み入れたんだ。Ruby にかかわった誰もが天才だとか、思想的指導者だとか、歴史を形づくるべき定めにあったとか言うつもりはないよ。ただそこには小さなコミュニティがあった。集まっていた人たちはみんな、自分以外には周囲に誰も使ってる人がいないツールを使っていて、他の人たちにも使ってほしいと思ってた。だって、Ruby を使ったほうが気持ちいいし、生産的になれたからね。この動きは、小さいけれども世界規模の広がりがあったよ。平凡であることへの抵抗のサイン。僕には Ruby が他よりすぐれているかどうかの確信なんてなかった。僕にわかっていたのはただ、Ruby を使ってるときや、小さな Ruby コミュニティのみんなとネット越しに交流していると、自分が賢くなったように感じてたってことだけだった。

ところで、当時は「コミュニティ」っていうのは日本以外の全世界的な Ruby ユーザの集りを形容するのにふさわしい言葉だった。もちろん日本にも「コミュニティ」と呼ぶにふさわしい、活発なグループがあるだろうことはよくわかってた。でも僕は日本語を話せないから (いまだにね！) 、どうやって確かめたらいいかわからなかった。で、当時の僕らのコミュニティは、だいたい全員がお互いのことを知っていた。一緒にソフトウェアをつくったりドキュメントを書くためにメーリングリストや IRC で繋っていたからね。なつかしい地元のコミュニティ BBS みたいな感じだった。もし僕らがみんな近所に住んでたら、毎年ボウリング大会を開催したと思うよ。

それと、早い時期からエクストリームプログラミングのコミュニティ (あそこも当時は「コミュニティ」だった) からもどんどん人がやってきた。だから当時のプログラマたちは、まだそんなにテスト駆動開発を話題にしてなかったけど、ほとんどの Rubyist は TDD のことをよく知ってたよ (積極的に実践はしてなかったとしてもね)。

僕もいくらか年をとったから「あの頃は良かった」みたいに考えてるんだろうとは思うけど、それは僕が年をとった証拠というよりは、実際にあの頃が良い時代だった証だと思うんだ。他のみんながやっていることとは違う、これまでのやり方をひっくり返すような新しい何かの一部になるっていうのはわくわくするよ。その一方で、海のものとも山のものともわからないものに多大な労力を投入するのは怖いことでもある。僕らはみんな承知していたよ。Ruby は死んでしまうかもしれないし、永遠に流行らないかもしれないということを。僕らの多くは愛とナイーブさ、それから信念にもとづいて Ruby に取り組んでたんだ。

当時 Ruby に取り組んでた職業プログラマについて僕が言えることは、自分の昼間の仕事で Ruby を使っていた人はほとんど誰もいなかったということだ。あの頃の Ruby コミュニティで開発されていたのは、ドキュメンテーションツールやコードブラウザみたいな、言語自身に関するものがほとんどだった。僕自身も 仕事での Ruby の使いかたはバックエンド処理やスクリプティングだった。他には Java コードを生成するのにも使ったけど。おかげで時間を節約できたね。当時の僕らの多くはこんな風に舞台裏で Ruby を使っていたと思う。

Ruby on Rails

――Railsの衝撃はいかがでしたか？

2004年の中頃に、僕らの小さなコミュニティの死を告げる鐘の音が聞こえてきた。発生源はデンマーク。その名は Ruby on Rails。いま僕が「死」と言ったのは、さっき話した我らが小さなコミュニティに限った話だ。Rails は僕らと、僕ら以外のたくさんの人たち、これまでに Ruby を使ったことのなかった人たち(それから今もまだ使ってない人たち)の状況を変えてしまった。

僕は Rails のことを知ってたし、妻と一緒にやってる小さな非営利組織向けのアプリケーションも Rails で構築していた。ネット越しだけど David Heinemeir Hansson とも面識があったし、RubyGems の問題で彼を手伝ったこともあった。そんな僕でも、ヴァージニア州シャンティで開催した RubyConf 2004 の開催前夜のことが強く印象に残ってる。僕はいつも会場設営の手伝いがあるから早めに現地入りするんだけど、空港に着いたときからいつもと違っていた。会う人みんながこう聞いてくるんだ。「David Flanemeyer Landon とかいうヤツはまだ来てないのかな？」だいたい発音を間違えてたね。みんなが彼に会いたがってて、Rails の話をしたがっていた。

僕はびっくりした。というのも、僕にしてみれば Rails なんて、数ある Ruby 製の Web フレームワークのひとつに過ぎなかったんだから。Ruby には Iowa とか Arrow とか他にもたぶんあなたは聞いたことがないようなフレームワークがたくさんあるからね。Ruby を Web アプリケーション開発に使ってる人は、僕が Ruby を使い始める前からいたわけだし、僕にとって Rails は誰も使ってないニッチな言語で書かれた、ただの MVC フレームワークだった。僕は Rails を気に入ってはいたけれど、そんなに多くは期待してなかった。

けれども RubyConf 2004 でそうじゃないことを僕は確信した。Rails とその作者は、カンファレンスの中心勢力だった。それから、DHH がちょっと見たことない感じのプレゼンテーションをしたこともよく覚えてる。彼は自分の持ち時間を Rails の技術的な詳細を話すのに使わなかった。あれはまるで大当たりするマーケティングキャンペーンのやり方とか、注目を浴びるプロダクトの作りかたについてのプレゼンみたいだったよ。彼のプレゼンは RubyConf が慣れ親しんでいた話題とは根本的に違ってたし、すごく興味深いのは、DHH は将来実現することになる Rails の成功が、あの時点で既にもう起きてしまっていたかのように話してたことだ。その戦略はうまくいったように僕には思えるし、彼はあれ以来これを繰り返し続けているようにみえる。

この RubyConf 2004 が 9 月下旬。そのあと 2005 年の 7 月に DHH は O’reilly Open Source Convention(OSCON) という大規模なオープンソースの (僕がささやかな Ruby トラックを存続させるのに必死になってた) カンファレンスで基調講演をした。OSCON 2005 は日程も場所も時間も、どれをとってもこれ以上ないぐらいメインストリームの開発者たちに Ruby の存在を (Rails を通じて) 気づいてもらう絶好の機会だった。それで水門は開かれて、ありとあらゆる方面から開発者が Ruby コミュニティに流れ込んできた。PHP プログラマや HTML コーダからゴリゴリの Java や .NET 開発者やアーキテクトまで、やってきた人材は幅広かった。他のプログラミング言語コミュニティでよく知られていた開発者がどっぷり Ruby に頭の先から飛び込んできたこともあったし、そのなかには自らを Rubyist だと再定義する人まで出てきたんだ。

そして Ruby と Rails の書籍が書店の本棚からあふれ出はじめた。普通の企業が Ruby による開発を視野に入れだした。Ruby を自分たちのビジネスの主力製品に採用することが増えた。そう、Ruby で仕事ができるようになったんだ！

けれど一方でこの出来事は、それまで長い間、 Ruby を愛する気持ちから作業を続けていた、僕らのコミュニティの一部にとってはとても残念な話でもあった。Rubyが「ウェブ言語」になっちゃったわけだから。Rails の影響はそれぐらいすごかった。しばらくの間、Ruby と Rails の違いがわからない開発者たちとやりとりする光景によく遭遇した。「Ruby on Rails」はそれ単体で存在するものであり、プログラミング言語でもなければフレームワークでもない何かだったんだ。

そうはいっても、感じていたのは不信よりも圧倒的な感謝の思いのほうが強い。僕たちはみんな、Rails の到来によって待ち望んでいたこと以上のものを得たんだ。これは昼間の仕事で堂々と大好きな Ruby を使っていいという環境だけじゃない。素晴しい Web フレームワークと、これはまずいだろうという考えに囚われすぎていて、ほとんど誰も気づいてすらいなかったアイデアを光り輝かせる格好の事例という、イノベーションの肥沃な土壌の両方をまとめて手に入れたんだ。

Rails on Ruby

――Rails は Ruby 自身の開発に影響をおよぼしましたか？　他に Rails の発展に影響をおよぼした外部要因があれば教えてください。

Rails は確実に Ruby の開発へも影響を与えた。Matz が Ruby でやりたいことを Rails が牽引するようなことは無いにしても、社会的なプレッシャーの下で、言語の受けとめられ方(と、対話に使う自然言語)は大きく変わったんじゃないかと思う。この時点ではもう、多くの Ruby 開発者にとって Rails が Ruby への入口になっていた。というのも、彼らが最初に出会う Ruby を使ったサンプルは Rails のフレームワークのコンテキストに沿ったコードだからね。最初に学ぶ API は Rail の API だ。コーディング規約も、用語も、簡潔であることと冗長であることとのトレードオフに期待することも、すべて最初は Rails を通して学んでいるんだ。

Rails 以前を思い返してみると、Rubyist に広く受け入れられる決定版のコーディング規約なんて、とても作れるとは思えなかったね。ほんとうに色んな流派があったんだ。メソッド名をキャメルケースで定義する人たちもいれば、ライブラリのコードは単一のファイルにまとめる流儀の人たちもいた。パッケージ作成に至っては install.rb 派と setup.rb 派と RubyGems 派がいたよ。

Rails は実際のコードで示すことでコーディングスタイルをうまく根づかせた。例えば「キーをシンボルとしたハッシュを追加オプションとして渡すメソッド」というのは一般的になったと思う。こんな感じのやつだ。

Botanist.find(:all, :conditions => {:first_name => "Bobby"})

今となっては受け入れてるけど、当初こういうコードは僕には目障りで醜いコードに見えてた。けれどもあまりに Rails で頻繁に使われるものだから、いつしか当たり前のことになってしまった。事実、Ruby 1.9 では「ハッシュのキーにシンボルを使う」という規約は簡潔さの新たな次元に突入している。

Botanist.find(:all, conditions: {first_name: "Bobby"})

こうなるのが言語の発展の必然だったのだとしても、その発展に少なくとも間接的な影響をおよぼした一番手は Rails だと思ってる。

Ruby 2.0 では、Shugo Maeda が「Refinement」と呼ばれる新機能に取り組んでるんだけど、Refinement を使うと特定のスコープの中でだけ Ruby のクラスを再オープンして変更できるようになる。これがあれば Ruby のもつクラスやモジュール、オブジェクトの再オープン機能を安全にやりたい放題に使えるようになる。僕らは Rails が作られるよりもずっと前からこうした機能を待ち望んでいたけれど、Rails がこの機能の需要を煽ったことは確実だ。Rails は既存の Ruby クラスを再オープンして便利メソッドを追加するのが好きすぎるからね。Rails を使えばこんなこともできちゃうし。：

ruby-1.9.2-p0 > 1.day.ago
=> Sat, 27 Nov 2010 00:01:36 UTC +00:00
ruby-1.9.2-p0 > "Botanist".pluralize
=> "Botanists"
ruby-1.9.2-p0 > Object.ancestors.map(&:name).to_sentence
=> "Object, Kernel, and BasicObject"

Shugo の Refinement 実装があれば、こういうことを手軽で便利な仕組みを使ってできるようになる。しかも、その影響を局所的にできるから、今のやり方よりも安全にやれるようになるだろう。

細かいものも含めれば、Rails が Ruby の言語や標準ライブラリに影響を与えている事例はこれ以外にもたくさんある。でもまあ、あなたの質問に手短かに答えるならこうだね。確かに Rails は Ruby の開発に影響を与えてる。

Rails が Ruby に与えたインパクトで他に大きなものがあるとすれば、パッケージシステムとして RubyGems (僕も作者の一人だよ) の普及を助けてくれたことが挙げられる。RubyGems が Rails のインストール手順だったから、Rails が広まれば RubyGems も広まっていった。特に RubyGems を売り込まなくても、Rails が使える環境に向けてライブラリや Ruby アプリケーションを配布しようと思ったら、RubyGems を使うのが一番簡単な方法になったんだ。

RubyGems の普及がもたらしたのは、バザールスタイルのオープンソースのエコシステムだ (Eric S. Raymond が「伽藍とバザール」で定義したあれだ)。バザールスタイルは、モノリシックなオープンソースプロジェクトでよく採用されている、歩みの遅い、保守的な伽藍モデルと対比される。ここで僕らが発見したのは、もし RubyGems を使えば書いたコードを配布するのが簡単になるんだったら、単純なニーズに応えるためのコードを書くための障壁なんて無いも同然だってことだ。

この考えかたがコミュニティで発展した結果が、新しい RugyGems.org だ。これは昨年、Nick Quaranto が開発したもので、新しい gem の公開がコマンドラインで自動化できるようになっている。なので、簡単な問題に対処するようなものなら、解決策を思いついてから gem として公開してアナウンスするまでものの数分でやれるんだ。

こうした動きは今のところは、言語としての Ruby には直接のインパクトは与えてないけれども、Ruby のソフトウェアエコシステムには相応の影響をもたらしてる。Ruby プログラマは、言語や標準ライブラリのサポートが足りなくて身動きがとれなくなるようなことは滅多にないんだけど、欠陥を細ごまと「修正」したものをみんなに配布するというのはよくやってる。こういったことが実現されるようになるのに、Rails が果たした役割は大きいね。

RubyConf

――RubyConf について教えてもらえますか？　第1回とその後どう発展していったのかを教えてください。それから、地域カンファレンスやコードフェストといった現象についてもお話しいただけますか？

僕がいまも Ruby にかかわっているのは、たぶん RubyConf があるからだ。最初の RubyConf は 2001 年にフロリダ州タンパで開催した。元々このカンファレンスを企画したのは Guy Hurst という開発者だった。彼が RubyConf のアイデアを思いついて、ドメインを取得した。ウェブサイトを立ち上げて、会場を手配したのも彼だ。けれど、彼は他のことで忙しくなってしまって、カンファレンスを諦めざるをえなくなってしまった。けれど、Dave Thomas は初めてのカンファレンスを未完で終わらせたくはなかった。そこで彼は David Alan Black と僕を IRC のプライベートチャンネルに招待して、僕らで引き取れないかと相談してきたんだ。

で、僕らはやり遂げた。最初のカンファレンスは僕ら 3 人が主催者だったんだ。参加者は 34 名。参加者の中には著作のある人が何人もいたし、4 人はアジャイルマニフェストへの署名者だった。そして参加者の 1 人は Ruby の作者だった！

最初の RubyConf は、カンファレンスというよりはミーティングみたいだった。プレゼンテーションもあったけど、どれも結局ディスカッションになった。Ruby Application Archive の後継サービス (僕らは RAA.succ と呼んでた) の計画を立てるセッションをやったりもした。

以来、RubyConf は開催都市を変えながら毎年開催してる。みんなが参加しやすいように北米のタイムゾーンでローテーションしてるんだ。2001 年には 34 名だった参加者も、2010 年のニューオーリンズでは約 800 名にまで増えた。2005 年の RubyConf は、Rails がリリースされた直後だったので、史上最速でチケットが完売したよ。以後は毎年チケットは完売してるけど、2006 年からは RailsConf という別のカンファレンスも分離して開催してる。これは RubyConf 2005 で明らかになった、RubyConf に収まりきらない数の参加者と、彼らの興味関心にフォーカスして対応するためだ。

僕は主催する側の立場だからこう言っても許されると思うけど、RubyConf はいつもくだけた感じだし、運営はグダグダでいきあたりばったりだ。だけど、そこに魔法があるんだ。カンファレンスが終わるとみんな、新たなる思いや新しい仲間、時には新しいキャリアをお土産にして家路につくんだ。

RubyConf はいつも米国で開催しているんだけど、2〜3 年ほどすると、ヨーロッパのプログラマたちが自分たちの地元でカンファレンスを開催するのを引き受けてくれるようになった。彼らは自分たちのカンファレンスを Euruko と名づけた。Euruko も RubyConf と同じく、始まりはとても小さかった。開催地をヨーロッパ中でローテーションさせるのもやってる。いま彼らは、持ち回るのは開催地だけじゃなくて、主催団体も毎年、開催予定都市で選出してるようだね。

Euruko が始まってから、RubyConf の運営母体 (Ruby Central という非営利法人になった) は RubyConf よりも頻繁に地域的な集まりが開催されるのを支援できたらいいんじゃないかと考えるようになった。そこで僕らは補助金制度を準備して、コードフェストを開催したい人に金銭的な支援をすることにした。地域で集まって、プロジェクトとして動いている人たちを対象としてね。僕らには RubyConf 2003 からの繰越金が少しあったし、非営利組織なんだから、こうやって余ったお金をコミュニティに還元することに決めた。地域 Ruby カンファレンスの開催支援目的の補助金制度を用意する前に、いくつかのコードフェストを金銭的に補助したこともある。

もしかしたら間違っているかもしれないけど、僕の認識では 2007 年の前半にユタ州で開催された Mountainwest Ruby Conference が米国で最初の地域 Ruby カンファレンスだった。すごくたくさんの人が参加しててびっくりしたことをよく覚えてる。ユタ州では初めての Ruby のカンファレンスだったにも関わらず、200 名の参加者がいた。地元向けの、地域 Ruby カンファレンスなのに。

以後、地域 Ruby カンファレンスの開催される数は爆発的に増えていった。どのカンファレンスにも地域独特の雰囲気と味わいがある。今はこうした地域カンファレンスの取り組みは世界中に広がってる。僕はいくつもの地域カンファレンスに参加して、それぞれの違いを楽しんだよ。そこから RubyConf でも採用するために拝借したアイデアもあったな。

僕が次のステップとして期待していることは、あるテーマに特化したカンファレンスが開催されるようになっていくことだ。今年、またしてもユタ州で……ええと「Ruby Web Conference」という Ruby のウェブテクノロジに特化したカンファレンスが開催された。ひょっとしたら来年は「Ruby MusicConf」とか「Ruby HardwareConf」が開催されるようになるかもしれない。僕はそうなることを願ってるよ。

Ruby の採用者たち

――あなたは出張や講演でたくさんの Ruby 開発者と出会うと思うのですが、そういった人たちがどんなことに Ruby を使っているという印象をお持ちでしょうか？　また、その傾向は年を追うごとに変わっていますか？

最近は、みんな本当に色んなことに Ruby を使っているよ。Web アプリケーション、バックエンド処理、GUI アプリケーション、シンプルな Web サービス。そこら中で Ruby は使われてるよ。通信会社やテレビでも使われてる。Ruby が適用できる領域はどんどん多様になっていってる。2005 年の時点では、たくさんのスタートアップ企業が Ruby を使っているという話ばかりだった。これは又聞きだけど、2006 年前半の Web 2.0 系カンファレンスでは、Ruby を使ってないスタートアップは「どうして Ruby を使わないんだ」と訊かれたらしいね。Ruby を使うのが当たり前みたいな風潮だったんだ。

でも最近はスタートアップ企業に限らず、大企業や政府でも Ruby を使うようになってる。他には、政府を開かれたものにしようとしている人たちの間でもね。世界最大級の企業のなかには戦略的に Ruby へ投資しているところもある。政府機関にもそういうところは多い。僕個人の経験でいえば、ここ数年のあいだに 5 つか 6 つの合衆国政府機関と話し合ったこともある。

世界のなかのRuby

――世界中での Ruby の採用についてはどうでしょう？

Ruby は世界中で使われてるけど、なかでも採用の動きが激しいのは米国とカナダだと思う。思うに、これはアジャイル開発手法や NoSQL、Git みたいな最先端のアイデアと同じぐらい使われてるんじゃないかな。こういうのは北米では早いうちから取りあげられる傾向にある。北米が他の地域よりもすぐれてるという意味じゃなくて、僕らがただ、他の地域よりも新しいもので遊びたがるってだけのことだけど。僕はインドにしばらく住んで働いたときにそのことを学んだ。米国では衣食住は(だいたいにおいて)足りてるから、気にかけることすらしない。家にコンピュータの 1 台や 2 台あるのは当たり前だ。自分が自由に使える時間だってある。もしそうじゃなかったら、愚痴をこぼすと思う。僕らは本当に甘やかされてるんだ。

北米以外の地域では、テクノロジの受容はもっとゆっくりと進む。インドで僕がよく考えていたのは、インド経済はいまだ安定化の最中にあるってことだ。これは、インドでもっとも成功したプログラマでも生活の基本的な心配をしなくてよくなってから、たかだか 2〜3 世代しか経っていないってことなんだ。だから、平均的なインド人プログラマはまだ、プログラミングを楽しみのためにおもしろがってやる、という段階には至ってない。いずれそうなるだろうとは思うけれど、少なくとも今はまだそうじゃない。

インド以外でもそうした光景を見たことがある。なにもかもが経済に駆動されているとは思ってないけれど、絶えまない変化を望むようなテクノロジへの渇望をそなえた文化というのは米国以外で僕はお目にかかったことがないね。ブラジルとかインドのようなところへ行くと、大きな変化を起こしたがっている思想的指導者たちが不満を抱えている姿をよく見るんだけど、基本的な文化的状況は僕らが 5〜6 年前に居た場所に留まったままだね。

僕のなかの一部は、それはよくないことだと感じてる。でも別の一部はそれを羨ましく感じている。だって、革新的になることで自分自身が報われるんだよ :)

JRuby や 他の Ruby 実装について

――Ruby の別実装がすごくたくさんあることについてはどうお考えですか？

Ruby にはいくつか発展をとげている実装がある。ということは、大文字で始まるプログラミング言語としての「Ruby」のコードは、互いにほぼ独立したコードで実装された高品質の処理系のどれかで実行されうる、ということだ。MatzRuby(1.8)、YARV(1.8 に新しい VM と 1.9 向けの文法を拡張したもの)、JRuby、Rubinius、Maglev、IronRuby、MacRuby、Rite など、他にも開発中のものが存在する。どの実装も実際に Ruby コードを実行できる。それぞれの処理系は、他の処理系にはない利点を備えてる。こうした実装のなかには、最先端の本家 Ruby 実装よりも速い部分があったりもする。

Lisp や Scheme の世界以外で、こんなことが起きたことはないんじゃないかな。選択肢が豊富になって、しかも Matz がそのことを喜んで受け入れてる。今年の RubyConf の基調講演でも、処理系の多様性は主要なテーマのひとつだった。Ruby 処理系の実装者たちはお互いによくコミュニケーションをとってアイデアを共有してるし、実装しづらい機能について文句をつけて(えっ)、いつも互いを高めあってる。本家 Ruby 実装も、こうした Ruby 実装者たちの豊かなコミュニティから多くのことを得ているよ。

もしも、 (ニッチな言語だとか、ニッチな VM であるとか、現在の JVM のような商業的な状況になるとかで) あなたが使ってる言語の長期的な生存可能性を気にしたことがあるなら、Ruby のように数多くのオープンソースな別実装があるという状況は新鮮に感じるんじゃないかな。もしも、本当に本当になにかまずいことが起きて、Matz のインタプリタ実装がどうかなってしまって危機的な状況に陥ったとしても、瑣末な変更を施すだけで JRuby に切り替えられるかもしれないんだ。これはすごいことだよ。

Ruby の文化

――Ruby 独自の文化というものはあるでしょうか？

僕は、Ruby のエコシステムに文化的な意味合いがあると思う。処理系の開発はバザールモデルになってる。ライブラリとライブラリを配布する仕組みがある。カンファレンスもある。ドキュメンテーションもね。オープンソース的な貢献だってある。これ以外にもいろいろなものがエコシステムには揃ってる。

こうしたことが起きたのは、Ruby がこうした文化を促進したからだと思う。ソフトウェア開発者としての視点からは、とても困難で危うく思える道をあえて選んで、常識を引っくり返すという文化をね。

わかりやすい例を挙げよう。僕らはなんでコードを書くときにカッコやセミコロンを必ずつけなきゃならないんだっけ？　セミコロンやカッコをコード中に撒き散らすプログラミングを僕らは長いこと疑問にすら思わず続けてた。ところが Ruby だとそんなの要らないんだ。

このとき僕の心に沸き起こる疑問は「どうして僕らはこれまで鬱陶しいカッコを使い続けたり、行末に来るごとにセミコロンを打たなきゃいけなかったのか？」ということだ。Java のパーサは行末にセミコロンがないとコードを解釈できないんだろうか？　もちろん、やろうと思えばできたはずなんだ！

その一方で、どうしてこれまで僕らは Rails がやったような自動化を自分たちの手でやってこなかったんだろうか、とも思う。PBX の開発をどうして Adhearison フレームワークでやれるみたいに簡単にしてこなかったんだろう？　なんでもっと早く Capistrano みたいな取り組みをやらなかったんだろう？

僕らが目にしてきたのは、Ruby のソフトウェアがこれまでの慣習や前提の数多くをぶち壊していくという光景だ。しかもこれは、それまで Ruby を使うにあたって守ることが正しいとされていた前提や慣習を破ることによって達成されたんだ。『「風変りな」言語は真のエンタープライズでは歓迎されない』という前提は、そうやって破壊されたもののひとつだ。

僕が思うに、Java だってかつては「風変りな」言語だった。けれど、主要な業界プレイヤーの後押しを受けたテクノロジでもあった。お金もたくさんあったしね。Ruby が Web 業界を席巻した 2004 年から 2005 年の時点では、まだ Ruby は欧米では誰も聞いたことのない日本人の作ったニッチなオープンソース言語でしかなかった。さっきも話したけど、それは従来の IT 業界では物笑いの種だったんだ。

けれど、突然すごくたくさんの人たちが、Ruby の可能性に気づいた。多分、僕自身もそこで気づいたんだけど、このとき一緒に Erlang、Python、Ocaml、Haskell、Scala、MongoDB、Casandra といったテクノロジを受け入れる門が開いちゃったんじゃないかな。こうした風変りで型破りなテクノロジが同じような時期に急に話題になって、受け入れられはじめたんだ。僕の考えでは Ruby が (Rails の成功を通して) 少なくとも一時的には、たとえ従来通りの保守的な環境であっても「試してみてもいいんじゃないの」という雰囲気になったと思うんだ。企業で採用されるのっぺりとしたツールボックスとはうまく折り合いをつけられなかったとしても、自分たちの仕事に合った適切なツールなんだったらそれを採用するという風潮は、これまでよりも許容されるようになってきてる。

世界中を飛びまわっていると、どの企業にもかならずこういう人がひとりはいるんだ。みんなにもっと効率的にやることを考えてほしい。もっと一生懸命にやってほしい。もっと美しさを目指してほしい。自分たちのスキルに気を配ってほしい。鈍重で使えない開発プロセスから解放してあげたい、などなど。こういう人たちが「アジャイル」プロセスと動的言語を強く支持してる。彼や彼女がテスト駆動開発や、顧客を巻き込むことを推し進めてる。ドメイン駆動設計も。リーンスタートアップのアイデアも。良いと思うものなら何でもだ。僕が Ruby に関わって以来、Ruby はずっとこうした人たちを招き寄せるハニーポットになってる。それが Ruby の魔法だよ。僕には説明できないけれど、とにかくそうした人たちがみんな……年を追うごとにどんどん Ruby 界隈にやってくるんだ。とても幸運な場所だよ。

Ruby の未来

――Ruby はどこへ向かっているのでしょうか？　言語やコミュニティにあなたが期待していることは？

僕には Ruby がどこへ向かうかなんてわからないよ。僕のなかの一部は「もういいんじゃないか。これで十分だよ。あとはバグを直して速くすればいいんじゃないの」と言ってる。けどそれは、僕がみんなほどにはすごくないからだと思う。Matz や Shugo Maeda、Nick Quaranto、Ruby のコアチームや Rails のコアチームのみんなとか、他にもたくさんいるすごい人たちみたいにはね。彼らは本当にすごいものを作りだしたように見えても、そこからさらにもっともっと良くしようとすることを続けてるんだ。

ただわかってるのは、ついに Ruby 2.0 が視野に入ってきたっていうことだ。僕が初めて Ruby 2.0 の話を聞いたのは RubyConf 2001 だった。Matz が基調講演で Ruby 2.0 について話したんだ。そこで彼は「仕上げるまでには Perl 6 よりも時間をかけたいと思う」みたいなことを言ったんだ。一言一句このままじゃないけどね。でもその後、2006 年の RubyConf での基調講演で Matz は「Ruby 2.0 は Perl 6 よりもひどいベイパーウェアだ」と言って、両方の開発期間をみんなに見せたんだ。

あなたの使ってる言語のバージョン 1.x がまだ死んでなければ、いつまでも手に入らないバージョン 2.0 っていうのはみんなに希望を与えるんじゃないかと思う。もしあなたが長いこと取り組むことに決めた何かがあったとしよう。それはまだまだ立ち上がり時期にあって、開発途中の段階だと思ってるんだとしたら、それがどこへ向かうのかを見届けたいと思うんじゃないかな。1.x がすごいんだとしたら、2.0 はどんな風になるんだろう！　みんなのそういう楽しみを奪う理由なんてないと思わない？

けれどもとにかく Matz は僕たちみんなの想像する楽しみを、遠くないうちに台無しにするつもりみたいだ。ここで「台無しにする」っていうのは、Matz が僕らの世界を揺るがそうとしている、っていう意味を込めて言ってる。それこそ僕が待ち望んでいるものだからね。1.9.2 は史上最高の Ruby だ。他の言語なら間違いなくバージョン 2.0 と呼んだと思うよ。

だから僕が Ruby に望むのは、2.0 では非互換な変更を入れることだ。2.0 は僕らが慣れ親しんでしまってる、細かいけれども醜いものすべてを取り去ってほしい。今まで気づいてすらいなかった問題を修正してほしい。それから、2.0 は 2.1 とは全然違ったものにしてもらいたいな。2.0 には 2.1 にはとても引き継げないような、どうかしてると思われるような馬鹿げたアイデアを盛り込んで欲しいんだ。

そして Ruby 2.1 はどこでも動くようになっていて欲しい。僕じゃとても手が及ばないようなハードコアな数学で使えるようになって欲しいし、携帯電話や電子レンジでも Ruby が動いて欲しい。何年か前にポーランドで Gilad Bracha と会ったんだけど、僕が熱心な Rubyist だとわかる前に彼は「自分たちのやっていることは IO バウンドなアプリケーション (Web アプリ) だから」といって Ruby インタプリタのパフォーマンスの貧弱さを正当化して Ruby を擁護する人たちを批判した。Gilad が言ったのは僕らみんなが気づいてることだった。Ruby が計算の遅くても構わないアプリケーション領域に追いやられなければならない理由はない。たとえそんなアプリばっかりだとしても。

今年の RubyConf で Matz は「Rite」という新しいプロジェクトについて話してくれた。Rite は Ruby のサブセットとなる新しい実装で、携帯電話や家電のような低フットプリントなアプリケーションに特化したものだ。メソッドのルックアップとかの遅い操作を補助するための Ruby チップだって開発されるかもしれないらしい。それがうまくいったら Ruby 3 になったりするかな？　Rubyist たちが Rite に乗り換え始めたりとか。とにかく、この先も Ruby から目は離せないよ。

'’Chad Fowler はソフトウェア開発者、著者、スピーカー、カンファレンスの主催者、そしてミュージシャンです。昼間はさまざまな業態と規模の企業のために難問を解決する InfoEther, Inc. の CTO であり、夜は『情熱プログラマー』のような書籍を執筆しています。近刊は『Rails 3 Recipes』です。

原文へのフィードバックは Chad 宛のメール か、PragPub のフォーラムへお寄せください。訳文へのフィードバックはるびま編集部までメールでお願いします。

Chad の写真は、James Dunhcan Davidson が撮影したもので、彼の許可を得て掲載しています。’’

訳者について

O-Show

アプレンティスRubyist。RubyKaigiは2010が初参加で、以来Rubyistを自称するようになりました。ブログでRubyやGit関連記事の翻訳をあげています。Gitが「難解だから」と忌避されると潜在的Rubyistが減りそうな気がしてならない今日この頃。 Twitter:@oshow

かくたに

日本Ruby会議 2011 の実行委員や大江戸 Ruby 会議01 の実行委員長をやったり、るびまのRSpecの連載記事を途中で長期間放り出したりしています。チャド先輩へのインタビューをるびまに掲載できてとても嬉しいです。@kakutani, http://kakutani.com