Velocityを巧みにコントロールすれば、どんな仕事もうまく回すことができる

2024年7月11日 10:28

「データ分析×人×ビジネス」の軸で記事を書いています。

今回の記事、後半に小難しいことを書いていますが、要点は以下のようなことです。

Velocity（ベロシティと読みます）とは価値の方向性を定め、そこに向かって速く進めているかどうかをチェックする表現方法である。
Velocityの性質は「量から質へ」転換していくもので、その転換ポイントを作れるかどうかがキモである。
活動、アウトプット、価値という３点を血液が循環するかのように「サラサラ」になっている状態をつくるのが個人／チームのマネジメントが成り立っていることの証である。

はじめに

急にVelocity（ベロシティ）なんて聞きなれない言葉を使ってしまいました。この言葉の定義自体を重視するよりも、Velocityという「ものの考え方」をもつことで、個人レベルもしくはチームレベルでも仕事がうまく回っていくことを示したいと思っています。
※アジャイル開発・スクラムの専門家の方々へ：私はPOの資格も、Sマスターの資格も持っていません。専門家からして、本来の理解を妨げる不適当な表現があるかもしれませんがご容赦いただければと思います。

Velocityという言葉の一般的意味

速さ、速力；速度
https://ejje.weblio.jp/content/velocity

日本語の「速さ」という意味ではspeedと同義ですが、２つの区別をつけると本来のVelocityの意味が分かりやすくなると思います。

VelocityとSpeed

どちらも、日本語的には「速さ」を表しますが、

Velocityは"方向性"がある。例えば、西に向かって時速60kmで走る、といったように。
Speedは方向性をもたず、単に時速60kmということを表す。（数学が得意な人はスカラーとベクトルの違いといえば、分かりやすいかもしれない。）

Velocityの本質をとらえるにあたって重要なこと

Velocityには"方向性"という意味が込められています。我々の取り組みにおいて、この方向性とはユーザーに提供する価値のことであり、プロダクトバックログアイテム１つ１つを達成するということに他なりません。もっといえば、スプリントバックログアイテムや、それを形作っているタスクは全て「ユーザー価値という方向に向かっている」ものでなければなりません。

例示

ハムエッグをつくる、ということを例にとって考えてみます。
VelocityとSpeedは「速さ」という意味ですから、いかに速くハムエッグを作れるかという点にフォーカスした場合：

　1) Aさんはハムエッグを5分で作った
　2) Bさんはハムエッグを10分で作った

という結果について評価するとAさんの方が「優秀だった」といえるでしょう。なぜなら、Bさんよりも5分も早くハムエッグを作っているからです。

これはSpeedで評価した場合です。これをVelocityで評価する場合どうなるでしょうか？　極端な例示をすると：

　1)' Aさんのハムエッグは「マズい」とクレームを受けた
　2)' Bさんのハムエッグは「美味しい」と賞賛を受けた

お客様に提供することを考え、味に対してのフィードバックという点を考慮すると明らかにBさんの方が「よい仕事」をしていたといえると思います。こういう評価ができるのは「お客様に美味しいと満足していただく」という方向性があるからこそです。

つまり、「Velocity = Speed + 方向性」などいう表現が良いかもしれないということです。単に速くアウトプットをだす（プロダクトをつくる）というだけでなく、何のために・それがどう喜ばれるか・どのように使ってもらうといいか、etc.といった方向性に向かって速く作らなければならないというわけです。

ただし、実際にはこれほど簡単なことはありません。少し意地悪な例を挙げてみますと：

　1)'' Aさんのハムエッグは貴族には不評だったが、平民には好評だった
　2)'' Bさんのハムエッグは貴族には好評だったが、平民には不評だった

この場合、貴族にとって提供される時間は重要ではなく、味（や見た目など色々）が重要だったのかもしれません。一方で平民にとっては味より速く、安く提供されることの方が重要だったのかもしれません。極論いえば「何を価値として感じるかは人や、その状況によって変わりうるもの」だということです。だから、ScrumにおいてVelocityを用いる際には「誰のために、何を？」という方向づけが必要なのです。それが前提にあっての速度が重要なのだと思います。

