ベロシティを捨てた理由

scrum開発をはじめたときは教科書としていたカイゼンジャーニーにならってベロシティを導入していましたが、今はベロシティはやめています。広く知られているベロシティをなぜ捨てたのかについて書いてみようと思います。

ベロシティとは

ベロシティはその名の通り速さを表します。より具体的にはタスクやバックログの消化速度です。また、ベロシティは結果ではなく予測として使用されます。つまりは見積もりとほぼ同じ意味になります。よくあるソフトウェアの見積もりは日数（人日/人月）で見積もられますが、ベロシティはもっと曖昧で相対的なものになります。なので、ベロシティの1ptは1人日ではありません。
「フィボナッチ数でプランニングポーカーをして素早く決める」あたりがキーワードになると思います。

ベロシティを導入した理由

まずはチームとしてベロシティを導入した理由について書いていこうと思います。
もちろん、教科書としていたカイゼンジャーニーに書かれていたからという理由が大きいですが、ベロシティはチームにとって何が嬉しいのか、について考えてから導入しました。

一番嬉しいと思ったのは、ベロシティは計測可能な数値であることです。新しいことをはじめるにあたって計測可能な数値があるということは正しさの指標にできることが多いです。特にscrum開発ではスプリントという短い期間で実験と考察を繰り返しプロセスを改善していくことが求められます。改善しているかという問いに対してベロシティが上がっているから改善できていると言えるのはすごく嬉しいことだと思いました。
これはモチベーションにも繋がります。スプリントが進むにつれてベロシティが成長曲線を描いてくれればモチベーションアップにつながると考えました。やはり成長が見えるというのは嬉しいことです。

また、マネジメント観点でもベロシティは有効であると考えました。各スプリントで消化したベロシティから未来が予測できるかもしれないからです。各スプリントでどれだけベロシティを消化できたかと残りのバックログがどの程度のベロシティになっているかを見れば、残りのバックログを消化するのにおおよそいくつのスプリントが必要かが予想できます。

まとめると、

ベロシティは計測可能な数値であること
モチベーションアップに繋がりそうなこと
未来の予測に使えそうなこと

が嬉しいと思いベロシティを導入しました。

ベロシティの問題

ベロシティを運用してみていくつかの問題が出て来ました。
ベロシティを見直すきっかけになった事象はプランニングに時間がかかることです。ベロシティを決めるときに各メンバの前提や想定している完了条件、やり方、スキルの差などを埋める話し合いに発展してしまい、結果的にベロシティを決めるのに時間がかかるようになってしまいました。各メンバの考えの差に気付けるのはいいことなのですが、詳細まで話すことになってしまい、時間と作業の自由度を無くしてしまう形になってしまいました。

次に、ベロシティのポイントが安定しないことに気づいたことです。まず、見積もりといえば人日として育った人が多いので、1ptと1人日を切り離すのに苦労しました。その後、ある程度は相対的にベロシティを決めれるようになって来たのですが、どうしても作業内容でポイントをつけてしまいます。基準となるバックログはこんな作業があるから、このぐらいのポイントになっていて、今決めたいのはこういう作業があってこのぐらいかかるからこのポイント。というように考えていることが多かったです。
また、基準となるバックログをうまく固定できないことにも気付きました。昔のバックログをずっと使うのは記憶の最適化が発生し、基準がぶれていくことがわかったので、毎スプリントで基準となるバックログを決めて相対的にポイントをつけていました。

ここでチームは気がつきました。基準となるバックログが固定できないということは、ベロシティの1ptがスプリントごとに異なるということ。そうなると、ベロシティの計測では成長曲線は現れず、ほぼ一定の値をキープすることになるので、モチベーションアップにはつながらず、未来の予測にも使えないのではないか、つまりはベロシティは計測可能な数値ではないのではないかと考えるようになりました。

まずはプランニングに時間がかかることに着目しました。各メンバの認識を合わせるのは良いことで、時間をかけてもいいのではないかと思いますし、スキルや文化の醸成で時間が掛からなくなっていくと思いました。ここでの問題は、認識合わせをした結果、ベロシティのポイントという曖昧な数値が出てくるだけということです。すごくもったいないと思いました。
話し合いの内容は作業内容についてある程度詳細に話をしているのでタスクに分割できるはずですし、プランニングなのでタスクは登場しています。なので、タスクの数をベロシティの代わりに使えないかと考えました。タスクの粒度をある程度揃え、タスクの消化度を計測すれば良いのではないかと考えました。少なくともベロシティにこだわるよりタスクにこだわったほうが良いのではないかと思いました。

そしてベロシティを捨てました。

それからどうした

今もベロシティは捨てたままで開発を続けています。むしろ計測をあまり重要視せず、実感重視になって来ている印象です。数値で成長を見るのではなく、ふりかえりで成長を実感するような感じです。また別の記事として書きたいと思っていますが、タスクの作成がすごく難しく色々と試行錯誤した結果、今のような形になっているようにも感じます。

そもそも、ベロシティはスクラムガイドには登場しない仕組みです。scrum開発には必要な概念ではないので、合わないと思ったら捨ててみるのも良いかもしれません。確かに未来の予測ができなくなるかもしれませんが、アジャイルは未来を予測できない物に対する開発手法なので、相容れない部分が多少なりあるはずです。どの程度未来を予測する必要があるのかによると思います。

個人的な意見ですが、ベロシティはもう少し役割を変えるとより良いものになるのではないかと思います。ベロシティをフィボナッチ数で設定するのはなぜかというと、ざっくりとしたポイントをつけたいからです。では見積もりがざっくりとするのはどんなときか、と考えると内容が曖昧なときではないでしょうか。内容が曖昧であればあるほど調査や検討に時間が必要で、実現できるかもわからなくなります。この曖昧さにポイントをつけるのはすごく良いことだと思います。なので、ベロシティは名前を変えて、曖昧さを表すポイントとして見積もり的な概念は捨てると面白いかもなと思っています。