2011年09月15日 09時00分取材

「人間様が気分よくプログラミングするための言語」Rubyは何を目指すのか

「気分やノリがソフトウェア開発には重要だ」と断言し、そこに注目して自らRubyを開発してきたまつもとゆきひろ氏は、どのようにしてプログラマに育ち、Rubyを生み出し、そして開発を続けてきたのでしょうか？

今や日本初のオープンソースソフトウェアとして100万人規模のユーザを持つRuby。数々の賞を受け、なおも変化と成長を見据えるまつもと氏が日本最大のゲーム開発者向けカンファレンス「CEDEC2011」にて、自らの若かりし日々から長いRubyの開発の歴史とそこで培われたコンセプト、そして未来への展望までを余すところなく披露してくれました。「Ruby開発が教えてくれたこと」と題されたこの講演の全内容は以下から。

まつもと：
はじめまして、まつもとゆきひろです。

最近はRubyを開発した人ということで有名になりましたが、Ruby自体ゲームのソフトウェアというより、それを動かすサーバとして使用して頂き嬉しい限りです。私自身はゲームが得意というか、そういったこととは別に、ゲーム業界でRuby使っていただいてるようで、気が楽になった感じがします。今日は「Ruby開発が教えてくれたこと」ということで、Rubyとその開発にまつわる話をとりとめもなくお話しします。

自己紹介代わりに話しますと、私がプログラミングを始めたのはかれこれ30年ぐらい前で、その頃にポケットコンピュータというものが発売されました。1980年くらいのシャープ製ですが、私の父親がこれを買ってきました。当時4万円ほどしたものだそうです。

父親は業界の人でも何でもないただのガジェット好きで、会社の計算、事務計算にでも使おうと思ってこれを買ったらしいのですが、当時中学生だった私にぶんどられました。これでbasicプログラミングを始めたのが私のプログラミングのきっかけでした。

プログラミングを、コンピュータを使って何をするかという時に、いろいろな人がゲームなり計算なりと自分の目的を持ってプログラミングをしますが、私は割と早い時期から「プログラミング言語」というものに関心を持ちました。さっきのポケットコンピュータは400ステップしか入力できないんです。今で言うと400行くらいで、ものすごく小さなプログラムしか入力できないのですが、そうやってbasicをほそぼそとやっているうちに、世の中にはbasic以外のプログラミング言語があるのを発見していろいろと学び始めました。

当時パソコンは高かったんです。少なくとも高校生のお小遣いでは買えないレベルで。さすがに裕福な家に育ったわけでもないので「ちょっとお父ちゃん、パソコン買ってよ」とは言えませんでした。当時のお金で19万とか20万円を超えるので、今の物価でいうと40万円くらいでしょうか。それをとても息子の趣味のために買ってとは言えず、そうすると書籍に頼ることになります。残念ながら当時はインターネットは（一般には）存在しませんでしたので、本屋で「ASCII」などの雑誌を買っていました。

最近コンピュータ雑誌が少なくなっていてさみしいのですが、当時は4大マイコン誌というものがありました。それを小遣いの範囲で毎月買っては「いつかコンピュータが手に入ったらこんなことするんだ」というように情報を集めてた若かりし時代が30年近く前に私にはあったわけです。

その頃私の興味を一番引いたのがプログラミング言語でした。さっきも言いましたが、最初basicしか知らなかったのが、世の中にはPascal、C、LISP、smalltalkなどのプログラミング言語が存在することを発見して、そういう記事はあまり載らないのですが、載っている雑誌を見つけると購入してはむさぼるように読んでいました。

そして高校生の時に「Pascal入門」という本を買ってPascalを学びました。当然Pascalコンパイラなどは確か6万もして、高校生のお小遣いじゃ買えません。Cという言語もあるようだけれど、Cコンパイラは「Whitesmith C」が19万8000円でもっと高い。そうすると勢い本だけを読むことになります。

Pascalの本を最初から最後まで読み通して、当然コンピュータがないので実行できませんが、読み終わった時に「私はPascalマスターしました」みたいに自分に言い聞かせて何となく分かった気がしていました。Pascalにはローカル変数や構造体、再帰呼び出しといったbasicにはなかったさまざまな機能がありました。

そういう新しい概念に出会う度に、最初はbasicで十分だと思っていたのが、世の中には本当にたくさんのプログラミング言語があって、そのひとつひとつが前のものよりも改善した何かを提供している、ということに気がついて「これは面白いな」と思ったわけです。

世の中にたくさんあるプログラミング言語のひとつひとつに、「このようにプログラムしたらもっと面白くなる、もっとよくなる」と考えて設計した人がいるわけです。Pascalの場合はニクラウス・ヴィルトというスイス人、Cの場合はデニス・リッチーやカーニハンというアメリカ人が作ったということを知ると「もしかしたら、それは自分で作ってもいいのかもしれない」と思ったんです。

