相見積もりの取り方と比較の観点

複数の開発会社から見積もりを取ろうと思い立ったものの、何社に声をかければよいのか、どんな順番で進めればよいのか、そして返ってきた見積書を並べたときに金額以外の何を見て比較すればよいのか、分からないまま止まってしまっている。ひとりで情シスや総務のIT担当を兼任していると、こうした場面で相談できる相手が社内にいないことも多く、「とりあえず知り合いの1社に頼んでしまう」という選択に流れがちです。

相見積もりは、単に「複数社から金額を集めて安いところを選ぶ」ための作業ではありません。金額だけを並べて安い会社を選んでしまうと、契約範囲や保守体制の違いを見落とし、契約後に「思っていたのと違う」というトラブルにつながることがあります。相見積もりの本来の目的は、複数の会社の提案を通じて、自社の要望がどこまで一般的か、どこが特殊で費用がかかりやすいかを把握し、金額と提案内容の両方を比較検討できる状態を作ることにあります。

結論から言うと、相見積もりを成功させる鍵は「進め方のマナーを守ること」と「金額以外の比較の観点を事前に決めておくこと」の2つです。この記事では、何社に依頼すればよいかという実務的な疑問から、依頼時に守るべきマナー、見積もりが返ってきたあとに金額以外で見るべき比較の観点、よくある失敗パターンまで、順を追って解説します。

この記事で分かること

相見積もりを取ろうとしている担当者が抱えやすい疑問に、順番に答えていきます。

• 相見積もりは何社に依頼するのが現実的か
• 相見積もりを依頼する際に守るべきマナーとは何か
• 各社に同じ条件で依頼するために、何を揃えておく必要があるか
• 金額以外に、どんな観点で見積もりを比較すればよいか
• 見積もりの金額差が大きいとき、どう解釈すればよいか
• 相見積もりでよくある失敗パターンと、その回避策

一つずつ、順を追って見ていきます。

そもそも相見積もりはなぜ必要なのか

システム開発の発注において相見積もりが推奨される理由は、単に「安く買うため」ではありません。むしろ実務上は、金額の妥当性を検証する材料を得るためという側面の方が大きいといえます。

システム開発の見積もりは、家電製品のように決まった値札があるわけではなく、開発会社側が「この要望を実現するにはどれだけの作業量が必要か」を見立てて算出したものです。この見立ては会社によって、経験や得意分野、使用する技術、既存の資産(過去に作ったコードやテンプレートの再利用可否)によって差が出ます。1社だけに見積もりを依頼した場合、その金額が高いのか妥当なのかを判断する基準がなく、「言われた金額をそのまま受け入れる」以外の選択肢がなくなってしまいます。

複数社から見積もりを取ることで、次のようなことが見えてきます。

• 自社の要望に対する金額の「幅」(相場そのものではなく、案件固有の幅)
• 各社が要望のどこを難しいと感じ、どこにリスクを見込んでいるか
• 提案の切り口の違い(同じ要望でも、実現方法や範囲の区切り方が会社によって異なる)
• 担当者とのやり取りのしやすさ、説明の分かりやすさ

実務上の視点: 相見積もりを「値切り交渉の材料」として使おうとすると、開発会社側との関係がぎくしゃくしやすくなります。相見積もりの本来の価値は、金額を下げることではなく、自社の要望と市場の提案とのズレを把握し、納得感を持って発注先を選ぶことにあります。

この記事では、相見積もりを「金額比較の作業」ではなく「発注先を適切に選ぶための情報収集プロセス」として捉え、進め方と比較の観点を解説していきます。

相見積もりは何社に依頼するのが現実的か

相見積もりの社数に、絶対的な正解はありません。ただし、実務上の目安として押さえておきたい考え方はあります。

1社だけに依頼した場合、前述の通り金額や提案内容を比較する基準がなく、相見積もりとしての意味をなしません。逆に、5社、6社と多くの会社に同時に依頼すると、各社とのやり取り(質問対応、資料の追加提供、打ち合わせの日程調整など)に社内の稼働時間が想像以上に取られ、ひとりで情シスや総務を兼任している担当者にとっては、本来の業務を圧迫する負担になります。

多くの実務担当者が現実的だと感じている社数は、2〜3社程度です。

