誰？
もともとエンジニアでIT畑に入るも社内のやんごとなき理由により営業畑と技術畑を何往復も行ったり来たり。
それを１０年ほど繰り返した後、成り行きで独立起業してしまい８年経った成り行き系エンジニア兼営業です。
自身も開発案件をこなしながら、営業としても活動してます。
営業に費やす作業も馬鹿にならないのでツール化して営業活動をハック、作業にかかる時間をどんどん短縮していくことを生きがい？にしています。営業活動は面談と移動時間以外ほとんど自動化できてるくらいに。。したいなあと。（願望）
ちなみにこの記事で話題にしている見積書はだいたい年間80から120くらい作っている感じです。
"見積り"こそ会社運営の生命線
なんのかんの言いつつも、見積りが大事。
どれだけプレゼンが素晴らしくとも、どんな大企業と取引ができるチャンスに恵まれたとしても、見積が甘すぎて赤字になってしまっては目もあてられません。
- 「やっぱり思ってたより時間がかかりました！」
- 「このリスクを考慮していませんでした！」
では通りません。この時間で出来ますっていうのが見積書ですから。。
見積ミスがたてこんでくると、会社も傾いてきたり、社内社外の信用を失ったりと色々マズイことになっちゃいますね。
(残念ながら)見積作業はお金にはなりません
いや受注すれば売上につながるんじゃというツッコミは置いといて、時間を掛けてみっちりと見積をすれば精度はあがります。
しかしながらお客さんの方でも「予算編成のために、明日中に概算額だけ知りたい！」等突発イベントが発生する場合も割りとあります。（そもそものんびり見積りしてる暇なんて無いですし。。）
どんな手段を使っても、ささっと精度のいい見積りを叩き出してスピーディーに受注するぞというのがこのシリーズのコンセプトです。
本題：工数内訳にはフィボナッチ数列を使う
というわけで、この記事で伝えたいことはこの一つだけです。
「工数内訳にはフィボナッチ数列を使う」
ご存知でしょうか、フィボナッチ数列を。。私も数年前にこの見積方法を知った時に思い出せず焦りました。
すなわち、「1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…」の数列ですね。
これら数列を使って工数見積を行います。
例：イケてない見積り
| 作業名 | 工数(日) |
|---|---|
| 要件定義 | 3 |
| 基本設計（テーブル定義） | 4 |
| 基本設計（画面遷移図） | 4 |
| 製造（プログラムA） | 5 |
| 製造（プログラムB） | 6 |
至って普通っぽい工数表で何がいけないんだろう？とお思いかもしれませんが、例えば製造（プログラムA）と（プログラムB）について1日差の理由を質問された場合、明確な理由を述べられるでしょうか？
まだ１日と２日という見積工数では比較してほぼ２倍等と説明できると思いますが、５日と６日では１日の差を説明できる明確な理由は出ないと思います。
- 「頑張ればプログラムBもAと同じく５日で行けるでしょう？」
- 「そもそも基本設計も何で４日なんです？」
など木を見て森を見ず的に全ての項目を再レビューする必要に迫られる可能性も。。見積やりなおしたくないですよね。。
例：そこでフィボナッチ登場
| 作業名 | 工数(日) |
|---|---|
| 要件定義 | 3 |
| 基本設計（テーブル定義） | 5 |
| 基本設計（画面遷移図） | 5 |
| 製造（プログラムA） | 5 |
| 製造（プログラムB） | 8 |
工数の算出に使う日数を「1, 1, 2, 3, 5, 8…」のフィボナッチ数列から割り当てます。
フィボナッチ数列の特性として、数字が大きくなるほど数と数との間隔がだんだん大きくなり、割り当てる工数の数字が差別化できます。
- 「ああ、プログラムAとBは難易度が違うんだな」
- 「テーブル定義と画面遷移については大体同じなんだな」
より直感的に把握できる工数リストになっていると思いませんか？
よくよく見ると、表している工数のパターンが3，5，8だけの３パターンになっていることにも気づかれたのでは無いかと思います。悪い例では3,4,5,6と少しだけ複雑ですよね。
数字で表現するパターンを少なくする事は商談を進めていく上、メリットでもあります。
人が記憶として理解できる限界値として「マジックナンバー７（±2）」というものがあるからです。
記憶力の高い人でも、7＋2＝9程度しか記憶できない。
少ない人なら、7-2＝5つ程度しか認識できないということです。
だから何？これは意外に重要で、見積のレビューをお客さんにしてもらう中で情報量をシンプルに減らせるというメリットがあります。また、フィボナッチ数列は「1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…」と続いていきますが、システム開発において日数で見積もる場合13以降の見積日数はざっくり大きくとりすぎているのでせめて1,2,3,5,8の5パターンに収まるよう工程を切り分け直したほうがスッキリするかと私の経験上考えます。
レビューの際に見積り工数を細かくチェックしすぎて、
- 「一度持ち帰って検討します」
- 「根拠となる補足資料を追加で出してもらえますか？」
となったら更に見積作業に時間を費やすことになります。困りますよね。お互いに。
丁寧で分厚い資料がついてる豪華な見積書も結構ですが、ファストかつスマートな見積りが私は好きです＾＾；
と、いうわけでフィボナッチ配列でわかりやすい見積工数を提示する、というちょろっとハックでございました！