でもやはりコンピュータもインターネットもなくてあまり情報も手に入らないので、ノートを取り出してきて「ぼくのかんがえたさいきょうのげんご」みたいなものを、ほとんど中二病ですが、書き始めたわけです。「こんな感じでプログラム書き始められたらいいに違いない」みたいに。

でも当然知識もなければ経験もないので、自分で言語をデザインした後にそれを体系的に設計したり処理系を実装したりということはできません。それは本当に中二病の妄想と同じようにノートに封印されました。この間実家に帰った時にそのノートを探してみたのですがどうしても見つからなくて、そのアイディア永遠に失われてしまいました。

ここ数年20歳以下の若者を対象にしたプログラミングコンテストの審査員をやっていますが、最近の若者は結構馬鹿にならなくて、高校生なのに平気でプログラミング言語をひとつ設計・実装してコンテストに応募する人がいます。私が審査員をしているのを知っているからかもしれませんが。彼らは私が高校生の時には妄想するだけで実現に移せなかったことを実現してコンテストに応募してくるので、最近の若者の未来は明るいと思ったりもしますが、私自身についてはそういう能力も経験も情報もなかったので現実には移せなかった。

普通はコンピュータを手に入れて計算やゲームをしたり、大学の研究の助けにしたりということを目指すんですが、このあたりから既に手段と目的がひっくり返ってきていました。プログラミングを作るための手段、自分のやりたいことをコンピュータに伝えるための手段としてのプログラミング言語というのが本来の姿のはずが、だんだんそのプログラミング言語そのものを作ったり考えたりすることが目的になって、それさえ作れれば、もう何に使おうと構わないというようになっていました。

そのように「いつか言語が作れたらいいなあ」みたいなことを妄想していた高校生時代があって、その中でどんなプログラミング言語が欲しいのかを考え続けていました。

言語学に「サピア＝ウォーフ仮説」というものがあって、ここでの言語学というのはプログラミング言語ではなく人間のしゃべる自然言語なのですが「言語はそれを話す人の思考に影響を与える」という説です。

例えばアマゾンの奥地の原住民の言語には数を表現する単語が1と2と3しかないそうです。それ以上は「たくさん」です。そうすると、その言語をしゃべっている人たちには数学の概念は構築することはできない。あとはエスキモーの言語には雪と氷を表現する言葉が80から90あるそうです。そうすると雪や氷について語ろうとする時、エスキモーの言語を使うと非常に豊かな表現をすることができる。考えてみたら日本語でも雨を表現する時に五月雨などのいろいろな言葉があるので、雨や天気を表現するために日本語を使うとより情緒あふれる表現をすることができる、ということもあると思います。

こういうものがサピア＝ウォーフ仮説なのですが、プログラミング言語においてこれはより効果的に働くような気がしています。つまり、私がプログラミングを始めた時にはbasicという非常に原始的なプログラミング言語で始めたのですが、そこにはローカル変数という概念がなかったため、自分でスタックを管理するのでなければ、「再帰」などもできなかったんです。

さっき話した「Pascal入門」を読んだ時に、その再帰という考え方を全然理解できなくて、それを説明したページを3日読んでも分からなくて進みませんでした。「こうやって自分を読み返す時にこのローカル変数と次読んだ時のローカル変数は違うから繰り返しループみたいになることができるんだ」ということに気がつくまで3日くらいかかりました。

その後学校の数学の授業で「帰納法的定義」というのを勉強した時に「これは再帰だ」と気がついた覚えがあります。つまりbasicという言語で私の思考は制限されていてその概念を理解することはできなかったのですが、Pascalという再帰ができる言語を学ぶことで新しい発想を理解することができるようになったということです。

そういうこともあるので、チューリング理論的には「ほとんど全てのプログラミング言語はありとあらゆるアルゴリズムを記述することは可能なので、計算理論的には等価」なのですが、実際問題としてどのプログラミング言語を使うかによって結果を得るためのコストや時間は変わってくる。あるいは発想が助けられるということもあります。

そのため、どのプログラミング言語を選ぶかはその人の生産性に直結すると言ってもいい。それによって、「プログラムしている時のストレス」「どれくらいの時間をかけてソフトウェアを開発できるか」「どんな記述量でそれを書くことができるか」ということがずいぶん変わってきます。

Rubyは、プログラミング言語ごとにいろいろ注目している点、強調している点があるのですが、その中でも「開発効率に注目」していて、「より簡単に」「より効率よく」「より気分よく」開発できることを目指しています。

「気分」というのは長らくソフトウェア開発の中で重視されてこなかった領域なのですが、考えてみればソフトウェア開発というのは非常に人間的な側面の強い分野です。ソフトウェアは機能ベースで、何ができるか、あるいは実行速度といったところに注目されることが多く「ベンチマーク最強」のように、プレミアムが優秀のような取られ方をします。でも実際にソフトウェア開発において「開発中に開発者がどのようなことを感じるか」ということは無視できません。

