まつもとゆきひろ氏が語るRubyの未来　「劇的な変化は必要ない」

Rubyの発展は変化が少なかったことに救われた

まつもとゆきひろ氏：過去25年の変化を考えてみると、Rubyにとって非常にラッキーだったのは、過去25年の変化が驚くほど小さかったことです。私たちの社会はITによってものすごく変化したようなイメージがありますが、プログラミングの、少なくともプラットフォームの話をすると、例えばOSはUNIX系に収斂していったわけですよね。

MacOSはUNIXですし、WindowsもWindows Subsystem for Linuxって、UNIXっぽくなってます。クラウドのサーバーサイドやスーパーコンピュータのOSは、Linuxがほぼ席巻してます。そういう意味で言うと、プラットフォームとしてのOSがほぼUNIXになったんですよね。

私はもともと25年前より以前からUNIXプログラマーだったので、自分のいたプラットフォームに世界がついてきたというイメージがあります。私のほうにみんなが近づいてきた。

CPUに関しても、25年前もいろんなCPUがありましたけれども、PCに関して言うと今はほぼx86系で収斂しました。Itaniumとかいう言葉が聞こえてたような気がしましたけれども、過ぎ去っていきましたね。

それから、モバイルについてはARMがたくさんありますけれども、CPUの根本的なアーキテクチャはそんなに変わらないんですよね。同じソフトウェアをコンパイルすれば、IntelでもARMでも動くという感じになってます。

そうすると、この25年間、プラットフォームに関してはまったく新しいことが起きなかったうえに、さらに多様性まで減少してるということです。Rubyの初期の開発環境は……すいません、過去の話になってます。やっぱり年寄りに話させると、みんな過去の話になるんですよね。

一番最初は、ソニーのNEWS-OSで開発したんですけれども、これはBSD系のOSです。それからSunOSに移りました。まだSolarisって呼んでなかったんですね。CPUに関しても、Motorolaの68030からSPARCにいって、それから386、486、586って、今までIntel系できてるわけです。

基本的なアーキテクチャはUNIX系、それからOS……。CPUは若干変わりましたけれども、ここ何年かはずっとIntel系で劇的には変わっていません。なので、Rubyの発展の一部は、この安定性に救われたところがあると思います。これが、過去のOS、まったく互換性のないようなものが世界を席巻していたら、Rubyはその大きな変化についていけなくて、絶滅していた可能性がかなり高いと思いますね。

25年間の変化のキーワードは「スケーラブル」

一方、25年の間、変化したこともたくさんあります。大きな変化は、例えば性能、容量、価格、台数です。システムアーキテクチャは、Web、モバイル、クラウド、マルチコアとか、そういうことが違ってきました。

また、適用分野に関しては、例えばデータサイエンス、AI……「AIって何ぞや？」みたいなことは言わないでくださいね。それからIoTとか、そういうキーワードが人気を呼ぶようになりました。

性能、容量はどんどん拡大しているので、プログラマーはむしろ楽になってきています。価格や台数が増えたおかげで、コンピュータがどこにでも手に入るようになりました。

また、World Wide Webは、一種のシステムアーキテクチャであり、サーバークライアントシステムでもあるんですが、Webのすごくいいところは、スケールしやすいんですよね。水平方向にも、垂直方向にも非常にスケールしやすい、非常にいいアーキテクチャだと思います。

また、PCがあんまり人気がなくなってきていて、デバイスの主戦場がモバイルになったということも大きな違いだと思います。なので、サーバーサイドでなにもかも済んでいた時代はもうとっくの昔に終わってしまって、モバイルアプリとか、Single Page ArchitctureとかのBeyond Serversideです。

言語においても、フロントエンドについてはJavaScript、Java、Swiftを使って開発するようになってきていましたが、サーバーサイドについては、そこまで極端には変わっていないということです。

クラウドが登場することによって、サーバーサイドアーキテクチャにちょっと見直しが必要になってきています。それから、マルチコア。1つのコアの性能向上が頭打ちになったので、「1つのチップの中にたくさんのコアを詰め込みましょう」みたいなことが起きてます。そうすると、さっきのクラウド使って分散・並列実行環境が注目されるようになってきていました。

クラウド、データサイエンス、機械学習、AI、IoTとかですね。それから、そのIoTに伴うデバイスのプログラミングや、過去25年の間、トレンドが変化していきました。この変化の傾向を見てみると、スケーラブルというキーワードが、ものすごく重要になってきたと思いますね。

