“変化の拒絶”か“過剰な進化か”——求められるトレードオフ　ソフトウェアが進化し続けるために必要なこと　

「Ruby3.0はRuby2.0よりも3倍高速にしよう」とぶち上げた

まつもとゆきひろ氏：さて、もう8年になるのか（笑）。8年ぐらい前に「Ruby3x3」という別のRubyのコミュニティのスローガンを立ち上げました。意味としては「Ruby3.0というバージョンを、Ruby2.0というバージョンよりも3倍高速にしよう」という開発者のためのゴールであり、スローガンです。

ある処理を3倍にするというのは、あまり簡単なことではないんですよね。これは、だいぶ困難な目標です。アメリカの「Ruby Conferences」というカンファレンスのキーノートで、正直に言うと「やってみてできなかったらできなかったでしょうがないや」と思いながらこのスローガンをぶち上げたんですね。

ジョン・F・ケネディ大統領が1963年にアメリカの大学で演説をした時に「We choose to go to the moon」という有名な演説をしました。「簡単だから月に行くんじゃなくて、難しいから行くんだ」「それがチャレンジだ」と言っているんですね。その困難な挑戦をみんなで乗り越えることによって一体感が生まれる。あるいは技術革新を起こすということです。

ぶち上げたことを言ったのは私なんですけど（笑）。この「3倍速くする！」という技術的チャレンジ、技術的困難さをぶち上げることによって、たくさんの人たちががんばって、「そこをちょっと速くしよう」と、いろいろな技術的工夫をすることによって、本当に3倍になったんですね。ある種のベンチマークにおいて3倍になったんです。

ケネディ大統領は月（へ行くため）のロケットを作らなかったんですよ。というか、ロケットを作る前に亡くなっているんですが、アメリカは月に行ったんですよね。Rubyも同じように私の技術的貢献はほぼないんです。

だけど、私が「3倍にしよう！」と旗を振ることによって、リーダーシップを取ることによって、たくさんの方々がいろいろなビジョンを受け継いでくれて、「こうやってやろう」「ああやってやろう」「こういう技術的チャレンジを果たそう」とがんばってくださった結果、本当に3倍速くなったんですね。これは、そのビジョンの効果だと思うんです。

変化しないと魅力がなくなる、過剰に進化すると巨大化し過ぎて発展できなくなる

先ほどのソフトウェアの寿命の話に戻ると、ソフトウェアは老化するんですよ。変化の追随ができない環境変化。ハードウェアの変化によるソフトウェアの環境とか、ビジネスの環境とか、ユーザーの変化とかで追随することが難しくなってくるので、その現実と乖離したプロダクトはまず廃れていくんですね。

よく我々の業界では「停滞したオープンソースソフトウェアは廃れる」と言うんですよ。先ほども言いましたが、変化のないソフトウェアは、本当は腐らないんですよ。腐らないし、錆びないし、傷まないですが、実際には周りの環境の変化に追随することができないソフトウェアはだんだん魅力がなくなるんですよね。

魅力がなくなったオープンソースソフトウェアからはユーザーも離れていくし、開発コミュニティも小さくなっていくので、結果的に廃れていく。そうやって誰も使わなくなってしまったオープンソースソフトウェアは本当にたくさんあるんですね。でも考えてみると、オープンソースソフトウェアでなくても廃れるんですよね。

それで魅力が低下したり、あるいはコミュニティが縮小したり。コミュニティが縮小するとさらに魅力が少なくなるので、さらにユーザーが少なくなるという負のサイクルが起きるわけです。そうすると、そのソフトウェアプロダクトが生き延びて進化し続けるためには、継続的な進歩が必要なんですね。

なんだけど、これはけっこう危険なトレードオフがあるんです。「Creeping Featurism」という言葉で、Perlコミュニティでは「Feeping Creaturism」と言っています。