ソフトウェア開発では、皆さんも経験あるかもしれませんが、調子よくPCのキーボードをたたいて進んでいる時に電話が鳴って呼び出しをされると、頭の中にあったエネルギーみたいなのが抜けていって、5分後に電話が終わってPCの前に戻ってきた時にはもうそのエネルギーがなくて、その後一日中生産性が全然上がらなかったりします。やはり「気分」とか「ノリ」といったものがソフトウェア開発の生産性には非常に重要で「どのようなプログラミング言語を使うか」ということも実は影響を及ぼすことがあるということです。

ソフトウェア開発に重要な「気分」についてですが、どんなときに気分がいいかというと、「自分が思った通りに開発のプログラムができた時」「万能かなと感じる時」「我慢しなくてすむ時」「悩まない時」などでは少なくとも私は気分がいいです。

例えば「こういうプログラム書くとこうに動くに違いないという期待が応えられる時」や「自分が実現したいことと書いてるコードの間にあまりギャップがない時」など。

あとは「もしかして俺ってすごいんじゃない、こんなコードを書いたらこんなソフトが動いたよっていう時」のように「万能感を感じる時」ですね。

子供は6歳くらいになると「やれば何でもできる」という思いと「でもやってみるとあんまりできない」というギャップを感じて悩んだりしますが、プログラミング言語の世界でも「すごい言語が作りたい」という熱意があっても、実際自分で言語を作ってみると「技術的な制限や能力や知識の制限で結構ショボかった」というギャップを感じてがっかりしたりします。プログラミング言語、あるいはライブラリがそれを助けてくれる時に「思ったより簡単にやりたいことができた。俺ってすごいんじゃない」という気持ちになれるのは意外と大切だと思うんです。

ソフトウェア開発はいろいろ我慢しなければいけないことがありますが「我慢」「苦痛」「不合理」などを感じない時に割と気分よく開発できる。

「なんなんだよー！」と海に向かって叫ばなくてすむような時です。それからプログラミング言語やライブラリが提供する世界観に一貫性があってクリアな時は悩まなくてすむ。

気分よくプログラミングできている時はプログラムは簡潔で済むし、作っている人は自分がすごいプログラマーであるかのような錯覚、妄想でもいいですが、そういうものを感じることができます。

フレッド・P・ブルックスという人が書いた「人月の神話」という本のいくつかある名言の1つに「プログラマが一定時間に開発できるソフトウェア量は言語によらず一定である」という「ブルックスの法則」があります。

これは「あるひとりのプログラマが1日500行のソフトウェアを開発できる能力があるとすると、その人がアセンブラで書いていてもC++で書いていてもJavaで書いていてRubyで書いていても、1日500行書くことができる」といった意味です。もちろん理論的な根拠があるわけではなく、経験則としてですが。

仮にある人がアセンブラで500行作ることができて、Rubyでも500行作ることができるとしたら、アセンブラの500行とRubyの500行とではできることの間にかなりの、場合によっては100倍から1000倍の差があります。つまり、適切なライブラリと言語を選択することでプログラマの見かけの能力が10倍、100倍、1000倍に差がつくこともある。だから適切な言語を選択することは生産性にとって非常に重要です。

このことを称して、プログラミング系のエッセイをたくさん書いているポール・グレアムというアメリカ人が「簡潔さは力なり」というエッセイを書いています。

どういうことかというと、1954年にFORTRANというプログラミング言語が最初に作られ、その時以来、プログラミング言語は半世紀以上少しずつ進化して来ていて、後から出てきたものは前のものの悪かったところを直して、新しい何かを提供しながら成長、進化してきたと。そしてそれが「いかにプログラムを簡潔に書くことができるかという方向に進化してきた」というのがポール・グレアムの主張です。実際そういう傾向はあると思います。

つまらない例で紹介しますが、階乗(factorial)を計算すると、n以下の自然数の全ての積で、nの階乗は1×2×3×…×nである。

この階乗を計算するプログラムをみんな大好きJava言語で書くとこうなります。

何の変哲もありません。個人的に私はずっとCのプログラマなのでCで書くとこうなります。Javaよりちょっと密度が低くて、より簡潔に書けています。

これをRubyで書くとこうです。

より簡潔で、かつ、これは帰納法的定義で計算していますが、階乗を計算する時に不要なものがほとんどないです。つまり、nの階乗の計算は、nが1の時は1、それ以外の時はnとn-1の階乗をかけたものであると。まあendとかはありますが。6の階乗はこれだけ。本当に余分なものが何もないです。

一方Cは「includeなんとか」ですとか、Rubyにはなかったものが書いてあります。Javaになると「public staticなんとか」とか、これ書く度に腹が立ちますね。もちろんJavaにはJavaの都合があるんですが。

