フィボナッチ工数見積という手法があるらしい。 jabba.cloud
凄まじい衝撃を受けたんで、早速試してみた。
まだ開発に入ってないので、今回、適用してみたのは見積フェーズのみ。
それだけでも、十分に有用だという実感があった。
超ざっくり説明すると、以下の段取りで進める。
- 作業を細かい単位に切り出してチケット化する
- 各チケットに、２、３、５、８、１３、２１のどれかのポイントを付ける。重いタスク程、高ポイント。
（ポイントに単位は無い。ただの数字）
詳細はリンク先を参照して下さい。
ちゃんと適用する場合は、開発フェーズにも突っ込みます。そして今回初めて使うんで、過去の累積などは無い。
今回はポイントに３４も追加して実践しました。
以下、やってみた感想。
実践し、自分なりに感じたメリットなどを書いています。
また、上記のリンク先の記事を先に読んでおいた方が、以下で何を言っているのか分かりやすいかと思います。
重いタスクの見積がやりやすい
以下、要約して抜粋した内容。
ポイントを１、２、３、..８、９、１０と連続した数字ではなくフィボナッチ数列にしているのには理由がある。
実務においてタスクの重さは指数関数的に伸びていく。重量なタスクにはモノによって大きな差が出る。 また、重くなるにしたがって差を大きくすることでその差をより意識するように仕向ける。
軽いタスクの場合、２や３の差は小さく多少の誤差が出ても大きな影響は無い。見積もりの重要性は重いタスクほどにある。
重いタスクを「９かな？それとも１０かな？」とじっくり考えても９と１０の差は１でしかでなく、９と１０の差を意識するのが難しくなる。
ここをフィボナッチにすることで、１３と２１の差はとても大きく、「あれが２１だったらこれは１３にすべきだろ」と、より明確に区別することが可能になる。
これは本当に目から鱗。
特に、未知の部分が多い機能の実装については、見積が非常に難しい。
これは…5人日？6人日？？といくら考えても、答えなんて出てこない。
が、少し手を動かしてみて
「おおお！これは難しい！２１ポイントで。いや、まだ××という問題もあるぞ…。それなら、その次の３４ポイントだな。」
といった感じで、次の数字が明確化されているので、重いタスクに数字を付ける行為がやりやすい。
２１ポイントじゃ低すぎるな。じゃ、２５ポイント？２６ポイント…？と、変に悩まなくて済む。
タスクの重さを測る事に注力できる
人日（人月）で考えないので、余計な考えを挟まなくて済む。
具体的には、
「これは３人日で。いや…３日で出来るかな…？」とか、
「自分でやったら２日で終わるけど、Aさんがやったら４日かな…」とか、
「これは１日で終わってほしいけど、新人のB君にタスクを振る事を考えたら、３日…いやいや取り過ぎか。２日かな。」
とか、そんな感じの内容。
人日で考えると、どうしても作業担当者の開発力にも視点が行きがちになる。
その点、単位の無いポイントで考えると、単純にタスクの重さを測る事だけに注力できる。
提案から実践までのハードルが低い
業務改善や新しい手法の導入は、受け入れられにくい事も多い。
慣れ親しんだ業務のやり方を変えたり、新しいツールの使い方を覚えたり、そのツールにおける概念を覚えたりするのに、抵抗感を感じる人が少なからず居るからだ。
そういう人達を説得するために、デモを見せたり、資料を作ったり、ツールを使うための環境を整えたり、様々な検証をしたり・・・といった作業は、かなり骨が折れる。
『好奇心＞労力』という図式が成り立っているうちはいいが、そのうち通常業務が忙しくなるか、「お前、仕事しないで何やってんの？」という冷ややかな視線と言葉で徐々にテンションが下がってくるかで、
『好奇心＜労力』となってしまった瞬間に、提案活動は停滞もしくは終焉に向かう。
その点、フィボナッチ工数見積は、提案のハードルがめちゃめちゃ低い。
準備なんてほとんど要らないし、必要なツールも無い。効果や背景も、上記のブログ１記事を見てもらうだけで十分。
また、見積について、確固たる手法を確立させている人は、それほど多くないと思う。
それこそ、見積もりなんて星占いレベルという意見もあるぐらいだ。毎回毎回、確たる拠り所や足がかりは無く、これなら絶対に行ける！という確証など無いまま、内心恐る恐る出しているというのが実情だと思う。
つまり、見積については、多くの人が拠り所を求めている。何かいい方法はないものか… と常に頭を抱えている。
組織において、提案を受け入れやすい土台が既に整っている可能性は高い。
加えて、「この言語は最高だ！」「このフレームワークは最も洗練されている！」といったポリシーを持っている人は居ても、見積手法についてポリシーを持っている人など皆無に等しい。
その点でも、スムーズに受け入れてもらいやすい材料になっている。
以上が、感想。
実践した結果、ポイントとボリュームを見ると、概ね正解に近そうな数字が出た。
でも最終的には人日（人月）で資料を作らないといけなかったので、試しにちょっとだけポイントあたりの労力を測ってみた。
具体的には５ポイントのタスクを消化し、何人日が妥当だろうか。と検証してみた。
すると、今回のプロジェクトでは、５ポイントが大体１人日くらいかな？という事が分かり、その係数を全体のポイントに掛け、見積の数字とした。
結果、割と正解に近い数字が出たと思う。人日で見積もったとしても、大体これぐらいになったかな。という感触はあった。
仮に数字が大きく間違ったとしても、それは掛ける係数が間違っていただけで、手法としては間違っていないんじゃないかと思う。
正直、人日で見積もるよりも遥かに頭を悩ませる材料が少ないので、見積に苦労しているエンジニアは、是非一度試してみてはどうでしょう？
他にも実践する人が出てきて、成功例や失敗例、そして運用の知見がもっとネット上に蓄積されて行かないかな、と願い、微力ながらもそれに協力できないかと今回のエントリにしてみた。
