Firefox 3.0.6のリリース予定日は、米国時間で2009年2月3日だ。3.0.5のリリースが2008年12月16日だったので、7週間空くことになる。
Firefox 3.0.3がリリースされた後、セキュリティ・アップデートの開発プロセスが変更されたことは、あまり知られていない。2008年10月半ばのことだ。この変更により、修正の投入を認める期間を短くする一方、品質チェックにかける期間は長くとるようになった。また、全体としての開発期間も短くする予定だったが、こちらは平均6週間以上かかっているので、さほど変わっていない。
変更のきっかけは、Firefox 3.0.2の失敗だ。品質チェック（QA）中に、ある修正が引き起こした別のバグ（リグレッションという）が発見され、リリース予定日を1週間繰り下げることになったうえ、アップデートによってパスワードが使えなくなってしまうという致命的なバグが出てしまった。日本語その他のUnicodeを利用する言語（ロケール）だけでのこととはいえ、一時はMozillaに不具合の報告が殺到した。幸いパスワード自体は消失しておらず、わずか3日で3.0.3が緊急リリースされたため、目立った後遺症が残ったわけではなかったものの、主要開発者たちにとっては苦い経験となった。
いかにしてアップデートの品質を向上させることができるか。彼らが考えた末に出した結論は、従来の開発プロセスに三点の変更を加えることだった。具体的には、１．修正を受け付ける基準を厳しくすること、２．一度のリリースで修正する個所を少なくしてリリースの頻度を上げること、３．QAに十分な時間をとることである。
修正を受け付ける基準を厳格にし、リスクを大幅に緩和
Mozillaでは修正コードのことをパッチと呼ぶが、セキュリティ・アップデートの開発プロセスにおいて、パッチを受け付ける基準をこれまでよりもはるかに厳しくすることにした。すなわち、セキュリティ問題の修正、Top 20に入るクラッシュ原因の修正、そして前のバージョンアップのせいで生じたバグの修正しか許さない。しかも、開発者はパッチの投入（チェックインという）前に自分でテストを行うことが義務づけられた。これらの例外は、開発責任者らの承認があってはじめて認めるものとした。
修正個所を減らしてより頻繁にリリース
リリースの期間が空くと、パッチ投入の機会が増えるだけでなく、開発者の心理としては、「今回を逃すと次はまた当分先になるから、何としても間に合わせよう」ということになりがちだ。その結果、1回のリリースにたくさんのパッチが詰め込まれ、リグレッションなどの問題が起きる。あるいは、内部のテストをパスできず、再度の修正が必要になってその分の時間ロスが生じ、加えて新たにリリース候補となるプログラムを作成する（ビルドという）手間もかかってしまう。
そればかりか、コードフリーズ（パッチ投入期間の終了）の直前になると駆け込みのチェックインが増える傾向にあり、QA担当者に負担をかけていた。彼らはそれまでの修正状況を見ながらテストのスケジュールを立てているので、テストを始める直前になってたくさんのパッチが投入されると予定が狂ってしまう。
そこで、リリース期間の短縮化である。これまで6〜8週間のサイクルだったものを、4〜5週間のサイクルにすることで、1回のアップデートに投入されるパッチの量を減らすことにした。
QAの長期化
これは、リリースサイクルの中でその構造を変えるものだ。たとえば、開発版であるFirefox 3.1では、リリース予定日を決めたら、できるだけコードフリーズ日を後のほうに置いて、パッチを受け付ける。QAにかかる期間を短縮することで対応し、開発を前進させる。だが、セキュリティ・アップデートは新機能を追加する場ではなく、プログラムの安定性が何よりも重要だ。そこで、サイクルの中でパッチを受け付ける期間を短縮し、QA担当者たちが修正内容とテストプランを検証・分析する期間を長くとることにした。
ここで想定されているサイクルは、次のようなものだ。
- 第1週：パッチの投入
- 第2週：バグ検証の開始
- 第3週：検証終了 / ビルド開始
- 第4週：Beta版作成 + QA終了
結局、プラン上は、開発者がパッチを投入できる期間はぐっと短くなり、その基準も厳格化され、他方で余裕をもって品質チェックを行えるようになったわけである。
実際のところはどうだろう（リリース予定表参照）。米国時間を基準にすると、Firefox 3.0.3のリリースが2008年9月26日で、3.0.4は11月12日だったから、7週間かかっている。QA開始が10月29日で、ビルド開始は28日だから、これは明らかに新プランから外れた進行だ。
これに対し、Firefox 3.0.5のリリースは12月16日であり、5週間弱でアップデートが提供されている。しかも、QA開始が11月18日で、ビルド開始が12月1日という、かなり理想に近いスケジュール進行だ。
次のFirefox 3.0.6がリリースまでに7週間かかるのでは、元の木阿弥のようでもある。しかし、クリスマス休暇や新年といった、開発が停滞する期間を挟んでいることは考慮されていいだろう。停滞を2週間弱とみれば、新プランに無理があるというわけでもなさそうだ。QA開始は2009年1月7日の予定で、1月19日にビルドが開始された後、20日からより厳密な品質チェックが実施されるという。新プランはほぼ定着したと評価してよいと思う。