• 2社: 最低限の比較はできるが、金額や提案の傾向が「たまたま」なのか「一般的」なのかの判断がやや難しい
• 3社: 金額や提案の傾向をある程度俯瞰でき、比較検討の材料としてバランスが良い
• 4社以上: 比較の精度は上がるが、対応する側の負担が大きくなり、依頼先の開発会社側にも「本気度の低い相見積もり」と受け取られるリスクが出てくる

依頼先の候補が見つからない場合は、RFP（提案依頼書）を簡易的に作成し、それを軸に問い合わせを行うと、依頼内容の粒度がそろいやすくなります。RFPの具体的な書き方については、関連記事「RFPは必要？中小企業の現実的な進め方」で詳しく解説しています。

なお、社数を決める際は、案件の規模も考慮する必要があります。数十万円規模の小さな依頼であれば2社程度で十分なことが多く、数百万円以上の規模で長期的な保守関係も見込む発注であれば、3社程度まで広げて比較する価値があります。

相見積もりを依頼する際に守るべきマナー

相見積もりは発注者の権利であり、複数社に声をかけること自体は何ら問題のある行為ではありません。ただし、進め方によっては開発会社側に不要な負担をかけたり、後々の関係性に影響したりすることがあるため、いくつかのマナーを押さえておく必要があります。

相見積もりであることを正直に伝える

「他社にも声をかけている」ことを隠す必要はありません。むしろ、正直に伝えたほうが、開発会社側も見積もり作成の工数配分を適切に判断でき、結果として双方にとって効率的なやり取りになります。多くの開発会社は、相見積もりであることを前提に営業活動を行っており、隠されていたことが後から分かるほうが、かえって心証を悪くすることがあります。

依頼する情報の粒度を、全社でそろえる

ある会社には口頭で詳しく説明し、別の会社には資料だけを送って終わる、という対応をしてしまうと、返ってくる見積もりの前提がバラバラになり、金額の単純比較ができなくなります。同じ資料、同じ説明を、同じタイミングで各社に提供することを意識してください。

回答期限を明確に伝える

「いつまでに見積もりが欲しいか」を伝えないまま依頼すると、開発会社側の対応の優先順位が下がり、想定より時間がかかることがあります。目安として、2〜3週間程度の余裕を持った期限を提示すると、開発会社側も無理なく丁寧な見積もりを作成しやすくなります。

発注しない会社には、必ず結果を連絡する

見積もりを依頼しておきながら、発注しなかった会社への連絡を怠るケースは少なくありません。見積もり作成には、開発会社側も相応の工数をかけています。採用しなかった場合でも、簡単でよいので結果を連絡することが、最低限のマナーとして求められます。今後、別の案件で再度依頼する可能性もあるため、関係性を良好に保つ意味でも重要です。

見積もり依頼のメールや資料に、必ず「他社にも同時に依頼している」旨と「回答期限」を明記する習慣をつけると、上記のマナーの多くを自然に満たせます。

各社に同じ条件で依頼するために揃えておくもの

比較可能な見積もりを得るためには、各社に渡す情報の粒度をそろえることが前提条件になります。ここが揃っていないと、どれだけ丁寧に比較検討の観点を用意しても、そもそも比較の土台が成立しません。

最低限そろえておきたい情報は次の通りです。

要望・要件のまとめ方については、関連記事「要件のまとめ方: 開発会社に伝わる資料の作り方」で、開発会社に伝わりやすい資料の作り方を具体的に解説しています。この資料を先に用意しておくと、相見積もりの依頼作業そのものがスムーズになります。

見積もり依頼から取得までの進め方

情報を揃えたあと、実際にどのような流れで各社とやり取りを進めればよいかを整理します。進め方には大きく分けて「説明会形式」と「個別ヒアリング形式」の2つがあります。

説明会形式は、依頼したい要望をまとめた資料をもとに、各社と同じ内容の打ち合わせを個別に(あるいはオンラインで)実施する進め方です。同じ資料・同じ説明を各社に対して繰り返すため、情報の粒度がそろいやすいという利点があります。一方で、1社ごとに1時間前後の打ち合わせ時間が必要になるため、3社に依頼する場合は合計で半日近い時間を確保する必要があります。

個別ヒアリング形式は、まず資料を送付し、各社からの質問をメールやオンライン会議で個別に受け付ける進め方です。打ち合わせの負担は説明会形式より軽くなりますが、ある会社からの質問で明らかになった情報を、他の会社にも共有する手間を忘れずに行う必要があります。この共有を怠ると、失敗パターンで後述する「情報の粒度がバラバラになる」状態を招きます。

