システム開発の見積もり｜見積書サンプルで読む内訳と相場、妥当性チェックリスト

システム開発の見積もりは、受け取ってから困ることが多い書類です。金額が妥当なのか、なぜ会社によって 3 倍も開くのか、社内にどう説明すればよいのか。この記事は、発注担当者が見積書を自分で確かめ、根拠を添えて社内に説明できるようにするためのものです。

先に結論を 3 つ挙げます。

• 見積もりは「工数 × 単価 + 諸経費」で決まる。機能ごとの定価はない
• 妥当性は総額ではなく、前提条件と工程の抜けで判断する
• 公的な調査では、スクラッチ開発の外注コストの平均単価は 1 人月 96 万円 (JUAS「ソフトウェア・メトリクス調査 2025」)

見積書を既に受け取っている方は「2. 見積書サンプルで内訳を読む」と「3. 妥当性チェックリスト」から、これから依頼する方は「13. 依頼の準備と RFP」から読んでください。AI 駆動開発に絞った費用の内訳は AI 駆動開発の費用・期間の記事 で扱っています。

1. 見積もりの仕組み — 工数 × 単価 + 諸経費

システム開発の見積もりは、必要な作業量 (工数) に担当者の単価を掛け、そこへ諸経費を乗せるという構造で決まります。見積書の末尾には、一般管理費やプロジェクト管理費として工数費の 10〜20% 程度が乗るのが一般的です。この項目自体は不当なものではなく、進行管理や品質管理にかかる実費です。

人月・人日・人時

「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 時間

算出方法 5 種と、発注者から見た注意点

工数の出し方にはいくつかの方法があり、どれを使ったかで精度が変わります。見積書からは直接読み取れないので、気になる場合は「どの方法で出しましたか」と聞いてください。

算出方法	やり方	使われる場面	発注者から見た注意点
類推見積	過去の似た案件と比べて出す	初回相談での概算	比較した案件が自社と似ているかで大きく外れる
パラメトリック見積 (FP 法を含む)	機能の数や複雑さを点数にし、係数で工数へ換算する	大手 SIer・公共案件・稟議の根拠	係数の元データが自社の開発方法に合っているかを確認する
ボトムアップ見積	作業を細かく分解し、1 項目ずつ積み上げる	要件定義後の本見積	精度は高いが、分解の漏れがそのまま金額の漏れになる
三点見積	楽観・最頻・悲観の 3 つの値から期待値を出す	不確実性の高い作業	悲観値の置き方でバッファの厚さが決まる
プライスツーウィン	受注できそうな金額や予算から逆算して見積もりを合わせにいく	競争入札・予算が先に決まった案件	作業量の積算ではない。安さの根拠を聞いても答えが出てこないことがある

プライスツーウィンは算出方法というより、価格の決め方です。IPA が公開している講演資料 (三菱総合研究所「ソフトウェア開発見積りの基本的な考え方」、2012 年) は、見積りミスの原因の 1 つに「目標と見積りの混同」を挙げ、入札額と見積り額は本来違うものだと説明しています。予算に合わせて作られた見積もりは、作業量の裏付けがないまま契約金額になりやすい点に注意してください。

同じ資料は「ほとんどのコスト見積りは低すぎる傾向がある」(DeMarco-Glass の法則) とも紹介しています。見積もる人は、不要な作業を足すより、必要な作業を書き忘れることのほうが多いためです。見積もりを受け取ったら、高すぎるかどうかより先に、抜けている作業がないかを確かめるほうが実務では役に立ちます。

工程別に積み上げる計算例

発注者が見積書を逆算して読めるように、ボトムアップ見積の組み立てを 1 つ示します。受発注の管理システムで、機能一覧から設計〜結合テストの工数を積んだ結果が 6.0 人月になったとします。

1. 機能ごとに、設計・実装・単体テスト・結合テストの工数を積む。合計 6.0 人月
2. 要件定義と総合テスト以降 (総合テスト・移行) を工程比率から出す。JUAS の調査の工数比 (要件定義 15 : 設計〜結合テスト 60 : 総合テスト 25) を当てると、全体は 6.0 ÷ 0.60 = 10.0 人月
3. 要件定義は 10.0 × 0.15 = 1.5 人月、総合テスト以降は 10.0 × 0.25 = 2.5 人月
4. 工程ごとに担当者の単価を掛け、管理費を乗せる

この 10.0 人月を工程別の明細にしたものが、次の章の見積書サンプルです。工程比率は JUAS「ソフトウェア・メトリクス調査 2025」 の図表 2-2-12 の値で、211 件の実績を 5 刻みに丸めたものです (丸める前は 13 : 61 : 26)。JUAS の総合テストにデータ移行は含まれませんが、この計算例では説明を簡単にするため、総合テストと移行をあわせた分をこの比率に当てています。調査の対象は大規模な案件が多いため、自社の案件にそのまま当てはまるとは限りません。要件定義と総合テストの行が、少なくとも立っているかを確かめる目安として使ってください。

2. 見積書サンプルで内訳を読む

見積書で最初に見るべきは総額ではありません。その金額がどう組み立てられているかです。

見積書サンプル (架空)

かがみ (表紙) には、次の内容が並びます。

欄	記載例	ここを見る
宛先	株式会社サンプル 御中	宛先と担当部署が合っているか
件名	受発注管理システム 開発	件名が自社の呼び方・依頼の範囲と一致するか
見積総額	1,089 万円 (税抜)	税抜か税込か、別途費用が含まれているか
有効期限	発行日から 3 ヶ月	稟議にかかる期間より短くないか
支払条件	着手時 30%・検収後 70%	検収前に支払う比率と、検収の条件
前提条件	別紙のとおり	別紙が実際に付いているか、空欄になっていないか

明細は工程ごとに分かれています。

工程	工数	単価	金額	ここを見る
要件定義	1.5 人月	120 万円	180 万円	成果物 (要件定義書など) が明記されているか
基本設計	1.5 人月	110 万円	165 万円	画面数・帳票数など、設計の対象が数で示されているか
UI デザイン	0.5 人月	100 万円	50 万円	何画面をデザインするのか
実装・単体テスト	3.0 人月	90 万円	270 万円	機能一覧と対応しているか
結合テスト	1.0 人月	90 万円	90 万円	外部サービスとの連携の確認が含まれているか
総合テスト・受入支援	1.5 人月	90 万円	135 万円	発注側の受入テストをどこまで支援するか
データ移行・導入支援	1.0 人月	100 万円	100 万円	移行するデータの件数と回数、操作説明の範囲
工数費 小計	10.0 人月	—	990 万円	工数費の小計を人月で割ると 1 人月あたり 99 万円
プロジェクト管理費	工数費の 10%	—	99 万円	管理費の率と、PM の稼働が別に計上されていないか
合計 (税抜)	—	—	1,089 万円	—
別途 (見積外)	—	—	実費	サーバー・SaaS・ライセンスの費用と、月額の運用費

前提条件の別紙には、たとえば次のような内容が書かれます。

• 利用者は社内 50 名、同時利用は 20 名程度を想定
• 対応ブラウザは Chrome・Edge の最新版。スマートフォン表示は対象外
• データ移行は既存の CSV からの取り込みを 1 回
• 画面の文言・ロゴなどの素材は発注側が用意する
• 仕様の確認への回答は 3 営業日以内を想定
• 会計システムとの API 連携は対象外 (別途見積)

