2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
リンクをコピー
記事をブックマーク
まつもとゆきひろ氏:それでは始めましょう。まつもとゆきひろと申します。よろしくお願いします。
(スライドを示して)こんなアイコンで、Twitterではつぶやいている人なのですが、だいぶ前に作ったので今よりもちょっと若い感じの似顔絵になっています。
今回のEngineer Festaの客層だとあまり自己紹介は要らないような気がしますが、まつもとゆきひろを名乗っていて、英語圏ではMatzと名乗っています。Rubyを作った人で、たぶん日本では一番有名なプログラマーなんじゃないかなぁと思います。今日は「Rubyを通して見たこの30年の変化」というタイトルで話します。
Rubyを作り始めたのは1993年なのですね。作り始める時に、まず先輩にチャットで相談しました。「こんなの作ろうと思ってるんですけど」みたいな記録が残っているんですけど、それが1993年の2月24日だそうです。先輩がよく記録してくれる人だったので、教えてくれました。
それから考えると2023年の2月で、Rubyを作り始めてから30年です。そうするとですね、今日の客層の中では生まれていない人もいるぐらい昔なわけですよね。
年寄りが昔話をするとだいぶ老害っぽい感じがするんですが、変化したことについて話せればと思っています。来年(2023年)で30年ですが、この30年間を俯瞰しながら変化について語れるといいなぁと考えています。
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年後を考えた時、長期的にそれにロックインされるのは、ちょっと危険です。変化しないものを探しましょう、ということです。
(次回へつづく)
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略