Creepは「はう」という意味で、featureは「機能」ですよね。ソフトウェアプロダクトを長いこと開発していると、どんどん機能を増やしていくんですよ。つまり変化していかないといけないし、新しい機能を提供していかないと魅力がなくなってしまうと感じるので、どんどん新しい機能を入れるんだけど、新しい機能を入れるとソフトウェアの規模が大きくなってソフトウェアが複雑になって、メンテナンス性が下がって、だんだん開発速度が遅くなって、結果的に停滞するということが起きるんですよね。

変化しないと魅力がなくなるし、過剰に進化してしまうとその進化そのものの重さによって巨大化し過ぎて発展できなくなる。どちらも悲しい感じですが、これもまたトレードオフなんですよね。

変化が必要な場合は大胆に変化するが、基本的な部分は変えない「水道モデル」

「これをやればいつもうまくいく」とは言いませんが、私が好きなのは「水道モデル」と呼んでいるものです。

みなさんのご家庭にも水道が来ていて、蛇口をひねると水が出ると思います。この水道事業は、ほとんどの場合自治体が運営しています。蛇口をひねると水が出るというモデルは、もう100年以上そういう感じなんですよね。100年前から蛇口をひねると水が出るという感じなんです。この機能は、安定した基本的な機能ですよね。

例えば、私の住んでいる松江市は「蛇口をひねるとオレンジジュースが出るようにしましょう」とか「うどんの出汁が出るようにしましょう」とか、そういう新しい機能は提供しません。しないほうがいいと思いますけど（笑）。あるいは蛇口をひねるとお湯が出るという機能は、だいたいのお家にありますが、じゃあ水道がそれを提供しているかというと、そうじゃなくて、それはローカルで提供しているんですよね。家にボイラーがあって、それが水をお湯に変えて出す。それによって本質的な水道事業は、蛇口をひねると水が出るという基本的な機能に特化しています。

一方で、なにもしていないのかというとそうでもなくて、例えば水道の配管が老化するのをメンテナンスするとか、あるいは大きな漏水があったらそこを工事して直すとか、水道の浄水場を改善して、より効率的に浄水できるようにしようとか、よりコストを下げようみたいなことをしているわけです。

そういう継続的な保守は行っていて、継続的な更新も行っているんだけど、基本的な部分は基本的な機能に特化している感じです。ソフトウェアプロダクトとして変化が必要だった場合は大胆に変化するかもしれないけれども、基本的な部分は変えずにいる。水道としての魅力をなくすようなことはしないし、必要以上にコストがかかるようなこともしないということですね。

プロダクトに関わる全員の人たちのベクトルを揃えることが必要

つまり、リーダーシップとは何かというと、解決すべき課題を正しく把握して適切な解決策を模索して、トレードオフが伴う複数のアイデアがあった場合には、トレードオフを検討して、みなさんに対して納得可能な解決方法を提示することです。リーダーが自分で手を動かすばかりではなく、もちろんメンバーと一緒に働くわけですが、ただその時にはチームの方向性を決定する必要があります。

チームの方向を一方向にまとめないと、ベクトルがバラバラになってしまって打ち消しあってしまうので、チームの生産性が下がるんですよね。そうしないためにもチーム、全社と言ってもいいと思いますが、そのプロダクトに関わる全員の人たちの方向性を揃えることが必要です。そのためにはビジョンを提示して、「そのビジョンの方向だ！」と言ってベクトルを揃える必要があります。

そうするとそのプロダクトを管理する人たち、プロダクトオーナーだったり、プロダクトマネージャーと言うのかな？　プロダクトマネージャーの管理するものには、プロダクトの仕様や、プロダクトの未来が必要です。さらにプロダクトの未来を見るためには、そのメンバーよりも高い視座を持って、このソフトウェアは何をするものでこれから先どういうふうに変わっていくべきか、ということを考えていかないといけないということです。さらにそのチームの人たちが、くだらない対立によってモチベーションを奪われて生産性が下がることがないようにしないといけないということだと思います。

