開発工数の算出は、開発の環境や要件について大きく異なってくる事になりますがこれが大きくぶれたりするとかなり悲惨な事になったりします。
ですが、大きく安全に取っていても余計な開発費がかかることになりますし、そもそも人員を持て余す事になりそれも問題になります。
開発工数の算出の際の多くは過去の実績のナレッジなどから算出する事が多いと思いますが、そういったものがなかったりするとエンジニアのカンに任せられたりします。
しかし、カンに頼るほど危険なものはありません。
例え自分がその対応をすることになるにしても仕様に関する認識の違いからくる手戻り、技術的なスキル不足による工数の増大、プロジェクトで行う場合のメンバーの管理不足やコミュニケーション不足から工数が大幅に増えてきたりします。
※ 「迷走プロジェクト 」で触れた222の法則なんてのもよく言われる話で。
このサイトでは、画面数に大きな工数がかかるという事で工期算出の方程式を定義していますが、これもシステムの特性によって大きく異なってくるなぁと感じたりはします。
最近は確かにフロント部分は凝ったつくりが多いですが、私が担当している社内情報システムなんかは、あまりこの辺に力を入れていない（凝る必要がそれほどない）ので、この方程式とはおそらくかけ離れるんだろうなと感じます。
ファイル数×0.1（人月）と言うのも、設計しだいで大きく異なってくるでしょうしね。
どうしようもない設計されたら、頭でっかちなプログラムファイルが出来上がって、大きな工数がかかると言う事もあるでしょうから。
ここでは、工期のかかる順に「1. 画面」、「2.バッチ」、「3.ファイル」としていますが社内情報システムの場合、「1.バッチ」、「2.ファイル」、「3.画面」の順になるんじゃないかと。
まぁ、画面にそれほど工数がかからないのは、「かけられない」と言うのが本音かもしれませんが。
