2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
まつもとゆきひろ氏:こんにちは、まつもとゆきひろと申します。今日はですね、DXDカンファレンス(「Developer eXperience Day 2023」)で「Visionとリーダーシップ」というテーマでお話をします。よろしくお願いします。
今日はRubyのカンファレンスではないので、まず自己紹介から始めます。まつもとゆきひろと申します。こんなアイコンで活動していますけども、ふだんはひらがなで「まつもとゆきひろ」という名前を使っています。まぁ、ペンネームですね。それから英語圏では、Matzというニックネームで活動しています。なんかね、「ゆきひろ」とか「まつもと」とかだとあまり覚えてもらえないので、自分で短いニックネームを付けて、こう呼ぼうと決めています。
誰かというと、Rubyを作った人ですね。プログラミング言語のRubyを知っている人もそれなりにいると思いますが、そのRubyを作った人です。その結果、たぶん日本人で一番有名なプログラマーと言ってもいいんじゃないかなと思います。
もちろん優秀なプログラマーの方はたくさんいらっしゃるんですが、例えば海外に行って、「日本人で誰かプログラマーを知っているか?」と聞いた時、まぁいろいろな方の名前が出るかと思いますが、たぶん私の名前が一番たくさん出るんじゃないかなと思います。「(日本で)一番優秀なプログラマー」と(スライドに)入れてもよかったんですけど、そこまでは、残念ながらちょっといかない感じがします。
あと、松江市さんから名誉市民というものをいただいていまして、松江市名誉市民です。
Rubyを作り始めてから、今年(2023年)で30年経ったんですが、今日はその30年の間で学んだことをベースにお話ししようと思います。Rubyを作り始めたのは、1993年2月24日です。ずいぶん昔になりますね。30年以上も前です。
その時から現在まで続く、このRubyというものをソフトウェアプロジェクトとして見た時、あるいはRubyというものをソフトウェアプロダクトとして考えた時に、ある種の特異性があるんじゃないかなとは思います。
その特異性とは何かというと、1つは「30年続くプロジェクトである」ということですね。それから「海外でも広く使われていること」。それから「オープンソースである」ということ。これらがRubyをソフトウェアプロダクトとして見た時の特異性ではないかと思います。
考えてみると、今日はDXD、Developer eXperience Dayなので、ソフトウェアの開発について、ある程度の知見を持った方がたくさん聞いてくださっていると思います。ソフトウェアってあまり長生きしないんですよね。ソフトウェアには寿命があって、多くのソフトウェアは何年とか、長くても10年とかです。廃れるソフトウェアというのが、圧倒的に多いんですよ。
それを考えると、(Rubyの)30年ってすごく特異なんですね。ソフトウェアの寿命は何で決まるのか。例えば、多くの企業体は30年ぐらいが寿命であることが多いと言われています。つまり30年経つと世代交代があったり、事業を引き継いだりする中でうまくいかないことが多くて、潰れたり買収されたり業態変換したりすることが多いんですね。
ソフトウェアは組織によって運営されることが多いので、組織の寿命がプロダクトの寿命になることが多いです。そういう意味で言うと、「プロダクトの継続」みたいなものが困難になるのが、5年、10年、15年という感じです。それを超えて生き残るソフトウェアももちろんありますが、少数派ですね。
ソフトウェアは物理的実体がないので、放っておいても腐ったり錆びたりしないんですよね。なので、1回作ったらずっともちそうな気がするのですが、まぁ実際はそうはいかないんですね。例えば、「周りの環境が変化して、それに適応できない」ということがよく起きるんですよ。
具体的に言うと、例えばハードウェア環境。
Rubyを作った30年前のコンピューターは、パPC-9801とか、そんな感じの時代です。当時は「国民機」と言われて「パソコンと言えばPC98です」という感じだったんですが、現在においてそのPC98を使っている企業は……まだ工場とかで動いているという話ですが、実際は少数派ですよね。
私自身は、当時ソニーのUNIXワークステーションというものを使っていました。今のソニーはコンピューターは作っていますが、ワークステーションは作っていないんですね。その後、サン・マイクロシステムズという会社の、やはりUNIXワークステーションを使ったのですが、その会社ももう今はないんです。このように、ハードウェア環境が変化するということが当然あるわけです。
あとは、例えば30年前のコンピューターのCPUは、コアが1個しかなかったんですね。パソコン1個にCPUが1個というのが当たり前だったのですが、現在のコンピューターにおいてはマルチコアが当たり前で、ちょっとしたサーバーマシンだとコアが16個とか、64個とかがあったりするんですよね。
大きめのマシンで「コアが128個あります」みたいなものは、現代では別に珍しくもなんともないわけです。そうすると、コア1個を想定して作られたソフトウェアは環境に適用できていないとなるんですね。
ソフトウェアについてもそうです。ソフトウェアトレンドはけっこう変化するので、放っておくと適応できない。
例えば30年前は、Webはぜんぜん一般的ではなかったんですが、今この講演は「Stream Yard」というソフトを使って中継しています。そのStream Yardも、結局はブラウザの中で動いているWeb経由の技術です。
このオンラインのカンファレンスそのものが、「enavle」というソフトを使っているんですが、これもWebアプリケーションですよね。30年前のソフトがもしWebに対応できていなければ、それは生き残っていけない。ソフトウェアトレンドによって、どんどん立ち位置が変化していくということはあり得ると思います。
あとはユーザー層も変化するわけです。ソフトウェアトレンドはユーザー層から現れるというのもそうで、ユーザー層の変化に適用していかなければいけない。そうしないと生き延びていけません。
Rubyのもう1つの特異性は、海外に進出したことだと思うんですね。実際にRubyを使っている人たちは日本人だけではなくて、世界中にいます。正直に言うと、日本人が開発したソフトウェアで海外で使われている物はあまりたくさんはないんですよね。車とか、家電とか、トヨタとか、パナソニックとか、ソニーとか、あとはゲーム機とかですね。
日本人が作ったそういうものは世界中で使われているのに、なぜか一般のソフトウェアは、海外にウケないんですよ。「なんでだろうな」という感じではあるんですけれども(笑)。そういう中で、海外に展開できているRubyは、ある種特異であると言えると思います。これが、なんでそうなのかはよくわからないんですね。
例えばゲームは間違いなくソフトウェアですが、日本発のゲームは意外と海外でも遊ばれているんですよね。そうなると、「日本人がソフトウェアを作るのが上手か下手か」みたいな話ではないと思うんですよ。だけど、そのビジネスであるとか、下回りのOSであるとか、言語であるとかで、海外で使われているソフトウェアがあまりないのが現状です。
おそらくは、日本のマーケットのサイズが十分に大きいので、野望を持たずに普通にご飯を食べようと思ったら日本だけでやっていけるんですよね。例えば、商習慣の違いとか、文化の違いとか、法律の違いとか、そういう違いを乗り越えて海外に進出するためには、高いハードルを越えることが必要で、それだけのモチベーションがない場合「じゃあ国内でいいか」みたいになってしまいがちです。それが日本のソフトウェアが海外に出ていかない理由の1つではないかなとは思います。
高い志を持って海外に出ていきたい人がいても、先ほど言った商習慣とか、文化とか、言語とか、そういう違いを乗り越えるのが難しいんだと思います。
そういう意味で言うと、Rubyはシステムプログラミング、プログラミング言語という、わりとわかりやすいジャンルの中で海外のユーザー層にリーチできたので、非常にラッキーだったなと思います。
最後は、オープンソースであるという話です。
オープンソースの説明は、今さらいらないと思いますが、20年前とは違って無償で自由に配布することができるソフトウェアです。これをソフトウェアプロダクトを作るプロジェクトとして考えると、とにかくお金がないんですよね。つまり、ソフトウェアそのものは無償で配っているので売上がないわけです。
売上がないので、開発している人たちのほとんどは、ボランティアというか有志で開発しているんですね。私自身はRubyを作っていることで給料をもらっていますが、それも特殊というか、スポンサーに支援していただいているのであって、ほとんどの人はボランタリーで自主的に参加していて売上がないので、採用してなんとかみたいなことができないんですよ。人事権もないんですね。
さらに言うと、Rubyコミュニティに強制されて来ている人は誰もいないし、給料を払っているわけでもないので、業務命令というものがないんですよね。「お前、このプロジェクトをやれよ」とかは言いにくいんですよ。そもそもプロジェクトは、プロジェクトをコントロールする、プロジェクトマネジメントみたいなことがすごく難しいんですね。
みなさんに提供できるものは何かというと、例えば達成感ですね。そういうもので、惹きつける。名誉経済みたいな感じですね。やっと回っている感じなんです。そういう意味で言うと、会社の業務として開発するソフトウェアプロダクトとだいぶ毛色が違うところはあると思います。
ですが、そういう困難さがあっても、30年間続いていて、海外にも進出することができて、たぶん〇百万人のユーザーがいるソフトウェアを作ることができた。それだけのソフトウェアプロジェクトを30年間立ち止まらずにここまでできたというのは、自慢してもいいんじゃないかなと思います(笑)。すごく狙ったわけではないですが、結果的にプロダクトオーナーとして、大成功したと言ってもいいんじゃないかなと思います。
(次回につづく)
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
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには