見積もり（Estimate）をしない。絶対しない。
開発において「見積もりする（Estimates）」というのは、スクラムというフレームワークによっては大きな時間がかかっている部分であり大事なアプローチになっている。
なので、スクラムにおける見積もりをする理由について考えてみる。そして、それを踏まえて見積もりのPros / Consを確認しながらも、結果として見積もりをしないという選択肢についても考えていきたい。
大きな話の流れしては、見積もりによって得るべきもの、失うものを述べた後にスクラムのムーブメントにおける見積もり（Estimate）手法の推移について見ていきながら、目指すゴールを確認していく。
極論、「なぜ見積もりが必要なのですか？」を5回自問自答してみて、自分の中で明確なメリットが答えられないのであれば、時間をかけて見積もる必要ないかもしれません。
マーティンファウラーのこの考え方も参考になります。
私にとって、見積もりは、重要な決定の手助けするときに価値があるものです。
見積もりに基づいた決定について、私の最初の例として、人員の配置があります。 組織は大抵固定のお金と人を持っていて、普通はやるべきことが多すぎます。だから決定に直面します。私たちはAとBどちらを実行するのか？ そういった決定に直面したとき、どれだけの労力(そして費用)がそれぞれ関与するのかを知ることが役立ちます。何をやるべきかという賢明な決定をするには、費用と利益の両方の感覚を持つ必要があります。
だからこそ、見積もりを求めようと考えているときはいつも、その見積もりが教えてくれる決定は何かということを常に明らかにしないといけません。
ある決定を見つけたなら、そのとき、それを知ることが見積もりに焦点を当てていることになります。なぜなら、決定は文脈を与えるからです。それはまた、望んでいる確度と精度を明らかにすべきです。
決定を理解することはまた、見積もりに関与しないかもしれない別の行動を導くかもしれません。もしかすると、タスクBよりも、タスクAが重要かもしれません。タスクBは、それを先に実行しようとすべての力を注ぐ見積もりが必要ありません。おそらく、青チームのメンバーが、緑チームともっと早くサービスを構築する方法があるはずです。見積もりによって得るべきもの / 失うもの
“見積もりをする”という行為には、”見積もりの精度を高くする”ことが目的ではない。
- 意思決定をする
- 信頼を獲得する
この2つのために見積もりをします。
そこを忘れてしまうと「見積もりが精度が高い。ベロシティーが安定している！」ということに満足してしまいます。
本来はそこが目的ではありません。
「意思決定をする」とは、何を意思決定するのかというとアイテムの優先順位を決めていく。
もう少しいうと「アイテムの価値（消化したときのインパクト値）」と他アイテムとの相関関係を考えた上での「ボトルネック」に探りを入れることで、同時にアイテムの優先順位をつけていきます。
例えば、Aというアイテムはスプリントゴールを達成するためには必須の機能（価値）で、これを完了させることで後続のアイテムが出てくる（他アイテムの相関関係）、かつAというアイテムは時間がかかるという制約が見れれば、自ずと優先度をあげて対応するべきものとわかります。
そうした判断材料の1つとして見積もる。そして、見積もりと実際の結果の「予実」から学習していきます。
言い換えれば、見積もりは必要なく、決定を下すのが目的です。
もうひとつの「信頼を獲得する」とは、プロダクトオーナーやステークホルダーから、チームへの信頼です。
ここに関しては見積もり = 計画の予測という文脈になりますが「このチームは計画どおりに開発できるのか」「生産性はどうか」といった疑問に対して、見積もりの精度をあげることで、信頼を獲得していきます。
プロダクトオーナーやステークホルダーに対して、「このプロジェクトやこの施策を2ヶ月かかります。完了させるべきアイテムを洗い出して見積もった結果がこちらです」という会話はよくあります。
逆を返せば、チームに対しての信頼度が高くなり、繰り返し正確な予測で安定した生産性を出していれば、何も言われなくなります。「あのチームは、ずっと生産性が予測との乖離がなく安定しているので、もう計画書なんていらないよ」となれば、良いチームです。
失うもの
フェーズにもよりますが、時間と心理的安全性をすり減らします。
特にこなしたスプリント回数が少ない頃は、 不透明な部分が多く精度の高い見積もりができません。
そうするとどうなるかというと
PO : このストーリーってどのぐらいで終わりそうですか？Aさん : あと1スプリント（1week）で終わります！
やるべきことは、Issueに書いておきました！1時間程度、調査して見積もりました。PO : 承知しました！それで計画立てておきます。~ 1週間後Aさん : すみません、追加でやるべきことが判明したので、あと2日程度ください！進捗は80%ぐらいです。PO : 承知しました！~ 2日後Aさん : すみません、設計的にいけていないことがレビューでわかり、今後のことを考えてもう少しリファクタリングさせて完了とさせてください！リファクタリングを考慮して、進捗は80%ぐらいです！PO : 進捗80%が2回...
となります。これはAさんが悪いわけでもPOが悪いありません。
不確実性が高いからしょうがないのです。これによってチームの雰囲気も悪くなり、再見積もりの時間もかかります。
一方、「でも、無理にでも見積もらなければ、計画自体出せなくないですか？」という疑問が残る。
それはそのとおりなので、いくつか見積もりのムーブメントを見ていきます。
1. ポイント見積もり
ストーリーポイントとはユーザーストーリー（プロダクトバックログアイテム）を見積もるための架空の単位です。つまり、作業量の定量化です。 ストーリーポイントは、何に対して見積もるのかというとストーリーが「完了」するためのすべての作業に対して見積もりです。
ユーザーストーリーが実装されたということは、ユーザーに提供できる状態であり、もちろん本番の環境で利用可能であるということです。
見積もりの方法として、一番有名なやり方としてフィボナッチ数列の値で表現するやり方があります。 フィボナッチ数列は、1,2,3,5,8…等で表現していきます。
これは、相対見積もりの一種でアイテムの「重さ」を表しています。
架空の単位なので、チームメンバー間での限定した価値間の単位です。
この手法の肝となる部分は、圧倒的なサンプル数による相対的な見積もりであることです。相対的なサイズの比較と言っても良いでしょう。
Aのアイテムに対して開発チーム全員で各々が思うストーリーポイントを提示していきます。
このときに「前回のスプリントで行った作業と同じぐらいの重さで、このチームでの「2」とつけたから今回も「2」でいこう」という経験知から来る提示を各々が行い、それが開発チーム全員の共通認識として合うかです。
その次にBのアイテムを見積もる際に、Aのアイテムの大体2倍ぐらいの作業量がありそうだということで「4」をつけると言った形で、スプリントバックログアイテムに対して見積もりをつけていき、このストーリポイントの合計値が、次のスプリントでスクラムチームが消化するべき生産性の指標となります。
一方、単位が架空なので、そのチーム限定の価値観でもあります。チームが解散して他チームでもう一度スクラムを行うことがあれば、また1からそのメンバーと価値観を作り直していきます。
つまり、スプリントを始めた頃は、ポイントによる見積もりは価値観の積み上げがないため、精度は低くなるケースが多いです。
2. 時間見積もり
つぎに時間見積もりです。これはシンプルに作業量から見て「何時間かかるか」という単位で見積もっていきます。
いつもストーリーポイントでの見積もりを比較され、エンジニアのスキルの差から完了目処にばらつきがでてくるなどの理由で、形成されがちが見積もりです。AさんとBさんではスキルに差があって、終わる時間も違うだろうとことです。
ですが、チームが成熟していれば、意外と有効な見積もり方法です。
なぜなら「時間」というのは、全員が統一してもっている価値観だからです。1時間の認識は、全員同じ1時間です。スキルの差などによるズレは会話をしてコミュニケーションを取ることで補えます。
ストーリーポイントはある意味、皆の頭の中にある空想の単位なので全体が統一された価値観を持っているかは確認仕様がありません。
何事も「単位」が揃っていることは大事です。
3. No-Estimates（見積もりをしない）
ストーリーポイントや時間による見積もりの課題としてあるのが、スプリントプランニングの時間が長くなる傾向にあることです。
ひとつひとつのアイテムに対して開発チーム全員で見積もりをしていき、ズレがある場合にはそこで議論が始めるため時間が長くなります。
特にスクラムチームが組成されてすぐの形成期や混乱期では、各々のスキルレベルや価値観も違うためズレが発生し議論も発熱していきます。
一方、チームが成熟してくると見積もりをするという作業が必要なくなる傾向があります。
いわゆる、開発チーム全員が思う、各ストーリーポイントのイメージが統一されている状態です。
例えば、ストーリーポイント「3」をつけたアイテムの作業量やアウトプットの量、質ともに全員の頭の中が一致しており、この領域までチームをもっていければ、かなり自己組織化しているに等しい状態です。
ひとつひとつのアイテムに対する作業量・質の感覚的な暗黙知が開発チームのメンバー同士で共有できている状態です。
これは、形式的に頭ではわかってやろうとしてもなかなかできないことでスクラムチームとして、近い距離で暗黙知を高めながら開発を進めたことによる賜物でしょう。
そのため、チームが成熟していない状態で導入しても、統一された暗黙知がないため生産性が安定せずに予測が難しいです。
見積もりをしないアプローチのことを「No-Estimates」と言います。
これは本来「見積もりをするな」ということではなく「見積もりに踊らされるな」というメッセージです。
スクラムに限らず、開発することで大事なのはベロシティーをあげることではなく、ユーザーに価値を届けることです。
No-Estimatesにおける生産性の指標は、消化ストーリーポイント数ではなく、消化アイテム数になります。
そのため、チームが一番作業しやすい粒度の作業量のイメージを共有して、ひとつのアイテムを作成するようにします。
例えば、ひとつのアイテムはストーリーポイントが「3」ぐらいのイメージで作成しましょう。という認識が取れていれば、生産性をアイテム数で計算しても認識が合います。
見積もりの考え方は、チーム状態に比例する
3つの見積もりに関するアプローチーを見てきましたが、結局どんな方法が良いのかは、チームのフェーズによります。
そのチームが安定しているか成熟していて、既に成果を出しているのか。
また、その事実を周りが知っているかによります。
順番としては
- ストーリーポイント見積もり
- 時間見積もり
- No-Estimates
そもそも、自己組織化したチームは、見積もりなんかどうでも良くなる。
自分たちがスプリントで安定した成果を出せることを、「自分たち自身」も「周り」も知っているからだ。
一概には言えませんが、タックマンモデルをもとに見積もり方法をマッピングするとこんな形です。
チームを組成して、まだ価値観の積み上げが行われていない場合には、信頼を獲得するのと意思決定のブレをなくすためにストーリーポイントで大幅に失敗しないようにコントロールすると良いでしょう。
あとは、こんなややこしいことを考えなくても、モブプロでやっていれば定量的な見積もりはいらないのでシンプルかもしれません。
その先
さらに「見積もり」という概念さえ、必要なくなるケースが来ると思っています。よくよく考えると少人数でガンガン進めているスタートアップが、こんな時間のかかる見積もりをしていると思うのでしょうか。少人数で近くにいながら密な会話で暗黙知を感じながら開発を進めていることで、そもそもタスク管理すらしていないかもしれません。
エンタープライズ組織でもスモールチーム化した上で、「分割統治」ではなく「統治分割」のボトムアップで文化を育てていけば、そうした状態を目指していけるでしょう。※エンタープライズアジャイルは厳しいという感じです。
今後の課題とします。
参考資料
※モブプロで有名な、Woody ZuillとChris Lucianの記事
