コンテンツにスキップ
Scrum Knowledge Graph

ユーザーストーリー (User Story)

概要

Section titled “概要”

ユーザーストーリーは、XPに端を発しアジャイル開発で広く普及した軽量な要件アーティファクトである。利用者の視点から「役割・手段・目的」を簡潔に表現し、粗粒度のエピックから開発可能な粒度へ分解して扱われる。対話や受け入れ基準を通じて共通理解を形成し手戻りを防ぐ一方、制御された自然言語ゆえの曖昧さに対しては、前提の特定や多面的な品質基準（構文・意味・実践）、NLPによる自動検証等を活用した洗練と適応的更新が図られる。見積もりや計画の基礎として機能し、スケーリング環境におけるチームの自律性を担保する中核単位となるほか、セキュリティやモデルベース開発など多様な領域へと応用されている。

詳細

Section titled “詳細”

標準的なアジャイル・スクラム開発において、ユーザーストーリーは開発サイクルの初期フェーズから用いられ、プロダクトバックログ内の機能要件や品質要件を表現するための標準的な手法であり、価値を継続的に届けるための要件アーティファクト・実践的プラクティスとして広く用いられる[1][2][3][4][5][6][7]。ユーザーストーリーは主にエクストリーム・プログラミング（XP）で導入されたが、スクラム等においてもバックログアイテムを表現する標準形式として広く普及している[8]。ステークホルダーの述べられた意図から開始され、価値や利用者の視点を表現するものであり[9]、顧客が価値を認める特定の機能や成果を定義するために収集・整理され[10]、「[ユーザー]として、私は[機能]を望む。それによって[ベネフィット]が得られるからだ（As a … / I want to … / In order to …）」といった標準フォーマットで記述され、ユーザーの役割（ユーザータイプ）、望む機能や要件、および達成したい目的や得られる価値を明確に提示する[11][5][6]。顧客やユーザーのニーズを直接的かつ簡潔に表現し、ステークホルダーによってバックログへ継続的に追加および更新され、開発チームとステークホルダー間のコミュニケーションの基礎として機能する[4]。その際、顧客のニーズを捉えた言葉でストーリーについて議論することが重要とされる[10]。また、開発結果が正しく開発されたかを検証するための受け入れ条件（Acceptance Criteria）や詳細なシナリオなどの属性と組み合わせて運用される[1][2][3][5][6]。ユーザーストーリーは、1スプリントで開発可能な適切なサイズと明確な受け入れ基準を持つことが求められる[12]。

通常、プロダクトオーナーが提示した粗粒度の要件や大きな要件単位である「エピック」から、開発チームがスプリントで実装可能な適切な低粒度のユーザーストーリーへと分解される[2][13]。チームはタイムボックス化されたスプリント期間内でユーザーストーリーを開発する権限と責任を持つ[13]。ユーザーストーリーは、アジャイルやリーンの原則に基づき、作業を顧客満足に直結する価値単位へと分割・可視化する手段を提供し、プロダクトオーナーによる優先順位付けを経て、スプリント計画（スプリントプランニング）の段階で優先順位付け・工数見積もり・具体的な開発タスクへの分解が行われて開発が進められる[2][3][4][5]。各スプリントにおいてユーザーストーリーを完了させるためには、新機能の開発だけでなく、ドキュメント作成、テスト、UIの要求事項の反映などが初期段階から進められる[10]。また、リリース計画を策定する際には、リリース前に完全に完成させる必要のあるユーザーストーリーや機能の数を適切に特定・管理することが求められる[13]。

しかし、スクラムが具体的な要件定義手法を規定していないことに起因して、実務における要件エンジニアリングには種々のアンチパターンが観測されている[12]。「ユーザーストーリーが十分に詳細化されていない」反パターンは、表IXの重み付けスコアが58.93%（満点168に対する割合で、組織の割合ではない）で3位である[12]。著者らは、これを要件エンジニアリングの問題に起因するとしている[12]。加えて、「会議中に大きなユーザーストーリーを小さなものに分割しない」反パターンの重み付けスコアは38.10%（満点168に対する割合）であった[12]。一方で「非常に詳細すぎるユーザーストーリー」は重み付けスコアが32.74%（満点168に対する割合）であり、要件定義における過不足のバランスを取ることの難しさが指摘されている[12]。