冷静に考えると、なぜこれを書くかというと「書かないとコンパイルが文句を言う」からです。「そんなん知らん」と。でも我々はコンパイルのために働いているわけではなく「機械が我々のために働いてくれるべきではないか」と思うわけです。コンパイルを満足させるためにこれを書くということは、言語デザイナーの私としては結構屈辱です。やはり本質だけ書きたいので。

最近はあまり使っていませんが、アルゴリズムの教科書では疑似コードというものがあります。例えばJavaでサンプルプログラムを書くとすると、アルゴリムで説明を書く時にさっきの「public static void」のような本質と関係ないものがいっぱい出てくるので「本質だけに集中して、人工的な言語、仮想的な言語でアルゴリズムを書きましょう」ということです。

でも、そうした簡潔で仮想的な言語でアルゴリズムがかけるなら、それがそのまま動けば最高です。そういう記述にできるだけ近づけたいというのがRubyや最近のLLと呼ばれているプログラムの設計ポリシーになってきています。

さらにRubyの場合はこんなこともできます。1からnまでの数字の列にかけ算記号を差し込むというものです。さっきの定義に戻ると、1×2×3×と、1からnまでの間にかけ算記号を差し込んだもの、かけ算という処理を差し込んだものという意味になるんですが、これでかけていきます。一見わかりにくいですが、1からnまで差し込むというところが分かれば非常に簡潔です。さっきのように6の階乗ってやると同じ結果が出ます。

このように「簡潔な表現」を目指しているわけです。次にこれはRubyのシナトラという名前のウェブアプリケーションフレームワークの記述です。このgetというのは、そのウェブページのドメイン名の下に/fooという名前のページを取得するリクエストが来たら、ブラウザがchromeだった場合は「Google Chrome使ってます」そうでない場合は「Chromeじゃないブラウザを使ってます」ということを表示します。これだけでウェブアプリケーション1個書けたと言うのはちょっと無理がありますが。

「抽象化」に関して、こちらはJavaとかCとか書き方です。「for i=0とiが100以下の時にiを1個ずつインクリメントしてループを回す」と。訓練されたCプログラマはこれを見ると「ああ、そうか100までループするのか」と見てしまうわけですが、「iが0に初期化する」「1個1個比較する」「インクリメントする」などという情報は本質とは関係ない中身の部分です。データの高度の抽象化という観点からすると「いかにループするか」という実装の中身が漏れ出してるわけです。「抽象化の漏れ」というものです。

もちろんRubyでもこのような書き方はできます。でも、どちらかといえば、Rubyは100回繰り返してと言うと100回繰り返すんです。何も余分な情報はない。こうして抽象的に表現できるのがRubyのメリットになります。

人間と機械の都合が対立する時は結構ありますが「コンピュータが速く動くために人間がいかなる努力でもいたします」という態度は古いと思います。今や人間が主人なので、できるだけ仕事はコンピュータに押しつけたいわけで、そのためにがんばるのがRubyのポリシーです。

30年以上前の時代は、コンピュータといえば大型コンピュータが普通で、いわゆるパソコンは存在していませんでした。大型コンピュータだと計算量や時間で課金されるので、無駄な計算をするとそれだけ計算機使用料が取られます。

大学にある、当時としては性能のいいコンピュータのリース料が月に1億円程度もかかっていて、バグだったり無限ループのような無駄な計算をすると先輩に怒られるんです。「おまえが無駄に使った計算機使用量でいったいいくらかかったと思うんだ」と。そういう時代には「人間ができる限りの努力をして、コンピュータ様が無駄な計算をしないように努力をする」ということがあったそうです。

今や、その時代のスーパーコンピュータよりも性能のいいものがその辺の電機屋で10万円以下で買えます。10万円で買ったノートパソコンの性能が30年、40年前のスーパーコンピュータの何十倍、何百倍とかの計算機能を持っています。そうすると、計算能力を節約するのはもうばかばかしい。もはや「人間がコンピュータをこき使って全然問題ない時代」になってきていると思います。

それにもかかわらず、プログラミング言語は古い時代に設計されたものが多いので、昔と同じようにコンピュータの都合が人間に押しつけられることがあちこちで見当たるわけです。

ひとつ例を挙げると、200の階乗を計算したいとします。さっきのJava版でも構いませんが、これはCの例です。Cで階乗を計算する時に12の階乗は479001600です。13の階乗は既におかしいですね。12の階乗の13倍なのに合っていません。さらに14の階乗を計算すると13の階乗より減ってしまう。そして200の階乗を計算すると0と言うんです。

これは何が起きてるか、プログラマの皆さんは分かりますね。JavaでもCでもそうですが、intのサイズに制限があります。この場合は32bitを想定しました。符号付き32bitの整数は20億ちょっとまでしか表現できません。それを超えると何も言わずにオーバーラップするんです。ひどい話ですが。

