リリース周期の短縮と固定化を耳にするようになった～ FirefoxのWebとIBM Innovate2011の講演から

ソフトウェアのリリース周期の短期化のトピックが前よりも増えているように思います。早くリリースすると先行者利益がある、状況の変化に強いという話は前から言われていましたが、技術的な仕組みも揃い現実のものになりつつあるのではないかと思っています。

同じような感触をもたれている方も少なくないと思います。私の場合はSalesforceの年3回のリリースを聞いたくらいから感じ始めました。ここでは詳しく書きませんので、デブサミでのSalesforceの方の講演のレポート（Enterprisezine）等をご参考にお使いください。

もう1つFirefoxのリリース周期の固定化と短縮化の話が印象に残っています。Publickeyの記事（publickey1.jpへ）で知ったのですが、Firefoxの「高速リリースサイクルに関するよくある質問」のページ（mozilla.jp）に、リリースする機能を決めてからリリース日を計画し、実行していくという旧来のやり方をやめて、6週間ごとに新バージョンをリリースすることを決めたと書いてあります。6週間ごとに自動でアップデートされるそうでダウンロード→インストールというユーザの手間は必要ないそうです。

Firefoxの同ページには「開発チャネル」に関する記述もあり、Nightly, Aurora, Beta, Releaseの4種類が紹介されています。それぞれのチャネルでは品質の位置づけがあります。たとえばNightlyは品質保証メンバのチェックは受けていない等です。

2011/6/5～9に米国オーランドで開催されたIBM Innovate2011（IBMの紹介Web）に招待いただきました。ここでも、リリース期間の短縮、再利用に焦点を当てた話を聞けました。

基調講演でGMのテクニカルフェローの方がGMでのソフトウェア開発の事例を紹介されていました。ボルトというハイブリッドカーのソフトウェア開発が紹介され、ハイブリッドカーに必要となるソフトウェアは非常に複雑なものであることを述べた上で、29ヶ月でという短期間でリリースできたことを強調していました。

ここでも、100万行以上のソースコード（モデル駆動による自動生成コードを含む）を6週間に1回のペースでリリース（ここでのリリースは出荷の意味ではなく、テストを終えた成果物という意味だと思います）しているという話が出ていた。

他にもプロダクトラインをはじめとする再利用を前提としたプロセス、より多くのステークホルダーに対応するためにインフラツールを利用していると言及がありました。

この基調講演に関する日本語の解説記事（@IT）があります。

本エントリの主題とは少しずれますが「ビジネスプロセスは様々な部門の人が関わって構成されている、ソフトウェアの開発も同様に様々な部門の人が関われるようになっておくべきだ」というのが印象に残りました。

固定化、短期化が適している分野とそうでない分野があると思います。ご自身のソフトウェア開発においてリリースの固定化、短期化はどのように変わるでしょうか。もしそのようなリリースの形態にメリットがある場合、リリースの固定化、短期化にはどのような仕組みが必要でしょうか？

Tweet