アジャイルモデルでは、顧客とテストの関わりが強くなる

アジャイルモデルでもっとも難しい部分はテストではないでしょうか。特にウォーターフォールモデルにおける総合テスト／受入テストは各手法のプラクティスでもあまり記述されていません。これは、テストという作業自体が開発モデルに関わらず共通することであるからだと思います。

アジャイルモデルでは、イテレーションごとにテストを行います。特に顧客が行う受入テストがイテレーションごとに行われることは、顧客が開発期間中ずっと関わることにつながります。顧客とテストの関わりが強くなることが、アジャイルモデルのテストにおける特徴であり、他の開発モデルとの大きな違いです。テストで発見した不具合や改善点は顧客から開発業者に伝えられ、次のイテレーションで対応することになります。アジャイルモデルのイテレーションは1〜2週間程度と短いことが多く、次のイテレーションで対応するためには即座に伝えることが必要となりますが、顧客と開発業者が離れている場合に問題が起こることがあります。ここでは、その対策を紹介します。

「BTSの利用とその共有」という開発ドキュメント

不具合や改善点の伝達は「障害管理票」といった名前で規定され、開発ドキュメントの1つとして認識されています。大きな開発では、昔からBTS（Bug Tracking System）という形でシステム化されており、発見者から対応者まで直接情報を伝えることができます。最近はオープンソースのものが普及してきており、比較的規模の小さいアジャイルモデルの開発においても積極的に利用すべきです。

しかし、BTSを構築しても開発業者内で閉じてしまい、顧客と共有されていないことが普通ではないでしょうか。このことは、他の開発モデルでは問題にならないのですが、アジャイルモデルでは好ましいことではありません。

BTSが共有されていない場合、不具合や改善点の伝達手段は口頭やメールになります。この方法は、発見者から対応者までに複数の人が挟まることが多く、遅延が発生したり、内容が誤って伝わったりということが発生します。他の開発モデルでも同様に発生する問題ですが、即時性が求められるアジャイルモデルでは影響が大きく、例えば、次のイテレーションで改善してほしかったものがされていない、といったことが起こってしまいます。

この問題を解決するには、BTSを共有するのがもっとも簡単です。しかし、ネットワークなどのインフラ環境が許さない場合が多く、現実的ではないようです。そこでBTSの利用方法にひと工夫します。その工夫とは「情報のインポート／エクスポートツールを作る」ことです（図3）。

BTSの情報の蓄積方法はそれほど難しい仕組みではなく、ファイルやデータベースで行っている場合が多いです。インポート／エクスポートを行うツールを作るのはそれほど難しいことではありません。ツールを作り、顧客と開発側で情報を共有することで、リアルタイムとはいかないまでもある程度の即時性を確保した上で、情報を正確に伝達することが可能となります。アジャイルモデルを採用することが多い企業では他のプロジェクトに流用することも可能ですので、ぜひ試してみてください。

本連載はこれで終了です。「開発ドキュメント」というテーマで、筆者たちが現場での試行錯誤を通じて考えたことを、誌面の許す限りお伝えしてきました。開発ドキュメントは必ず作成するにも関わらず、参考になる情報が少ないのが現状です。本連載が現場で開発ドキュメントを作成しなければならない皆さんの一助になれば幸いです。 タイトルへ戻る