見積方法

システム開発(ソフトウェア開発)の見積りは構造的に難しいものです。
それは、ソフトウェアを作るという作業は、ハードウェアのそれに比べて、
非常に自由度が高いため、やりようによってどうにでもなる部分が多いためです。
また作成中は外から形が見えにくいため、出来上がったものが発注者の考えていたものと
大きく違っているということも良くある話しと言えるでしょう。

見積に影響する要因

見積金額に影響する要因は数多くあります。
機能例えば、会員登録、情報検索、買い物カゴなどといったシステムの機能です。機能の数と難易度が見積金額に直結します。
性能大規模なシステムでは性能の要件が機能以上に見積に影響してくる場合があります。例えばチケット発行開始直後に購入アクセスが殺到するとか、電子証券取引でミリ秒以下の決裁トランザクション処理が必要な場合とかは、その性能要件によりソフトウェアさらにはハードウェアの金額に大きく影響してきます。
デザイン特に外部サービスのシステムはデザインに大きな比重がかかる場合があります。要件定義フェーズでどのようなレベルのデザインとするのかをできるだけ具体的に詰めておくことが重要です。
発注者発注者(顧客)のスキルも見積金額に影響してきます。ソフトウェアは自由度が高いため、顧客のITスキルが低く、開発ベンダーに丸投げをしたとしたら、作った後にやり直しや修正を要求することが多くなるためです。
開発者特にシステムの難易度が高い場合は開発者の特にスキルが影響してきます。例えば数学的なパズルを解く能力は人によって10倍以上のスピードが違うことも有りえますが、その人を雇う給料は違ってせいぜい2~3倍程度です。
プラットホームどんなOS、言語、DBを使うかということも見積金額に影響してきます。その会社あるいは開発者が経験があって習熟度が高いものを選ぶのが好ましいです。
企業規模開発会社の規模が大きければその分だけ管理工数や間接工数が見積金額に反映されて高くなります。ただし、企業規模が大きい方がトラブルが発生したときの対応にも社会的立場として応じてくれやすいので、その分は保険と考えることもできます。

見積りに正解はない

正確な見積金額を算出するというアプローチはいろいろ研究されてきていますが、現実的な問題としては「正解はない」と考えてください。なぜなら、上記の要因が変わることにより見積金額の正解も変わってくるからです。
現実的なアプローチとしては「意志とコントロール」が重要です。
実現可能な範囲で見積金額を意志として決めて、それをコントロールするためにプロジェクト管理をしっかり行うことが大切です。

見積方法の例

システム開発フェーズを上流(要件定義から基本設計)と下流(詳細設計からプログラミング)にわけます。

上流フェースはやればやるだけお金がかかりますので、トップダウンで人数(担当者)と期間を決めます。
例えば全体の開発を6ヶ月と考えた場合、大体1~2ヶ月ぐらいを上流期間にするのが良いでしょう。
外部のSE(システムエンジニア)が1人で設計できる規模であれば、80万円/人月×1ヶ月。
値切れば60万円ぐらいでもSEを確保できるかも知れませんが、安かろう悪かろうにならないように気をつけてください。

下流についてはFP(ファンクションポイント)法のように、システムの規模から算出します。
例えば単純な登録画面を1P(ポイント)とすると、検索>一覧>詳細表示は3P、買い物カゴ機能は10P
などと機能の一覧にポイントを算出して合計します。
例えば1P=10万円とすれば、30Pで300万円となります。
人月60万円のプログラマは1ヶ月20日として1日3万円です。1Pの機能を3日で開発・テストできるとすれば、大体1P=10万円で妥当な見積といえます。

政治的要素

上流、下流の見積を行った後(あるいはそれと同時に)、政治的要素などにより見積金額を調整します。
リスク始めて取引する場合はお互いの流儀が違っていたりしてコミュニケーションロスや食い違いが発生します。
そのリスク分を見積金額に上乗せ(係数を掛けたり)します。
営業的値引今後の商談を期待して是非この取引を受注したい場合に、見積金額を意図的に下げることもあります。
正規な見積に値引きの項目を付ける場合もあれば、状況によっては各見積項目の金額自体で調整する場合もあるでしょう。
繁忙期受注が重なっていて人員の確保が難しい時期は、それを加味して金額が高くなる場合もあります。
出来れば開発ベンダーの閑散期に開発を依頼できると良いでしょう。

総論(まとめ)

・見積金額に正解はない。
・上流には出来るだけ優秀な人材をアサインして短期間で終わらせる。
 要件定義書と基本設計書を納品物とする。
・下流は具体的なシステムイメージと予算規模を開発ベンダーと意識合わせをする。
 開発途中に適切な進捗確認をして見積金額が膨らまないようにコントロールする。