いくつかの本に書かれている説明

参考書籍：SCRUM BOOTCAMP より

開発チームの過去の実績（これをベロシティと呼びます）
ベロシティに求められているものは安定
ベロシティが安定しているスクラムチームは、全員が協力して作業を進めている
ベロシティは単なる目安

参考書籍：正しいものを正しくつくるより

チームの速度
ベロシティを計測し、安定させている
スプリントをつなげていけば徐々に高まっていくはず
ベロシティがスプリントごとに乱高下しているようだと、何か問題が起きている

安定とは何を意味するか

賛否両論、色々な意見があると思いますが、ベロシティが安定しているということは以下の２つの状態を表しているはずです。

　[1] プロダクトの価値の方向性が定まっている
　[2] 1つ1つのSPRINTがその方向に向かって、"継続的に"上積みされている

ただし、１点注意があります。「現状維持は継続的な上積みにならない」ということです。最初は直線的に右上に上積みされるイメージかもしれませんが、いずれは鈍化するはです（永遠に直線的に貯金が増え続けるようなことはなかなかない）。状況の変化に応じて、我々の活動も変えていかないといけないわけです。

つまり[2]で表現した"継続的に"に隠された意味として、ユーザーの価値とは対象セグメントや世の中の環境によって変化するものであり、その変化をキャッチし、そこに対してのプロダクトをリリースするという考えが必要です。それをするためには、ダイナミックにリスクの高いことを選ぶような勇気も必要で、時には全くやったことのない未知の領域に踏み込み、ミスをしてもリカバリするような柔軟性も必要です。 ※非線形的（指数関数的）に成果指標をあげることを考えるのは、このためである。

なお[1]の補足ですが、方向性が定まっていない（SPRINTごとに重要なことがコロコロ変わる＝悪い意味で）ようなプロダクトバックログが選ばれていたりすると、活動に対してのアウトプット（それは結果としてユーザーに提供する価値になる）の量や質が相関しなくなってくるのだと思います。

で、結局Velocityって何なの？

現時点で私が最も分かりやすいと思える表現、大げさに言えばVelocityの定義はこうです。

【定義】 VelocityとはScrumチームの活動、その活動によって生み出されたプロダクト、そしてプロダクトを利用することによって生まれるユーザー価値という3つの要素をつなぐ"流れ"がよく循環している状態をマネジメントすること。ここでいう"流れ"とは、活動によるアウトプット、それをユーザーに提供し、フィードバックを受け、それを反映させることを意味している。アウトプット→提供の流れ(換言すればユーザーへのインプット)をたくさん、はやくやることは、ユーザーからのフィードバック→プロダクトへの反映がたくさん、はやくできるということ。その結果、定められたユーザー価値が効率よく増大していくことができる。

活動・アウトプット・価値の３点が、まるで血液が（サラサラに）循環している状態をつくる

では、具体的にどのようにVelocityを使うか

まず全ての前提として、Velocityが安定しているという状態について
　[1] プロダクトの価値の方向性が定まっている
ということが成り立っているとします。すなわち、プロダクトバックログアイテムが適切に設定されているということです。

これを基にSPRINTのゴール（正確ではないが≒SPRINTバックログアイテムといえるだろう）に対して、必要なタスクを書き出します。ここから、

　・活動とアウトプットという２軸で、
　・それぞれスピード、量、質という要素分解をしながら
　・タスクの優先順位をつける(大まかな得点付けを行う)

という操作を行います。これが「Velocityを見積もる」ということです。

アナロジーでの実例

ハムエッグの例で実際に試してみましょう。まずハムエッグをつくる手順は以下のようにしてみます。

食材(卵とハム)を選別する
下準備をする(例えばハムに下味をつけたり、卵の殻を割ってお椀に入れておくなど)
フライパンに火をつけて、ハムと卵を焼く
状態を観察しながら待つ
盛り付けの準備をする
盛り付けをする
お客様のテーブルへ提供する

