Murga

個人的に言いたいコト・主張・気持ち。

工数見積にはフィボナッチ数を使う

工数を見積もる時はフィボナッチ数を使うと良いよ、という、今更な話を書く。自分は何気なく使っていたのだが、知らない人もいるみたいだったので書いてみる。

フィボナッチ数とは、

0, 1, 2, 3, 5, 8, 13, 21

といった数列。「2つ前の数」と「1つ前の数」を足した数を並べていったモノだ。

この数列をグラフにすると、いわゆる「指数関数的な」形を示す。最初はゆるやかに増加している曲線が、段々と急激な増加を示す、アレである。

このフィボナッチ数を使って工数を見積もると、ズレが少なく済むというのだ。

大きな数は細かく見積もっても意味がない

自分はこうした数学的な知識に疎いので、理屈がちゃんと理解できていないが、大きな数の中で小さな差を比べてもよく分からんから、大きな数は大雑把に扱えばいい、という意味合いになるのかなと思う。

例えば、ある作業を完了するのに1時間かかるか1週間かかるか、という単位は大きな差がある。しかし、100日かかるのか101日かかるのか、といった単位だと、1日という単位は大した差ではなくなる。それに、それほど大きな規模の場合に、果たしてそれが見積どおりに実現されるかは疑問である。

だったら最初から「100か101か」で悩むことは止めて、「だいたい100」と見積もれば良いだろう、ということだ。

見積と実績のズレが均される

勿論コレは、そもそもそんな大きな粒度で見積をするな、という忠告でもある。

見積で使う数字は、フィボナッチ数列の最初の方の小さな方に留めるよう工夫すれば、その間でのズレは比較的小さく済む。

例えば、1つのタスクは1日で完了する粒度に分割すれば、そのタスクが1時間・2時間・3時間・5時間・8時間のどのくらいで終わるか、と見積もれるようになる。この数で考えていれば、「1時間で済むと思ったら2時間かかった」というズレも、「8時間かかるとおもったら5時間で済んだ」というズレも、結果的に大きなズレにはならず、中和されるというワケだ。

時間で見積もる際は「0.5」も使うと良いかと

フィボナッチ数を使った見積は、「時間」を単位にしても良いし、「作業の難易度」を評価する値に使っても良い。時間で見積もる場合は、0.5時間を加えてやると、より見積もりやすいだろう。すなわち、

  • 0.5時間 (すぐに終わるタスク)
  • 1時間
  • 2時間
  • 3時間 (この量のタスクを2・3こなすのが1日の限度)
  • 5時間 (半日はかかるタスク)
  • 8時間 (まる一日かかるタスク)

という度合いだ。

そして、8時間を超えそうだと判断したタスクは、2つ・3つに細分化すれば良い。

似たような指数・対数を使った考え方

フィボナッチ数は

  • 1・2・3・5・8・13…

という数だったが、見積に使えそうな指数・対数は他にもあるようだ。

サイトが消えているので Archive.org で紹介するが、BugbearR さんの「開発規約」より。

  • 10n (とても大雑把に考える場合)
    • 1, 10, 100, 1000, 10000, 100000, 1000000
  • ほぼ 2.2n (おすすめ)
    • 1, 2, 5, 10, 20, 50, 100, 200, 500, 1000
  • 2n (機械的に処理する場合)
    • 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024

一番上の「10n」を除くと、フィボナッチ数列とよく似た数に収まっていると思う。フィボナッチ数が覚えにくい場合は、「1・2・5・10」や、倍々ケームの「1・2・4・8」でも大差は出ないので、これらを使っても良いだろう。

ちなみに、こうした見積がうまくいく理由も数学的に説明されていた。

なぜ対数だとうまく行くか?

常に2倍の見積もり誤差が発生すると仮定すると、

n ≒ N n/2 <= N <= n*2 n: 見積もった値 N: 実際の値

となる。

変形すると、

2^t ≒ N 2^(t-1) <= N <= 2^(t+1) ただし t = log_2(n)

となる。

実際の工数が見積から2倍ズレていたとしても、こうした対数を使っておけばその範囲内に収まるから、大きなズレは起こりにくいということですな。


というワケで、数学が苦手な人も、「フィボナッチ数」だけは覚えておいて損はないだろう。