システム開発の相見積もり、比べ方と断り方

システム開発を外部に依頼するとき、複数の開発会社から見積もりを取って比べる相見積もりは、発注側にとって基本的な手順です。ところが実際には、届いた見積書の金額だけを見比べて一番安い会社を選び、開発が始まってから想定外の追加費用に悩まされる、ということがよく起きます。

相見積もりで比較がうまくいかない原因の多くは、依頼の段階にあります。各社に渡した条件がそろっていなければ、返ってくる見積もりは前提の違う数字の集まりになり、比べること自体ができません。また、選ばなかった会社への断り方に迷い、連絡を後回しにしてしまう担当者も少なくありません。

相見積もりは、価格を下げるための交渉材料ではなく、自社の依頼内容に対して各社がどう理解し、どう進めようとしているかを比べる機会です。比べ方と断り方の両方を最初に決めておけば、手間をかけた分だけ判断の精度が上がります。

この記事では、相見積もりを依頼する前に決めること、条件のそろえ方、見積書の前提の読み比べ方、金額差が大きいときの判断、そして断るときの連絡の仕方と文例を、発注側の立場で解説します。見積書の内訳や費用が変わる要素そのものについては、見積もりの基本を扱った記事に譲り、ここでは比較と判断の手順に絞ります。

相見積もりを依頼する前に決めておくこと

相見積もりを取る前に、社内で三つのことを決めておきます。何社に依頼するか、何を基準に比べるか、いつまでに決めるかです。これが決まっていないと、見積もりが届いてから比較の軸を探すことになり、金額という分かりやすい数字に引きずられます。

決めること	考え方
依頼する社数	比較の手間を考えると、2〜4社程度が扱いやすい。社数を増やすほど質問への対応や比較表の作成に時間がかかる
比較の基準	金額のほか、作業範囲、進め方、体制、保守の条件など。基準ごとにどれを重視するかの順位も決めておく
判断の時期	見積もりの提出期限、質問の受付期限、社内で決める日、結果を連絡する日

比較の基準は、案件の性質によって重みが変わります。業務の流れがはっきりしていて作るものが固まっている案件なら、金額と納期の比重を高くしてかまいません。一方、要件がまだ固まっていない案件や、既存システムとの連携が多い案件では、金額よりも、不明点をどう扱おうとしているか、要件を詰める工程をどう組んでいるかを重く見るほうが失敗を避けられます。

見積もりの精度は、依頼の段階でどこまで内容が決まっているかで変わります。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」の解説では、システム化の計画段階では試算見積レベル、要件定義を終えた段階では概算見積レベルの見積提案を受け、画面や帳票などを決める外部設計の段階で確定見積が可能になる、という考え方が示されています。要件定義が終わっていない段階で取る相見積もりは、あくまで概算の比較だと割り切ることが大切です。

この段階で、相見積もりであることを各社に伝えるかも決めておきます。伝えずに依頼すると、開発会社は受注が決まったものと受け止めて準備を進めてしまうことがあります。「複数社にご相談しています」と最初に一言添えておけば、相手も見積もりにかける時間を判断でき、後で断るときの心理的な負担も軽くなります。

参考：情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈第二版〉／IPA（情報処理推進機構）

各社に渡す条件をそろえる

相見積もりで最も効くのは、すべての会社に同じ資料と同じ情報を渡すことです。打ち合わせの中で口頭で補足した内容が会社ごとに違えば、見積もりの前提もずれます。依頼の資料は一つにまとめ、補足は文書で全社に共有します。

依頼の資料には、少なくとも次の内容を入れておきます。

• システムで解決したい課題と、対象となる業務の範囲
• 必ず実現したい機能と、できれば欲しい機能の区別
• 利用者の人数、社外の人が使うかどうか
• 既存システムや外部サービスとの連携の有無
• データ移行の有無と、移行するデータのおおよその量
• 希望する稼働開始の時期と、予算の上限
• 見積もりに含めてほしい範囲（要件定義、設計、開発、テスト、導入支援、保守など）
• 見積書の形式の希望（工程別の内訳、前提条件の明記など）

