規模を見積り、ベロシティを計測し、期間を予想する
アジャイルな見積りと計画づくりの鉄板の方程式！！
前回は、「ソフトウェア見積り人月の暗黙知を解き明かす」から、ターゲット、見積り、コミットメントを混ぜるなについてポイントを絞って解説しました。今回は「アジャイルな見積りと計画づくり」より、規模を見積りベロシティを計測して期間を予想するにポイントを絞って解説します。
見積りと計画づくりに対する課題感
ソフトウェアウェア開発を行う場合、ある明文化したビジネス目標（=ターゲット）を達成するために、あるスコープセットがどれぐらいの期間で完成できるのかを見積り（予測）し、完成させることをコミット（=約束）する活動が欠かせません。
ただし、次のような課題感にしばしば出くわします。
- 不確実性の高い状況下では見積りは外れやすい。予期せぬことが起こること前提に、不確実性コーンと上手に付き合っていく必要がある
- 見積りの予想が発言力の高い特定の人の意見に引っ張られ、チーム全体としての能力の実態と合わなくなってしまう
- 機能Aを完成させるのに私のm日とあなたのn日のギャップで不毛な論争に発展し、時間をかけても意見が収束しない
- 小さいタスクの下から積み上げの時間見積りは、多大な労力の割に見積りの正確さが増すことはあまり期待できない。優先順の低い項目で、後からやらなくなった場合、労力の無駄にもなる。
- アジャイルな開発の場合、顧客や市場ニーズに合わせて何をつくるかについて柔軟に計画を変更できることが求められるが、見積り作業自体が重厚だと計画変更が難しくなる。
- 依頼する側と作る側で見積り（完了予想）の活動に対して、互いに疑心暗鬼になり信頼関係が壊れていく。
- etc..
そこで、アジャイルな見積りと計画づくりでは、上の課題に対して、「規模を見積り、ベロシティを計測し、期間を予想する」の仕組みを通じて、取り組んでいます。
1. 規模を見積る
見積りの際は、特定の個人の意見にひっぱられてしまうアンカリングを避けるように司会進行します。また、絶対量の時間見積りでは、個人のスキル差から時間見積りのチームとしての見解が収束しない場合も、相対的な作業量や複雑さといった規模の観点では、素早く収束しやすくなります。
もちろん、規模を見積ってあるスコープセットのポイント総量がおおよそ300Pointとわかっても、このままでは、いつまでに完成できそうかの期間を見極めることはできません。期間を予測するためには、次にベロシティを計測するが必要があります。
規模見積りをする方法として、プランニングポーカーやTシャツサイズを使ったアフィニティ見積りが有名ですが、詳細説明は別の機会にします。
2. ベロシティを計測する
実際に１スプリント当たりにチームがどれぐらいのペースで仕事を終わらせることができるのか把握するために、実績のベロシティを計測し続けます。計測しつづけることで、チームのペースが仮に30point/sprintだとわかっとしましょう。チームの実績ベロシティがわかれば、あるスコープセットの総量（仮：300point）がいつまでに完成できそうかが予想できるようになります。事実ペース
3. 完了する期間を予想する
規模見積りの総量と（300point）と実績のベロシティ(30point/sprint)がわかれば、割り算の計算で完了する期間が予想ができます。
300(point) ÷ 30(point/sprint) = 10(sprint)
この計算は、みなさんも小学生のときに似た計算をしたことがあるでしょう。「目的地までの距離が 300km 時速 30km/hの場合、何時間で到着することができるでしょうか？」
300(km) ÷ 30(km/h) = 10(h)
おなじ発想ですね。
もちろん、不確実性の高い状況下では10sprintぴったりで終了すると予想することは難しいでしょう。不確実性を考慮して、10 +- 1sprint など幅を持たせて完了を予測することになります。
そのほか、スコープを絞ってもっと早くリリースし、顧客の反応をみながら軌道修正するアジャイルらしい作戦に変更することもあります。
リリースバーンダウンチャート等を使い、着地の予報を更新しつづけ、早期に課題発見と対処に取り組む
ベロシティを計測し、リリースバーンダウンチャートを更新しつづければ、チームが何かしらの障害物に出会いペースダウンしている場合もあるでしょう。
- エースのエンジニアが抜けてしまったが、既存メンバーではゴール達成に必要なスキルセットが不足している
- 兼務で共同作業の時間帯があわず、コラボレーションによる早期の問題発見と対処ができなくなった
- なんらかの理由により、Readyの定義を満たすプロダクトバックアイテムが準備が滞ってきた。
- 技術的負債によって新機能追加が難しくなった。
- etc
リリースバーンダウンチャートによる図だけでは、何の障害物によってペースダウンの傾向が起きているかわかりませんが、早期にペースダウンの事象を発見すれば、原因を特定し持続可能なペースで着実に成果を出しつづけ、着地できるようにチームで改善に取り組みます。
