投稿日:

HEAD指向リリースマネジメントのスピード感

2012年2月29日、スペインのバルセロナで開催されたMWC2012（Mobile World Congress 2012）のイベントで「Windows 8 Consumer Preview」版のお披露目が行われた。このConsumer Previewという製品は、正式版の発売に先駆けて、一般消費者向けにプレビュー版として公開されたものだ。

本稿ではWindows 8の是非を論じたい…のではない。10年以上も前、まだ本コラムも始まったばかりで試行錯誤をしていたころ、「バージョン番号の謎」と題した記事を私が書いた。その記事ではバージョン番号の付け方、すなわち外形的なバージョンの決め方について言及しているが、本稿ではバージョン自体の決め方、すなわちバージョニング戦略あるいはリリース戦略について考えてみたい。

アルファ版、ベータ版、RC版…

さて冒頭で紹介したConsumer Preview、その前の版は開発者向けのDeveloper Previewという名前で開発途中のスナップショットが公開されていた。通常のソフトウェアでは、アルファ版、ベータ版、リリース候補（Release Candidate、RCと略される）版というような名称を用いて、都度、スナップショットが公開される。Windows 8に関していえば、Developer Previewがアルファ版に、今回のConsumer Previewがベータ版に相当するとのこと。今回のConsumer Previewは、かなり製品に近づいたものと考えてよい。

一般に、アルファ版のソフトウェアはまだ粗削りな製品であり、ときとしてバグが多すぎて常用には向かないこともある。ベータ版になれば一般消費者がいじってもまあ実用に耐えうるレベルとなる。そしてリリース候補版は製品として十分な品質が確保できたものとして扱われる。

ところで、ソフトウェアのリリースに際して、なぜこのような細々としたバージョン管理、あるいは少しずつご機嫌伺いをするような「そっと出し」戦略がとられるのだろうか。それは「ソフトウェアはあまりにも複雑だから」だ。ソフトウェアは生き物のようなところがあり、「これで完成です！」と胸を張って宣言できるケースは稀といわざるを得ない。正式版がリリースされてもバグフィックスが適宜行われることは周知のとおり。セキュリティパッチやバグフィクスパッチといった修正データが頻繁に公開され、ユーザーの手を煩わしつつも、ソフトウェアは変化してゆく。

しかし一方で「オトナの都合」というものもある。ソフトウェアの開発も経済活動の一環である以上、必ずどこかで、「正式版の公開です！」と宣言するタイミングが求められるはずである（必ずしも商用ソフトウェアだけでなく、OSSであってもそれは求められるはず）。いつまでも「いえ、まだ開発途中でして…」と引きずるわけにはいかないのだ。また適切なタイミングで「ナントカ版です！」とチラ見せしないと、世間様の関心を失いかねない。そこで、ある程度の形が整ったところで、「アルファ版です」「ベータ版です」とやるわけである。このような状況を加味して、ソフトウェアのリリース戦略は決められてゆく。

HEAD指向リリースマネジメント

ソフトウェア製品のバージョンアップに関しては、各世代について、アルファ版、ベータ版、RC版ないしはプレビュー版といった過程を繰り返していくやり方が主流であった。ところが、最近はこの方法をとらずに頻繁にバージョンアップを繰り返すことでなし崩し的に進化させていくやり方が幅をきかせ始めた。例えばFirefoxやChromeといった代表的なウェブブラウザは、短いリリースサイクルで頻繁なバージョンアップを繰り返している。

もちろんこれらの頻繁なリリースであっても、ある程度のベータ版は公開されている。しかしFirefoxではベータ版の公開に止まり、何回ものステップを踏んで熟成させていくやり方はとらなくなった。頻繁な自動更新を行うことで、「ユーザには常に最新の利用体験を提供する」というポリシーを実現しているのである。

この方式の究極は、常に開発最先端のバージョンを公開・提供してユーザに使ってもらうというリリース管理方法である。駿河台大学の八田講師はこれを「HEAD指向リリースマネジメント」と呼ぶ。HEADとは、コードのバージョン管理ツールにおいて「最新の」コードセットを指す用語である。

短いリリースサイクルによるバージョンアップの提供や、HEAD指向リリースマネジメントの実現は、オンラインによる自動アップデートでユーザの手を煩わせず最新版に更新できる機能があってこそ、受け入れられた方法であろう。この方法のよいところはユーザにとっては最新機能を常に利用できることであり、また開発者にとっても、各バージョンに枝分かれしたコード管理を行わなくて済むというメリットがある。

ウェブアプリ時代にマッチした戦略と留意点

ここまで読んで、慧眼な読者諸兄は「HEAD指向リリースの究極は、ウェブアプリケーション全てに当てはまる」ことに気がつかれたのではなかろうか。そう、エンドユーザに対するデリバリの不要なウェブアプリケーションは、常に最新版をエンドユーザに提供するアプローチを実現しているのだ。いつも利用しているサービスに、ある日、アクセスしたら新しい機能が追加されていたという経験をお持ちの方も多いはず。これこそがHEAD指向のリリースに見られる最大の特徴に他ならない。

このように、新しいモノ好きなギーク、もしくはイノベータ、アーリーアダプタと称される人々にとって、HEAD指向リリースは「わくわくする」方法だろう。しかし常に新しい機能を堪能できるということは、常に新しいバグに晒されるリスクもあるということには気をつけねばならない。さらに、大多数の保守的なユーザは常に新しい機能を欲しているわけではない、という点も注意が必要だ。

また企業内での利用のように、特定の情報システムと組み合わせて使う際も気をつけねばならない。頻繁なバージョンアップがシステムとの不整合を招く可能性があるからである。対策としては、特別な契約によりバージョンを固定して利用するという後ろ向きな解決策と、できるだけ標準的なプロトコルや機能の利用に留めることで頻繁なアップデートにも耐えうるシステムを構築する方法があろう。しかし前者は安易な解決だがいずれ破綻するモデルである。企業内のシステム管理者の皆様には、ぜひともHEAD指向リリースの効果と意義を十分に理解し、そのスピード感を享受しつつ新しいソフトウェアを有意義に活用し得るような、健全なシステム構築の検討をお願いしたいところである。

本文中のリンク・関連リンク：