このように、ユーザーストーリーは軽量であるがゆえに複数レベルで潜在的な曖昧さを抱えやすい[9]。そのため、ステークホルダーへのアクセスと継続的な対話を通じて、前提条件や未解決の疑問、依存関係を特定することが不可欠とされる[9]。さらに、品質ユーザーストーリーフレームワークなどの明確な品質基準を導入することで検証可能性を高めるとともに、プロトタイプによる検証や意思決定の結果に応じて、ストーリーの内容や受け入れ基準を適応的に更新していく運用が重要となる[9]。

生命に関わるシステムや基幹系システムなどの特定領域ではユースケースの併用がみられる[1]。また、プロダクトの全体像把握やプロダクトビジョンから具体的な作業項目へのブレイクダウンを支援する目的で、ユーザーストーリーマッピング、インパクトマッピング、共感マップといった関連手法と連携・統合され、顧客ニーズの理解と価値の協調的設計に活用される[3]。

  • 大規模アジャイル開発・スケーリング環境における実践とチームの自律性: 大規模開発の実践事例では、定義された300個のエピックから約2,500個のユーザーストーリーが導出され、各開発チームの作業単位として割り当てられた[14]。ビジネスプロジェクト側がユーザーストーリーの定義、優先順位付け、および詳細化を担当し、開発者はイテレーション期間中に「ミニデモ」を実施してビジネス側のオペレーターと解釈や実装内容を直接確認することで、手戻りの防止や調整が進められた[14]。また、スケーリングフレームワークの分析においては、バックログアイテムを作成・洗練してストーリーへと分解・具体化する作業はチーム主導で行われ、SAFeのPIプランニング等においてもチーム自身がストーリーへの分解方法を決定する[15]。どのストーリーをスプリント（イテレーション）で実装するかはチームが決定し、承認はプロダクトオーナーによって行われるとともに、ストーリーの作成、選択、タスク分解、見積もりをチーム自身が担うことで、ストーリー実現への完全な責任と自律性がチームに委ねられている[15]。 6 組織の比較事例研究で、デジタルトランスフォーメーションの専門家は、コンサルタントのフレームワークで役割を定義する組織が、誰のために何のために作るのかというユーザーストーリーを見落としていると述べた[16]。 大規模アジャイル変革の文献レビュー（一次文献の大半は体験報告）が紹介する 1 つの研究では、上位のプロダクトマネジメントが要求を大きな塊（チャンク）で提供したため、チームが適切な規模のストーリーを定義するのに膨大な時間を費やした[17]。
  • セキュリティ要件への応用: セキュアソフトウェアのアジャイルエンジニアリング（AESS）において、ユーザーストーリーは要件記述の基礎であり開発アクティビティを牽引する原動力とされる[18]。潜在的なリスクや脅威シナリオを表現するため、アビューザーストーリー、セーフティストーリー、誤用・悪用ケース（Misuse/Abuse Case）、汎用セキュリティユーザーストーリーといった派生形式が活用される[18]。アビューザーストーリーと通常の機能要件ストーリーを相互に調整・確認するプロセスや、汎用セキュリティユーザーストーリーによるチーム全体の共通認識形成を通じ、バックログ上でのセキュリティ課題の可視化と優先順位付けが容易になる[18]。
  • インクルーシブデザインとアクセシビリティ: 教育技術デザインなどの領域では、全盲の指導者や全ろうの学生といった具体的な障害ペルソナを設定し、アクセシビリティニーズを前面へ出した要件定義に活用される[6]。要求事項を受け入れ条件（基準）と直接紐付けることで、アクセシビリティを「生きたアーティファクト」としてプロダクトバックログ上で継続的に優先管理する運用がなされる[6]。
  • ブロックチェーン活用: 分散開発フレームワークChainAgileにおいては、ストーリーの設計・開発プロセスを透明かつ自動的にサポートし実行を促進するため、スマートコントラクトが利用される[19]。
  • モデルベース開発との統合: 複雑なシステム開発におけるMBSEとスクラムの統合アプローチであるsMBSAPでは、ユーザーストーリーを動的UMLモデルと組み合わせることで、従来のスクラムにおける構造の不足を補い、要件の曖昧さの削減・構造化・トレーサビリティの向上を実現している[7]。
  • BDDおよびオントロジーとの統合: ビヘイビア駆動開発（BDD）の文脈では Given / When / Then 形式の受入シナリオを包含し、オントロジーを活用することで自然言語による曖昧さを排除し、形式的な仕様記述および自動実行可能な受入テストへの変換が行われる[11]。
  • ソフトウェアプロダクトライン手法との融合: ソフトウェアプロダクトラインエンジニアリング（SPLE）とスクラムの統合アプローチにおいて、資産の再利用可能性を高めたアジャイルな要件定義および開発アプローチの基盤として活用される[5]。
  • 課題管理データにおけるアジャイル実践のプロキシとしての参照: 実証研究などの文脈において、課題追跡ツール（Jira等）の大規模データセットからプロジェクトがアジャイルフレームワークを採用しているかを判別する指標（プロキシ）の一つとしてもユーザーストーリーが参照されている[8]。