繰り返しになりますがVelocityには方向性が必要なので、例えば、

方向性1 ホテル朝食のような気分を味わえるハムエッグを提供する
方向性2 忙しいビジネスパーソンが効率よくタンパク質を摂取できるハムエッグを提供する

といった方向性の違いによって、上記１～７の「何が重要か」は変わってきます。すなわち、どこに技術や時間を充てるかが変わりうるということです。

先ほど、
　・活動とアウトプットという２軸で、
　・それぞれスピード、量、質という要素分解をしながら
　・タスクの優先順位をつける(大まかな得点付けを行う)
ということを書きました。

「活動」とは「ハムエッグをつくる」ということで、そのタスクは１～７に示したとおりです。この活動についてスピード、量、質という要素分解をしながらタスクの優先順位をつけるのです。これをするためには、アウトプット軸でのスピード、量、質を定義（実際には交互に複雑に考える）しなければなりません。

●方向性1についてアウトプットのスピード、量、質
ここで重要なのはスピードや量ではなく、質です。もっといえば、ハムエッグの出来栄えそのものというよりも（タスクにはないが）店装や席へ案内する作法、注文時の接客配慮；タスク７に示したような提供の際の作法などが重要かもしれません。となれば、実はハムエッグを作るという操作（タスク）そのものは重要でないとも考えられます。強いて言うならタスク６が重要でしょう。

つまり、アウトプットの質を重視したとき、もっとも重要なタスクは６や７であり、ここに「盛り付けが上手な人＝技術リソース」を充て、さらに盛り付けの品質基準を定め、そこに到達するまでどのくらいの時間をかけてよいかを見積もるのです。

古典的な表現で言えば、タスク６には人月単価の高い上流人材がアサインされるべきであるし、かける工数も多めに見積もる必要がある、ということです。

●方向性2についてのアウトプットのスピード、量、質
方向性2は「忙しいビジネスパーソンが効率よくタンパク質を摂取できるハムエッグを提供」ということでした。実はこれ曖昧な表現で「効率よく」とは、手っ取り早く食べれるという意味なのか、栄養素を効率よく摂取できるという意味なのか明確ではありません。こういう方向性についてもVelocityを見積もる・計測するという操作において考える必要があります。なぜならVelocityにおいて方向性が重要であるからです。

ここでは前者の意味としておきましょう。そういうシーンを考えると、忙しいビジネスパーソンにとって食パン一枚を忙しく食べて出るようなところかもしれません。栄養学的には食パンと一緒に卵をとることは効率が良いのです（モーニングメニューでトーストとゆで卵がセットになっているのは理由がある）。そうなると、卵は生より熱を通した方がビオチンが効率的に摂取できるので良いと考えれば、よく焼く必要があります（ということを考えて焼ける人が必要かもしれないし、あるいはレシピを考える際にそのような調理基準を作っておけばこのタスクはさほど重要でないかもしれない）。

ただ、こういったことはユーザーが明確に１回の食事で得られるメリットではありません。そうなると、調理の質よりは手っ取り早く量を食べたいニーズがあると考える方が自然です。あるいは、ここに「より安く」という条件も必要かもしれません。

その場合、タスク６や７（方向性1では重視された）はさほど重要でないといえるかもしれません。２～５は多少手を抜いても大丈夫だろうから、ここに技術リソースを充てる必要性は低いのです。換言すれば活動の質はさほど重要ではありません。むしろ、食材選別(できるだけ仕入れが安く大量にできるということ)が重要で、大げさに言えばそこに技術リソースを充てるべきだし、時間もかけるべきであるということです。薄利多売のビジネスをしている人たちは、まさにこれをやっています。

改めてVelocityのまとめ

