ベロシティを"安定させる" の代わりに "制御する" といいたい

典型的なスクラムではない開発プロセスでベロシティの安定化に取り組んで、「安定させることそのもの」に集中するのはそれほど意味がないな、と感じたので言語化した。

自分が経験している開発プロセスについて

フレームワーク

タイムボックスが変動するスクラムで開発している。具体的には 新規事業×生成 AI の不確実性を乗り越える開発プロセス - Speaker Deck を参照。

ベロシティの計測方法

1 週間ごとに完了した PBI の pt の合計をベロシティとしている。つまり、ベロシティの計測の頻度とタイムボックスの期間は必ずしも一致しない。

「安定」についての誤解

「安定させる」は簡単そうに見える。ベロシティを上げるわけでもないので、今まで通り毎日決められた分の仕事をすれば良いだけである。だが、実際はそんな簡単な話ではないと思い始めている。

例えるなら、「散らかった部屋を片付ける・散らからないように部屋を使う」と「部屋を散らかすイタズラ妖精がいる中、なんとか生活できる部屋に保つ」のうち、「ベロシティを安定させる」ことは後者に近いと思っている。チームにはベロシティを不安定にさせる力が働くため、安定した状態を続けることは非常に難しい。

完璧にベロシティが安定したチームは存在しない

ベロシティが完璧に安定しているチームがいるとする。

そのチームは、

• 正しく見積もりできる

  • メンバーが正しく見積もれるスキルを持っている

  • PBI の不確実性が低い

• 人員が十分である

  • 誰かが休んでもカバーできる

• メンバーの異動が少ない

• メンバーが仕事に集中できる状態である

  • 差し込みやチーム外からやってくる仕事が少ない

といったことができるのだと思う。

仮に、自分が複数のチームを俯瞰する立場で、このような素晴らしいチームがいたとしたら、そのチームメンバーには以下のことをお願いしたくなる。

• 人手が足りないチームに異動してもらう

• 新人を受け入れて育成してもらう

• 不確実性が高い（リスク高め）なことをやってもらう

余裕があるなら、余裕がないチームを助けて欲しいし、採用とか評価に関する仕事もやってもらいたいし、リスク（不確実性）を十分に低くできるならもっと難しいことをして欲しい。

仕事が早く終わったらその分仕事が増えるのと同じで、安定に近づくほどリスクを取ることが期待されるわけである。これがベロシティを不安定にさせる力である。

リスクのないプロジェクトには手をつけるな。

（熊とワルツを - リスクを愉しむプロジェクト管理）

もちろん、リスクがなければ良いということではない。リターンを得るためにはリスクを負わなければならない。

「完璧にベロシティが安定したチーム」は、チームが受け入れられるリスクの容量に対し、実際に負っているリスクが低い状態ともいえる。このように、安定しているからといってそれが必ずしも良いとは限らない。

ベロシティという数値に集中しすぎない

ベロシティが数値として見えることと「安定」という言葉から、ベロシティの分散を小さくするというわかりやすい目標を目指してしまうことがある。

ベロシティを安定させることは難しく、安定させたからといって価値が生まれるわけではない。数値を調整して安定を目指すよりも、開発を進めた方が良い。

ベロシティを制御する

「ベロシティの安定」という言葉によって、簡単に実現できるような印象を与えたり、数値の調整を目的にしてしまうことがあると思っている。

ベロシティの増減に一喜一憂していても、チームが受け入れられるリスクは増えない。ベロシティで重要なのは数値の増減ではなく、そのベロシティが意図通りかどうか（説明が可能であるかどうか）であると考えている。

例えば、差し込みでタスクをやらなければならないことが予めわかっている場合、ベロシティが低くなることは予想できる。一方で、予想よりもベロシティが下がっており、その理由がまったくわからないのであれば、それは問題である。

リスクをうまく扱って開発を進めるには、ベロシティの「安定」よりも「制御」のような、制御下にある・コントロールできるといった意味の言葉のほうが適切に感じている。