第4章：ユーザーストーリー

更新日：2025年12月7日

本章では、アジャイル開発における要求記述手法であるユーザーストーリーを解説する。ユーザーストーリーは、ユーザー視点で機能を簡潔に記述する手法である。良いストーリーの条件（INVEST原則）、受け入れ基準の書き方、大きなストーリーの分割手法について学ぶ。

1. ユーザーストーリーの概要

ユーザーストーリーは、ソフトウェアの機能をユーザーの視点から簡潔に記述したものである。エクストリーム・プログラミング（XP）から生まれ、現在では多くのアジャイルフレームワークで採用されている[1]。

ユーザーストーリーの主な目的をTable 1に示す。

Table 1. ユーザーストーリーの目的

ユーザーストーリーの標準的なフォーマットを以下に示す。

ユーザーストーリーフォーマット
「〇〇として、△△したい。なぜなら□□だからだ。」
（As a [role], I want [feature], so that [benefit].）

このフォーマットには3つの要素が含まれる。

1.2.1 ロール（誰が）：その機能を使用するユーザーの種類を明示する。

1.2.2 機能（何を）：ユーザーが達成したい具体的な行動を記述する。

1.2.3 価値（なぜ）：その機能がもたらすビジネス価値や利益を説明する。

良いユーザーストーリーの条件としてINVEST原則が知られている[2]。Fig. 1にINVEST原則の概要を示す。

Table 2. INVEST原則の詳細

受け入れ基準（Acceptance Criteria）は、ユーザーストーリーの完了条件を具体的に記述したものである。プロダクトオーナーがインクリメントを受け入れる際の判断基準となる。

Table 3. 受け入れ基準の役割

受け入れ基準の記述形式として、Given-When-Then（GWT）形式が広く使用されている。

Given-When-Then形式
Given（前提条件）：〇〇という状態のとき
When（操作）：△△を行うと
Then（期待結果）：□□となる

大きすぎるストーリー（エピック）は、1スプリント内で完了できず、見積もりも困難になる。INVEST原則のSmall（小さい）を満たすため、適切なサイズに分割する必要がある。

ストーリー分割には複数のパターンが存在する。Fig. 2に主な分割パターンを示す。

Table 4. ストーリー分割パターン

Table 5. ユーザーストーリー活用のポイント

ポイント	説明
ユーザーの言葉を使う	技術用語ではなく、ユーザーが理解できる言葉で記述する
解決策を記述しない	「どうやって」ではなく「何を」「なぜ」を記述する
会話を重視する	ストーリーカードは詳細仕様書ではなく会話のきっかけ
受け入れ基準を明確に	曖昧な完了条件は後からトラブルの原因となる
適切なサイズを維持	大きすぎるストーリーは分割、小さすぎるものは統合

次章では、アジャイルにおける見積もりと計画立案の手法について解説する。

[1] M. Cohn, "User Stories Applied: For Agile Software Development," Addison-Wesley, 2004.

[2] B. Wake, "INVEST in Good Stories, and SMART Tasks," XP123, 2003.

免責事項
本コンテンツは2025年12月時点の情報に基づいて作成されている。ユーザーストーリーの記述方法や分割手法は、チームやプロジェクトの特性に応じて適切にカスタマイズされたい。