Loading article…
ベロシティとは、ソフトウェア開発の進捗速度を表す用語です。課題追跡ソフトウェア（Jiraなど）を使用する開発チームでは、ベロシティはストーリーポイント[ 1 ]で測定されることがよくあります。しかし、「コードが進化する速度」はあらゆるソフトウェアプロジェクトの成否に大きく影響するため、ベロシティを測定するためのさまざまな方法が提案されています。これらの多くは、ストーリーポイント[ 2 ]を推定するために必要な時間と調整の負担を伴いません。
アジャイルの実践者は、ベロシティについて論じる際、開発者のパフォーマンスを評価する唯一の手段としてベロシティに頼ることの危険性を強調する[ 3 ]。彼らはしばしばグッドハートの法則[ 4 ]、すなわち、目標となった尺度はもはや良い尺度ではなくなるという法則を引用する。しかし、ベロシティが高いチームの方がより良い成果を上げていることを示唆する研究が続いているため[ 5 ]、ベロシティ計測方法への関心は依然として高い。
特に、AIコーディングアシスタントの利用拡大により、ソフトウェアデリバリーの速度に対するAIの影響を理解する手段として、ベロシティへの関心が高まっています。2026年のデータによると、「AIの利用拡大」と「ベロシティ向上」の相関関係は増加し続けています[ 6 ]。
ベロシティの主な目的は、チームが一定期間内にどれだけの作業を完了できるかを推定することです。平均的なアジャイルチームのスプリントは約2週間続くため[ 7 ]、「過去のベロシティ」を解釈することは、「妥当な作業負荷」を予測する上で重要です。
アジャイルチームは、開発者の過去の作業速度（ストーリーポイントまたはその他の単位）を分析することで、スプリントごとにストーリーポイントを適切に配分し、割り当てられた課題の余裕や過剰を最小限に抑えることができます。
ストーリーポイント、コミット、解決済み課題のいずれの単位で測定しても、ベロシティは相対的な尺度です。言い換えれば、生の数値には客観的な価値はほとんどなく、重要なのはその傾向です。[ 8 ]
速度追跡では、以下の用語が使用されます。
ベロシティの問題の1つは、実行された作業と計画の正確さを混同することです。言い換えれば、チームはタスクをより保守的に見積もることでベロシティを水増しすることができます。チームがタスクに2時間かかる、または2ポイントの価値があるのではなく、4時間かかる、または4ポイントの価値があると言えば、ベロシティは良く見えます（ポイントインフレーションと呼ばれることもあります）。[ 10 ] [ 11 ]
ベロシティの2つ目の問題点は、品質、ユーザー目標との整合性、優先順位を考慮していないことです。ベロシティは、優れた設計、リファクタリング、コーディング標準、技術的負債を無視することで向上させることができます。品質に関係なく、機能をできるだけ早く完成させるだけでベロシティは向上します。同様に、ベロシティには、その作業のメリットに関係なく、完了した作業が含まれます。たとえば、誰も望んでいない、あるいは必要としていない機能を構築しても「完了した作業」としてカウントされ、使いやすさなどのユーザー目標から逸脱する作業単位を完了することは、望ましい方向とは逆の動きとなります。
速度に関する3つ目の問題点は、効率性やチームのパフォーマンスを測る指標として誤用されることが多い点です。速度は作業量を表す指標であり、効率性を表す指標ではありません。残業やチームメンバーの増員によって速度を上げることはできますが、これらは必ずしも効率性やパフォーマンスの向上につながるわけではありません。