これまでエンジニアやスクラムマスターとしてスクラムチームに関わって来ましたが、その過程で何度も「相対見積もり」や「ストーリーポイント」に纏わる悩みにぶち当たってきました。工数や期間での見積もりに慣れていた私にとって、それらは理解も実践もしにくい手強いものでした。

今回は、私が実際に直面した問題と、それらを打破するためチームで取り組んできたことを思い返してみようと思います。

壁1. 「相対見積もり」の考え方を理解できない

バックログ上に積まれたユーザーストーリーやエピックを見積もろうとしたとき、私たちは真っ先に「こんなコンポーネントを新規実装するだろう、おそらく2日くらい掛かる」「あの既存機能をいじる必要があるが、複雑な箇所なので時間がかかりそうだ」と具体的な作業内容とそれにかかる時間をセットでイメージしていました。それらを足し合わせて(さらにバッファを加えて)最終的な見積もりを出していました。

しかし、これは相対見積もりではありません。

相対的に見積もるには、過去に取り組んだ仕事を基準とし、その仕事との比較で考える必要があります。ストーリーポイントで見積もるにせよ、日数で見積もるにせよ、です。
これを理解し体に馴染ませるために、見積もりの度に「このストーリーは(基準としている)あの仕事と同じくらい？ 倍くらい？ 半分くらい？」と聞き合うようことを繰り返しました。今では基準と比較することにも慣れてきましたが、長いこと苦戦した問題でした。苦戦した要因は、次の『壁2』で紹介する問題と合わさって、相対見積もりをより難しく捉えていたからでもあります。

壁2. ストーリーポイントが「何を見積もる手段か」を理解していない

ストーリーポイントの考え方は、慣れるまでは分かるようで分からないものでした。分かったつもりになっていた私がよくやった失敗は、「このストーリーは基準の2倍くらいの4日程度かかりそう、であればポイントは５だ」と期間を見積もりストーリーポイントに換算してしまうことでした。これはまさしくストーリーポイントの用途を理解していないことの現れです。

ストーリーポイントは「規模」を見積もります。規模を「作業量」と言い換えることもできます。ストーリーポイントを使う理由は、作業量の見積もりと期間の見積もりを分離して行うことだと考えると分かりやすかったです。上述の失敗例では期間を見積もってからストーリーポイントに変換していますが、本来のストーリーポイントの使い方に習うなら、ストーリーポイントによって作業量を見積もり、ベロシティと照らし合わせて期間を導き出すが正解です。

私たちがこの考えに馴染めず苦労した背景には、「相対見積もりをするならストーリーポイント(またはTシャツサイズ等のそれに準ずるもの)を利用しなければならない」と思い込んでいたことがあります。また、いくつかあるストーリーポイントの利点をチームメンバー各々が断片的に知り、それを利用目的だと思い込んでいたことも要因でした。例えば「ストーリーポイントを使えば個々人の力量に依存しない見積もりができること」や「ストーリーポイントを使えば仕様が曖昧でも見積もれること」を、ストーリーポイントを採用する理由だと思っていました。
そういった利点は多々あるものの、本質的にはストーリーポイントは「期間」と「作業量」を切り離し別々に見積もる道具だと腹落ちしたことで前進しました。

とはいえ、理解できてもすぐにうまく実践できたわけではありません。

壁3. 見積もりをコミットメントと捉えてしまう

先述の2つの壁を少しずつ乗り越え、ストーリーポイントを使った相対見積もりに慣れてくると、仕様が固まっていない曖昧な案件に対しても見積もりをするようになりました。言い換えると、作業量の見積もりに「複雑さ」を加味するようになりました。

「この手の案件はステークホルダーの時間が取りにくく後になって仕様がひっくり返るケースがある」「細かい仕様は決まってないけど、この画面の機能をいじるのであればおそらく作業量はこのくらいになる」と、作業量に複雑さをかけ合わせたものにポイントをつけるようになりました。

このやり方は一長一短だとは思いますがそれはさておき、より深刻な失敗だったことは、一度見積もったポイントは根性で守り抜こうとしていたことです。もちろん期限を守ることはエンジニアには必須です。ただし見積もりはコミットメントではないということも忘れてはなりません。見積もりを基にコミットメントを決めることはありますが、見積もりのすべてがコミットメントになるわけではないのです。

“不確実性のコーン”と表現されるように、見積もりは初期段階ほど不正確です。ましてや私たちのように複雑さを加味するのであれば尚更です。ですので作業量に影響する要素が明らかになる度に再見積もりをし、その確度(実現可能性)を上げることが必要でした。
加えて、プランナーと「あとどんな情報が揃えば再見積もりができるか」や「見積もりと実働がズレたらどう対応していくか」などについて事前に認識を合わせておくことも、再見積もりを繰り返すプロセスを維持するために必要でした。

見積もりの確度がどの程度かは、見積もった私たちにしか分かりません。ですのでそれを丁寧にステークホルダーに共有し、確度に応じたプランを用意しておくところまでをセットで行うよう習慣化することで、周囲から再見積もりのプロセスの理解を得やすくなると考えています。

まとめ

「相対見積もりといえばストーリーポイントでしょ！」と勢いで始めたもののなかなか定着せず、効果を得られなかった私が、どのような問題に陥っていたかを紹介しました。

  • 相対見積もりとストーリーポイントをごちゃまぜに捉えていたこと
  • ストーリーポイントにより「作業量」を見積もり、その値から「期間」を算出する、という根本的な考え方を理解していなかったこと
  • 再見積もりをして確度をあげようとしていなかったこと

これらが主な失敗でした。乗り越えるためには失敗を自覚し向き合うことはもちろん大事ですが、併せて根気も必要だったと思います。時間をかけて実践とふりかえりを重ねてようやく今の理解度に到達できたので、総括すると「根気強く向き合う」が私たちの乗り越え方だったと言えるかもしれません。と言っても、まだ完璧な相対見積もりができているわけではないので、これからも新しい壁にぶつかりながら試行錯誤していこうと思います。

最後に、参考書籍を紹介して締めくくります。
いろいろ読みましたが、一番理解が捗ったのはアジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～でした。同じような悩みを持つ開発者の手助けになれば幸いです。