なぜ「相見積もり」がうまくいかないのか
先代からシステム関連の判断を引き継いだばかりの後継社長・後継者にとって、最初に戸惑うのが「相見積もり」の取り方です。複数の開発会社から見積もりを取れば、いちばん条件の良いところを選べる。理屈としてはそうなのですが、実際にやってみると「A社は50万円、B社は300万円、C社は800万円」というように、桁が違う見積もりが並んでしまうことがよくあります。
これは、どこかの会社が特別に高い金額を取ろうとしているとか、どこかが特別にお得だという話ではありません。ほとんどの場合、原因は発注側にあります。つまり、各社に「同じ条件」を伝えられていないのです。開発会社は、渡された情報だけを手がかりに見積もりを作ります。A社には「在庫管理システムを作ってほしい」としか伝えず、B社には「在庫管理システムを作ってほしい、ただし既存の販売管理システムと連携させたい、利用者は20人、拠点は3箇所」と伝えていたら、そもそも見積もっている対象が違います。違う対象の値段を並べて「高い」「安い」と判断するのは、リンゴとオレンジを比べて「リンゴのほうが安い果物だ」と結論づけるようなものです。
先代の時代は、長年付き合いのある一社に丸ごと任せる「言えば分かる」関係が多く、相見積もりという概念自体になじみが薄かった会社も少なくありません。先代が引退し、後継者の代になって初めて「複数社から見積もりを取る」という経験をする方も多いはずです。この記事では、なぜ条件がそろわないと相見積もりが機能しないのか、そしてどうすれば条件をそろえて公平に比較できるのかを、具体的な伝え方のレベルまで落とし込んで解説します。相見積もりに進む前の、そもそも何を決めておくべきかという段階は刷新を開発会社に相談する前に、決めておきたい3つのことで扱っている。
相見積もりの目的を最初に整理する
条件をそろえる前に、そもそも何のために相見積もりを取るのかをはっきりさせておく必要があります。目的が曖昧なまま「とりあえず3社くらいに聞いてみよう」と動くと、比較の軸がぶれてしまいます。
相見積もりの目的は、大きく分けて次の3つに整理できます。
第一に、適正な価格帯を知ること。 業界の相場観がないまま1社だけに発注すると、相場より高い金額を払っている可能性も、逆に安すぎて後で追加費用がかさむ可能性も見えません。複数社の見積もりを並べることで、その仕事のおおよその適正価格帯が見えてきます。
第二に、提案内容や進め方の違いを比較すること。 価格だけでなく、どういう技術で作るのか、どのくらいの期間がかかるのか、開発中にどう連絡を取り合うのか、といった進め方の違いも見えてきます。同じ予算でも「毎週打ち合わせをして細かく確認しながら進める会社」と「最初にまとめて要件を聞いて、あとは完成品を見せるまで音沙汰がない会社」では、後継者としての安心感がまったく違うはずです。
第三に、自社の要望を整理する機会にすること。 複数の会社に同じ内容を説明しようとすると、自分自身が「結局何を作りたいのか」を言語化せざるを得なくなります。これは相見積もりの副産物のように見えて、実は非常に重要な効果です。何を作りたいかが自分の中で整理されていない状態で発注すると、開発が始まってから「あれも欲しかった」「これも入れてほしい」と後出しで追加要望を出すことになり、追加費用と工期延長の火種になります。
この3つの目的を意識しておくと、相見積もりの過程で「安いところに決めればいい」という単純な判断に流されず、総合的に判断する視点を持てます。
条件がそろっていないと何が起きるか
条件をそろえずに相見積もりを取ると、具体的にどういう弊害が起きるのかを、よくあるパターンで見ていきます。
パターン1：機能の範囲がずれる
「顧客管理システムを作りたい」と伝えたとき、A社は「顧客の名前と連絡先を登録できる簡易な名簿ソフト」を想定し、B社は「顧客ごとの購入履歴、対応履歴、請求書発行機能まで含む統合システム」を想定するかもしれません。どちらも「顧客管理システム」という言葉には当てはまりますが、作るものの規模がまったく違います。当然、見積額も数倍から十数倍の差が出ます。
パターン2：前提となる環境がずれる
すでに使っている会計ソフトや在庫管理システムと連携させたいのか、まったく新しく単独で動かすものを作るのかによって、開発の難易度は大きく変わります。既存システムとの連携は、相手のシステムの仕様を調べる工程が余分に必要になり、思わぬ落とし穴にはまることも多いため、多くの会社は連携ありの見積もりを高めに出します。この前提を伝えていないと、連携を想定していない会社の見積もりだけが不自然に安く見えてしまいます。
パターン3：運用後の体制がずれる
作った後、誰がどうやって使うのか、社内に詳しい人がいるのか、外部に運用を頼み続けるのかという情報も、見積もりに影響します。「作って終わり」なのか「作った後も月々のサポート費用が発生する」のかで、初期費用の見え方はまったく異なります。ある会社は初期費用を高めにして月額費用を抑え、別の会社は初期費用を抑えて月額費用で回収するモデルを取っていることもあります。これを比較せずに初期費用だけを見て決めると、数年単位のトータルコストで大きく損をすることがあります。
パターン4：納期の前提がずれる
「できるだけ早く」という表現は、会社によって解釈が異なります。ある会社は「2ヶ月」を早いと捉え、別の会社は「2週間」を早いと捉えるかもしれません。急ぎであることを具体的な日付や理由とともに伝えていないと、納期に対する温度差がそのまま見積もりの前提のずれに直結します。
これらのパターンに共通しているのは、後継者側が「当たり前だと思って言わなかったこと」が、開発会社にとっては見積もりを左右する重要な情報だったという点です。先代の時代からの付き合いの会社であれば「察してくれる」こともあったかもしれませんが、初めて相見積もりを取る相手には、察してもらうことを期待してはいけません。
条件をそろえるための基本の考え方
条件をそろえるための最も確実な方法は、すべての会社に「同じ文書」を渡すことです。口頭で伝えると、話す順番や強調するポイントが会社ごとに微妙に変わってしまい、結果として伝わる情報にばらつきが出ます。文書にしておけば、少なくとも「渡した情報」は完全に同一になります。
この文書は、開発会社の業界ではSOW（作業範囲記述書）や提案依頼書と呼ばれる形式に近いものですが、後継者の立場では、そこまで厳密な書類を最初から作る必要はありません。まずは「依頼内容メモ」のようなシンプルな一枚の文書で構いません。重要なのは、形式の完成度ではなく、各社に同じ内容が伝わることです。
この文書には、少なくとも次の項目を含めるようにしてください。
- 何を作りたいのか（システムの名前や用途を一言で）
- なぜ作りたいのか（背景・課題）
- 誰が使うのか（利用者数・利用者の立場）
- どんな機能が欲しいのか（優先順位をつけて）
- 既存のどのシステムと連携するのか、しないのか
- いつまでに欲しいのか（希望日と、それが動かせない理由の有無）
- 予算感（出せる場合は範囲でよい）
- 運用開始後のサポートについての希望
- 見積もりの提出期限と、いつまでに何を回答してほしいか
これらを一つずつ具体的にどう書くかを、次の章で見ていきます。
項目ごとの具体的な伝え方
「何を作りたいのか」を一言で言えるようにする
まず、依頼内容を一文で表現してみてください。「うちの店舗の予約をネットで受けられるようにしたい」「取引先ごとの発注状況を一覧で見られるようにしたい」といった具合です。この一文が曖昧だと、そのあとに続くすべての説明もぼやけてしまいます。
一文で言えない場合は、まだ自分の中で要望が整理できていない可能性があります。その場合は、相見積もりに進む前に、社内の関係者（現場のスタッフ、経理担当、先代がまだ関わっているなら先代自身)に話を聞いて、要望を一文にまとめる作業から始めましょう。
「なぜ作りたいのか」の背景を隠さない
背景を伝えることには、二つの利点があります。一つは、開発会社が「本当に必要な機能」を見極めやすくなること。もう一つは、開発会社からより良い提案が出てくる可能性が上がることです。
例えば「毎月の在庫チェックに社員が3日かかっていて、その間ほかの業務が止まっている」という背景を伝えれば、開発会社は「全項目を毎日更新できるシステム」ではなく「月次チェックの手間を減らす仕組み」に焦点を当てた提案をしてくれる可能性が高まります。背景を伝えずに「在庫管理システムを作ってほしい」だけを伝えると、開発会社は的を絞れず、過剰に立派な、しかし的外れなシステムを提案してくることがあります。
「誰が使うのか」を具体的な人数と立場で伝える
「社員が使う」だけでは情報として足りません。「本社の事務員2名と、3つの店舗のスタッフ合計15名、合わせて17名が使う」「社外の取引先も見られるようにしたい」といったように、具体的な人数と立場を伝えてください。利用者数は、システムの規模やサーバーの選び方、権限管理の複雑さに直結する要素です。
「機能」は優先順位をつけて箇条書きにする
欲しい機能を思いつくままに並べるのではなく、優先順位をつけて三段階程度に分類することをおすすめします。
- 絶対に必要（これがないと発注する意味がない機能）
- できれば欲しい（あれば助かるが、なくても運用は成立する機能）
- 将来的に検討（今回は入れなくてよいが、将来追加したい機能）
この分類をすべての会社に同じ形で渡すことで、各社が「絶対に必要」な部分にどれだけの費用がかかるかを明確に見積もってくれるようになります。逆に、優先順位をつけずに機能を並べてしまうと、ある会社はすべてを含めた見積もりを出し、別の会社は独自の判断で一部を削った見積もりを出すという、見えないずれが発生します。
「既存システムとの連携」の有無を明記する
すでに使っている会計ソフト、販売管理システム、勤怠管理システムなどがある場合は、それらの名称と、連携させたいかどうかを明記してください。連携させたい場合は、可能であればそのシステムの提供会社名やバージョンも伝えると、見積もりの精度が上がります。連携の要否は、開発期間と費用に大きく影響する要素なので、ここを曖昧にしたまま進めると、後になって「実は連携が必要だった」という話になり、追加費用の交渉で不利な立場に立たされることがあります。
「納期」は希望日と根拠をセットで伝える
「できるだけ早く」ではなく、具体的な日付を伝えてください。そして、その日付に根拠がある場合は、根拠も併せて伝えましょう。「来年の確定申告の時期までに経理システムを新しくしたい」「新店舗のオープンが3ヶ月後に決まっているので、それまでに予約システムを稼働させたい」といった根拠があると、開発会社側も優先度を判断しやすくなります。
逆に、根拠のない「早ければ早いほどいい」という要望は、開発会社に無理な短納期を強いる結果になり、品質の低下や、急ぎ料金による費用の上乗せにつながることがあります。本当に急ぐ理由がないのであれば、多少の余裕を持った日付を伝えるほうが、結果的に良い提案を得やすくなります。
「予算感」は言えるなら言う、言えないなら聞き方を工夫する
予算を伝えることに抵抗を感じる後継者は多いです。「先に予算を言うと、その金額まで見積もりを引き上げられるのではないか」という心配があるからでしょう。この心配には一定の理由がありますが、予算を一切伝えないことのデメリットのほうが大きい場合が多いです。
予算感を伝えないと、開発会社は「フルスペックの提案」を出してくることがあります。それは開発会社にとって悪意があるわけではなく、単に「予算の制約が分からないので、要望を満たす最善の提案をした」だけなのですが、後継者側から見ると「聞いてもいないのに高額な提案をされた」と感じてしまいます。
対策としては、正確な金額ではなく「範囲」で伝える方法があります。「50万円から150万円程度を想定している」というように、幅を持たせて伝えれば、極端に外れた提案を防ぎつつ、過度な誘導も避けられます。範囲すら決められない場合は、「まずは機能を絞ったシンプルな案と、フルスペックの案の両方を教えてほしい」と伝え、複数パターンでの提案を依頼するのも有効です。
「運用開始後のサポート」への希望を伝える
作って終わりでよいのか、その後の不具合対応や機能追加を継続的に依頼したいのかを伝えてください。この希望によって、見積もりに含まれる保守費用の考え方が変わります。ここを伝えないと、ある会社は保守費用を含めた高めの見積もりを出し、別の会社は保守費用を別枠にした安めの見積もりを出すという、見えにくい差が生まれます。
「見積もりの提出期限」と「回答の締め切り」を明記する
すべての会社に同じ提出期限を伝えることも、条件をそろえる上で欠かせません。ある会社には「今週中に」と伝え、別の会社には「来月まで」と伝えていたら、準備にかけられる時間が違い、見積もりの精度や提案の丁寧さにも差が出ます。「見積もりは〇月〇日までにご提出ください」という一文を、全社共通で入れてください。
依頼内容メモのテンプレート
ここまでの項目を、実際に使えるテンプレートの形にまとめると、次のようになります。このまま埋めていけば、各社に同じ条件を伝える文書が完成します。
件名：〇〇（システム名・用途）の開発に関するお見積もり依頼
- 依頼概要：〇〇を実現するシステムを新規に開発したい
- 背景・課題：（現在困っていること、なぜ今取り組むのかを2〜3行で）
- 利用者：〇〇名（内訳：本社事務〇名、店舗スタッフ〇名、社外〇名）
- 必要な機能
- 絶対に必要：（箇条書き）
- できれば欲しい：（箇条書き）
- 将来的に検討：（箇条書き）
- 既存システムとの連携：あり／なし（ありの場合はシステム名を記載）
- 希望納期：〇年〇月〇日まで（根拠：〇〇のため）
- 予算感：〇〇万円〜〇〇万円程度（未定の場合は「複数パターンでの提案希望」と記載)
- 運用開始後のサポート：希望する／希望しない（希望する場合は想定頻度）
- お見積もり提出期限：〇年〇月〇日まで
- ご質問がある場合の連絡先：（担当者名・電話番号・メールアドレス）
この文書を、相見積もりを依頼するすべての会社に、同じタイミングで、同じ内容で送ってください。可能であれば、メールの本文にそのまま貼るのではなく、一枚のPDFやワード文書にして添付すると、後から見返す際にも整理がつきやすくなります。
質問への対応も「条件をそろえる」対象になる
依頼内容メモを送ると、各社からさまざまな質問が返ってくることがあります。ここで注意したいのは、質問への回答も「全社に同じ内容を伝える」対象だという点です。
例えば、A社から「利用者のうち、社外の方はスマートフォンからも使いますか」という質問が来て、それに答えたとします。もしB社やC社が同じ疑問を持っていたとしても、聞いてこなければその情報は伝わりません。結果として、A社だけがスマートフォン対応を前提にした見積もりを出し、他社はパソコンのみを想定した見積もりを出すという、条件のずれが生まれます。
これを防ぐには、次のような運用が有効です。
- 質問と回答を一つの文書にまとめて、全社に共有する
- 一定期間（例えば3営業日)を「質問受付期間」として設け、その期間中の質問は締め切り後にまとめて全社へ回答する
- 個別に電話で質問を受けた場合も、後で文書化して他社にも共有する
手間はかかりますが、この運用を徹底することで、見積もりの前提を最後までそろえたまま比較できるようになります。逆に、質問対応を個社ごとの個別対応にしてしまうと、条件をそろえるために最初に作った依頼内容メモの効果が、後半で薄れてしまいます。
業種別に見る「条件のそろえ方」の具体例
抽象的な項目だけを説明されても、自社に当てはめて考えるのは難しいものです。ここでは、業種ごとに条件をそろえる際の具体的なポイントを見ていきます。自社の業種に近い例を探しながら読んでみてください。
製造業で生産管理システムを作りたい場合
製造業では、工程の数、扱う部品の種類、ロット管理の方法など、業種特有の情報が見積もりの精度を大きく左右します。「何を作りたいか」を伝えるだけでは不十分で、現在の工程がどうなっているか、どの工程を効率化したいのかまで書き出す必要があります。例えば「材料の入庫から出荷までの工程は7段階あり、そのうち3段階目の在庫チェックと5段階目の検品記録が紙の台帳で管理されている。この2工程をシステム化したい」というように、工程図とともに伝えると、各社が同じ範囲を見積もることができます。また、生産管理システムは既存の基幹システムとの連携が発生しやすい分野なので、連携の有無を明記する重要性が特に高い業種です。
小売業や店舗業でECサイトや予約システムを作りたい場合
店舗数、決済方法（クレジットカード・電子マネー・後払いなど）、在庫と店舗のシステムを連動させるかどうかが、条件をそろえる上での重要な要素になります。「オンラインで予約を受けたい」という要望だけでは、キャンセル機能や当日変更の可否、予約可能な時間帯の細かさなど、想定する機能の粒度に差が出やすい分野です。店舗のスタッフが実際にどのような業務フローで予約を管理しているのかを、簡単な図や時系列のメモとして添えると、開発会社側の理解が深まります。
建設業や工事業で現場管理システムを作りたい場合
現場の数、協力会社との情報共有の範囲、写真や図面の管理方法などが条件のかなめになります。「現場の進捗を見える化したい」という要望は多く聞かれますが、進捗をどの単位で管理したいのか（工程単位か、日次の作業報告単位か）によって、システムの作り込みの深さがまったく変わります。また、建設業では現場でスマートフォンやタブレットを使う場面が多いため、パソコンだけの利用を想定しているのか、現場での入力を想定しているのかを明記することも重要です。
サービス業や士業で顧客管理・案件管理システムを作りたい場合
顧客数、案件の進行状況の管理方法、契約書や請求書の発行機能の必要性などが条件をそろえる際のポイントです。特に、既存の紙やエクセルでの管理方法を、開発会社にそのまま見てもらうと、システム化すべき範囲が明確になります。可能であれば、現在使っているエクセルのシートや管理台帳のサンプル（個人情報を伏せた状態で）を各社に同じものを共有すると、条件のずれを大幅に減らすことができます。
このように、業種によって条件をそろえるべき「ポイント」は異なりますが、共通しているのは「今の業務がどう動いているか」を具体的に見せることです。抽象的な要望だけでなく、現状の業務フローや使っている台帳・シートのサンプルを添えることで、開発会社側の想像に頼らない、精度の高い見積もりを引き出せます。
見積もり依頼を送る前に社内で準備しておくこと
条件をそろえた依頼内容メモを作る前段階として、社内での準備を怠ると、そもそも良い依頼内容メモが作れません。相見積もりを取る前に、次のような社内準備を済ませておくことをおすすめします。
現場の声を先に集める
システムを実際に使うのは、多くの場合、経営者本人ではなく現場のスタッフです。後継者が一人で要望をまとめてしまうと、現場が本当に困っていることと、依頼内容メモに書かれる内容がずれてしまうことがあります。相見積もりを取る前に、現場のスタッフに短いヒアリングの時間を設け、「今の業務で一番時間がかかっていること」「今の仕組みで一番困っていること」を聞き出しておくと、依頼内容メモの背景・課題の部分がより具体的で説得力のあるものになります。
先代や経理担当に予算の枠を確認する
後継者が独断で予算感を決めてしまうと、後から先代や経理担当の理解を得られず、話が振り出しに戻ってしまうことがあります。相見積もりを始める前に、社内でどの程度の予算枠が現実的かを確認しておくと、依頼内容メモに書く予算感に自信を持てるようになります。予算に補助金の活用を検討している場合は、その申請スケジュールとの整合性も事前に確認しておくとよいでしょう。
過去の資料やデータを整理しておく
現在使っているエクセルの管理表、紙の台帳、既存システムの画面のスクリーンショットなど、開発会社に見せられる資料を事前にまとめておくと、依頼内容メモに添付する際にスムーズです。相見積もりの段になって慌てて資料を探すと、会社によって渡せる資料の充実度に差が出てしまい、条件をそろえる努力が台無しになってしまいます。
社内の決定権者を明確にしておく
複数人が別々に開発会社とやり取りしてしまうと、伝える内容や質問への回答にばらつきが生まれます。相見積もりの窓口となる担当者を一人に絞り、その担当者を通じてすべての連絡をやり取りするようにしてください。後継者自身が担当者になる場合はもちろん構いませんが、実務を別の社員に任せる場合は、その社員が依頼内容メモの内容を正確に理解し、判断に迷ったときにすぐ後継者に確認できる体制を整えておく必要があります。
見積もり比較の際に見落とされがちな「隠れコスト」
条件をそろえて比較しても、見積書の総額だけでは見えてこない費用が存在します。これらを見落とすと、実際の支払いが想定より膨らんでしまうことがあるため、比較の際には必ず確認するようにしてください。
サーバーやドメインなどの維持費
システムを動かすためのサーバーやドメインの費用は、開発費とは別に、年額や月額で発生することが一般的です。この維持費が見積書に含まれているのか、別途契約が必要なのかを、必ず全社に確認してください。ある会社は開発費に維持費の初年度分を含めて提示し、別の会社は維持費を完全に別枠にしていることもあり、総額の比較を誤りやすいポイントです。
データ移行の費用
既存のエクセルや紙の台帳から、新しいシステムにデータを移す作業は、想像以上に手間がかかることがあります。この移行作業を開発会社が代行してくれるのか、自社で行う必要があるのか、代行の場合は費用がいくらかかるのかを確認してください。見積もりの段階でこの点が曖昧なまま契約してしまい、開発が完了する頃になって「データ移行は別料金です」と言われるケースは少なくありません。
教育・研修にかかる費用
システムが完成した後、実際に使うスタッフへの説明や研修が必要になります。この研修を開発会社が行ってくれるのか、マニュアルの提供のみなのか、追加費用が発生するのかを確認しておきましょう。特に、スタッフの入れ替わりが多い業種では、初回だけでなく継続的な研修が必要になる場合もあるため、その体制についても質問しておくと安心です。
契約解除・データ持ち出しに関する費用
将来、別の会社に切り替えることになった場合に、データを引き出す際の費用や条件についても、契約前に確認しておくことをおすすめします。この点は見積もりの比較表には出てきにくい項目ですが、長期的な視点で見ると重要な判断材料になります。特定の会社に依存し続けることを避けたい場合は、契約書や見積もりの段階で、データの所有権や持ち出し方法についての記載があるかどうかを確認しておくとよいでしょう。
見積もりが返ってきた後の交渉の進め方
条件をそろえて比較した結果、気になる点や不明点が出てくることは自然なことです。ここで大切なのは、交渉の際にも「条件をそろえる」姿勢を崩さないことです。
一社だけに追加の条件を伝えたり、一社だけに価格交渉を持ちかけたりすると、それまで公平に比較してきた前提が崩れてしまいます。交渉が必要な場合は、可能な限り同じタイミングで、同じ内容を全社に伝えるようにしてください。例えば「全社の見積もりを拝見した結果、当初想定していた予算より高くなっているため、機能の優先順位を見直したい」という趣旨であれば、これを全社に同時に伝え、再見積もりを依頼することで、公平性を保ったまま交渉を進めることができます。
また、一社を選んだ後に、他の会社にどのように結果を伝えるかも、後継者としての信頼づくりに関わってきます。選ばれなかった会社にも、丁寧に結果を伝え、可能であれば選ばなかった理由を簡潔に共有すると、今後別の機会に相見積もりを依頼する際の関係を良好に保つことができます。地域の中小企業にとって、開発会社との関係は一度きりで終わらないことも多いため、この対応も長期的には重要な意味を持ちます。
見積もりが返ってきたときの比較の仕方
条件をそろえて依頼を出しても、返ってくる見積もりの「見せ方」は会社によって異なります。ある会社は機能ごとに細かく分けた見積書を出し、別の会社は「一式」としてまとめた見積書を出すこともあります。これを公平に比較するために、次のような比較表を自分で作ることをおすすめします。
比較表には、少なくとも次の項目を並べてください。
- 会社名
- 総額（税込・税別を明記)
- 開発期間（見積もり提出日から数えて何ヶ月か)
- 「絶対に必要」機能がすべて含まれているか
- 「できれば欲しい」機能のうち、含まれているものはどれか
- 連携機能の対応可否
- 運用開始後のサポート費用（月額・年額）
- 支払いのタイミング（着手金・中間金・完了時の割合)
- 見積もりの前提条件（見積書に「〇〇を想定」と書かれている内容)
特に最後の「見積もりの前提条件」は見落としがちですが、非常に重要です。見積書の下部や別紙に、小さな文字で「本見積もりは〇〇を前提とする」「別途費用が発生する場合がある」といった注記が書かれていることがあります。ここを読まずに総額だけを比較すると、実際の請求額とのずれに後から気づくことになります。見積書の内訳の読み方をさらに詳しく確認したい場合は、システム開発の見積書、この内訳の見方で損を防ぐも参考になる。
相見積もりでよくある失敗パターン
ここでは、後継者が相見積もりを取る際によく陥る失敗パターンを、具体的に紹介します。自分の状況と照らし合わせながら確認してみてください。
失敗パターン1：口頭で伝えた内容を覚えていない
打ち合わせの場で口頭で要望を伝え、後日その内容をすっかり忘れてしまい、別の会社には違う内容を伝えてしまうケースです。打ち合わせのたびに要望が微妙に変わってしまうと、開発会社側も「結局何が欲しいのか」が分からなくなり、見積もりの精度が落ちます。対策は単純で、依頼内容メモを一度作ったら、それをすべての打ち合わせの「基準」として使い続けることです。打ち合わせの中で新しい要望が出てきたら、その場でメモに追記し、最新版を全社に再配布するようにしてください。
失敗パターン2：先に来た会社の提案に引っ張られる
最初に相談した会社の説明が分かりやすかったために、その会社の提案を基準にして他社を評価してしまうケースです。これ自体は自然な心理ですが、注意が必要なのは、最初の会社の言葉遣いや機能の分け方に他社を当てはめて考えてしまうことです。会社ごとに得意な領域や表現の仕方が違うため、同じ機能でも呼び方が異なることがあります。「これはA社が言っていた〇〇機能に当たりますか」と、他社にも確認しながら比較すると、認識のずれを防げます。
失敗パターン3：安さだけで決めてしまう
条件をそろえて比較した結果、一社だけ極端に安い見積もりが出てくることがあります。これは、その会社が本当に効率的に開発できるからかもしれませんが、次のような理由も考えられます。
- 見積もりの前提条件で、機能の範囲を実は絞っている
- 開発後のサポートを別料金にして、初期費用だけを抑えている
- 経験の浅い担当者が見積もりを作っていて、後から工数不足が発覚する
- 他社との差別化のために、最初だけ安く出して受注後に追加費用を積む方針
極端に安い見積もりが出てきた場合は、その理由を必ず質問してください。「なぜこの価格で実現できるのか」を聞いて、納得できる説明が返ってくるかどうかを確認しましょう。説明が曖昧だったり、「詳しくは契約後に」といった返答だったりする場合は、慎重に検討する必要があります。
失敗パターン4：高いところは最初から除外してしまう
逆に、一番高い見積もりを出した会社を、金額だけを理由に検討対象から外してしまうケースもよくあります。しかし、高い見積もりには、次のような理由がある場合もあります。
- 将来の拡張性を考慮した、しっかりとした設計を提案している
- 保守や運用のサポート体制が充実している分、費用に反映されている
- リスクを丁寧に洗い出した上で、余裕を持った工期と費用を積んでいる
金額だけで判断せず、なぜその金額になっているのかを必ず確認してから、除外するかどうかを決めてください。特に、システムは一度作ったら何年も使い続けるものです。目先の金額だけでなく、数年単位で見たときの総コストや、トラブル時の対応力も含めて判断することが大切です。
失敗パターン5：担当者の印象だけで決めてしまう
打ち合わせで話しやすかった、説明が丁寧だったという理由だけで、条件面の比較を後回しにして決めてしまうケースです。担当者との相性は確かに重要な要素ですが、それだけで決めると、後になって「金額に見合った内容だったのか」を検証する機会を失います。担当者の印象は比較表の一項目として加え、他の条件と並べて総合的に判断するようにしましょう。
失敗パターン6：比較を先延ばしにして期限が過ぎる
複数社から見積もりが届いても、比較検討に時間をかけすぎて、いつまでも決められないケースもあります。特に、先代から経営を引き継いだばかりの時期は、他の業務も多く、意思決定に時間がかかりがちです。あらかじめ「見積もりが揃ってから2週間以内に決定する」といった自分自身のルールを決めておくと、判断が長引くことを防げます。
相見積もりを取る社数の考え方
何社から見積もりを取るべきかという疑問もよく出てきます。一般的には3社程度が目安とされますが、これは絶対的なルールではありません。
社数が少なすぎると（1〜2社)、比較の材料が少なく、その金額が適正かどうかの判断がしづらくなります。逆に社数が多すぎると（5社以上)、比較検討にかかる時間と手間が増え、各社への質問対応や打ち合わせの調整だけでかなりの労力を消費してしまいます。特に後継者が経営の他の業務と並行して相見積もりを進める場合、社数を増やしすぎると本業に支障が出ることもあります。
3社程度であれば、価格帯の相場観を把握しつつ、比較検討の負担も現実的な範囲に収まります。最初の依頼先を選ぶ際は、次のような組み合わせを検討してみてください。
- すでに何らかの接点がある会社（先代の代からの付き合い、知人の紹介など)を1社
- インターネットで検索して見つけた、実績や事例の説明が分かりやすい会社を1社
- 商工会や取引先からの紹介など、第三者を介した紹介の会社を1社
このように出会い方の異なる会社を組み合わせることで、視点の偏りを減らすことができます。すべてが知人の紹介だと、断りにくくなったり、条件面での交渉がしづらくなったりすることもあるため、少なくとも1社は、こちらから直接アプローチした会社を含めておくと、比較の客観性が保たれます。
相見積もりを取ることを開発会社にどう伝えるか
相見積もりを取っていることを開発会社に伝えるべきかどうかも、よく相談される点です。結論としては、伝えたほうがよい場合が多いです。
理由は、相見積もりであることを知らせることで、開発会社側も「他社と比較される前提」で誠実な見積もりを出そうとする意識が働くからです。逆に、相見積もりであることを隠していると、後から発覚した際に「なぜ最初から言わなかったのか」と不信感を持たれ、その後の関係に影響することもあります。
伝える際の言い方としては、次のような表現が使いやすいでしょう。
「今回は複数の会社様にお声がけをして、比較検討させていただく予定です。公平に比較するため、同じ内容の依頼内容メモをすべての会社様にお渡ししております。ご質問がありましたら〇月〇日までにお願いいたします」
このように伝えれば、相見積もりであることも、条件をそろえていることも、同時に伝えることができます。開発会社にとっても、他社と比較される中でどう提案すればよいかの見通しが立ちやすくなり、結果的により誠実な提案が返ってくる可能性が高まります。
条件をそろえた上でも生じる「比較しにくさ」への対処
条件をそろえて依頼を出しても、それでも会社ごとの提案スタイルの違いから、比較が難しく感じる場面は残ります。そうした場合の対処法をいくつか紹介します。
同じ質問を全社に投げて回答をそろえる
比較表を作っていて「ここが分からない」と感じた項目があれば、その質問を全社に同じ形で投げてください。個別に気になったことをその場で質問するのではなく、いったんメモにまとめて、まとめて全社へ送るという運用を徹底すると、回答の粒度がそろいやすくなります。
提案書の構成を指定する
依頼内容メモの中に、「提案書には以下の項目を含めてください」と、提出してほしい書類の構成をあらかじめ指定しておく方法も有効です。例えば「1.提案概要、2.機能一覧と対応可否、3.開発体制、4.スケジュール、5.見積金額の内訳、6.保守サポート内容」という構成を指定すれば、各社の提案書がある程度同じ形式になり、比較がしやすくなります。
打ち合わせの質問リストを事前に統一する
各社との打ち合わせの際、その場の流れで質問内容が変わってしまうと、聞いた内容にばらつきが出ます。事前に「すべての会社に聞く共通の質問リスト」を10項目程度作っておき、それをすべての打ち合わせで使うようにすると、後から比較する際の材料がそろいます。
相見積もりの結果を先代や社内に説明するときの注意点
後継者の立場では、相見積もりの結果を先代や社内の関係者に説明し、了承を得なければならない場面もあるでしょう。その際、単に「A社が一番安かったので決めました」という説明だけでは、先代の世代からは「本当にそれで大丈夫なのか」と不安を持たれることがあります。
説明の際には、次の点を含めると納得感が高まります。
- 何社から、どのような条件で見積もりを取ったか
- 各社の提案内容の違い、金額の違いの理由
- 最終的に選んだ理由（金額だけでなく、提案内容・体制・実績なども含めて)
- 見積もりに含まれていない、今後発生しうる追加費用の見込み
特に、先代の世代は「言えば分かる」関係の中で長年やってきたケースが多いため、条件をそろえて複数社を比較するという進め方自体に馴染みがないこともあります。プロセスを丁寧に説明することで、後継者としての判断の妥当性を伝えることができ、社内の理解も得やすくなります。
まとめ
相見積もりで条件をそろえるということは、単に「同じことを3社に言う」という表面的な作業ではありません。自分自身が「何を、なぜ、誰のために、いつまでに作りたいのか」を明確に言語化し、それを文書にして、すべての会社に同じ形で伝え、質問への回答も同じ形で共有し続けるという、一連のプロセスです。
このプロセスを丁寧に行うことで、見積もりの金額差の理由が見えるようになり、単純な安さだけでなく、提案内容や体制、将来的なコストまで含めた総合的な判断ができるようになります。先代から経営を引き継いだばかりで、開発会社とのやり取りに不安を感じている方でも、依頼内容メモというシンプルな道具を使うことで、条件をそろえた公平な比較が可能になります。
最初の一回は手間に感じるかもしれませんが、この依頼内容メモは一度作れば、次に別のシステムを発注する際にも形式を再利用できます。相見積もりの精度を高める投資として、ぜひ取り組んでみてください。提案書そのものの見極め方は刷新の相談先を見極めるために、提案書で見るべきポイント、相見積もりの前段としてRFPを作るべきかどうかはRFPは必要？承継後の会社が現実的に進める方法でそれぞれ解説している。
よくある質問
Q1. 相見積もりを取ることを、既存の付き合いのある会社に伝えると気を悪くされませんか。
丁寧に伝えれば、多くの会社は理解してくれます。「今回は初めての大きな発注なので、社内の説明のためにも複数社を比較させていただきたい」というように、比較する理由を添えて伝えると、納得してもらいやすくなります。長年の付き合いがある会社であれば、むしろ正直に相見積もりを取る意向を伝えたほうが、その後の関係にとってもプラスになることが多いです。
Q2. 依頼内容メモを作る時間がなかなか取れません。どこまで簡略化してよいですか。
最低限、「何を作りたいか」「誰が使うか」「いつまでに欲しいか」「予算感」の4項目だけでも、口頭でその場ごとに伝えるより、条件をそろえる効果は大きく上がります。時間がない場合は、まずこの4項目だけを一枚のメモにまとめて、全社に同じ形で渡すことから始めてください。機能の詳細な優先順位づけなどは、後から打ち合わせの中で肉付けしていくこともできます。
Q3. 見積もりの金額が全社ともに予算を大きく超えていた場合、どうすればよいですか。
まず、なぜ全社が同じように高くなったのかを考えてみてください。多くの場合、依頼内容メモに書いた「絶対に必要」な機能自体が、想定より大掛かりだった可能性があります。その場合は、機能の優先順位を見直し、「絶対に必要」な部分をさらに絞り込んだ上で、再度見積もりを依頼するとよいでしょう。一度に全部を作るのではなく、まず必要最小限の部分だけを作り、後から段階的に機能を追加していくという進め方も検討の余地があります。何から刷新に着手するかを見直す全体的な進め方は承継後2〜3年目、何から刷新するかを決める全体の進め方でも整理している。
Q4. 見積もりの内訳が「一式」としか書かれていない会社があります。詳細を求めてもよいですか。
もちろん求めてよいですし、求めるべきです。「どの機能にどのくらいの費用がかかっているのか、内訳を教えてください」と依頼すれば、多くの会社は対応してくれます。内訳を出すことを渋る、あるいは「企業秘密なので出せない」と言われる場合は、その後の関係でも情報が見えにくい進め方になる可能性があるため、注意深く検討したほうがよいでしょう。詳細な内訳が分かれば、他社の見積もりとも項目単位で比較でき、条件をそろえる作業の精度がさらに上がります。
相見積もりの対象にノーコード・ローコード外注を含める場合は注意点がある。ノーコード外注、先代のシステムを任せる前に知っておきたい落とし穴を確認しておきたい。
