基礎知識

見積もりと工数はどう決まるのか。営業が知っておくべき価格の構造

見積もりの金額はどう決まっているのか。なぜ想定より高いのか。この記事では、価格の構造を分解し、営業として何を聞き、どう交渉すればよいかを整理します。

人月という単位

システム開発の見積もりは、多くの場合「人月」という単位で計算されます。1人が1か月働く量を1人月とし、必要な量に単価を掛けて総額を出します。

たとえば5人月の作業に、1人月80万円の単価を掛ければ400万円になります。単純な計算ですが、ここに2つの落とし穴があります。

ひとつは、人数と期間は交換できないこと。5人月だからといって、5人で1か月では終わりません。人が増えれば連携の手間が増え、教育の時間も必要になります。

もうひとつは、単価が人によって違うこと。経験や担当工程によって、同じ1人月でも60万円から120万円まで開きがあります。「安い見積もり」は、経験の浅い人員を前提にしている場合があります。

工数を決める要素

作業量がどこで決まるかを分解します。

• 機能の数／画面の数、処理の種類。最も分かりやすい要素
• 例外処理の量／異常時の扱い。ここが工数の大半を占めることがある
• 既存システムとの連携／相手の仕様が不明だと、調査だけで時間がかかる
• データの状態／整理されていないデータの移行は、想定の数倍かかることがある
• 求められる品質／社内利用と、不特定多数の顧客向けでは試験の量が違う
• 関係者の数／確認と調整の時間。技術とは別の要因

顧客が意識しているのは1つ目だけである場合がほとんどです。「画面が5つだから安いはず」という感覚と、実際の見積もりが乖離する原因はここにあります。

営業として、2〜6の存在を説明できるかどうかが交渉の質を決めます。

見積もりに含まれていないもの

後から追加費用の議論になりやすい項目があります。事前に確認しておくべきものです。

要件定義の工数。何を作るか決める作業自体に時間がかかります。ここを含まない見積もりは、前提が確定していることになります。

試験と修正。作って終わりではなく、検証と手直しの期間が必要です。

データの移行。既存データを新システムに移す作業。量と状態次第で大きく変わります。

教育と引き継ぎ。使う人への説明、手順書の作成。

稼働後の保守。不具合対応、問い合わせ対応。月額で別途必要になることが一般的です。

これらを見積もりの前提として明記しておかないと、必ず後で揉めます。

なぜ想定より膨らむのか

見積もりが当初より増える典型的な原因を挙げます。

要件が固まっていなかった。着手後に「これも必要」が追加される。最も多い原因です。

既存システムの実態が想定と違った。資料と実際の動作が異なる、仕様書が存在しない。

データの状態が悪かった。重複、表記揺れ、欠損。移行前の整備に時間がかかります。

関係者が増えた。途中から別部署の要望が入る。調整の時間が積み上がります。

いずれも技術的な問題ではありません。事前の確認で防げるものがほとんどです。営業が商談の段階でどこまで聞けるかが、後の混乱を左右します。

値引き要請への向き合い方

価格交渉になったとき、選択肢は3つあります。

①範囲を減らす。最も健全な方法です。機能を絞る、段階的に作る。金額を下げるなら、対応する内容も減らします。

②品質の水準を調整する。試験の範囲、対応する端末の種類。ただし下げすぎると、後で問題になります。

③単価を下げる。経験の浅い人員を充てることになります。結果として工数が増え、総額が変わらないこともあります。

避けるべきは、範囲を変えずに金額だけ下げることです。無理な条件で受注した案件は、赤字になるか、品質を落とすかのどちらかに向かいます。

「この金額なら、ここまでです」と範囲で答えられるかどうかが、営業としての交渉力になります。

精度を上げるために聞くこと

見積もりの精度は、商談で得た情報の質で決まります。聞くべき項目を挙げます。

いまの業務の流れ。何を、誰が、どの順で行っているか。

既存システムの資料の有無。仕様書があるか、作った会社と連絡が取れるか。

データの量と状態。件数、形式、整理されているか。可能なら実物を見せてもらいます。

使う人の数と種類。社内何名か、社外の顧客も使うか。

絶対に外せない条件。期限、予算、法令上の要件。ここが動かせない制約になります。

これらを持ち帰れば、エンジニア側の見積もり精度が大きく上がります。情報が不足していると、リスクを見込んで高めの数字になります。

段階に分ける提案

最後に、実務で有効な進め方を示します。

全体を一括で見積もるのではなく、段階に分ける方法です。

第一段階として、要件定義だけを契約する。何を作るかを決める作業を、独立した契約にします。この段階で全体像が見え、次の見積もりの精度が上がります。

第二段階で、優先度の高い機能から作る。すべてを一度に作らず、動くものを早く出します。

この方式の利点は、双方のリスクが小さいことです。顧客は巨額の一括契約を避けられ、開発側は不確定な要件を丸ごと引き受けずに済みます。

とくにAI活用の案件では、この進め方が推奨されます。実現可能性が事前に確定しないためです。

契約形態による違い

見積もりの前提として、契約の形が2種類あることを押さえておきます。

請負契約。完成を約束し、対価を受け取る形です。金額が固定されるため顧客は予算を管理しやすい一方、要件が確定していないと開発側のリスクが大きくなります。

準委任契約。作業に対して対価を払う形です。完成の義務は負いません。要件が変わりやすい案件や、検証が中心の工程に向きます。

営業として重要なのは、どちらで受けるかで見積もりの意味が変わることです。請負なら想定外の作業も自社負担になり、準委任なら稼働時間で精算されます。

要件が固まっていない段階で請負を約束するのは、最も危険な受け方です。

顧客への説明のしかた

金額の根拠をどう伝えるかで、交渉の展開が変わります。

内訳を工程で示す。要件定義、設計、実装、試験、移行。どこにどれだけかかるかを分けると、削れる部分の議論ができます。

比較対象を出す。「同規模の案件では通常これくらい」という相場観を示すと、金額の妥当性が伝わります。

安くする方法を一緒に示す。範囲を絞る、段階に分ける、既製品を使う。選択肢を出せる営業は、値引き要請そのものを減らせます。

高い理由を具体的に説明する。「データの整備に時間がかかる」「既存システムの調査が必要」。理由が具体的なほど、納得を得やすくなります。