「良いものを作れば広まる」は嘘ではないが真実でもない　まつもとゆきひろ氏が語る、“30年”の経験の中で感じたこと

Rubyは30年間生き延びたソフトウェアプロダクト

まつもとゆきひろ氏（以下、まつもと）：それでは発表をさせてください。「成功するソフトウェアの作り方」と題しまして、Rubyのまつもとが発表します。先ほど「Heroku」の発表がありましたが、私は元Herokuなので、すごく懐かしく聞いていました（笑）。

（スライドを示して）こんなアイコンでふだん活動しています。

英語圏ではMatzという名前を使っています。Rubyを作った人として知られていて、おそらくはRubyのおかげで日本人プログラマーとしては一番有名だろうと思います。「優秀だろう」と言いたいところなんですけれども、そうも言えないところは残念です（笑）。知名度だけは高いと言えます。

1993年にRubyを作り始めましたので、2023年で実に30年。「そんなに時間が経ったのか」という感じではあるんですけれども。考えてみると、ソフトウェアプロダクトって寿命が長くないことがわりと多くてですね。30年も続いているソフトウェアって、あまりないんですよね。

そういう意味でいうと、貴重な成功例だと言うこともできるんじゃないかなと思います。30年間生き延びたソフトウェアプロダクトとして、ある意味成功したほうと言ってもいいんじゃないかなと思います。

その30年の経験は、全部なにもかもうまくいったわけではなくて、「思うようにならんな」と思ったこともたくさんあるんですけれども、そういうのも踏まえて、自分の経験から「成功するソフトウェアとは何ぞや？」みたいな話をできたらいいなというふうに思っています。

ソフトウェアにおける成功とは何か

まず「成功とは何ぞや？」ということを定義したいんですけれども。ビジネスでソフトウェアを作っている時の成功というのは、「お金を生み出すソフトウェア」と言いたいんですけど、難しくてですね。

例えば私のやっているオープンソースソフトウェアは、いくら広まってもお金はぜんぜん入ってこないんですよね（笑）。売上が立っていないので。

私自身、ビジネス経験がすごくあるわけではないので、「お金を生み出すソフトウェア」としての（意味での）「成功するソフトウェア」の話で、説得力のある話はしづらいんですね。

それを考えると、「お金を生み出す」というのは「ビジネス的に成功する」みたいな、営業などのいろいろな要素が含まれてくるので今回はちょっと避けて、別の定義を使ってみようと思います。

（今回は）「広く、長く」というキーワードで定義できるような成功するソフトウェアを考えています。どういうことかというと、1人だけが使っているソフトウェアを作っても、（それが）成功したとはなかなか言い難いので。たくさんの人たちにリーチして、たくさんの人たちに使ってもらえる、あるいはたくさんの人たちに喜んでもらえるようなソフトウェアは「成功したソフトウェア」と言ってもいいだろうというふうに思います。

それから、パッと出てきて、1年間だけ話題になったんだけど、その次の年とか、2年、3年経つうちに誰も使わなくなって、「あぁ、そんなものもあったね」って言われるようなソフトウェアも意外と多くて（笑）。そうすると、リーチする範囲はともかくとして、時間的要素みたいなものもあるんじゃないかなと。

だから、縦軸として「どのぐらい広く使われたか」と、横軸として「時間としてどのぐらいの寿命を持ったか」ということで、両方が大きくて、トータルの面積が広いようなソフトウェアを、この講演の中では「成功するソフトウェア」と定義して考えてみようと思います。

ソフトウェア開発者の立場になって考えるために“生涯プログラマー”を目指す

私自身はですね、エンジニア出身というか、今でもエンジニアのつもりなんですが。実際“生涯プログラマー”を目指していて。私はもう50代、2023年で58歳になるんですけど（笑）。そうすると、私の同期とか同世代の人たちとかは、なんか「上がり」というか、「いやぁ、昔はコードをばりばり書いたけど、最近ソフトウェア開発をしていなくて」とか「プログラミングから離れて久しくて」みたいな人が多いんですよね。

すごく悔しくてですね（笑）。私自身は、プログラミングという活動から絶対に離れないようにしようと思っていて、今でも「GitHub」でmatzっていうアカウントで活動しています。

GitHubって知っていますか。活動すると緑の点がついて、いっぱいコミットすると緑が濃くなるんですね。なので、できるだけ毎日緑になるようにということを目標にして、「1日1コミットはしよう」みたいなことを考えて今でもがんばって活動しています。もう2年以上かな。毎日1コミットがんばっていますけれども（笑）。

ソフトウェア開発の気持ちがわからなくなってしまうとマネージャーみたいな立場になって話しがちなんですが、同士である、ソフトウェアを直接開発する人の立場になって物を考えたいと思っているところもあります。

「良いものを作れば広まる」は嘘ではないが真実でもない

ソフトウェア開発者として、私は若い頃ずっと「良いものを作ればソフトウェアっていうのは広まる、ひいては成功する」と考えていたんですね。

大学卒業して、ソフトウェア会社に就職してプログラマーとして働いていて、ソフトウェアプロダクトを作っている時もずっと「良いものを作れば広まる、いろいろな人たちに見つけてもらって、いろいろ人に使ってもらえて」というふうに考えていたんですね。

実際に自分で「これこそが私の理想の言語だ」みたいな（ことを思える）Rubyというものを作って、それが長い目で見るといろいろな人に使われたので。一番人気っていうわけにはなかなかいかない。PythonとかRustとかに人気や評判とかでは勝てないんですけど（笑）。