どちらの形式を選ぶ場合でも、次のようなおおまかなスケジュール感で進めると、無理なく比較検討まで到達できます。

1. 依頼先の選定と資料準備(3〜5日): 候補となる開発会社を2〜3社選び、要望をまとめた資料を用意する
2. 一斉依頼(1日): 全社に同じタイミングで、同じ資料・同じ回答期限を伝えて依頼する
3. 質疑応答期間(1〜2週間): 各社からの質問に回答し、必要に応じて全社へ情報を共有する
4. 見積もり受領(依頼から2〜3週間後を目安): 各社から見積もりが返ってくる
5. 比較検討と意思決定(1週間程度): 比較表を作成し、社内の決裁者を交えて検討する

依頼先の候補が2〜3社に満たない場合は、既に取引のある開発会社からの紹介や、業界団体・商工会議所の紹介制度を利用する方法もあります。面識のない会社にいきなり問い合わせることに抵抗がある場合は、まず1社と相談しながら要望を整理し、その過程で紹介を受けるという進め方も現実的です。

見積もりが返ってきたら: 金額以外に見るべき5つの観点

相見積もりの本題は、実はここからです。各社から見積もりが返ってきたあと、金額の大小だけで判断してしまうと、契約後に想定外のトラブルに遭遇するリスクが高まります。ここでは、金額以外に確認しておきたい5つの観点を解説します。

観点1: 内訳の粒度と説明の具体性

見積書に「一式」とだけ書かれている場合と、工程ごとに内訳が示されている場合とでは、金額の妥当性を検証できる度合いが大きく異なります。内訳の詳細な読み方については、関連記事「システム開発の見積書、この内訳の見方で損を防ぐ」で解説していますが、相見積もりの比較という観点では、次の点を意識してください。

• 各社の内訳の粒度がそろっているか(A社は工程別、B社は機能別など、粒度が違うと比較しづらい)
• 質問した際に、はぐらかされずに具体的な回答が返ってくるか
• 「なぜこの金額になるのか」の説明に、納得感があるか

内訳の説明を求めた際の対応の丁寧さは、契約後に追加費用が発生した際の説明の丁寧さとも相関する傾向があるため、金額そのものと同じくらい重要な確認ポイントです。

観点2: 契約形態(請負か準委任か)

見積書や提案書に、契約形態が明記されているかを確認してください。請負契約と準委任契約(仕事の完成ではなく、業務の遂行そのものを目的とする契約形態)とでは、成果物に対する責任の所在や、仕様変更時の扱いが大きく異なります。同じ要望に対して、A社は請負、B社は準委任を提案してきた場合、金額の単純比較はできません。それぞれの契約形態が自社の案件に適しているかどうかを、別途検討する必要があります。

観点3: 保守・サポート体制と期間

開発が完了したあとの保守・サポートが、見積もりに含まれているかどうかは、会社によって扱いが大きく異なります。

• 納品後、一定期間の無償対応(不具合修正など)が含まれているか、その期間はどれくらいか
• 保守契約は別契約になるのか、その場合の月額目安はどの段階で分かるか
• 障害発生時の対応時間や連絡手段について、どこまで明記されているか

保守体制が見積もりに含まれていない、あるいは曖昧なままの提案は、初期費用だけを見ると安く見えても、稼働後のトータルコストで逆転することがあります。保守契約の内容を確認する際は、関連記事もあわせて参考にしてください。

観点4: 実績と担当者の対応

同業種・同規模の開発実績があるかどうかは、要望の理解度や、想定外の事態への対応力に影響します。ただし、実績を確認する際は、単に「実績があります」という言葉だけでなく、次のような点を意識して確認するとよいでしょう。

• 実績として紹介された案件が、自社の要望とどれくらい近いか(規模・業種・システムの種類)
• 見積もり作成の過程で、担当者からの質問がどれだけ的確か(質問の質は、要望の理解度を反映することが多い)
• 打ち合わせや問い合わせへの返信速度、説明の分かりやすさ

特に、専任のIT担当者がいない中小企業にとっては、専門用語を使わずに分かりやすく説明してくれる担当者かどうかは、契約後の長期的な付き合いやすさに直結する要素です。

観点5: 契約後の情報開示とロックインのリスク

