TechとPoemeの間

Qiita に書かないエンジニア業の話

相対見積もりが機能するために必要そうなこと

この1年、様々なチームを支援する中で共通して出てくる話題もなんとなく見えてきて、そのひとつが「相対見積もり」の取り組み方に関することだ。そして、テクニックの話の前に、相対見積もりに対する「発想」や「スタンス」に問題があって機能不全や逆効果に結果することが多いと思っていて、その話をしたい。

ちなみに、個人的には「相対見積もり」のことを「ストーリーポイント」と呼ぶのは好きじゃないんだけど、その話はまたどこかで。

ベロシティはスプリント計画の「予算」

1つのスプリントが終わった時にそのスプリント内で「完了」したプロダクト・バックログの相対見積もり値の合計のことを「ベロシティ実績」と呼ぼう。次のスプリントを計画するときに、直近の数スプリントのベロシティ実績から、次のスプリントで実現できそうなベロシティを予想する。例えば直近最大5スプリントの平均値をこのスプリントの予想ベロシティとしよう。スプリント計画では、この「予想ベロシティ」にほぼ収まるようにスプリントに取り組むプロダクト・バックログを選ぶ。ゆえに「予想ベロシティ」はスプリント計画の前提となる「予算」である。相対見積もりを行う目的は、この「予想ベロシティ」を算出することに他ならない。

誤ってもスプリントの中盤から終盤になって誰か (大抵の場合はマネージャー) が相対見積もり値の予定と現時点の実績を持ち出して「XXポイントを完了させなきゃいけないのにまだYYポイントしか出来上がってないよ」と鐘を叩いて急がせるような真似をしてはいけない。また、スプリントの終了時にスプリント計画時よりも大幅に下回ったベロシティ実績 だけ をみてチームの能力や成果を判断してはならない。一度そうしてしまったら、相対見積もりを行う開発者は次から自らの身を守るために保守的な見積もりをするようになる。開発力も見積もり能力も上がらずに相対見積もりの値だけが大きくなる様子は、インフレーションというよりスタグフレーションという例えが適切に思える。

ベロシティは変動する

「ベロシティ」という言葉は長い道のりを自動車やマラソンなどで走り切る際の「速度」にインスパイアされた比喩だ。このとき、速度には2種類ある。速度計が指し示す「瞬間的な速度」と、特定の地点からもう一つの地点までの走行距離を走行時間で割った「平均的な速度」だ。スクラムの相対見積もりにおける1スプリントの実績ベロシティは瞬間的な速度である一方、スプリント計画時に利用する予想ベロシティは平均的な速度の考え方に則って算出する。

大切なのは、車にしても人にしても、終始一定の速度である程度長い距離を走ることはない ということだ。例えばレースの中盤に差し掛かって走者の身体が温まってくることもあるし、逆に異変が生じるかもしれない。走っている道がフラットな一直線なのか、入り組んだ市街地なのか。カーブが続く道で速度計のみを凝視して運転してはならない。

だから、スプリント計画を行う時には、必ず予想ベロシティ以内にチケットを収めなければならないわけでもないし、予想ベロシティ以上を積むのを禁じるわけでもない。でも迷ったら少なく積む方を選ぶかな。少なく積んで集中して確実に仕留めるのが「リーン思考」のハズなので。

互いの「コミットメント」を信じる

日本語で「コミットメント」というと、「後に引けない程に覚悟を持った約束事」のような意味合いで使われることが多い。一方で commitment を辞書を引くとかなり多義なのだけれど、そのひとつに 「献身」 という意味がある。積極的な関わりとか、傾倒していることとか。以下の椎葉さんの記事にもあるように、どうやら「スクラムの価値基準」にあるコミットメントというのは、献身の意味で捉えるのが正解なようだ。

bufferings.hatenablog.com

コミットメントは『献身』であり、それは最終結果に対してではなく、行動や努力に対して適用するものである

相対見積もりが正しく機能して生産的なチームを支えるために一番必要なのは、スクラムチームのメンバーが互いのコミットメントを信じることができる状態なんじゃないかと思う。

マネージャーが相対見積もりを使って開発者の尻を叩くのは、開発チームのコミットメントを信じていないからではないだろうか。開発チームがベストを尽くしているなら、そんなことをしても成果は改善しない (ストーリーポイントをインフレさせればベロシティは向上させられるだろう)。コミットメントを信じられない一方で、相対見積もりという分かりやすい数字が手に入ってしまったが故に、入り組んだ道をアウトバーンと同じ速さで走るように求めてしまうことはないだろうか。「スプリントに少なめにプロダクト・バックログ・アイテムを積んで開発者は遊んだり手を抜いたりしないだろうか」という誰かからの指摘に対して「早めに全て完了すれば、プロダクト・バックログから適切なアイテムを自主的に取るか、必要に応じて生産性向上のための投資をします」と、自信を持って言えるだろうか。

そして、1人の開発者としてコミットメントを信じてもらえるように、透明性の高いプロセスで最高の成果を出すことはできているだろうか。信頼の構築は「鶏と卵」だ。「鶏と卵」の問題は自分が動かせるものから動かすしかない。

そんな前提を成立させるところからスプリントプランニングやリリースプランニングの成功は左右されるんじゃないかな、と最近は考えている。