昔のデータは、1メガバイトあったら巨大データで、「フロッピーに入らないんだけど」ということが問題になるような時代だったわけです。しかし、今だとギガとかテラとか、下手するとペタとかエクサという単位のものを見るようになってきています。ソフトウェアの全体の規模もだんだん大きくなってきていますし、その開発をするためのチームの規模も大きくなってきています。

Rubyのコアに関して劇的な変化は不必要

分散という観点からだと、1つのCPUだけで処理が終わることが少なくて、マルチコア、マルチノード、マルチデータセンターです。つまり、1つのシステムが1つのコンピュータの1つのコアの上に動いている1つのソフトウェアで済まなくて、複数のCPU、複数のコンピュータ、複数のデータセンターにまたがった多数のコンピュータの個別のソフトウェアが協調するシステムというものが、登場してくるようになりました。

これを踏まえて25年後の未来のRubyを考えていくと、言語、このコアの部分については、実はそんなに変わらないんじゃないかな、と思ってるんです。

というのも、プログラミング言語にはチューリング完全性というものがあります。つまり、現在まだ人類に知られていないすべてのアルゴリズムを含めて、チューリング完全な言語があれば、記述することは原理的には可能です。すごく婉曲な言い方をしましたけれども、楽かどうかはともかく、書こうと思えば書けるということです。

プログラミング言語のつらいところは、やればできるということですよね。島根に引っ越したばかりの頃、地方に引っ越してきたプログラマーがいるということで、地元の新聞の取材を受けました。ただ、あんまりITとかプログラミングとかをご存知ない方だったので、「あなたのつくっているそのRubyというソフトは、いったい何ができるんですか？」という質問を受けたんですね。

（会場笑）

すごく困って、「え……、やればなんでもできます」とか言って（笑）。なんか子どものケンカみたいですよね、「やればできるもーん」とかいう（笑）。チューリング完全性というのはそういう性質なわけです。

ということは、25年後のプログラミング環境がもしあったとしても、そこで要求されるアルゴリズムは、現在のRubyでも書こうと思えば書けるわけですよね。そこが難しいと……（笑）。

それを考えると、Rubyのコアに関しては、劇的な変化はそんなに必要ではないと。やるべきことはすでにできるし。さらに言うと、Rubyは、ちょっとあんまり記号が余ってないので、もうそろそろ文法的な限界に近づいてきていて（笑）、もうこれ以上、あんまり文法を変えられないというところがあるわけですね。

いろんな文法をいじったり変えたりして、だんだん言語が変わっていく。とくに今動いているRubyのソフトウェアが動かなくなったりした日には、「本当にそれはRubyと呼べるのか？」ということを考えると、RubyがRubyであり続けるためには、今とまったく異なった言語にはならないということです。そのつもりで、やる気満々です。

もしそういう言語ができてしまったら、それはもうRubyではないと思うんです。そういうことを踏まえつつも、プログラミング言語として進化していかなきゃいけない。

プログラミング言語の進化の方向は「生産性を向上させること」

1954年に最初のプログラミング言語と言われているFORTRANが誕生して以来、COBOL、PL/I、LISPとか、さまざまなプログラミング言語が生まれては、また次の世代によって取って代わられたり、代わられなかったりしたわけです。

その間のプログラミング言語の進化の方向は、基本的には生産性を向上させるという点にあります。コンピュータのためには、プログラミング言語はいらないんですよね。マシン語で直接見れば、コンピュータは実行できるので、プログラミング言語というものが存在するのは、人間の理解力に限界があるからこそ、プログラミング言語のようなものが必要だったわけです。

FORTRANが初めて誕生した時に、Formula Translator、つまり数式変換機というのがもともとの意味だそうですけれども、数学の数式と同じようなものを書いたら、それをコンピュータが理解してくれるということです。当時、そのコンパイラ技術は、人工知能と言われてたんですね。

「どこが人工知能だよ」って思うんですけれども、だいたいコンピュータサイエンスの世界では、尖った技術は人工知能って言われて、それが普及すると、ちゃんとした名前が付いて人工知能のジャンルから外れる、ということが繰り返されてます。そう遠くない将来に、機械学習も人工知能のラベルが剥がれて、また新しい人工知能のブームがもう1回くるんじゃないかな、と思います。

