ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは(後編)

今回は「ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは(後編)」についてご紹介します。

関連ワード (直近数、開催、開発等) についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。


開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。

そのことを詳しく株式会社アトラクタ 吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。

吉羽氏のセッションの内容をダイジェストで紹介しましょう。

本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は後編です。

それでもまだ定量的な報告を求められたら?

それでもまだ、定量的な指標が必要なんだと言われたら、これはなかなか手ごわい状況です。

そういうときにどうするか、という話をします。

これはケント・ベックのブログに載っていたものを書き起こしたものですが、インパクトやアウトカムというのはこういうつながりになっています。

fig

エフォート→アウトプット→アウトカム→インパクト

エフォートとは、計画づくりを頑張りました、ミーティングを何回やりました、コードを何行書きました、プルリクエストを何本送りました、何時間働きました、などの労力をどれだけかけたか、というものです。

アウトプットは、出来上がった計画書とか書いたコードとか、出来上がった機能とか、目に見える形になったもの。

アウトカムが行動変容で、インパクトは売り上げとかコンバージョンレートの向上とかチャーンレートの減少とか。これらはコンテキストによるので自分たちのプロダクトに応じて当てはめていただければいいんですけれど、こんな感じで分解をできるわけです。

この中のどこを測ると良いのかを考えると、最終的に目指しているのはインパクトなので、できればインパクトがいいですよね。もしそれが無理ならアウトカムがいいし、それも無理ならアウトプット、それも無理ならエフォートですよね。

ただ、計画作りを頑張りました、ミーティングを何回やりました、ということを測っても意味があるのかは分からないですよね。なので、インパクトやそれに近いものを狙って測る必要があるのかなと思います。

ちなみにベロシティはアウトプットの一種ですかね。

これに関してケント・ベックは「サイクルの早い段階で測定すればするほど、測定は簡単になる。そしてまた、意図しない結果をもたらす可能性も高くなる」と言っています。

fig

つまりエフォートを測るとみんなそこに最適化しちゃうので、その先のアウトカムやインパクトに必ずしもつながらないよね、と言ってるわけですね。

ですのでアウトカムやインパクトのように、なるべく後ろにあるものを測っていくといいよね、ということになります。

なのでスクラムチームみんなで見るべき指標はプロダクトに関連する指標を選んだ方がいいと個人的には思います。それはNSM(North Star Metric)でもいいし、KGI(Key Goal Indicator)でもKPI(Key Performance Indicator)でもいいです。

fig

ただ、プロダクトの指標は遅行指標が多いんですね。しばらく後にならないと結果が分からないというのも多いので、先行指標を探したい、ということはスクラムチームで話せばいいんです。

プロダクトオーナーしかそのプロダクトのメトリクスに関心がないという状態は非常に不健全です。チーム全員がプロダクトのメトリクスに関心を持っているのがあるべき状態かなと思います。

SPACEフレームワークの紹介

ここで1つフレームワークを紹介しておきます。

「SPACEフレームワーク」というものがあります。これは「LeanとDevOpsの科学」という本の著者の1人であるニコール・フォースグレンという人が論文で発表していて誰でも読めるようになってます。

fig

この中でも明確に、単一のメトリクスを見てもしょうがなくて、複数のメトリクスを見る必要があるよと言っていて、それを複数のカテゴリの中から選んだ方がいいよと言ってるわけです。

そのカテゴリがS(Satisfaction and wellp-being:満足度)、P(Performance:パフォーマンス)、A(Activiti:アクティビティ)、C(Communication and collaboration:コミュニケーションとコラボレーション)、E(Efficeiency and flow:効率とフロー)ということで、それぞれの頭文字をとってSPACEフレームワークということになっています。

fig

ただ、これら全部のカテゴリのマトリクスを必ず全部測れというわけではなくて、複数のカテゴリからチームにとって必要な分だけを選んでね、と言ってるわけです。

ベロシティの良い使い方

ベロシティの良い使い方は、実は非常にシンプルです。1つは、スクラムチームがスプリントでどれぐらいの量を計画するかの材料に使う。

もう1つは、スクラムチームが将来の見通しを立てるために使う。最後は、スクラムチームが自分たちを検査するために使う。

全部にあえて主語として「スクラムチーム」を入れました。つまり、自分たちのためにベロシティを使いましょう、ということです。

fig

それぞれを見ていきましょう。

1つ目の、スクラムチームがスプリントでどれぐらいの量を計画するかの材料に使う。

ベロシティは事実ベースの計画作りに使えますよね。このスライドでは、左側にプロダクトバックログアイテムが並んでいて、平均的なベロシティが10であれば上から2つぐらいが完成しそうだと分かるし、20であれば下の緑の線まで完成しそうだと、大体分かりますよね。

fig

リファインメントのときも同じです。ベロシティが分かってれば、準備がどれぐらい必要かは見えてくるので、そういう計画の材料に使うというのがシンプルな使い方です。

ただし、ベロシティには誤差がありますのであくまで目安として考えてください。数字はどうせ正確ではありません。

スプリントプランニングのときにベロシティ分めいっぱいプロダクトバックログを積みたい、というチームもありますが、スプリントの唯一の目的はスプリントゴールの達成です。

