まつもとゆきひろ氏が登壇！「Visionとリーダーシップ」【Developer eXperience Day 2023】イベントレポートVol.4

日本CTO協会が主催を務め、2023年6月14日・15日に開催された大型カンファレンス「Developer eXperience Day 2023」。「Developer eXperience（=開発者体験）」をテーマとし、その知見・経験の共有とそれに関わる方々のコミュニケーションのために計30以上のセッションが行われました。

本記事では、「Visionとリーダーシップ」の様子をお届けいたします。

1. 登壇者紹介

1.1. まつもとゆきひろ（Matz）氏

2. 「BDFL」とは、慈悲深き終身の独裁者のことである。

3. リーダーシップをとるうえで、Visionは欠かせない。

3.1. RubyのVision

4. Visionとリーダーシップとは

5. Developer eXperience Day 2023 イベントレポート一覧

登壇者紹介

まつもとゆきひろ（Matz）氏

一般財団法人Rubyアソシエーション理事長（Ruby 開発者）

Rubyのパパ。Rubyアソシエーション理事長。OSS Vision(株) CTO

「BDFL」とは、慈悲深き終身の独裁者のことである。

ソフトウェア開発のプロダクトマネージメントにおいて、集団管理体制のようになるケースは多く見られます。プログラミング言語の開発においても同様で、「この機能を追加すべきか否か」について、投票を用いて決めるケースなどがあります。しかしながら、そのような体制はあまりうまくいかないことが多いです。意見が割れた際、先程述べたように投票などを用いて意思決定していってしまうと、ソフトウェア全体を見たときに凡庸になったり一貫性にかけてしまう恐れがあります。ですので、Rubyというプロダクトを作るコミュニティにおいて、私はプロダクトオーナーとしての絶対的な役割と全責任を持ち、いわゆるBDFL（=Benevolent Dictator For Life：慈悲深き終身の独裁者）として立ち回っています。BDFLは慈悲深い（強権的でない）独裁者（少数の意思決定者）ですので、私は周りの意見をしっかりと聞き、参考にしつつ、合理的かつ一貫性に基づいて判断し、私自身が最終意思決定をするようにするようにしています。オープンソースであるRuby開発において「慈悲深さ」がなく、強権的な態度を取っていると、プロジェクトがフォーク（=ある時点までの成果物をもとに、新たに別のプロジェクトを立ち上げること。）してしまう恐れがあります。そうすると、ただでさえ少ないリソースが分散してしまい、コミュニティの崩壊に繋がります。

リーダーシップをとるうえで、Visionは欠かせない。

リーダーとして重要なのは、メンバーのベクトルを揃えることです。コミュニティメンバー全員が同じ目標に向かって進んでいるとき、プロジェクトはうまくいきます。プロジェクトの創始者やプロダクトの責任者は、リーダーシップを取ることによって意識統一を徹底するべきです。基本的に、ソフトウェア開発に関わるほとんどの方は「よいもの」を作りたいと考えています。ただ、問題なのは「よい」が未定義であり、「なにをもってよいものとするのか」が明確でない点です。リーダーは、コミュニティメンバーのベクトルを揃えるために「よい」を定義し明確にする必要があります。そして、そのために重要なのが「Vision」です。Visionとは、そのプロダクトの「あるべき姿」や「成功した未来を予見するもの」「メンバーに対する説得力の根源」です。

RubyのVision

Programmers’ Best Friend

Rubyの開発を始めた1993年当時、コンピュータはまだまだ非力でしたので、プログラミング言語はマシンパワーを最大限に活用できるものが好ましいという考え方が一般的でした。C言語やC++はその時代の名残が色濃くあります。一方、小規模な開発を手軽に行いたいと考える人達にとっては、マシンパワーを最大限に活用する必要がなく、「スクリプト言語」と呼ばれるものを好んでいました。

私がプログラミング言語を開発しようと考え始めた頃、「特定の課題を解決する言語を作りたい」というよりは、「なんでもいいからプログラミング言語を作りたい」と思っていました。そして、スクリプト言語の可能性に注目し、スクリプト言語を作ろうとしていました。しかしながら、Awk,Perl,Pythonなどすでに先発のプログラミング言語は多数登場していたため、性能や機能などで真っ向勝負をしても、圧倒的な開発リソースの差により負けてしまうと考えていました。なので、私はRubyを開発する上で「私が楽しいかどうか」を重視することにしました。ただ、それではメンバーに対する説得力がなく、先程申し上げた「コミュニティメンバーのベクトルを揃える」ことと矛盾してしまいます。そこで、「よい言語」「たくさんの方に使ってもらえる言語」を作り、手軽な開発を実現するものを目指そうと考え、オブジェクト指向プログラミングの導入や、メタプログラミング、クラスライブラリの充実、生産性（と、楽しさ）にフォーカスすることにしました。

その後、スクリプト言語は「人間のための言語」であるものだと言語化し、そこからRubyのVisionである「Programmers’ Best Friend」という言葉が生まれました。これが「メンバーに対する説得力」に繋がり、開発に楽しさを求めるコミュニティという点でメンバーのベクトルを揃えることができました。それにより、コミュニティが成長し、メンバーの増加、機能増加、性能向上、実用性向上、ライブラリ増加、エンタープライズ利用と繋がり、うまくいきました。

