システム開発の見積もりが高い。3社で3倍違うときの読み方

三社から見積書が届き、最高額は最低額の三倍でした。営業担当者の説明を聞いても、各社が自社の提案を勧めるため、社内では金額の話だけが残ります。

「システム開発の見積もりが高い」と感じても、最高額が間違いとは限りません。最低額が正解でもありません。僕なら総額を比べる前に、各社が何を完成させ、どの仕事を発注側へ残したかを揃えます。

選ぶべき見積もりは、差額を作業内容で説明でき、対象外の仕事を自社で担える提案です。三倍の差を値引きで埋める前に、見積書の人月、単価、バッファ、前提条件を同じ形へ直します。

システム開発の見積もりが高いかは、総額だけでは決まりません

システム開発の見積もりは、完成品の値札ではありません。まだ作っていないシステムについて、必要な作業と不確実な部分を予測した文書です。同じ依頼を受けた三社でも、完成の範囲と予測の置き方が違えば金額は変わります。

一社は要件整理から公開後の初期対応まで含め、別の一社は決まった仕様の実装だけを計上しているかもしれません。データ移行、外部サービスとの接続、セキュリティ確認、利用者による受入テストも、含む会社と対象外にする会社があります。

総額が高い会社に必要な作業が多く入っていれば、差額は過剰請求ではありません。総額が低い会社の対象外を社内で実施できるなら、低い提案が妥当な場合もあります。金額の高低だけでは、発注後に必要な支出と社内作業を比べられません。

最初に見積書の終点を確認します。要件定義の完了、検証環境への実装、本番公開、データ移行、公開後の安定稼働では、完成したと呼ぶ地点が違います。三社の終点が揃っていなければ、同じ案件の見積もりには見えても別の商品です。

開発見積もりの妥当性は、人月・単価・バッファを分けて読みます

人月は、作業量を人数と期間で表す単位です。二人月と書かれていても、二人が一か月で終える保証にはなりません。担当者を増やすと会話や確認も増えるため、作業量と日程は分けて読みます。

「開発一式」と書かれた行は、作業へ分けてもらいます。業務の聞き取り、画面設計、実装、テスト、移行、公開、進行管理のうち、何を何人月で見たのかを確認します。

各工程の成果物も聞きます。成果物が説明できない人月は、完了を判定できません。

単価を見るときは、安いか高いかだけで終えません。担当する職種、経験、役割、稼働の前提を見ます。設計や難しい連携を担う人と、決まった手順でテストする人が同じ単価なのか、管理担当者の工数が各工程へ重ねて入っていないかを確かめます。

高い単価でも、少人数で設計から公開までつなげられるなら、総人月を抑えられる場合があります。低い単価でも、引き継ぎや管理の人月が増えれば総額は上がります。単価と人数を別々に評価せず、誰が何を終えるかまでつなげます。

バッファは、仕様が変わるかもしれないという曖昧な上乗せではありません。既存データの欠損、外部サービスの制約、未確認の業務など、見積もり時点で確定できない事項と結び付けます。「どの前提が外れた場合に使う工数ですか」「前提が外れたとき、どの行が増えますか」と聞けば、危険への備えか、説明できない余白かを分けられます。

バッファを見積書の独立した行へ出さず、各工程へ含める会社もあります。表記方法の違いを理由に良し悪しを決めず、不確実な事項、金額への入れ方、追加見積もりへ切り替える条件を書面で揃えます。

安すぎるシステム開発の見積もりは、抜けた作業を疑います

最も危ないのは、安い見積もりそのものではなく、安い理由を説明できない見積もりです。既存製品を使う、対象業務を狭める、過去に検証済みの部品を使うなど、作業を減らす根拠を説明できる場合は、低い金額にも理由があります。

一方で、要件を固める仕事、移行データを整える仕事、受入テスト、公開作業が対象外なら、必要な作業は消えません。発注側が実施するか、契約後の追加見積もりとして戻ってきます。社内に担当者も時間もなければ、見かけの安さは発注後に崩れます。

安い会社には、値上がりする条件を先に聞きます。画面数が増えた場合、既存データが想定より汚れていた場合、外部サービスとの接続仕様が変わった場合に、再見積もりを始める地点と計算方法を確認します。