私たちの考えている整数は「これ以下」とか「ここまでで整数終わり」という概念ではないので、13の階乗が計算できないというのはコンピュータの都合です。でも、もう21世紀にもなるというのにそういう都合を押しつけられたくない。なのでRubyでは200の階乗を計算したいと言うと、ちゃんと計算してちゃんと出ます。問題はこれがあってるかどうか誰にも分からないということですが、きっと合ってます（笑）。

人間が200の階乗を計算したいと言ったらコンピュータは「分かりました。人間様が200の階乗を欲しいというのなら、そんなでかい数は私要らないと思うんですけど」と言いながらもちゃんと計算する。これが「機械の都合よりも人間の都合を優先する」という、ひとつの例だと思います。こういうことの積み重ねが「簡潔なプログラム」や「気分がよいプログラム」につながると思っています。

もちろんJavaでも200の階乗はできます。bigintegerっていうライブラリを使えば、200の階乗も平気で計算できます。でも、さっきのシンプルなJava版でintと書いてあって、これは我々には見えないけれどコンピュータには「これは符号付き32bit整数だ」という意味があるので、そうすると人間が「13の階乗より大きな数の階乗を計算したいから、これはbigintegerで書き換えなきゃいけない」と考えなきゃいけないわけです。気にしなければいけないことが増える。

ところがRuby版では、まったく同じプログラムを200の階乗を与えると「人間様がもし200の階乗計算したいとおっしゃるなら、私はこのまま計算しましょう」と、計算してくれます。こういうことの積み重ねが「気分のいいプログラム」の開発につながるわけです。

Rubyは開発コードに着目していて、より簡単に気分よく開発したいという時代の要請にマッチしています。コンピュータの性能ずいぶん上がって「性能よりも生産性」「開発者の気分が重要である」となっています。

本当に開発しなければいけないソフトウェアはたくさんあって、いかに少ないコストでいいものを書くかが大事なのですが、そこで今まで重視されてこなかった非常に重要な要素が「ひとりひとりの開発者がいかに気分よく開発するか」「開発者がどのくらいいい気分で開発できるのか」である、ということです。

Rubyの場合、設計した私自身がプログラマで、「自分がこんな言語でプログラミングしたい」という気持ちを込めてデザインして実装してきました。そうすると、使う人の気持ちが分かる。

Rubyを最初に作った時は「世界中のプログラマが私と同じように感じる」なんておこがましいことは全然考えてていませんでした。でもそれをインターネットで公開したら意外と多くの、それも世界中の人たちが同じように感じて、Rubyを使って気持ちいいと思ってくださったのでこれだけ広まりました。

それで、プログラマが心の中で思うことは意外と変わらないんだと思いました。もちろん違う趣味を持っている方がいるのは当然で「私はJavaの方が気分がいい」「私はPascalの方が気分がいい」「Pythonの方がいい」という方はそれでいいと思います。自分が一番気分がいい、一番生産性が高まる言語やツールを使って開発するのがいいと思います。

問題は、Rubyが気分がいいという人がRubyを使って開発することができるか、という点にあります。もともとプログラミングは本当に楽しいものだと思います。私は30年前から今までいろんな言語、いろいろなツールでソフトウェア開発してきましたが、ソフトウェア開発は本当に楽しいと思います。何か新しいものを作り出す楽しさ、作ってきたソフトウェアに関してユーザの方々や一緒に開発してきた人とコミュニケーションする楽しさ、それにバグを見つけるという一種のパズルみたいな楽しさもあります。

しかも、他のものづくりと違ってソフトウェアは物理的な制約を受けることは非常に少なく、自分のイマジネーションの限り、そして非常に少ない人数で開発することができます。

今私が車に関心があって、自分の好きな車が欲しいと思った時に、自分でデザインした車を手に入れるのはほとんど不可能です。車は工業製品としてメーカーが作っていますし、作っても車検も通らないかもしれない。理論的には、自分のデザインしたありとあらゆる機能を詰め込んだ車を作ることは不可能ではないかもしれないけれど非常に敷居が高いです。

でもソフトウェアの場合は自分の思ったとおりの、イマジネーションの届く限りのソフトウェアを作るというのは実はあまり大変ではないし必要なことはPCが大体できてしまう。

もちろん楽しくないこともあります。「バグが黙らない」「締め切りが迫ってきた」「プロジェクトが炎上」したりするとやはり楽しくないです。その解決策のひとつが「どれだけコンピュータに仕事を押しつけるか」です。

ムーアの法則によって、コンピュータの性能はどんどんよくなってゆくので、仕事を押しつけてもなんとかやっていけるというようになりました。それからRubyというのはオープンソースソフトウェアとしていろんな人の助けを借りてよくなってきたんですけどね、その辺も含めてリクエストも出てくると思います。

取材を受けた時によく「どうしてRubyを売らないんですか」と聞かれます。

