機能するベロシティ、機能しないベロシティ
はじめに
こんにちは、「メタルは全てを解決する」です。ナビタイムジャパンでVPoEと経路探索の研究開発部門（以下、ルートグループ）の責任者を担当しています。
今回の記事では、その是非について議論が交わされることの多いベロシティについて扱っていきます。
ベロシティ
まず、ベロシティとは何なのか確認していきます。スティーブ・マコネルの「More Effective Agile」では以下のように紹介されています。
チームが各スプリントで取り組む作業の量は、ストーリーポイントを使って数える。各スプリントでチームがデリバリーできるストーリーポイントの数が、そのチームのベロシティになる。ベロシティはスプリントごとに計算され、平均ベロシティも計算される。
いくつかスプリントを重ねベロシティが安定してくると、様々な場面で活用することができます。平均ベロシティをもとに計画を立てられますし、平均ベロシティから大きく逸脱しているときにはチームに何か起きているということがすぐわかります。
なお、当社の標準開発ガイドラインであるNTJ Team Guidesではタスクをストーリーポイントで見積もり、ベロシティを計測し、それを計画に役立てることを推奨しています。
ベロシティ不要論
一方、ベロシティについては不要論が湧き出ることもあります。
上記の記事では、ベロシティを向上させることが目的化してしまい、そのために重要なビジネス指標を見失ってしまうといった問題点が指摘されています。ここはそのとおりで、当社のガイドライン中でもベロシティの向上を指標としてもつべきではないこと、ベロシティはチーム固有の数値なのでチーム間で大小を比較することに意味はないことを明記しています。
しかし、「ベロシティの向上を目指す」という誤用を回避しさえすればベロシティを有効活用できるかといえば、残念ながらそうではありません。社内においてもうまく機能させられているチームとそうでないチームがありました。
機能するベロシティ
まず、チームAにおける活用について紹介します。
長年ベロシティ計測を実施し、計画づくりやチームの異常検知に活用しているこのチームのベロシティ推移を以下に示します。
灰色がスプリント開始時点でのコミットメント、
緑色がスプリント終了時点での実際のベロシティ
概ねコミットメント通りのベロシティとなっていること、多少前後していますが安定していることがわかります。
注目したいのは真ん中のスプリントです。ここではコミットメントを大幅に割り込んだベロシティとなっています。他のスプリントが安定しているため「チームに何かがあった」ことが瞬時に判断でき、対処することができます。このときはスプリント期間中に終日の全社イベントがあり、その影響を考慮せずプランニングしていたのが課題だったということがわかりました。メンバーの不在による影響を考慮してプランニングしよう、ということを改めて再確認できました。（次スプリントからはまた持ち直していますね）
安定していること、コミットメント通りのベロシティが出ていること。この2つが満たされるとき、ベロシティはチームの状況をつぶさに伝えるシグナルになってくれます。また、安定しているがゆえに、スプリントプランニング時に過剰にスプリントバックログアイテムを積んでいないか検査する基準値にもなります。
機能しないベロシティ
つづいて、チームBのベロシティについて紹介します。
計画時点のコミットメントにばらつきがあり、ベロシティ推移についても波がある
このチームでは個々のスプリントバックログアイテムのストーリーポイントは見積もっているものの、ベロシティの計測やそこから洞察を得ることは実施していませんでした。
Jiraの機能を使うと、ストーリーポイントを入力していればベロシティ推移は簡単に表示することができます。その機能を使って可視化してみたのが上記のベロシティ推移です。
ここから読み取れることは「ベロシティが安定していない」ということのみ。安定していないから、コミットメントと実績に乖離があったときにそのスプリントで何かが起こったからなのか、そもそもコミットメントに無理があったのかの判断がつきません。
なぜチームBはベロシティ計測をしていないのか
ところで、チームBはなぜベロシティ計測をしていなかったのでしょうか。当社ではほとんどのチームでJiraを活用しており、このチームもそうでした。前述のとおり、Jiraを活用してればストーリーポイントを記入することで簡単にベロシティ推移を算出できます。そしてこのチームはストーリーポイントを記入していました。では、なぜベロシティ計測をしていなかったのでしょうか。
チームBにヒアリングしたところ「問い合わせ対応などでベロシティにばらつきがあり安定させることができないため、計測していない」ということがわかりました。
また、他にも「未着手のまま複数スプリントにまたがるスプリントバックログアイテムがある(のでベロシティが安定しない。だから計測しない)」といった課題がありました（これは次スプリントにアイテムを持ち越しやすいJiraを使っているから起こりやすい課題かもしれません）。
ベロシティが機能しない、というアラート
さあ、あらためてチームBの状況を整理してみましょう。
問い合わせ対応などでベロシティを安定させることが難しい
未着手のまま複数スプリントにまたがるスプリントバックログアイテムがある
よってベロシティが機能しない。なので測定しない
機能しないのであれば測定しないというのは理にかなっています。
一方で、なぜ機能しないのかを読み解いていくと、チームの仕事を安定させられない、今取り組むべき課題とその終了条件を明確に定義できていない(だから明確な終了がなくズルズル行ってしまう)、といった課題が浮き彫りになりました。
そう、ベロシティが機能しない、計測しても意味がない状態だという事実自体が、チームの開発プロセスに課題があることを指し示しているのです。
「機能していないベロシティ」から改善に向かう
このチームBはヒアリングを通して「ベロシティを機能させられないという状態そのものに課題がある」ということに気づきました。
問い合わせ対応についてはまだ最適解が見つかっていませんが、未着手スプリントバックログアイテムについてはDoDを定義する、細分化するといった解決アイデアが出てきています。
まだ改善策について話し合っている段階なので「これだけよくなったよ！」ということは本稿ではお伝えできないのですが、課題を認識することで前に進めそうな感触があります。
まとめ
今回は当社におけるベロシティの活用事例を2つ紹介しました。うまく活用できている例とそうでない例。そして、ベロシティを活用できないという状況は、チームのプロセスに課題があることを示していることがわかりました。
冒頭で述べたように、ベロシティ計測についてはそもそも不要論が出ていたりします。誤用につながるリスクはあるし、必ず計測しなければいけないというものでもありません。
しかし、ベロシティを計測しないではなく計測できない状況はプロセスに課題が内包されていることを示しています。もしベロシティが計測できないようでしたら、なぜ計測できないか検査してみましょう。そうすることで課題が浮き彫りになり、チームを前進させるきっかけにつながることでしょう。