これまで、マネージャーの方と話していると、チームのベロシティについて詳しく報告を求めていたり、評価の仕組みに取り入れている方がいらっしゃいました。とはいえ、自分の管理しているチームのベロシティが気になる方は多いと思います。
ベロシティは、ほとんどのスクラムチームで計測されている指標であり、作業量の見積もりなので、生産性を確認したいと思ったときに最も最初に目についてしまいます。
しかし、このベロシティによる評価や管理が思わぬ問題を生み出し、利益に対してネガティブな影響を与えることも多いことはご存知でしょうか?
今回は、ベロシティにまつわる、やってはいけない問題行動と、その解決策について紹介したいと思います。
問題
ベロシティにまつわる最も多い問題行動は、ベロシティを増やせとチームにいう、評価をベロシティで決める、他のチームと比較する、です。まずは、それぞれの問題行動が、どんなことを引き起こしてしまうのか説明します。
ベロシティを増やせとチームにいう、評価をベロシティで決める、他のチームと比較する
なぜ、これが問題なのでしょうか?2つの理由を紹介します。
まず1つ目は、ベロシティの本来の目的である作業計画を立てることを阻害してしまうからです。
ベロシティは、一定期間にどれだけの作業量が終わったかを示します。しかし、その作業量の見積もりは開発者がポイントを相対的に算出しているものです。そのため、作業量を多く見積もることが非常に簡単です。
すなわち、ベロシティを増やせと言われたり、評価に組み込まれたり、他のチームと比較されることで、開発者が最も簡単にベロシティを伸ばすための方法が、見積もり時にポイントを大きく算出することだからです。その結果、ベロシティはどんどん大きくなるでしょうが、本来の目的である今後の中長期的に完了させられる量の計画を立てることを困難にしてしまいます。
2つ目は、ベロシティを最優先に行動をするようになり、成果にネガティブな影響を与えてしまうからです。
私が関わる前のチームで、ベロシティを指標として報告したり注目されているチームがありました。そこでは、エンジニアがユーザーインタビューに出ることを渋っていました。なぜなら、インタビューに出た時間の分だけ、作業ができる時間が減り、ベロシティが下がってしまうからです。
こうなると、成果(ユーザーへの価値を提供すること)を出すために何をするのが良いかチームで話すことが難しくなってきます。ものを作ることに注力はしてくれるでしょうが、成果を出しづらくなってしまうと本末転倒です。
そのチームでは、エンジニアが作業者となり成果をだすためにチームで考えることを放棄し、開発に集中するようになっていました。その結果、起こることはユーザの役に立たないものが素早く作られていくのです。
他にもやってはいけないがチームから提案されやすい、個人ごとのベロシティの集計です。
個人ごとのベロシティの集計
こちらは、開発が早い人が十分に人事評価で認められてないときに提案することが多いように思います。
これは、なぜ問題なのでしょうか?
スクラムでは、チームで協力し1つずつTODOを終わらせていくのが理想です。しかし、個人ごとのベロシティを計測しようとすると、1人ひとりが1つのバックログアイテムを担当することになり、しかかりが多くなってしまいます。これは、協力して完了させていればリリースされ価値を提供していたはずのものが途中の状態で価値を産まなくなってしまいます。
さらに、チームで働いていることであるメリットの助け合いが起こりづらくなります。自分の完成させたベロシティを増やすために、積極的に他の人のサポートをしなくなってしまうのです。
解決策
以上のように、ベロシティの誤った使い方をすることで、ネガティブな状況を引き起こしてしまいます。
ここからは、そういった場合の解決策を紹介していきます。
評価に使う指標を計測したい
「ベロシティを生産性の指標として、増やせといったり、評価に使ってはダメなのはわかったけど、じゃあどうしたらいいの?」という声が聞こえてきそうですね。
こんなときのコーチからの回答は、「ベロシティではなく、アウトカムを計測するようにする」です。とは言っても、アウトカムを計測するって難しすぎると思われるかもしれません。そうです、活動は、努力→成果物→成果→利益のように影響していて、後ろのフェーズに進むほど計測が難しくなってしまうのです。そこは仕方ないところだと割り切って、KPI、NSM、KGIなどを追うようにしましょう。
※NSM:North Star Metric「チームの目標と方向性、そして成功を計る尺度」であり、KPIとKGIの間に相当する指標
なので、部署やチームで決めているKPIがあれば、それをチームで追うようにしていくのがよいでしょう。デイリースクラムの最初に自分たちのKPIを確認するチームもありました。
さらに、KPIを評価に使う指標にすることで、こんな意見も出そうです。「POが考える施策がイケてないからKPIが上がらない場合は、KPIを評価指標にすると、開発者はいいものを作っているにも関わらず開発者の評価が低くなる」といったものです。これは開発者が施策の良し悪しなど知らんといっているようなもの。アジャイルではよい状況ではありません。
みんなで成果を出すために頑張っていこうというのが理想的です。そのため、POがイケてないのであれば、開発者からバックログアイテムをどんどん提案していく、POを研修に活かせる、どうしてもダメならPOを交代するなどの手段があるでしょう。バックログアイテムを作ることをPO任せにしているチームもよく見ます。
評価に使う指標は、ベロシティではなくKPI、NSM、KGIのアウトカムの計測とし、みんなで協力してKPIを上げることを目標に取り組みましょう。
成果物の量を改善したい
「ベロシティを重要視しすぎるのはよくないことは分かったうえで、それでもチームの生産能力が低いのではないかと気になっているが、どうしたらいいの?」という場合もあるでしょう。
いくつか回答があるので、それぞれ説明していきます。
まず1つ目は、「ベロシティは上がり続けるものでもないと心に留める」です。生産性の歯指標と捉えると重視してしまいやすいベロシティは、上がり続けるものではありません。ある程度、開発のプロセスや、システムの自動化を済ませると大きな変化はなくなります。そのあたりのさじ加減はスクラムマスターと相談してみても良いかもしれません。
2つ目は、『「自分がやるのであれば」の前提で考えない』です。メンバーごとにシステムの理解度や、開発スキルが異なることを前提に「自分がやるなら」で考えないのが大切です。それに加えてマネージャーになる人は、開発スキルや、プロセスの改善の考え方が優れている場合も多いです。そのため、自分を基準に考えると無理な要求をしてしまいがちです。
3つ目は、「スクラムマスターに相談する」です。もし兼任だとしても、スクラムマスターは、マネージャーよりも圧倒的にチームと接している時間が長いですし、プロセス改善の観点でチームを見たり、深くチームを理解している部分も多いでしょう。さらに、問題行動で上げた通り、マネージャーが積極的に行動してよいことはあまりありません。スクラムマスターに相談してみましょう。
4つ目は、「見積もりが時間見積もりになっていないか確認し、基準となるストーリーを決める」です。見積もりが時間を基準としていた場合、スキルが上がってこなせる量が増えた場合、過去には3ポイントだったタスクが2ポイントになっているなんて場合はよくあります。これは、基準になっているストーリーがないことが要因です。基準となるものをきめうることで改善されます。
とはいえ、こちらの問題を解決したとして、成果物の量の指標が捉えやすくなりますが、成果が増えるわけではないので、あまりメリットはありません。
5つ目は、「投資を積極的にする」です。こちらを実施しているマネージャーは、チームから喜ばれる存在であることが多いように思います。もう少し具体的なアクションに分割して紹介していきます。
投資:プロダクトオーナーとスクラムマスターと中長期的な投資に時間を使う相談をする。
ベロシティにかかわらず、チームの成長の機会が失われているケースでよく見るのは、プロダクトオーナーが短期的な成果を常に追ってしまっている場合です。チームのスキルアップの勉強会をスキップしてどうにか終わらせてほしいといった要求が多かったり、システムの保守性や、自動化に関しても後回しにし続けたり、プロセス改善のバックログアイテムの優先順位を下げたりする場合がありました。そういった場合に、プロダクトオーナーとスクラムマスターと相談してみてもよいでしょう。
スキルアップ、システムの効率化、プロセス改善、こちらをなくしては長期的な成果がどんどん減ってしまいます。社内外問わず、他のチームでどの程度の投資のリソースを確保しているか情報交換をしてみてもよいでしょう。私が見ていて投資の多いチームだと、1週間のうち1日以上は、投資に充てていました。
また、プロダクトオーナーが短期的な成果を求めるのと同じく、開発者でも長期的な投資に対して「業務中に勉強をやっていいんだろうか」とか罪悪感を抱いてしまう方も少なくありません。そういった場合は、マネージャーが勉強会を推奨していることを何度も繰り返し伝えたり、マネージャーが率先して勉強会に参加したりしても良いでしょう。
投資:チームの使える予算の確保。マネージャーとしての行動で期待されていることが多いのが、こちらの予算の確保です。取ってきた予算で、有償の開発ツールを導入したり、研修や技術カンファレンスにチームで参加したり、外部の専門家を呼んでチームを指導してもらったり、お金があれば選択肢が非常に充実します。
ベロシティの正しい使い方
ここまで、ベロシティを指標として重視しすぎてしまったときに起こる問題と解決について紹介してきましたここで改めて、正しいベロシティの使い方を紹介します。
ベロシティは、次の未来のスプリントでどの程度の作業量を消化できるか想定するときに使います。過去1スプリント分のベロシティや、過去3スプリント分の平均を取って参考にするのがよいとされています。
計画のときに、このくらいは消化できてほしいという願望や目標から、スプリントにバックログアイテムを詰め込むチームも見たことがありますが、チームが疲弊して成果物の品質にも問題が発生していました。くれぐれもこのようなことにならないよう、過去の実績を使ってキャパシティを想定しましょう。
コメント