ベロシティ (Velocity)
ベロシティとは、スクラムチームが1スプリント等の一定期間内に完了・提供できる作業量や開発速度を示す定量的な指標である。過去の実績に基づいて測定され、プロダクトバックログの消化予測や将来のリリース計画の策定、完成時期の推計などに活用される。本指標は局所的な生産性を表す文脈依存的な値であり、チーム間比較や全体的なチーム有効性の代替尺度として用いるには限界があるため、外部評価ではなくチーム内部の自律的なプロセス改善や予測のために機能させる必要がある。ベロシティは外部依存関係やリモート環境の摩擦、セキュリティツールのオーバーヘッドなどによって低下するリスクを持つ。そのため、自動化や運用の工夫を通じて速度と品質を両立させ、単なる速度の追求ではなく、確実な価値提供と持続可能なペースを維持することが重要である。
- 計測と予測への活用：スプリントごとに開発および完了した工数実績、ストーリーポイント、ソフトウェアの単位数を過去の実績に基づき評価・測定し、チームの開発スピードや生産性を測る定量的な尺度として将来の計画策定や予測に用いられる[1][2][3][4]。コード行数やマージ時間などと並び、開発者の生産性や開発速度を測るメトリクスの一つとしても言及される[5]。様々なベロシティのシナリオを仮定することで、プロダクトバックログの残作業に対する完成・納品時期や必要なスプリント数、リリース日を算出・予測する手法が示されている[1][6][2]。特にスプリントレビューにおいては、プロダクトオーナーが将来の完成日やリリース時期を分析・予測するための仮定値として活用される[6]。なお、ベロシティはチーム構成の変更や技術的背景によって変動するため、特に初期スプリントでは慎重に評価される必要がある[1]。また、セキュリティツール等の統合影響を客観的に評価する上でも、ベロシティの変化といった定量的データを測定することが重要とされる[7]。
- 目的と評価への適用不可能性：ベロシティはチーム内部の継続的改善を目的として活用されるメトリクスであり、外部からの評価目的等で使用してはならないとされる[2]。ベロシティの高低は組織やチームごとの文脈に依存するため、チーム間や組織間で客観的に比較することが困難であり、チーム有効性の総合的な代替指標としては限界があると指摘されている[5]。そのため、チーム有効性の総合的評価にはステークホルダー満足度やチーム士気が採用されるべきであり、速度の追求そのものよりも、スプリントごとの確実な価値提供や継続的な改善活動がチームの本質的な有効性に寄与するとされる[5]。他チームとの数値の比較や数値自体の追求ではなく、依存関係の解消や運用の円滑化、チームの自律的改善を促すための指標として機能させることが重要である[2]。
- 影響要因と低下・阻害リスク：外部依存関係やタスクの待ち時間の発生はベロシティを低下させ、チームの応答性を損なう点が指摘されている[8]。リモートワーク環境においては、VPNやMFA（多要素認証）といったセキュリティコントロールに伴う認証の手間や手続き上の摩擦が生じ、これが直接的なコミュニケーションを阻害して意思決定の遅延やベロシティ低下を引き起こすリスクが示されている[4]。さらに、ログベースの不正検知システム導入などのセキュリティアナリティクス統合においては、他チームとの調整やミーティングのオーバーヘッド、意思決定の遅延がベロシティを圧迫するリスクとして挙げられている[9]。また、専任エンジニアをセキュリティ統合業務に割り当てている期間はベロシティが安定するものの、その専任リソースの離脱や再配置が生じるとデリバリー能力の低下が懸念される[9]。
- 維持・安定化と領域特有の適用：学術的なデータ分析や論文執筆などの研究活動を開発プロセスと並行させる際、ベロシティの過剰な重視が研究の厳密性を損なわないよう調整が行われる[3]。分析専用スプリントの導入や研究タスクの並行管理を行うことで、アジャイルのデリバリーベロシティのコントロールと研究成果の創出を両立できることが示されている[3]。カンバンなどのアジャイル手法の活用がベロシティ維持に貢献するほか、ログ分析やアラート通知などの処理を自動化して手動調査の負担を軽減し、開発者のキャパシティを回収することで、開発者のベロシティを損なうことなく持続的なデリバリーとセキュリティ向上を両立できることが示されている[9]。さらにカンバンワークフローやCI/CDへのDAST（動的アプリケーションセキュリティテスト）の統合において、セキュリティよりスピードを優先するタスク指向の文化が存在する場合でも、専任エンジニアへの統合タスク委任や四半期ごとのスキャン実行といった運用方法を採用することで、ベロシティへの悪影響をゼロまたは最小限に抑えられることが示されている[7]。
- 所属タグ: Scrum Metrics Productivity
- カテゴリー: Scrum Core
オントロジー上の位置
Section titled “オントロジー上の位置”- 上位クラス（直接の親から順に）: Measure
- 兄弟クラス: 未定義
- 他の概念との関係: 未定義
- 関連する検証ルール: E7
- 関連CQ: 未対応
- 原文: 未定義
- オントロジー階層: オントロジー階層で見る
Process Constraints (プロセス制約)
Section titled “Process Constraints (プロセス制約)”SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。
- E7 [警告] (Velocity): ベロシティはチーム内部の継続的改善のための指標です。文献(Scrum: An Agile Software Development Process and Metrics)によれば、外部からの評価目的やチーム間の比較に使用してはなりません。また、ベロシティ（アウトプット量）の向上は価値（アウトカム）の向上と同義ではありません。
-
Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3
-
Scrum: An Agile Software Development Process and Metrics — 「ベロシティは、スプリント数の計画や見積もりに使用できます。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4
-
Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design（ライセンス: CC BY 4.0） ↩ ↩2 ↩3
-
Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered — 「これらの技術的課題は、アジャイル思想の核心である自発的で迅速かつ直接的なコミュニケーションを阻害し、意思決定プロセスを遅らせ、ひいてはチーム全体のアジャイルベロシティ（Velocity）を低下させる。」（原文: “These technical challenges hinder the spontaneous, rapid, and direct communication at the heart of the Agile philosophy, slowing down decision-making processes, which in turn reduces the team’s overall agile velocity.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2
-
Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（ライセンス: CC BY 4.0） ↩ ↩2 ↩3
-
Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2
-
Integrating DAST in Kanban and CI/CD: A Real-World Security Case Study（ライセンス: CC BY 4.0） ↩ ↩2
-
Integrating Log-Based Security Analytics in Agile Workflows: A Real-World Experience Report（ライセンス: CC BY 4.0） ↩ ↩2 ↩3