ソフトウェアのバージョンアップというのは、直接的な影響を受けるユーザーにとっても特別なイベントですが、開発する側から見ればたぶんもっと感慨深い、重大なイベントです。

長い時間をかけて開発した我が子のような新バージョン。その出来栄えに自信があればある程、社外には派手なイベントを打ってその変化をアピールし、社内では喜びの祝宴を盛大に開いて製品の旅立ちを祝ってやりたいものです。しかし最近はそんなバージョンアップの「イベント性」がだんだん薄れつつある、という事を感じるようになりました。

Firefox logo / Titanas

21日にリリースされたFirefox5のキャッチコピーは「ここが、新たなる出発点。」何をもって「新たなる出発」と言っているのかと言えばそのバージョンアップサイクルが「新た」であることはみなさん承知のことと思います。

Firefoxは6週間ごとに最新版に 拡張の互換性は？

上記の記事にあるように、今後Firefoxのリリースは6週間毎に行われます。結果として年末頃にはバージョンは「9」になる。これを聞いて怪訝に思う方もいれば、最近のトレンドから見て当たり前に思う人もいるでしょう。僕はこのニュースを見ながらFirefoxが行なってきた過去のリリースイベントを思い出していました。

覚えていらっしゃる方も多いと思いますが、Firefox3リリースの時は「Firefoxの灯」としてダウンロードの度に地図に灯りが灯るイベントが行われ、Firefox4の時はFirefox関連ツイートが動植物を生み出す森 「Virtual Park ―トゥムクマケ―」 が開設されるなど、Firefoxのバージョンアップには派手でセンスのある大イベントがつきものです。

VirtualPark ―トゥムクマケ―

対して、Google Chromeはかなり前からイベント方式とは正反対のバージョンアップポリシーをとっています。つまり、バージョンアップが行われた事を可能な限り意識させない方式です。

人は頻繁に変わるものを意識しなくなるもの。今回のFirefoxの方針転換はGoogleと同じく、バージョンの「数字」が持つ意味を事実上無くしてしまうものとも言えるでしょう。

あれ程の規模の、素晴らしいイベントを実施していたMozillaが、今回のリリースでは正反対の方向性を打ち出したという事。それは短期間のリリースサイクルが、派手なバージョンアップイベントよりも多くのメリットがある事が明らかになった、という事を示しています。それではそのメリットとは一体なんなのでしょうか？ソフトウェアベンダー側の視点から考えてみると、次のような事が言えると思います。

ソフトウェアベンダーは、ユーザーの使っているバージョンを可能な限り統一したいと思っています。バージョンがバラバラだと、過去のバージョンをいつまでもサポートする必要が出てくるため、本来は必要のない作業にエネルギーを取られ続けることになるのです。

バージョンアップ毎の差を大きくすると、使い勝手の変化を恐れてバージョンアップを見送る人が出てくるものですが、気づかない程の変化を徐々に与えていく事で、ユーザーに意識させる事無くバージョンを最新版にする事ができます。

バージョンアップの間隔が長いと、自然にユーザーとの約束が発生するようになります。

ユーザーからしてみればバージョンアップ間隔が長いと「この機能、次のバージョンアップに無かったらいつまで待たされんの？」という不安が湧いてくるものです。

そのような不安を解消するため、ユーザーの要望を可能な限り取り入れた「次バージョンに必ず入れる機能リスト」が作成されるわけですが、あれは入ってないのかとか、これは必須だとかいろいろな声を拾っていくうちにリストはどんどん膨らんでゆき、結局は更なるリリースの遅れにつながるというジレンマを生み出します。

転じてバージョンアップの間隔が短いと、ユーザーの不安は格段に少なくなるため、このような約束をする必要は薄れます。

次のリリースに入れるリストがなければ、ベンダーは自分達のペースで機能実装を進められます。不具合が出やすい改修には時間を掛ける事ができるようになり品質UP、逆に人気があって不具合の出にくい機能は、他の機能に足を引っ張られる事無く、先行してリリースが可能になるのです。

Firefoxのイベントはいつもなかなか凝っていて素敵なものばかりでしたが、一度凝ったイベントをしてしまうと次からのイベントに手を抜けなくなります。下手に手を抜くと「今回のイベントは気合が入ってないな」「製品にも気合が入っていないのかな」と思われてしまうかも知れませんし、イベントに手間を取られ過ぎることで、製品リリースそのものに影響が出る可能性も無いとは言えません。

本来的にはソフトウェアのリリースサイクルは、製品の開発状況に直結しているべきであり、他の要因に左右される事はあまり望ましくありません。

このように、いろいろとソフトウェアベンダーにとってメリットのある「リリースサイクルの高速化」ですが、企業向けソフトウェアではその限りではありません。

オンプレミスのサーバソフトの場合はオンラインでパッチを取得できる環境にあるものばかりではなく、バッチを適用することはそう簡単ではありませんし、リレーショナルデータベースを利用するサーバー製品であれば、DB構造に変化があるような修正を、簡単には適用できません。

また、FirefoxもChromeも、巨大なベータテスターのコミュニティがあるからこそ非安定版の検証が半自動的に行われ、品質の高いリリースが可能となりますが、企業向けのソフトウェアではこれ程のベータテスターのコミュニティを持っている所は少いですし、実際の運用環境に非安定版を導入する管理者がいるはずもありません。

このような関係から、企業向け（BtoB向け）で、オンプレミスのソフトウェアに、このリリースサイクルの高速化がやってくるのはまだまだ先になると思われます。

それでも、この大きな流れは止められないでしょう。企業向けのオンプレミスの製品であっても、少しつづ前進しリリースサイクルの高速化を実現するベンダーは出てくるでしょうし、パッチ適用の難しい環境に対して、効率的にパッチを提供するための枠組みを提供するメーカーも現れるかも知れません。

10年くらい経って見返してみると、企業向け製品でもバージョンアップイベントは珍しいものになっている。などということも、移り変わりの早いこの世界ではあり得ない事ではないのでしょう。