反復開発の“反復”とは何をどのように反復するのか：開発プロセス再入門（2）

» 2004年05月13日 12時00分 公開
[津田義史（豆蔵），＠IT]

反復の単位

　さて、さっそく今回から反復型開発について具体的な話を始めましょう。本連載では、XPやRUPが登場する以前の、トラディショナルな反復型開発を扱っていきます。反復型の開発プロセスが実際に何を反復するのかといえば、それはビルドのリリースを繰り返すのであって、ビルドが反復の一番小さな単位です。ソフトウェアのドメインや規模にもよりますが、この反復の期間は通常1週間、長くても2週間程度です。テストが自動化されているプロジェクトであれば、反復の期間が1日ということもあります。

　ビルドについては、Insider's computer Dictionary［ビルド （build）］に説明があるので、目を通しておいてください。なお、ソフトウェアに関する洋書に出てくる「build」という語は、「構築」と訳出されることが非常に多いようですが、そのほとんどは「ビルド」と訳されるべきものです。

ビルドのライフサイクル

　以下に、ビルドのライフサイクルを示します。これはビルドの状態遷移をUMLの状態遷移図で表したものです。

ALT 状態遷移図

　これは、ウォーターフォール型の開発モデルと対応します。ウォーターフォール型の開発モデルでは、システムを統合するビルドを最後に１度だけ行い（結合テストですね）*、この成果物を製品としてユーザーにリリースします。これに対して、反復型の開発モデルでは、ビルドを何度も繰り返してリリースします。ただし、必ずしもすべてのビルドを顧客にリリースするわけではありません。ウォーターフォール型の開発では、顧客へのリリースを前提としてビルドを作成するわけですが、反復型の開発においては、最終ビルド（とマイルストーンビルド）を除く開発中のビルドは社内のQAチームに対してだけリリースします。

* 実際には、ウォーターフォール型の開発でも、ビルドが一度で済むということはありえません。開発後期には、ビルドを何度も繰り返してリリースすることになります。

　1つの反復をどのような手順で行うか、この状態遷移図（図のこと）を見ながらもう少し詳しく説明しましょう。ここでは、1回の反復を1週間で行っているとします。各ビルドには、ユニークな通し番号をビルド番号として付加し、それぞれを識別できるようにします。

［開発中］

　担当者は開発者です。各開発者は、このビルドで達成しなければならないことや、このビルドを行う曜日（納期）を意識しながら、ソフトウェアを開発します。この作業のインプットとしては、前回のビルドのソースコード、種々の仕様書（要求仕様、設計仕様、画面仕様など）、前回のビルドまでで報告されている不具合などです。不具合を修正したら、この不具合報告書の状態を解決済みに変更します。不具合の追跡については、後で詳細に解説します。

［ビルド中］

　担当者はビルド担当者です。QAにビルドのリリースが予定されている曜日の1日くらい前には、ビルド担当者がビルド環境で候補ビルドをビルドします。ビルド担当者は、ビルドの前に開発者に対して「そろそろビルドするけど、大丈夫？」などと告知をして、開発者のお尻を叩かなければいけません。開発者全員の同意が得られたら、ビルド作業を行います。具体的なビルド手順については、今後機会があれば説明したいと思います。もしコンパイルエラーなどが出て、ビルドが通らなければ、開発者にこれを修正したコードのコミットを催促し、期日までにビルドがリリースできるようにします。候補ビルドができたら、その旨を開発者に告知します。

［候補ビルド］（開発者によるテスト中）

　担当者は開発者です。ビルド担当者からの告知を受けて、候補ビルドを自分の環境にインストールし、QAによるテストに耐える品質かどうか、半日ほどかけてテストします。自分が追加したはずの新しい機能が正しく実装されているか、修正したはずの不具合が正しく修正されているかを確認するということです。実装したはずの機能がうまく動作しなければ、制限事項としてリリースノートに追記しなければなりません。また、直したはずの不具合が修正できていなければ、［解決済み］とした不具合報告書の状態を［開始］などの状態に戻さなければいけません。

　QAによるテストが実施できる程度の品質であると判断できれば、この候補ビルドは当確です。これをQAチームにリリースしてもらうようにビルド担当者にお願いします。これを受けて、ビルド担当者はQAチームにリリースする作業（リリースノートの記述・とりまとめ、候補ビルドをQAチームに見える場所にコピー、QAチームにリリースの告知など）をします。

　テストの結果、予定していたテストが実施できなくなるような不具合が見つかれば、この候補ビルドは落選です。このビルドをQAチームにリリースするわけにはいきませんので、ビルドの状態を［開発中］に戻します。もちろん、予定どおりQAチームにビルドをリリースできるように急いでソースコードを修正し、次の候補ビルドをビルドする必要があります。

