【ITニュース解説】Stop Chasing Velocity: What to Measure in Zenhub Instead

システム開発の現場では、プロジェクトの進捗やチームの生産性を把握するために様々な指標が使われる。その中でも「ベロシティ」という言葉は、アジャイル開発に取り組むチームにとって非常によく聞かれる指標の一つだ。ベロシティとは、具体的には、ある一定期間（スプリントと呼ばれる短い開発期間）において、チームが完了したタスクの合計ポイント数を指す。各タスクにはその複雑さや工数に応じて「ポイント」という見積もりが割り当てられており、スプリントの終わりに完了したタスクのポイントを合計することで、チームがどれだけの量をこなしたかを示すのがベロシティだ。

多くのチームでは、このベロシティがまるでスポーツのスコアボードのように扱われ、「チームのベロシティが上がらないのはなぜだ？」といった問いかけがされることがある。しかし、記事では、ベロシティを唯一の、あるいは最も重要な目標として追いかけることには多くの問題があると指摘している。ベロシティだけを指標として重視すると、チームの健全性やプロジェクトの本質的な成功を見誤ってしまう危険性があるのだ。

ベロシティが誤解を招く理由を具体的に見ていこう。まず、ベロシティは単に「どれだけの量のタスクが完了したか」を示すだけであり、その「質」については何も語らない。たとえ高いベロシティを記録しても、その成果物の品質が低ければ、ユーザーにとって価値のあるものとは言えない。次に、計画外の作業への対応状況が不明瞭になる点だ。システム開発では、予期せぬトラブル対応や緊急性の高い修正作業など、計画になかった作業が発生することも少なくない。ベロシティはこれらの突発的な作業をどれだけ処理したかを考慮しないため、チームが実際には多くの困難を乗り越えていたとしても、数字には表れない。

さらに、ベロシティはチームの士気や燃え尽き症候群といった、人間的な側面を全く考慮しない。高いベロシティを維持するためにチームメンバーが過剰な残業を強いられたり、ストレスを抱えていたりしても、ベロシティの数字だけではその実態は把握できない。そして最も重要な点として、提供された作業が本当に価値のあるものだったのかどうかをベロシティは教えてくれない。単に多くのタスクをこなしたとしても、それがユーザーやビジネスにとって意味のある成果につながっていなければ、そのスプリントは成功とは言えないだろう。

ベロシティを目標として追いかけると、チームは数字を良く見せるための行動を取りがちになる。例えば、タスクの見積もりポイントを実際よりも高く設定したり、簡単なタスクばかりを選んで優先的に完了させようとしたりするかもしれない。このような行動は、アジャイル開発が目指す「変化への適応」や「価値の継続的な提供」とはかけ離れており、単なる「システムを欺く行為」になってしまう。これでは、本当の意味でのチームの生産性向上や成長にはつながらない。

では、ベロシティに代わって何を測定すべきなのだろうか。記事では、チームの健全性をより正確に把握するために、Zenhubのようなツールで追跡すべき3つの健全な指標を提案している。

一つ目は「サイクルタイム」だ。サイクルタイムとは、一つのタスク（イシュー）が「In Progress」（作業中）の状態になってから「Done」（完了）の状態になるまでの時間の長さを指す。この時間が短ければ短いほど、チームの作業の流れは健康的であると言える。システム開発のプロセスにおいて、タスクがスムーズに次の工程へ進み、停滞することなく完了までたどり着いているかを測る重要な指標となる。サイクルタイムが短いということは、チームが効率的に作業を進め、迅速に価値を提供できている証拠であり、ボトルネック（作業の滞留地点）がないことを示唆している。

二つ目は「WIP（Work in Progress）」だ。WIPとは、ある時点で同時に進行中のタスク（イシュー）の数を指す。つまり、「作業中」の状態にあるタスクの総数だ。多くの人が一度にたくさんのタスクを抱えている状態は、一見すると多くの作業が進んでいるように見えるかもしれない。しかし、実際にはWIPが多すぎると、個々のタスクに対する集中力が分散し、タスクからタスクへと注意を切り替える「コンテキストスイッチング」が頻繁に発生する。このコンテキストスイッチングは、脳にとって大きな負担となり、結果として作業効率を低下させ、全体的なデリバリーを遅らせる原因となる。WIPを適切に制限することで、チームは特定のタスクに集中し、より速く、より高品質なアウトプットを生み出すことができるようになる。

三つ目は「スプリントゴール達成度」だ。これは、スプリントを開始する前の計画段階でチームが「このスプリントで何を達成したいのか」という具体的な目標（スプリントゴール）を設定し、その目標がスプリントの終わりに達成できたかどうかを評価する指標だ。ベロシティが「どれだけの量をこなしたか」という「アウトプット」に焦点を当てるのに対し、スプリントゴール達成度は「どのような目的を達成したか」という「アウトカム（結果）」に焦点を当てる。たとえ完了したタスクのポイント数が少なかったとしても、設定したスプリントゴール、つまりそのスプリントで最も重要だと考えられた目的が達成できていれば、そのスプリントはチームにとって価値のある成功だったと言える。この指標は、単にタスクをこなすだけでなく、ビジネスやユーザーにとって意味のある成果を生み出すことを重視する姿勢を育む。

結論として、ベロシティは確かにチームの活動を示す一つのデータポイントではあるものの、それを唯一の、あるいは最終的な目標として追いかけるべきではない。チームの本当の健全性や、ユーザーへの価値提供の度合いを理解するためには、サイクルタイム、WIP、そしてスプリントゴール達成度といった、より多角的な視点からプロセスと成果を評価することが不可欠だ。システムエンジニアを目指す皆さんには、数字の裏にある本質的な意味を理解し、単なるタスクの量だけでなく、提供する価値やチームの持続可能な働き方に目を向けることの重要性を常に意識してほしい。これらの健全な指標に注目することで、チームは数字に振り回されることなく、真に生産的で、持続可能な開発プロセスを築いていくことができるだろう。