見積もり段階では見落とされがちですが、ソースコードの権利の帰属や、データのエクスポート可否、開発に使用する技術やツールの汎用性についても、可能であれば確認しておくとよいでしょう。特定の会社にしか扱えない独自技術に依存しすぎると、将来的に他社への乗り換えが困難になるベンダーロックインの状態に陥るリスクがあります。

見積もり段階でここまで確認するのは負担が大きいと感じる場合は、少なくとも「ソースコードの著作権は納品後どちらに帰属するか」だけでも質問しておくと、後々のリスクを減らせます。

案件の性質によって、比較の重み付けは変わる

ここまで挙げた5つの観点は、どの案件にも共通して確認すべき項目ですが、案件の性質によって、どの観点を重視すべきかの重み付けは変わります。

業務の根幹に関わる基幹システムの入れ替えなど、長期の運用が前提となる案件の場合は、保守・サポート体制と、契約後の情報開示(観点3・観点5)を特に重視することをおすすめします。稼働してからの期間が長くなるほど、保守対応の質や、将来的な乗り換えのしやすさが、総コストに大きく影響してくるためです。

特定の業務を効率化する小規模なツールや、PoC(小さく試してから本格導入するかを判断する検証)を目的とした案件の場合は、内訳の具体性や実績よりも、担当者とのやり取りのしやすさ(観点4)や、スケジュールの柔軟性を重視した方が、結果的にスムーズに進むことが多くなります。小さく試す発注の考え方については、関連記事「小さく発注して試す: PoC発注のすすめ」も参考にしてください。

社外に公開するWebサイトやサービスなど、見た目やユーザー体験の質が重要な案件の場合は、内訳や契約形態と同じくらい、過去の実績のデザインの質やユーザビリティへのこだわりを確認しておくと、完成後のミスマッチを防ぎやすくなります。

このように、5つの観点すべてを一律の重みで評価するのではなく、自社の案件がどのタイプに近いかを踏まえて優先順位をつけると、限られた時間の中でも精度の高い比較検討ができます。

比較表を作って可視化する

各社から集めた情報を、頭の中だけで比較しようとすると、金額のインパクトが強すぎて、他の観点が埋もれてしまいがちです。簡単でよいので、比較表にまとめることをおすすめします。

比較表に入れる項目の例は次の通りです。

• 総額(内訳が分かる場合は工程別の内訳も)
• 契約形態
• 納期の目安
• 保守・サポートの有無と内容
• 見積もりに含まれる範囲(テスト工程、導入支援などの有無)
• 担当者とのやり取りで感じた印象(定性的な評価でよい)

比較表は、社内の決裁者への説明資料としてもそのまま使えます。金額だけでなく、なぜその会社を選んだのかという判断根拠を可視化しておくことで、稟議の起案書を作成する際の材料にもなります。

比較表を作る際に注意したいのは、「安い会社が良い会社」という単純な図式に飛びつかないことです。次の章で、金額差の解釈について詳しく見ていきます。

見積もりの金額差が大きいとき、どう解釈するか

複数社から見積もりを取ると、金額が2倍、3倍と大きく異なることは珍しくありません。この金額差を見たとき、多くの担当者は「一番安い会社が得だ」あるいは逆に「安すぎる会社は不安だ」といった直感的な判断に流れがちですが、まず確認すべきは、見積もりの前提条件が本当にそろっているかどうかです。

金額差が生まれる主な要因には、次のようなものがあります。

• 見積もりに含まれる作業範囲の違い: テスト工程や導入支援、保守費用が含まれているかどうかで、総額は大きく変わる
• 契約形態の違い: 請負と準委任では、リスクの負担のされ方が異なり、金額の構造も変わる
• 既存の資産(テンプレートやフレームワーク)の有無: 過去の類似案件の資産を再利用できる会社は、その分工数を抑えられることがある
• バッファの見込み方の違い: 想定外の作業増加に備える余裕分を、どれだけ金額に織り込んでいるか

前提条件をそろえたうえで、それでも金額差が大きい場合は、安い会社・高い会社の双方に「なぜこの金額になるのか」を具体的に質問し、回答の納得感で判断材料を補うことをおすすめします。極端に安い見積もりについては、後から「この作業は追加費用です」という形で当初の想定より費用が膨らむ可能性がないか、見積もりに含まれる範囲を特に丁寧に確認しておくと安心です。

相見積もりでよくある失敗パターン

相見積もりの進め方でつまずきやすいパターンには、一定の型があります。ここでは、実務でよく見られる失敗パターンと、その回避策を整理します。