Rubyはオープンソース扱いで、無料でコピーも自由、使うのに許可も不要なためユーザ数を正確に数えることもできませんが、ある推計によると大体100万人くらいではないかと言われています。ちなみにJavaは800万人くらいだと言われています。その人たちから、例えばひとりあたり1万円ずつくらいもらうと100万人で100億と、すごいお金持ちになりそうです。

でも、私がRubyを作った時に「これは本当にいいソフトだからユーザからひとり1万円くらいもらおう」と考えていたら、Rubyがいいソフトウェアでも、例えばPerl、Python、PHPなど、他にも言語が既にオープンソースで数多く存在しているので、それでは「いいかもしれないけど1万円は払わないよね」となり、Rubyに関心を持つ人は増えずに切れてしまい、私は今Rubyではない他のことをしていると思います。

Rubyをオープンソースとして開発して、たくさんの人がRubyを使ってハッピーになって、そう思ってくれた方たちの何人かはRubyの開発を支援してくれ、私を直接的、間接的に支えてくれているので、結局私はRuby関係のことだけで今ご飯を食べていくのに十分な収入を得られているわけです。ということで、ビル・ゲイツになれる予定は全然ありませんが、Rubyをオープンソースで配ったことでRubyが広まり、結果的に私の生活を支えています。

おかげさまで1993年にRubyを開発して以来、認知度はどんどん上がってきました。1993年に作り始めて、95年に一般公開し、99年には最初の本が出て、2000年には最初の英語の本が出ました。この辺りから私の想像をはるかに超えてきました。

1997年にはRubyを作っていることを名刺や履歴書の代わりに、就職しました。2000年に経済産業省の「未踏ソフトウェア」事業の第1回に採択され、2004年には「Ruby on Rails」という有名なウェブアプリケーションフレームワークが登場して、Rubyのユーザ数と知名度は一気にふくれあがりました。2005年には、IPA、経済産業省の外郭団体からオープンソースソフトウェアの普及、発展に貢献したとして「OSS貢献者賞」をいただきました。

2007年辺りからRubyの知名度は一気に上がったため、楽天技術研究所のフェローになり、Rubyアソシエーションという団体ができて理事長にもなり、その活動の一環として「Ruby技術者認定試験」も始まりました。

同じ2007年には「日経BP技術賞大賞」をいただき、「経済産業大臣表彰」をいただいたりもしました。その時もやはりジーンズ姿で受けましたが。

そして2009年に松江市の名誉市民になりました。私は松江市に住んでいるので、普通は名誉市民はそこに住んでいない人がもらうものだと思っていたので「どういうことですか」と聞いたら、松江市の名誉市民制度はそうではなくて「松江市に住んだことがあるか、強くゆかりのある方に差し上げます」ということで、断るのもなんだと思っていただきました。後でインターネットで調べたら松江市名誉市民第一号はラフカディオ・ハーン(小泉八雲)。一緒に並べていいんだろうかという感じですが。

松江市のホームページの下に歴代名誉市民のリストがあるんですが、ラフカディオ・ハーンに始まって過去に市長として貢献された立派な方々が並んでいて、その一番下にプログラマーとか書いてあってですね、松江市はおかしいんじゃないかと思いますけれどね。

その間には客員教授や「ものづくり日本大賞」「日本イノベーター大賞」などをいただきました。

ここに至って「日経BPチェンジメーカー2010」などもいただいて、このポスター、カメラマンに写真を撮ってもらったんですが、これが地下鉄の釣り広告になったと。

見た人は恐怖におののいたのではないかと思いますけどね。

今年になってからはherokuという会社にお世話になっています。チーフアーキテクトという肩書きをいただいて、何をするかというと今まで通りRubyを開発するだけです。ただ、herokuは、Platform as a Serviceという企業で、デプロイなどを簡単にする企業で、GIDのコマンドを一発打つだけでそのウェブATMサービスをデプロイできて、ウェブコンソールがあるだけでノードをいくらでも追加できるという状態です。まあ、インノード以上は有料ですが、そういう風なサービスですがデプロイ以上に簡単であるということです。こういうところにもお世話になっています。

キャズム論によると、テクノロジーの発展の段階で、プレイヤーが「イノベーター」「アーリーアダプター」「アーリーマジョリティ」「レートマジョリティ」「ラガード」に分類されます。

最初に新しいものが登場した時にイノベーターという人が飛びつきます。人柱みたいなものです。そのイノベーターがいろいろなことやってるのを見て、アーリーアダプターの人たちが「ああ、ちょっと面白い技術だ、がんばってみようか」というようなことを言うわけです。

そのようなアーリーアダプターが成功するのを見て、マジョリティの中で比較的革新性の高い人たちが受け入れて、それを見てようやく腰の重い人たちが技術を受け入れ初めて、でもラガードの人たちは昔の技術に固執して新しい技術を採用することは決してない、という5つの段階にユーザは分類されるという理論です。