スプリントゴールに関係ないプロダクトバックログを無理に積んでも仕方がないので、ゴールを達成するための計画作りに使ってください。

ちなみに、僕が支援したチームのベロシティの推移を出すとこんな感じです。

fig

デコボコしてますよね、だってプロダクトバックログアイテムの見積もりがしょっちゅうずれますからね。

下にある「出来事」に、「全員1日休み」とか「1人2日不在」などと書かれていますが、こういう記録もとっておくと、スプリントレトロスペクティブでちょっと議論する材料になったりします。

この例は本物です。どこのお客さんかは言えませんが、許可はもらっています。

ベロシティは昨日の天気

次に、スクラムチームが将来の見通しを立てるために使う、ということについて。

「ベロシティは昨日の天気」というスクラムのパターンがあります。直近数スプリントの平均値を使って今後の見通しを立てましょう、というのがよくある使い方です。

fig

例えば、過去3スプリントのベロシティが22→26→24と、まあ普通はこんなに綺麗に安定しないですが、これぐらいで推移してたら、1スプリント24ぐらいはできるのかなと想像がつくので、残りのスプリントがあと5回だったら120ポイント分できるねと。

最低限のリリースまでに96ポイント必要だとしたら、4スプリントは必要だねということが、とりあえず分かります。

ただ、この数字が当てになるかというと、つねに当てになるわけではなくて、時間を経るごとに、チームが安定するごとに数字の信用性は上がっていくので、いつも見通しを更新することが重要です。

そのスクラムチームの説明責任と、いつも自分たちの状況を見える化するという意味で、今後の見通しを見えるように伝えていく。それを繰り返し繰り返しやってください。

ベロシティを自分たちの検査のために使う

最後は、スクラムチームが自分たちの検査のために使う。

透明性、検査と適用ということで、ベロシティのデータを見ながら自分たちのパフォーマンスの改善に使えるはずです。

fig

例えばベロシティの上下動がものすごく激しいとき。0→50→0→50とか、こんな極端な動きははないと思いますけれど、もしこうだとしたら、未完成なものを次スプリントに先送りすることが常態化してるのかもしれない、とか、特定のプロダクトバックログアイテムの見積もりは当てにならないのかもしれない、とか、何かのスキルが足りてなくてボトルネックになっていて、その作業があるときだけうまくいかないのかもしれないとか、掛け持ちがあって時間が不安定なのでベロシティがおかしくなってるのかもしれないとか、議論をして仮説を立てて、検証ができるはずです。

ベロシティはスクラムチームのために使いましょう

ということで今日のまとめです。まあ、このスライドには書いてないですけれど、ベロシティの数字遊びなんかしてないでプロダクトの価値にフォーカスしようねというのが実は一番大事です。ベロシティにDeep Diveなんかしないでください。

fig

ベロシティはスクラムチームのために使いましょう、自分たちのために使いましょうというのが、お伝えしたい内容でございます。

以上でございます。ご清聴いただきましてありがとうございました。

≫公開されているスライド「ベロシティ Deep Dive」

関連記事

  • プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか(前編)

COMMENTS


Recommended

TITLE
CATEGORY
DATE
NEC、マーケティング企業のCCIとAI活用の広告考査支援を実証実験
IT関連
2023-07-05 00:55
ヒューマンエラーによるサイバーセキュリティ問題を防ぐCybSafeが8.3億円調達
セキュリティ
2021-01-31 10:27
既存防犯カメラで来店客の店内行動を解析可能なエッジAI端末を提供する「AWL」が20億円調達
IoT
2021-06-03 12:19
AWSを駆使した生徒起案の文化祭を開催–奈良県 西大和学園高校
IT関連
2022-09-29 01:01
DeFiの基本を解説–ブロックチェーンを活用した新たな形の金融サービス
IT関連
2022-02-03 04:27
Cohesity、異なるSLAに一元対応する自動ディザスターリカバリーを発表
IT関連
2021-01-26 18:14
Tesla決算、売上高が初の100億ドル超、通年で初の黒字に
企業・業界動向
2021-01-29 08:07
大阪万博に顔認証システム導入へ–受入世代が広がる中で懸念も
IT関連
2024-07-09 06:54
モバイルアプリ用テスト自動化ツール「Appium 2.0」まもなく登場。ドライバーの分離、プラグインによる拡張対応など、新機能を開発者Jonathan Lipps氏が解説
JavaScript
2021-05-11 03:17
テレワークで広がる「ワーケーション」 地方再生の“切り札”なるか
IT関連
2021-05-27 22:16
パブリッシャーのコンテンツ推奨収入を最大化を支援するイスラエルのWhizzCo
ネットサービス
2021-04-25 16:52
ハイブリッドクラウド環境の管理に悩む企業に向けた解決策
IT関連
2023-03-09 02:25
GitLab、日本法人のリーダーとして小澤正治氏を任命
IT関連
2023-11-08 03:46
ミスミに聞く、基幹システムのマイクロサービス化で挑戦する可観測性
IT関連
2023-06-22 20:50