2023年6月14日から15日にかけて、日本CTO協会が主催するカンファレンス「Developer eXperience Day 2023」が開催されました。さまざまなテーマのセッションがおこなわれたなかで、本記事では「ビジョンとリーダーシップの重要性」をテーマにしたセッションの内容をお届けします。
セッションにはプログラミング言語「Ruby」の開発者である、まつもとゆきひろ（Matz）さんが登壇。その模様をお届けします。
まつもとゆきひろ（Matz）さん
Rubyのパパ。一般財団法人Rubyアソシエーション理事長。 OSS Vision（株） CTO
目次
「Ruby」30年の歴史から学んだこと
まつもとゆきひろと申します。英語圏では「Matz」というニックネームを使用しています。
わたしはプログラミング言語の「Ruby」をつくりました。その結果、おそらく日本人で一番有名なプログラマと言ってもいいのではないかと思います。
Rubyをつくりはじめてから、今年で30年が経ちました。その間に学んだことをお話ししようと思います。
Rubyをつくりはじめたのが、1993年2月24日です。
そのときから現代まで続くRubyをソフトウェアプロダクトとして考えたときに、ある種の特異性があると思います。
Rubyの特異性は、次の3つです。
- 30年続くプロジェクト
- 海外でも広く使われている
- オープンソース
ソフトウェアには寿命があって、あまり長生きしません。数年から長くても10年くらいで廃れてしまうソフトウェアが圧倒的に多いです。
ソフトウェアには物理的実体がないので、放っておいても腐ったり錆びたりはしません。
そのため、1回つくったらずっと持ちそうな気がしますが、そうはいきません。
ハードウェア環境やソフトウェアトレンドなど、周りの環境が変化して、それに適応できないことがよく起きます。
ユーザー層も変化します。このユーザー層の変化にも適応していかなければ生き残れません。
日本のソフトウェアが海外進出しない理由
Rubyの特異性の1つに、海外進出が挙げられます。Rubyを使っている方は日本だけではなく、世界中にいます。
日本人が開発したOSやプログラミング言語などのソフトウェアが、海外でも使われているケースは多くありません。
でも、日本発のゲームは海外でも遊ばれています。ゲームはソフトウェアですから、日本人がソフトウェアをつくるのが下手という話ではないと思います。それなのになぜ、OSやプログラミング言語などのソフトウェアが海外進出しないのでしょうか。
おそらくは、日本のマーケットサイズが十分に大きいからです。食べていくだけなら、日本のマーケットだけでもやっていけます。
そうすると、たとえば商習慣の違いや文化の違い、法律の違いなどを乗り越えて海外進出していくだけの高いモチベーションがなくなってしまいます。
オープンソースの大変さ
Rubyの特異性として、オープンソースであることも挙げられます。オープンソースをソフトウェア開発プロジェクトとして考えると、とにかくお金がないんですよね。ソフトウェアそのものは無償で配るので、売上がないわけです。
売上がないので、人材採用ができません。開発する人たちのほとんどはボランティアです。
さらに、Rubyコミュニティに参加するのも強制でなければ、給料を支払っているわけでもありません。なので、業務命令として「このタスクをやってほしい」とは言えないんですよ。そうなると、プロジェクトのコントロールが難しくなります。
このように、会社の業務として開発するソフトウェアとは、だいぶ毛色が違います。
こうした困難さがあっても30年間続いていて、海外にも進出でき、数百万人のユーザーがいるソフトウェアをつくれたことは自慢してもいいと思います（笑）。
Rubyはわたしがはじめたので、コミュニティのなかでの絶対的な立ち位置があります。Pythonコミュニティから来た言葉に、「BDFL（Benevolent Dictator For Life）」があります。「慈悲深き終身の独裁者」という意味の言葉です。
独裁者というのは、少数の意思決定者によってプロダクトがリードされていることを意味すると思います。
「慈悲深き」というのは、「強権的ではない」ことです。人の話を十分に聞いたうえで、合理的に判断する独裁者といえます。
オープンソースのソフトウェアの場合、ソースコードを含めてすべて公開されています。強権的な態度を取っていると、プロジェクトが分離してしまう可能性もあるんです。ただでさえ少ないリソースが分散されてしまって、チームが崩壊してしまうかもしれません。
こうした事態を避けるためにも、少数の決定者によって一貫的な判断をするだけではなく、人の話も聞いて、コミュニティの分裂や崩壊が起きないようにする必要があります。
ビジョンはプロダクトの「あるべき姿」
プロダクト開発のプロジェクトをうまく進めるために「ベクトルを揃える」という言い方を、わたしはよく使います。開発コミュニティに参加している全員が同じゴールに向かって進んでいるときに、プロジェクトはうまくいきます。
プロダクトの創始者あるいはプロダクトの責任者がリーダーシップをとって、意識統一を徹底することが必要です。
ほとんどの開発メンバーは、「よいもの」をつくりたいと思っています。
ただし、「よい」という言葉はものすごくあいまいで、未定義ですよね。どういう性質を持ったプロダクトがよいものなのかを明確にする必要があります。よいを定義するわけです。
それこそが、リーダーやオーナーの重要な責務であると思います。
その責務を果たすときに重要なツールが、「Vision（ビジョン）」です。ビジョンは、そのプロダクトのあるべき姿、未来の予見、説得力の根源となります。
Rubyのビジョンは「Programmers’ Best Friend」です。
Rubyをつくりはじめた1993年当時、プログラミング言語はマシンパワーを最大限に使うことが望ましいとされていました。
一方、手軽に小規模な開発をおこなうのであれば、パフォーマンスはあまり関係ないという人たちもいて、そういうものがスクリプト言語と呼ばれていました。
わたしは特定の目的を解決するためにプログラミング言語をつくりたいというよりも、プログラミング言語ならなんでもいいからつくりたいと思っていたんです。そのときにスクリプト言語の可能性に注目し、自分がつくるならこれを作ろうと思いました。
ただ、後発で真っ向勝負を挑んでも、なかなか勝ち目はありません。性能や機能で競争しても勝てないわけです。そこで、手軽な開発の部分にフォーカスしようと思い、スクリプト言語の方向性を言語化しました。そのなかで「Programmers’ Best Friend」という言葉も生まれました。
解決すべき課題を正しく把握して、適切な解決策を模索する
わたしはRubyをつくりましたが、Rubyを構成しているありとあらゆるジャンルの専門家ではありません。たとえばRubyのなかにはネットワークライブラリがありますが、わたしはネットワークの専門家ではありません。
なにかを判断する前に、コミュニティにいるくわしい人に話を聞いて、情報を十分に集めるんですね。そのときに、個人の感想や意見ではなくて、ファクトを集める必要があります。
ファクトを集め、トレードオフが存在することを認めたうえで判断しなければなりません。物事の優先順位はリーダーが決めるべきことです。トレードオフに対して判断をする、優先順位を決定することがよいプロダクトをつくることにつながると思います。
その際には、できるだけ説明可能な判断が必要です。「機嫌」や「思いつき」によって行動するリーダーにはついていきたくないですよね。分裂を招いてしまいます。
つまり、リーダーシップとは、解決すべき課題を正しく把握して、適切な解決策を模索することです。そこにトレードオフがともなう複数のアイデアがあった場合は検討して、それをみなさんに対して納得可能な解決方法を提示するわけですね。
リーダーはメンバーと一緒に働くわけなので、チームの方向性を決定する必要があります。チームを一方向にまとめないと、ベクトルがバラバラになって打ち消しあってしまい、チームの生産性が下がってしまいます。ベクトルを揃えるためには、ビジョンの提示が必要です。
ビジョンとリーダーシップがプロダクトをつくる
ビジョン、つまりどのようなソフトウェアをつくり、どのような問題を解決するのか。これらを説得力のある形で提示します。それをすることがリーダーシップです。リーダーシップによって「よいプロダクト」をつくれます。
よいプロダクトをつくることで、プロダクトの存在する世界がよりよくなると信じています。
それこそが、わたしたちがよいソフトウェアをつくる・つくりたいと思う動機の源ではないでしょうか。
（取材／文：川崎博則）