驚き最小の原則

しかしながら、私が提示したVisionがうまくいかなかったこともありました。過去に、「驚き最小の原則」というものを掲げ、人間指向の自然な拡張（=人間が使っていて驚くことが少なく、直感的で自然な期待に答えられるようなデザイン）を目指していた時期がありました。このVisionがうまくいかなかった理由は、「誰にとっての驚きなのか」が定義されていなかったことでした。Rubyが好きでコミュニティに入ってきた方たちは、似たような感性を持っており、驚きを感じる点も似ているだろうと考えていたのですが、実際はそうではありませんでした。人間は自分のバックグラウンドをもとに形成された個別の視点に固執してしまう事があります。つまり、Javaを使っていた人にとってはJavaの機能や仕様が当たり前であり、Perlを使っていた人にとってはPerlの機能や使用が当たり前なのです。なので、「Javaを使っていた人が驚かないもの」だからといって、「Perlを使っていた人が驚かない」とは限らないのです。それにより議論が堂々巡りをするようになってしまい、そのVisionは取りやめ、以後Visionを掲げる際には以下の4点を意識するようにしました。

1.十分な情報を集める

前提として、リーダーはすべての専門家ではありません。例えば、私はRubyを作りましたが、Rubyをとりまくすべての物事を把握し、問題解決できるわけではありません。なので、判断をする前に専門家から情報を集めることが大切です。その際、感想や意見ではなく事実を集めることが大前提となります。

これに関して補足ですが、ユーザーに解決策を聞くことは問題の解決につながらず、リーダーの怠慢であるといえます。ヘンリー・フォード（自動車メーカーのフォード・モーター創設者）は、ユーザーに対して「あなたは何を求めるか」と質問した際、「より速く走ることができる馬」と回答されました。ユーザーは自分の「必要」を知らないため、「解決策（=あなたは何を求めるか）」ではなく、「解決したいことは何か」を問うべきなのです。今回の場合だと、ユーザーが「解決したいこと」は「移動に時間がかかる」ということでした。それを知ることができたからこそ、ソリューションとして「より速く走ることができる馬」ではなく「車」が生まれました。つまり、「ファクトを問い、本当の問題を知る」ということは非常に大切なのです。

2.トレードオフを考慮する

十分な情報を集め、真の問題を知った上で、トレードオフが存在することを考慮する必要があります。トレードオフに対して判断をしたり、優先順位をつけることがリーダーの役割です。

3.できるだけ説明可能な判断をする

機嫌や思いつきを排除し、説明可能な判断をすることが「よい」プロダクトに繋がっていくと言えます。機嫌や思いつきに基づいたロジカルでない判断はメンバーからの「納得」を得られず、フォークに繋がります。

4.上記3点を責任者が行う

フォークを発生させないためにも、上記3点は責任者の責務として行われるべきです。責任者以外が上記3点を行うような集団管理体制を取っていると、安易な判断によって方針がぶれ、一貫性がなくなる恐れがあります。私は、「驚き最小の原則」がうまくいかなかった経験によって、真のリーダーのあるべき態度は、判断や優先順位付けを人に任せるのではなく、自身が責任を持って実行することであると学びました。

Ruby3x3

8年ほど前に、Ruby3x3（ルビースリーバイスリー）というVisionを掲げました。具体的には、「Ruby3.0をRuby2.0より3倍高速にしよう」といったものでした。これはかなり困難な目標であり、当初から「やってみてだめだったらだめで仕方がないな」と考えていました。なぜこのようなVisionを掲げたかというと、ケネディ（アメリカ合衆国第35代大統領）の言葉に理由があります。彼は演説で「簡単だからではなく、難しいからこそ月に行く。」ということを述べました。実際に3倍高速にできずとも、困難な挑戦をみんなで乗り越えることにより、一体感や技術革新につながると私も考えたため、Ruby3x3を掲げました。

そして、Ruby3.0はRuby2.0と比べて3倍高速にすることができ、Ruby3x3は達成することができました。これこそまさに、Visionの効果だと考えています。3倍高速にするために、私は技術的な貢献はほとんどしていません。しかしながら、「3倍にする」というVisionを掲げ、リーダーシップを取ることにより沢山の方々がVisionを受け継いでくださり、頑張ってくださった結果達成することができました。

Visionとリーダーシップとは

Visionとは、チームの方向性を決定するために提示するものであり、チームのベクトルを揃える役割があります。そして、リーダーシップとは、解決すべき課題を正しく把握し、適切な解決策を模索し、トレードオフを検討し、納得可能な解決方針を提示することです。またメンバーよりも高い視座を持ってプロダクトの使用や未来、チームのモチベーションを管理する必要があります。

Visionとリーダーシップがよりよいプロダクトを作る。そしてそれが世界をよりよいものにする。つまり、Visionとリーダーシップはより良い世界のためにあるのです。