余談はともかく、つまり、生産性を高めるというのは、「より早く、より安く、より速く」、ソフトウェアを開発したいということですね。

「より早く」というのは、短い時間で開発するとか、簡潔な表現で開発するとか、抽象度が高いので詳細に立ち入らずに開発するとか、そういうことです。それから、頭の中に存在しているソフトウェアに関するイメージを、直接コンピュータに伝えることができるとか、イメージに近い表記ができるとか。あるいは、自分が表現したい実行モデルを十分に表現できるような抽象的なモデルを提供するかどうか、というところです。

ただし、短くすればいい、簡潔にすればいいというものではなくて、あとで見た時にわからないと困るので、保守性もある程度、重要であるということです。

現状、Rubyが良いって言われてるところは、簡潔で、直接的で、オブジェクト指向やMVCとかの優れたモデルを提供するところにあるわけです。

「より安く開発したい」というのは、人月モデルが適切かどうかわかりませんけれども、少なくとも同じソフトウェアをより短い時間で開発できれば、かかるトータルのコストは安いことが期待できます。なので、より安く開発できるというのは、より短く開発できる、あるいは、より小さなチームで開発できるということです。

Amazonの創設者であるジェフ・ベゾスさんは、「プロジェクトはピザ2枚で満足できるようなチームがいい」とおっしゃってるらしいんです。アメリカのピザはめっちゃでっかいので、どのぐらいのチームかよくわからないんですけど（笑）。

（会場笑）

「だいたい6～7人じゃないか」と言われてますね。そうすると、「ソフトウェア関係は人数を加えるとより遅くなる」というブルックスの法則があるので、小さなチームで開発ができる、より広い範囲に適用できる、問題を解決できるということは、非常に重要なわけですよね。

さらに、より高速な開発サイクルを回すことができる、俊敏な開発ができるということは、ソフトウェアをより早く、より安く開発するためには、重要なことだと思います。

未来の要求は「高度な分散、高度な抽象、高度な支援」

ソフトウェア開発でアジャイルという単語が有名になったのは、確か2001年に「アジャイルソフトウェア開発宣言」が出た時です。人数は忘れちゃったんですけれども、17人だったかの、アメリカで有名な独立系のソフトウェア開発のオピニオンリーダーみたいな人が集まって、「こういうソフトウェアの開発があるべき姿である」ということを宣言したモデルです。

「ドキュメントよりも実装を重視しよう」とか、「規約よりも」……何だっけ、忘れちゃった（笑）。4つの項目があるんですけれども。

（会場笑）

そのアジャイル宣言を書いた人の中に、最初のRubyの本である『プログラミングRuby』を書いてくれたデイブ・トーマスとアンディ・ハントがいました。

プログラミングRuby 第2版 言語編

後で数えたら、最初のアジャイル宣言にサインをしたソフトウェアのオピニオンリーダーのうち、過半数がRubyを使っている。Rubyだけを使っているとは言わないんですけれども、SmalltalkもJavaもRubyも使うという人たちが、半数を超えていた。さらに言うと、その中で1、2、3、4人……確か4人が、Rubyの本を書いています。

「私がアジャイルに影響を与えた」みたいなことを言うつもりはないんですけれども（笑）。ただ、「もっと楽に、もっと楽しくソフトウェア開発をしたい」と思って、ずっとRubyをつくってきたんです。そういう気持ちは、そのアジャイルという開発手段がソフトウェア開発にとってすばらしいと思っている人たちの、少なくとも共感を得ることができたという点では、「間違ってなかったんだな」と思った覚えがあります。

さらに、ソフトウェア開発は、書くだけではなくて保守もしないといけないので、高い保守性というのもあります。Rubyは、ある点においては保守性が高い。別の点においては、ちょっとダメなんですけれども……。まあ、いいや（笑）。

最後、「より速く」です。実行効率なんですけれども、速くて文句を言う人は、あんまりいないわけですよね。遅くて文句を言われることは、しょっちゅうあるんですけれども。しょっちゅうあるんですけれども……（笑）。

（会場笑）

速いのは理想ですよね。未来の要求というのは、繰り返すと、「より早く、より安く、より速く」ということですね。言い方を変えると、「高度な分散、高度な抽象、高度な支援」というものが求められるということです。