アジャイルで利用されるベロシティの意味とは？開発での意味を解説

近年、社会構造やニーズが変化するスピードが早まり、システム開発においても柔軟かつ迅速な対応が求められるようになりました。

そのうえで開発手法もウォーターフォール型からアジャイル型へのシフトが注目されています。

しかし、アジャイル開発の手法を適切に取り入れられている企業は少なく、本コラムをお読みの方もアジャイル開発の導入に課題を抱えているのではないでしょうか。

本コラムでは、アジャイル開発における重要な判断指標となるベロシティに関して、概要から具体的な活用法や失敗例を踏まえてご紹介します。

アジャイル開発とはどのような手法なのか

アジャイル開発は、ビジネス価値を最大化するために、顧客に対してシステムを素早く届け、価値ある状態を継続的に提供するための開発手法です。

具体的にはタイムボックス化された開発業務を反復し、短いサイクルで顧客からのフィードバックを受けつつ、成果物の価値を確認していきます。

メリット

アジャイル開発の主なメリットは、次の3点です。

• 仕様変更に強い
• 開発がスピーディ
• 顧客満足度を高めやすい

アジャイル開発は従来のウォーターフォール開発と異なり、仕様を厳密に決めません。

そのため、顧客の要望に対して柔軟に応えられるうえに、開発工程を後戻りすることがなく、その際に発生するコストを削減できます。

また、開発途中での仕様変更に対応しやすい分、結果として短期開発が実現できます。

デメリット

アジャイル開発の主なデメリットは、次の2点です。

• 開発の方向性や届けるべき顧客価値を見失いやすい
• 全体的な進捗管理が難しい

アジャイル開発は顧客の要望を細かく聞き入れられる反面、機能ごとに開発を進めるため、目的やスケジュールなどの全体観が把握しづらいデメリットがあります。

また、作業を効率的に進めようとした結果、「1度決めたやり方を変えられない」「顧客要望を現場ベースで考えてしまう」という制限が生まれてしまうこともあります。

ここで重要なのは、アジャイル開発にとって作業効率化は手段であり、目的ではないということです。

どれだけ作業を効率的に進められたとしても、顧客に価値ある成果物を提供できなければ意味がありません。

絶えず変化するビジネス環境の中で、最適なビジネス解を柔軟かつ迅速に出し、顧客に継続的な価値を提供することがアジャイル開発の重要ポイントになります。

そのためには新しい手法を試すだけでなく、失敗を許容し、経験から学び取るためのマインドセットを心掛けましょう。

アジャイル開発の流れ

アジャイル開発の流れには、主に「リリース計画」「スプリント」という2つのポイントがあります。

リリース計画

システムの方針を固めるため、仕様や要求を取りまとめる工程です。

ウォーターフォール開発とは異なり、ここでの計画は絶対的なものではありません。

これはVUCA時代の変化の早さなどに対応できる柔軟さを持つためでもあり、開発の過程で仕様や要求が変更になることもあり得ます。

イテレーション（スプリント）

アジャイル開発では、「要件定義→設計→実装→テスト」を機能単位で進めていきます。

この短期間（1週間～4週間ほど）の開発サイクルをイテレーション（反復・繰り返し）と呼び、イテレーションの連続でプロダクトを完成させるのがアジャイル開発の特徴です。

イテレーションごとに成果物をリリースすることで、問題の早期発見や改善につなげられます。

アジャイル開発でのベロシティとは

アジャイル開発では、ストーリーポイント（SP）というシステムが提供する価値実装に必要な作業コストの見積り単位がありますが、これを開発チームでどのような計画で消化していくかを表す指標として、ベロシティが扱われます。

ベロシティの概要

ベロシティとは、開発チームが1回のイテレーション（スプリント）で完了したストーリーポイントの合計値です。

簡潔に表現するなら、開発チームの進行速度を数値化したものといえます。

タスクごとにポイントをつけ、チームの開発がどれほど進んでいるかを可視化することで、さまざまな要素を把握するための材料として役立ちます。

ベロシティの具体的な活用法

ベロシティによって把握できるポイントは、「イテレーションの参考値」「開発完了の時期推測」「開発チームの成長度」があります。

イテレーションの参考値

計画を立てる際に、「計画通りに進むかどうか」を判断する材料としてベロシティが使われます。

過去のベロシティと比較して、「過度な合計値になっていないか」「バランスは適切か」を見て計画の妥当性を判断し、問題があれば修正を施します。

開発完了の時期推測

1回のイテレーションに対するベロシティが分かれば、「全体のストーリーポイント ÷ ベロシティ」で、開発完了に必要なイテレーション数が導き出せます。

仮にプロジェクトのストーリーポイントが100で、開発チームのベロシティを20とした場合、5回のイテレーションが必要という計算です。

1回のイテレーションが1週間であれば、5週間で開発完了の見込みという数値的根拠を出せます。

開発チームの成長度

1回のイテレーションにおける作業実績値がベロシティのため、ベロシティが安定、あるいは上昇傾向にある場合は、開発チームが成長している根拠になり得ます。

ベロシティの計測を継続することで、開発チームが今どういう状態なのかを可視化でき、チームメンバーが自律的に成長していくための材料にもなるでしょう。

アジャイル開発でのベロシティによる失敗例2選

「イテレーションの参考値」「開発完了の時期推測」「開発チームの成長度」など、幅広い活用ができるベロシティですが、考え方を誤ると十分な効果を得ることができません。

ここではベロシティにおける失敗の代表として、2つの例をご紹介します。

直近のイテレーションだけで判断する

ベロシティは、「稼働日」「チームメンバーの出勤率」「見積もりの甘さ」などによる影響を受けます。

直近のイテレーションだけで判断してしまうと、直近よりも進捗が悪い、あるいは同じ失敗を繰り返す可能性が出てきます。

そのため、イテレーションは複数のデータを参照し、平均値を取ったうえで判断したほうが良いでしょう。

これによって、環境起因によるベロシティの波を一定抑制できます。

ベロシティの上昇が目的化する

ベロシティが数値で表現されるため、どうしても開発チームのベロシティを上げようとする、あるいは他チームのベロシティと比較して競争するという出来事が起きがちです。

ベロシティを上げていくこと自体が悪いことではありません。

問題なのは、ベロシティを上げることが目的化すると、結果的に残業が増えるだけでなく、チームメンバーに過度なプレッシャーを与え、チーム間の関係性が悪化する原因になり得る点です。

ベロシティの本来の目的は、1回のイテレーションにおける業務を安定させ、予測可能性を高めることにあります。

そのため、ベロシティの数値にばらつきが生まれると、計画通りに進むかすら判断できません。

ベロシティはあくまでリスクを取り除き、チームメンバーが安定したペースで作業できるための計画に活用する数値として捉えましょう。

ベロシティの数値が安定軌道に乗り、開発チームが成熟していくと、特定プロセスを変更した際に変化した数値から、プロセス最適化の糸口を見出すこともできるようになります。

ベロシティを安定させ、アジャイル開発の精度を上げていくには

アジャイル開発で顧客とWin-Winな関係性を築きつつ、効率的かつ効果的に開発を進めていくには、イテレーションやベロシティを活用した計画性が重要になります。

しかし、ベロシティは「直近のイテレーションだけで判断する」「ベロシティの上昇が目的化する」などの誤った考え方が定着しやすいため、適切なファシリテーションが欠かせません。

特にチーム立ち上げ当初は、関係構築やプロセス最適化に追われるため、ベロシティは安定しにくいです。

また、アジャイル開発には代表的なスクラムの他にも複数の手法があり、企業やプロジェクト規模によって適した手法が異なるため、知識や経験がないと仮にアジャイル開発を取り入れても上手に活用するのは難しいでしょう。

人材面では開発チームに属するエンジニアの他に、社内外のステークホルダーとの調整を行うプロジェクトオーナーや、チーム全体が自律的に動けるように指揮するスクラムマスターなど、幅広い人材が必要となります。

エンジニア自体も専門性に特化したメンバーより、多様な領域をマルチで担当できる人材が重要視されるため、採用難易度は従来のエンジニアより高いといえるでしょう。

そのような多方面でのスキルを持つ人材を求めるうえで、おすすめしたいのがHiPro TechにおけるITフリーランサーの活用です。

当サービスでは、特定領域に強いエンジニアだけでなく、幅広いプロジェクトや業界での実績を持つITフリーランサーが登録しています。

プロジェクト単位での短期活用もできるため、必要なときに必要なノウハウを取り入れやすいサービスです。

VUCA時代の柔軟な対応力を身に付けるために、ぜひ当サービスをご検討ください。