Ericssonの大規模アジャイル開発組織の事例では、ユーザーストーリーはエピックから分割される最も詳細な機能要求で、主に開発者が使用する[20]。

安全重視のソフトウェア向けの Scrum for Safety（S4S）を検証した事例では、ソフトウェア機能の初期セットは、プロダクトバックログのユーザーストーリーとセーフティストーリーの形式で与えられた[21]。

機械学習システム開発では、従来のユーザーストーリーがデータ要件や倫理的課題に十分対応できないため、モデルストーリーやデータストーリーといった派生形式への拡張が提案されている[22]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Requirements Agile User Story Quality
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

Process Constraints (プロセス制約)

Section titled “Process Constraints (プロセス制約)”

SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • S1 (UserStory): ユーザーストーリーには受け入れ条件が1つも定義されていません。

脚注

Section titled “脚注”

  1. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3

  2. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4

  3. Agile Coaching Growth Wheel — 「『ユーザーストーリーマッピング：プロダクトの全体像を見いだし、正しいプロダクトを作る』 (2014).」（原文: “Jeff Patton. User Story Mapping: Discover the Whole Story, Build the Right Product, (2014).”）（訳）（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  4. Scrum: An Agile Software Development Process and Metrics — 「したがって、ユーザーストーリーとも呼ばれるこれらの機能はプロジェクトの開始時に優先順位付けされ、このプロダクトバックログは常に生きた状態となり、ステークホルダーはユーザーストーリーの形でバックログに項目を追加し続けます。」（原文: “So, these features which are also called as User Stories are prioritized at the starting of the project, this Product Backlog will always be live and the stakeholders keep on adding things to the backlog in the form of User Stories.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  5. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  6. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「各ユーザーストーリーは、ユーザー、アクセシビリティ要件、および意図されたベネフィットを指定し、設計ガイダンスと受入基準の両方として機能しました。」（原文: “Each user story specified the user, the accessibility requirement, and its intended benefit, serving simultaneously as design guidance and acceptance criteria.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  7. Integration of MBSE and scrum for complex system development: the sMBSAP proposal（ライセンス: CC BY 4.0） ↩ ↩2

  8. A Novel Technique to Assess Agile Systems for Stability — 「「ユーザーストーリー」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  9. Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「明示的なストーリー品質基準は、Quality User Storyフレームワークによって支持されている」（原文: “Explicit story-quality criteria are supported by the Quality User Story framework”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  10. Lean and Agile Software Development for Managing Technical Debt on Large-Scale Software: A Systematic Literature Review — 「アジャイルでは、顧客が価値を認める特定の機能や成果を説明する顧客の「ユーザーストーリー」を収集することを重視します。」（訳）（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  11. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development — 「ユーザーストーリーは、そのストーリーにおけるユーザーの役割、ユーザーが望むフィーチャー、およびシステムが望ましいフィーチャーを提供した場合にユーザーが得られる価値（ベネフィット）を明確にする必要があります。」（原文: “A user story should elucidate the user’s role in this story, the feature desired by the user, and the benefit gained by the user if the system provides the desired feature.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  12. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations — 「その結果、ユーザーストーリーの30%が進行中、およびスプリント計画日とスプリントレビュー日のそれぞれで32%のユーザーストーリーが完了していることが示されました。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  13. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  14. Inter-team Coordination in Large-Scale Agile Development: A Case Study of Three Enabling Mechanisms — 「これにより、ペンションファンドがプロジェクトのビジネスチームに30人以上の優秀なオペレーターを配置することが可能になり、開発者は、ユーザーストーリーについて直接確認することができました。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  15. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks（ライセンス: CC BY 4.0） ↩ ↩2

  16. How to Implement Bottom-Up Organizing: Lessons from Agile Piloting and Scaling — 「彼らが完全に見落としているのは、ユーザーストーリーです。誰のために？ なぜこれをやっているのか？ ということです。」（原文: “What they completely miss is the user story.”）（訳）（ライセンス: CC BY 4.0） ↩

  17. Challenges and success factors for large-scale agile transformations: A systematic literature review — 「ある研究 [P48] では、上位のプロダクトマネジメントが要求を大きな塊（チャンク）で提供したため、開発チームが適切な規模のストーリーを定義するのに膨大な時間を費やすことになったと述べられている。」（原文: “One study [P48] describes how high level product management delivered requirements in large chunks, resulting in development teams spending huge amounts of time defining suitably sized stories.”）（訳）（ライセンス: CC BY 4.0） ↩

  18. Identifying Key Activities, Artifacts and Roles in Agile Engineering of Secure Software with Hierarchical Clustering — 「さらに、ユーザーストーリーがAESSの原動力と見なせるため、セーフティストーリー [9]、アビューザーストーリー [36]、誤用・悪用ケース [37]、および汎用セキュリティユーザーストーリー [38] などのセキュリティ関連ストーリー（最終製品に対するあり得るシナリオや脅威のセット）が文献で提案されています。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  19. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain（ライセンス: CC BY 4.0） ↩

  20. Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson — 「ユーザーストーリーはエピックから分割される。これらは最も詳細な機能要求であり、主に開発チームによって使用される。」（原文: “User stories are split from epics. They are the most detailed functional requirements and are mostly used by the development teams.”）（訳）（ライセンス: CC BY 4.0） ↩

  21. Scrum for safety: an agile methodology for safety-critical software systems — 「プロダクトバックログのユーザーストーリーおよびセーフティストーリーの形式による、ソフトウェア機能の初期セット。」（訳）（ライセンス: CC BY 4.0） ↩

  22. Agile Management for Machine Learning: A Systematic Mapping Study — 「さらに、MLワークフローの本質的に連続的かつ相互依存的な性質（例：データ前処理、モデルトレーニング、モデル評価）は、従来のユーザーストーリーの個別で独立した構造とは対照的であり[8]、スプリントプランニングにおける不一致につながっている。」（原文: “Furthermore, the inherently sequential and interdependent nature of ML workflows (e.g., data preprocessing, model training, model evaluation) contrasts with the discrete, self-contained structure of traditional user stories [8], leading to misalignments in sprint planning.”）（訳）（ライセンス: CC BY 4.0） ↩