目次
- アジャイルの要件定義の考え方
- 全体像：要件の階層
- 上流で押さえるべきこと
- ユーザーストーリーの基本
- 受け入れ条件（Acceptance Criteria）
- ストーリーの見つけ方・広げ方
- ストーリーの分割
- 非機能要件の扱い
- Definition of Ready / Definition of Done
- プロダクトバックログの管理
- よくある失敗と対策
- ストーリーのテンプレート
- 参考になる体系・資料
1. アジャイルの要件定義の考え方
ウォーターフォールのように開発前に要件を確定させるのではなく、価値の高いものから少しずつ具体化し、作って確かめながら要件を育てていくのがアジャイルの要件定義。
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 確定のタイミング | 開発前に一括で確定 | 必要になる直前に詳細化（Just-in-Time） |
| 主な成果物 | 要件定義書 | プロダクトバックログ、ユーザーストーリー |
| 変化への姿勢 | 変更は管理・抑制する対象 | 変化は学びとして歓迎し、優先順位で吸収する |
| 合意の方法 | 文書の承認 | 継続的な対話と、動くソフトウェアでの確認 |
| 完成の判定 | 要件をすべて満たしたか | 成果（アウトカム）が出たか |
ただし「ドキュメントを書かない」わけではない。目的・制約・非機能要件など、後から変えにくいものは早めに言語化しておく。
2. 全体像：要件の階層
要件は粒度ごとに階層化して管理する。上位ほど早く・粗く、下位ほど遅く・細かく決める。
プロダクトビジョン … なぜこのプロダクトを作るのか
└ プロダクトゴール / OKR … 一定期間で達成したい成果
└ エピック … 大きな機能のまとまり（複数スプリントにまたがる）
└ ユーザーストーリー … 1スプリント内で完了できる価値の単位
└ 受け入れ条件 … ストーリーの完了を判定する具体的条件
└ タスク … 開発チームが実装のために分解した作業
3. 上流で押さえるべきこと
ストーリーを書き始める前に、以下をチームと関係者で共有する。
3.1 プロダクトビジョン
エレベーターピッチ形式で書くと、ブレない判断軸になる。
[対象顧客] の
[課題・ニーズ] を解決するための
[プロダクト名] は
[プロダクトのカテゴリ] である。
これは [主要な価値] を提供し、
[競合・代替手段] とは違って
[差別化ポイント] を備えている。
3.2 成果指標（アウトカム）
- 「何を作るか（アウトプット）」ではなく「何が変わるか（アウトカム）」で目標を置く
- 例：「申請機能をリリースする」ではなく「経費精算のリードタイムを平均5日から2日にする」
3.3 ペルソナ
- 主要な利用者像を2〜4人程度に絞って定義する
- 役割、目的、困りごと、利用環境、ITリテラシーなどを記載する
- ストーリーの「〜として」は、このペルソナやロールを使う
3.4 インセプションデッキ（推奨）
プロジェクト開始時に「我々はなぜここにいるのか」「やらないことリスト」「トレードオフスライダー」などをチームで作り、期待値をそろえる。
3.5 制約と非機能要件
セキュリティ、性能、法令、既存システム連携などはスプリントの途中で後付けしにくい。初期に洗い出して、後述の方法で管理する。
4. ユーザーストーリーの基本
4.1 フォーマット
<役割・ペルソナ> として、
<目的・得たい価値> のために、
<やりたいこと> がしたい。
例
経費申請者として、
立替金を早く受け取るために、
スマートフォンで領収書を撮影してその場で申請したい。
- 役割：誰のためのストーリーか（「ユーザー」ではなく具体的なロール）
- やりたいこと：利用者視点の行動（システムの内部処理ではない）
- 目的：最も重要。これがあると、より良い解決策の提案や優先度判断ができる
4.2 3つのC
ストーリーは仕様書ではなく、会話のきっかけ。
| C | 意味 |
|---|---|
| Card（カード） | 短い記述。詳細を書きすぎない |
| Conversation（会話） | PO・開発者・テスト担当・利用者の対話で詳細を詰める |
| Confirmation（確認） | 受け入れ条件で、完成を確認できるようにする |
4.3 INVEST：良いストーリーの条件
| 条件 | 意味 | チェックの問い |
|---|---|---|
| Independent（独立） | 他のストーリーに依存しない | 単独で着手・リリースできるか |
| Negotiable（交渉可能） | 実現方法は話し合いで決められる | 画面や実装方法まで固定していないか |
| Valuable（価値がある） | 利用者や顧客に価値がある | 「誰が嬉しいのか」を説明できるか |
| Estimable（見積もり可能） | チームが規模を見積もれる | 不明点が多すぎないか |
| Small（小さい） | 1スプリント内に完了できる | 数日〜1週間程度で終わるか |
| Testable（テスト可能） | 完了を判定できる | 受け入れ条件が書けるか |
5. 受け入れ条件（Acceptance Criteria）
5.1 書き方のポイント
- ストーリーごとに3〜7個程度を目安にする（多すぎるなら分割のサイン）
- 正常系だけでなく、エラー・境界値・権限のケースも書く
- 実装方法ではなく、観察できる振る舞いを書く
- スプリント計画の前までに、PO・開発者・テスト担当で合意しておく
5.2 Given / When / Then 形式（Gherkin）
シナリオ: 領収書を撮影して申請する
Given ログイン済みの申請者が申請画面を開いている
When 領収書を撮影し、金額・日付・用途を入力して申請する
Then 申請が「承認待ち」状態で登録される
And 上長に承認依頼の通知が送られる
シナリオ: 必須項目が未入力
Given ログイン済みの申請者が申請画面を開いている
When 金額を入力せずに申請する
Then 「金額を入力してください」と表示され、申請は登録されない
シナリオ: 上限額を超える申請
Given 申請者の1件あたりの申請上限が5万円に設定されている
When 60,000円で申請する
Then 上限超過のため事前承認が必要である旨が表示される
5.3 チェックリスト形式（簡易版）
シンプルなストーリーなら箇条書きでも良い。
- [ ] JPEG / PNG / PDF の領収書を添付できる
- [ ] 1ファイル10MBを超える場合はエラーを表示する
- [ ] 申請完了後、申請一覧に「承認待ち」で表示される
5.4 曖昧さを避ける
| 悪い例 | 良い例 |
|---|---|
| 検索が速いこと | 検索結果が2秒以内に表示されること |
| エラーを適切に表示する | 金額が未入力の場合「金額を入力してください」と入力欄の下に表示する |
| 管理者が編集できる | 「経理管理者」ロールのみが承認済み申請の金額を修正でき、修正履歴が残る |
6. ストーリーの見つけ方・広げ方
6.1 ユーザーストーリーマッピング
ストーリーを「利用者の行動の流れ」に沿って並べ、全体像と抜け漏れを可視化する手法。
[アクティビティ] 経費を記録する ─── 申請する ─── 承認する ─── 精算を受け取る
│ │ │ │
[ステップ] 領収書を撮る 内容を確認 申請を確認 入金を確認する
金額を入力 提出する 承認/差戻し
│ │ │ │
─────── リリース1（MVP）───────────────────────────────────────────
[ストーリー] 撮影して添付 申請を提出 承認する 入金通知を受け取る
─────── リリース2 ──────────────────────────────────────────────
OCRで金額読取 下書き保存 一括承認 精算履歴を見る
─────── リリース3 ──────────────────────────────────────────────
交通系ICから取込 定期申請 代理承認 会計システム連携
効果
- 横軸（流れ）で全体の抜け漏れが見える
- 縦軸（優先度）で切ると、端から端まで使える最小のリリース（MVP） が決められる
- 関係者全員で同じ絵を見ながら議論できる
6.2 ストーリーを引き出す問い
- この人は、このプロダクトを使う前後に何をしているか？
- 一番困っていること、一番時間がかかっていることは何か？
- うまくいかなかったとき（エラー、キャンセル、やり直し）はどうするか？
- 他にこの業務に関わる人（承認者、管理者、監査担当）は誰か？
- 初めて使うとき、慣れてきたとき、それぞれ何が必要か？
7. ストーリーの分割
大きすぎるストーリー（エピック）は、価値を保ったまま縦に切る。 「画面だけ」「APIだけ」「DBだけ」のように技術レイヤーで横に切ると、単独で価値を生まないので避ける。
分割パターン
| パターン | 例（元：経費を申請できる） |
|---|---|
| ワークフローの段階 | 申請する / 承認する / 差し戻す |
| 業務ルールのバリエーション | 交通費 / 宿泊費 / 接待交際費 |
| データのバリエーション | 円建て / 外貨建て |
| 入力方法 | 手入力 / 領収書撮影 / CSV取込 |
| ハッピーパスと例外 | 正常な申請 / 上限超過時の事前承認 |
| 操作（CRUD） | 申請を作成 / 編集 / 取消 |
| シンプル→高度 | 1件ずつ承認 / 一括承認 |
| 性能を後回しに | まず動く版 / 1万件でも2秒以内に改善 |
| スパイク（調査）を切り出す | OCRライブラリの精度検証（タイムボックス） |
分割の目安：チームのベロシティに対して、1ストーリーがスプリント容量の1/4〜1/6程度に収まる大きさ。
8. 非機能要件の扱い
ユーザーストーリーだけでは非機能要件が抜けやすい。次の3つを組み合わせて管理する。
8.1 制約として全ストーリーに適用（DoDに組み込む）
すべてのストーリーで満たすべきもの。
- 例：「主要画面は3秒以内に表示」「入力値はサーバー側でも検証」「WCAG 2.2 AA準拠」
8.2 個別ストーリーの受け入れ条件に含める
特定の機能だけに関わるもの。
- 例：「申請一覧は1万件あっても2秒以内に表示される」
8.3 独立したストーリーにする
利用者や運用者の視点で書けるもの。
運用担当者として、
障害の原因を素早く特定するために、
エラー発生時にリクエストIDつきのログを検索したい。
チェックの観点：可用性、性能、セキュリティ、運用・監視、データ移行、アクセシビリティ、法令・個人情報保護（詳細は IPA「非機能要求グレード」が参考になる）
9. Definition of Ready / Definition of Done
9.1 Definition of Ready（着手可能の定義）
スプリントに入れる前に満たしているべき条件。チームで合意して使う（厳しすぎると逆にフローが止まるので注意）。
- ストーリーの「役割・やりたいこと・目的」が書かれている
- 受け入れ条件があり、PO と開発者が合意している
- 見積もり済みで、1スプリントに収まる大きさである
- 依存関係・外部要因（他チーム、外部API等）が把握されている
- 必要に応じて画面モックやデータ例が用意されている
- 未解決の大きな疑問点がない
9.2 Definition of Done（完成の定義）
すべてのストーリーに共通する品質基準。
- 受け入れ条件をすべて満たしている
- コードレビューが完了している
- 自動テスト（単体・結合）が書かれ、すべて成功している
- 非機能の共通基準（性能・セキュリティ・アクセシビリティ）を満たしている
- 本番相当の環境にデプロイされている
- 必要なドキュメント（API仕様、運用手順など）が更新されている
- PO が受け入れを確認している
10. プロダクトバックログの管理
10.1 DEEP：良いバックログの条件
| 条件 | 意味 |
|---|---|
| Detailed appropriately | 上位は詳細に、下位は粗くてよい |
| Estimated | 見積もりがついている |
| Emergent | 学びに応じて常に追加・変更・削除される |
| Prioritized | 価値・リスク・コストに基づいて並んでいる |
10.2 優先順位付けの手法
- 価値 × コスト：価値が高くコストが低いものから
- MoSCoW：Must / Should / Could / Won’t
- WSJF：（事業価値 ＋ 時間的緊急性 ＋ リスク低減）÷ 規模
- リスク優先：技術的に不確実なものを早めに検証する
10.3 バックログリファインメント
- スプリント中に定期的に（目安：作業時間の10%以内）実施する
- 次の1〜2スプリント分のストーリーを Ready の状態にしておく
- PO だけでなく、開発者・テスト担当も参加して、受け入れ条件や分割を一緒に考える
- 不要になったストーリーは迷わず削除する
10.4 実例で具体化する手法
- 実例マッピング（Example Mapping）：ストーリー（黄）・ルール（青）・具体例（緑）・疑問（赤）のカードで25分程度で整理する。赤が多ければまだ Ready ではない
- Three Amigos：ビジネス（PO）・開発・テストの3者でストーリーを検討し、視点の偏りを防ぐ
11. よくある失敗と対策
| 失敗 | 対策 |
|---|---|
| 「ユーザーとして」ばかりで、誰のためか分からない | ペルソナや具体的なロールを使う |
| 目的（〜のために）が抜けている、形だけ | 目的が書けないストーリーは価値を再検討する |
| 技術タスクをストーリー形式で書いている（「開発者としてDBを作りたい」） | 利用者価値に紐づけるか、タスクとして扱う |
| ストーリーが大きすぎてスプリントに収まらない | 7章の分割パターンで縦に切る |
| 画面レイアウトや実装方法まで指定している | 振る舞いと価値に絞り、方法はチームとの会話で決める |
| 受け入れ条件が正常系だけ | エラー・境界値・権限のケースを必ず検討する |
| 非機能要件が抜けて後で大きな手戻り | 初期に洗い出し、DoD・受け入れ条件・独立ストーリーで管理する |
| バックログが数百件に膨れて誰も見ない | 定期的に削除・統合する。遠い将来分はエピックのまま粗く保つ |
| PO が一人で書いて開発者に渡すだけ | リファインメントや Three Amigos で一緒に作る |
| リリースしたが成果を測っていない | アウトカム指標を決め、リリース後に検証して次に活かす |
| 「アジャイルだから」と全体像を考えない | ストーリーマップとビジョンで全体を見渡す |
12. ストーリーのテンプレート
## [ID] ストーリー名
**ストーリー**
<役割> として、<目的> のために、<やりたいこと> がしたい。
**背景・補足**
- なぜ今これが必要か、関連する課題やデータ
- 関連エピック：
- 関連資料（モック、業務フロー等）：
**受け入れ条件**
- シナリオ1：（正常系）
- Given
- When
- Then
- シナリオ2：（例外・エラー系）
- Given
- When
- Then
**非機能・制約**
- 例：〇件のデータで〇秒以内に表示
**対象外（このストーリーではやらないこと）**
-
**未解決の疑問**
- [ ] 質問内容（担当・期限）
**見積もり**：〇 ポイント
**優先度**：13. 参考になる体系・資料
- 『ユーザーストーリー実践入門』（Mike Cohn）：ユーザーストーリーの書き方と INVEST
- 『ユーザーストーリーマッピング』（Jeff Patton）：ストーリーマップによる全体像とリリース計画
- 『アジャイルサムライ』（Jonathan Rasmusson）：インセプションデッキ
- スクラムガイド：プロダクトバックログ、完成の定義の公式な定義
- BDD / Gherkin：Given / When / Then による受け入れ条件と自動テストの連携
- IPA「非機能要求グレード」：非機能要件の観点チェック