ビルドの位置付けとリリースの順序：開発プロセス再入門（6）（1/3 ページ）

[津田義史（豆蔵），＠IT]

　反復を計画するということはビルドのリリース計画を立てることです。ビルドはなるべく早い段階から定期的にリリースすることが重要です（論文「伽藍とバザール」にある、「はやめのリリース、しょっちゅうリリース」ですね）。定期的にリリースしてテストを行い、発見した不具合の統計情報を収集することで、現在のビルドがどれだけ安定してきたか、品質がどの程度向上したのかを測ることができます。不具合の数が収束してくれば、ユーザーに対してそのソフトウェアをリリース可能な時期が近づいてきたと判断できます。開発のフェイズによって、リリースすべきビルドの位置付けも異なります。RUPには、方向付け（Inception）、推敲（Elaboration）、作成（Construction）、移行（Transition）という4つのフェイズがありますが、要するに開発の段階が進むと、そんな感じでビルドの位置付けが変化していくわけです。各ビルドでは着目すべき側面（aspect）が異なりますし、求められる品質も違います。最初のビルドに、最終ビルドと同じ品質を求めても仕方がありません。同じビルドが、複数の側面を持ち得ることに注意してください。ビルドをリリースするときは、それがどのように位置付けられるものなのか、意識しておくべきです。

　今回は、どのような位置付けのビルドをリリースしていくべきかを順に紹介します。

ビルドの位置付け
first build	最初のビルド
weekly build	毎週のビルド
daily build	毎日のビルド
private build	ビルド番号が管理されないビルド
milestone build	より大きな反復の単位においてリリースするビルド
latest build	最新のビルド
stable build	安定したビルド
candidate build	候補ビルド
freeze build	ある側面を凍結したビルド
release build	エンドユーザーにリリースするビルド

first build

　ソフトウェア開発プロジェクトにおいて初めてリリースされる最初のビルド、ビルド番号が1の記念すべきビルドです。このビルドでは主に製品のfeasibility（実現可能性）の調査と検証をゴールとして設定することが多くなります。見てくれが悪かろうが、多少不安定だろうが、あまり気にしません。重要なのは、曲がりなりにもきちんとビルドされていて、取りあえず動作することです。もちろん、first buildの位置付けが必ずそうなるというわけではありません。場合によっては、ユーザビリティに注目して最初のビルドを開発し、これを早い時期に顧客にリリースすることもあります。この手法をプロトタイピングということがあります。

　プロトタイピングを目的としたビルドではハリボテを作成することが多いため、これがたとえ最初のビルドであったとしても、先に説明した位置付けとはまったく異なるゴールを設定して開発し、ビルドすることになります。また、プロトタイプのソースコードは次のビルドのインプットとしては使わないこともよくあります。もちろん、すでに技術的なノウハウがあるドメインのアプリケーションを開発する場合にも、最初のビルドの位置付けは異なってくるでしょう。また、テストケースを記述するためのインプットの1つとして、この最初のビルドを加えることになるかもしれません。が、どんなソフトウェア開発プロジェクトにおいても最初のビルドが以後の開発を方向付ける重要なビルドになることは変わりません。

　筆者の経験では、開発期間がおよそ1年程度のプロジェクトでは、最初のビルドをリリースできるのは大抵、開発が始まってから2カ月後くらいになることが多いと思います。また、開発期間がおよそ2カ月程度のプロジェクトであれば、最初のビルドをリリースするのは開発が始まってから2週間後くらいになるでしょう。

　このビルドからインストーラを用意するのは困難な場合が多いですが、ユーザーがビルド番号を確認する手段はこのビルドから実装しておくことを強くお勧めします。

weekly build

　ソフトウェアの規模にもよりますが、build#1をリリースしてから2〜4週間後にbuild#2を、さらにその1〜2週間後にbuild#3をリリースできるようになるでしょう。2〜4番目のビルドから、ビルドを1週間置きにQAにリリースし、実装された機能からテストしていきます。QAによるテストは開発と並行して進めます。この1週間置きに定期的にリリースするビルドをweekly buildといいます。また、このような反復型開発の手法自体を指して「weekly build」ということもあるようです。

　前回に述べたとおり、ビルドのリリースは（不定期にでなく）定期的に行うのが理想的です。なぜなら、

• 発生した不具合の数
• 修正した不具合の数
• 修正しようとしたが失敗した（QAリリース候補のテストで制限事項となった）不具合の数
• 未修正の不具合の数（累計）

などをビルドごとに計測することで、意味のある結果が得られやすいからです。定期的にリリースされるビルドにおいて、QAから報告される不具合の数は、ビルドの品質が安定してきたかどうかを示す重要な指標となります。

　ただし、ソフトウェアの開発時期や規模によっては適切なリリースの間隔が1週間ではないかもしれません。新しいビルドをリリースしたら、テストはすべて最初からやり直さなければならないため、ビルドを頻繁にリリースしてしまうと、QAは各ビルドをテストし切れなくなってしまいます。テストをすべて最初からやり直すのは大変にコストが掛かるので、実際にweekly buildでテストをするのは新しく実装された機能と、開発者から修正したと報告された不具合のみ、ということが多くなります。また、ビルドをリリースするには、ビルド作業自体の工数以外にも、各QAのマシンにおいてはアンインストール/インストール（デプロイ）し直す工数が必要になるので、必要以上に頻繁にビルドをリリースすることは避けなければいけません。

　しかし、可能な限り新しいビルドでテストをした方が、より有益な情報を開発者にフィードバックできます。開発中の（QAにリリースされていない）ビルドと、QAにリリース済みのビルドがあまりに異なっていては、QAによるテストの価値がずっと低くなってしまいます。この観点からは、ビルドは可能な限り頻繁にQAにリリースした方がよいのです。

　ここにトレードオフがあります。QAに定期的にリリースする最適な間隔を見つけましょう。多くのソフトウェア開発プロジェクトでは、このちょうどよい期間が1週間であることが多いので、インクリメンタルな開発を初めて行おうとする人は、まずweekly buildをリリースすることを計画してみてください。曜日と時間を決めて、定期的にリリースしましょう。開発期間が決まっていれば、weekly buildをリリースできる回数も決まってきますので、計画は立てやすいはずです。実現しなければならない機能を何番目のビルドで実装するのかを決め、一緒にテスト計画も立案しましょう。

　隔週ごとにリリースするビルドはbiweekly buildといいます。