SODA Engineering Blog
🏂

やはりベロシティは安定を目指すべきだった

2023/07/04に公開

はじめに

「ベロシティは安定すべき」とはよく聞くし、それが一番難しいともよく聞く。
そして「そもそもなぜベロシティが安定していたほうがいいのか」もよく議論されている。

本記事では特に目新しい議論はないが、自分の中で「なぜベロシティが安定しているべきなのか」が納得できたので、自分の理解を整理するために言語化しておく。

前提

  • ソフトウェアエンジニアやプロダクトマネージャー、デザイナーなどが中心となってソフトウェアプロダクトを開発する組織である
  • ToC領域に展開しているなど不確実性の高い領域で事業成長を目指すプロダクトを開発している
  • プロダクトの成長が事業の成長、会社の成長、会社のビジョンの実現などに寄与する

あたりが前提である。

事業成長が第一

会社が成長していくためにも、会社のビジョンを実現するにも、会社が持つ事業が成長することが最も重要である。
ソフトウェアエンジニアやプロダクトマネージャー、デザイナーなどが協力してプロダクト開発を進める大きな理由は、プロダクトを伸ばし、事業を成長させ、会社を大きくしたり、ビジョンを実現したいからである。

市場変化は予想できない

ただ、不確実性の高い事業領域では少し先の未来しか予想できない。
今すぐ作れば価値を生み出すプロダクト施策も、数カ月後に作るとまったく価値がないことなど往々にして発生する。

そのような事業領域では、可能な限り短い期間で仮説検証を繰り返し不確実性を減らしていくことが重要で、そのためには最小の価値単位に施策を分解し、見積り、優先度順に並べることを継続的に行う必要がある。

参考までに、スクラムではそのような活動は「リファインメント」と呼ばれている。

スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。

『スクラムガイド』Ken Schwaber, Jeff Sutherland (2020)

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

イテレーションの予測精度が重要

そのような不確実性の高い事業領域では「どのような価値をいつまでに生み出せるか」が鍵を握る。
優先度順に並べられた施策は最小単位に分解されているのもあり、開発スケジュールの予測精度を向上させるため、スケジュールを作る際に用いる期間の単位を1週間や2週間などと出来るだけ小さくすることが多い。
そのような開発期間の最小単位をイテレーションと呼ぶ(スクラムでは「スプリント」と呼ばれている)。

そして、当たり前だが、「どのような価値をいつまでに生み出せるか」を正確に予測するにはイテレーションにおける開発スケジュールの予測精度が重要になってくる。

ベロシティの安定は未来予測精度の安定

その「イテレーションにおける開発スケジュールの予測精度」を安定させるためには、ベロシティなるものを安定させることが近道になる。

ベロシティとは、イテレーションあたりに消化できる仕事の量を指す。
Story Pointという相対見積手法の1つを用いて工数を見積り、スプリントあたりに消化できるStory Pointの合計値を計測し、それをベロシティとすることが多い。

このベロシティが安定すれば、1つのイテレーションで進めることが出来る仕事の量が安定して予測できるため、「イテレーションにおける開発スケジュールの予測精度」も安定する。

ひいては、「どのような価値をいつまでに生み出せるか」が安定して予測できるようになり、不確実性の高い事業領域でもプロダクトを伸ばしていくための適切な戦略を策定することが出来るようになる。

「終わらせる」ことが重要

最後に少し脱線して、どうすればベロシティは安定するかの議論に少し踏み込んでみる。

筆者が思うに、イテレーションの計画を「終わらせる」・「達成する」ためにチーム協力を生み出せるかが重要そうである。
組織成果を最大化することを念頭に置き、早めにタスクを消化したメンバーは他メンバーを手伝うなど、チームとしての計画を達成するための動きが愚直に出来るかどうかが最終的には重要であると考える。

『ELASTIC LEADERSHIP』でも次のように言及されている。

アジャイルな方法論では、プロダクトをきちんと届けるために、イテレーションを終わらせて「完成」させるためならどんな作業でも引き受ける覚悟のあるメンバーによる、チームワークと連携を重視します。

『ELASTIC LEADERSHIP』Roy Osherove(著), 島田 浩二(訳) (2017)

https://www.oreilly.co.jp/books/9784873118024/

おわりに

アジャイルにプロダクトを開発していくなら、やはり、ベロシティは安定を目指すべきだった。

GitHubで編集を提案
SODA Engineering Blog
SODA Engineering Blog

Discussion