今日のテーマは「Rubyを通して見たこの30年の変化」
まつもとゆきひろ氏：それでは始めましょう。まつもとゆきひろと申します。よろしくお願いします。
（スライドを示して）こんなアイコンで、Twitterではつぶやいている人なのですが、だいぶ前に作ったので今よりもちょっと若い感じの似顔絵になっています。
今回のEngineer Festaの客層だとあまり自己紹介は要らないような気がしますが、まつもとゆきひろを名乗っていて、英語圏ではMatzと名乗っています。Rubyを作った人で、たぶん日本では一番有名なプログラマーなんじゃないかなぁと思います。今日は「Rubyを通して見たこの30年の変化」というタイトルで話します。
Rubyを作り始めたのは1993年なのですね。作り始める時に、まず先輩にチャットで相談しました。「こんなの作ろうと思ってるんですけど」みたいな記録が残っているんですけど、それが1993年の2月24日だそうです。先輩がよく記録してくれる人だったので、教えてくれました。
それから考えると2023年の2月で、Rubyを作り始めてから30年です。そうするとですね、今日の客層の中では生まれていない人もいるぐらい昔なわけですよね。
年寄りが昔話をするとだいぶ老害っぽい感じがするんですが、変化したことについて話せればと思っています。来年（2023年）で30年ですが、この30年間を俯瞰しながら変化について語れるといいなぁと考えています。
Ruby開発のきっかけはチームの解散
1993年というとバブル崩壊直後なのですね。だいたい1991年とか1992年とかぐらいに、景気がドンドン悪くなっていった感じがします。
その頃私は、いわゆるソフトウェアハウスというんですかね、システム開発会社にいました。その会社は受託開発をしていたのですが、私が配属されたチームは、社内で働くエンジニアの生産性を高めるためのツールを作っていました。
比較的自由に開発できてすごく良い環境だったのですが、景気が悪くなると、社内で使うためのツールは売上が立たないから、外貨を稼いでこないんですね。そうすると、経営陣も危機感を持って、「こんなに景気が悪くなってきて全体の売上が下がっているのに、この売上が立たないツールの開発にそんなに人を割り当てるわけにはいかない」という話になって、「残念ながらあなた方のチームは解散です」と言われました。「ああそうですか」という感じですけど。
そういう悲しい過去があったのですが、逆にいうと、そのチームの解散がRubyの開発のきっかけになりました。
会社員時代に上司から得た教訓
（スライドを示して）当時私が使っていたマシンは、ソニーが作っていたエンジニアリングワークステーションでした。社内のシステムを開発していたし、Rubyの最初のコードを書いたのもこのマシンでした。
CPUがモトローラのMC68020でクロックは16MHz、メモリが8MBで、ハードディスクが156MB、OSがUNIX系の「NEWS-OS」です。BSD3.xみたいなやつをソニーがちょっと改造したものらしいです。
これはエンジニアリングワークステーションという一応プロのためのツールなので、1台で200万円以上します。そういうマシンを当時の開発者はツールとして使っていました。
社内同一システムだったので、メモリ容量とハードディスクの容量だけは違ったり、あと時代によって、筐体の大きさが若干変わったりするのですが、基本的に同じCPU、同じOSで同じソフトが動くアーキテクチャでした。
当時としてはまだ珍しく、イーサーネットで全部つながった状態でマルチメディアメール、今でいう添付ファイルが付いたメールシステムや、あるいは設計用の絵を描いたりするツールを一揃い自社で開発していました。
ネットワークに非常に強く依存したツールだったので、なかなか楽しいソフトウェア開発でした。ホモジニアス、均質なソフトウェア環境と言われる全社同一OS・同一CPUだったのですが、ソースコードを見たら、ネットワークを越えたマシンに構造体をバイナリコピーしていました。
大学で勉強していた時に「それはやっちゃいけないことだ」と教わっていたので、先輩に「これ、ちょっと構造体をそのまんまバイナリコピーしています。同じCPU、OS、コンパイラだったら問題ないですけど、違うアーキテクチャが入ってきたら途端に破綻しますよね」と話をしました。当時は入社1年目か2年目ぐらいだったと思います。1年目だったかな。
アラインメントやエンディアンなど、いろいろあるわけです。構造体のメンバー間の隙間が空く大きさが、OSによって違ったりします。それからエンディアンといって、整数をバイナリ表現する時に、下の桁が前に来るのか上の桁が前に来るのか等が違ったりするので「他のアーキテクチャだと、そのままバイナリコピーすると破綻しますよ」と話しました。
そうしたら先輩から「我が社のシステムはホモジニアスな環境であることが最初から想定されていて、それを前提条件にしていいので、想定しなくても大丈夫」と言われました。
「上司がそういう言うんならそうなのですね……」と、そこはそのまま放置していたんですよね。だけど、そんなに経たないうちに、新しいバージョンのNEWSマシンのOSが、BSD系からSystem V系という違う系統に変わっちゃったんですね（笑）。
システムコールもけっこう変わるし、CPUも違っていて、「これどうすんの？」みたいな感じになりました。しかも、その大丈夫と言った上司よりもっと上の取締役あたりから、「ちょっとIBMのマシンもおもしろそうだから試しにつなぎたいんだけど」とか言われました。
今はもうなくなりましたが、「PowerPC」というRISCマシンが入ってきて、それにも対応してくれみたいなこと言われて、「ああー」という感じでした。
モトローラのCPUは、ビックエンディアンというタイプの1個バイナリ表現なのですけれども、System V系とか、PowerPCとか、リトルエンディアンとかが入ってきたので、それを見て「ああー」という感じで、みんな総出で、構造体を直接ネットワークに書き込んでるところはどこだっけ？ と探し回って全部つぶすという、非常にひどい目に遭ったことがあります。
私はこのことから、「誰かが大丈夫と言っても信じてはいけない」という教訓を得ました。上司とか、大丈夫と言った人が想像もつかないようなことが未来には起きます。
長期的な予想をすることは困難なので、「未来はこのままでいく」とか「大丈夫」と言われても信じてはいけません。
ソフトウェアの寿命は人が予想するよりも遥かに長い
特に重要なのが、ツールの持続性です。特に便利な商用のツールを採用した時が難しいです。
何が起きるかというと、ソフトウェアの寿命が長い場合にソフトウェアがまだ生きているのに、実際そのソフトウェアを作るのに使った商用ツールが、発売中止、サポート停止、あるいは会社が倒産ということがけっこうあるんですね。
自分の作るシステムは、今回1回だけしか使いませんというならぜんぜん関係ないんですけど、10年20年使われる可能性があると考えると、サードパーティのものを使う時は、「何かあったら自分でメンテできる」ぐらいの心意気がないと困るんですね。
ソフトウェアの寿命は予想外に長いと言えます。IBMの中で使われていたREXXというスクリプト言語があります。その言語を作った人はマイク・カウリシャーさんという人で、IBMのフェローをしていました。
彼は、「自分が20年前にIBMで新人だった頃に書いたソフトウェアのバグについて、ある日レポートがきた」と言うんですね。20年前に書いたプログラムだから何も覚えていないのに、IBMにたくさんいるエンジニアの中の誰かがそれを使い続けていて、「あなたの書いたこんなプログラムがバグっているんですけど」とレポートしてくるんですね。それで、「ああそうですか」みたいなことがあるそうです。
自分は書き切ったつもりだったのに、ちょっとしたプログラムを書いたつもりだったのに、それが20年間動き続けたこともあるそうです。ソフトウェアの寿命は、人が予想するよりも遥かに長いんです。
商用のサードパーティは変化しないものを探す
考えてみたら、Rubyも同じです。1993年に作り始めた時に、まさか30年後もRubyをメンテしているとは思わないじゃないですか。5年ぐらい持てばいいかな、と思って作っていました。それが、30年経って、すごくたくさんの人に使われるようになったというのは、予想外なわけです。
だとすると、ソフトウェアに関する予想、未来に関する予想はだいたい外れます。なので、できるだけ変わらない（変わりにくい）ものを押さえておくのが肝要かなぁと思います。それまで長く生き残ったものは、これからも長く続く可能性がけっこう高いと思います。
それから、オープンソースソフトウェアの場合だと、ソースコードが手に入っているので、何かあった時には最悪自分でメンテできるのがメリットになると思います。
例えば、LinuxやFreeBSDみたいなOS。Linuxで30年、FreeBSDだとCoreから数えると、もう40年ぐらいメンテされているので、明日なくなることを心配しなくてもいいし、ソースコードが全部公開されているので、いざとなったら自分で中を見られる安心感があります。
すごく生産性が高い商用ソフトのほうが、かえって危ないということが言えると思います。商用のサードパーティは、特に欠かせないものでその時に便利なものは（利用しても）ぜんぜん問題ないのですが、5年後や10年後を考えた時、長期的にそれにロックインされるのは、ちょっと危険です。変化しないものを探しましょう、ということです。
（次回へつづく）