　ここまでの作業が終わるまでは、開発中のビルドや候補ビルドが誤ってQAチームにリリースされないように注意を払わなければなりません。QAチームに見える場所（ファイルサーバなど）に、リリース前のビルドを置いてはいけないということです。リリース前のビルドとは、不正なビルド番号が付いた不正なビルドのことです。こういったビルドがQAに漏れてしまうと、不具合が正しく追跡できなくなってしまいます。

［リリース済み］（QAによるテスト中）

　担当者はQAです。予定されていたテストケースを実施して、不具合を発見します。不具合を発見したら、不具合報告書に記述します。テストが自動化されていれば、この不具合を再現できるテストケース（テストスクリプト）を追加することもします。また、開発者によりこのビルドで解決されたと報告されている不具合が、受け入れ可能な形で解決されているかどうかを確認し、不具合報告書の状態を［確認済み］に変更します。この作業は、次のビルドがリリースされるまで続きます。つまり、QAによるこのビルドのテストと、開発者による次のビルドの開発は並行して行われます。

　万が一、リリースされたビルドにおいて、予定されていたテストの実施・続行が困難となるような不具合を発見してしまったら、このビルドの状態を［開発中］に差し戻すことを開発チームに要求することがあります。

　ただし、このようなことはものすごくまれだと考えてください。また、差し戻すことができるのは、ビルドがQAにリリースされてから数時間以内と考えてください。やむを得ずビルドを差し戻した場合、ビルド番号はそのままでもう一度ビルドを行って、リリースし直すのが普通です。というのも、ビルド番号をインクリメントしてしまうと、ビルド計画書や不具合報告書にあるビルド番号と、実際のビルドに付加されたビルド番号に不整合が生じてしまい、混乱を招いてしまうからです。

　ビルド番号とは、ビルドのライフサイクルを通じて不変のものと理解した方が分かりやすいかもしれません。ビルドを差し戻した場合には、確実にその旨をQAチームのメンバー全員に告知して、廃棄された不正なビルドでテストが続行されないようにしなければなりません。リリースされてからある程度の時間が経過し、このビルドについて、すでにたくさんの不具合報告書が記述されてしまったのなら、そのビルド（の番号）の状態を［開発中］という状態に差し戻すことは難しくなります。このような場合には、ビルド計画を変更して、次のビルド番号のビルド（翌週にリリースする予定だったビルド番号のビルド）をすぐにリリースすることを検討する必要があります。このような判断を迫られるときは、大変憂うつな気持ちになります。

　もし、QAからビルドの差し戻しを要求されたら、開発者は恥ずかしく思うべきです。

反復の階層

　ソフトウェア開発プロセスにおける、いわゆる「反復」には、いろいろな単位で繰り返されるものがあります。XPにおけるテストから実装・リファクタリングという数時間単位での反復、Scrumにおけるdaily Scrum meetingの反復、weekly（毎週）もしくはbiweekly（隔週）でのビルドのリリースという反復、ScrumのSPRINT reviewによる1カ月単位の反復、さらにRUPなどにおける数カ月単位の反復、などです。小さな反復の単位が、より大きな階層における反復を構成します。

　ここで示したビルドのライフサイクルは、チームで作業するうえでの最小の反復の単位と理解してください。これはあくまで開発中のビルドについてであって、顧客にリリースする候補となるビルドは、さらに候補ビルドという段階がいくつか増えます。候補ビルドという考え方はとても重要で、候補ビルドによるテストがパスすれば、そのビルドをもう少し広い範囲（例えば開発チームからQAチーム、QAチームから全社、全社から顧客など）、つまりより上の階層での反復という位置付けでリリースすることが可能になります。今回説明している候補ビルドとは、QAチームにリリースする候補ビルドを指しています。

　次回は、この反復の最小の単位である「ビルド」が満たすべき要件について説明をします。お楽しみに。

この記事に対するご意見をお寄せください

managemail@atmarkit.co.jp


著者紹介

▼津田義史

　5年間、某外資系ソフトウェアベンダでパッケージ製品の開発とグローバリゼーションに従事。その後、オブジェクト指向技術に疑問を感じ、2000年に豆蔵に入社。現在は、コンサルティングを通して、間違った開発プロジェクトをみることが多く、改めてソフトウェアというものが難しい仕事であることを実感する毎日。興味の対象は、C++のテンプレートを使った静的な多態性の活用だが、最近はC++のコードを書く機会そのものが少ない。


「開発プロセス再入門」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