ビルドはどのような要件を満たすべきか：開発プロセス再入門（3）

　前回（「反復開発の“反復”とは何をどのように反復するのか」）は、ビルドのリリースが反復の単位であることを説明しました。今回は、ビルドがどのような要件を満たしているべきかを説明します。

ビルドが満たすべき要件

　ビルドは、以下の要件を満たしていなければなりません。

1. リリースされる範囲が明確であること
2. ビルド番号が付加されていること
3. リリースノートが添付されていること
4. インストーラが添付されていること
5. ゴールが設定されていること

　それぞれについて、説明します。

［1］ リリースされる範囲が明確であること

　ビルドには、いろいろな位置付けのものがあります。開発者は日々の開発作業のために、自身のマシンでソフトウェアをビルドしなければなりませんが、この開発者が自分だけにリリースするビルドをどう扱おうが、それは開発者の自由です。ビルドするたびに、これをいちいち丁寧にインストールしてからデバッグ、ということはしないでしょう。高度なデバッグ機能を持つ統合開発環境から開発中のソフトウェアを実行して、デバッグ作業を行うこともできます。また、デバッグ中のビルドには正しいビルド番号を付加することができません。このため、開発者が開発中のビルドをデバッグしているときに見つけた不具合は、正しく追跡できないため、この不具合を文書化する価値がないので、開発者はこれを黙って直してしまって問題ありません。

　つまり、リリースされないビルドが満たすべき要件は何もありません。あるとすれば、「リリースしてはいけない」ということだけです。

　この要件を、リリースされるビルドについても適用できるように拡張して、もう少し汎的にいえば、「すべてのビルドは、どの範囲にまでリリースされるのか明確に決められていなければならない」のです。決められたリリース範囲の外にビルドが漏れたりしないように、厳重に管理する必要があります。

　そして、ある範囲にリリースされるビルドは、さらに以下に説明する複数の要件を満たしていなければなりません。

［2］ ビルド番号が付加されていること

（2-1） ビルド番号とは

　ビルド番号は、ビルドに付ける通しの番号です。最初のビルドを1として、1つずつ増やしていきます。どこかにリリースされるビルドには、そこがどこであれ、すべてビルド番号が付加されていなければいけません。ビルド番号が付加されているとは、このソフトウェアのユーザー（QAチームにリリースされるビルドであれば、QA）が、いまどのビルドを使って（テストをして）いるのかを確認する手段が用意されている、ということです。

　このビルドに添付されたリリースノートにビルド番号が書いてあるだけでは、ビルド番号が付加されているとはいえません。最初のビルドからビルド番号をリソースという形でプログラム中に埋め込んでおき、これを確認する手段を用意しておくことを強くお勧めします。

　例えば、コマンドラインで動作するプログラムであれば、ビルド番号を表示する-versionオプションを用意しておくとか、Windowsアプリケーションならバージョン情報ダイアログ（aboutbox）を用意するといったことです。サーバサイドアプリケーションであれば、このビルド番号をクライアント側からでも確認する手段があるとなおよいでしょう。QAは必ずビルド番号を確認してからテストを実施するようにします。

（2-2） ビルド番号が意味するもの

　ビルド番号を付加するのは、各ビルドを一意に区別して、不具合を正しく追跡できるようにするためですが、ビルド番号の有用性はそれだけにはとどまりません。以前開発したことのあるドメインや規模のソフトウェアを再度開発するときは、以前のソフトウェアをリリースしたときと、おおよそ同じビルド番号で開発中のソフトウェアがリリース可能なものになることが予測できます。ソフトウェア開発のプロジェクトを多くこなすことで、例えば「この規模のソフトウェアならビルドを50回くらい出せば品質が安定してくるだろう」などと予測できるようになるということです。

　また、開発作業の進ちょくがすべて「ビルド番号」ではかれるのも便利です。「この不具合は次のビルド#5に入れるのは難しいから、ビルド#6で直すよ」とか、「このインターフェイスの変更はビルド#8でやってしまおう」「なんとしてもビルド#20を最終ビルドにしないといけないから、この不具合の修正はあきらめざるを得ないね」などという会話で、複数のチーム間でタイミングを合わせ、コミュニケーションを取ることができます。

　多くのウィンドウアプリケーションは、バージョン情報ダイアログを持ち、ここでソフトウェアのバージョンとビルド番号を確認できます。例えば、Microsoft Windowsのビルド番号は、エクスプローラのヘルプから確認できます（相当な回数、ビルドが行われていることが分かります）。最初のビルドから、豪華なバージョン情報ダイアログを用意するべき、というわけでは決してありませんが、最初のビルドから、ファイルのプロパティなどでそのビルド番号を確認できるようにしておくべきです。QA（もしくはユーザー）がビルド番号を確認できるようにしておくことは、不具合を追跡するために非常に重要なことです。

　一般に、ビルド番号が大きければ大きいほど、そのソフトウェアの規模が大きいか、もしくは品質が高いものとなります。開発中のソフトウェアのビルド番号が大台を超えるとそれだけでうれしくなったりしますから、ビルド番号はチームメンバーのモチベーション管理にも御利益があります。ビルド番号は最初のビルドからきちんと数えていきましょう。

　ただし、ソフトウェアによっては、ファイルの生成日時（タイムスタンプ）をビルド番号の代わりに用い、ビルド番号というのは特に付加しないということもあります。この場合、各ビルドを立てるごとにビルド番号を管理する（リソースに含まれるビルド番号をインクリメントするなどの）工数が不要になりますが、その代わりに前述したビルド番号のメリットは享受できなくなります。

