なぜソフトウェアは死んでしまうのか
まつもとゆきひろ氏（以下、まつもと）：今度は横軸、時間軸です。ソフトウェアの寿命って意外と短いんですよね。開発のほうでいうと、毎年新しいWebアプリケーションフレームワークとか、なんとかツールみたいなものがどんどん出てくるんですけど、数年経つと何か違うものに取って代わられるみたいなことが頻繁に起きるんですよね。
物によるんですが、アプリケーションとかだと数年。2年とか3年とかで代わることが多いです。全部じゃないですけど、多くて。
その下にあるフレームワークとかだと10年ぐらいもつものもけっこうあって。Ruby on Railsは2004年発なので2024年で20年という、だいぶ息の長い感じのアプリケーションフレームワークです。
さらにその下のプログラミング言語とかだと、Rubyは30周年になりますが、もうちょっと長めという傾向があります。いずれにしてもソフトウェアっていうのは、いつまでも生きられるものではない。ソフトウェアっていうのはよく死ぬんですね。時々長生きなやつがいるという感じで。
ソフトウェアが死ぬってどういうことかというと、例えば状況の変化についていけなくなってしまう。例えばOSが変わってしまうとか、「Windows 95で動いていたアプリは、新しいWindows 11（の環境）では動きません」みたいなこともよく起きるわけなんですが、そういう感じの環境の変化とかですね。
あるいはハードウェアですね。昔のコンピューターは1台しかCPUを積んでいませんでしたが、今のコンピューターはマルチコアで4つとか8つとか32とか64とかCPUを積んでいるような変化とか。あるいはデータ量が増えました、通信量が増えましたみたいな状況の変化とかもありますね。
そういうのについていけなくなったりすると、ユーザーが離れていって、より新しい状況に適したようなソフトウェアに移行してしまうようなことが起きます。
意外と多いのがスポンサーの離反というかたちで、例えば、そのサービスをやっている会社そのものが「事業の方向が変わりました」とか「会社そのものがどこかに買収されてしまいました」とかいろいろなことがあって、「ご好評のなんとかサービスは何年何月をもってサービス停止させていただきます」みたいなこと（になってしまうこと）がしょっちゅう起きるわけですよね。
結局いろいろなかたちで状況が変化するので、その状況の変化に対応できるかが寿命につながるということだと思うんですね。そうすると、どんどん変化していく足元の状況をいつも把握していないといけないということがあると思います。
変化と話題性のバランスが非常に強く求められる
特に「Creeping Featurism」という言葉があって。「Creeping」は「這い寄る」という感じ（の意味）ですね。「Feature」は機能です。
寿命が長いソフトウェアはずっと同じではいられない。状況の変化とかにどんどん対応していかないといけないので、「新しい機能を追加しましょう」ということになりがちなんですよね。
そうすると、メニューがものすごく大きくなったりとか選択肢が増えたりとか機能が増えるんだけど、そのうち90パーセントぐらいは誰も使っていないみたいなことが起きるわけですよね。
機能が増えるとソフトウェアが複雑になるんですけど、その複雑さによってもたらされるデメリットみたいなものも当然あるので、這い寄る機能みたいなものはけっこう気をつけないといけない。
個人的に望ましいと思っているのは「水道モデル」って私は呼んでいるんですけど、どこの家も水道の契約をしていると思うんですけど。蛇口を捻ると水が出るっていう。
水道の機能って、「以上、終わり」なんですよね。おうちによっては、例えばボイラーとつながっているので、お湯が出る機能もついていたりするわけなんですが、少なくとも日本ではほとんどの町ではお湯は供給されないんですよね。水をお湯に変えるのは手元の機能なんですよ。サービスとしては水を提供するという機能だけを何十年もしてきているわけですよね。それでみんな満足している。
ということを考えると、安定して機能を増やすわけでもなく、状況の変化とかには対応しつつ、機能を増やさず安定してサービスを提供する、あるいはパフォーマンスは改善するとか小さな改善のまま、基本的な部分は同じままずっといくのが理想に近いかなと思っているんですね。
しかし一方、話題にならないソフトウェアというのは、聴衆を集められない傾向にあるんですね。オープンソースソフトウェアはよく「サメモデル」だと言われているんですけれども。
つまり、何か変化がないと、泳ぐのをやめてしまうと死んでしまう。つまり「今年はこんな新しい機能が出ました」とか「こういう新しい改善をしました」みたいなことを常に提示していかなくちゃいけないということです。
つまり、機能について足るを知る。変化はしないで、この時点（のもの）で満足するということと、機能なり性能なりの拡大路線みたいなものというのは、いつもバランスを取らないといけないという、かなり難しいところがあるというふうに思いますね。
あと、スポンサーの離反を避けることを考えると、赤字を垂れ流していると見切られる可能性があるんですよね。なので、価値を提供し続ける必要があります。
単一のスポンサーに依存していると、そのスポンサーに見限られた時に絶滅の危機みたいなこと（が起こること）があるわけですね（笑）。
可能であればプロダクトの重要な部分とか、大切な部分とかをオープンソースに切り出して死なないようにするのも1つの戦略だと思うし、あるいは複数の場所のアライアンスみたいなかたちでやっていくというのも手だと思います。いろいろあると思いますね。
いずれにしても現状に甘んじないということは、けっこう大事なことだなと思います。変化する状況を捉えてそれに対応していかないといけないというのもそうだし、でもだからといって話題性のためだけに機能をどんどん追加していって誰もついてこられないようになるっていうのも駄目だし。要はバランスですね。
あともう1つ大事なのは、既存のユーザーに対して、特にAPIとか言語とかそういう感じのソフトウェア周りのものは、互換性を破壊すると大変なことが起きることが多いんです（笑）。Rubyもそれでだいぶ後悔したり苦労したことがあります。
進歩するためには変化し続けないといけないんですが、そのあたりのバランスが非常に強く求められると思います。
（スライドを示して）Gartnerというところが「新しい技術が来るとこんなふうになる」みたいなグラフを描いてくださいました。上がVisibility、どれだけその技術が話題になるかで、横軸が時間です。
最初にテクノロジーが始まって、すごく話題になる。それからちょっと落ちるという感じですね。
テクノロジーのハイプサイクル
これを時期にして分類すると、テクノロジーが登場した時は黎明期で、それがものすごく話題になった時には流行期です。だけど、流行期ではだいたい実体以上の期待をかけられることが多くて。そうすると、時間が経つと幻滅されることがけっこうあるわけですね。幻滅期。
幻滅した時には必要以上に評判が落ちるわけなんですが、実体に応じた評判を取り戻すのが回復期。回復した後、安定して人気があるというかたちで、もう1回グラフを見るとこんな感じになりますね。黎明期があって、流行期があって、幻滅して落ちて、回復して、安定するというグラフですね。
ほぼあらゆる技術は、このグラフを通るんですね。というか、中には例えば流行に乗れなくてそのまま落ちちゃったやつとか（笑）。あるいは、幻滅期で落ちきってしまって二度と這い上がれないやつとか。
途中でドロップアウトするやつも中にはあるんですけど、基本的に生き残る技術というのはこういうグラフを描くことが多いと言われています。こんな感じですね。
その時に自分がハイプサイクルのどこにいるかを自覚することができると、各段階で工夫することができると思うんですね。
例えば黎明期であれば、仲間が必要。あるいはコミュニティの中でリーダーになるようなユーザーが必要です。そういうコミュニティとコネクションを作ることが必要な時期になります。
Rubyの場合だと、インターネットに上げた時に何人かのアンテナの高い人がRubyに注目してくれて、その中にはRubyの本を書いてくれた人もいるし、Rubyを周りに紹介してくれた方もいるし、アプリケーションを作ってくれた方もいます。そういう人たちがいたからこそ、ほかの人たちがRubyを安心して使えるようになるということですね。
流行期の時には話題性と注目が集まっているので、そのタイミングでキラーアプリケーションみたいなものを見つけられるといいなと思います。あと、この流行期の時にある一定のボリュームの味方を集めることができたテクノロジーは幻滅期を生き延びることができるんですね。
話題だけでみんなが離れていってしまうと、幻滅期で誰も味方がいないので、そのままやる気がなくなって破滅してしまうみたいなケースがけっこうあるんですよ。だから、ここで味方を集めるのが大事だと思います。
幻滅期です。Rubyも2011年、2012年ぐらいから、Ruby on Railsの人気にちょっと陰りが出て幻滅期みたいなものを体験しています。この時は正直、すごくつらいんですよね。つらいんだけどここで諦めてしまうと試合終了なので、「諦めてはいけない」ということをすごく学ぶ時期です。
くじけず価値を継続的に提供していったり、あるいは技術革新によって状況が変化していくところに適合しつつ、Rubyを使い続ける。（そうすると）RubyならRubyで、自分のプロダクトを使い続けることの価値を提供の継続していく中で、みんなが誤解を解いて、そのテクノロジーに戻ってきてくれることが期待されるわけですね。
Rubyはたぶん今は安定期と言ってもいいんじゃないかなと思っているんですが、（その時には）継続的な情報公開、「Rubyはこんなことをしています。こういうふうな未来を持っています。こういうふうなことを考えて開発しています」みたいなことを提供していくことによって、実体に応じた人々を集めることができるんじゃないかなと思います。
2009年ぐらいの時、「猫も杓子もRuby on Rails」みたいなことを言っている時代よりは、現在の「Ruby on Railsもいいところがあるから、それが気に入った人は使ってください」というほうが、だいぶ健全だとは思いますね。
だからこそ、みなさんのプロダクトも、幻滅期はつらいかもしれませんが、それを乗り越えた後は安定して生き延びることができるんじゃないかなと思います。
最終的に言えるのは、生き延びることが非常に重要で、そのためにハイプサイクルのそれぞれの時期に応じてできることがいろいろあるというようなことが言いたかったことでした。
乗り越えるやり方は1通りではないが、Rubyの経験も役に立つ
今回は広く使われること、それから長く生き延びることを軸に、良いソフトウェアを作るいくつかの鍵、気をつけるべき点について話してきました。
みなさんが今作っている、あるいはこれから作るサービスなりプロダクトなりは、どういうものかに応じて微妙に変わってくるとは思うんですけれども、ただ、先ほどの（話に出てきた）キャズムのグラフとか、それからハイプサイクルのグラフは、いずれもほとんどのプロダクトが経験していることなので、おそらくはみなさんのプロダクトにも発生するんですね。
それを乗り越えるやり方は1通りではないかもしれないけれど、Rubyがやってきたことっていうのは、非常に役に立つ有効なことではないかなと思いました。
今日の発表は以上になります。駆け足でしたが、みなさんどうもありがとうございました。