Velocityには"方向性"という意味が込められている。我々の取り組みにおいて、この方向性とはユーザーに提供する価値のこと
ScrumにおいてVelocityを用いる際には「誰のために、何を？」という方向づけが必要
ベロシティが安定しているということは以下の２つの状態を表しているはずである。
- [1] プロダクトの価値の方向性が定まっている
- [2] 1つ1つのSPRINTがその方向に向かって、"継続的に"上積みされている
[2]の"継続的に"に隠された意味として、ユーザーの価値とは対象セグメントや世の中の環境によって変化するものであり、その変化をキャッチし、そこに対してのプロダクトをリリースする
VelocityとはScrumチームの活動、その活動によって生み出されたプロダクト、そしてプロダクトを利用することによって生まれるユーザー価値という3つの要素をつなぐ"流れ"がよく循環している状態を表現する指標。
SPRINTのゴール(正確ではないが≒SPRINTバックログアイテムといえるだろう)に対して、必要なタスクを書き出す。ここから、
- 活動とアウトプットという２軸で、
- それぞれスピード、量、質という要素分解をしながら
- タスクの優先順位をつける(大まかな得点付けを行う)という操作を行う。
これが「Velocityを見積もる」ということ。

上級者向け、補足

これ以降は、小難しい話なので「補足」として付け加えさせてもらっています。

見積と計測(評価)

SPRINT Planningの際にはVelocityは見積もられるものである。これに対してSPRINT ReviewやRetrospectiveなどのシーンでは評価されるものになる。古典的なシステム開発でいえば、工数の想定見積に対して実績がどうだったかの対照である。ただし、Velocityの計測(評価)の際は単に速くできたかどうかだけでは足りない。何度もいうが方向性にあっていた活動ができて、それが速くできていたのかどうかという点が重要である。

例えば、

食材(卵とハム)を選別する　→15
下準備をする(例えばハムに下味をつけたり、卵の殻を割ってお椀に入れておくなど)　→5
フライパンに火をつけて、ハムと卵を焼く　→2

などと架空のスコア（≒Velocity）を見積もっていたとする。

このスコアは初期段階においてはキャパシティを100としたとき、どのくらいのPowerを充てられるか（工数よりも不正確な作業ボリュームイメージ）を配分するのが手っ取りはやい。しかし、慣れてくればVelocityの定義が決められ、それを頭の中で多変量的に計算できるようになる。ただし、これをするのに時間をかけてはいけない（そうなるようなら、あなたはまだそれほど高度なVelocityの見積ができるレベルにない）。

まずは、
Velocity = 速さ + 方向性
という定式を以下のように分解し、
Velocity = (アウトプットのスピード + 量 + 質 ) * (活動のスピード + 量 + 質)
をイメージしてタスクの"重さ＝スコア"を絶対基準(例えば10点満点)でつけてみる。

これが自然にできるようになったら、そのチームなりの定式分解式を正確につくりあげていくのがよい。しかしながら、上の例だけでも最初はかなり難しだろう。その場合、何段階かに分けて試してみるとよい。

【例】
第1段階: Velocity = (アウトプットのスピード) * (活動のスピード)

とにかくはやくアウトプットするための定式分解式

第2段階: Velocity = (アウトプットの量) * (活動のスピード + 量)

何が自分たちのプロダクト定石化を知るためには大量のアウトプットに対してフィードバックを受けることを考える。そのための定式分解式である。アウトプットの量だけになっているのは、意識しなくとも1SPRINT-1weekくらいなら、第1段階をクリアできたチームなら強く意識しなくてもスピードはやくアウトプットするチームになっているはずだから。

第3段階: Velocity = (アウトプットの量 + 質 ) * (活動の質)

第2段階で大量にアウトプットを出して、効率よくユーザーフィードバックを受けられるチームになっているなら、活動の質にフォーカスすれば理想の定式分解式におのずと近づくだろう。

第4段階: Velocity = (アウトプットのスピード + 量 + 質 ) * (活動のスピード + 量 + 質)

理想の定式分解式の運用

第5段階: Velocity = アウトプットQCD * 活動QCD * ROI * ユーザー価値 | チームの力