　オープンソースのソフトウェアでは、weeklyでのゴールを設定するような機会が少なく、また、そもそもソースコードというビルド前の状態で配布され、さまざまなロケーションでビルドが行われたりするので、ビルド番号が管理されないことも多いようです（代わりにバージョン番号だけが管理されます）。

（2-3） ビルド番号とバージョン番号について

　通常、ソフトウェアにはビルド番号のほかにバージョン番号も付加します。バージョン番号も、ビルド番号と同じくソフトウェアの版を管理するための番号ですが、ビルド番号よりも大きな単位でインクリメントします。バージョン番号は、通常、ピリオドで区切られたメジャーバージョン番号とマイナーバージョン番号から構成されます。

　ビルド番号だけでビルドを一意に特定することができるとしたら、バージョン番号はどのように付けて、どのような意味を持たせればよいのでしょうか。それは、皆さんが好きに決めればいいことです。ぞんざいに決めてしまっても、なんの問題もありません。そろそろ完成度が高くなってきたから1.0にしようかな、とか、アーキテクチャは大きく変わったけど見た目はほとんど変わってないから1.1にしとこうかな、とか、中身は変わってないけど見た目が大きく変わったから2.0にしとくか、とかそんなものです。バージョン番号は、製品のアーキテクチャの変遷にとらわれる必要はないので、マーケティング上の理由から決めることができます。

　Microsoft Windows の実行形式ファイルには、バージョンリソースとしてピリオドで区切られた4つの数値を持たせることができます（これはファイルのプロパティで確認できます）。この4つの数字は、一般に

といった意味を持ちます（持たせます）。ビルド番号は、バージョン情報の一部であると位置付けることができます。

　ところで、メジャーバージョンアップなどでバージョン番号をインクリメントしたり、メンテナンスなどのために製品のソースコードブランチがフォークしてしまったようなときに、ビルド番号を1にリセットすべきか否かは判断に困ることがあります。リセットしない方が通し番号としてのビルド番号の特徴を生かせます。が、同じソフトウェアの複数のバージョンをメンテナンスしていかなければならないときには、どのみちビルド番号だけでは製品を特定できなくなってしまいますから、バージョンごとにビルド番号を1に戻してしまった方が管理が楽になることもあります。

　バージョン／ビルド番号のポリシーは非常に重要ですので、ビルド計画を立てるときに一緒に決めておくとよいでしょう。

［3］ リリースノートが添付されていること

　リリースノートは、各ビルドのリリースに際して添付される文書です。この文書には、一般に以下のようなことが記述されます。QAは、これらの情報をインプットとしてテストを実施します。

　　◇ 製品名
　　◇ ビルド番号
　　◇ ソースコード管理ツールに打ったブランチ、タグ（ラベル）などの名前
　　◇ リリース場所（ファイルサーバ名やディレクトリの位置など）
　　◇ インストール手順
　　◇ 変更点、新機能
　　◇ 制限事項
　　◇ その他 （このビルドに含まれるモジュール、ファイルの一覧など）

　ソフトウェア開発に際しては、さまざまなドキュメントを書く機会がありますが、どんなドキュメントを書くときでも、そのドキュメントの対象読者と目的を意識して記述する必要があります。weekly buildに添付するリリースノートの対象読者はQAで、この目的はQAが効率よくテストを行い、品質の良い不具合報告書を記述できるようにすることです。

　QAは、新しいビルドが出るたびに、古いビルドをアンインストールして、新しいビルドをインストール（デプロイ）し直さなければなりません。また、どこをテストすべきで、どこをテストすべきでないかを知っておかなければ、テストの作業に着手できません。リリースノートは、QAの作業が滞りなく行えるようにするためのインプットを提供する文書であることが、お分かりいただけると思います。

［4］ インストーラが添付されていること

　ビルドは可能な限り、エンドユーザーに出荷するのと同じ状態にまでキッティングされていなければなりません。顧客にリリースされないビルドであっても、顧客にリリースするのと同様の体裁を整えるべきです。というのは、ユーザーが正しくソフトウェアをインストール（デプロイ）できるかどうかも、QAによるテストの対象とすべきだからです。そうでなければ、ウォーターフォールモデルでいうところの「結合」が、正しく行われているとはいえません。また、正しい手順でインストールされたソフトウェアをテストするのでなければ、品質の悪い不具合報告書が記述されてしまうことにもなります（キッティングというのは箱詰めするという意味ですが、ここではビルドした実行可能なソフトウェアの体裁についてのみ論じており、ユーザーマニュアルなども一緒に用意すべきという意味ではありません）。

　なるべく早い時期のビルドから、インストーラもしくはインストール手順書を準備するようにしましょう。また、反復を繰り返すたびに、各ビルドのインストールの手順が異なってくるでしょうから、リリースノートには常に最新の正しいインストール手順書を添付するようにしましょう。早い時期にソフトウェアを配置する手順を確立することによって、ウォーターフォール型開発における「統合テストの悪夢」から逃れることができるようになります。

［5］ ゴールが設定されていること

　各ビルドには、それぞれ達成すべきゴールが設定されていなければなりません。どこまでの機能を実現するか、ということが決められていなければ、QAは何をテストすればいいのか分かりません。この問題に関しては、上に挙げた4つの要件とは少々側面が異なりますので、詳細は次回に説明したいと思います。

　次回は、反復の計画について説明します。お楽しみに。