2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
まつもとゆきひろ氏:それでは始めましょう。まつもとゆきひろと申します。よろしくお願いします。
(スライドを示して)こんなアイコンで、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.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには