# ベロシティ ## 定義 ベロシティ(velocity)とは、チームが1回のイテレーションで完了させたユーザーストーリーの、ストーリーポイントまたは理想日の合計値である。[[ストーリーポイント]]や[[理想日]]で見積もった規模の合計をベロシティで割ることで、プロジェクトに要する期間が導出される。すなわちベロシティは、単位を持たない相対値(規模)を実際の期間へ変換する媒介変数として機能する。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 4 ストーリーポイントによる規模の見積り]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] 導入) リリースプランニングでチームのベロシティを見積もる手法には、(1)過去の実績値を使う、(2)実際に1イテレーションやってみる、(3)予想する、の3つがある。どの手法にもふさわしい局面があるが、いずれを採用してもベロシティの見積り結果は単一の値ではなく幅で表現すべきである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] 導入) ## プロジェクト開始時点での見積り手法 ### 1. 過去の実績値を使う 過去の実績値は、現在のプロジェクトとチームが以前とまったく変わっていない場合に最大の価値を発揮する。採用前に、技術・業務分野・チーム・プロダクトオーナー・ツール・作業環境・見積り担当者が同じかを確認すべきであり、1つでも「いいえ」があるなら採用を考え直すか、幅を大きく取るべきである。幅の算出には、直前のリリースでのチームの平均ベロシティに、不確実性コーンが示す60%〜160%という係数を掛ける方法が使われる(例: 平均15ポイント→幅9〜24ポイント)。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1) ### 2. 実際に1イテレーションやってみる ベロシティを知る最もよい方法は実際に測ることであり、著者はこれを最善の選択肢とする。1イテレーションだけ実施した場合は測定値に0.6〜1.6を掛けて幅を作る。3イテレーション以上実施できるなら、測定値の最小・最大をそのまま幅として採用するか、不確実性コーンの段階を実施イテレーション数だけ進めた幅(表16.1)を採用する。ただし著者は、3回以上イテレーションを実施済みのチームには不確実性コーンを適用しない。この方式に従うと、6回実施したチームは不確実性コーンの右端にいることになり、ベロシティがすでに正確かつ精密でプロジェクト終了まで変わらないという含意になってしまうためである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §2) ### 3. 予想する 過去の実績値もイテレーション実績も使えない場合(開始が1年先のプロジェクトなど)、ベロシティは予想に頼らざるをえない。手順は、(1)各メンバーの1日あたり作業可能時間を見積もる、(2)人数とイテレーション日数を掛けて1イテレーションあたりの作業可能時間を求める、(3)ストーリーをランダムに選んでタスクへ分解することをその上限まで繰り返す、(4)得られた見積りに幅を持たせる、の4段階である。この手順はイテレーションプランニングとほぼ同じであり、著者が最善とする実測(手法2)ができない場合の代替として位置づけられる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §3) 著者が推奨する優先順位は、(1)イテレーションを1回でも実施できるならそれを使う、(2)同じチームメンバーが関わった関連プロジェクトの実績値を使う、(3)作業可能時間からの予想を使う、の順である。どの手法で見積もったにせよ、ベロシティの実績値が得られ次第そちらへ切り替えるべきである。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §5) ## 実施イテレーション数による不確実性の低減 不確実性コーン(1章で導入、図16.1として16章で再掲)は、プロジェクトの進行にともないスケジュール見積りの不確実性が狭まっていく図式であり、実施したイテレーション数が増えるほどベロシティの見積り幅も狭まっていく。実施イテレーション数と幅の係数の関係は表16.1にまとめられている。 | 実施したイテレーション数 | 下限の係数 | 上限の係数 | |---|---|---| | 1 | 0.60 | 1.60 | | 2 | 0.80 | 1.25 | | 3 | 0.85 | 1.15 | | 4以上 | 0.90 | 1.10 | ![[wiki/sources/_attachments/agile-estimating-and-planning-ja/ch16-tbl16.1-velocity-multipliers.png]] (表16.1 実施したイテレーション数に応じたベロシティ見積り係数。Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §2, 表16.1) 例えば、イテレーションを3回実施していて平均ベロシティが20ポイントなら、見積り幅は85%〜115%(17〜23ポイント)になる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §2) ## 作業可能時間からの算出 「予想する」手法(上記手法3)では、ベロシティをメンバーの作業可能時間から具体的に積み上げる。SwimStatsの例では、4名のメンバーが1日6時間プロジェクトに従事できると見積もり、10日のイテレーションで合計240時間の作業可能時間を算出した。この作業可能時間の上限に達するまでストーリーをタスクに分解した結果が表16.2であり、合計221時間・25ポイント分のストーリーがチームのコミット対象となり、ベロシティの見積りは25ポイント(幅を持たせると15〜40ポイント)となった。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §3-2, §3-3, §3-4, 表16.2) プロジェクトを兼務するメンバーが多いチームでは、作業可能時間を1つの値に絞らず、メンバーごとの表(表16.3)を作るとよい。SwimStatsの例では、専属メンバー(1日6時間)・管理職業務も抱えるメンバー(1日4時間)・複数プロジェクトを兼務しマルチタスク化の影響を受けるメンバー(1日2時間)が混在し、4名合計で1イテレーションあたり180時間の作業可能時間となった。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §4, 表16.3) ## 幅で扱うことの意味 ベロシティの見積りを単一の値ではなく幅で表現することは、本章全体を貫く原則である。「20ポイントです」と断言するのではなく「15ポイントから24ポイントです」のように述べることで、見積りの不確実性そのものを相手に伝達できる。著者は幅の算出に一貫して60%〜160%(または表16.1の係数)という不確実性コーン由来の係数を用いており、これは章冒頭の引用「正確に間違っているよりも、だいたい正しいほうがよい」(ジョン・メイナード・ケインズ)を体現する運用方法である。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] 導入, §1) ## 横断的知見 - [[ストーリーポイント]]は「単位を持たない相対値」であり値そのものに意味がないのに対し、[[理想日]]は「理想時間」という具体的な時間の単位を保持する。両者はどちらもベロシティで割ることで期間を導出するという同一のロジックを共有するが、16章の「予想する」手法(§3-3)は、この規模の単位がストーリーポイントであっても理想日であっても、「チーム全体でこなせると判断したストーリーの規模の合計値」がそのままベロシティの見積りになると述べるのみで、単位の違いによる算出方法の差を設けていない。ベロシティという媒介変数を挟むことで、規模の単位が抽象的(ストーリーポイント)か具体的(理想日)かという4章・5章の対比が、期間換算の段階では意識する必要のない差異に還元されることが、16章を読んで初めて見える。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 4 ストーリーポイントによる規模の見積り]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 5 理想日による見積り]] §2, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §3-3) - [[理想日]]の未解決の問いには「1理想日を現実時間に換算する具体的な比率が5章では数値化されていない」という点が残されていた。16章の「予想する」手法(§3-1〜§3-3)は、この換算比率を固定値として与える代わりに、メンバーごとの1日あたり作業可能時間(4〜6時間という実証的な目安)を積み上げてイテレーション単位の作業可能時間を実測し、そこにタスクの見積り時間を突き合わせるという具体的な手続きで代替している。つまり16章は、5章が数値化を避けた理想時間と現実時間の関係を、固定比率ではなく「都度算出する作業可能時間」というかたちで運用可能にしている。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 5 理想日による見積り]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §3-1, §3-2) - 16章§1の「過去の実績値が使えるか」の判断基準の1つは「チームは同じか？」だが、23章のケーススタディはこの前提がプロジェクト内でも短期間に崩れうることを示す。第2イテレーションでは、未完了ストーリーを含めずベロシティをオール・オア・ナッシングで算出する原則が採られ、さらにローズがテスト支援からアート専任へ移るといったチーム内の役割配分の変化によって、ベロシティは前回の平均と一致しない形で変動した。16章が「チームは同じか？」を過去実績流用の判断基準として挙げていたのは、23章の実例のようにプロジェクト内の1イテレーションの間隔でも成立しなくなりうる、比較的脆い前提であることがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §6) - 16章はベロシティを「チームが1イテレーションで完了させたストーリーの規模の合計」と定義するが、何をもって「完了」とみなすかの判定基準までは示さない。19章「リリース計画のモニタリング」はモニタリング局面での運用ルールとしてこれを補う: ベロシティに加算できるのはイテレーション終了時点で完了しているストーリーのポイントだけとするオール・オア・ナッシングの原則であり、「完了」とはリファクタリング済みでレポジトリにチェックインされ、コーディング規約に沿い、すべてのテストケースが成功している状態を指す、という具体的な条件を伴う。16章が扱うのは見積り段階の(幅で表現される)ベロシティであるのに対し、19章が扱うのは実測されたベロシティであり、両者を合わせて読むと「ベロシティ」という1語が計画段階では予測の対象、モニタリング段階では厳密な測定手続きの対象という異なる役割を担うことがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1〜§3, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §1) - 16章は「実測値が得られ次第そちらへ切り替えるべき」(§5)と推奨するのみで、切り替えた後の実測ベロシティをどう活用するかは述べない。19章はこれを、実測ベロシティによる残ポイントの減少ペースを[[バーンダウンチャート]]として可視化し、スコープの変化と切り分けて追跡する手続きとして与える。23章のケーススタディ(第2イテレーションで未完了ストーリーを除外しベロシティをオール・オア・ナッシングで16ポイントと確定し、残116ポイントを16で割って8イテレーションの見立てを更新した場面)は、16章の「実測値への切り替え」という推奨と19章のオール・オア・ナッシング原則が、実際のプロジェクトでは切り離せない一体の手続きとして運用されることを示している。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §5, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 19 リリース計画のモニタリング]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] §6) - 16章はベロシティ自体の不確実性を、実施イテレーション数に応じて狭まる幅(表16.1の係数)として表現するのに対し、17章「不確実性に備えるバッファの計画」はストーリーポイントの合計側に安全余裕(スケジュールバッファ)を積み増すことで不確実性に備える。両者は「ポイント合計 ÷ ベロシティ = 必要イテレーション数」という同一の計算式の分子・分母それぞれに働きかける独立した不確実性の発生源である。17章の例(表17.2の6ストーリー、ベロシティ9ポイント/イテレーション)では、バッファなしの50%見積り合計17ポイントなら2イテレーションで完了できそうに見えるが、スケジュールバッファ9を加えた26ポイントでは必要イテレーション数が3に増える。この例ではベロシティは固定値として扱われており、16章が扱うベロシティ側の幅(例えば9ポイントではなく7〜11ポイントの幅がある場合)まで同時に考慮した必要イテレーション数の算出方法は、16章・17章のいずれにも明示されていない。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §2, 表16.1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 17 不確実性に備えるバッファの計画]] §2-2) - 16章はベロシティを終始「チーム」の単位で定義し(過去の実績値・実測・予想のいずれの手法も、チーム全体でこなせるストーリーの規模の合計を求めている)、個人単位のベロシティという可能性には触れない。20章「イテレーション計画のモニタリング」はこの前提を暗黙のままにせず、個人単位でベロシティを測定・トラッキングしてはならないと明示的に禁止する。理由は2つ示される: (1) 個人のベロシティを公表すると、チームメンバーは自分のストーリーを終わらせることと他のメンバーを手伝うことのどちらかを選ぶ場面でチーム全体の利益に反する行動を取りやすくなる、(2) そもそもユーザーストーリーは複数の役割(UIデザイナ・プログラマ・DBエンジニア・テスト担当者)の協働なしには完了できないように書くべきであり、正しく書かれていれば個人のベロシティは原理的に計算不能になる。16章がベロシティをチーム単位の指標として無条件に定義していたのは、20章を読むと単なる用語上の省略ではなく、ストーリーの書き方そのものによって個人単位の測定を構造的に不可能にするという設計意図の帰結だとわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1〜§3, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] §4) - 16章はプロジェクト開始前の見積り局面で、単一の平均ベロシティに60%〜160%(または表16.1の係数)という一律の掛け率を適用して幅を作る(「幅で扱うことの意味」節)。21章「計画とコミュニケーション」はプロジェクト進行中の伝達局面で、実測済みのベロシティ履歴(図21.2: 過去8イテレーションの実績15, 17, 18, 20, 12, 20, 15, 19ポイント)から直近・過去8イテレーション平均・ワースト3イテレーション平均という3つの代表値を抽出し、それぞれに残イテレーション数を掛けて幅を作る(表21.1: 14×5=70、17×5=85、19×5=95)。同じ「ベロシティを幅で扱う」という原則を共有しながら、16章の幅は理論上の掛け率に基づき、21章の幅はチーム固有の実測データの分布に基づいており、プロジェクトが進むにつれて幅の作り方が理論的な係数から実測の分布へ切り替わっていくことがわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1, 導入, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 21 計画とコミュニケーション]] §2) - 16章は過去の実績値を使う手法(§1)で「チームが変わっていなければ過去の平均は最も価値を発揮する」と述べ、過去の傾向が将来にも続くことを暗に前提とする。21章はこれと対照的に、実測データ(図21.2)に傾向線を引くことも、傾向をもとに「次はもっと出せる」と楽観視することも明確に避けるべきだとし、ベロシティが低下する場面ではその原因を探して取り除くべきだと述べる。16章がチーム同一性という条件つきで過去の値の外挿を許容するのに対し、21章はイテレーションを重ねて実測データが蓄積した後ですら外挿(傾向線)を避けており、過去のベロシティをどこまで将来予測に使ってよいかという許容度は、プロジェクト開始前(16章)より実測後の伝達局面(21章)のほうが慎重になっていることが両章を合わせて読むとわかる。(Source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] §1, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 21 計画とコミュニケーション]] §2) ## 未解決の問い - 実施済みイテレーション数が4回以上になった後、ベロシティの見積り幅をいつ・どう更新し続けるかは本章では触れられていない。19章はオール・オア・ナッシングの原則とバーンダウンチャートによる追跡は示すが、見積り幅そのものの再算出方法には触れておらず、20章「イテレーション計画のモニタリング」の担当範囲も残る。 - 兼務メンバーの作業可能時間(表16.3)が途中で変化した場合、ベロシティの幅をどう再算出すべきかは示されていない。 - 60%〜160%(または表16.1の係数)という幅の係数は、ストーリーポイントで見積もった場合と理想日で見積もった場合とで同じように適用してよいのか、16章では単位の違いによる調整は明示されていない。 - 「予想する」手法(§3)で得たベロシティの見積りと、実イテレーション開始後の実測値がどれだけ・どのように乖離しうるかの検証は16章に無い。 ## 関連 - 概念: [[ストーリーポイント]](規模の見積り単位。ベロシティで割ることで期間を導出) / [[理想日]](もう1つの規模の見積り単位) / [[リリース計画づくり]](ベロシティを使って総作業量の上限を決める) / [[イテレーション計画づくり]](ベロシティ駆動プランニングで使う指標) / [[バーンダウンチャート]](ベロシティを使って残作業から完了時期を推定) / [[計画のコミュニケーション]](ベロシティを幅で経営層に伝える手続き) / [[タスクボード]] - 実体: [[SwimStats]](ベロシティ見積りの具体例として登場) - source: [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 16 ベロシティの見積り]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 4 ストーリーポイントによる規模の見積り]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 5 理想日による見積り]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 23 ケーススタディ ボムシェルタースタジオ]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 20 イテレーション計画のモニタリング]] / [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 21 計画とコミュニケーション]] - 書籍: [[wiki/entities/アジャイルな見積りと計画づくり|アジャイルな見積りと計画づくり]] ## 出典 - Mike Cohn 著, 安井力・角谷信太郎 監訳, 『アジャイルな見積りと計画づくり』, マイナビ, 2009, 16章(主典拠)、4章・5章・23章・20章・21章(横断的知見の突き合わせに使用)。