このうち、見積もりに含めてほしい範囲と見積書の形式は、比較のしやすさを大きく左右します。範囲を指定しないと、ある会社は保守まで含め、別の会社は開発だけの金額を出す、といった違いが生まれます。工程別の内訳と前提条件を書いてもらうよう依頼しておけば、後で表にまとめる作業が楽になります。

各社から質問を受けたら、質問と回答を一覧にして、全社に同じ内容を返します。ある会社の質問で明らかになった前提を他の会社が知らないままだと、その会社だけが違う前提で見積もることになります。質問した会社の名前は伏せて共有すれば問題ありません。

依頼の前には、秘密保持契約を結ぶかどうかも検討します。業務の流れや取引先の情報を詳しく渡すほど、見積もりの精度は上がりますが、情報を外に出す量も増えます。また、各社から受け取った提案書に含まれる進め方のアイデアや技術的な工夫を、別の会社に伝えて「同じことを安くできないか」と求めるのは避けてください。相手の信頼を損なうだけでなく、次に相談したときに本気の提案を受けにくくなります。

見積書の前提を読み比べる

見積書が届いたら、金額を見る前に前提条件を読みます。前提条件には、その金額がどういう条件で成り立っているかが書かれています。前提が違えば、金額の差は価格の差ではなく、範囲の差です。

比べるときは、各社の見積書を一枚の表に書き写すと違いが見えやすくなります。行に比べる項目、列に会社を並べ、見積書に書かれていない項目は空欄のままにしておきます。空欄が多い会社には、その項目が含まれているのかを質問します。

比べる項目	読むポイント
工程ごとの金額と工数	どの工程に多くの工数を見ているか。テストや要件定義が極端に少なくないか
含まれる作業と含まれない作業	データ移行、操作説明、本番環境の構築、保守が含まれているか
前提としている数量	画面数、帳票数、連携先の数、移行データの件数をいくつで見積もっているか
発注側の作業	テストデータの準備や受入テスト、資料の提供など、発注側が担う前提の作業は何か
不明点の扱い	決まっていない事項を、仮の前提で含めたのか、除外したのか、別途見積もりとしたのか
契約形態と支払条件	請負か準委任か。工程ごとに契約を分ける前提か。支払の時期
見積もりの有効期限	いつまでにその金額で発注できるか

なかでも重要なのが、不明点の扱いと発注側の作業です。要件が固まっていない部分を除外して安く見せている見積もりと、仮の前提で含めて高くなっている見積もりは、一見すると後者が不利に見えます。しかし、除外された部分は後で追加費用として請求されるため、最終的な支払額は逆転することがあります。

工程ごとに契約を分ける提案かどうかも確認します。前述のモデル契約では、工程ごとに個別契約を結ぶ多段階契約と、曖昧さがある段階の見積もりを要件が明確になった段階で見積もり直す再見積りの考え方が採用されています。要件定義の後で再見積もりを行う前提の見積書は、総額が仮の数字であることを示しています。この場合は、総額よりも、最初の工程の金額と、再見積もりの際にどんな条件で金額が変わるのかを比べてください。

前提条件を読んでも分からない点は、遠慮なく質問します。質問への回答の仕方も比較の材料になります。回答が具体的で、分からないことを分からないと答える会社は、開発が始まってからのやり取りも期待しやすいといえます。

金額の差が大きいときはどう判断するか

条件をそろえて依頼しても、見積もりの金額に倍以上の差が出ることは珍しくありません。金額の差が大きいときは、安い見積もりと高い見積もりのどちらかが誤っていると決めつけず、差の理由を特定します。

差が出ている場所	考えられる理由	確認すること
開発の工数	既製の部品やサービスを使う前提か、一から作る前提か	使う部品やサービスと、その利用料が別にかかるか
要件定義や設計の工数	業務の整理を開発会社がどこまで担う前提か	発注側に求める作業と、成果物として何が出てくるか
テストの工数	テストの範囲や記録の残し方の違い	テスト計画書と結果報告書が成果物に含まれるか
全体に一律の差	体制や単価、リスクの見込み方の違い	担当者の人数と役割、リスクとして見込んだ項目

差の理由が分かったら、自社の案件にとってどちらの前提が妥当かを判断します。たとえば、既製のサービスを組み合わせて安く仕上げる提案は、業務の流れがサービスに合わせられるなら合理的です。一方、独自の業務ルールが多く、サービスに合わせると現場の負担が増えるなら、一から作る前提の見積もりのほうが実態に合っています。