守破離でいう"離"の状態。自分たちのオリジナルをつくって運用。最終的にはユーザーの価値向上と、ビジネスとしての儲けをバランスよく考える。ちなみに | という記号は条件付きという意味で「チームの力があるという条件の下で、4つの要素をコントロールする」ということ。

Velocityの運用

前述のようなVelocityの定式分解式ができたなら、それを運用していかなければならない。この際、Velocityは安定していることが重要と既に述べたが、再掲する：

賛否両論、色々な意見があると思うがベロシティが安定しているということは以下の２つの状態を表しているはずである。
　[1] プロダクトの価値の方向性が定まっている
　[2] 1つ1つのSPRINTがその方向に向かって、"継続的に"上積みされている

ある意味でよい状態とは、
・活動のQCDとアウトプットのQCDが相関しており、
・かつ、ユーザーへの提供価値が向上している
ということである。分かりやすく言えば、頑張った分だけ適切にアウトプットが出され、それが認められているということである。これはうれしいに違いない。

もし活動のQCDとアウトプットのQCDが相関していない場合、これも再掲するが

【定義】 VelocityとはScrumチームの活動、その活動によって生み出されたプロダクト、そしてプロダクトを利用することによって生まれるユーザー価値という3つの要素をつなぐ"流れ"がよく循環している状態をマネジメントすること。

ということならば、よく循環していない状態になっているということである。

したがって、まずは活動とアウトプットの相関性を見出すことが重要である。それが見出せたならば、ユーザーへの提供価値が向上しているかどうかだが、
【活動とアウトプットのQCDが相関しているのに、ユーザー価値が向上しない】
という現象に出くわすだろう。

これはどのような状態かというと、ハムエッグの例で出した、

方向性1 ホテル朝食のような気分を味わえるハムエッグを提供する
方向性2 忙しいビジネスパーソンが効率よくタンパク質を摂取できるハムエッグを提供

ということについて
【１】そもそも方向性の定め方が間違っているか、
【２】もしくは、方向性に向かう歩み方＝Velocityの見積もりが間違っている
かのどちらかであるかの可能性が高い。
※急な震災とか、そういうこともあり得るが、、、

例えば、こんな話がそれである。

わずか1日でよいLPをつくれて、リリースできた
web予約(CV)も増えた
でも儲かっていない(これは実際に価値を認めてもらえず買わなかったということ)

おそらくLP制作という活動とアウトプットLP（正確にはLPというアウトプットがweb予約という行動を生み出している）は相関しているが、LPの訴求と購買シーンもしくは購買に至るだけの十分な理由になっていないのだろう。マッチングアプリの例はこういうやつの典型例かもしれない。利用者は増えるが、結局いい相手が見つからず退会者が多い（サクラだらけのサービスに成り下がる）。

ここで重要なことは「考える」ことである。実際に何が原因かどうかは極論いえばどうでもよい話である。Velocityは

であるとするならば、【１】か【２】かという視点を持って考え、次のSPRINTをどう組み立てるかを考えるのが重要である。この原因特定をしすぎると「課題探しの迷い人」になり、考えているだけで何もアウトプットを出せない状態にある。これは活動のスピードに対して、アウトプットのスピードも量も担保されていない状態になってしまっている、よくある例。

いずれにせよ、我々Scrumチームの活動とは心臓であり、効率よく血液を循環させる状態を保つ(走っているときはバクバクすることもあるが、それは状況に応じた変化である)ことをイメージし、心拍の状態で体の状態をマネジメントするように振る舞う。こういう自分たちなりのイメージをもって進むことが本質。Agileとは決められたメソッドに従って動くことではなく、自己組織化と職能横断が根本的な思想であることを忘れてはならない。

自己組織化: ミッション実現に向かうための選択を自分たちで決定し、行動できる度合い。
職能横断: チームの外側に頼らず仕事を成し遂げられる編成になっている。

※最後の箇条書き２つは「正しいものを正しくつくる」より引用。