管理がそれほど重要ではないものもある

一方、管理しないものもあってですね……。管理はそれほど重要ではないという言い方をしましょうか。まずはスケジュール。オープンソースソフトウェアだからというのもあるんですが、Rubyにおいてスケジュールはあまり重要ではありません。Rubyはちょっと特殊なやり方をしていて、毎年12月25日にリリースしているんですよ。年次リリースなんですけども。

新しい機能で「これを入れましょう」「あれを入れましょう」みたいな話があって、リリースに間に合ったものは入れるけど、間に合わなかったものは次の年にとなるんですね。だいたいの人たちは、自分の開発したものは次のリリースに入れたいのでスケジュールに間に合うように動かすんですけども、そうすると「あなたの今やっているプロジェクトがなにかの事情で遅れたら延期、来年ね」というふうになるんです。

受託開発やクライアントのためにソフトウェアを開発していると、スケジュールってすごく大事なんですよ。なぜかというと契約書の中に「いつまでに納めます」って書いてあるから。その場合はしょうがないんですが、例えば自社プロダクトを作っていると、場合によっては「毎日リリースします」とか「毎日デプロイします」とか「毎時間デプロイします」みたいなことがけっこうあるわけです。

そうするとスケジュールはあまり意味がないんですよね。「スケジュールを守る」とか「スケジュールを立てる」にあまり意味がないんです。そうすると、プロダクトマネジメントの中のスケジュール管理はさほど重要ではないということですね。

さらに言うと、これもオープンソースならではなんですが、予算がそもそもないので、予算も管理しないんですよね（笑）。みんなで集まって、できるだけ開発するけれど、できなかったり間に合わなかったりしたら「まぁ、しょうがないよね」という感じになります。

いわゆるプロジェクト管理みたいなものは、オープンソースソフトウェアの開発の場合、ないというか、いらないんですよね。

「業務としてソフトウェアを開発している場合は別だろう」とおっしゃる方がほとんどだと思うんですけども、私の見立てだと、先ほども言いましたが受託開発は別ですよ？　契約の中に時間、予算というタイムフレーム、制約条件を入れなくてもいい開発って、思ったより多いんじゃないかなと思っているんですね。その場合は、そのオープンソース的やり方を適用したソフトウェア開発をすることができるんじゃないかなと考えています。その範囲は、みなさんが想像しているよりもはるかに広いんじゃないかなと思います。

ちょっと流行に疎いので最近聞いたのですが、今は「インナーソース」という言葉があって、これはオープンソースのやり方を社内ソフトウェアの開発に取り込むという試みだそうです。このキーワードで検索すると、いろいろとおもしろい情報があるんですが、そういうインナーソースのやり方だとプロジェクト管理みたいなものの重要度が格段に下がるんじゃないかなと思います。

リーダーは「何を解決するのか」を具体的あるいは説得力のあるかたちで提示し続ける

最後に何が言いたいかというと、ビジョン。つまり、どんなソフトウェアを作るか。どんな問題を解決するかを具体的に、あるいは説得力のあるかたちで提示し続けるリーダーシップによって、良いプロダクトを作ることができる。

良いプロダクトを作ることによって、そのプロダクトのユーザーにとって、あるいはそのプロダクトが存在する世界がより良くなると思います。結局は、ソフトウェアを作るということは、「良いプロダクトを作ることによって世界を変える、世界をより良いものにする」と言えるんじゃないかなと思っています。それこそが、私たちが良いソフトウェアを作りたいと思う、その動機の源ではないかなと思います。

今日話したいことは、だいたいここまでですね。今回の話は、Salesforce.com、松江にあるネットワーク応用通信研究所、松江にあるOSS Vision株式会社、それから私に対して個人的に支援してくださるGitHub Sponsors。そしてなによりですね、私と30年間一緒にRubyを開発してきてくれたRubyコミュニティのみなさんによってお送りいたしました。ありがとうございました。