津田義史（豆蔵）

　実際にソフトウェア開発をマネージするときには、非常に多くの側面に注目しながら、プロジェクトの現在の状態を監視していかなくてはなりません。本連載では、特にビルドと不具合の追跡という側面に焦点を当て、なるべく具体的なプロセスを解説するように努めましたが、いかがだったでしょうか。今回は、ここまでに解説してきたプロセスを簡単にまとめ、皆さんが開発プロセスを改善するための具体的なアプローチを紹介します。

　第8回「ソフトウェアの不具合を追跡するには」では、不具合報告書のライフサイクルと状態、処理方法について説明しました。今回は、不具合報告書に記述すべき項目を紹介します。また、トリアージという考え方についても紹介します。

　不具合の追跡プロセスはソフトウェア開発の下流工程では非常に重要なもので、それはそのままソフトウェア開発の下流工程を規定するものといっても過言ではありません。不具合は、一般に開発者とQAの間で、不具合報告書（PR：Problem Report）をやり取りしながら管理することになります。今回は、不具合の状態と処理方法に注目し、不具合を追跡するプロセスについて説明します。

　 前回「反復計画のたて方」は、反復の計画について説明しました。今回は、ビルドとリリースの手順を具体的に説明し、ビルド担当者の責務を明らかにしてみましょう。

　前回（「ビルドはどのような要件を満たすべきか」）は、ビルドが満たすべき要件について説明しました。今回は、どのように反復を計画すべきかを説明します。

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