そうは言っても、いろいろな人、おそらくは100万人以上の人たちが日々使うようなプログラミング言語まで成長したという意味では、プログラミングデザイナー、プログラミング開発者としては、自分の作ったプロダクトは成功したというふうに言ってもいいと思うので。

「良いものを作れば広まる」ということは長らく間違っていないと思っていたんです。

しかし30年経っていろいろな経験をした後で振り返ってみると、「良いものを作れば広まる」っていうのは、まったくの嘘だというわけではないんだけれども、「完全にこれが真実だ」というわけでもないなと思いました。

“良い”を定義するためには、説得力のあるビジョンを持つ必要がある

どういうことかというと、最初に「良いものを作れば広まる」の前提になる「良いもの」というところ。ここの「良い」っていうのは未定義なんですね。

例えば、「プログラミング言語として良いプログラミング言語」というふうに言った時に、例えば「Rubyが良いプログラミング言語かどうか」というのと「Rustが良いプログラミング言語か」っていう時に、同じ指標で測ることは難しいですよね。「Rustのある機能がRubyにはないからRubyは駄目だ」とか、その逆みたいなことはあまりないんですね。

RustはRustで良いところがあるし、RubyはRubyでいいところがある。英語の慣用句として「アップルとオレンジを比べる」みたいな表現がありますけれども、同じ指標で比べてもしょうがないところがあるんですよね。

つまり、いいかどうかは1次元ではないので、直接比較することはできないんですね。私が今働いているこのソフトウェアがいいかどうかっていうことは、ほかのなにかと比べるのではなくて、その言語なり、プロダクトなりがどういう軸で良いかについて考えないといけないんです。

それは「誰にとって良いものなのか」ということとか、あるいはプログラミング言語の話なので、「どんなプログラミング言語が良いプログラミング言語なのか」とか、そういう感じで“良い”を定義しないと話にならないんですよね。

「なにが良いか」を定義するということは、つまり「私たちは世の中にこういうプロダクトがあったほうが、こういうサービスがあったほうがよいと思うんです」ということを定義するかたちになって。それこそビジョンとして世に示すべきものだと思うんですね。

それを考えると、ビジョンを示しているかどうかというのと、「良いものを作る」の「良い」は、非常に強く結びついているんだと思います。

Rubyの場合は、自分がどんな言語が欲しいのかを考えた上で、その理想みたいなものを詰め込んで、いろいろな言語の機能を持ってきた上でRubyという一貫したフォーマットというか形式とポリシーに合っているかどうか、あるいは合っていなかったら合わせるような変更をした上で組み込んできて、理想を追求したところに良さを示してきました。

こういう「理想の追求」みたいなものが、私がRubyを通じて世に問うた「良い言語」というものだったんですけども、それがある程度共感を得たからこそ、たくさんの人たちが「Ruby、いいよね」と言ってくれて、Rubyを使ってくれたということだと思うんですね。

ということは、“良い”を定義するためには、説得力のあるビジョンを持つ必要があって、「これこれこういうようなもの」を“良い”として世に問う。「その背景にあるビジョンはこういうもので、こういうビジョンに従ってデザインされた言語だからこそ良いものです」というふうなことを言うということですね。

そのビジョンによって、コミュニティに対しての求心力、「そういうビジョンがあるならそれのために集まろう」とか、オープンソースソフトウェアの場合、Rubyはオープンソフトウェアなので「開発に参加しよう」みたいなことになるわけですね。

30年前のRubyは今のクオリティから考えると驚くほど低かったわけなんですけれども、そういう人たちがどんどん集まって、私自身だったりコミュニティの人たちだったりが力を合わせて進歩させてきて、今のクオリティと今の機能のレベルまで到達したわけなんです。

そういうのも、ビジョンを提示した、ビジョンに共感してくれた方が集まってということだと思うんですね。

そういうビジョンがあるからこそ、「そのソフトウェアをどんどん作っていこう」というモチベーションも上がってきたと思います。

なので、ビジョンというのは、ソフトウェアのあり方を導き出すために非常に必要なことなんですね。それも、すごく深く考えないといけないんですよ。

表面的に“良い”だけでは十分ではない

（スライドを示して）このおじさんはヘンリー・フォードさんっていう人なんですけども、ヘンリー・フォードさんの頃は自動車が発明されたばっかりで、世の中の人たちは「自動車が本当に世の中を変えるテクノロジーかどうか」ということに対して、あまり信じていなかったんですね。

当時は道路は舗装されていないし貧弱だし、ガソリン自動車もだいぶ貧弱で燃費も悪いという、今思えばですねだいぶ欠けていたものだったので、これが世の中を変えるソリューションになるかはあまり信じていない人が多かったんですね。

そういう状況でヘンリー・フォードさんが「もし私が人々に対して『どんなものが欲しいの？』と聞いたらほとんどの人は、急いで移動する時は馬を使う時代だったので、『速い馬が欲しい』というふうに言うだろう」というふうに（言いました）。

でもヘンリー・フォードさんは「それがソリューションではない」と。自動車こそが世の中を変えるソリューションだと信じて、人々が表面的に欲しいものじゃないものに対して……。まぁ、ユーザーに直接聞くと、情報的にろくな答えが返ってこないんですよね（笑）。ユーザーは「こんなものが欲しい」と言うんですけど、だいたいの場合それってろくなもんじゃないんですよね。

ユーザーは自覚していないけど、本当はあったら便利なものを提示するのがビジョンなんですよね。馬全盛期の時に自動車を提供するようなものがビジョンであるというわけですね。

そういう意味では、「馬が欲しい」と言ったら「馬を用意します」ではなくて、本質を見抜いて備える必要がある。だから、表面的に良いだけでは十分ではなくて、それ以上のことをしないといけません。

（次回に続く）