アジャイル開発におけるテストスケジュールへのリスク

1.アジャイル開発とは

まず初めに、アジャイル開発の特徴について、ウォーターフォール開発と比較しながらご説明します。

ⅰ.期間が短い
システム/ソフトウェア単位であるウォーターフォール開発に対し、よりコンパクトに、機能単位で開発・テストのサイクルを回すため、テスト期間が短いという特徴があります。

ⅱ.柔軟性がある
ウォーターフォール開発は、原則として工程を遡らず一つずつ順番に工程を進めますが、アジャイル開発は、開発とテストがほぼ同時期に行われます。同時並行で互いにやり取りしながら工程を進められるため、仕様変更や不具合対応への柔軟性が高いという特徴があります。ただし、変更が増え、先のスケジュールが読みづらいともいえます。

ⅲ.テストメンバーが上流工程から参加できる
ウォーターフォール開発はテストの段階になってからテストメンバーが参加するため、仕様の検討等の上流工程に触れる機会が限られます。対してアジャイル開発は、テストメンバー全員が比較的上流の工程でプロジェクトに参加できるため、開発メンバーとテストメンバー全体で仕様検討ができる場合があります。より少ない機能を集中的に検討できることに加えて、開発メンバー・テストメンバーの多角的な目線から漏れを防ぐことが可能です。

2.テストスケジュールへのリスク

アジャイル開発の特徴を紹介しましたが、その特徴ゆえにテストスケジュールに影響するリスクが発生します。
以下に、リスクとその原因の例を挙げていきます。

①仕様書不備

絶対的な開発期間が短いため、仕様書の整備が追いつかないことがあります。不完全な仕様書が不具合判断に使われると、仕様検討漏れ、単純な誤記等が原因となる不具合報告が増加します。また、このような、仕様書不備による不具合報告にリソースを割きすぎると、クラッシュ等の重大な不具合を見落とすリスクも高まります。

②仕様変更

柔軟な開発方法ゆえに、イテレーション内での仕様変更が起こりやすく、スケジュールの遅延が起こるリスクが高まります。テスト中の機能内の仕様変更にとどまらず、機能の消滅（次回への見送り含む）や、逆に新機能が追加されることも考えられます。アジャイル開発は機能単位でイテレーションを構成するため、機能の増減がスケジュールに大きく影響します。

③開発メンバーのリソース分担

開発メンバーとしては、開発と不具合修正のタスクが並行しているため、リソース分担をする必要があります。リソース分担が適切でない場合、どちらかが手薄になり、スケジュール遅延のリスクが高まります。

④単体テストの未実施化

開発の段階で動作確認（単体テスト）が不完全、または行われなかった場合、テストの段階で機能全体の不具合が見つかり、テストメンバーの業務が止まるリスクがあります。
たとえば、「機能開始しようとしただけでクラッシュやフリーズする」、「そもそも機能追加が一切反映されていなかった」等の場合がこれにあたります。

⑤過去のテストケース流用

テスト自動化の一環として、前のイテレーションで使用したテストケース（リグレッションテスト等）を流用する場合、最新の仕様向けに更新しておく必要があります。しかし、更新が不十分である場合、都度読み替えてテスト実行することになります。特に、参加したばかりのメンバーがテストの読み替えに直面した場合、テスト実行に迷ってしまい、Q&Aの工数増加に繋がるでしょう。

3.まとめ

アジャイル開発は、イテレーションで行うタスクを絞っておくことが特に重要です。追加する機能や修正する不具合などを取捨選択しないと、デグレード等が発生し、スケジュールのバッファ（リカバリの余地）を食い潰しかねません。どこまでをテスト対象とするか、ある程度細かい粒度で取り決めておく必要があります。
また、開発メンバーとテストメンバーが協力しプロジェクトを完了できるよう、「過去のやり取りをナレッジとして共有する環境づくり」、「ルールづくり」、「コミュニケーションの取りやすい関係づくり」をすることが大切と考えます。

業務が追い詰められた時、本記事のリスクが当てはまるかもしれません。ふと思い出した時に振り返り、プロジェクトを見つめる機会にしていただけたら幸いです。