このサンプルで読み取れることは 3 つあります。1 つ目は、工数費の小計を人月で割った平均単価 (99 万円) が、4 章で紹介する JUAS の加重平均単価 (96 万円) に近いことです。管理費を含めた総額で割ると約 109 万円で、JUAS の 10〜50 人月未満の区分 (95 万円) より 1 割ほど高くなります。2 つ目は、要件定義 (1.5 人月) と総合テスト以降 (2.5 人月) がきちんと行として立っていることです。3 つ目は、サーバー費や API 連携のように「見積外」になっているものが明示されていることです。受け取った見積書で、この 3 つのどれかが読み取れない場合は、そこを聞き返してください。

見積書の欄のうち最も重要なのは「前提条件」です。金額は前提条件の上に成り立っているため、ここを読まずに総額だけ比較しても意味がありません。

総額を検算する

工程別ではなく役割別に書かれた見積書でも、掛け算で妥当性を確かめられます。約 600 万円の Web システムの見積もりで、期間が 6 ヶ月と書かれていれば、次のような形に分解できるはずです。

項目	工数	単価	小計
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 人あたりの稼働が薄い、といった形で出ます。

要件定義の比率の目安は 6 章で扱います。AI 駆動開発では費用の 15〜25% に上がるのが正常なので、要件定義が費用の 30% を超えたときに「なぜそこまでかかるのか」を聞いてください。

過少のサインは逆で、テスト工数が実装の 10% 程度しかない、要件定義や設計の行がない、移行と運用引き渡しの記載がない、といった形です。過少のほうが危険です。抜けている工程は消えたのではなく、後から追加費用として現れます。

3. 妥当性チェックリスト — 受け取った見積書で確かめる 15 項目

見積書を受け取ったら、次の 15 項目を上から順に確かめてください。「書かれていない」項目があれば、それが聞き返すべき箇所です。

群	確認項目	書かれていないときのリスク
範囲・前提	1. 想定する利用者数・データ量	規模の想定が各社でずれ、比較できない
範囲・前提	2. 対応するブラウザ・OS・端末の範囲	後から対応環境を足すと追加費用になる
範囲・前提	3. 発注側が用意するもの (素材・アカウント・環境)	用意が遅れた分の待ちが工数に跳ね返る
範囲・前提	4. 対象外 (やらないこと)	双方の想定する範囲の下限が決まらない
工程と工数	5. 工程ごとの工数と単価 (「一式」が多くないか)	どこが厚く、どこが抜けているかが見えない
工程と工数	6. 要件定義・設計の行	要件が曖昧なまま実装に入る
工程と工数	7. テスト工程の厚み	リリース後の不具合対応が追加費用になる
工程と工数	8. 既存システムや外部 API の調査・分析の工数	着手後の調査が「想定外」として追加される
工程と工数	9. データ移行・運用引き渡し・ドキュメント	本番化の直前に別見積が出てくる
お金の条件	10. サーバー・SaaS・ライセンスの購入費と月額	開発費とは別に、毎月の費用が発生する
お金の条件	11. 予備費・バッファの有無と率	追加請求が前提になっている可能性がある
お金の条件	12. 有効期限と支払条件	稟議中に期限が切れる、検収前の支払が重くなる
契約と責任	13. 検収の方法と条件 (何をもって完成とするか)	完成の判断で揉め、支払と保守の開始が遅れる
契約と責任	14. 仕様変更の手続きと単価	変更のたびに金額の交渉が発生する
契約と責任	15. 契約不適合責任の期間と、成果物の権利の帰属	不具合の無償対応や、保守会社の選択肢が狭まる

3 番目の「発注側が用意するもの」には、確認への回答にかかる日数も含めて考えてください。「1 営業日で返す」前提で組まれた見積もりに対して、実際は稟議や役員確認で 1 週間かかる場合、その待ち時間は工数として跳ね返ります。

聞き返し方

内訳が足りない見積書は、項目を指定して出し直してもらいます。「役割別の人月と単価、工程ごとの工数を分けて記載してほしい」「前提条件として想定している利用者数と対応環境を書き足してほしい」「見積外の費用を一覧にしてほしい」と具体的に頼むと、各社の答えが揃います。これを断られる場合は、そもそも積算していない可能性があります。

チェックリストを埋めても判断がつかない場合は、第三者に見てもらうのも手です。FIXIT では、他社から受け取った見積書を無料で診断し、工程の抜けや追加費用の条件、見積書を出した会社へ確認すべき質問をお返ししています。社名や案件名は伏せたままで構いません。詳しくは 見積書の無料診断 をご覧ください。

4. 相場 — 公的調査と種類別・規模別の目安

相場は値切るための材料ではなく、桁違いの見積もりに気づくための物差しです。ここでは公的な調査の実績値と、種類別・規模別の目安を並べます。

公的調査で見る平均費用と人月単価 (JUAS 2025)

日本情報システム・ユーザー協会 (JUAS) の 「ソフトウェア・メトリクス調査 2025」 は、ユーザー企業が回答したシステム開発の実績を集計しています。スクラッチ開発で外注コストが記載された 99 件の、工数の区分別の値は次のとおりです (図表 2-9-1)。

工数の区分	件数	外注コストの平均	工数の平均	加重平均単価
10 人月未満	6 件	850 万円	5 人月	185 万円
10〜50 人月未満	23 件	2,951 万円	31 人月	95 万円
50〜100 人月未満	22 件	7,570 万円	70 人月	109 万円
100〜500 人月未満	36 件	1 億 9,381 万円	205 人月	95 万円
500 人月以上	12 件	14 億 6,901 万円	1,542 人月	95 万円
全体	99 件	2 億 7,273 万円	284 人月	96 万円

同じ調査では、パッケージ利用開発と SaaS 利用開発の加重平均単価はいずれも 144 万円で、スクラッチ開発より高くなっています (図表 2-9-2・2-9-3)。パッケージや SaaS を扱う知識を持つ技術者が必要なためと考察されています。また、工数と総費用の関係を回帰分析した結果からは、分析対象のデータに対する人月単価は 127 万円が妥当としています (図表 2-8-1、パッケージ利用も含む 195 件)。

役割別の人月単価

単価は担当者の役割と経験で変わります。同じ「Web システム開発」でも担当者の構成次第で総額が変わり、その差は目安で 1.5〜2 倍ほどになります。

役割	人月単価の目安 (税抜)
ジュニアエンジニア (実務 2〜3 年)	60 万〜80 万円
中堅エンジニア (実務 3〜7 年)	80 万〜120 万円
シニア / テックリード	120 万〜180 万円
PM / PL	100 万〜160 万円
UI / UX デザイナー	80 万〜130 万円
オフショア (東南アジア)	30 万〜60 万円

この表は役割ごとの目安です。JUAS のスクラッチ開発の加重平均単価 96 万円は、中堅エンジニアの帯に入ります。見積書の平均単価がこの帯から大きく外れている場合は、体制の構成 (シニアや PM の比率、オフショアの有無) を聞くと理由が分かります。

種類別の費用相場

対象によって、同じ規模でも金額帯が変わります。種類ごとの詳しい内訳は、右の列の記事で扱っています。

