「RubyはRailsと一緒に“峡谷”を乗り越えた」　「キャズム理論」に沿った、Rubyが広まるまでの歩み

知られないものは存在しないものと同じ

まつもとゆきひろ氏（以下、まつもと）：「良いものを作れば世に広まる」という話なんですが、ビジョンを用意しました、ビジョンに従って世に問うような、未来を予測して、彼らは自覚していないけれども「こんなものがあったら顧客は本当に喜ぶ。生活が便利になるし、これはすばらしいものだ」と思って、良いものを提供しました。それで十分かというとですね、残念ながら「良ければ広まる」ということも、残念ながらあまり当たっていないんですね。やはり知名度が必要なんですよね。

知られないものは存在しないものと同じなんですよね。例えば名前だけが知られていても、本当にそれが便利かどうかがわかっていないと、存在しないのと同じなんですね。

1990年代の後半にRubyが一般公開されて、人々に少しずつ知られるようになった時に、たくさんの方が「Rubyは良い言語」と言ってくださることがありました。

私がRubyの作者だということを知っていると、例えば私が出版した本を読んだ方とかから「Rubyは良い言語ですね」と褒めてもらえることがけっこうあったんですね。私自身も言語に自信があったので、褒めてもらうとうれしいわけなんですが。

ただほとんどの場合、続きがあるんです。「だけど、私は使っていません」と続くんですね（笑）。残念ながらね。

1995年にインターネットで公開して、1999年に本を出して、それから2000年代、2005年ぐらいまでは、「Rubyというものがあります。知っている人は知っています。だけど、実際に次のソフトウェアプロダクトを作る時にどの言語を使うかというと、Perlとかを使います」みたいな感じで、いまいち伸びなかったんですよね。

「フレンド」と「ベネフィットシーカー」の乗り越え難い壁

「キャズム理論」というものがそういうのを説明しているわけなんですが、イノベーターだったり、アーリーアダプターだったり、アーリーマジョリティだったり、レイトマジョリティだったり、ラガートだったり。ユーザーはそういういろんな種類に分類されます。

イノベーターというのは、新しい技術を作り出す人ですね。アーリーアダプターは新しい技術を見つけて、それを使ったりすることに対して喜びを見いだす、新しいもの好きな人です。

アーリーマジョリティというのは、一般層なんだけれど、比較的新しい技術を受け入れやすいタイプの人で、それでもですね人柱になりたいとかまでは思っていない人ですね。

レイトマジョリティというのは、周りの人たちがみんな（すでに）使っていて、「使わないと取り残されますよ」みたいなことを言われて初めて使い出す人です。

ラガートは「頑固者」という意味らしいんですけれど、周りの人がどんなに言っても「わしは昔の技術がいい」とか「慣れ親しんだ技術がいい」と言って、新しいものは決して受け入れないタイプらしいです。この5段階があるらしいです。

上からイノベーター、アーリーアダプター、アーリーマジョリティ、レイトマジョリティ、ラガートというものがあって、このアーリーアダプターとアーリーマジョリティの間にキャズムと言われているところがあるんですね。キャズムは峡谷というか、崖に挟まれたところです。谷ですね。険しい谷です。

このアーリーアダプターとアーリーマジョリティの間にある崖。テクノロジーが広まる時の越え難い壁みたいなのがあるんですね。

新しい技術を作り出す人は当然ですが一定数いて、その新しい技術、例えば「Stack Overflow」とかがいろいろなところで話題になって。そうすると「ちょっと使ってみようか」「勉強してみようか」という人たちが出きます。そういう人たちはアーリーアダプターですよね。

なんだけれど、そのアーリーアダプターに受け入れられたものがその次のアーリーマジョリティまで受け入れられるかというとなかなか。アーリーマジョリティの人たちは、実際に利益がないと使う気にならないわけですよね。

アーリーアダプターたちは新しいもの好きなので、利益とか何もなくても「新しい」というだけで飛びつく傾向があるんですが、ここの壁が厚いんですよね。

テクノロジーに関して、イノベーターから見てみると、アーリーアダプターの人たちはフレンドなんです。作りさえすれば寄り添ってくれる親しい存在ですが、そこから先のキャズムの向こう側の人たちはですね、実利がないとついてきてくれないんですよ。

このフレンドとベネフィットシーカーの間の壁、乗り越え難い壁があるんですね。広めるためにはここをなんとかして乗り越えないといけない。

乗り越えるために必要な「キラー」

乗り越えるために必要なものはなにかというと、もちろん前提条件として良いプロダクトは必要で、プロダクトそのものが話題性しかないとか、本当に便利じゃないみたいなものは、キャズムを乗り越えられません。

それを成立させるために、良いビジョンによって良いプロダクトを作らないといけないというところまでは先ほど説明しました。

さらに言うと、「キラー」。キラーアプリケーションやキラープロダクトと言ったりしますが、「この分野に対してこのテクノロジーは非常に合っているので、このテクノロジーを使いたければこれをやったほうがいい」みたいな感じのものがあると乗り越えられるということですね。

例えばPythonという言語があって、「AIをやりたかったらPythonをやるべきだ」みたいなことが一般的に言われるので、そうするとAIが話題になって興味があると「じゃあ、ちょっと試してみたいからPythonを勉強しようか」というふうになるわけですよね。

