Rubyの生みの親 まつもとゆきひろ
プログラミング言語「Ruby」の生みの親。1993年頃からRubyの開発に着手し1995年にフリーソフトとして公開。NPO法人軽量Rubyフォーラム理事長を始め、株式会社ネットワーク応用通信研究所フェロー、一般社団法人「Rubyアソシエーション」理事長、米Heroku Chief Architectなど、肩書多数。三女一男一匹の父である。
Vareal株式会社代表取締役社長 寺本昌弘
福岡県北九州市出身、京都大学工学部卒。2006年05月にVareal株式会社を創業、設立。東京・福岡を中心にシステム・ソフトウェア開発などの事業を展開している。美味しいもの、日本酒、ワインが好き。好きな言葉は「今やらねばいつできる、わしがやらねばたれがやる（平櫛 田中）」。
対談内容
今回は、2024年1月12日に行われた、まつもとゆきひろ氏×寺本昌弘による対談の内容をご紹介させていただきます。貴重なお話をお伺いできたので是非最後までご覧ください！
Rubyとの出会い
まつもとさん、今日はよろしくお願いいたします。
こちらこそよろしくお願いします。
ちょっと振り返りをさせて頂きますと、前回対談の機会を頂いたのが2017年で、その際にまつもとさんが執筆された「オブジェクト指向スクリプト言語Ruby」にサインを頂きました。
本当だ、サイン入ってる。
この本は私が大学2年生のときに購入して、私がRubyと出会ったきっかけになったものです。当時まさかこんな形で執筆者であるまつもとさんとお会いできるなんて夢にも思っていなかったですし、RubyがこのWebの世界でこんなにスタンダードになるとも思っていませんでした。
私からすると20年経って非常に感慨深いんですけれども、もちろんRubyを作られて30周年を迎えたまつもとさんは非常に感慨深いものがあったのでは無いかと思うのですが、この30年間を振り返っていかがですか？
どうだろう。ソフトウェアって続かないものが多いんですよね。古いコンピューター関係の雑誌を見るの好きなんですが、10年前20年前のものを見ると、そこに載っている広告とか商品とか、記事で扱っているソフトウェアとかって大体全滅しているんですよね。その中にあってRubyはまだ生き残っているので、良かった良かったって。
雑誌のコーナーのためにつくった言語
先日、30周年のイベント記事を読ませて頂いて、Rubyを作られる前に色々な言語を作られたとか。
作りかけましたね。（笑）
Rubyを作った後もmruby、mruby/Cを作られてますよね。それからStreemの話を伺いたいんですけれど、Streemは雑誌のコーナーのために作られたんですか？
そうなんです。雑誌の連載のために書いてましたね。
1つの雑誌のコーナーのために言語を作るんですよ。こんなことできるのは日本では唯一言語デザイナーのまつもとさんしかできないんですけれども。今もまた新たな構想を考えていらっしゃっているとか。
考えているだけですけどね（笑）
勝率7割
その雑誌の記事の中で構想したものの70％は実現されてきたということを拝見してすごく驚きました。
去年の話ですね。Ruby会議とか、あとはアメリカのRuby Conferenceとかで、「未来のRubyはこうなる」みたいなことやこんな機能を入れようと思うみたいな話をするんですね。
大体誰とも相談しないでKeynoteを書いているので、皆そんなこと聞いてないよって思うんだけど（笑）最初のRuby Conferenceが開催された2001年から一昨年のものまでカウントして、数は忘れちゃったけれど提案した数と最終的に採用された数とを比べたら勝率7割っていう。
それはすごいですよね。
言ったけど何もなりませんでしたみたいなものも結構あるんです。3割は言っただけ、みたいな感じです。
7割ってすごい実現率だと思います。
後半のやつはほとんど自分は手を出していないからね。恐ろしいことに。
つまりどなたかが打ち上げられたということですね。
そう、ここ10年ぐらいは誰かがやったのが結構ありますね。。2001年ぐらいの時はだいぶ手を出していたので提案したものは自分で作っていたんだけど、ここ10年ぐらいは「こんな機能があると良いと思うんだけど」みたいなことを言ったら、すぐに「作りました」とくるので「やった」とか言って（笑）
最近の話題で言いますとプリズムが導入されたり、MJITがYJITに置き換えられたりと、、パフォーマンスを向上させる取り組みをされていらっしゃってありがたいなと感じています。これらはまつもとさんが提案して皆さんが取り組まれているんですか？それともコミュニティで俺はこれをやりたい！みたいなところから実現されているんですか？
両方じゃないかな。何かしらRubyに貢献したいけれど何をしたら良いかみたいな人もいて、その時に私の話を聞いてじゃあこれをやろうか！と思う人もいるだろうし、逆に自分からこれをやりたいと手を挙げてくれて、Rubyに貢献された方もいますね。
OSS-Vision株式会社の立ち上げ
最近OSS-Visionを立ち上げられたとのことで、そちらの話も伺いたいです。
そうです。CTOのまつもとです。初めて役員になった（笑）
おめでとうございます！
給料無いですけれどね。無給で働いてるんです。
本当ですか！役割だけ、義務だけ？
はい（笑）
名前からして、Open Softwareの世界を広げるのか、そこら辺を是非伺いたいなと思ったんですけれど。
OSS-Visionを宣伝して良いんですか！？
ぜひぜひ。
1997年に起業したネットワーク応用通信研究所、通称NaClという会社を松江でずっとやっていて、私も1997年にちょっと遅れてジョインしているんですが、そこの会社も25年ぐらい経って、井上さんが若い人に譲るって言って社長を辞めたんですよ。
次の社長はRubyコミッターの前田修吾さんが就任されたんですね。Rubyコミッターが社長をしている会社は他に無いんじゃないかなと思ったんですけれども。
そして、副社長は同じくRubyコミッターの後藤裕蔵さんが就任されて、社長副社長がRubyコミッターという非常に稀有な会社で。
それで、何かやりたいことない？という話を相談されていて、じゃあ1つ考えがあると話をして作ったのがOSS-Visionですね。
OSS-Visionの取り組み
OSS-Visionのやっている仕事って大体3つぐらいあって、そのうちの1つはTシャツとかグッズを作っていて（笑）
それが1番最初にくるんですね（笑）
これはお小遣い程度にしかならないんですけれど。例えばRuby会議のRuby WeekというイベントのTシャツを作って売ったりしてます（笑）
２つ目が、カンファレンスの情報を集約するサービスの立ち上げを考えています。例えば10年前のRuby会議のスポンサーが誰だったのかやカンファレンスで誰がどんな話をしたかという情報って、Webサイトで消えちゃうこともあるんですね。だから情報が残らないんですよ。それらを集約するようなサイトを作りましょうというサービスを考えています。
そうすると過去のRuby会議で私の会社は何年間スポンサーをしてきました、みたいなことがアピールできるので、企業さんから会費を頂いて、ランディングページみたいなところに載せますみたいな感じのサービスをやっていますけれど、お小遣いにしかならないですね（笑）
あはは（笑）
3つ目がセミナー事業ですね。私は色々な会社の技術顧問をしているんですが、大体自社でプロダクトを開発している会社しか技術顧問していないんですよ。だけども受託開発のように見積もりやスケジュールとかを考慮しながら開発しているんですね。
自社プロダクトを開発している時に、あまり見積もりとかスケジュールとか要らなくない？と思って。
一方で、オープンソースコミュニティには業務命令が無いので、開発スピードが速いという特徴があるんですね。なので企業もプロダクトマネジメントに関してオープンソースのやり方を適用してプロダクトを開発するとエンジニアがもっと幸せになる会社が増えるんじゃないかな、と思ったんですね。
もちろん全部の会社に適用することは不可能で、そもそも受託開発しているところにオープンソースのやり方ってできないので。ただ、自社プロダクトに対して裁量権を自社で持っている時は、見積もりとかスケジュールとか作らない方が効率が良くて心理的安全性があって開発スピードも速い、幸せな開発ができるやり方がありますよ、ということを教えるセミナーをしています。OSSのやり方だからOSS-Visonという。
そういうことですね。何でそれを1番に持ってこないんですか（笑）
まだ全然売上が立っていない。（笑）1月末に行う第1回のセミナーでどのぐらいの反応があるかなという感じです。
モチベーションはどこから生まれる？
弊社は受託開発を主軸としていますが、1つの試みとして、オープンソースコミュニティのやり方で任意の有志がVareal Familiaというプロダクトを開発しています。
何でこのプロジェクトが始まったかというと、うちの会社をもっと魅力的にするにはどうしたら良いんだろうっていう話し合いを社内でしていて、なににも縛られず自由に開発できるプロジェクトを1つ作ってみたいという意見から始まったのですが。
そういう取り組みってこれまでやったこと無くて、とてもチャレンジングで面白いなと思っていたんですが。やはり少し義務感が出てきていまいち前進していないところがあります、、
開発のモチベーションというのはどこから生まれると考えていらっしゃいますか？
基本的にソフトウェア開発は、楽しいものと思っているんですね。問題を解決することによる達成感みたいな。つまり世の中には、クロスワードパズルを喜んで解く人がいて、その人はお金のために解いているのではなく問題を解くことが楽しいからやっているということがあると思うんですね。
あとは、何か作り出す創造の楽しさですよね。絵を描く人もいるだろうし、写真を撮る人もいるだろうし、小説書く人もいるかもしれない。そういう作品を世に出すことで、自分の努力や技術の結晶がここに生まれましたということに喜びを感じる人って結構いるんですね。ソフトウェア開発にもそういう楽しさがある。
やりたくないなあ、けど締切が、、ていう気持ちよりは、今日は何をしてやろうか、どう改善してやろうかって思っている人の方が生産性が高いんじゃないかなと思います。心が生産性に大きく影響するんですね。だけどそこで進捗遅れてるんだけどと言われると楽しさが減っていって結構辛い（笑）楽しさを減らすようなことは何とかして避けていきたいというのが私の考えです。
楽しみと締切のバランスを取っていくのが大きな課題
オープンソースコミュニティの場合そういうビジネス上での制約が無く、趣味の高度版みたいなイメージがあります。一方で仕事としてプログラミングを書いていると、楽しみと締切とのバランスを取っていくのが1つ大きな課題かなというのはずっと思っています。何かそこについてアドバイスありますか？
本当は締め切りが無い方が良いですよね。（笑）何故締切が発生するかというと、やっぱり約束するからなんですよね。見積もりをしてクライアントといつまでに納品すると約束するんですが、そもそもソフトウェアって正確な見積もりをする手段が知られていないと思うんです。上司から「このタスク、君のチームでどのぐらいでできると思う？」と聞かれたら何て答えますか？
「まあこのぐらいのレンジですかね」と答えます。
そうですよね。正直なところ、上司に見積もってと言われたら「分かりません」ていう答えになるんです。でも、上司はクライアントに「どのくらいでできるか分かりません」と言うわけにもいかないので「じゃあ大体で良いから分かる範囲内で見積もってくれ」って技術者に言いますよね。
すると技術者は「じゃあ分からないけど、これぐらいかな」って上司に出してそのまま進めてしまうと、納期に間に合わなくなったとき上司から「お前はできるって言ったじゃないか」となります。技術者はいい加減で良いから出してくれって言われたから出したのに、それを正確な約束として捉えられたらどうしようもないですよね。何が言いたいかというと「約束するのはいけない。」ということです（笑）
ありがとうございます。（笑）そこはうちの会社でも受託の方では頑張っていて、まずレンジを示しますと。だけど、約束はできませんというところからまず入ります。
クライアントが分かってくれると良いですよね（笑）
これに対して解決をする方法は2つしか思いつかなくて。
1つは、顧問ソフトウェア開発者っていうんですかね。顧問料として毎月費用をいただいて、毎月少しずつ開発していきます。ある時点でサービスは提供できますし、追加の機能が欲しいんだったらお約束している稼働時間の範囲内でソフトウェアを作っていきます。というやり方。
もう1つは、受託というビジネスモデルを切り捨てて、自社のプロダクトでサービスをやるというやり方。この2つしか思いつかないんです。それ以外はレンジでやって約束はできませんっていうところを納得してくれるクライアントがいるといいですよね。本当に。
あくまでそれは一番最初の入り口だけで、実際詳細の話を聞いて画面の設計とかをやった後は確定したスケジュールをやっぱり出さないといけないです。ただ、そこの前提条件についても、こういうところは考慮していませんとか色々細かく書く必要はありますね。
そうですよね。この見積もりをやっているコストをソフトウェア開発に回せたらどんなにいいかと思います（笑）自己防衛のためには見積もりを細かく書く必要がありますが、それでもなお不測の事態が起きるんです。
顧問型のサービスに似たところでいうと、準委任契約という形は、受託（請負契約）に比べると、エンジニアは幸せそうな顔はしていますね。
見積もりの概念をできるだけ減らしたい
ちなみにRubyを作られた時って、どれだけの時間がかかるとかイメージはあったんですか？
全然。見積もりというものが存在している世界では無いので、できたら良いや、みたいな感じで作っていました。でもモチベーションは高いから、どんどんやるし、やれば少しずつ進んでいくしという感じで。
なるほど。新しいプロダクトを作るっていうところに関わっていると、考えることが多すぎて、本当にまつもとさんが仰る通り見積もりがすごく大変です。
プロダクトを作る時の見積もりっていう概念をできるだけ減らしたいというのがOSS-Visionのセミナーで教えることの1つなんですね。
ちなみにそれは非プロダクトエンジニアでも分かるような内容になるんですか？
ソフトウェア会社にいないと分からないような話はしないつもりです。
お話を伺っていますと、どちらかと言うと会社の経営をやる立場ですとか、プロダクトマネージャーの立場の方がまずそこでしっかり認識する必要があると思いますね。
そうですね。ボトムアップだと結構辛いと思いますね。トップダウンで一番上がそういうやり方をするんだって決めないとどうにもならないですね。寺本さんが見積もれって言ってるのに、私は見積もりたくありませんって言ってもそこはどうにもならないですよね（笑）
そうですよね（笑）ちなみに僕も見積もりを如何に軽減するかということはすごくポイントだと思っています。
是非それをゼロにできれば良いなと。
そうですね（笑）
良いエンジニアってどういうエンジニアだろう？
ちょっと話題を変えまして、社内にいるエンジニアは、キャリアチェンジをしてエンジニアになったケースがすごく多いんですよ。僕はそういった子たちを応援したいなと思っています。
一方で、どうしてもバックグラウンド的にコンピューターサイエンスの知識が無いと弱い部分があるんですね。そういう人たちが、良いエンジニアになりたいと思って励んでくれているんですが、まつもとさんが考える良いエンジニアってどういう人だと思いますか。
職業エンジニアで限定して話をすると、「問題を解決できるエンジニア」の一言だと思います。問題を解決する中には、問題が何であるか発見するところも含まれます。場合によっては別のエンジニアが問題を発見して解決だけやるっていう事もありますが。
クライアントが何となく不便だなと思って相談をしたり、ユーザーが操作している時に不便さを感じているという問題を解決するためには、知識が必要だと思います。今の自分にその知識がなかったら、調べたり人に聞いたりしてその知識がどこにあるかを知ることも問題解決力に含まれますよね。
その中で自分の興味が深くて、自分の専門分野ができたらそこに対して深掘りすれば良いと思うんですけど。基本的には今自分が取り組んでいる解決すべき問題に対して何らかの方法で必要な知識を調べて、それを実際にソフトウェアに落とし込むということができる人が良いエンジニアなんじゃないかなと思いますね。
Rubyの将来について
僕ばっかり質問してしまっていますが、ここにいるメンバーのなかでまつもとさんに質問がある方はいますか？
では僕から1つ質問させてください！AIやVRそしてIRもある中でRubyの将来はどうなりますか？
少なくとも近い将来にAIを作る方の言語としてはRubyの出番はあまり無いかなと思っています。それは技術的な問題では無くて、コミュニティのサイズの問題なんですね。
AIは言語に興味が無いんですよね。つまり、隣の人が使っている言語と同じ言語を使えば良いやってなるので、そこに素晴らしい言語があるんですけどって言われても、いやそれ誰も使ってないからって。困ったことに一度広まった言語に勝つのは難しいんですね。
ただ、Rubyにとってラッキーだったのは、AIがデータを集めていたときには既にRubyについての情報が世の中にたくさん存在していたので、RubyのことをChatGPTに聞いたら教えてくれるんですね。だけど全く新しい言語についてChatGPTに聞いても情報は知られていないので、その言語について知りませんっていって断られちゃうんですね。
もしかするとChatGPT以後の言語というのは広まるのがより難しくなるかもしれない。新しい言語を勉強したい人は、ChatGPTに聞いてサンプルプログラムを出してもらうというのを良く聞くようになったんですよね。これから先、初心者が使うツールとして対話型AIみたいなものが重要視されるようになってきているので、そうすると新しい言語にとってはそれが不利になるということは危惧しています。
それに絡めて言うと、ChatGPTが出てきたお陰で、今まで使ったことのない機能だったり言語そのものが速く学べるようになり、学習コストが大幅に下がってきたイメージがあります。
そこで1つ仮説として、非職業エンジニアたちが短期間でアプリケーションをある程度まで作れるようになるということは、裾野が広がる可能性が大きいなと感じているんですけれども、まつもとさんはその点についていかがですか？
そうだと思いますね。例えば何十年前のプログラミングってすごく大変だったんですよね。それに比べると現代はプログラミング言語のレベルは高いし、あまり書かなくてもできるように段々技術が進歩してきたんですね。
ChatGPTやCopilotみたいなAIの進化によってプログラマーはもう要らなくなります。というようなことは僕は起きないと思っていて。だけど生産性向上とか省略化とかのツールとしてすごく役に立っているなと思います。
Rubyの開発で心がけていること
私からも質問させてください！Rubyの開発に携わっている方は、Rubyを作っていくこと自体に魅力を感じているところが大きいのかなと思うんですけど、まつもとさんがRubyの開発に対して心がけられていることはありますか？
まずは敷居を下げたいなと思っています。例えばRustやGoの開発に参加したいと思っても、敷居が高いんですよね。なのでRubyは参加しやすくしたいと思っています。
実は過去にいたVareal社員が、RubyとRailsのメソッドに抜けているメソッドがあることを発見し、GitHubでプルリクエスト送って採用されたことがありました。
昔は特別な許可など面倒くさいことがあったけれど、今だとGitHubでプルリクエストを送りつけるとコミッターがレビューして、そのプルリクエストをそのまま取り入れられるので、更に敷居が下がったと思います。さらに今はGitHubでプルリクエストを受け付けるのでその人の名前がそのまま残ります。
なるほど。大チャンスですね（笑）我々も何らかの形でRubyに貢献できるように頑張っていきましょう。
では本日の対談はここまでとさせていただきます。貴重なお話をお聞かせいただきありがとうございました！
こちらこそありがとうございました！
まとめ
最後までご覧いただきありがとうございます！対談内容はいかがでしたでしょうか？Rubyの発展から良いエンジニアの定義とはなどなど…貴重なお話をたくさん伺えました。次回の対談もお楽しみに！
