結論：見るべきは「見積金額」ではなく「要件が固まっていない状態への向き合い方」
システム開発の発注で最も失敗が多いのは、要件が固まりきらないまま金額だけで選んだケースです。開発会社選びで本当に差が出るのは、価格でも技術力でもなく、「まだ決まっていないこと」をどう扱うかの姿勢です。
この記事では、相見積もりを取る前に確認すべき比較軸を、実務の判断順に整理します。
なぜ「安いところ」を選ぶと高くつくのか
同じ要件書を3社に渡しても、見積額は2〜3倍の開きが出ます。この差は技術力の差ではなく、要件の読み方の差であることがほとんどです。
見積が安い会社に起きていること
| パターン | 発注後に起きること |
|---|---|
| 書かれたことだけを最小構成で見積もった | 「それは要件に無かった」と追加費用が発生する |
| 曖昧な部分を楽観的に解釈した | 認識違いが発覚し、作り直しになる |
| 見積時点で設計を詰めていない | 着手後に「できない」が判明する |
要件書に書かれていないことは必ずあります。その空白をどう埋めるつもりかを見積の段階で説明できる会社は、着手後の追加費用が少なくなります。
高ければいいわけでもない
逆に、必要以上に大きな構成を提案してくる場合もあります。「将来を見据えて」という説明には注意が必要です。使われない機能への投資は、初期費用だけでなく保守費用も一生ついてきます。
判断基準は「今、何のために必要か」を1文で説明できるかどうかです。
比較チェックリスト：発注前に確認する11項目
A. 要件の扱い方（最重要）
① 要件が固まっていない部分を指摘してくれたか
こちらの要件書を見て「ここは決まっていませんね」と言える会社は、後から揉めません。何も言わずに見積を出してきた場合、空白を都合よく解釈している可能性があります。
② 「やらないこと」を明示しているか
見積書に「本見積に含まないもの」が書かれているかを確認してください。含まないものが書かれていない見積書は、後から解釈が割れます。
③ 要件定義を別工程として提案してきたか
規模が大きい案件で、いきなり全体の見積を出してくる会社より、まず要件定義だけを区切って提案する会社のほうが誠実です。決まっていないものは見積れないからです。
B. 見積の中身
④ 工程と工数の内訳が出ているか
「一式 300万円」では判断できません。要件定義・設計・実装・テスト・移行それぞれに何人日かかるのかが出ていれば、妥当性を検討できます。
⑤ 人月単価の水準が説明できるか
日本の受託開発では、一般に中小規模で月60〜100万円、大手で月100〜200万円程度といわれます。単価そのものより、その単価にどんな役割の人が含まれるか（PM・設計・実装・テストの比率）が説明できるかを見てください。
⑥ 保守・運用の費用が提示されているか
作って終わりではありません。月額いくらで、何をしてくれるのかが初期見積の段階で出てくるかを確認します。
C. 体制と進め方
⑦ 誰が作るのかが分かるか
営業担当と実際の開発者が別会社（再委託）というケースがあります。悪いことではありませんが、質問の答えが返ってくるまでの時間が変わります。体制図を求めてください。
⑧ 進捗をどう共有するかが決まっているか
週次の定例があるか、進捗が見える場所があるか。「できたら見せます」という進め方は、認識違いの発覚が遅れます。
⑨ 仕様変更の扱いが決まっているか
開発中に必ず変更は出ます。変更をどう受け付け、どこから追加費用になるのかが事前に決まっているかを確認してください。
D. 引き渡しとその後
⑩ ソースコードとデータの権利がどうなるか
納品後のソースコードが誰のものかを契約で確認します。「保守を頼まないとソースを渡さない」という条件は、後の選択肢を奪います。
⑪ 他社に引き継げる状態で納品されるか
ドキュメント、環境構築手順、依存関係の一覧。これらが揃っていないと、その会社以外は触れないシステムになります。長期的に見て最も高くつくのがこの状態です。