失敗パターン1: 各社への説明の粒度がバラバラになる

最初に問い合わせた会社に対しては熱心に説明する一方、2社目、3社目になると説明が簡略化されてしまうケースです。これでは前提条件がそろわず、比較の意味が薄れます。回避策は、事前に要望をまとめた資料を1つ作成し、全社に同じ資料を渡すことです。

失敗パターン2: 金額だけで即決してしまう

比較表を作らず、総額の数字だけを見て「一番安いところにしよう」と決めてしまうケースです。前述の通り、見積もりに含まれる範囲や契約形態が違えば、単純な金額比較は意味を持ちません。回避策は、本記事で挙げた5つの観点を最低限確認してから決定することです。

失敗パターン3: 発注しなかった会社への連絡を怠る

見積もりを依頼するところまでは丁寧に進めるものの、発注先が決まった後、他の会社への結果連絡を忘れてしまうケースです。マナーの観点だけでなく、今後別の案件で再依頼する可能性を考えると、良好な関係を保っておく価値があります。

失敗パターン4: 相見積もりを引き延ばしすぎる

比較検討に時間をかけすぎて、意思決定が数ヶ月単位で先延ばしになるケースです。開発会社側の見積もりには有効期限が設定されていることが多く、検討が長引くと、材料費や人件費の変動を理由に金額が見直される場合があります。回答期限をあらかじめ設定し、社内の意思決定スケジュールも並行して決めておくことで、この失敗を避けられます。

失敗パターン5: 途中で要望を追加・変更したのに、全社に共有し漏れる

ある会社との打ち合わせを通じて要望が具体化したり変更になったりした際に、その内容を他の会社に共有し忘れるケースです。結果として、各社が異なる前提で見積もりを作成することになり、最終的な比較ができなくなります。要望に変更があった場合は、その都度、依頼している全社に同じ内容を共有する習慣をつけてください。

開発会社側から見た相見積もりの受け止め方

発注者側の視点だけでなく、見積もりを作成する開発会社側が相見積もりをどう受け止めているかを知っておくと、依頼の仕方や比較の解釈に役立ちます。

多くの開発会社にとって、相見積もりであること自体は珍しいことではなく、むしろ標準的な発注プロセスの一部として受け止められています。見積もり作成には相応の工数がかかるため、依頼段階で「相見積もりであること」「回答期限」「比較の観点」がある程度明確に伝わっている案件ほど、開発会社側も的確な提案を組み立てやすくなります。逆に、要望が曖昧なまま「とりあえず見積もりをください」とだけ依頼されると、開発会社側は最大限の機能を盛り込んだ提案と、最小限に絞った提案のどちらを出すべきか判断に迷い、結果として想定より高額な、あるいは実情に合わない提案が返ってくることがあります。

また、見積もり作成の担当者は、依頼者からの質問の的確さや、要望資料の具体性から、案件の進めやすさをある程度推し量っています。曖昧な依頼に対しては工数を抑えた簡易的な見積もりで対応し、具体的な依頼に対しては踏み込んだ提案で応える、という対応の差が生まれることも実務上はあります。相見積もりを依頼する側にとっても、丁寧な要望資料を用意することは、結果的に各社からより精度の高い提案を引き出すことにつながります。

まとめ: 相見積もりは「比較の準備」が9割

相見積もりは、複数社から金額を集めて安いところを選ぶ作業ではなく、自社の要望に対する適切な発注先を、納得感を持って選ぶための情報収集プロセスです。うまく機能させるための要点を整理すると、次の3点に集約されます。

• 依頼社数は2〜3社を目安に、各社へ同じ条件・同じ情報を、正直に「相見積もりである」と伝えたうえで依頼する
• 金額だけでなく、内訳の具体性、契約形態、保守体制、実績と担当者の対応、契約後のリスクという5つの観点で比較する
• 比較表にまとめて可視化し、金額差が出た場合はその要因を各社に確認してから判断する

相見積もりの質は、依頼する前の準備でほぼ決まります。要望をまとめた資料を先に用意し、各社に同じ条件で依頼できる状態を整えることが、結果的に比較検討をスムーズにし、納得感のある発注先選びにつながります。

見積もりを受け取ったあとの内訳の読み方についてさらに詳しく知りたい方は、「システム開発の見積書、この内訳の見方で損を防ぐ」もあわせてご覧ください。