三社へ同じ条件を渡せていない場合は、まず依頼条件を一つの文書にまとめます。安値の理由が提案力なのか、依頼内容の読み違いなのかを分けるには、各社へ同じ質問を送り、回答を見積書へ反映してもらう必要があります。

追加費用の計算方法と承認者も、発注前に決めます。受託開発の仕様変更と追加請求を決める方法で扱った変更票まで用意すると、安い見積もりが契約後の追加請求を前提にしていないか確認できます。

高い開発見積もりには、必要な作業と過剰な提案が混ざります

高い見積もりも、自動的に安全な提案にはなりません。要件整理、テスト、移行、セキュリティ確認が丁寧に入った結果かもしれませんが、使わない機能、必要以上の性能、重複した管理作業が混ざっている可能性もあります。

人月が大きい行には、人数を減らした場合ではなく、作業を減らした場合の影響を聞きます。利用者を限定する、過去データの移行期間を短くする、外部連携を次の段階へ送るなど、事業上許容できる範囲を狭めれば、品質を落とさず金額を下げられる場合があります。

反対に、テスト担当者を外す、設計資料を納品しない、公開後の監視をなくすといった削減は、必要な仕事を後ろへ送るだけかもしれません。削る行ごとに、誰が代わりに実施し、失敗した場合に何が起きるかを確認します。

三社の平均額を妥当な予算にする方法も勧めません。比較対象の範囲が違えば、平均値にも根拠がありません。最高額と最低額の間を選ぶ前に、各社の前提を揃えた改訂見積もりを受け取ります。

値引き交渉は最後です。作業範囲を変えずに金額だけ下げると、担当者の経験、確認時間、テスト範囲など、見積書から見えにくい部分が削られるかもしれません。減額するなら、外す作業、変わる成果物、増える社内作業をセットで残します。

見積もりレビューでは、値下げより比較可能な状態を作ります

社内に技術責任者がいない場合、外部CTOへ見積もりのセカンドオピニオンを頼む選択肢があります。目的は最安値を探すことではありません。三社の提案を同じ作業範囲へ直し、経営側が引き受ける仕事まで見える状態を作ることです。

レビューには、見積書だけでなく、提案依頼書、各社の提案書、質疑回答、現在の業務資料、既存システムの構成図を渡します。資料が見積書だけでは、書かれていない作業が不要なのか、説明から漏れたのかを判定できません。

外部CTOは、大きな人月の根拠、職種の重なり、対象外、技術上の前提、公開後に残る作業を確認します。特定の開発会社を選ぶ前に、各社へ返す共通質問と、再提出してもらう書式を作る役割も担えます。

依頼時の条件が会社ごとに違うなら、見積もりレビューだけでは足りません。RFPで提案条件と回答形式を揃える方法を使い、業務の開始地点、完了地点、必須条件、提案してほしい範囲を一つの文書へ戻します。

レビューを頼む時期は、契約へ署名する前です。発注先が決まった後に値下げの根拠だけを求めても、比較条件を直しにくくなります。候補を二社か三社へ絞った段階で資料を開けば、提案を作り直す余地が残ります。

明日は「開発一式」の内訳を一枚へ移します

明日は三社の見積書を同時に開き、新しい表計算シートを一枚作ってください。縦の行には、要件整理、設計、実装、テスト、データ移行、公開、進行管理、保守を置きます。横の列には各社名を置き、人月、単価、成果物、前提、対象外を写します。

見積書に記載がない欄は、ゼロではなく空欄にします。空欄は、費用が不要という意味ではありません。社内で担うのか、別料金なのか、未検討なのかを各社へ確認します。

次に、差が大きい行を三つ選びます。「作業の開始と完了はどこですか」「人月を置いた前提は何ですか」「対象外を誰が担当しますか」という同じ質問を三社へ送ります。回答は口頭で終えず、見積書か提案書の改訂版へ入れてもらいます。

最後に、対象外の各行へ社内の担当者名と実施日を書きます。担当者を置けない仕事は、開発会社の範囲へ戻して再見積もりを頼みます。完成条件と変更時の計算方法まで揃ったら、総額を比べます。

三倍の差を作業内容で説明できないうちは、最高額を断る段階でも、最低額へ発注する段階でもありません。まず「開発一式」を分け、空欄を質問へ変えてください。差額の理由と自社の担当を一枚で説明できた提案が、発注を検討できる見積もりです。