第5章要件とユーザーストーリー

本章では、スクラムプロジェクトにおける要件の扱い方と、ビジネス価値を表現するための一般的な形式である「ユーザーストーリー」について解説します。

5.1 概要

スクラムと順次的なプロジェクト（ウォーターフォールなど）では、要件へのアプローチがまったく異なります。

順次的なプロジェクト: 要件は事前の交渉の余地がない「契約」のように扱われ、初期段階で詳細に文書化されます。
スクラム: 誰かが開発を始めるのに必要な分だけ、ジャストインタイムで要件を明確にします。要件を完全に固めるのではなく、プロダクトバックログアイテム（PBI）としてビジネス価値を表現します。

5.2 対話する

要件は、構築する対象について共通理解を促進するための「コミュニケーション手段」です。

文書化された要件は重要ですが、見た目が立派な文書ほど誤解を生みやすく、質問を封じ込めてしまう傾向があります。
スクラムでは、文書を完璧にすることよりも、ステークホルダーと開発チーム間の「対話」を重視します。文書はあくまで対話を記録したスナップショットにすぎません。

5.3 改良し続ける

スクラムでは、すべての要件を初期段階で詳細化することはしません。

必要になったときに、ジャストインタイムで大きな要件を小さく詳細な要件の集まりへと分割します。これを段階的洗練（progressive refinement）と呼びます。

5.4 ユーザーストーリーとは何か

ユーザーストーリーは、ビジネスマンと技術者の両方が理解しやすいように作られた、ビジネス価値を表現する便利な形式です。Ron Jeffriesは、ユーザーストーリーを「3つのC」で説明しています。

1. カード（Card）

ユーザーストーリーは、伝統的にインデックスカードに書かれます。
一般的な形式は「（役割）として、（目的）を達成したい。なぜならば（理由・価値）だからだ」という形をとります。
カードは要件のすべてではなく、要件の意図を表す数行の文章であり、「詳細を議論するためのプレースホルダー（予約席）」です。

2. 対話（Conversation）

要件の詳細は、開発チームとプロダクトオーナー、ステークホルダー間の対話によって明らかになります。
これは一度きりのイベントではなく、継続的なやり取りです。対話を通じて要件の曖昧さを排除し、詳細を文書やUIスケッチとして書き留めます。

3. 確認（Confirmation）

ユーザーストーリーには、それが完了したかどうかを判定するための「満足条件（受け入れ条件）」が含まれます。
これはカードの裏面に書かれることが多く、期待される振る舞いを明示します。
受け入れ条件は、受け入れテスト駆動開発（ATDD）と呼ばれるアプローチの基礎となり、多くの場合、自動化された受け入れテストとして実装されます。

5.5 詳細化のレベル

ユーザーストーリーは、計画の期間に合わせて適切な大きさに分割されます。

エピック（Epic）: 数か月から複数リリースにまたがる、非常に大きく抽象度の高いストーリーです。大きすぎるためそのままではスプリントに入りません。
フィーチャー（Feature）: エピックを分割したもので、複数のスプリントにまたがる大きさのストーリーです。
スプリント可能なストーリー（Sprintable Story）: 1回のスプリント内で設計、構築、テストが完了できるサイズに分割されたストーリーです。
タスク（Task）: 開発チームがストーリーを実装するために分割する、技術的な作業単位です（通常1〜2人日）。ストーリーが「何を（What）」を定義するのに対し、タスクは「どうやって（How）」を定義します。
テーマ（Theme）: 共通点を持つユーザーストーリーの集まり（タグ付けのようなもの）を指します。

5.6 うまく書けたユーザーストーリーとINVEST

Bill Wakeは、ユーザーストーリーが書き手の意図に合うか、評価するために有用な基準として「INVEST」という原則を提案しました。これらを満たすことで、優れたユーザーストーリーになります。

I（Independent：独立している）: ユーザーストーリーは他のストーリーとできる限り独立しているべきです。相互依存性が高いと、見積りも優先順位付けも計画も複雑になってしまいます。
N（Negotiable：交渉できる）: ストーリーは前もって作成された要件定義書のような契約ではなく、詳細の交渉をするためのプレースホルダー（予約席）です。開発チームが詳細について交渉する余地を残すべきです。
V（Valuable：価値がある）: ストーリーは顧客や利用者（あるいはその両方）にとって価値があるものでなければなりません。ビジネスの価値をもたらさない純粋な技術的ストーリー（例：データベースの移行など）は、できる限りビジネス価値の観点に書き換えるべきです。
E（Estimatable：見積り可能）: 開発チームは、ストーリーの規模や労力、コストの目安になる見積りができなければなりません。規模が大きすぎる場合や、知識が不足している場合は見積りが難しくなります。
S（Small：適切な大きさ / ほどほどに小さく）: ストーリーは、1つのスプリント内で設計、構築、テストを完了できる小さなサイズ（スプリント可能なストーリー）に分割しなければなりません。
T（Testable：テスト可能）: ストーリーは、成功と失敗の2値で判断できるテストができなければなりません。満足条件（受け入れ条件）が明確で、テストをパスすれば「完了した」と確信できる必要があります。

5.7 非機能要件

パフォーマンスやセキュリティといった非機能要件は、システムレベルの制約として重要です。

プロダクトバックログに単独のストーリーとして書くこともありますが、通常は「完了の定義（Doneの定義）」に追加し、すべてのストーリーにおいてその制約を満たすように開発を進める形式が取られます。

5.8 知識獲得のためのストーリー

チームが見積りや開発を行うために必要な「知識」が不足している場合、その知識を獲得するための活動をストーリーとして扱います。

これらはプロトタイプ、概念実証（POC）、実験、またはスパイクと呼ばれます。
知識獲得のためのストーリーは、際限なく調査を続けるのを防ぐため、タイムボックス化（例：最大2日間など）して投資の上限を決める必要があります。

5.9 ストーリーの収集

要件を収集・作成するための効果的な手法として、以下の2つが紹介されています。

ユーザーストーリー記述ワークショップ

ビジネス価値について協調的にブレインストーミングを行うセッションです。
プロダクトオーナー、スクラムマスター、開発チーム、ステークホルダーが参加し、数日から数時間かけて行われます。
最初から完璧な要件定義を行うのではなく、エピックのような大きなストーリーから小さなストーリーまで、全体像を洗い出すことが目的です。

ストーリーマッピング

Jeff Pattonによって広められた、ユーザー中心志向の観点から要件を視覚化するテクニックです。
ストーリーを単純な一次元のリストではなく、ユーザーのワークフロー（時系列）を横軸に、優先順位や重要度を縦軸に配置した二次元のマッピングを行います。
これにより、「どの機能群を含めれば最初のリリースが成り立つか」といったリリース計画が視覚的にわかりやすくなります。

5.10 終わりに

スクラムにおける要件は、プレースホルダーとしてプロダクトバックログアイテムを作成し、後から対話を通じて詳細化するアプローチをとります。これらを「INVEST」の原則で評価し、未知の領域には「スパイク」を用い、要件の洗い出しには「ストーリーマッピング」などのワークショップを活用することで、価値の高いプロダクト開発が可能になります。

第5章 要件とユーザーストーリー