MozillaとGoogleのブラウザのリリースサイクルの短縮化について思うこと
MozillaとGoogleのブラウザのリリースサイクルの短縮化について、いくつか思うことを。
ブラウザのリリースサイクルより前に、Linuxの世界では、FedoraとUbuntuの両ディストリビューションのリリースサイクルは約半年である。OSなのにリリースサイクルが半年というのは、かなりのハイペースだ。Fedoraのリリースまでのロードマップはこのようになってる。Releases/16/Schedule - FedoraProject
- 機能FIXに約2ヶ月
- 機能実装に約2ヶ月
- テスト&BUGFIXに約2ヶ月
このペースでリリースすると大きな機能追加もできなさそうだが、実際には、GNOME3のリリースだったり、仮想化システムの大幅なアップデートだったり大きなシステム追加ができている。
MozillaもGoogleのブラウザも6週間というリリースサイクルの中で、機能追加、機能改善、バグ修正などかなりのコード追加・修正を行っている。
これを可能にするのは、やはりテストのオートメーション化であろう。人がテストを行うのは間違いもあるし、何しろ時間がかかる。マウスでポチポチしたり、テストデータを作成したり。そこで、機械にテストさせるテストの自動化に行き着くのだが、実際の現場として、テストの自動化は"言うは易し、行うは難し"であると思う。テストありきで開発を行うテスト駆動開発が難しいのは、色々要因がある。
- スキルがある一定であること
- 機能修正や追加の仕様がある程度固まっていること
- プロジェクトがテスト駆動開発で開始されていること
1.はテストが書きやすいようにソースコードを書く必要がある。なぜならソースコードよりテストコードの方が規模がふくれあがってしまい、その後の修正等に支障がでてくる。そのようにテストを意識したソースコードを書くことができるスキルがある人がいなくてはならない。
2.は、テスト駆動開発では、テストコードとソースコードを一緒に書き、多くの場合テストコードが仕様書となる。つまり、仕様がある程度固まっていないのに両方のコードを書き始めるとオーバーヘッドが高くなってしまう。
3.は、これは意識の問題で、すでにあるプロダクトの修正を行う時に、テストコードがないとあまりテストを書く気が起こらない。意識が高い人は書くと思うけど。
MozillaもGoogleもFedoraもUbuntuもリリースサイクルを短くできるのは少なくとも上に挙げた3点が当たり前のようにできているからだろう。つまるところ、短期間に案件を数こなすには、人の数を増やすのではなくテストの自動化をするのが正解なのではないかと思う。まぁ会社内で、これを実証するのは骨の折れることだなと考えるだけで憂鬱になる。
