結論：見るべきは「見積金額」ではなく「要件が固まっていない状態への向き合い方」

システム開発の発注で最も失敗が多いのは、要件が固まりきらないまま金額だけで選んだケースです。開発会社選びで本当に差が出るのは、価格でも技術力でもなく、「まだ決まっていないこと」をどう扱うかの姿勢です。

この記事では、相見積もりを取る前に確認すべき比較軸を、実務の判断順に整理します。

なぜ「安いところ」を選ぶと高くつくのか

同じ要件書を3社に渡しても、見積額は2〜3倍の開きが出ます。この差は技術力の差ではなく、要件の読み方の差であることがほとんどです。

見積が安い会社に起きていること

パターン 発注後に起きること
書かれたことだけを最小構成で見積もった 「それは要件に無かった」と追加費用が発生する
曖昧な部分を楽観的に解釈した 認識違いが発覚し、作り直しになる
見積時点で設計を詰めていない 着手後に「できない」が判明する

要件書に書かれていないことは必ずあります。その空白をどう埋めるつもりかを見積の段階で説明できる会社は、着手後の追加費用が少なくなります。

高ければいいわけでもない

逆に、必要以上に大きな構成を提案してくる場合もあります。「将来を見据えて」という説明には注意が必要です。使われない機能への投資は、初期費用だけでなく保守費用も一生ついてきます。

判断基準は「今、何のために必要か」を1文で説明できるかどうかです。

比較チェックリスト：発注前に確認する11項目

A. 要件の扱い方（最重要）

① 要件が固まっていない部分を指摘してくれたか

こちらの要件書を見て「ここは決まっていませんね」と言える会社は、後から揉めません。何も言わずに見積を出してきた場合、空白を都合よく解釈している可能性があります。

② 「やらないこと」を明示しているか

見積書に「本見積に含まないもの」が書かれているかを確認してください。含まないものが書かれていない見積書は、後から解釈が割れます。

③ 要件定義を別工程として提案してきたか

規模が大きい案件で、いきなり全体の見積を出してくる会社より、まず要件定義だけを区切って提案する会社のほうが誠実です。決まっていないものは見積れないからです。

B. 見積の中身

④ 工程と工数の内訳が出ているか

「一式 300万円」では判断できません。要件定義・設計・実装・テスト・移行それぞれに何人日かかるのかが出ていれば、妥当性を検討できます。

⑤ 人月単価の水準が説明できるか

日本の受託開発では、一般に中小規模で月60〜100万円、大手で月100〜200万円程度といわれます。単価そのものより、その単価にどんな役割の人が含まれるか（PM・設計・実装・テストの比率）が説明できるかを見てください。

⑥ 保守・運用の費用が提示されているか

作って終わりではありません。月額いくらで、何をしてくれるのかが初期見積の段階で出てくるかを確認します。

C. 体制と進め方

⑦ 誰が作るのかが分かるか

営業担当と実際の開発者が別会社（再委託）というケースがあります。悪いことではありませんが、質問の答えが返ってくるまでの時間が変わります。体制図を求めてください。

⑧ 進捗をどう共有するかが決まっているか

週次の定例があるか、進捗が見える場所があるか。「できたら見せます」という進め方は、認識違いの発覚が遅れます。

⑨ 仕様変更の扱いが決まっているか

開発中に必ず変更は出ます。変更をどう受け付け、どこから追加費用になるのかが事前に決まっているかを確認してください。

D. 引き渡しとその後

⑩ ソースコードとデータの権利がどうなるか

納品後のソースコードが誰のものかを契約で確認します。「保守を頼まないとソースを渡さない」という条件は、後の選択肢を奪います。

⑪ 他社に引き継げる状態で納品されるか

ドキュメント、環境構築手順、依存関係の一覧。これらが揃っていないと、その会社以外は触れないシステムになります。長期的に見て最も高くつくのがこの状態です。

相見積もりの取り方

同じ条件で比較するために渡すもの

渡すもの 理由
現状の業務フロー 何を置き換えるのかが伝わる
現在使っているツール・システム名 連携の可否が判断できる
使う人数と、その人たちのITへの習熟度 画面設計の前提が変わる
予算の上限（レンジで可） 実現可能な構成に絞れる
いつまでに必要か 段階リリースの提案が出せる

予算を伝えると足元を見られると考える方がいますが、伝えないほうが不利になります。予算が分からないと、各社が想定するグレードがバラバラになり、比較できない見積が並びます。

比較の落とし穴

  • 金額だけを並べた表を作らない：含まれる範囲が違うので、比較になりません
  • 納期の短さで選ばない：短い納期の裏には、テスト工程の圧縮があります
  • 提案書の厚さで選ばない：厚い提案書は営業リソースの表れであって、開発力の表れではありません

中小企業が特に注意すべき点

「業務に合わせる」か「業務を合わせる」か

既製パッケージで足りるなら、そのほうが安く早く済みます。開発会社に相談したときに、「作らなくていい」と言ってくれるかは信頼できる相手かの試金石です。

すべてを受託したい会社は、パッケージで済む話でも開発を提案します。既製品との比較を提示してくる会社のほうが、長期的に付き合いやすい傾向があります。

小さく始められる提案か

いきなり全社導入・全機能実装ではなく、一部門・一機能から始めて広げる提案ができるかを見てください。使われないまま終わるシステムの多くは、最初から大きすぎたものです。

現場を見に来るか

業務システムは、現場の作業を見ないと設計できません。ヒアリングをオンラインの1時間で済ませようとする会社と、実際の作業を見せてほしいと言う会社では、出てくる設計が変わります。

よくある質問

Q. 見積の妥当性を判断できません。どうすれば？

工程ごとの人日数を出してもらい、「この機能でこの工数がかかる理由」を質問してください。答えに具体性があるかで判断できます。金額の絶対値より、説明が成立するかが指標になります。

Q. 大手と中小、どちらがいいですか？

規模より、担当者が変わらないかを見てください。中小企業の業務システムは、業務の細部を理解している人がいるかどうかで品質が決まります。

Q. 開発中に会社が対応しなくなったらどうなりますか？

これを防ぐのが⑩⑪です。ソースコードと構築手順が手元にあれば、最悪でも他社へ引き継げます。契約時に必ず確認してください。

Q. 補助金は使えますか？

システム開発は補助対象になる制度があります。ただし公募時期・要件は年度で変わり、採択は保証できません。当社は制度の説明と、要件に沿った見積書の作成までは支援できますが、申請代行は行っていません。

当社の考え方

Nortiq Labs は、いただいた要件をそのまま見積るのではなく、まず「作らなくて済む方法」を検討します。既製サービスの組み合わせで足りるなら、そう申し上げます。

実際に、iPad アプリと外部POS（スマレジ）を連携させた在庫登録システムのように、作る部分と既製品に任せる部分を切り分けた構成を採ることが多くあります。

ご相談の段階で「これは作らないほうがいい」とお伝えすることもあります。判断材料をお求めでしたら、現状の業務フローを拝見した上で率直にお答えします。

関連記事

  • 社内システム外注の要件定義チェックリスト｜失敗を防ぐ7項目
  • 社内システム外注費用の相場と工数単価の見方｜失敗しない発注ガイド