Webアプリケーションを作ること（自体）は最近あまり流行らないんだけど（笑）。でも「Webアプリケーションを作ります」という話になった時に「Rubyがいいよ」という話になる。「Webアプリケーションを作りたいならRubyになるよ」と。だからWebアプリケーションというのは、Rubyにとってのキラーアプリケーションだったということですね。

「Androidアプリを作りたい」という時には、JavaだったりKotlinだったりを使うわけですし、「iPhoneアプリを作りたい」となったら、「Objective-Cを勉強したい」あるいは「Swiftを勉強したい」となったりするわけです。これはObjective-CやSwiftっていう言語にとって、iPhoneアプリを作るということがキラーアプリケーションになっているということですね。

結局、多くの人たちがやりたがることに対して説得力のあるベネフィットを提供できるかがけっこう重要になってくるということなんですね。

なのでベネフィットシーカーを説得する努力が必要という話なんですが、実利とか話題性とか、そういうものが必要だということになります。

Rubyがどのように壁を乗り越えたか

これが難しいわけなんですよ。なぜかというと、始まったばかりのテクノロジーってほとんどが少人数、場合によっては1人で開発しているわけですね。Rubyも昔そうでしたけど。

そうすると、純粋にリソースが足りないんですよね。Webページを準備して、ドキュメントを用意して、ソフトウェアも開発して、新しい機能も考えて、それも実装してとなんとかかんとかやっていると……。あと細々と広報活動みたいなもの、ブログを書いたりとかTwitterで説明したりとかしていると、どう考えてもリソースというか手が足りないんですよね。

手が足りないので、十分なユースケースみたいなものも集まらないし、十分なユースケースが集まらないからキラーアプリケーションみたいなものもなかなか出てこないというところがあって。

キラーアプリケーションが出れば人々が集まるし、人々が集まればキラーアプリケーションを開発するだけのリソースがあるしというような良いサイクルが回り始める前は、鶏と卵問題みたいなものが起きるんですね。

キラーアプリケーションが欲しいけど、今はリソースがない。リソースが欲しいけど、今はキラーアプリケーションがない。デッドロックみたいなことが起きるわけですね。

現代的なアプローチとしては、オープンソースソフトウェアでもそうなんですが、プロダクトの周辺にコミュニティを作ることによって乗り越えていこうとするアプローチがわりと現実的ですね。

フレンドを強化したり拡大したりすることによってリソースを集めたりとか注目を集めたりとか、そういうアテンションとリソースを集約させることによってキャズムを乗り越えていく。

必ずしもオープンソースソフトウェアだけの手法ではなくて、ビジネスサービス、ビジネスプロダクトにおいても、「巻き込み型マーケティング」みたいなかたちでユーザーを巻き込んでいくことによって、キャズムを乗り越えるという感じですね。

Rubyがキャズムを乗り越えたのも、最初は細々とやって、リソースが少なくてという鶏・卵問題に苦しんでいたんですが、そういう中で「楽しいから」「Rubyが好きだから」ということで集まってくれた方々が少しずつ増えて、その中から、Ruby on RailsみたいなWebアプリケーションフレームワークが登場して。Webアプリケーションフレームワークを使ったWebアプリケーションを作るというところで、キャズムを乗り越えるようなベネフィットを提供できたということですね。

Railsもソフトウェアなので同じようにキャズムを乗り越えなくちゃいけませんでした。

こっちの実利のほうは、具体的に言うと2004年当時、Ruby on Railsを使ってWebアプリケーションを開発することは、当時の典型的なJavaのフレームワークを使ったWebアプリケーションの開発よりも生産性が10倍高いみたいなことが言われていてですね。今それを言う必要はないんですが（笑）。2004年当時、今から18年、19年前とかだと、それが真実に近かったということですね。

さらに言うと、そういうのはJavaのコミュニティの人たちはうれしくないわけですよね。「言語を変えるだけで10倍生産性が上がるとは何事だ」みたいな。

今でいうと炎上みたいなことが起きたんですが、Railsを作った人、デイヴィッド・ハイネマイヤー・ハンソン（DHH）さんは議論が燃えていると喜んで飛び込んでいくような人で（笑）。彼も仲間に入っていろいろ話題が盛り上がって、非常に注目されるようになりました。

あと、Ruby on Railsのすごく昔のWebページには、作者がデモンストレーションでWebアプリケーションを15分ぐらいでその場で作ってみせるようなビデオがアップロードされていました。2004年ってYouTubeができた年なんですよね。だから、インターネットでビデオを使うことは、まだそんなに一般的ではなかった。そのタイミングでビデオを使うことで人々の耳目を集めて。

当時、ゼロから15分でWebアプリケーションが作れるということは、だいぶ画期的だったので、そういうような説得力みたいなものもあったということですね。

そういう説得力によって広く広まった。（Railsは）それでキャズムを乗り越えて、Railsがキャズムを乗り越えたのにつれてRubyも一緒に乗り越えさせてもらったという感じで、広まったという感じですね。

もちろんそれまでにもですね、Rubyの英語の本が出たり、海外でRubyのカンファレンスが開かれたりとかいろいろなことがあったんですが、そういうのを全部含めたコミュニティとかコネクションとかを使って広めることができたというのは、Rubyにとってラッキーだったと思います。これが縦軸というか、広まるほう（の話）です。

（次回に続く）