# ユーザーストーリーとは

システムにしてほしいことを、利用者の目的とともに短く整理した計画の単位です。詳細は開発開始が接近するにつれて会話で具体化するため、全体の範囲は別に決定し、遵守すべき条件も別に用意する必要があります。

## ユーザーストーリーとは

ユーザーストーリーはシステムにしてほしいことを、利用者の視点で短く整理した記述です。誰として、何をしたいか、何のためかの3点を示す[形式が一般的](https://martinfowler.com/bliki/UserStory.html)で、付箋やカード、開発管理ツールの作業1件として管理されます。たとえば次のとおりです。

> 地域担当の営業マネージャーとして、地域ごとの月次売上を比較したい。支援が必要な地域を特定するためです。

最初の記述では画面構成や表示項目を必要以上に固定しません。重要な制約は早めに確認し、詳細は開発開始が接近するにつれて、開発チームとの会話や例で具体化します。

要件定義書が要件の全体を文書化するのに対し、ユーザーストーリーは[要件を計画しやすい規模に分割した単位](https://martinfowler.com/bliki/UserStory.html)です。1件は[通常は1人で数日かかり、1回の開発期間に複数件含まれる程度](https://martinfowler.com/bliki/UserStory.html)が目安とされています。

建築なら間取り図の代わりに、朝の混雑を避けるため洗面台を2か所にしたいと要望し、配置は設計者と相談する進め方に近いです。

![ユーザーストーリーの記述を誰として・何をしたい・何のための3段で構成した表。誰としては地域担当の営業マネージャー、何をしたいは地域ごとの月次売上を比較、何のためは支援が必要な地域を特定で、何のための段を強調している。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-0bdc2e56db39cd098e0e035aa01b8c8541928169e224e0b010091f73fd254108.png)

## なぜ必要か

要件を最初に長い文書で網羅すると、[確実になったという錯覚が生じやすい](https://www.mountaingoatsoftware.com/agile/user-stories)うえ、詳細を書き足しても、[開発を開始してから認識の違いが明らかになる場合があります](https://www.mountaingoatsoftware.com/agile/user-stories)。[詳細の一部は開発前に変化するか、開発されないこともあります](https://www.mountaingoatsoftware.com/agile/user-stories)。

ユーザーストーリーは[長い仕様書の代わりに会話を中心にした要件の伝え方](https://martinfowler.com/bliki/UserStory.html)として考案され、短い期間の反復で開発する[アジャイル開発で広範に使用されています](https://martinfowler.com/bliki/UserStory.html)。詳細を先送りするため、ストーリーには[次の3つの要素](https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)がすべて必要とされています。

- カード: 何の話かを示す短い記述
- 会話: 利用者の目的、例外、業務の規則を、意思決定できる人と開発チームが対話して具体化すること
- 確認: 完成と判定する条件。完成条件、受入条件とも呼び、[完成したものを確認する受入テストの項目になる](https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)

![1件のストーリーに必要な3つを示した図。カードは何の話かを示す短い記述、会話は目的・例外・規則を対話して具体化すること、確認は完成と判定する条件。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-a36c0e3b71d16dd83f7c92bbf2d8432bbbce6a23675502c3cb45dfaec5f2c8f3.png)

## 効果

- [計画と優先順位の判断を件単位で実施できる](https://martinfowler.com/bliki/UserStory.html)。[未開始のストーリーは詳細と優先順位を後から変更できる](https://www.agilealliance.org/glossary/user-stories/)
- 画面の案ではなく目的で議論できる。[目的が記述できない機能は必要性を再検討する合図になる](https://www.gov.uk/service-manual/agile-delivery/writing-user-stories)
- 完成条件があればできたかどうかを開発チームと事業側が同じ基準で判定できる

![議論の対象の違いを左右で示した対比。左は画面の案を議論する場合を示し、画面の構成と表示項目が対象になる。右はストーリーを議論する場合を示し、目的、完成条件、件ごとの優先順位が対象になる。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-f30853e3292b193e6e55db8e522e5e1f39154ddeb0a548e20c3de42fe6068ea4.png)

## コストとリスク

- 会話での詳細の具体化に、意思決定できる人の時間が必要。アジャイル開発の枠組みであるスクラムでは、開発する候補を優先順に列挙した一覧をプロダクトバックログ、その順序の責任者をプロダクトオーナーと呼ぶ。[プロダクトオーナーは1人で、組織全体がその決定を尊重する前提](https://scrumguides.org/scrum-guide.html)
- 全体像を把握しにくい。一覧が長いと範囲や費用を確認しにくいため、利用者の行動の流れの順にストーリーを配置する[ストーリーマッピング](https://www.mountaingoatsoftware.com/agile/user-stories)などで補完する
- テストを自動で実行する仕組みであるテスト自動化の費用が必要。機能が増加するたびに過去の機能も再確認するため、[小さな単位で追加する開発ではテスト自動化がほぼ必須](https://www.agilealliance.org/glossary/user-stories/)
- 記録とバックログの維持が必要。仕様が変更されるたびに、完成条件、テスト、判断の理由を更新する。更新しないと改訂前の条件で完成を判定するおそれがある。[バックログの詳細化も継続的な作業](https://scrumguides.org/scrum-guide.html)
- 記述できる人材が必要。[要件分析の経験者が習得しやすい](https://www.agilealliance.org/glossary/user-stories/)ため、担当できる人がいなければ育成か採用が必要

![2つのレーンで示した役割分担。一覧の順序の責任者はプロダクトオーナーで、開発期間の対象とする件は開発者がプロダクトオーナーと相談して選択する。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-4ca703b9e13d308fa97a0ab4b5311ffe4753920010a85ed5c0ab6010d8b17786.png)

## 要件定義書がなくてもユーザーストーリーで開発してよいか

機能の単位としてはユーザーストーリーで開発できます。ただし事業の目的、対象範囲の大枠、遵守すべき条件は、ストーリーとは別に用意する必要があります。ストーリーは[要件を計画のために分割する単位](https://martinfowler.com/bliki/UseCasesAndStories.html)で、全体を示す役目がないためです。スクラムでは目標とするプロダクトの将来の状態を[プロダクトゴールとしてバックログに含め](https://scrumguides.org/scrum-guide.html)、バックログの各項目はそれを実現する内容として列挙します。

次の場合は開発前に別の記録や調査を用意します。

- 法令、監査、社内規程で、要件の文書を提出または保管する必要がある
- 既存システムの機能をそのまま新システムへ引き継ぐ。[要件定義の前に現行システムを調査し、仕様を明確にする必要がある](https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087450.pdf#page=11)
- 複数の部署が関与する。関係する部署が最初に対象と対象外を記録して合意する
- 優先順位を決定する人が未定。担当と権限を先に定める

該当せず、使い方を確認しながら開発したい業務の機能なら、範囲と費用を最初から固定せず開発する選択もできます。

![文書の提出・保管、現行踏襲、複数部署、判断者未定のいずれかに該当するかの分岐。どれかに該当するなら記録・調査後にストーリーで開発し、なしなら使い方を確認しストーリーで開発する。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-1f95dd6773c5a1980998c1f83db85591a5cb9cd6729aa6e90e4b97f5eacdf112.png)

## どこまで記述すれば開発を開始してよいか

開始直前のストーリーは1回の開発期間で完成でき、完成条件を具体的に説明できる状態を目安とします。先の予定のストーリーは[優先順位が低いほど粗いまま](https://www.mountaingoatsoftware.com/agile/user-stories)でも問題ありません。

### 合意と確認

冒頭の例では売上の計上日と契約日のどちらで月を決定するか、地域への帰属は営業所と顧客のどちらの所在地か、売上のない地域をどう表示するかを開発チームと事業側が開発前に合意します。合意した内容は次のような完成条件にします。説明用の例です。

- 選択した月の地域別売上が合意した集計規則と一致する
- 担当外の地域の売上は表示されない
- 売上のない地域は0円と表示される

開始の可否は次の3点で確認します。

- 誰のどの目的かを1文で説明できる
- 完成条件を具体的に記述できる
- 開発チームの見積もりで、1回の期間以内に終了できる。[規模の判断は開発者の責任](https://scrumguides.org/scrum-guide.html)で、他システムの変更待ちやデータ準備の未完了がないことも条件になる

### スプリントと分割

スクラムの固定の開発期間をスプリントと呼び、[長さは1か月以内](https://scrumguides.org/scrum-guide.html)です。[開発とテストに数週間を超えてかかる大きなストーリーは、一般にエピックと呼ばれ](https://www.gov.uk/service-manual/agile-delivery/writing-user-stories)、可能なら分割します。分割は[画面と集計処理のように技術の層だけで分割せず](https://www.mountaingoatsoftware.com/agile/user-stories)、利用者が結果を確認できる単位にします。冒頭の例が1回の開発期間で完成できないなら、1か月分の一覧、月ごとの推移、前年同月との比較の順に分割します。

![地域別売上の比較が1回の開発期間で完成できない大きなストーリーだった場合の分割例。1か月分の売上一覧、売上の月ごとの推移、売上の前年同月比較に分割し、左から右の順に開発を開始することを示す木の図。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-662911a31d4cd11ec2a0a1a03371785648c72f0b12cd9057f1eaa7b7232b51b3.png)

スクラムではスプリントの対象とする項目は[開発者がプロダクトオーナーとの相談を通じて選択します](https://scrumguides.org/scrum-guide.html)。

## 性能や安全性のような条件はどこに記述するか

全体にかかる条件は個別のストーリーに分散させず、全ストーリーに共通する品質の基準である完成の定義に記載します。特定の機能にだけ関係する条件は、そのストーリーの完成条件に記述します。

性能、安全性、停止してよい時間のように、機能ではなく性質に関する条件を非機能要件と呼びます。[設計の選択肢を限定する制約として、ストーリーの形で記述できます](https://www.mountaingoatsoftware.com/agile/non-functional-requirements-as-user-stories)。求める人と目的を記載しないと、後から理由が分からなくなるおそれがあります。たとえば既存のデータベースを使用するとだけ記録すると、別のデータベースを作成するおそれがあります。

完成条件はそのストーリーの振る舞いを確認する基準です。スクラムでは完成の定義を満たさない項目は[公開も、スプリントの成果を確認するスプリントレビューでの提示もできません](https://scrumguides.org/scrum-guide.html)。個別に記述すると条件を記述しなかったストーリーが条件を満たさないまま完成するおそれがあります。同時に利用する人数、個人情報の管理、停止してよい時間帯のような全体の条件は、機能ごとには確認できないため、システム全体での確認を別に計画します。

![ストーリーごとの完成条件と、全ストーリーに共通する完成の定義を示した図。ストーリーの下部に斜線付きの基礎線があり、その下に共通の完成の定義を示している。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-a6bb4d609a8956de69bfa3de6bdbd8e8d2187ebadd90083804ef1186c6c08b84.png)

## よくある誤解

### 1文記述すれば仕様になる

記述された1文は要件そのものでなく、会話の合図です。[要件は会話や例、規則、テストを通じて明らかになります](https://www.mountaingoatsoftware.com/agile/user-stories)。合意した振る舞いは完成条件に記述し、判断の理由はストーリーから参照できる形で記録します。

![左から順に、記述された1文、会話・例・規則・テスト、要件を示した流れ。中間の会話・例・規則・テストを強調している。](https://media.marketing.kdotdev-tunnel.org/glossary-user-story-4519a800c2badc321560347652f5d9ff1fdfe2fcf79d3587195d1301909411fa.png)

### 機能一覧をストーリーの型に変換すれば十分

[要件文書の章立てから機械的にストーリーを作成する](https://www.agilealliance.org/glossary/user-stories/)のは、典型的な失敗です。画面やボタンだけの項目はストーリーではなく、目的が記述されていなければ、形式だけの機能一覧です。調査や技術的な改善のように、[ストーリーの形にしないほうが明確な項目](https://www.mountaingoatsoftware.com/agile/user-stories)は、ストーリーにしなくても問題ありません。

### 誰としての欄に利用者と記述すれば利用者の視点になる

[誰としての欄に利用者とだけ記述した例は、利用者も目的も曖昧な不十分な例として示されています](https://www.mountaingoatsoftware.com/agile/user-stories)。冒頭の営業マネージャーのように、利用者を具体的に記述します。[プロダクトオーナーは利用者ではないことが多い](https://www.mountaingoatsoftware.com/agile/user-stories)ため、事業側の担当者の視点だけで記述すると、実際の利用者の目的が欠落することがあります。