アジャイル開発では「作るべき成果物」がウォーターフォールと大きく異なります。
ISTQB Agile Tester Extension のシラバスでも、この違いは重要ポイントとして扱われています。
この記事では、動画で解説されていた内容を元に、アジャイル開発における成果物（Work Products）とは何か？
そして、どんな種類があるのか？どんな特徴があるのか？ を、わかりやすく整理します。
■ 1. アジャイルでは「動くソフトウェア」を重視する
アジャイル宣言には、次の有名な価値観があります。
包括的なドキュメントよりも、動くソフトウェアを重視する
つまり、
-
重厚なドキュメント作成
よりも
-
短いサイクルで動くものを提供して改善する
ことに価値があります。
● そのため、アジャイルの成果物は“軽量”
アジャイルでは次のような理由から、文書は最小限に抑えられます。
-
チーム内での密なコミュニケーション
-
プロダクトオーナー（顧客）との近い協働
-
短いスプリントで、迅速に価値を届ける必要がある
-
同じ内容を重複して文書化する時間がない
その代わりに、必要な情報を必要な形で素早く共有することが優先されます。
■ 2. アジャイルの成果物（Work Products）は3種類
アジャイルで扱う成果物は、次の3つに分類できます。
① ビジネス指向の成果物（Business-oriented Work Products）
ビジネス価値を表すための成果物。
主な例
-
ユーザーストーリー（User Story）
-
エピック（Epic）
-
受け入れ基準（Acceptance Criteria）
-
ユーザー向け文書（必要に応じて）
● ユーザーストーリーの構造
一般的なテンプレート：
As a（誰として）
I want（何をしたい）
So that（なぜ必要か）
例：
「ユーザーとして、ログインできるようにしたい。自分のアカウント情報にアクセスするために。」
● エピック → ユーザーストーリー → タスクの関係
-
エピック：大きな要求（例：ログイン機能全体）
-
ユーザーストーリー：小さく分割された要求（例：パスワード再設定）
-
タスク：更に細分化（例：UI実装、API接続、単体テストなど）
② 開発成果物（Development Work Products）
開発者が作成する技術的な成果物。
主な例
-
コード（ソースコード）
-
アルゴリズム、フローチャート、設計メモ
-
開発者によるユニットテスト（自動化されることが多い）
アジャイルでは**TDD（テスト駆動開発）**が使われることも多く、
「テストコード → 実装 → リファクタリング」の循環を高速に回します。
③ テスト成果物（Test Work Products）
アジャイルチームのテスターが作成し、利用する成果物。
主な例
-
テストストラテジ（軽量）
-
テスト計画（スプリント単位で必要最小限）
-
テストケース（手動／自動）
-
チェックリスト
-
リスクカタログ
-
ディフェクトレポート
-
テスト結果ログ
特にアジャイルでは
「自動テストの整備」
が非常に重要とされています。
■ 3. 成果物は“再利用できるもの”であることが重要
ISTQBでは、Work Product = 再利用価値のある成果物 と説明されています。
つまり、
-
スプリント中
-
継続的インテグレーション
-
次のスプリント
-
将来の機能開発
などで何度も使えるものが「成果物」とされます。
例：
-
自動化テスト → 継続的に利用可能
-
チェックリスト → 全スプリントで活用可能
-
ユーザーストーリー → スプリント計画やテスト設計に使われる
■ 4. アジャイルにおける成果物作成の特徴まとめ
-
ドキュメントは軽量・最小限
-
価値ある情報に絞って作成
-
再利用しやすい形でまとめる
-
チーム内の会話・コラボレーションを最優先
-
自動化テストは開発者・テスター双方によって整備される
■ 5. まとめ
アジャイル開発では、
“重厚な文書よりも、実際に動くソフトウェアとチームのコラボレーション”
が重視されます。
その中で、成果物（Work Products）は
-
ビジネス価値
-
開発の効率
-
品質保証
のために必要最小限でありながら再利用可能な形で作成されるものです。
ISTQB Agile Testerの試験ではこの考え方がよく問われるため、
分類や特徴をしっかり押さえておくことが重要です。
コメント