判断の目安は次のとおりです。

• 前提をそろえ直すと差が小さくなるなら、残りの差は体制や進め方の違いとして評価する
• 安い見積もりが不明点を除外しているなら、除外部分の見込み額を加えてから比べる
• 高い見積もりが自社の想定していない作業を含んでいるなら、その作業が本当に必要かを確かめる
• どの見積もりも予算を大きく超えるなら、範囲を絞るか、最初の工程だけを発注して要件を固めてから見積もり直す

どの選択肢を取るにしても、ある会社の金額を別の会社に示して値引きを求める使い方は勧めません。前提の違う金額を突きつけても、相手は範囲を削るか品質を落とすことで応じるしかなく、結果として自社が困ります。金額を下げたいなら、どの範囲を削れば下がるかを相談するほうが建設的です。

断るときの連絡の仕方と文例

依頼先が決まったら、選ばなかった会社にもできるだけ早く結果を伝えます。開発会社は見積もりのために、要件の読み込みや体制の仮押さえをしています。結果が分からないままだと、その人員を他の仕事に回せません。社内で決まった日か、遅くとも数日のうちに連絡するのが礼儀です。

断りの連絡に入れる内容は、見積もりへのお礼、今回は依頼を見送ること、差し支えない範囲での理由、今後の関係についての一言の四つで足ります。他社の社名や金額を伝える必要はありません。理由を聞かれた場合は、比較の基準に沿って簡潔に答えると、相手にとっても次の提案に生かせる情報になります。

理由ごとの言い回しの例を挙げます。いずれもメールの一部として使える短い表現です。

場面	文例
書き出しのお礼	このたびはお忙しいところ、詳細なお見積もりとご提案をいただきありがとうございました。
結論（共通）	社内で検討した結果、今回は別の会社にお願いすることになりました。
予算が理由	ご提案の内容は大変参考になりましたが、今回は予算の範囲で進められる形を優先する判断となりました。
進め方や範囲が理由	今回は、要件の整理から段階的に進める進め方を重視して判断いたしました。
時期が理由	稼働開始の時期を優先した結果、今回は見送らせていただくことになりました。
案件自体を見送る	社内の事情により、今回の開発自体をいったん見合わせることになりました。
今後の関係	また別の機会にご相談させていただくことがあるかと存じますので、その際はどうぞよろしくお願いいたします。

案件自体を見送る場合は、その旨を正直に伝えてください。他社に決めたと伝えておきながら後で同じ案件を再び相談すると、信頼を失います。逆に、時期をずらして再開する可能性があるなら、その見込みを一言添えておくと、相手も再相談に応じやすくなります。

受け取った資料の扱いにも触れておくと丁寧です。提案書や見積書は社内の検討資料としてだけ使い、外部には出さないことを伝えます。秘密保持契約を結んでいた場合は、契約に定められた方法で資料を返却または破棄し、その旨を連絡します。

断りの連絡は、電話よりもメールのほうが記録が残り、相手も社内で共有しやすい手段です。打ち合わせを何度も重ねた相手であれば、メールを送ったうえで担当者に電話で一言伝えると、関係を保ちやすくなります。

まとめ

相見積もりの比較がうまくいくかどうかは、依頼の段階でほぼ決まります。依頼する社数、比較の基準、判断の時期を先に決め、すべての会社に同じ資料と同じ回答を渡せば、返ってくる見積もりは比べられる形になります。

見積書が届いたら、金額より先に前提条件を読み、工程ごとの金額、含まれる作業、前提の数量、発注側の作業、不明点の扱いを一枚の表に並べます。金額の差が大きいときは差の理由を特定し、自社の案件にとってどちらの前提が妥当かで判断します。要件が固まっていない段階の見積もりは概算であり、最初の工程の内容と再見積もりの条件を比べるほうが実態に合います。

選ばなかった会社には、早めに、お礼と結論と簡潔な理由を伝えます。これから相見積もりを取る段階であれば、まず依頼資料に「見積もりに含めてほしい範囲」と「工程別の内訳と前提条件の明記」を書き加えるところから始めてください。それだけで、届く見積もりの比べやすさが大きく変わります。