ダメな見積もり
- 人足見積もり
エンジニアの頭数だけ揃えて、時間単価か月の単価を書いた見積書と言う見積もりしかない。過去に指示されたとおりの経験があるだけでましで、プロジェクトで必要とされるスキルセットを持っていないことはザラ。 - いいね！見積もり
顧客の予算に合わせた工数で見積もったり、見積書を作り、エンジニアを現場に送り込むか、常駐しているエンジニアに丸投げする。見積書には受託業務がふわっとしか書いておらず、現場が顧客に詳細を聞きに行くと、スコープが膨らみ、ねじ込まれる。見積もるエンジニアも営業も当事者でない。 - 勘と経験と度胸
顧客からの見積もり仕様があったとしても、過去の類似している案件と似ていると思い込みを根拠とした見積もり。ろくに要求を確認していなかったり、顧客の業種や客バカ度を考慮していなかったり、送り出すチームのエンジニアも決まっていないまま見積もるため、見積もりと実績の乖離が必ず生じるが、それはエンジニアチームのせいだと責任を押し付ける。 - ギャンプル
勘よりひどい。類似はもちろん、未経験分野でも無理くりに見積もる。それは見積もりと呼べるものではなく、博打でしかない。 - LoC
Line of Codeの略で、言語の標準的なステップ数と工数を掛け合わせて見積もる。実態は逆で、期間（時間的な長さ）や工数（工期と時間の掛け算した面積）が瀬制約条件で押しつぶされて面積の削減の辻褄をあわせるとき、生産性向上できるだろうと勝手に月あたりのステップ数を増やされたりする。同じコードを書いたとしてもIDEを使わずフルスクラッチでピュアな環境とIDEを使って書いたコード量が違うので信憑性はない。その点で、プログラムを共通化やライブラリ化せず、コピペして１−２行書き換えるような作り方をしているとコードの生産性は上がると言う矛盾を持っている。
