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

要件 (Requirement)

概要

Section titled “概要”

要求（要件）とは、プロダクトやシステムが達成すべきゴールであり、顧客や利用者の機能・品質条件や制約を規定したものである。アジャイル開発では固定的な事前計画ではなく、短いサイクルごとに収集・整理され、環境変化やフィードバックに応じて柔軟に適応される動的な存在とされる。作業サイクルに合わせて小さな要素やタスクに分割され、段階的に検証可能な成果物として具体化されるとともに、根本的な課題解決に向けた仮説として継続的に検証・再定義される。プロダクトバックログ等で管理される一方、大規模開発では外部環境の変化に伴う新規要件の追加や頻繁な変更が技術的複雑さやチーム間の依存関係を増大させるため、チームの自律性維持や組織的な調整メカニズムへの適応が不可欠となる。

詳細

Section titled “詳細”

  • 要求の定義と表現形式 アジャイル開発においては顧客とデベロッパーの継続的な協働を通じて進化し、ユーザーストーリーやシナリオとして段階的に詳細化される[1][2]。また、従来の非形式的な自然言語記述では解釈の食い違いや曖昧さが生じやすいため、ドメインオントロジーやBDD（振る舞い駆動開発）を用いて形式化する手法も用いられる[1]。

  • 反復的アプローチにおける要件の収集と段階的分割 顧客のニーズや期待を満たすために定義され、ユーザー要件の変化に対応して柔軟に調整される[3]。反復的なアプローチにおいては、要件は固定的な事前計画としてではなく、反復開始時にチームでまとめて収集・計画される[3]。さらに、各反復の作業サイクルに合わせて要件は小さな構成要素やタスクに分割され、段階的に検証可能な成果物として具体化される[3]。

  • ユーザー中心設計・リーンスタートアップとの統合における問題解決と継続的再定義 従来のプロジェクト型開発のように事前に定義された要件を受け取って実装するだけでは、真の課題解決につながっているかが不明確になりやすい[4]。そのため、単なる要件の精緻化作業に終始するのではなく、ユーザーやビジネスが抱える根本的な課題の理解に焦点を当て、創造的なソリューション探索を促す問題解決型アプローチへと視点を転換する[4]。ビジネスアナリストなどの特定職種のみならず、ソフトウェアエンジニアやデザイナーを含むチーム全体がニーズ把握と定義プロセスに関与し、構築-測定-学習（BML）サイクルや実験を通じて仮説を検証しながら、得られた知見に基づいて要件や前提条件を柔軟に再定義する[4]。

  • 要求工学・分類とトレーサビリティ管理 要求はシステムが提供すべき具体的な動作を規定する主要機能要件（MFR）と品質基準等を規定する非機能要件に分類され、ビジネスプロセスモデルやユースケース、顧客ニーズから特定・抽出される[1][5]。ドメイン要件エンジニアリング等においては共通性や可変性が分析・モデル化され、分析や設計プロセスを経てプロダクトバックログ、スプリントバックログ、テスト基準へと具体化される[5]。これらの成果物間で一貫したトレーサビリティが維持される[1][5]。また、MBSEとスクラムの統合アプローチ（sMBSAP）では、UMLモデルおよびスプリントと直接関連付けることで、高水準で継続的なトレーサビリティと柔軟な変更対応が両立される[6]。

  • 非機能要件・技術要件への適応 セキュリティなどの品質要件（非機能要件）は標準的なプロセスから漏れやすいため、要件定義、リスクアセスメント、優先順位付けを通じて開発プロセス内に組み込むことが不可欠とされる[7]。また、KanbanやCI/CD環境でのDAST統合などにおいては、急速に変化する機能要件やデータ保護要件に対して、認証連携や動的コンテンツ対応などの技術的・運用要件を満たしつつ適応的に対応することが求められる[8]。

  • アジャイルにおける要求の変更・自己組織化とシンプルさ 開発の後期であっても要求の変更を歓迎し、変化を味方にすることで顧客の競争力を引き上げる[9]。最良の要求は、最良のアーキテクチャや設計と同様に自己組織的なチームから生み出される[9]。また、ムダなく作れる量を最大限にする「シンプルさ」を本質とし、要求や設計を最適化することが重視される[9]。

  • EBM（エビデンスに基づくマネジメント）における仮説と実験としての要求 要求は「特定の作業が特定のアウトカムにつながる」という価値の仮説を表す[2]。多額の費用をかけて実装された要求であっても、実際に顧客によって検証されるまでは仮説の域を出ず不確実性が残る[10][2]。経験的アプローチに基づき、要求が持つ価値を具体的にテストする実験を意図的に設計し、結果を検査・適応させる[2]。要求の価値を判断するためにプロダクト全体の構築が必須なわけではなく、重要な想定を検証できるだけの最小限の構築とテストで十分とされる[10][2]。

  • ブロックチェーンを活用した分散型スクラムでの特定と記録 ChainAgileの要求抽出層において顧客から導出され、ユーザーストーリー形式で表現される[11]。グループチャットやビデオ会議などを通じて検証が行われ、決定された要求はスマートコントラクトとして改ざん不能な形で記録されることで、分散開発環境における高い透明性とトレース可能性が確保される[11]。

  • 大規模アジャイル変革における要件エンジニアリング 大規模アジャイル変革においては、要件エンジニアリングにおける不明確または誤った要件の存在が主要な課題として挙げられる[12]。とりわけ非機能要件を含む統合や連携の困難さは、ソフトウェア品質の劣化を引き起こす要因となる[12]。そのため、プロセス完了前に要件を明確かつ十全に定義・確立する要件エンジニアリングの実践が、変革における重要な成功要因とされる[12]。

  • 大規模スクラム環境における要件管理の課題 大規模アジャイルスクラム環境においては、要件の頻繁な変更（高い変動性）と要件間の複雑な相互依存関係が、チーム間の調整負荷を増大させ、チームが自律的に運用することを阻害する最大の要因の一つとなる[13]。さらに、プロジェクト管理者が従来のウォーターフォール方式のように要件を固定的に管理しようとする傾向があり、チームの自律的な選択原則と衝突する課題が生じる[13]。また、プロダクトオーナーが作成する粗粒度の要件と開発チームが作成する詳細要件の間で依存関係や仕様の不整合が発生しやすいことや、事前の包括的な文書化を避けるアジャイルの傾向に起因して要件を満たすためのアーキテクチャドキュメントが不足し、安全性やミッションクリティカルな開発において重大な問題を引き起こすことが指摘されている[13]。

  • 大規模アジャイルにおける要件の変化と調整メカニズムの適応 大規模アジャイルソフトウェア開発において、要件の変更や新規追加は不可避な変化イベントであり、システムの技術的複雑さやチーム間の依存関係を直接増大させる主要因となる[14]。公共交通機関改革などの外部要因や新規クライアントのオンボーディングに伴い、厳しい納期とともに大量の新規要件が導入されたり、既存顧客のリブランディング（顧客名やロゴの変更）といった外部イベントにより古いハードコードされたシステムから新システムに至るまで広範なコード変更・要件更新が要求されたりする[14]。新たな要件は各チームの個別バックログだけでなく、プログラム全体のチーム間バックログやデリバリー計画へと集約・更新され、優先順位付けが行われる[14]。このように要件の増加や変化はチーム間の知識・技術・プロセスの依存関係を激増させ、顧客マネージャーの増員やデリバリールーチンの統一など、新たな調整メカニズムを導入・適応させる直接的な契機となる[14]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Requirements Change Management Dependencies
  • カテゴリー: Value & Metrics

