システム開発の見積もりは、受け取ってから困ることが多い書類です。金額が妥当なのか、なぜ会社によって 3 倍も開くのか、どこまで交渉できるのか。この記事は、発注担当者が見積もりについて判断するために必要なことを 1 本にまとめたものです。
必要な章だけ拾って読めるように構成しています。まず全体像を掴みたい方は「1. 相場」から、既に見積もりを受け取っている方は「2. 見積書の読み方」から読んでください。
1. 相場 — 見積もりは「工数 × 単価 + 諸経費」で決まる
システム開発の見積もりは、機能ごとの定価があるわけではありません。必要な作業量 (工数) に、担当者の単価を掛け、そこへ諸経費を乗せるという構造で決まります。
「1 人月」とは、エンジニア 1 人が 1 か月フルタイムで作業したときの作業量です。「3 人月」なら「1 人で 3 か月」または「3 人で 1 か月」で終わる想定量を指します。暦の 1 か月ではなく、平日 20 日・1 日 8 時間を前提とした概念です。
| 単位 | 意味 | 目安 |
|---|---|---|
| 1 人時 (MH) | 1 人が 1 時間作業した量 | 1 時間 |
| 1 人日 (MD) | 1 人が 1 営業日作業した量 | 約 8 時間 |
| 1 人月 (MM) | 1 人が 1 か月作業した量 | 約 20 営業日・160 時間 |
役割別の人月単価
単価は担当者の役割と経験で変わります。同じ「Web システム開発」でも、担当者の構成次第で総額が 1.5〜2 倍変わるのはこのためです。
| 役割 | 人月単価の目安 |
|---|---|
| ジュニアエンジニア (実務 2〜3 年) | 60〜80 万円 |
| 中堅エンジニア (実務 3〜7 年) | 80〜120 万円 |
| シニア / テックリード | 120〜180 万円 |
| PM / PL | 100〜160 万円 |
| UI / UX デザイナー | 80〜130 万円 |
| オフショア (東南アジア) | 30〜60 万円 |
見積もりの末尾には、一般管理費やプロジェクト管理費として工数費の 10〜20% 程度が乗るのが一般的です。この項目自体は不当なものではなく、進行管理や品質管理にかかる実費です。
種類別の費用相場
対象によって、同じ規模でも金額帯が変わります。
| 開発の種類 | 小規模 | 中規模 | 大規模 |
|---|---|---|---|
| Web システム (業務効率化・SaaS) | 300 万〜800 万円 | 800 万〜2,500 万円 | 2,500 万円〜 |
| スマホアプリ (iOS・Android 両対応) | 500 万〜1,200 万円 | 1,200 万〜3,000 万円 | 3,000 万円〜 |
| 業務システム (社内向け) | 400 万〜1,000 万円 | 1,000 万〜3,000 万円 | 3,000 万円〜 |
| EC サイト (フルスクラッチ) | 500 万〜1,500 万円 | 1,500 万〜4,000 万円 | 4,000 万円〜 |
| AI・機械学習システム | 800 万〜2,000 万円 | 2,000 万〜5,000 万円 | 5,000 万円〜 |
いずれも税抜の目安です。この表は「自社の案件がどの帯にいるか」を確かめるためのもので、個別の金額を当てるものではありません。
規模別の目安
種類ではなく規模で見ると、社内の予算組みに使いやすくなります。
| 規模 | 想定工数 | 画面数の目安 | 期間 |
|---|---|---|---|
| 小規模 (〜300 万円) | 1〜3 人月 | 5〜10 画面 | 1〜3 か月 |
| 中規模 (300 万〜2,000 万円) | 3〜20 人月 | 20〜60 画面 | 3〜9 か月 |
| 大規模 (2,000 万円〜) | 20 人月以上 | 複数チーム編成 | 9 か月〜数年 |
帯によって、費用の中身の比率も変わります。小規模帯では、実装よりも確認の往復にかかるコストの比率が上がります。 逆に大規模帯では、PMO・品質保証・受入テスト・移行支援といった開発以外の工程が総額の 30〜50% を占めることがあります。
日本の受託開発でもっとも多いのは中規模帯です。要件定義から本番リリースまで一通り回すため、進行管理と品質保証に一定の費用がかかります。
相場を知る意味
相場感がないまま見積もりを受け取ると、「A 社は 300 万円、B 社は 900 万円」と 3 倍以上開いたときに判断ができません。相場は値切るための材料ではなく、桁違いの見積もりを見抜くための物差しとして使ってください。
2. 見積書の読み方 — 金額ではなく「金額の根拠」を読む
見積書で最初に見るべきは総額ではありません。その金額がどう組み立てられているかです。
見積書に含まれる 7 つの構成要素
一般的な開発見積書は、次の要素で構成されます。
| 構成要素 | 記載内容 | 見るポイント |
|---|---|---|
| 表紙 (かがみ) | 宛先、発行日、案件名、見積総額 | 案件名が自社の呼び方と一致しているか |
| 作業内訳 | 工程・機能単位のタスク一覧 | 粒度が細かいか、抜けはないか |
| 工数見積 | 各タスクの人日 / 人月 | 合算値だけでなく内訳が開示されているか |
| 金額 | 単価 × 工数、諸経費、消費税 | 単価と工数が分離して書かれているか |
| 前提条件 | 見積の根拠となる想定 | 自社の想定と食い違っていないか |
| 有効期限 | 見積の有効期間 | 通常 1〜3 か月、延ばす場合は要再見積 |
| 支払条件 | 支払時期・分割条件 | 検収前後の支払比率、着手金の有無 |
このうち最も重要なのは「前提条件」欄です。金額は前提条件の上に成り立っているため、ここを読まずに総額だけ比較しても意味がありません。
開発会社は工数をどう積んでいるか
工数の出し方は 3 通りあり、どれを使ったかで精度が変わります。見積書からは直接読み取れないので、気になる場合は聞いてください。
類推見積 (アナロジー法) は、過去の似た案件と比べて出す方法です。速く出せますが、比較対象がずれていると大きく外します。初回相談での概算はこれで出ていることがほとんどです。
ボトムアップ見積 は、作業を細かく分解して一項目ずつ積み上げる方法です。時間はかかりますが精度が高く、内訳が細かい見積書はこの方法で作られています。
機能ポイント法 (FP 法) は、機能の数と複雑さを点数化して工数へ換算する方法です。大手 SIer や公共案件で使われ、社内で稟議を通しやすい反面、実装技術の違いが反映されにくいという性質があります。
総額を検算する
内訳が出ていれば、掛け算で妥当性を確かめられます。600 万円の Web システム見積であれば、次のような形に分解できるはずです。
| 項目 | 工数 | 単価 | 小計 |
|---|---|---|---|
| PM | 1.0 人月 | 130 万円 | 130 万円 |
| エンジニア | 3.5 人月 | 100 万円 | 350 万円 |
| デザイナー | 0.5 人月 | 100 万円 | 50 万円 |
| 管理費 (10%) | — | — | 53 万円 |
| 合計 | 5.0 人月 | — | 583 万円 |
ここで見るのは金額の一致ではありません。総額を人月に割り戻したとき、その人数と期間で本当に終わるのかという点です。5 人月を 6 か月でやるなら実質 1 人弱の体制であり、PM が兼任である可能性が高いと読めます。
工数が過大 / 過少になっているサイン
内訳を見たとき、次のような偏りがあれば理由を聞いてください。
過大のサインは、要件定義が全体の 30% を超えている、テスト工数が実装の 2 倍近くある、役割が細かく分かれすぎていて 1 人あたりの稼働が薄い、といった形で出ます。
過少のサインは逆で、テスト工数が実装の 10% 程度しかない、要件定義や設計の行がない、移行と運用引き渡しの記載がない、といった形です。過少のほうが危険です。 抜けている工程は消えたのではなく、後から追加費用として現れます。
前提条件で必ず確認すること
- 想定しているユーザー数・データ量
- 対応するブラウザ・OS の範囲
- テストの範囲 (どこまでを開発会社が担保するか)
- 発注側が用意するもの (素材・アカウント・環境)
- 意思決定にかかる日数の想定
最後の項目は見落とされがちです。「1 営業日で返す」前提で組まれた見積もりに対して、実際は稟議や役員確認で 1 週間かかる場合、その待ち時間は工数として跳ね返ります。
危険信号
次のような見積書は、後から追加費用が発生する可能性が高いと考えてください。
- 総額しか書かれておらず、工数と単価の内訳がない
- 「一式」という表記が多用されている
- テスト工程の記載がない、または極端に薄い
- 前提条件欄が空欄、または一般論しか書かれていない
- 運用引き渡しやドキュメントの扱いが書かれていない
3. なぜ会社によって数倍違うのか
「同じ要件で相見積を取ったのに、A 社は 300 万円、B 社は 900 万円、C 社は 1,500 万円だった」という相談は珍しくありません。3 倍以上の差を前にすると「どこかが吹っかけている」と考えたくなりますが、多くの場合はどちらも正しいというのが実情です。
差が生まれる要因は 4 つあります。
要因 1: 単価の差
エンジニアの人月単価は、会社の体制・所在地・保有スキルで大きく変わります。自社の正社員だけで組む会社、協力会社を使う会社、オフショアを組み合わせる会社では、同じ工数でも金額が変わります。
要因 2: 想定スコープの差
「同じ要件」を渡しても、各社が想定する作業範囲は揃いません。たとえば「会員登録機能」と書いてあるだけでは、メール認証の有無、退会処理、管理画面での会員管理まで含むかどうかが会社ごとに異なります。
要因 3: 品質水準の差
自動テストのカバレッジ目標を 80% に置く会社と、手動テストで最低限確認する会社では、テスト工数が 2〜3 倍違います。一般的な受託開発では、テスト工程は開発工数の 30〜50% を占めるため、ここの前提差が総額に直結します。
要因 4: 積算方法の差
「経験ベースでざっくり」出す会社と、作業を細かく分解して一項目ずつ積む会社では、同じ機能でも 1.3〜1.8 倍の差が出ることがあります。
開発会社のタイプによる傾向
会社のタイプが違えば、そもそも土俵が違います。同じ案件を投げても、得意な規模帯から外れていれば金額は跳ねます。
| タイプ | 従業員規模の目安 | 主な案件レンジ | 得意領域 |
|---|---|---|---|
| 大手 SIer | 数千〜数万人 | 数千万〜数十億円 | 基幹システム、公共、金融 |
| 中堅 SIer | 数百〜千人規模 | 数千万〜数億円 | 業務システム、社内基幹 |
| 独立系受託開発会社 | 30〜300 人規模 | 500 万〜1 億円 | 業務 Web、BtoB SaaS |
| Web 系開発会社 | 10〜100 人規模 | 300 万〜5,000 万円 | Web サービス、アプリ |
| スタートアップ系ブティック | 数人〜30 人規模 | 300 万〜3,000 万円 | MVP、新規事業、PoC |
誰が実際に手を動かすか
タイプによる金額差の実体は、契約する会社と、実装する人が同じかどうかにあります。
大手 SIer では、契約主体が要件定義と全体管理を担い、実装は協力会社が入ることが一般的です。品質管理の層が厚いぶん間接費が乗り、単価は高くなります。一方で、大規模・高信頼性の案件で体制を維持できるのはこの層です。
独立系や Web 系の開発会社では、提案した担当者がそのまま実装に入ることが多くなります。間接費が薄いぶん単価は下がりますが、体制の冗長性は落ちます。
確認すべきは、提案の場にいる人が実装するのかどうかです。 ここが違うと、伝えた前提が実装者まで届くかどうかが変わります。
安い会社が悪い、高い会社が良い、という話ではありません。 案件の性質と、自社が許容できるリスクで選ぶものです。
4. 見積もりが高い / 安い要因と、安すぎる見積もりの見分け方
金額を左右する 5 要因
| 要因 | 金額インパクトの目安 | コントロール主体 |
|---|---|---|
| 要件の明確さ | ±20〜30% | 発注側 |
| 非機能要件 | +20〜100% | 発注側 (規制で不可避もあり) |
| デザインの作り込み度 | ±30〜80% | 発注側 |
| 既存システムとの連携数 | +10〜50% | 発注側と開発側で半々 |
| 発注側の意思決定スピード | ±10〜20% | 発注側 |
5 つのうち 4 つは発注側が動かせます。要件を具体的に書く、デザインを標準化する、社内の決裁ルートを事前に整える。この 3 つだけで見積もりは動きます。
非機能要件だけは、業界規制で下げられない部分が残ります (第 7 章で詳述)。
良い削減と悪い削減
コストを下げるとき、あとで効いてくる削減と、あとで高くつく削減があります。
あとで効いてくるのは、作るものを減らす削減です。初期リリースの機能を絞る、デザインを標準コンポーネントに寄せる、対応環境を絞る。いずれも総額に効く割に、品質は落ちません。
あとで高くつくのは、作り方を薄くする削減です。テスト工程を削る、ドキュメントを省く、レビューを飛ばす。目先の金額は下がりますが、リリース後の改修と引き継ぎで回収されます。
削減に手をつける順番は、インパクトの大きいものからです。 機能を 3 割削れば総額は 2〜3 割動きますが、単価交渉で動くのは数%です。
安すぎる見積もりの構造
複数社から見積もりを取ったとき、1 社だけ他社の半分以下を提示してくることがあります。安さ自体は問題ではありませんが、その理由が説明できるかを確認してください。
危険なのは、次のスコープが抜けているケースです。
- テスト工程 (開発工数の 30〜50% を占める)
- 非機能要件への対応
- ドキュメントの作成
- 運用引き渡しと保守の初期対応
- データ移行
これらが抜けたまま契約すると、総額が 1.5〜2 倍に膨らむことは珍しくありません。「小さな仕様変更」でも 1 件あたり数十万円が積み上がり、5〜10 件たまると初期見積もりを超える追加請求になります。
年間保守費が開発費の 30% を超えるような提示になっている場合も、初期の安さを保守で回収する設計になっている可能性があります。一般的な保守費の目安は年間で開発費の 15〜20% です。
「なぜ安いのか」は直接聞いてよい
安い理由が説明できる会社は問題ありません。説明できる安さと、説明できない安さを分けるのが目的です。
説明できる安さの例としては、似た案件のテンプレートを持っている、社内に同じ構成の実績がある、オフショアを組み合わせている、初回実績づくりとして戦略的に受けている、といったものがあります。いずれも根拠が具体的です。
一方、「頑張ります」「なんとかします」といった精神論しか返ってこない場合は、積算していない可能性があります。
安さを許容できる案件、できない案件
安さを取ってよい案件もあります。判断の分かれ目は、失敗したときに作り直せるかどうかです。
許容できるのは、社内利用に限る小規模ツール、検証目的の PoC、使い捨て前提のキャンペーンサイトなど、止まっても事業が痛まないものです。
許容してはいけないのは、売上が直接乗るシステム、個人情報や決済を扱うもの、基幹業務に接続するもの、長期の保守が前提のものです。ここで安さを取ると、作り直しのコストが初期見積もりを大きく超えます。
5. 概算見積と本見積 — 精度が違う
初期相談で受け取った「概算 300 万円」と、後日出てきた「本見積 620 万円」。この 2 つは矛盾していません。そもそも精度が違う書類だからです。
| 種類 | 出てくる時点 | 精度 | 用途 |
|---|---|---|---|
| 概算見積 | 相談〜初回ヒアリング後 | ±30〜50% | 予算感の確認、社内の企画通し |
| 本見積 | 要件定義完了後 | ±10〜15% | 契約金額の根拠、正式な稟議 |
| 確定見積 | 契約締結時・着手直前 | ±5% 以内 | 実際の契約金額 |
概算が単一の数字で示されていても、実際には ±30〜50% のレンジを内包していると考えるのが妥当です。本来は「300〜500 万円」のように幅で提示されるべきものです。
概算で意思決定する罠
最も危険なのは、概算の数字をそのまま稟議に通してしまうことです。要件が固まった段階で本見積が上振れし、稟議のやり直しに追い込まれます。
対策は 2 つあります。
- 稟議上限を、概算の中央値ではなく上限値 + 10〜15% で通しておく
- 初期ヒアリングの時点で情報を厚く渡し、レンジ自体を絞る
後者は効果が大きく、±50% だったレンジが ±20% 程度まで絞れることも珍しくありません。何を渡すべきかは第 10 章で扱います。
概算と本見積の差は、どこまで許容してよいか
要件定義を挟めば金額は動きます。問題は、その動き方が説明できるかどうかです。
概算から本見積への上振れが ±30% の範囲なら、要件定義で解像度が上がった結果として自然です。50% を超える上振れが出た場合は、概算の前提と本見積の前提を並べて、どの機能がどれだけ増えたのかを確認してください。
このとき見るのは金額差ではなく、機能の数と非機能要件の水準がどう変わったかです。概算時点で聞かれていなかった要件が本見積で足されているなら、それは正当な増加です。一方、同じ機能一覧のまま金額だけ上がっているなら、概算が営業的に低く出されていた可能性があります。
6. バッファと予備費 — 「その他」の中身
見積もりの末尾にある「予備費」「バッファ」「その他」。工数費の 10〜20% を占めることもあり、削れないかと気になる項目です。
まず、呼び方によって中身が違います。ここを混ぜて交渉すると話が噛み合いません。
| 呼び方 | 主な意味 | 使いどころ |
|---|---|---|
| 予備費 | 見積時点で想定していない事象への備え | 想定外の要件追加・追加調査 |
| バッファ | 各タスクの工数に乗せる余裕分 | 実装・テストの遅延吸収 |
| コンティンジェンシー | 特定リスクが顕在化した場合の備え | 新技術検証・API 仕様変更対応 |
| その他 | 上記に分類しにくい小額費目 | 打合せ交通費・軽微な調査費 |
| 一般管理費 | 会社運営のための間接費 | オフィス費・バックオフィス費 |
このうち 一般管理費は交渉の対象になりません。 会社の固定費であり、案件ごとに動かせる性質のものではないためです。動かせるのは予備費とコンティンジェンシーで、これは不確実性が減れば下がります。
結論から言うと、バッファは削るべきものではありません。開発には、着手してみないと分からない部分が必ずあります。バッファがない見積もりは、原価ぎりぎりで組んでいるか、後の追加請求を前提にしているかのどちらかです。
妥当なバッファ率
| 案件タイプ | バッファ率 | 理由 |
|---|---|---|
| 要件が固まった小規模改修 | 5〜10% | 影響範囲が読み切れる |
| 要件定義済みの新規開発 | 10〜15% | 一般的な Web システム |
| RFP ベースの中〜大規模開発 | 15〜20% | 前提未確定の項目が残る |
| 新技術・PoC 要素あり | 20〜30% | AI・データ基盤・新規プロトコル |
| リプレイス案件 | 20〜30% | 既存仕様の掘り起こしコスト |
| アジャイル・準委任 | 明示分は薄い | 変動は精算で吸収する前提 |
10% 未満は過小、30% 超は過大のサインです。前者は追加請求のリスク、後者は情報不足で会社側がリスクを高く見積もっている可能性を示します。
バッファを下げる正しい交渉
バッファは「削ってください」では下がりません。バッファの正体は不確実性なので、不確実性を減らせば自動的に下がります。 打ち手は 4 つあります。
- 情報を足す。読めていない部分を聞き出し、その資料を渡す
- 段階契約に分ける。要件定義だけ先に契約し、確度が上がってから本体を見積もり直す
- 凍結する範囲を宣言する。「この画面群は着手後に変更しない」と先に約束する
- 追加請求のルールを合意する。何が追加対象か決まっていれば、備えを厚くする必要が減る
30% を超えている場合は、値引きを求めるより「どの部分が読めていないのか」を聞くほうが、結果的に金額が下がります。
7. 非機能要件 — 指定 1 つで工数が数十%変わる
見積もりの差を生む要因のうち、発注側が最も無自覚なまま金額を動かしているのが非機能要件です。同じ会員登録機能でも、可用性 99.0% と 99.99% では設計も冗長化構成も別物になります。
| 分類 | 影響レンジ | 主な内容 |
|---|---|---|
| 可用性 | +5〜30% | 冗長化構成、24 時間 365 日監視 |
| 性能・拡張性 | +10〜40% | 同時接続数の想定、負荷試験、キャッシュ設計 |
| 運用・保守性 | +5〜20% | 監視ダッシュボード、ジョブ管理、運用手順書 |
| 移行性 | +5〜25% | 既存データ移行、並行稼働、切戻し設計 |
| セキュリティ | +10〜50% | 脆弱性診断、監査ログ、暗号化、鍵管理、規格準拠 |
| システム環境 | +0〜15% | オンプレ制約、業界固有の設置要件 |
具体例を挙げます。開発費 1,500 万円の中規模 Web システムで、可用性を「99.9% (月 43 分の停止許容)」から「99.99% (月 4.3 分)」へ引き上げるだけで、200〜400 万円の上振れが発生します。
過剰スペックを避ける
「念のため 10 倍」で指定すると、そのまま 10 倍の設計になります。BtoC の Web サービスでも、キャンペーンを除けば登録ユーザーの 5〜10% が同時利用というのが現実的な上限です。
一方で、設計の初期に決めておくかどうかで、同じゴールに到達する工数が 2〜3 倍変わります。後から追加すると作り直しになる領域なので、「決めない」のではなく「現実的な水準を早期に決める」のが正解です。
水準を決めるための 3 つの問い
過剰か適正かは、次の 3 つに答えれば絞れます。いずれも技術の話ではなく、事業の話です。
- 止まったとき、事業にいくら損失が出るか。1 時間止まって数万円なら、冗長化に数百万円は釣り合いません
- ピーク時の同時利用者は本当に何人か。登録者数ではなく、同時に操作する人数で答えます
- 扱うデータが漏れたとき、影響はどこまで及ぶか。決済情報や医療情報があるなら、セキュリティは削る対象になりません
発注前に埋めるチェックリスト
次の 13 項目を埋めて渡すと、各社の前提が揃います。埋まらない欄があること自体が発見です。 その欄が、見積もりのばらつきを生んでいる箇所です。
| 項目 | 記入例 |
|---|---|
| 想定同時利用者数 (通常時 / ピーク時) | 通常 50 / ピーク 200 |
| 応答時間の目安 | 一覧表示 3 秒以内、検索 5 秒以内 |
| 稼働時間帯 | 平日 8:00〜22:00、土日は縮退運用可 |
| 許容停止時間 (月あたり) | 60 分以内 |
| バックアップ頻度と保持期間 | 日次 / 30 日 |
| 障害復旧目標時間 (RTO) | 4 時間以内 |
| 障害復旧目標地点 (RPO) | 24 時間以内のデータ喪失は許容 |
| 取り扱うデータの機密度 | 顧客の連絡先 / 決済情報なし |
| 認証方式 | メール + パスワード + 2 要素 (管理者のみ) |
| 監査ログの保存期間 | 1 年 |
| 準拠が必要な規格・法令 | 個人情報保護法 / 特になし |
| 既存システム連携 | 会計 SaaS 1 本 / API 連携あり |
| 運用担当 | 社内情シス 2 名 (平日日中のみ) |
8. 契約形態 — 見積もりが何を保証しているか
契約形態は、その見積もりが何を保証しているかを決める土台です。
| 形態 | 責任の所在 | 見積もりの性質 |
|---|---|---|
| 請負 | 成果物の完成に責任を負う | リスク分が上乗せされる |
| 準委任 | 作業の遂行に責任を負う | 実際の稼働に応じた費用 |
| SES | 人員の提供 | 稼働時間に対する支払い |
請負は完成責任を開発会社が負うぶん、バッファが厚めに積まれます。準委任は柔軟に進められる反面、発注側が仕様の判断を担う必要があります。
判断の軸は 3 つです。
| 判断軸 | 請負が向く | 準委任が向く |
|---|---|---|
| 要件の確度 | 詳細まで固まっている | 探索段階・仮説検証中 |
| 変更の予測 | 変更は限定的 | 途中で方針が変わる可能性が高い |
| 発注側の内製度 | PM を外部に任せたい | 社内に PO / PM を置ける |
3 軸のうち 2 つ以上が同じ側に寄ったほうを選べば、大きく外しません。不確実性の高い初期フェーズは準委任、仕様が安定してから請負へ切り替える、という組み合わせも現実的です。
準委任を選ぶなら、発注側が持つ責任がある
準委任は「安く柔軟に頼める契約」ではありません。完成責任を開発会社が負わないぶん、その責任は発注側に移ります。
具体的には、スコープと優先度を決める人を社内に置くこと、進捗と品質を自分で見ること、稼働工数の精算前提を理解しておくことの 3 つです。ここを用意せずに準委任を選ぶと、「動いてはいるが完成しない」状態になります。
契約書で見積もりと突き合わせる条項
契約書と見積書は別々に読まれがちですが、次の 4 点は必ず突き合わせてください。
- 検収の基準 (何をもって完成とするか)
- 契約不適合責任の期間と範囲
- 変更が生じたときの手続きと費用の扱い
- 成果物の権利の帰属 (ソースコード・ドキュメント)
見積書に書かれた成果物と、契約書の納品物の定義がずれていることは実際に起きます。特にドキュメントとソースコードの扱いは、後の保守会社の選択肢を左右します。
9. 相見積 — 値切るためではなく妥当性を判断するため
相見積の目的は値引きではありません。1 社だけでは、その金額が高いのか安いのか判断する物差しがないからです。
| 社数 | 向いている場面 | 注意点 |
|---|---|---|
| 1 社 | 既に信頼関係があり判断できるとき | 相場との照合ができない |
| 2 社 | 予算感の当たりを付けたいとき | 中央値が取れず判断が難しい |
| 3〜4 社 | 発注先を本格的に選定するとき | 各社対応の工数を確保する |
| 5 社以上 | RFP 形式で公募するとき | 一次選考の仕組みが必要 |
現実的なレンジは 2〜4 社です。2 社だと片方が極端な場合に検知できません。3 社以上あれば金額と提案内容の分布が見えます。
揃えるべきこと
比較を成立させるには、各社に同じ情報を、同じ形式で渡す必要があります。口頭で説明する内容が会社ごとに違うと、そもそも比較になりません。渡す情報は第 10 章、書式は第 11 章で扱います。
窓口も 1 つに絞ってください。担当者ごとに違う補足が入ると、そこで条件が崩れます。
横並びで比較する
集まった見積書は、金額の列だけを並べても判断できません。次の形に置き換えると、差がどこから来ているかが見えます。
| 比較項目 | A 社 | B 社 | C 社 |
|---|---|---|---|
| 想定スコープ (機能数) | 20 機能 | 18 機能 | 25 機能 |
| 想定工数 (人月) | 12 人月 | 10 人月 | 15 人月 |
| 想定体制 (人数 × 役割) | PM1+Eng2 | PM1+Eng2 | PM1+Eng3 |
| 平均人月単価 | 100 万円 | 120 万円 | 90 万円 |
| テスト工数比率 | 20% | 25% | 10% |
| 諸経費比率 | 15% | 10% | 20% |
| 期間 | 6 か月 | 5 か月 | 7 か月 |
| 成果物にドキュメント含む | 含む | 含まない | 含む |
| 想定リスクバッファ | 15% | 明記なし | 20% |
この例で読み取れるのは、C 社が高いのは単価ではなく機能数の想定が多いから、B 社が安いのはテスト工数とドキュメントを削っているからという構造です。総額だけを見ていると、この違いは見えません。
比較軸として最低限そろえたいのは、機能スコープ・工数・単価・体制・成果物・スケジュール・保守条件の 7 つです。
避けるべきこと
- 他社の見積金額をそのまま伝えて値引きを迫る
- 発注する気がない会社から数合わせで取る
- 各社に違う条件を伝える
- 提案書の内容を、そのまま他社へ渡して見積もらせる
いずれも、その後の関係と提案の質を落とします。最後の 1 つは、提案が無償で行われている前提を壊す行為でもあります。
10. 依頼の準備 — 見積もりの質は依頼前に決まる
見積もりのブレは、多くの場合発注側の情報の曖昧さに起因します。準備を整えるだけでレンジが縮み、結果として金額も下がります。
発注前に決めておく 5 項目
- 解きたい業務課題 (機能ではなく課題で書く)
- 使う人と規模 (誰が何人、どのくらいの頻度で使うか)
- 予算のレンジ
- 希望する時期と、その理由
- 社内で誰が決裁するか
予算は伝えたほうが安くなります。 伝えないと、開発会社はリスクを見込んで高めに出すか、逆に受注のために薄く出して後から追加請求する構造になりやすいためです。
予算の伝え方
「言うと満額で出されるのでは」という懸念はよく聞きますが、実際に起きるのは逆です。予算が分からないと、開発会社は「最大限の要件」で見積もるしかありません。 結果として、必要のない機能まで積まれた金額が返ってきます。
伝え方には型があります。上限だけを言うのではなく、レンジと、その根拠になっている社内事情をあわせて伝えると、提案の質が変わります。
- 「500 万円前後、上限は 700 万円まで」のように幅で伝える
- 「今期の予算枠が 800 万円で、稟議は 1,000 万円から役員決裁になる」と背景を添える
- 「初期は 300 万円、次年度に追加で 500 万円を想定」と時間軸で分けて伝える
避けたいのは、実際の 3 分の 1 の金額を伝えて反応を見る形です。その予算では実現できない構成の提案しか返ってこず、比較の材料になりません。
社内調整を先に済ませる
見積もりを取る前に、社内で決めておくと後が早くなります。
決裁者が誰かを特定し、その人が求める資料の形式を先に確認してください。稟議に相見積が何社必要か、どの粒度の内訳が要るかは会社ごとに違います。これを後から知ると、開発会社に見積もりを出し直してもらうことになります。
あわせて、社内側の担当者と工数も押さえておきます。要件のヒアリング、レビュー、受け入れテストには発注側の時間が必要です。ここが確保されていないと、確認待ちで期間が延び、費用が増えます。
用意すると精度が上がる 3 つの資料
- 業務フロー図。現状の業務の流れと、システム化したい範囲を示します
- 画面遷移案。手書きで構いません。どんな画面が何枚必要かを示します
- 既存の資料。現在使っているエクセルや帳票の実物が有効です
特に業務フロー図と画面遷移案は効果が大きく、これがあるだけで各社の想定スコープが揃います。完璧である必要はありません。間違っていても構わないので、たたき台があることが重要です。
業務フロー図は記号 3 つで足りる
作図の作法を覚える必要はありません。次の 3 つで十分に伝わります。
| 記号 | 意味 | 使いどころ |
|---|---|---|
| 四角 (□) | 処理・作業 | 「申請する」「承認する」など |
| ひし形 (◇) | 分岐 | 「承認 OK？」「金額 10 万円以上？」 |
| 矢印 (→) | 流れの方向 | 処理から処理へつなぐ |
順番は、いまの業務 (As-Is) を先に描き、そのあとにあるべき姿 (To-Be) を描くのが確実です。理想像から描くと、現場で実際に起きている例外処理が抜け落ちます。粒度は「1 画面あたり 1〜3 ステップ」を目安にしてください。
画面リストは表で足りる
画面遷移案も、絵を描く前に一覧にするほうが早く進みます。勤怠システムなら次のような形です。
| 画面 ID | 画面名 | 主な操作 | 利用者 |
|---|---|---|---|
| S001 | ログイン | 認証 | 全員 |
| S002 | 打刻 | 出勤・退勤・休憩 | 従業員 |
| S003 | 勤怠一覧 | 自分の勤怠を月表示 | 従業員 |
| S004 | 勤怠修正申請 | 打刻漏れの修正申請 | 従業員 |
| S005 | 承認一覧 | 部下の申請を一覧 | 承認者 |
| S006 | 承認詳細 | 承認・差し戻し | 承認者 |
| S007 | 月次集計 | 部署別・個人別集計 | 管理者 |
| S008 | CSV 出力 | 経理システム連携 | 管理者 |
画面が 8 枚なのか 30 枚なのかが分かるだけで、工数の桁が決まります。この表 1 枚で、概算のレンジは目に見えて縮みます。
11. RFP と依頼メール — 複数社に同じ条件で依頼する
相見積を取るなら、RFP (提案依頼書) の形で条件を揃えるのが確実です。
似た略称が 3 つあるので、先に整理します。段階が違うだけで、どれか 1 つを選ぶものではありません。
| 略称 | 正式名称 | 目的 | 発注側が知りたいこと |
|---|---|---|---|
| RFI | Request For Information | 情報提供依頼 | どんな会社があるか、実績と体制 |
| RFP | Request For Proposal | 提案依頼 | どう実現するか、体制と概算費用 |
| RFQ | Request For Quotation | 見積依頼 | 確定した要件に対する正式見積 |
初めての領域で発注先の候補すら分からない段階なら RFI から、作るものが決まっていて金額だけ揃えたいなら RFQ から入ります。多くの案件は RFP が起点です。
RFP に盛り込む項目は次のとおりです。
- 背景と目的
- 現状の課題
- システム化の範囲 (やること・やらないこと)
- 機能要件
- 非機能要件 (第 7 章の 6 分類)
- 前提条件と制約
- 予算のレンジ
- スケジュール
- 提案してほしい内容と形式
- 選定の基準とスケジュール
「やらないこと」を明記するのが要点です。範囲の下限が示されていないと、各社が独自に想定して見積もりがばらつきます。
見積もりやすい RFP の 4 条件
受け取った側がすぐ積算に入れる RFP には、共通点があります。
- 前提と制約が最初に書かれている。既存システム、社内規定、使えない技術
- やらないことが書いてある。範囲の下限が決まる
- 優先度が 3 段階で示されている。必須・推奨・任意で分けると、予算に合わせた提案が返ってくる
- 意思決定者と締切が明記されている。誰がいつ決めるかが分かると、体制を押さえられる
3 番目が効きます。優先度が付いていない機能一覧は、全部必須として積算されます。 これだけで総額が数割変わります。
依頼メールなら 7 項目
RFP を作るほどではない規模なら、メールで足ります。書くべきは次の 7 項目です。
| 項目 | 書く内容 |
|---|---|
| 会社情報 | 会社名・部署・担当者・連絡先・事業内容の 1 行紹介 |
| 目的・背景 | 解決したい業務課題、想定利用者、期待する効果 |
| 対象スコープ | 種別、主要機能、対象環境 |
| 希望納期 | リリース希望日、動かせない締切 |
| 予算感 | 「100〜300 万円」のようにレンジで |
| 回答期限と回答方式 | いつまでに、どの形式で返してほしいか |
| 添付資料の一覧 | RFP、業務フロー図、画面遷移案、参考サービス |
添付する資料の分量にも目安があります。多ければよいというものではありません。
| 資料 | 目安分量 | 目的 |
|---|---|---|
| RFP | A4 で 5〜15 ページ | 目的・スコープ・要件・評価軸を提示 |
| 業務フロー図 | 1〜3 枚 | 現状業務と改善後の対比 |
| 画面遷移案 | 主要導線のみ 5〜10 画面 | 主要機能のイメージ共有 |
| 参考サービス一覧 | 3〜5 件 | 目指す世界観の擦り合わせ |
12. 交渉 — 金額ではなくスコープを動かす
見積もりの交渉で最も大事なのは、何を動かすかの選択です。
単純に「もう少し何とかなりませんか」で下がる金額は、経験上総額の 5〜10% が限界です。これは開発会社の利益を削る交渉なので、関係も悪くなります。
一方、スコープを動かせば 30〜50% 圧縮できるケースは珍しくありません。
効く打ち手
- 機能を削る / 後回しにする。初期リリースの機能を半分に絞ります
- デザインを標準化する。UI 工数は 2〜3 倍の差が出やすい領域です
- 対応範囲を絞る。両 OS 対応をやめるだけで工数が 30〜40% 下がります
- 期間を延ばす。繁忙期を避けられ、体制の組み方に余裕が生まれます
期間・単価・体制でも動かせる
スコープ以外にも、動かせる変数があります。効き方と副作用はそれぞれ違います。
期間で下げる。 開始時期に余裕を持たせると、繁忙期を避けた体制が組めます。急ぎの案件で乗る割増分がなくなるぶん、数%から 10% 程度動きます。
単価で下げる。 オフショアやパートナーを組み合わせる方法です。単価は下がりますが、仕様伝達の負荷が発注側に寄ります。浮いた金額の一部は、自社の管理工数として戻ってきます。
体制で下げる。 ドキュメントの量や進行管理の粒度を軽くする方法です。社内に技術が分かる人がいる場合に限って有効で、いない場合は引き継ぎで詰まります。
最も早い方法
実務上、予算を伝えて「この範囲で何ができるか」を設計してもらうのが最短です。金額を下げる交渉ではなく、予算に合う構成を一緒に作る話に切り替わるため、双方に無理がありません。
やってはいけない交渉
次の 4 つは、金額が下がっても失うものが大きくなります。
- 相見積の最安値だけを持ち出して、同額まで下げるよう求める
- 根拠を示さずに「もっと安くならないか」を繰り返す
- 本命が別にいることを隠したまま提案させる
- 極端に安い 1 社の金額を基準に、他社の妥当性を否定する
いずれも、次に困ったときに相談できる相手を減らす交渉です。開発は契約後のほうが長く、そこで融通が利くかどうかは関係の質で決まります。
13. 仕様変更と追加見積
開発が始まると、仕様変更や追加要望は必ず発生します。問題は変更そのものではなく、変更が見積もりにどう反映されるかが事前に決まっていないことです。
「小さな変更なのに高い」理由
画面 1 つの変更でも、影響範囲の調査、設計の修正、実装、テスト、既に通っていた箇所の再確認 (回帰テスト) が発生します。特に回帰テストの工数は見えにくく、「表示を変えるだけ」に見える変更が数十万円になるのはこのためです。
妥当性を確認する
変更見積を受け取ったら、次を確認してください。
- 影響範囲がどこまでと想定されているか
- 回帰テストの範囲
- その変更を後回しにした場合の費用差
3 つ目が重要です。まとめて後のフェーズで対応したほうが安い変更もあります。
変更の工数の目安
金額が妥当かどうかは、工数に割り戻すと判断しやすくなります。おおよその目安は次のとおりです。
| 変更の種類 | 目安工数 |
|---|---|
| 画面への項目 1〜2 個追加 (一覧・帳票への波及なし) | 0.5〜2 人日 |
| 画面への項目追加 (一覧・検索・帳票にも波及) | 3〜7 人日 |
| 既存機能の仕様分岐追加 (条件によって処理を変える) | 3〜10 人日 |
| 新規 1 画面の追加 (既存機能の延長線上) | 5〜15 人日 |
| 帳票・CSV・API の新規追加 | 5〜20 人日 |
同じ「項目を 1 つ足す」でも、一覧や帳票に波及するかどうかで数倍変わります。見積もりが高く感じたときは、どこまで波及すると想定されているかを聞いてください。 波及範囲の認識がずれているだけ、ということが実際にあります。
変更を安定させる
変更が頻発する案件では、変更管理のルールを契約時に決めておくのが有効です。何をもって変更とするか、いくらまでは追加費用なしで対応するか、判断は誰がするか。この 3 点が決まっていれば、都度の交渉が不要になります。
運用として効くのは次の 3 つです。
変更依頼書の書式を決める。 依頼の内容・理由・希望時期・優先度を毎回同じ形で書くようにすると、見積もりが返ってくるまでの往復が減ります。
優先度を決める場を用意する。 週次で 30 分の枠を取り、たまった依頼をまとめて判断します。都度判断より、まとめたほうが工数が下がります。
変更予算を別枠で確保する。 開発費の 10〜20% を変更用に確保しておくと、変更のたびに稟議をやり直す必要がなくなります。この枠がないことが、変更をめぐる摩擦の最大の原因です。
まとめ
システム開発の見積もりは、金額の大小ではなく前提条件を読む書類です。
- 見積もりは「工数 × 単価 + 諸経費」で決まる。単価より前提の差で総額が数倍動く
- 会社ごとに 3 倍開くのは吹っかけではなく、単価・スコープ想定・品質水準・積算方法の差
- 概算は ±30〜50%、本見積は ±10〜15%。概算をそのまま稟議に通さない
- バッファ 10〜30% は削るべきものではない。過小はむしろ危険信号
- 非機能要件の指定 1 つで工数が数十%変わる。過剰スペックを避ける
- 値引きで下がるのは 5〜10%。30〜50% 下げたいならスコープを動かす
- 見積もりの精度は、依頼前に渡す情報でほぼ決まる
今日から動かせる 3 つ
読んだあとに手を付けるなら、効果の大きい順に次の 3 つです。
- 画面リストを作る。8 枚なのか 30 枚なのかが決まるだけで、金額の桁が定まります
- 非機能要件のチェックリストを埋める。埋まらない欄が、見積もりのばらつきの原因です
- 予算をレンジで伝える。伝えないほうが高くなります
いずれも発注側だけで完結し、開発会社を待つ必要がありません。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、見積もりの前提を明示したうえでご提案しています。要件が固まりきっていない段階でも、業務課題と予算のレンジを共有いただければ、実現できる範囲を一緒に設計します。お問い合わせ からお気軽にご相談ください。
関連リソース
- AI 駆動開発の費用と期間: AI 駆動開発の費用・期間はいくら?料金相場と見積もりの内訳
- 発注先の見極め: AI 受託開発の会社を選ぶときの 5 つのチェックポイント
- 契約前の実務確認: AI 開発の発注前に確認する 10 項目
- 業務システムの発注先比較: 業務システム 受託開発の比較・選び方