ユーザーストーリーの見積りになぜフィボナッチ数を使うのか？

2018.05.15

Dr. Jeff Sutherland
（翻訳：和田 圭介、梅澤 友紀）

ユーザーストーリーの見積りにフィボナッチ数列を使うことについては、頻繁な議論があります。見積りは、完璧なツールではありませんが、計画作業に欠かすことは出来ません。

ユーザーストーリーの見積りは、デルファイ法を開発した1948年のアメリカ国防総省による調査に基づきます。デルファイ法は1960年代までに公式化され、ランド社（アメリカの軍事関連のシンクタンク）のホームページに多くの論文が掲載されています。まず第一に、ランド社の研究者は、不正確な見積りの典型的な原因である、他の人に意見を合わせなければいけないというプレッシャーを避けるため、各自が他の人の影響を受けずに見積りを実施することに決めました。課題に対し、皆、異なる見解を持っているので、まず初めに、見積りは別々に行います。個別の見積りの後、見積りの高かった人と低かった人に自分の見解を述べてもらいます。そして、もう一度、各自が別々に見積りをします。ランド社のホームページでは、デルファイ法における意見の集約を証明する論文を読むことが出来ます。

次に、ランド社の研究者は、見積りをする人が選択した数が見積りに与える影響について調査し、一次関数の数列（例：1,2,3,4,5..）による見積りは指数関数の数列（例：1,2,4,8,16..）による見積りよりも不正確になるということを発見しました。このことについては、今も数学的な議論がされています。統計学的に最も確からしい見積りを出したい場合は指数関数の数列を使用します。フィボナッチ数は、指数関数そのものではありませんが、全ての生態系に見られる成長のパターンであるという利点があります。フィボナッチ数列は自然界で頻繁に現れるので、我々はフィボナッチ数に非常に慣れ親しんでおり、例えば、洋服のサイズを決めるのにもフィボナッチ数を使っています。Tシャツのサイズはフィボナッチ数列なのです。デベロッパーの中には数字を嫌う人もいますが（普段はコンピューターを使っているにも関わらず！！）、そうした場合であっても、Tシャツサイズの見積りをすれば、その後、簡単に数字に変換することができます。

マイクロソフトは近年、IEEEの受賞論文＊において、この見積りに関する調査を再び行いました。調査の結果、マイクロソフトは、プロジェクトにおける時間見積りを廃止しました。
*Scrum + Engineering Practices: Experiences of Three Microsoft Teams.（See Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan. 2012年）

こうしてアジャイルのコミュニティでは、フィボナッチ数列を見積りに使うことに意見がまとまりました。しかしながら、残念なことに、多くのアジャイルチームでは、フィボナッチ数列を正しく使うことができておらず、特定のフィボナッチ数に全員を合意させようとして、強制的な合意による的はずれな見積りが行われています。これはまさにランド社の研究者がデルファイ法を使って避けようとしたことにも関わらずです。

繰り返し言いますが、ランド社の研究者は、時間による見積りが非常に高い確率で間違っていることを証明しています。見積もる人がエキスパートだとしても、そうなのです。時間による見積り自体が問題なのです。エビデンスに基づく正しい見積りを実践したいなら、フィボナッチ数による相対見積りをすべきです。そうすれば、これまでよりも遥かに正確な見積りをすることが出来るようになります。