オントロジー上の位置

Section titled “オントロジー上の位置”
  • 上位クラス（直接の親から順に）: 未定義
  • 兄弟クラス: 未定義
  • 他の概念との関係: 未定義
  • 関連する検証ルール: 未定義
  • 関連CQ: 未対応
  • 原文: 未定義
  • オントロジー階層: オントロジー階層で見る

脚注

Section titled “脚注”

  1. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  2. EBM Guide 2020（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  3. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  4. Combining User-Centered Design and Lean Startup with Agile Software Development: A Case Study of Two Agile Teams（ライセンス: 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

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

  7. Identifying Key Activities, Artifacts and Roles in Agile Engineering of Secure Software with Hierarchical Clustering（ライセンス: CC BY 4.0） ↩

  8. Integrating DAST in Kanban and CI/CD: A Real-World Security Case Study（ライセンス: CC BY 4.0） ↩

  9. Principles behind the Agile Manifesto（ライセンス: 著作権あり・告知を含む全文に限り複製可） ↩ ↩2 ↩3

  10. EBM Guide（ライセンス: CC BY-SA 4.0） ↩ ↩2

  11. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain — 「“Requirements”: “合意書における開発者のすべての条件が達成されること”。」（原文: ““Requirements”: “All the terms and conditions of developers in the agreement must be achieved””）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  12. Agile Transformation at Scale: A Tertiary Study（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

  14. Responding to change over time: A longitudinal case study on changes in coordination mechanisms in large-scale agile（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4