Recruit Tech Blog
Rubyはどのように生まれ、世界へ羽ばたいていったのか？まつもとゆきひろさん講演会の全貌をレポート
湊川あい
プログラミング言語Rubyの生みの親である"Matz"こと まつもとゆきひろさん。2016年12月、技術フェロー・技術顧問として株式会社リクルートマーケティングパートナーズ（以下RMP）にお迎えして以降、内製エンジニアのキャリアパス構築や、さらなる技術向上を目指すための取り組みに尽力いただいております。
その活動の一環として毎回大きな盛り上がりを見せるのが、顧問であるまつもとゆきひろさんとの交流イベント。今回2017年9月13日に開催されたまつもとゆきひろさん講演会では、全世界初公開のお話を用意してくださいました！
その全貌を、図解イラストとともにレポートいたします。
さぁ、Matzさん×RMPのスペシャル企画、スタートです！
（取材・文章・イラスト： 湊川あい）
基調講演
イベントはRMPでマネジメントを担当している金谷祐季氏の基調講演で始まりました。
Rubyとは「書いていて、とにかく楽しい言語」
金谷氏
Rubyとは、皆様ご存知のとおりプログラミング言語の一つです。個人的な感想ですが、Rubyは「書いていて、とにかく楽しい言語」なんですね。私自身、6〜7年ほど前からずっとRubyを使っています。ここまでエンジニアを続けることができたのは、Rubyのおかげと言っても過言ではありません。
そんなRubyですが、国内外の数多くのプロダクトで使われています。
国外では、huluやtwitter、Airbnb、KICK STARTER、Square、GitHub。国内では、cookpadや食べログ、Gunosy、Wantedly、MoneyForward。そして、我々RMPが開発しているオンラインラーニングプラットフォームQuipperもRuby製です。
さて、ここでみなさんには発想の転換をしてもらいます。このように国内外で広く使われるようになったRubyですが、このRubyという言語自体をプロダクトとして捉えてみるとどうでしょうか？
Rubyが成功したバックボーンを知ることはグローバルな展開を目指す我々RMPのプロダクト開発のヒントとなるはずです。
- Rubyはどのようにして生まれたのか？
- どのように国外へ羽ばたいっていたのか？
まつもとゆきひろさんに今回初公開の内容でお話していただきましょう！
まつもとゆきひろさん講演 〜日本から世界へ。Rubyの軌跡〜
まつもと氏
みなさんこんばんは！ 2016年12月から技術フェロー・技術顧問としてRMPのお手伝いをしております、まつもとゆきひろです。先日、家族でテレビを見ていたときのこと。ゼクシィのCMが流れたので「お父さん、ここの会社のお手伝いしてるんだよ」と言うと、中学生の娘が「 え！お父さん！？」とびっくり。娘の私を見る目が変わりました。どうもありがとうございます。
（会場笑）
Rubyという言語は主にwebで使われることが多いですね。実は、もともとweb用に作った言語ではありません。webで広く使われるきっかけとなったのは、2004年。Webアプリケーションフレームワーク『Ruby on Rails』の登場です。「Ruby on Railsを使うと、短い時間・少ない人員で高速にWebアプリケーションを開発できる」と注目され、引きずられるようにRubyの人気も高まっていったわけです。
そんなRubyですが、実は1993年に作り始めた言語なんです。1993年というのがどのぐらい古いのか、Javaと対比してみましょう。
| Java | Ruby | |
|---|---|---|
| 1993年 | サン・マイクロシステムズにて、コードネーム「Oak（オーク）」という名前で開発が始まる | まつもと氏、個人で開発を始める |
| 1995年 | 「Java」という名前で初公開 | Rubyをオープンソースとして公開 |
どうですか？ Rubyって新参者のイメージがあると思うんですけど、実はJavaと同じぐらい古いんですよ。
ちなみに、World Wide Webの原型になるものが作られたのは1990年だったそうです。Rubyを作りはじめた当時の1993年の時点では、World Wide Web自体は存在はしていたのですが、世間一般にはほとんど認知されていませんでした。つまり、冒頭でも申し上げたとおり、Rubyはweb用に開発されたわけではなかったのです。
当時すでに先輩としてPerlという言語があったのですが、その代わりになるような言語を作りたかった。でも単にまったく同じものを作ってもしょうがない。その頃の私はオブジェクト指向に傾倒していたので、こう考えました。
「オブジェクト指向に基づいて言語をデザインすることで、既存のものよりも良い言語が作れるんじゃないか」
―― それがRubyの始まりです。
国際色豊かなプログラミング言語の作者たち
「プログラミング言語の作者って、アメリカのシリコンバレーの人たちがメインなんじゃないの？」
そう思いますよね。実はそうでもないんです。
- FORTRAN: アメリカ
- Simula: ノルウェー
- C++: デンマーク
- Python: オランダ
どうですか？ 意外と国際的でしょう。
広く使われているRuby
でも残念ながらアジア人が作った言語って少ないんです。その中でもRuby on Railsのおかげもあって、Rubyは広く使われています。
オランダの会社が計測・発表しているTIOBE Indexという言語の人気ランキングがあります。そのサイトの2017年9月のランキングにて、150ほどのプログラミング言語の中でRubyは10位にランクインしました。過去、7位になったこともあります。嬉しいですね。
皆様にはメタ思考を要求します
まつもと氏
さて、ここからは皆様にはメタ思考で考えていただきたいと思います。当然ながら過去にRubyがやったことを今から完全再現することはできません。だってそうですよね。すでにRubyはあるし、時代も違う。個人によってバックグラウンドも違えば、得意なことも違います。ですが、今から話すストーリーの抽象度を一段上げることによって、Rubyが発展した要素をあなたの作りたいモノに応用できるかもしれません。
それでは、いってみましょう。
プロダクト発展 3つのカギ
Rubyが辿った軌跡を振り返ったとき、以下の3つのカギが浮かび上がってきました。
- なにを作るか
- どう作るか
- 誰と作るか
いったいどういうことか。順に説明します。
なにを作るか
正直言って「未来に何が起こるのか」ってわかりませんよね。どんなプロダクトを作れば将来ウケるのか、完璧に断言できる人はどこにもいません。皆それぞれ必死に考えて「きっとこれが当たるに違いない」と一生懸命予測するのですが、残念ながら予測は外れます。
何が良いのかを事前に分かる人はいません。たとえそれがシリコンバレーのベンチャーキャピタリストでも、です。
アメリカに Y Combinator (ワイ コンビネーター)というアーリーステージの企業に投資をしているベンチャーキャピタルがあります。この企業は大きな収益をあげていますが、その実その割合はというと……。
彼らが投資した1000件のプロダクトの中で当たったのはたった10件。その10件の中の1つ――Dropboxが大当たりしたので、全体的にはプラスの収益が出ているというわけです。とても低い確率ですね。
とはいえ、Y Combinatorの創設者が無能だったというわけではありません。彼は過去に自分でもスタートアップを立ち上げたことがあり、それをYahooに売り抜けてその資産を使ってベンチャーキャピタルを始めたという大変有能な人間です。スタートアップの経験も豊富だし、いろんな人の話を見聞きしている。ITやマーケティングをよーく理解しているはずなのに、それでも100分の1しか当たらない。
Y Combinatorの創設者でもそうなのに、我々が100発100中で当てられるわけがありません。
「PerlがあるからRubyはいらない」―― 文句をつけられたらどうすればいい？
一方で、文句をつける人はいっぱいるんですよね。ある日、海外からこんなメールが届きました。
「Rubyはスクリプト言語としてよすぎる」
どういうことか。読んでみると「オブジェクト指向やモジュール化は、本格的な言語には必要だけど、スクリプト言語としては大げさすぎるので必要ない」という意見でした。
他にもこんな意見もありました。
「RubyにはCPANのようなライブラリがない」
今はRuby gemというライブラリがあってCPANよりも数が多いんですけど。当時はCPANの方が多かったんですね。
あとは、
「PerlがあるからRubyはいらない」
（会場笑）
「Rubyがあるせいで、社内の開発リソースがRubyとPerlに分かれてしまった」
「リソースの無駄遣いだ」
「あなたはRubyの開発を辞めて、Perlに集約したほうがよい」
そう言われてしまいました。なかなかつらいものがありますね。
同様に
「PythonがあるからRubyはいらない」
「JavaがあるからRubyはいらない」
と言われたこともあります。
あるいは
「Rubyには○○機能がないからだめだ」
他の言語に存在する機能がRubyにない。そんな不満も耳にしました。
反対に、他の言語にない機能を入れると、
「Rubyは複雑すぎる」
という声……。
いったいどうしたらいいんでしょう。
ここで大事なのが、信じる気持ちです。
揺るぎない信念こそが原動力になる
さて、ここでAirbnb(エアビーアンドビー)の創業ストーリーを例にしましょう。Airbnbは、新たな旅行スタイルを作り出した民泊仲介サービスです。今でこそ有名になったAirbnbですが、最初は苦難の連続でした。
Airbnbのアイデアが生まれたエピソードをお話しましょう。
ある日のこと、現Airbnbの創業者の一人、ジョー・ゲビアがバーに行ったときのことです。たまたま隣に座っていた別の州から来た旅人ととても話が合いました。 「実は僕、今晩泊まるところがないんだよ」 旅人がそう言うのでジョーは彼を連れて帰り、自宅に泊めてあげたんですね。
その晩、ジョーはベッドに横になり天井を見上げながら思いました。
「あぁ、自分はなんてことをしてしまったんだろう。見ず知らずの人間が隣の部屋で寝てるんだぞ！？ 変な人だったらどうしよう」
寝てる間に何か盗まれるかもしれないし、最悪強盗されるかもしれない。
幸いそんなことは起きず、平和な朝がやってきました。旅人とジョーは大親友になりました。
この出来事がきっかけでジョーは確信しました。
「旅行者に部屋を提供するのは、とても楽しくて素晴らしい経験である」
「そして、それは実現可能である」
それからというもの、ジョーは投資家たちを説得して回りました。でも考えてもみてください。赤の他人を自宅に泊めるwebサービスですよ。あまりにもクレイジーです。会う人会う人に渋い顔をされ、断られ続けました。
そんな中折れずに活動を続けてこれたのは、彼の中に「このアイデアこそ世の中を変えるんだ」という確信があったからです。揺るぎない信念があったからこそ、数々の困難にぶち当たっても彼らはくじけませんでした。
そうしてAirbnbは、今や世界中で使われるサービスになったのです。
さて、Rubyの話に戻りましょう。
「PerlがあるからRubyはいらない」
「JavaがあるからRubyはいらない」
……そう言われても私が折れなかったのは、プログラミング言語というアイデア自体に惚れ込んでいたところがあるからです。
プログラミングに初めて触れたのは中学生の頃。今から30年ほど前ですね。当時ポケットコンピュータというものがあり、それをいじるのにハマっていました。使用言語はBASIC。メモリの容量は1400ステップ、つまり最大1400行までしか書けません。さらに変数名がアルファベット1文字しか使えません。つまり、グローバル変数が26個しか使えないんですね。
（会場、どよめきの声）
つまり、AやBといった変数名しか使えないんです。「わかりやすい変数名をつけましょう」どころの話じゃないですよ。
ものすごくプアな環境でしたが、中学生の私はそれしか知りません。「プログラミングというのは、こういうものなんだな」と思っていました。
でも、だんだん「これはおかしい」と気付きはじめました。「世の中には、BASIC以外の言語があるのではないだろうか？」
そこで本屋に行った私は、『Pascal入門』という本と出会いました。読んでみると、聞いたこともない概念がたくさん出てくるんですよ。ユーザー定義関数だとか、ユーザー定義データ構造だとか。読み進めていくうちに、こういう機能があればラクにプログラミングができることに気付きました。
「プログラミング言語って、自然発生的なものじゃないんだ！」
「誰かが目的を持ってデザインしているんだ！」
当時の私は、その事実に驚愕しました。
「それなら、もしかしたら自分が言語を作ってもいいんじゃないかな……！？」
ところが、ときは1980年代前半。インターネットはありません。仕方がないので本屋に通う日々。ある日『やさしいコンパイラの作り方』という本を見つけました。「これだ！」と思って開いてみたら、ちっとも優しくないんですね。
（会場笑）
それもそのはず、その本は大学の教科書でした。高校生だった私には、まったくわかりません。さらに当時私が持っていたのがBASICしか書けないコンピュータだったこともあり、結局挫折してしまいました。その後、大学でコンピューター科学を専攻してだんだん知識を身につけていったわけですが、それでも現代に比べると知識の入手手段が非常に限られていたんですね。
余談ですが、現在では『U-22プログラミング・コンテスト』という、若者向けのコンテストがあります。私はその審査員を何年もやっているのですが、ときどき自作のプログラミング言語を持ってくる高校生がいるんです。今年も2人いました。自分が高校生のときは、頭をよぎっただけで作るところまで行かなかったのを、今の子どもたちはちゃんと作って持ってくるんですよ。今の子どもたちはすごいなぁ。未来が楽しみですね。
話を元に戻します。私が高校生だったときって、コンパイラだけで19万円もしたんですよ。学生の自分には、当然そんなお金はない。そこで、どうしたか。仕方がないので、ノートを取り出して「僕の考えた最強の言語」という感じで手書きで書き溜めていったんです。それがRubyの原型になったとか、ならなかったとか……！
重要視したのは「自分がいかに気分良くプログラミングができるか」ということ
プログラミングというのは思考するためのツールです。普段意識していないかもしれませんが、みなさんがプログラムを書くとき、「コンピュータにどんな処理を、どんな順番でさせるのか」考えているはずです。
「プログラミング言語は、人間の心理に非常に大きな影響を受ける」
私はそう思いました。
ですから、自分がいかに気分良くプログラミングができるかということをもっとも重視してRubyを作りました。
世の中には、優れたプログラミング言語がたくさんあります。高速で多くの機能がある。そういった言語は、だいたい頭のいい人の集団が知恵をしぼりあって作っています。一方、自分は趣味でプログラミング言語を作っている。当然、普通に戦っても太刀打ちできません。
私はこう思いました。
「同じ土俵で戦うのはやめよう」
「性能や機能を最重要視せず、自分がいかに気分良くプログラミングができるかを重視しよう」
自身の経験から、気分はソフトウェアの生産性を上げることに直結していると思ったからです。イヤイヤ書くよりも、楽しんで書いた方が絶対に効率がいい。
プログラミングという分野において定量的な話はよく聞きますよね。ところが、個々のプログラマの気分にフォーカスした話って少ないんですよ。それもそのはず、『気分』って測定しにくいですからね。
でも、私の中には気分と生産性が直結しているという確信があったので、この哲学に基づいて自分が思う理想のプログラミング言語を作れば、世界のどこかにはいるであろう自分と趣味の合う人が使ってくれるのではないだろうかと考えました。
「この言語を、趣味の合う人たちに知ってもらって、遊んでもらえれば嬉しいな」
「きっと、2〜3週間で飽きられてしまうだろうけれど。そして誰も使わなくなって、私自身も何年かしたら飽きてしまって、インターネットの歴史の中に消えてしまうだろうけれど……」
私はRubyをリリースしてすぐに興味を持った人同士で話し合えるようにと、メーリングリストを作ってNetNews（当時の掲示板のようなもの）に公開しました。すると、2週間で200人もの登録がありました。予想していたよりずっと多い人数でした。
「何を作るか」から「どう作るか」へ変わっていったキッカケとは
メーリングリストからは、たくさんのフィードバックが流れてきました。たとえば、こんなメッセージです。
「長い間、MatzさんがRubyを作っているところを見てきました。ついにリリースしたんですね。ところでバグがありました」
「こういう風にしたら、もっとよくなると思うんですけど」
自分が作った言語に、たくさんの反応がもらえる！ 嬉しい！ 私は以前にも増して開発にのめり込んで行きました。
最初は「ただ単に作りたかったから」「趣味だから」という純粋な好奇心から始まったRubyの開発。しかし、インターネットにリリースし、コミュニティが発生してからは、「ただ単に作りたかったから」という動機から「反応をもらいながらインタラクティブにものを作ることの楽しさ」へ変化していったんですね。
これが、何を作るかからどう作るかへ変わっていったターニングポイントです。
エゴレスプログラミング
Rubyはフリーソフトウェアとして公開しました。当時はOSSという言葉はなかったんです。OSSという言葉ができたのは1998年なんですよ。最近でしょう。
フリーソフトウェアの基本原理は、「プログラマが自分が享受したい自由を最大化するために、他人に対しても同じ自由を許す」ことです。ということは、"自由を制限するような自由"は禁止しないといけないんですよ。
あるいは、エゴレスプログラミングという言葉もあります。ソフトウェアを作るのは時間がかかります。リターンを得たいというのは自然なことですよね。なんですけど、「これは俺のソフトウェアだ！」と主張するのではなく、所有を重視せず「どうぞみなさん使ってください」というスタイルです。
基本的に情報は所有することが難しいですし、コピーするのは自由なのでとどめておくことが難しいんですね。
比喩的な言い方をすると、「情報は拡散したがっている」と言えます。情報の拡散を制限するようなライセンスは、うまく働かないことが多いんですね。特にインターネット時代においては。
「伽藍とバザール」から見る開発体制の違い
ライセンスと開発体制には、あまり関係はありません。どんな開発体制で開発されていても、それがOSSのライセンスを満たしているライセンスで配布されていれば、それはOSSになるからです。
ここからは開発体制の話をしましょう。
1997年、 エリック・レイモンドという人が『伽藍（がらん）とバザール』という論文を書きました。
伽藍というのは大聖堂のことです。
対して、バザールというのはマーケット・青空市のことです。日曜の朝になると、みんながいろいろなものを持ってきて、道端に露店のテントが立て始められる。そして、互いに野菜、果物、鶏などを交換する。夜になると、みんなテントを片付けて帰っていく。どこにテントを立てるか、誰が何を売るかなんて決められていないのに、なんとなく全体としてうまくいっている。これがバザールです。
著者のエリック氏は、これら２つのパターンをソフトウェア開発に見立てました。
- 伽藍型
- 緻密な計画を立て、組織だって開発が行われるタイプ
- バザール型
- ロードマップがなく、自由に開発に参加でき、ゆるやかに開発されるタイプ
当時注目されていたLinuxはバザール型でした。Linuxは、リーナス・トーバルズ氏が大学生の頃に夏休みの自由研究みたいに作り始めたOSです。それが今や超有名なOSとなりました。今、世界中のスーパーコンピュータのトップ500台のうち97%がLinuxで動いているんですよ。こんなことを誰が予想できたでしょうか。ある学生が始めたバザール型の開発が、IBMといった有名企業が一生懸命開発していた伝統的なUNIXを一気に飲み込んでしまったわけです。
敷居の低さが開発を加速する
リーナス氏は「目玉の数が多ければバグは怖くない」と言っています。エリック氏もこのことをバザール開発のメリットとして挙げています。十分な人数で目を通せば、バグは見つけられるし、すぐに修正できます。
最近は、もう一段進んでソーシャルコーディングという言葉も出てきました。
ソーシャルコーディングの利点は、敷居の低さです。
たとえば、あなたがWindows10が大好きで、今すぐWindows10の開発に参加したいとします。それを実現するには、まずマイクロソフトに就職する必要があります。さらに、その中でもOS開発チームに配属されないと、中のコードをさわることはできません。
対して、あなたが今「Rubyを直したい」と思ったら、今日から参加することができます。ドキュメントのスペルミスを直すといったことでも、立派な貢献になるのです。
誰と作るか
白状するのも恥ずかしいのですが、私はプログラマとしては迂闊な方で、結構バグを出すんです。すると、ありがたいことに優秀なコミッターの方々が私のポカに気付いて、即座に修正したり改善したりしてくれるんですよ。逆説的ではありますが「私が迂闊だったから開発コミュニティーが伸びた」というのは確かにあるなと思います。
人は完璧なものには手を出しにくい。自分が理解できないものには手を出しにくいのです。
ここで例を出しましょう。その昔、ネットスケープナビゲーターというブラウザがありました。FireFoxのご先祖様ですね。もともと商用で開発されていたのですが、インターネットエクスプローラーとの競争に負けて、オープンソースとして公開されました。
ところが、これが何十人、何百人ものエンジニアが何年もかけて作った複雑なものでした。いきなり「ソースコード公開しました、何百万行です」と言われても、手が出ませんよね。そういうわけで、ネットスケープナビゲーターは敷居が下がるまで何年も時間がかかってしまったのです。
クローズなまま建てた高い塔に外から参加していくってすごく難しい。逆に最初からオープンな方がみんなでよってたかって開発できるので進みやすいんです。
名誉を独占しないこと
OSS活動って、売り物ではありませんよね。OSS活動による直接的な利益は発生しづらい。でも、OSS活動には名誉経済というものが発生します。
たとえば、
「あのバグを直した人は誰だ？」
「あの人が直したのか！あの人はすごい」
というように。
たしかに私がRubyを作り始め、私がコミュニティーリーダーではあるのですが、たくさんのアイデアを出してきたのはコミュニティーの人たちです。ですから、名誉を独占しないことです。やろうと思えば名誉を独占することもできるわけですが、それは望ましくない。
私の役割は次のとおりだと思っています。
- バザール開発として大まかに進む方向を決めること
- ゆるやかなリーダーシップの元に、コミュニティーベースで開発が進んでいくのが大事
- 不名誉の受け皿
- Rubyは遅い、バグがあるぞといった不平不満
寄せられる不平不満も、考え方を変えれば発想の源になります。
「もしかすると、その部分に手を入れればRubyはより良いものになるかもしれない」
ユーザーの方からいただくフィードバックをインスピレーションにし、常に良いものを目指していく。進み続けることが大切だと思っています。
開発コミュニティは「サメ」
開発コミュニティって、サメみたいなんですよね。サメは止まるとおぼれます。泳ぎ続ける必要があるのです。
まず、会社という場で考えてみましょう。業務命令が出ているのに「私はこのソフト開発したくありません！」と主張すると、どうですか？命令無視になってしまいますよね。
対してOSSの場合を考えてみましょう。OSSへの協力は業務命令ではないですよね。参加するもしないも自由。拘束力がないわけです。
Rubyの開発に参加してくれている人は、知的好奇心を求めて参加してくれている人ばかりです。もしRubyに変化がなくなってしまうと彼らはどう思うでしょうか？変化がないと彼らにとってのおもしろみ・魅力がなくなってしまいます。魅力がないと離れていってしまいます。
進歩を止めたOSSは、悲しいかな次第に死んでいくのです。
一方で安定性も必要
とはいえ「とにかく変化させ続ければいい」というわけではありません。
過去、Rubyをバージョンアップしたとき、Ruby on Railsが動かなくなったことがありました。ユーザーの中でボイコットが起こってしまったんです。
今や、仕事でRuby使ってる人は何万人といます。Rubyのバージョンアップひとつで仕事に支障をきたしてしまう可能性もあるわけです。
最初の頃に比べると、Rubyを開発するのはとても難しくなりました。間違いを訂正するチャンスが減っていくんです。ひとつ間違うとそれを消すのに10年、20年かかってしまう。当然、保守性・安定性を求められるようになります。
明確な矛盾
ここで、明確な矛盾が生まれます。
- 安定性を求めると → 開発コミュニティが離れる
- 進歩の速さを求めると → ユーザーが離れる
今のRubyに求められているのは「安定させつつ進歩もさせる」こと。細い道を足踏み外さないで走るような難しいことが必要とされています。
世界的なプロダクトになるための2つのカギ
1. ニッチに攻めてキャズムを乗り越えた
キャズム（渓谷）を乗り越えるのが、世界的なプロダクトになるためのカギです。
キャズムを乗り越えるにはどうすればいいか？キャズム理論では、基本的にはニッチから攻めるのがいいと言われています。ある特定のニッチなものから攻めていき、そこから横展開していくことによって乗り越えられるんですね。
Rubyの場合は、Webアプリケーションという分野がキャズムを乗り越えるための武器になりました。2000年代初頭、ちょうどCGIから本格的なWebアプリケーションへの移行期がやってきました。
- その時期までにRubyというものが存在していたこと
- ちょうどそのタイミングにRubyの柔軟性を利用して作られたWebアプリケーションフレームワーク『Ruby on Rails』がリリースされたこと
この２つの要素があってRubyは時代の波に乗ることができました。
2. 味方がたくさんいた
もうひとつの要因としては、味方がたくさんいたことですね。当時、NetNewsのグループ（掲示板）を作ってくれた人がいたんです。Rubyファンの人たちが掲示板を盛り上げてくれ、Troll（英語圏で言う荒らし）が流入してきたときにはいさめてくれました。そういった人たちのおかげでコミュニティの雰囲気がよくなったんですね。
そうこうしているうちに、海外の方から「Rubyの本を書きたい」というメールが届きました。その方は、わからないところをMatzにメールで質問しながらすごい勢いで原稿を書き上げ、最初にメールがきてから10ヶ月後には初のRuby本がアメリカで発売されました。その本が結構な部数出たこともあり、アメリカでカンファレンスも開催してもらえるようになりました。こうしてアメリカでRubyが広く知られていったのです。
ちょうどこの頃からRubyを仕事で使ってくれる人が増えてきました。
- ゲームの中のデータをプリプロセスするのにRubyを使いました
- Rubyでテストを書くとC++のルーチンをテストできるものを書きました。これでテスト生産性アップです
「プロダクトに直接Rubyを入れられない場合でも、仕事の後ろでこっそりRubyを使ってるよ」と教えてくれたりしました。
また、Rubyをエンタープライズに使ってくれる、勇気ある人たちも登場してきました。そういう人たちのおかげで「仕事にもRubyを使って大丈夫なんだ」という安心感が広まっていったのです。
まとめ 〜Ruby成功の秘訣 〜
1.信念
「こんなものを作るんだ」「こんな世界を実現したいんだ」という信念を持つこと。結局、何を作っても文句は言われます。不平不満に心を折られずに、インスピレーションに変えていく。
2. 開発コミュニティ
コミュニティーや開発チームをよいものにすること。
3. モチベーション
続けていくためのモチベーションの源泉を確保する。
4. 継続
20年間続いてきたからRubyがある。もし1年や5年で辞めていたら今のRubyはなかっただろう。
5. よい言語（プロダクト）を作る
自分が心から「いいな」と思うものを追求すること。
6. よいコミュニティ
ユーザーコミュニティーを味方につけること。ユーザーたちと開発者たちが、同じ方向を向いていくことが大切。
7. よい出会い
出会いを大切にすること。
8.運
素敵な人たちに出会えたことは本当にラッキーだったなと思います。
9. 英語
私自身、英語は得意というわけではありません。留学したこともなければ、住んだこともありませんから。
私もRubyを作り始めたときは日本人だけに届けばいいやと思っていました。でも、日本の中の情報って、海外からはとんでもなくググりにくいんです。
海外の友達から、こんな質問をされたことがあります。
「Matzのプログラミング言語は英語っぽい。日本語でできたプログラミング言語はないのか」
私はこう答えました。
「実は日本語のプログラミング言語はあるが、お前には見つけられない。なぜなら日本語で書いてあるから」
（会場笑）
残念ながら世界の公用語は英語です。日本だけに閉じこもるというのは、あまりにももったいない。
「感性の近い人だけが使ってくれればいいや」と思って作り始めたRuby。ところが、蓋を開けてみれば「Rubyは書いていて気分がいい」「Rubyが好きだ」という人が世界中にたくさん存在しているんです。
国籍も背景も文化も違うのに、驚くほど近い感性を持っている人が多い。これってすごいことじゃないですか？
つまり、あなたの作るプロダクトを気に入ってくれる人、驚くほど感性が近い人が日本国内にとどまらず世界各国にいる可能性が高いということです。
一人ではできなくても、コミュニティやチームを使ってできることもあります。可能性を広げましょう。
キーワードは「エゴレスプログラミング」
ひとつプロダクトを作ると「わしが育てた」と言いたくなってしまいます。このとき、自意識を制御することが結構重要だと思うんですね。必ずフェアになるよう、他の人に功績、つまり正当な評価をゆずりましょう。それは結局、自分に評価が返ってくるからです。
オープンソースとしてソフトウェアを公開することについても考えてみましょう。自然な思考として「無料で使ってください」というライセンスで配布する場合、「あんなに時間をかけて開発したのに、オープンソースにしてしまったらリターンがないじゃないか」と思いますよね。だってタダで配るんですから。直接的にはお金が発生しないんですよ。
ところがですよ。もし、私が当時「Rubyという言語を作りました。たくさん時間をかけて作ったので、1万円で売ります」と言っていたら……？Rubyはここまで広がっていなかったでしょう。
OSSとして公開したおかげで、たくさんの人が使うようになった。社会的にインパクトが出るようになった。その結果、「このRubyという言語の開発が継続することで、自分たちのビジネスにプラスになる」と思った企業が、我々の開発コミュニティー・私個人のスポンサーになってくれたのです。
もともと私は職業プログラマで、趣味の時間に細々とRubyを開発していました。ところが、今となってはRubyそのものは売り物でないのに関わらず、Rubyだけやってご飯が食べられるようになったわけです。
表面的なロジックだと
売らないから＝生活が成り立たない
ですが、我々に実際に起きたことは
無料で配ることによって＝生活が成り立つ
というものでした。
結局はそれに賭ける勇気、そして「私が作ったものを対価もなしに配るとはどういうことか」というエゴ（自意識）を抑えることによって、Rubyはここまで成長できたのです。
さて、Rubyがどう生まれ、どう世界に羽ばたいていったか、ひととおりお伝えしました。今日私が話したことは、ひとつの寓話です。皆様なりのメタ思考によって、皆様のプロダクトがたくさんの味方を得るヒントになれば幸いです。
"Matz"との距離が近いリクルートマーケティングパートナーズ
講演の後は、MatzさんとRMP社員でわいわいとRuby談義を楽しんでいる様子が見受けられました。Rubyの開発者と距離が近く、カジュアルに話ができるというのは、エンジニアにとって強力なモチベーションになります。会社全体で考えてみても、技術顧問としてのMatzさんの存在は、Rubyの最新動向にキャッチアップしていくという面で大変心強い存在です。
Rubyが世界へ羽ばたいて行ったように、より一層RMPもプロダクトをグローバルに展開させていく。そんな姿を重ね合わせながら、講演会は盛況のうちに幕を閉じました。
RMPが開発しているプロダクト
株式会社リクルートマーケティングパートナーズでは一緒に働く仲間を募集しています
リクルートマーケティングパートナーズではエンジニアを募集しております。一緒に働きたいと思った方はこちらから！