このアーリーアダプターとアーリーマジョリティーの間にキャズムという大きな溝があり、ほとんどの技術はそのキャズムを乗り越えられずに消えてしまうというのがキャズム理論です。

1995年にRubyを公開した時に、最初の1週間くらいで200人くらいのユーザの方々がメールで反応くださり、メーリングリストを作って、半ば無理矢理コミュニティが始まりました。1997年ぐらいにベンチャー企業や零細企業が、Rubyを採用し始めました。

その間はずっと鳴かず飛ばずでしたが「Ruby on Rails」が2004年に登場してからだんだん状況が変わってきて、もう少し大きめな中小企業やIT系の企業が採用し始めたのが2007年からです。去年辺りからは、例えばクラウドのサービスが充実してきたり「Ruby on Rails」が日常化してきたので、レートマジョリティの層がRubyを採用する率が増えてきました。

そうすると2007年くらいにアーリーマジョリティーに到達してようやくキャズムを超えたと。だからこれから先、Rubyが5年、10年でなくなることはないと思うので、ちょっと安泰かなとは思います。

キャズムの後半に行けたおかげで、財団法人を作ったり標準規格になったりもできました。

Rubyアソシエーションが今年になってからやっと財団法人化しましたし、JISX3017という形でRubyの標準規格も策定されました。Rubyを作り始めた1993年には自分の作った言語がJISに載るなどあり得ない話でした。JISはISOのファーストトラックの権利があるので、そのままISOにそおうとしています。

このようにRubyはキャズムを乗り越えて、これから先なくなる心配はあまりないのですが、このまま止まってしまうことはしたくありません。「転石苔生さず」ということわざがありますが、これには転がり続けるような石には苔も生えないから「落ち着いて、苔が生えて外見も日本庭園的にいい状態になれるよう、あんまりこうわさわさ動いたらだめだよ」という伝統的な意味と、それからアメリカなどが中心ですが「苔生えちゃったらもうだめだよね」「かびちゃうよね」というところから「いつも動き続けていて、いつもフレッシュじゃなきゃだめだよ」というふたつの意味があります。

テクノロジー系の企業の場合、後ろの意味を採用したい思うんです。「Rubyはキャズムを超えました。これから先なくなる心配はありません。だけどこれからも発展を続けたい」と思うんです。

Rubyの所属するオープンソースコミュニティは大体そのような感じです。つまり、世の中にはRubyに限らず大変たくさんのオープンソースがありますが、LinuxやRuby、MySQLなどの有名なものに関してはこれから先あっという間になくなることは心配しなくていいのですが、裾のあまり有名でないものを探してみると、本当に死屍累々です。

途中まで行ったけれど「開発者が諦めてしまった」「関心がなくなってしまった」「別のプロジェクトに取って代わられてしまいました」などです。なくなってしまったもの、中断してしまったもの、構想倒れになったもの、本当にたくさんあります。

オープンソースソフトウェアが生き延びるためにはどうしたらいいかというと、やはり「変化を続けて課題を提供し続ける」ということが非常に重要だと思います。Rubyもオープンソースソフトウェアとしてこれからも変化をし続け、課題を提供し続けることが重要だと考えています。

Rubyの未来を考える時に、さっき言ったムーアの法則が重要になります。

LSIの集積度が2年で2倍になって、コンピュータの性能もこれに比例して1年半から2年で倍くらいになっていくのをここ40年間くらい続けてきました。指数関数的増加というものです。CPUの集積度もこのグラフの緑の方を見ていただくと分かるりますが、これは対数グラフなので大体まっすぐです。ですから大体対数か、それ以上ですよね。

ただ、ちょっと気になるのが、このCPUのクロック、パフォーマンス、そしてこれがパワー。パフォーマンスとクロックの差がこれです。CPUの性能の伸びが2000年過ぎから止まっています。電機屋で買えるコンピュータのクロック数も4Gのものなども売っていたのですが、最近のパソコンはそこまでクロック数高いものがありません。大体2Gから3Gのぐらいの間です。そういう意味ではクロックの伸びが止まっています。

理由としてはCPUの性能、スキンで頭打ちになっていて、熱や集積度によって量子論的限界が出るという物理的限界でもありますし、コンシューマが大概のことをするのに十分なCPU精度が出てしまっており、マジョリティーのための要求が飽和してしているということもあります。

もちろん世の中にはどんなにCPUパワーがあっても足りない領域はあります。例えばスーパーコンピュータであったり、CGやレンダリングのようなものですが、一般の人たちがメールを見たりウェブを見たりするためには普通のCPUで十分足りてしまい、そうすると要求の飽和によってCPUの性能が頭打ちになったりします。

