ベロシティを目標にする危険性について学んだことをアジャイルサムライ風に振り返ってみた

こんにちは、Forkwell事業部の中の人です。

本日は、つい最近 Forkwell Jobs の開発現場で起きたエピソードについてご紹介します。

きっかけはあるメンバーの一言でした。

「複数メンバーの加入から1ヶ月以上がたった、ベロシティもかなり安定してきた。よし、ここらでおれたちのベロシティをあげて、ビジネスサイドの連中をあっと言わせてやろうぜ!

この一言で息巻いた我々は、ベロシティをあげることを目標に設定し、ビジネスサイドのホワイトボードに ◯pt / 10pt のような数字を書き加えました

しかし、すぐに色々な現場を経験してきた他事業部のエンジニアの面々から、ベロシティをあげることを目標にすることには弊害があることを教わることになりました…

ベロシティを目標にする弊害

  • 目先のポイントを増やすためにとりあえずリリースして残タスクを先に積む事案が発生、後々の作業が滞る
  • 目先のポイントを増やすために、レビューが甘くなり、バグが増える
  • ポイントの見積もりが甘くなり、見積もり結果が信頼できなくなる

つまり、ベロシティを上げようとする行為が結果的に不正確なベロシティを招き、正確な見積もりができなくなる事態を招く可能性があるということでした。

ベロシティを目標指標にすることは推奨されていないらしい… でも、チームの生産性を向上させることには妥協したくない…

悩んだ我々は、アジャイルサムライのレビューにも参加していたという、当社のマスター・センセイである @idesaku に教えを請うことにしました。

マスター・センセイと熱心な弟子

弟子: ベロシティを上げることを目的にしてはいけない!とはいったものの、では何を指標にしたらいいのでしょうか?

センセイ: ベロシティをあげることを目的にするのではなく、それを落としている障害を取り除く発想が必要じゃ。 アジャイルでは、チームメンバーは常に全力で取り組んでいるように扱うし、実際にお前らは自主的に勉強し、成長しようとしておる。 はっぱをかけて全力を引き出すという発想自体がアジャイル思想にマッチしない。

メンバーが全力で頑張っている以上、できることは障害を取り除くことである。

弟子: ありがとうございます。

では、毎週振り返りで行っているKPTのP(Problem)で 自分たちのベロシティを下げているものがないか、洗い出すようにします。 その上で、取り除けるのもがあればそれをT(Try)として取り組むようにします。

センセイ: 加えて、コスト・納期がどれだけ短縮できるかを考えるより、今までと同じ期間で新しくできるようになったことがどれだけか、というのを考えることが効果的じゃ。

弟子: ありがとうございます。

では、毎週行っているKPTのK(Keep)で、 今までと同じ期間で新しくできるようになったことは何かを、洗い出すようにします。 そのKの蓄積が、自分たちの成長だと考えます。

弟子: 一方で、ベロシティ以外の指標で、我々がビジネスサイドにも、しっかりやっていることを伝える方法はないでしょうか。

センセイ: 成果を伝えることだ。ベロシティは成果ではない。成果とはFeature(顧客へ届けた価値)のことだ。

弟子: バグの改善やリファクタリングは成果として示せないのでしょうか。

センセイ: バグは、過去に書いたものが間違っていただけで、それを直したからといって成果とはいえない。 しかし、どれだけ業務をこなしたかを伝えるにはいいかもしれない。

弟子: ありがとうございます。

では、今後はどれだけポイントをつぶせたかではなく、 どんな価値を顧客に提供できたかを、ポストイットを貼ることで報告するようにいたします。

f:id:grooves:20151020104547j:plain

いかがでしたでしょうか。 今回の事例が、皆さんの現場の参考になれば幸いです。

参考図書