開発の種類	小規模	中規模	大規模	詳しい記事
Web システム (業務効率化・SaaS)	300 万〜800 万円	800 万〜2,500 万円	2,500 万円以上	Web システム開発の費用と期間の相場
スマホアプリ (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 万円以上	EC サイト構築の見積相場
AI・機械学習システム	800 万〜2,000 万円	2,000 万〜5,000 万円	5,000 万円以上	AI・機械学習開発の見積相場

いずれも税抜の目安です。この表は「自社の案件がどの帯にいるか」を確かめるためのもので、個別の金額を当てるものではありません。

規模別の目安

種類ではなく工数で見ると、社内の予算組みに使いやすくなります。この表は工数で区切ったもので、上の種類別の表の小規模・中規模・大規模とは区切りが一致しません。また、工数を積み上げる従来の見積もりの目安なので、8 章の AI 駆動開発の事例 (期間と費用で示しています) はこの表の帯には当てはまりません。

工数	費用の目安	画面数の目安	期間
〜3 人月	〜300 万円	5〜10 画面	1〜3 ヶ月
3〜20 人月	300 万〜2,000 万円	20〜60 画面	3〜9 ヶ月
20 人月以上	2,000 万円以上	複数チーム編成	9 ヶ月〜数年

工数の帯によって、費用の中身の比率が変わることがあります。工数の小さい案件では、実装よりも確認の往復にかかるコストの比率が上がりやすく、大きい案件では、PMO・品質保証・受入テスト・移行支援といった開発以外の工程の比率が上がりやすくなります。

自社の条件でおおよその金額を出してみたい場合は、システム開発の費用シミュレーター を使ってください。作りたいものや機能の数など 7 つの質問に答えると、費用の概算 (税抜) と期間の目安、工程ごとの内訳、金額が上がる理由がその場で出ます。登録は要りません。

5. なぜ会社によって数倍違うのか — 高い・安いの見分け方

同じ要件で相見積を取っても、A 社は 300 万円、B 社は 900 万円、C 社は 1,500 万円、と 3 倍以上開くことがあります。どこかが吹っかけていると考えたくなりますが、各社の前提が違えば、どの金額もその前提のもとでは正しいことがあります。

差が生まれる 4 つの要因

1 つ目は単価の差です。自社の正社員だけで組む会社、協力会社を使う会社、オフショアを組み合わせる会社では、同じ工数でも金額が変わります。

2 つ目は想定スコープの差です。「同じ要件」を渡しても、各社が想定する作業範囲は揃いません。「会員登録機能」と書いてあるだけでは、メール認証の有無、退会処理、管理画面での会員管理まで含むかどうかが会社ごとに異なります。

3 つ目は品質水準の差です。自動テストを厚く書く会社と、手動テストで最低限を確認する会社では、テスト工数が大きく違います。JUAS の調査では、総合テストだけで開発工数の約 26% を占めています。テストの前提差は、そのまま総額に表れます。

4 つ目は積算方法の差です。類推でざっくり出す会社と、作業を分解して 1 項目ずつ積む会社では、同じ機能でも金額が変わります。

開発会社のタイプによる傾向

会社のタイプが違えば、得意な規模帯も違います。得意な規模帯から外れた案件では、見積もりが高く出やすくなります。タイプごとの規模や案件レンジは 業務システム 受託開発の比較 で整理しています。

タイプによる金額差の実体は、契約する会社と、実装する人が同じかどうかにあります。大手 SIer では、契約主体が要件定義と全体管理を担い、実装は協力会社が入ることが一般的です。品質管理の層が厚いぶん間接費が乗り、単価は高くなります。独立系や Web 系の会社では、提案した担当者がそのまま実装に入ることが多く、間接費が薄いぶん単価は下がりますが、体制の冗長性は落ちます。確認すべきは、提案の場にいる人が実装するのかどうかです。

金額を左右する 5 要因

次の金額インパクトは一般的な目安です。

要因	金額インパクトの目安	コントロール主体
要件の明確さ	±20〜30%	発注側
非機能要件	+20〜100%	発注側 (規制で不可避もあり)
デザインの作り込み度	±30〜80%	発注側
既存システムとの連携数	+10〜50%	発注側と開発側で半々
発注側の意思決定スピード	±10〜20%	発注側

5 つのうち 4 つは発注側が動かせます。非機能要件には規制で下げられない部分が残るため (10 章で扱います)、まず手を付けるなら要件の書き方、デザインの標準化、決裁ルートの整備の 3 つです。

コストを下げるなら、作るものを減らす削減を選んでください。初期リリースの機能を絞る、デザインを標準コンポーネントに寄せる、対応環境を絞る、の 3 つです。いずれも総額が下がり、品質は落ちません。逆に、テストを削る、ドキュメントを省く、レビューを飛ばすといった作り方を薄くする削減では、目先の金額は下がりますが、削った分の費用はリリース後の改修と引き継ぎで結局支払うことになります。

安すぎる見積もりの構造

複数社から見積もりを取ったとき、1 社だけ他社の半分以下を提示してくることがあります。安さ自体は問題ではありませんが、その理由が説明できるかを確認してください。

危険なのは、3 章のチェックリストの 7〜9 番 (テスト、既存システムの調査、データ移行・運用引き渡し・ドキュメント) や、非機能要件への対応が抜けているケースです。これらが抜けたまま契約すると、抜けた工程が後から追加費用として現れ、初期見積もりを大きく上回ることがあります。IPA が公開している前述の資料も、当初の想定機能は工程が進むにつれて膨張すると説明し、数値例として、1 ヶ月に 2% 増加するという値 (Capers Jones) を挙げています。

年間保守費が開発費の 30% を超えるような提示になっている場合も、初期の安さを保守で回収する設計になっている可能性があります。一般的な保守費の目安は年間で開発費の 15〜20% ですが、これは軽微な改修や追加開発まで含めた数字です。JUAS「ソフトウェアメトリックス調査 2020」 では、稼働後 5 年間の年平均で保守費が開発費の 7.8%、追加開発費が 12.0% でした。

「なぜ安いのか」は直接聞いて構いません。似た案件のテンプレートを持っている、社内に同じ構成の実績がある、オフショアを組み合わせている、といった具体的な答えが返ってくれば問題ありません。「頑張ります」のような答えしか返ってこない場合は、積算していない可能性があります。

安さを許容できる案件、できない案件

判断の分かれ目は、失敗したときに作り直せるかどうかです。

許容できるのは、社内利用に限る小規模ツール、検証目的の PoC、使い捨て前提のキャンペーンサイトなど、止まっても事業が痛まないものです。許容してはいけないのは、売上が直接乗るシステム、個人情報や決済を扱うもの、基幹業務に接続するもの、長期の保守が前提のものです。ここで安さを取ると、作り直しのコストが初期見積もりを大きく超えます。

6. 要件定義の費用 — 見積もりの前に払う費用

開発会社に見積もりを頼むと、「まず要件定義を別の契約で」と言われることがあります。

FIXIT

見積もりを頼んだら「まず要件定義を別契約で」って言われた。これって普通なの？

Shiori

普通です。作るものが決まる前に総額を約束すると、どちらかが大きな損をかぶるからです。

FIXIT

じゃあ要件定義にお金を払ったら、その会社に開発まで頼まないといけないの？

Shiori

いいえ。要件定義書を受け取って使える契約なら、それをもとに他社にも見積もりを頼めます。

要件定義は開発全体の何% か

JUAS「ソフトウェア・メトリクス調査 2025」 の工程別の比率 (図表 2-2-12、211 件) は次のとおりです。

工程	工数の比率	工期の比率
要件定義	13% (15%)	20% (20%)
設計〜結合テスト	61% (60%)	53% (50%)
総合テスト	26% (25%)	28% (30%)

かっこ内は調査が 5 刻みに丸めた値です。要件定義は工数の割に期間が長くかかります。要件定義は作業を分担して進めることに向かないため、と調査は考察しています。

AI 駆動開発では、実装が速くなる分だけ要件定義の比率が上がり、費用の 15〜25% を配分するのが目安です。詳しい配分は AI 駆動開発の費用・期間の記事 で扱っています。

金額の目安

開発全体の総額に比率を掛けると、要件定義の金額の目安が出ます。

開発の総額	JUAS の工数比 (約 13%、丸めて 15%) で計算	AI 駆動開発の配分 (15〜25%) で計算
500 万円	65 万〜75 万円	75 万〜125 万円
1,000 万円	130 万〜150 万円	150 万〜250 万円
2,000 万円	260 万〜300 万円	300 万〜500 万円

これは独自の相場ではなく、総額 × 比率の計算結果です (税抜)。要件定義は PM や経験の長いエンジニアが担うことが多く、単価が高い分だけ、費用の比率は工数の比率より上がることがあります。

要件定義と見積もりはどちらが先か

順番は、概算見積 → 要件定義 → 本見積です。概算で予算の桁を確かめ、要件定義を別に契約し、できあがった要件定義書をもとに開発の本見積を受けます。

IPA の 「情報システム・モデル取引・契約書 (第二版)」 も、見積もりを段階ごとに出し直す考え方を採っています。要件定義書をもとに RFP を出して見積もりを受け、工程ごとに個別契約を結び (多段階契約)、要件が明確になった段階で見積りなおす (再見積り) 形です。なお、モデル契約では要件定義書をもとにした見積もりも「概算見積」と呼んでいます。本記事の「本見積」にあたる金額も、外部設計でさらに見直されることがあります。

なぜ準委任で切り出すのか

同じモデル契約は、要件定義を契約書のなかで独立した段階とし、契約類型を準委任型としています。要件定義のフェーズは、発注側にとってもフェーズの開始時点では成果物を具体的に想定できないため、仕事の完成を目的とする請負には馴染みにくく、準委任が適切という説明です。

工程ごとに契約を分けるので、要件定義と開発を別の会社に頼むこともできます。モデル契約も、多段階契約にすると工程ごとに異なるベンダに分割発注することも可能になると書いています。ただし、前の工程の成果物を後の会社が読み込むためのレビュー期間は見込んでおいてください。

途中でやめたらどうなるか

要件定義を途中で打ち切る場合の精算は、準委任の報酬の決め方で変わります。作業に対して報酬を払う形なら、終了までに行った作業の割合に応じて精算するのが民法の原則です (第 648 条第 3 項)。成果に対して報酬を払う形 (民法第 648 条の 2) の場合、中途で終了したときの報酬請求権は請負に準じて扱われると、モデル契約が解説しています。契約書でどちらの形かを確認しておいてください。

要件定義の費用が高いと感じたときは、発注側で業務の流れと画面リストを用意すると、ヒアリングと整理にかかる工数が下がります。用意の仕方は 13 章で扱います。

7. 概算見積と本見積 — 段階ごとに精度が上がる

初期相談で受け取った「概算 300 万円」と、後日出てきた「本見積 380 万円」。この 2 つは矛盾していません。そもそも精度が違う書類だからです。

種類	出てくる時点	精度	用途
概算見積	相談〜初回ヒアリング後	±30〜50%	予算感の確認、社内の企画通し
本見積	要件定義完了後	±10〜15%	契約金額の根拠、正式な稟議
確定見積	契約締結時・着手直前	±5% 以内	実際の契約金額

ヒアリングより前、システム化の方向性しか決まっていない段階では、ぶれはさらに大きくなります。IPA が公開している前述の講演資料は、B. Boehm (1984) の図を引いて、最初期の規模見積りのぶれ幅を 1/4〜4 倍とし、要件定義・設計・製作と進むにつれて収束すると示しています。概算が単一の数字で示されていても、実際には幅を内包していると考えるのが妥当です。本来は「300 万〜500 万円」のように幅で提示されるべきものです。

本見積も確定ではありません。6 章で触れたとおり、外部設計の段階で見直されることがあり、表で契約時の確定見積を別の行にしているのはこのためです。

概算の金額で稟議を通さない

最も危険なのは、概算の数字をそのまま稟議に通してしまうことです。要件が固まった段階で本見積が上振れし、稟議のやり直しに追い込まれます。

対策は 2 つあります。

• 稟議の上限を、概算の中央値ではなく上限値に 10〜15% を足した額で通しておく
• 初期ヒアリングの時点で情報を厚く渡し、概算の幅そのものを絞る

何を渡すべきかは 13 章で扱います。

概算と本見積の差は、どこまで許容してよいか

要件定義を挟めば金額は変わります。問題は、その変わり方が説明できるかどうかです。

概算から本見積への上振れが ±30% の範囲なら、要件定義で解像度が上がった結果として自然です。50% を超える上振れが出た場合は、概算の前提と本見積の前提を並べて、どの機能がどれだけ増えたのかを確認してください。

このとき見るのは金額差ではなく、機能の数と非機能要件の水準がどう変わったかです。概算時点で聞かれていなかった要件が本見積で足されているなら、それは正当な増加です。一方、同じ機能一覧のまま金額だけ上がっているなら、概算が営業的に低く出されていた可能性があります。

8. AI 駆動開発で見積書の形はどう変わるか

AI 駆動開発を掲げる会社の見積もりは、工程の配分が従来と違います。安いか高いかより先に、配分の違いを知っておくと読み違えません。

工程配分が変わる

AI 駆動開発の標準的な費用配分は、次のようになります (AI 駆動開発の費用・期間の記事 の配分)。

工程	費用配分の目安
要件定義	15〜25%
設計	10〜15%
実装	25〜35%
テスト / 品質保証	15〜25%
運用設計・移行	10〜20%

実装の比率が下がり、要件定義とテストの比率が上がります。実装が速くなる分、AI に正しく作らせるための要件定義と、AI が書いたコードを信頼するための品質保証に重みが移るためです。2 章で、要件定義が費用の 30% を超えるまでは過大と見なさないとしたのは、この配分があるからです。

公開済みの実績で見る期間と費用

FIXIT が公開している事例の期間と費用は次のとおりです。

事例	AI 駆動開発での期間	費用の目安 (税抜)
SaaS の MVP	3 週間	400 万〜600 万円
AI エージェントによる一次対応の自動化	6 週間	800 万〜1,200 万円
基幹システムの刷新	4 ヶ月	1,800 万〜2,400 万円

SaaS の MVP は通常の見積もりで 2.5 ヶ月相当、基幹システムの刷新は 8 ヶ月相当の案件でした。費用はいずれも本案件相当の目安で、事例ごとの詳細は 事例ごとの費用と期間 にまとめています。

ただし、期間が半分になっても費用は半分にはなりません。要件を決める判断、レビュー、引き継ぎは人の仕事として残るためです。

AI 駆動開発を謳う見積もりで確かめること

• 要件定義とテストが十分に計上されているか。実装の比率だけが大きく、要件定義や品質保証がほとんど計上されていない場合は、AI を使いこなせていないか、後工程の手当てが抜けている可能性がある
• AI が書いたコードのレビューと、引き継ぎのための文書化が工程に入っているか
• AI ツールの利用について、機密情報の扱いや成果物の権利が契約で決まっているか

AI・機械学習のシステムそのものを作る場合の見積もりは、学習データの準備や精度の検証といった別の工程が入ります。AI・機械学習開発の見積相場 を参照してください。

FIXIT の見積もりでは、工程ごとの内訳と、どこで金額が増えうるかを先にお伝えしています。発注を決めきれない理由は、金額の高さより根拠が見えないことにあると考えているためです。

9. バッファと予備費 — 「その他」の中身

見積もりの末尾にある「予備費」「バッファ」「その他」は、工数費の 10〜20% を占めることもあり、削れないかと気になる項目です。まず、呼び方によって中身が違います。

呼び方	主な意味	使いどころ
予備費	見積時点で想定していない事象への備え	想定外の要件追加・追加調査
バッファ	各タスクの工数に乗せる余裕分	実装・テストの遅延吸収
コンティンジェンシー	特定リスクが顕在化した場合の備え	新技術検証・API 仕様変更対応
その他	上記に分類しにくい小額費目	打合せ交通費・軽微な調査費
一般管理費	会社運営のための間接費	オフィス費・バックオフィス費

一般管理費は会社の固定費で、案件ごとに動かせる性質のものではありません。動かせるのは予備費とコンティンジェンシーで、不確実性が減れば下がります。バッファがない見積もりは、原価ぎりぎりで組んでいるか、後の追加請求を前提にしているかのどちらかなので、削るべきものではありません。

妥当なバッファ率

案件タイプ	バッファ率	理由
要件が固まった小規模改修	5〜10%	影響範囲が読み切れる
要件定義済みの新規開発	10〜15%	一般的な Web システム
RFP ベースの中〜大規模開発	15〜20%	前提未確定の項目が残る
新技術・PoC 要素あり	20〜30%	AI・データ基盤・新規プロトコル
リプレイス案件	20〜30%	既存仕様の掘り起こしコスト
アジャイル・準委任	明示分は薄い	変動は精算で吸収する前提

小規模改修を除き、10% 未満は過小、30% 超は過大のサインです。前者は追加請求のリスク、後者は情報不足で会社側がリスクを高く見積もっている可能性を示します。

バッファは「削ってください」では下がりません。バッファの正体は不確実性なので、不確実性を減らせば下がります。打ち手は 4 つあります。

1. 情報を足す。読めていない部分を聞き出し、その資料を渡す
2. 段階契約に分ける。要件定義だけ先に契約し、確度が上がってから本体を見積もり直す
3. 凍結する範囲を宣言する。「この画面群は着手後に変更しない」と先に約束する
4. 追加請求のルールを合意する。何が追加対象か決まっていれば、備えを厚くする必要が減る

10. 非機能要件 — 指定 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 倍に耐える設計で見積もられます。一方で、後から追加すると作り直しになる領域なので、「決めない」のではなく「現実的な水準を早い段階で決める」のが正解です。

水準を決めるための 3 つの問い

過剰か適正かは、次の 3 つに答えれば絞れます。いずれも技術の話ではなく、事業の話です。

1. 止まったとき、事業にいくら損失が出るか。1 時間止まって数万円なら、冗長化に数百万円は釣り合いません
2. ピーク時の同時利用者は本当に何人か。登録者数ではなく、同時に操作する人数で答えます
3. 扱うデータが漏れたとき、影響はどこまで及ぶか。決済情報や医療情報があるなら、セキュリティは削る対象になりません

発注前に埋めるチェックリスト

次の 13 項目を埋めて渡すと、各社の前提が揃います。埋まらない欄があること自体が発見です。その欄が、見積もりのばらつきを生んでいる箇所です。

項目	記入例
想定同時利用者数 (通常時 / ピーク時)	通常 50 / ピーク 200
応答時間の目安	一覧表示 3 秒以内、検索 5 秒以内
稼働時間帯	平日 8:00〜22:00、土日は縮退運用可
許容停止時間 (月あたり)	60 分以内
バックアップ頻度と保持期間	日次 / 30 日
障害復旧目標時間 (RTO)	4 時間以内
障害復旧目標地点 (RPO)	24 時間以内のデータ喪失は許容
取り扱うデータの機密度	顧客の連絡先 / 決済情報なし
認証方式	メール + パスワード + 2 要素 (管理者のみ)
監査ログの保存期間	1 年
準拠が必要な規格・法令	法令: 個人情報保護法、業界規格: なし
既存システム連携	会計 SaaS 1 本 / API 連携あり
運用担当	社内情シス 2 名 (平日日中のみ)

11. 契約形態 — 見積もりが何を保証しているか

契約形態は、その見積もりが何を保証しているかを決める土台です。要件定義を準委任で切り出す理由は 6 章で扱いました。ここでは開発工程の契約を選ぶ軸を扱います。

形態	責任の所在	見積もりの性質
請負	成果物の完成に責任を負う	リスク分が上乗せされる
準委任	作業の遂行に責任を負う	実際の稼働に応じた費用
SES (準委任の一形態)	人員の提供	稼働時間に対する支払い

請負は完成責任を開発会社が負うぶん、バッファが厚めに積まれます。準委任は柔軟に進められる反面、発注側が仕様の判断を担う必要があります。

判断軸	請負が向く	準委任が向く
要件の確度	詳細まで固まっている	探索段階・仮説検証中
変更の予測	変更は限定的	途中で方針が変わる可能性が高い
発注側の内製度	PM を外部に任せたい	社内に PO / PM を置ける

3 軸のうち 2 つ以上が同じ側に寄ったほうを選べば、大きく外しません。

準委任は「安く柔軟に頼める契約」ではありません。完成責任を開発会社が負わないぶん、その責任は発注側に移ります。発注側には、スコープと優先度を決める人を社内に置くこと、進捗と品質を自分で見ること、稼働工数の精算を理解しておくことが必要です。ここを用意せずに準委任を選ぶと、作業は進んでいるのに完成しない状態になります。

契約書で見積もりと突き合わせる条項

契約書と見積書は別々に読まれがちですが、次の 4 点は必ず突き合わせてください。

• 検収の基準 (何をもって完成とするか)
• 契約不適合責任の期間と範囲
• 変更が生じたときの手続きと費用の扱い
• 成果物の権利の帰属 (ソースコード・ドキュメント)

見積書に書かれた成果物と、契約書の納品物の定義がずれていることがあります。特にドキュメントとソースコードの扱いは、後の保守会社の選択肢を左右します。

検収の基準と、検収の前に発注者が行う受入テストの進め方は、受入テストは誰がやる？発注者と開発会社の役割分担 で詳しく解説しています。

12. 相見積 — 同じ条件で比べる

相見積の目的は値引きではありません。1 社だけでは、その金額が高いのか安いのか判断する物差しがないからです。

社数	向いている場面	注意点
1 社	既に信頼関係があり判断できるとき	相場との照合ができない
2 社	予算感の当たりを付けたいとき	中央値が取れず判断が難しい
3〜4 社	発注先を本格的に選定するとき	各社対応の工数を確保する
5 社以上	RFP 形式で公募するとき	一次選考の仕組みが必要

現実的なのは 3〜4 社です。2 社だと片方が極端な場合に検知できません。3 社以上あれば金額と提案内容の分布が見えます。

比較を成立させるには、各社に同じ情報を同じ形式で渡し、窓口を 1 つに絞る必要があります。担当者ごとに違う補足が入ると、各社の前提が揃わなくなります。渡す情報と書式は 13 章で扱います。

横並びで比較する

集まった見積書は、金額の列だけを並べても判断できません。次の形に置き換えると、差がどこから来ているかが見えます。

比較項目	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%
総額 (工数 × 単価 + 諸経費)	約 1,380 万円	約 1,320 万円	約 1,620 万円

架空の例です。総額は「工数 × 単価」に諸経費を足した額です。

この例で読み取れるのは、C 社の総額が高いのは単価ではなく、機能数の想定が多いぶん工数が膨らみ、諸経費比率も高いから、B 社が安いのはドキュメントを含まずバッファも明記していないから、という構造です。機能 1 つあたりに直すと C 社が最も安くなりますが、テスト工数の比率は 3 社で最も低く、その安さはテストを薄く見積もった結果かもしれません。総額だけを見ていると、この違いは見えません。

ただし、この表で比べられるのは見積書に書かれた数字だけです。見積もりに何が入っていて何が入っていないか、どの条件で金額が増えるかは、次のひな形に書き写して比べます。

見積比較表のひな形 — 6 つのブロックで条件を書き写す

数字の表とは別に、条件を並べる表を 1 枚作ります。3 章のチェックリストが 1 社の見積書を確かめるためのものなら、このひな形は各社の答えを同じ行に並べるためのものです。行は工程・前提条件・追加費用の条件・保守費用・体制・契約と成果物の 6 つのブロックに分けます。

次の表は行の一覧と、各行に書き写す内容です。スプレッドシートでは「比較項目」を行に、各社と「確認したいこと」を列に置きます。

ブロック	比較項目	書き写す内容
工程	要件定義・設計	含む / 含まない / 記載なし と、その金額
工程	デザイン	同上。画面ごとか、共通部品だけか
工程	実装	同上
工程	テスト	単体・結合・総合のどこまでか、受入テストの支援の有無
工程	データ移行	含むか、移行する件数の想定
工程	リリース作業・操作説明	本番環境への反映、マニュアルや説明会の有無
前提条件	機能・画面の数	見積もりが想定している数
前提条件	対応端末とブラウザ	対応する範囲
前提条件	利用者数とデータ量	想定している人数と件数
前提条件	外部サービス・既存システムの連携	連携先の数と方式
前提条件	稼働時間・応答速度・セキュリティ	見積もりが前提にしている水準
前提条件	発注側が担う作業	資料やテストデータの用意、確認の返答期限
追加費用の条件	仕様変更の扱い	追加費用なしで対応する範囲、変更時の単価か算定方法
追加費用の条件	検収の方法と期間	何をもって完成とするか、検収に使える日数
追加費用の条件	契約不適合の扱い	契約書が定める通知の期限と、その期限の起点
追加費用の条件	別途費用	ライセンス・サーバー・外部サービスの利用料
保守費用	金額と単位	月額か年額か
保守費用	含まれる作業	監視・障害対応・問い合わせ・小さな改修のどれを含むか
保守費用	対応時間と契約期間	平日日中のみか、最低契約期間と解約の条件
体制	窓口と実装を担う人	提案した担当者が実装に入るか、再委託の有無
体制	進捗の共有	定例の頻度と、進捗を見せる方法
契約と成果物	契約形態	請負か準委任か
契約と成果物	納品物	ソースコード・設計書・テスト結果のどれが納品されるか
契約と成果物	権利の扱い	ソースコードやドキュメントの著作権がどちらに帰属するか

稼働時間や応答速度の水準の決め方は 10 章、契約形態と納品物は 11 章で扱っています。契約不適合の行は、期限の長さだけでなく起点も写してください。民法 637 条 1 項は、請負の注文者が不適合を知った時から 1 年以内に通知しないと、修補や報酬の減額などを求められなくなると定めています。起点は引渡しではなく不適合を知った時で、引渡しから 1 年間は直してもらえるという意味ではありません。準委任の契約には当てはまらず、契約書に別の定めがあればそちらが優先されるので、その条項を起点も含めて書き写します。

書き写し方 — 「記載なし」を空欄や 0 円にしない

見積書の書式は会社ごとに違います。比較表に写すときは、次の 3 つを守ると、会社ごとの差が表に残ります。

1. 「含む」「含まない」「記載なし」を書き分ける。見積書に書かれていない項目は「記載なし」と書きます。空欄にすると、確認して該当がなかったのか、まだ見ていないのかを区別できません。0 円と書けば、その会社の総額だけが安く見えます
2. 見積書の文言をそのまま写す。「テスト一式」とあれば「テスト一式」と書き、「結合テストまで含むはず」といった自分の解釈は「確認したいこと」の列に書きます
3. 「一式」は一式のまま残す。中身が分からない項目には、内訳を聞く対象として印を付けておきます

書式がばらばらで行に当てはめられない場合は、各社に同じ書式で出し直してもらいます。「工程ごとの工数と金額、前提条件、対象外の作業を、添付の表の行に合わせて記入してください」と表を添えて頼めば、書き写す手間も解釈の食い違いも減ります。依頼の時点で書式を揃える方法は 13 章で扱います。

保守費用まで足した期間総額で並べる

初期費用だけを比べると、保守を別見積にしている会社や、初期費用を抑え保守を高く設定した会社が有利に見えます。比較表の最後に、初期費用へ契約期間ぶんの保守費用と別途費用を足した「期間総額」の行を置いてください。保守費用は月額か年額かを揃えてから掛けます。

次の表は、3 年間で比べた架空の例です。前の表とは別の例なので、D〜F 社としています。ライセンスやサーバーなどの別途費用は 3 社とも同額と仮定し、表から外しています。

項目	D 社	E 社	F 社
初期費用 (税抜)	800 万円	1,000 万円	1,200 万円
テスト	テスト一式	結合テストまで含む	受入テストの支援まで含む
データ移行	記載なし	含まない (別途見積)	含む
保守費用 (税抜)	別途見積	月 25 万円	年 216 万円
3 年間の総額	移行と保守が未定で出せない	1,900 万円 + データ移行	1,848 万円

初期費用では D 社が最も安く見えますが、データ移行と保守の金額が決まっていないため、3 年間の総額はまだ出せません。F 社は初期費用が最も高いものの、データ移行と受入テストの支援を含み、3 年間の総額では E 社を下回ります。E 社には、この先データ移行の費用が加わります。

保守の月額が近い会社どうしでも、含まれる作業と対応時間が違えば、同じ金額として比べられません。保守費用の内訳と見積書の確認項目は、システム保守費用の相場と根拠 で扱っています。

「記載なし」を各社への質問に変える

比較表に残った「記載なし」「一式」と、前提の違いが、そのまま各社に聞く質問になります。表の状態ごとに質問の形を決めておくと、文面に迷いません。

表の状態	質問の形
記載なし	見積書にデータ移行の記載がありません。この見積もりに含まれていますか。含まれない場合の費用を教えてください
前提が他社と違う	当社は利用者 200 名を想定しています。200 名の場合の金額を教えてください
一式	テスト一式の内訳 (テストの種類と工数) を教えてください
保守の範囲が不明	保守費用に含まれる作業と対応時間、最低契約期間を教えてください

質問は全社に同じ文面で送り、回答期限を決めます。回答が届いたら比較表を更新し、「記載なし」が残っていないかを確かめてください。

比較表で分かるのは、各社の見積もりに何が入っているかと条件の違いまでです。工数が規模に対して妥当かどうかは、1 社ずつ 3 章のチェックリストで確かめます。

相見積で避けたいやり方は、14 章の交渉の節にまとめています。

13. 依頼の準備と RFP

見積もりのぶれのうち、発注側で減らせるのは情報の曖昧さから生まれる分です。準備を整えるだけで概算の幅が縮み、結果として金額も下がります。

発注前に決めておく 5 項目

1. 解きたい業務課題 (機能ではなく課題で書く)
2. 使う人と規模 (誰が何人、どのくらいの頻度で使うか)
3. 予算のレンジ
4. 希望する時期と、その理由
5. 社内で誰が決裁するか

予算は伝えたほうが安くなります。予算が分からないと、開発会社は最大限の要件で見積もるしかなく、必要のない機能まで積まれた金額が返ってきます。上限だけを言うのではなく、レンジと、その根拠になっている社内事情をあわせて伝えると、提案の質が変わります。

• 「500 万円前後、上限は 700 万円まで」のように幅で伝える
• 「今期の予算枠が 800 万円で、稟議は 1,000 万円から役員決裁になる」と背景を添える
• 「初期は 300 万円、次年度に追加で 500 万円を想定」と時間軸で分けて伝える

実際の 3 分の 1 の金額を伝えて反応を見るのは避けてください。その予算では実現できない構成の提案しか返ってこず、比較の材料になりません。

あわせて、決裁者が求める資料の形式 (相見積が何社必要か、どの粒度の内訳が要るか) を先に確認しておきます。後から知ると、開発会社に見積もりを出し直してもらうことになります。要件のヒアリング、レビュー、受け入れテストに使う社内側の担当者の時間も押さえてください。

用意すると精度が上がる 3 つの資料

• 業務フロー図。現状の業務の流れと、システム化したい範囲を示します
• 画面リスト。どんな画面が何枚必要かを示します
• 既存の資料。現在使っているエクセルや帳票の実物が有効です

業務フロー図は、いまの業務 (As-Is) を先に描き、そのあとにあるべき姿 (To-Be) を描くのが確実です。理想像から描くと、現場で実際に起きている例外処理が抜け落ちます。完璧である必要はありません。間違っていても構わないので、たたき台があることが重要です。いまの業務の流れを含め、要件定義書のうち発注側が自分で書く項目は、要件定義書の書き方【発注者向け】 で記入例とともに扱っています。

画面リストは、絵を描く前に表にするほうが早く進みます。勤怠システムなら次のような形です。

画面 ID	画面名	主な操作	利用者
S001	ログイン	認証	全員
S002	打刻	出勤・退勤・休憩	従業員
S003	勤怠一覧	自分の勤怠を月表示	従業員
S004	勤怠修正申請	打刻漏れの修正申請	従業員
S005	承認一覧	部下の申請を一覧	承認者
S006	承認詳細	承認・差し戻し	承認者
S007	月次集計	部署別・個人別集計	管理者
S008	CSV 出力	経理システム連携	管理者

画面が 8 枚なのか 30 枚なのかが分かるだけで、工数の帯が決まります。

RFI・RFP・RFQ

相見積を取るなら、RFP (提案依頼書) の形で条件を揃えるのが確実です。似た略称が 3 つありますが、段階が違うだけで、どれか 1 つを選ぶものではありません。

略称	正式名称	目的	発注側が知りたいこと
RFI	Request For Information	情報提供依頼	どんな会社があるか、実績と体制
RFP	Request For Proposal	提案依頼	どう実現するか、体制と概算費用
RFQ	Request For Quotation	見積依頼	確定した要件に対する正式見積

初めての領域で発注先の候補すら分からない段階なら RFI から、作るものが決まっていて金額だけ揃えたいなら RFQ から入ります。作るものの方向は決まっていて、提案と金額をあわせて比べたいなら RFP から入ります。

RFP に盛り込む項目は次のとおりです。

1. 背景と目的
2. 現状の課題
3. システム化の範囲 (やること・やらないこと)
4. 機能要件
5. 非機能要件 (10 章の 6 分類)
6. 前提条件と制約
7. 予算のレンジ
8. スケジュール
9. 提案してほしい内容と形式
10. 選定の基準と選定の日程

受け取った側がすぐ積算に入れる RFP には、共通点が 4 つあります。前提と制約 (既存システム、社内規定、使えない技術) が最初に書かれていること、やらないことが書いてあること、優先度が必須・推奨・任意の 3 段階で示されていること、意思決定者と締切が明記されていることです。優先度が付いていない機能一覧は、全部必須として積算されます。

依頼メールなら 7 項目

RFP を作るほどではない規模なら、メールで足ります。書くべきは次の 7 項目です。

項目	書く内容
会社情報	会社名・部署・担当者・連絡先・事業内容の 1 行紹介
目的・背景	解決したい業務課題、想定利用者、期待する効果
対象スコープ	種別、主要機能、対象環境
希望納期	リリース希望日、動かせない締切
予算感	「100 万〜300 万円」のようにレンジで
回答期限と回答方式	いつまでに、どの形式で返してほしいか
添付資料の一覧	RFP、業務フロー図、画面リスト、参考サービス

14. 交渉と仕様変更 — 金額ではなくスコープを動かす

見積もりの交渉で最も大事なのは、何を動かすかの選択です。

「もう少し何とかなりませんか」という値引きの交渉で動く幅は小さく、目安は総額の 5〜10% です。値引きの原資は開発会社の利益と予備費しかないためで、関係も悪くなりがちです。一方、スコープを動かせば、総額を 30〜50% 圧縮できる場合があります (目安)。

スコープと条件を動かす打ち手は次のとおりです。

• 機能を削る、または後回しにする。初期リリースの機能を半分に絞る
• デザインを標準化する。独自のデザインを標準コンポーネントに寄せる
• 対応範囲を絞る。対応する OS や端末を減らす
• 期間を延ばす。繁忙期を避けられ、体制の組み方に余裕が生まれる

実務上、最も早いのは予算を伝えて「この範囲で何ができるか」を設計してもらう方法です。金額を下げる交渉ではなく、予算に合う構成を一緒に作る話に切り替わるため、双方に無理がありません。オフショアの組み合わせで単価を下げる方法もありますが、仕様を伝える負荷が発注側に寄り、浮いた金額の一部は、発注側の管理工数に消えます。

次のやり方は、金額が下がっても失うものが大きく、その後の提案の質も落とします。

• 他社の見積金額や相見積の最安値を持ち出して、同額まで下げるよう求める
• 根拠を示さずに「もっと安くならないか」を繰り返す
• 本命が別にいることを隠したまま提案させる。発注する気がない会社から数合わせで見積もりを取る
• 提案書の内容を、そのまま他社へ渡して見積もらせる
• 極端に安い 1 社の金額を基準に、他社の妥当性を否定する

いずれも、次に困ったときに相談できる相手を減らします。開発は契約後のほうが長く、そこで融通が利くかどうかは関係の質で決まります。

仕様変更と追加見積

開発が始まると、仕様変更や追加要望は必ず発生します。問題は変更そのものではなく、変更が見積もりにどう反映されるかが事前に決まっていないことです。

追加費用の原因は 3 つに分かれる

追加費用は、発注側が要望を変えたときにだけ出るものではありません。原因は仕様変更・前提の違い・見積もりの抜けの 3 つに分かれ、確かめる文書も防ぎ方もそれぞれ違います。

原因	起きること	確かめる文書	契約前の防ぎ方
仕様変更	合意した機能や画面を、発注側が変える・足す	要件定義書、承認した設計書、見積書の機能一覧	「やらないこと」と優先度を明記し、追加費用なしで対応する範囲を決める
前提の違い	データ件数・連携先の仕様・資料の提出時期・動作環境が、見積もりの想定と実際で違う	見積書の前提条件欄、打ち合わせの議事録	前提を数値で書いてもらい、前提と違ったときの扱いを決める
見積もりの抜け	データ移行・テスト・インフラ構築・リリース作業などが、最初から見積もりに入っていない	見積書の作業内訳、「対象外」「別途見積」の欄	相見積の比較表で工程の有無を並べ、記載のない工程を契約前に質問する

前提の違いと見積もりの抜けは、発注側が要望を変えていなくても費用が増える原因です。追加費用を社内で説明するときも、3 つのどれに当たるかを先に分けておくと、見返す文書が決まります。見積もりの抜けは、契約前に見つかれば、追加費用ではなく当初の見積もりの修正で片付きます。工程の有無を並べる比較表のひな形は 12 章で扱っています。

変更の見積もりが高く感じるとき

画面 1 つの変更でも、影響範囲の調査、設計の修正、実装、テスト、既に通っていた箇所の再確認 (回帰テスト) が発生します。回帰テストの工数は見えにくく、「表示を変えるだけ」に見える変更が数十万円になるのはこのためです。金額が妥当かどうかは、工数に割り戻すと判断しやすくなります。

変更の種類	目安工数
画面への項目 1〜2 個追加 (一覧・帳票への波及なし)	0.5〜2 人日
画面への項目追加 (一覧・検索・帳票にも波及)	3〜7 人日
既存機能の仕様分岐追加 (条件によって処理を変える)	3〜10 人日
新規 1 画面の追加 (既存機能の延長線上)	5〜15 人日
帳票・CSV・API の新規追加	5〜20 人日

同じ「項目を 1 つ足す」でも、一覧や帳票に波及するかどうかで数倍変わります。変更見積を受け取ったら、影響範囲と回帰テストの範囲、その変更を後のフェーズにまとめた場合の費用差を聞いてください。まとめたほうが安くなる変更もあります。

契約書に書く変更の手続き — IPA モデル契約の条文から

変更の手続きを契約書にどう書くかは、6 章でも触れた IPA の 情報システム・モデル取引・契約書 (第二版) が参考になります。このうちソフトウェア開発委託基本モデル契約書では、第 33 条から第 38 条が契約内容の変更を扱っています。発注者の言葉に直すと、次のとおりです。

条	定めていること	発注者として押さえること
第 33 条	契約内容の変更は、事前に協議したうえで、書面の変更契約を結ぶことによってのみ行う	打ち合わせやチャットで決めた変更も、金額や納期が変わるなら書面に残す
第 34 条	仕様書や承認済みの中間資料を変えたいときは、変更の内容と理由を書いた変更提案書を出す	発注側からも開発会社からも提案できる
第 35 条	開発会社が設計書などの中間資料の承認を求めたとき、点検期間内に理由を示して異議を述べなければ、承認したものとみなす	確認依頼を期限内に返さないと、その内容で決まる。後から直せば変更の扱いになる
第 36 条	発注側がやむを得ず決められない事項は、その内容と確定予定時期、確定によって委託料や納期が変わる場合に受け入れることを書面にする	決めきれない要件を残したまま発注するなら、どこが未確定かを先に書面にする
第 37 条	変更提案書を受け取った側は、期限内に変更管理書を出し、連絡協議会で協議する。双方の責任者が承認して変更が決まる	変更管理書で費用と納期への影響を確かめてから承認する
第 38 条	協議がまとまらないとき、発注側は残りの作業について契約を解約できる。その場合、それまでの委託料と開発会社に生じた損害を負担する	変更に応じず解約するときにも費用がかかる。開発会社からの解約も定める案 (B 案) もある

第 37 条が変更管理書に書くよう定めているのは、変更の名称・提案の責任者・年月日・変更の理由・仕様を含む変更の詳細・費用が要る場合はその額・検討期間を含めた変更作業のスケジュール・納期や委託料など契約条件への影響の 8 項目です。発注側が出す変更依頼書 (モデル契約でいう変更提案書) もこの項目に合わせておくと、開発会社から返ってくる変更管理書と突き合わせやすくなります。

変更が納期や委託料などの契約条件に影響する場合は、変更管理書の承認に加えて、第 33 条の変更契約を結んだ時点で変更が確定します。また第 37 条 4 項は、協議が調わない間、発注側からの中断要請があるなど特段の事情があれば、開発会社は作業を中断できると定めています。

モデル契約はひな形であり、実際の契約書が同じ条文になっているとは限りません。変更管理書を返すまでの日数や中間資料の点検期間も、モデル契約では「○日以内」と空欄で、個別の契約で決める形です。自社の契約書に同じ趣旨の定めがあるか、日数がいくつになっているかを契約前に確かめてください。条項の解釈で開発会社と意見が分かれたときは、弁護士に相談するのが確実です。

変更を安定させる

変更が頻発する案件では、変更管理のルールを契約時に決めておくのが有効です。何をもって変更とするか、いくらまでは追加費用なしで対応するか、判断は誰がするか。この 3 点が決まっていれば、都度の交渉が要らなくなります。運用としては、変更依頼書の書式を決める、週次でたまった依頼をまとめて判断する場を用意する、開発費の 10〜20% を変更用の予算として別枠で確保する、の 3 つが役に立ちます。変更用の枠があれば、変更のたびに稟議をやり直す必要がなくなります。

まとめ

システム開発の見積もりは、金額の大小ではなく前提条件を読む書類です。読んだあとに手を付けるなら、次の 3 つです。いずれも発注側で準備でき、開発会社の返事を待たずに始められます。

• 手元の見積書を、3 章の 15 項目で確かめる。書かれていない項目が、聞き返す箇所です
• 画面リストを作る。8 枚なのか 30 枚なのかが分かるだけで、工数の帯が決まります
• 予算をレンジで伝える。伝えないほうが高くなります

受け取った見積書の読み方に迷ったら、見積書の無料診断 で工程の抜けや追加費用の条件を確認できます。これから依頼する段階なら、費用シミュレーター で概算と工程ごとの内訳を先に掴んでおくと、各社の見積もりを読むときの物差しになります。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、工程ごとの内訳と前提条件を明示したうえでご提案しています。進め方と費用の考え方は AI 駆動開発 のページにまとめています。要件が固まりきっていない段階でも、業務課題と予算のレンジを共有いただければ、実現できる範囲を一緒に設計します。お問い合わせ からご相談ください。

関連リソース

• AI 駆動開発の費用と期間: AI 駆動開発の費用・期間はいくら?料金相場と見積もりの内訳
• Web システムの実数値: Web システム開発の費用と期間の相場
• 業務システムの発注先比較: 業務システム 受託開発の比較
• 発注先の見極め: AI 受託開発の会社を選ぶときの 5 つのチェックポイント
• 契約前の実務確認: AI 開発の発注前に確認する 10 項目
• アプリ開発の費用と見積もりの比べ方: アプリ開発の費用相場と見積もり比較
• MVP・スモールスタート: MVP・スモールスタート開発の見積もり
• SaaS の MVP の実数値: SaaS の MVP 開発の費用と期間
• 既存システムのリプレイス: リプレイス案件の見積もり
• レガシー刷新の実数値: レガシー刷新の費用と期間
• 開発後の保守・運用・追加開発: システム保守費用の相場と根拠
• アジャイル開発: アジャイル開発の見積もり
• ラボ型開発・チーム貸し: ラボ型開発の見積もりの構造
• オフショア開発: オフショア開発の見積もり
• フリーランスへの発注: フリーランスに発注する場合の見積もり