だからといって未来の進歩を止めるわけにはいきません。私は未来の進歩というのはウェブ、分散、並列、マルチコアなどになると思いますが、そういうものに対して、クラウドやMapReduce、関数型プログラムだったり分散アーキテクチャといったところが重要になると思っています。

その辺りはRubyも必ずしも強いとは言いがたいところがあるので、キャッチアップしていかなければいけないと考えています。具体的に言うと「より広汎に」「より高速に」「より分散に」「より堅固に」となります。

「広汎に」とは、例えばスマートフォン、PC、スーパーコンピュータなどでRubyが動けるようにしたいと思っています。

その研究の一環としてHPC(High Performance Computing)というのがあって、東京大学の学生でこれを研究している方がいますが、これはRubyの型推論を行い、一度Cにコンパイルし、それでRubyを動かすという研究です。

RubyをただCに置き替えるだけでは全然性能が伸びません。それは簡単なので過去に何人かやった人いますが、この研究内容は型推論が入っているので普通のCにコンパイルできます。うまくはまると、Rubyで書いていて型情報を何も書かなくてもCより10％程度遅いくらいで実行できるということです。

Rubyはずっと機械に仕事を押しつけているので、同じプロダクトで見るとJavaやC++と比べて実際問題遅いです。でもこうしてコンパイルすると「Rubyのままで手軽に書けて、条件が合うと結構速度が出る」ということになります。

逆に小さい方もがんばりたいと考えています。組み込みや正規表現が出る領域では、全部ではないけれど、CPUの性能が上がってOSもLinuxなどを積んでいて、ソフトウェア的に余裕があることが多いです。システムを構成をする割合もハードウェアよりソフトウェアの割合の方が大きくなってきて、ソフトウェアの生産性が求められるケースがどんどん増えてきています。

上から下までをCやC++で開発するよりは、むしろ速度やリアルタイム性があまり問題にならないケースでRubyのような言語で開発したい、そして本当にクリティカルな部分はやはりCとかC++で開発しよう、とすみ分けが行われてきて、ソフトウェア生産性を求めるケースが増えてきました。

「そういったところで使えるようなLightweightが欲しい」ということがあり、福岡の企業の方と一緒に対応中です。組み込みやHPCのような、今までは届ききっていなかった領域でもRubyが使えるようにしていきたいと考えています。

かつてRubyは遅いと言われましたが、それにはそれなりの理由があって、この辺の技術を使って性能を改善したいと思っています。

あとは並列・分散、クラウドなどのキーワードがあって、より自由になってくるので、今後対応していきたいと思います。

それから言語そのものも進歩して、キーワード引数を追加したり、Classboxという機能を追加したり、Enumerableプログラミングなどを駆使してより堅固なプログラミングが書けるよう、あるいは開発のチームがが増えても対応できるようにと考えています。

最後に、ゲーム業界の方は気になるかもしれないので、軽量Rubyについてもう少し説明します。我々がコードネームRiteVMという名前のコードネームで開発しているものがあって、JISやISO、この間決まったものみんなに準拠した文法を持っています。

それからライブラリに関してもほぼ、JIS、ISOに準拠しています。「ほぼ」というのは組み込みの一部の領域では出入力がないのでそもそもI/Oが要りません。そこにI/Oを付けても無駄なので削れるようになってます。

簡単に言うとブラジルから出たLuaという非常にいい言語あって、いろいろなアプリに組み込まれたり、小さいデバイスに使ったりしていて、iPhoneやAndroidのアプリにはLuaを使って作るフレームワークもありますし、商用のゲームにもいくつも埋め込まれていたりします。

ただ、これは処理系としては非常にいいのですが、論理言語として見た時にはしっかりしたオブジェクト指向もなく、つらいところもあります。なので、RubyでLuaのような感じのものがほしいなという要望が結構あり、その辺りを目指しています。

最初から組み込みを意識したAPIを持って、リレーショナルベースのヴァーチャルマシンでインクリメンタルGCを持っています。リアルタイム性が欲しい人は組み込んでみたりしていきます。

C99で書かれているので基本ポータブルで、「特定のプラットフォームではないと動かない」「Windows、Linux、MacOSくらいまでなら動く」ということではなく、小さいデバイスやOSのない環境でも動くことを目指しています。

RiteVMはコンポーネント構成になっているので、例えば「コンパイラを分離する」ようなことができます。最初Rubyでプログラムを書いて、デバッグが終わったらコンパイルしてバイトコード完全に変換してしまって、あとコンパイラを全部外して、コンパイルしたバイトコードとヴァーチャルマシンだけリンクして、シップするということもできるようになってます。

ライブラリもRubyが動く最小限の「minimal」、JISの企画をほぼ満たす「standard」、そしてこれは全然予定だけですが、今のCRubyとか、いわゆるフルセットのRubyに近い機能を持った「full」という3段階の構成を目指しています。ファイバー(コルーチン)や非同期I/Oについても、まだ全然できていませんが、これからやっていきたいと思っています。