業務システム開発の見積もりの作り方｜あとで足せない項目

2026年8月23日

朝比奈蒼

この記事のポイント

✓業務システム開発見積もりの出し方を
✓受注する側の実務目線で整理しました
✓あとから追加できない項目の洗い出し

業務システム開発の見積もりの出し方で本当に難しいのは、金額の計算ではありません。難しいのは「何をどこまでやるのか」を、着手前に文章として確定させることです。結論から言うと、見積もりで失敗する原因のほとんどは計算間違いではなく、書き漏らした作業を後から請求できなくなることにあります。

この記事では、受注する側が業務システム開発の見積もりを作るときの手順を、洗い出し、算出、書式、提示後の立ち回りという順番で整理します。特に重点を置くのは「あとで足せない項目」です。工数の計算方法を学ぶ記事は世の中に多数ありますが、実務で赤字になるかどうかを決めているのは、計算式ではなく見積書に書かなかった一行のほうだという傾向が見られます。

見積もりが決めているのは金額ではなく境界線

業務システム開発の見積書は、発注者にとっては予算稟議を通すための資料ですが、受注者にとっては契約の範囲を定義する文書です。この非対称性を理解していないと、話がかみ合いません。発注者は総額の欄しか見ていないことが多く、受注者は前提条件の欄に一番神経を使っています。両者が同じ紙を見ながら別のことを考えている、というのが実態です。

見積もりは段階によって精度が違う

業務システム開発の見積もりは、一般的に段階を分けて出します。相談を受けた直後に出す概算見積もり、要件定義がある程度進んだ段階で出す基本見積もり、設計が固まった段階で出す確定見積もりの3段階です。段階が進むほど精度は上がりますが、そのぶん見積もり作業そのものに時間がかかります。

概算の段階では、精度の幅を明示するのが実務的です。「この段階の見積もりは上下におよそ50パーセントの幅があります」と書いておけば、後で金額が動いたときに説明ができます。逆に、概算なのに一円単位まで書いた見積書を出してしまうと、発注者はそれを確定金額として受け取ります。数字の見た目の精密さは、そのまま約束の重さに変換されるということです。

段階を分けるときは、次の見積もりを出すタイミングも同時に伝えます。「要件定義が完了した時点で、あらためて基本見積もりを提出します」という一文があるだけで、金額が変わることが想定内になります。この一文がないまま金額だけ更新すると、発注者からは値上げに見えます。

発注者が見積書のどこを見ているか

発注者側の担当者は、社内で稟議を回す立場です。稟議で聞かれるのは、なぜこの金額なのか、他社と比べて高くないか、後から追加費用が出ないか、の3点にほぼ集約されます。つまり見積書は、担当者が社内で説明するための台本でもあります。

このため、工程ごとに分解された見積書は通りやすく、「システム開発一式」とだけ書かれた見積書は通りにくいという傾向があります。分解されていれば、担当者は「設計にこれだけ、テストにこれだけかかります」と説明できます。一式では説明のしようがなく、値引き交渉の対象が総額そのものになってしまいます。

後から追加費用が出ないか、という懸念に対しては、追加費用が出る条件を先に書いておくのが最も効きます。曖昧にしておくほうが受注しやすいと考えるのは逆で、条件が明示されている見積書のほうが安心して選ばれます。

あとで足せない項目を先に洗い出す

見積もりの精度を左右するのは、目立たない作業をどれだけ拾えるかです。プログラムを書く時間は誰でも見積もりますが、その周辺にある作業が抜けます。ここでは、業務システム開発で特に抜けやすく、しかも着手後に追加請求しにくい項目を挙げます。

要件が固まっていない部分の扱い

見積もり時点で決まっていない仕様は必ずあります。問題は、決まっていないことを見積書に書かず、頭の中だけで「たぶんこのくらい」と置いてしまうことです。決まっていない項目は、前提条件として明記します。書き方は「帳票のレイアウトは既存Excelを踏襲するものとし、新規デザインの作成は含みません」のように、含むものではなく含まないものを書くほうが誤解が少なくなります。

未確定項目が多すぎる場合は、要件定義そのものを分離して受注する方法があります。要件定義を単独の契約にし、その成果物をもとに開発の見積もりを出す形です。この進め方は発注者にとっても合理的で、要件が固まっていない状態で総額を確定させるリスクを双方が避けられます。

環境構築とデータ移行

業務システムは既存業務の置き換えであることがほとんどで、そこには既に動いているデータがあります。移行対象の件数、文字コード、名寄せの要否、移行できなかったデータの扱いを決める作業は、コードを書く時間よりも長くかかることがあります。特に名寄せは、取引先マスタの表記ゆれを人が判断する作業が発生するため、機械的には終わりません。

移行を見積もる際は、誰が移行元データを抽出するのかを必ず確認します。発注者側が抽出できるのか、受注者が既存システムに接続して取り出すのかで、工数はまったく変わります。既存システムのベンダーに抽出を依頼する場合は、そのベンダーの費用と日程がクリティカルパスに入ります。自分の見積もりの外側に、動かせない他社の日程が挟まるということです。

環境構築も同様です。開発環境、検証環境、本番環境をいくつ用意するのか、それぞれ誰が費用を持つのかを書き分けます。クラウドの利用料を受注者が立て替える場合は、その扱いも明記します。

テストと受け入れにかかる時間

テスト工数は、開発工数に対する比率で置く方法が一般的ですが、業務システムでは受け入れテストの支援工数が見落とされます。発注者が自分たちでテストするから受注者の工数はゼロ、とはなりません。実際には、テストデータの準備、手順書の作成、テスト中の質問対応、指摘された事象の切り分けに時間が取られます。

受け入れテストの期間と、その間の対応体制を見積書に書きます。「受け入れテスト期間は2週間とし、その間の問い合わせ対応を含みます」という形です。期間を書かないと、受け入れテストが延々と続き、その間の対応が無償になります。

業務システム固有の要件

業務システムには、一般的なWebサービスにはない要件が入ります。代表的なものは、権限管理、承認フロー、監査ログ、締め処理、年度切り替えです。これらは画面数には現れませんが、設計とテストに大きく影響します。

権限管理は、役職ごとに見える範囲が変わる仕組みです。組織改編があると設定を変える必要があるため、管理画面まで作るのか、データベースを直接触る運用にするのかで工数が変わります。監査ログは、誰がいつ何を変更したかを残す仕組みで、内部統制の要件として求められることがあります。締め処理は、月末や年度末にデータを確定させる処理で、確定後の修正をどう扱うかという業務ルールの決定が必要になります。

これらは発注者から明示的に要求されないことがあります。要求されていないから作らなかった、では検収時に揉めます。見積もり段階で「今回は監査ログの機能は含みません」と書くか、含めるなら工数を積むかを決めておきます。

外部連携と帳票

既存の会計システムや販売管理システムとの連携は、相手側の仕様に依存します。APIが公開されているのか、CSVの受け渡しなのか、画面から手入力なのかで工数が桁違いに変わります。連携先の仕様書が手に入らない段階では、金額を確定させないほうが安全です。

帳票は特に注意が必要な領域です。画面の項目を並べるのと違い、帳票は印刷したときの見た目まで合わせる必要があります。改ページの位置、罫線の太さ、既存の専用用紙への位置合わせといった調整が発生します。帳票1枚あたりの工数を単価表として持っておき、枚数で計算する方法が実務的です。

運用開始後の作業

納品して終わりではないのが業務システムです。運用開始直後は、操作方法の問い合わせ、想定外のデータによる不具合、業務の例外パターンへの対応が集中します。この期間の対応を保証期間として無償にするのか、保守契約として有償にするのかを見積もり段階で決めます。

保証期間を設ける場合は、その範囲を書きます。「納品後3か月以内の、仕様書との不一致に起因する不具合の修正を無償とします」という形です。範囲を書かずに「3か月間サポートします」とだけ書くと、仕様変更の依頼まで無償対応の対象になります。

算出方法を使い分ける

見積もりの算出方法には複数の考え方があり、案件の性質と手元の情報量によって使い分けます。ひとつの方法に固執せず、複数の方法で出した数字を突き合わせるのが精度を上げる近道です。

類推法

過去に手がけた似た案件を基準にして、規模の違いを係数で調整する方法です。手元に実績データがあるなら、最も早く、そして意外に精度が高い方法です。

類推法は見積を行う企業が保有する”過去のシステム開発事例”を参考に、開発するシステムがどれくらいのコストや工数で作成できるかを算出する方法です。企業のシステム開発経験が長い場合、様々なシステム開発の経験を持っている可能性が高いです。そのため、今回作成するシステムに近い規模や難易度のシステムを参考にし、正確な見積を算出することができます。〇メリット過去に開発したシステムと作成するシステムを比較して見積を作成するので、見積を短時間で作成することが可能×デメリット過去に開発したことがないシステムでは使えない出典: plus.cmknet.co.jp

この方法を使うには、過去案件の実績工数を記録しておく必要があります。見積もり工数ではなく、実際にかかった工数です。多くの現場でこの記録が残っていないため、類推法が使えません。案件ごとに、工程別の実績を残す習慣をつけておくと、次の見積もりが速くなります。

記録する粒度は、工程別に週単位で十分です。細かく取ろうとすると続かないため、要件定義、設計、実装、テスト、移行、立ち上げ支援くらいの分け方で始めます。

パラメトリック法

要件や設計対象を数え上げて、係数を掛けて算出する方法です。画面数、帳票数、テーブル数、バッチ処理数といった数えられるものを基準にします。

パラメトリック法は、要件や設計箇所を点数化して、見積を作成する手法です。〇メリット計算式により見積が算出されるため、担当者の知識や経験に左右されるという人依存を払拭できる×デメリット要件や設計箇所の数に依存するため、見積の精度がそこまで高くない出典: plus.cmknet.co.jp

この方法の利点は、発注者に説明しやすいことです。画面が増えれば金額が増える、という関係が目に見えるため、追加要望が出たときの増額の根拠になります。欠点は、画面の複雑さが反映されないことです。一覧表示だけの画面と、入力チェックが30項目ある画面を同じ1画面として数えると、当然ずれます。

実務では、画面を難易度別に分類して係数を変えます。単純、標準、複雑の3区分程度に分け、それぞれに係数を割り当てるだけで精度が上がります。

ボトムアップ法

作業を細かく分解して、ひとつずつ工数を積み上げる方法です。設計が固まった後の確定見積もりに向いています。精度は最も高くなりますが、分解する作業自体に時間がかかるため、提案段階では現実的ではありません。

ボトムアップで積むときは、実装以外の作業を必ず行に立てます。設計書の作成、レビュー対応、単体テストの実施と記録、結合テスト、ドキュメント整備、会議への出席です。会議の時間は特に抜けやすく、週1回の定例が3か月続けば、それだけでまとまった時間になります。

三点見積もりで幅を扱う

楽観値、最頻値、悲観値の3つを出して加重平均する方法です。不確実性の高い項目に対して有効で、単一の数字で答えを出すよりも、なぜその金額なのかを説明しやすくなります。

外部連携やデータ移行のように、相手次第で工数が変わる項目にこの方法を当てます。悲観値をそのまま見積もりに載せると金額が跳ね上がるため、加重平均を採用し、悲観値に振れる条件を前提条件として書き添えるのが実務的な落としどころです。

見積書の項目立てをそろえる

算出した数字を、どう並べて見せるかで通りやすさが変わります。金額が同じでも、書き方によって発注者の受け取り方は変わります。

工程で分ける

要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、受け入れ支援、データ移行、環境構築、教育、保守という並びで書きます。それぞれに人日と金額を割り当てます。これにより、発注者は工程単位で調整を相談できるようになります。

工程を分けておくと、予算が足りないときに「教育資料の作成は御社で行い、その分を減額する」といった交渉ができます。一式で書いていると、減らせる場所がないため、全体の値引きしか選択肢がなくなります。値引きは利益をそのまま削りますが、範囲の調整は作業量が減るぶん利益率を維持できます。

前提条件と除外条件を必ず書く

見積書の最後に、前提条件と除外条件の欄を設けます。ここが業務システム開発の見積もりで最も重要な部分です。書くべき内容は次のようなものです。

対象業務の範囲、対象拠点や部署の数、想定利用者数、対応ブラウザとバージョン、既存システムの改修の要否、移行対象データの範囲と件数の上限、帳票の枚数、打ち合わせの回数と場所、発注者側で用意してもらうもの、成果物の一覧です。加えて、除外するものとして、既存システム側の改修、他ベンダーとの調整、運用マニュアルの作成、ハードウェアの調達、といった項目を並べます。

この欄を書くのを嫌がる人がいます。細かいことを書くと不信感を与えるのではないか、という懸念です。実際には逆で、書いてある見積書のほうが検討が進んでいると受け取られます。書かれていない見積書は、後で揉める前提で読まれます。

有効期限と変更管理のルール

見積書には有効期限を入れます。1か月から3か月程度が一般的です。期限を切らないと、半年前の見積もりで発注される事態が起きます。その間に前提条件が変わっていても、金額だけが残ります。

あわせて、変更管理のルールを書きます。要件が追加になった場合にどう扱うかです。「仕様変更が発生した場合は、影響範囲と工数を提示のうえ、双方合意の上で見積もりを更新します」という一文です。この一文があると、追加要望が出たときに自然に見積もりの話に移行できます。ない場合、追加要望は「ついでにお願い」として無償の期待とともに来ます。

見積もりを作る手順

実際に見積もりを作る流れを、順を追って整理します。

ヒアリングで確認する項目

最初の打ち合わせで確認する項目を、あらかじめリスト化しておきます。毎回同じことを聞くため、テンプレート化する価値があります。確認するのは、解決したい業務課題、現在の業務の流れ、関わる人数と役割、既存システムの有無と種類、希望する稼働時期、予算の枠、社内の意思決定者、過去に同種の開発を発注した経験の有無です。

予算の枠を聞くのをためらう人がいますが、聞いたほうが双方のためになります。枠が分かれば、その範囲で実現できる構成を提案できます。枠を知らずに見積もりを出すと、桁が違って検討にすら乗らないことがあります。聞き方は「概算で構いませんので、想定されている予算感を教えていただけますか」で十分です。

意思決定者の確認も重要です。窓口の担当者に決裁権がない場合、見積書は必ず上位者に回ります。誰が見るのかが分かれば、その人に伝わる書き方ができます。

画面と帳票を数える

業務の流れを聞いたら、必要な画面と帳票を紙に書き出します。この作業は打ち合わせの場で行うのが効率的です。ホワイトボードに画面遷移を書きながら、抜けている画面を発注者と一緒に見つけます。

マスタ管理画面は特に忘れられます。商品マスタ、取引先マスタ、社員マスタ、部署マスタ、区分値のマスタといった画面は、業務の説明では出てきませんが、必ず必要になります。マスタ画面を数え忘れると、実装段階で想定外の作業が発生します。

検索画面と一覧画面の条件も確認します。どの項目で検索できる必要があるのか、一覧に何件表示するのか、CSV出力は必要かといった点です。CSV出力は「あると便利」で追加されがちですが、出力項目の調整に時間が取られます。

データ設計から工数を導く

画面を数えたら、次はデータ構造を粗く設計します。テーブルの数と、テーブル間の関連を把握するだけでも、実装の難易度が見えてきます。テーブル数が多い、関連が複雑、履歴を持つ必要がある、といった条件は、そのまま工数の増加要因です。

履歴管理は特に工数に効きます。「変更前の値も残したい」という要望は、テーブル構成、画面の作り、検索の仕組みのすべてに影響します。要望として出た段階で、工数への影響を伝えておきます。

リスクバッファの置き方

不確実性に対する余裕を、どこに、どれだけ置くかを決めます。各作業の見積もりに個別に上乗せする方法は、積み上がりすぎて総額が膨らむうえ、どこに余裕があるのか分からなくなります。

推奨されるのは、全体に対してひとまとまりのバッファを行として立てる方法です。「プロジェクト管理費」「予備費」といった名目で計上します。行として見えていれば、発注者との調整でこの行を減らすかどうかという議論ができます。各作業に隠していると、値引き要求が来たときに、どこを削っているのか自分でも分からなくなります。

契約形態によって見積もりの意味が変わる

同じ金額でも、請負契約と準委任契約では約束していることが違います。請負は成果物の完成を約束する契約で、完成しなければ報酬を受け取れません。準委任は業務の遂行を約束する契約で、決められた稼働を提供することが履行になります。

要件が固まっていない段階で請負契約を結ぶのは、受注者にとってリスクが大きくなります。要件定義は準委任、その後の開発は請負、という分け方が実務ではよく採られます。見積書の段階で、どの工程がどの契約形態を想定しているかを書いておくと、契約交渉が円滑になります。

準委任で見積もる場合は、稼働の単位と精算のルールを明示します。月の稼働時間の下限と上限を定め、その範囲を外れた場合の精算方法を書く形が一般的です。この取り決めがないと、稼働が想定を大きく超えたときに、追加の請求根拠がありません。

見積もりを出したあとの立ち回り

見積書を送って返事を待つだけ、というのは機会損失です。提出後に何をするかで、受注率も、受注後の進めやすさも変わります。

説明の場を設ける

見積書は郵便やメールで送って終わりにせず、内容を説明する場を作ります。金額の根拠、前提条件の意図、除外した項目とその理由を口頭で補足します。この場で発注者から出る質問が、そのまま契約後のリスクの所在を教えてくれます。

説明の場では、金額を下げる話ではなく、範囲を調整する話をします。「この予算に収めるなら、この機能を第二期に回す構成が現実的です」という提案です。段階に分けた提案は、発注者にとっても稟議を通しやすく、受注者にとっては継続案件につながります。

金額のずれに気づいたとき

見積もりを出した後で、明らかに金額がずれていると気づくことがあります。工数を読み違えていた、前提が間違っていた、といった場合です。

見積金額が前章で述べた計算方法をもとに考えると、明らかにずれている場合などは、見積作成側かお客様のどちらかが損をしてしまいます。後々の関係悪化なども考えられるため、どちらが損になっているかにかかわらず、金額がおかしいと感じた場合は連絡する必要があります。出典: plus.cmknet.co.jp

自分が損をする方向のずれは言い出しやすく、発注者が損をする方向のずれは黙っていたくなります。しかし後者を放置すると、後で発覚したときに信用を失います。気づいた時点で伝えるのが、結果的に取引を長く続ける方法です。

断られたときに聞くこと

失注したときに、理由を聞ける関係を作っておきます。金額だったのか、実績だったのか、時期だったのか、提案内容だったのかが分かれば、次の見積もりに反映できます。聞き方は「今後の参考にさせていただきたいので、差し支えなければ決め手を教えていただけますか」で構いません。

失注理由が金額だった場合も、単純に高すぎたのか、他社の見積書の見せ方が良かったのかで対処が変わります。範囲の違いを比べずに総額だけで判断されているケースは珍しくなく、その場合は次回から範囲の明示を強めるという打ち手になります。

受注する側から見た見積もりの位置づけ

業務システム開発を個人や少人数で受ける場合、見積もりは営業活動の一部でもあります。どこまで無償で対応するかの線引きが必要です。概算見積もりまでは無償、要件を詰めるヒアリングと調査を伴う見積もりは有償、という切り分けが実務的です。

無償で詳細見積もりを作り続けると、受注しなかった案件の調査時間が丸ごと損失になります。この時間は、既存顧客への提案や、単価を上げるための準備に使ったほうが回収できます。仕事の内容や求められるスキルの全体像はWeb・業務システム開発のお仕事で職種ごとに整理されており、どの範囲まで自分で受けるかを決める材料になります。

工数を金額に換算する際の基準を持っておくことも必要です。同じ職種でも、担当する工程や経験年数によって水準は変わります。職種ごとの水準はソフトウェア作成者の年収・単価相場に統計としてまとめられており、自分の基準が市場からどれくらい離れているかを確認できます。近い領域として、AIを組み込んだ業務システムやセキュリティ要件の強い案件はAI・マーケティング・セキュリティのお仕事にまとめられており、扱う領域を広げる際の参考になります。

見積書という文書そのものの体裁も、受注に影響します。誤字、体裁の崩れ、計算の合わない合計欄は、成果物の品質を疑わせます。ビジネス文書としての基本を確認したい場合はビジネス文書検定で扱われる形式が、そのまま見積書や提案書の書き方の基準になります。ネットワークやインフラの構成まで提案に含める案件では、CCNA（シスコ技術者認定）の範囲にある知識が、前提条件の書き分けに直結します。

現場を見てきた立場からの観察

フリーランスと在宅の仕事の市場を20年見てきた立場から言えば、見積もりが上手い人と下手な人の差は、計算能力ではなく質問の量にあります。見積もりが上手い人は、金額を出す前に驚くほど多くの質問をしています。逆に、見積もりで赤字を出し続ける人は、聞くのを遠慮して、想像で埋めています。

もうひとつ、長く仕事が続く人に共通しているのは、見積書を「断るための道具」としても使っていることです。受けたくない条件の案件に対して、条件を明示した見積もりを出す。前提条件を正確に書けば、無理な案件は自然に金額が上がり、発注者側から辞退してくれます。安請け合いして後で苦しむより、最初に正しい数字を出すほうが、双方にとって時間の節約になります。

もうひとつ、額面と手取りの関係についても触れておきます。仲介が入る取引では、提示された金額から手数料が引かれた額が実際の収入になります。手数料0%で直接取引できる場合、発注者は同じ予算でより多くの作業を依頼でき、受注者は同じ作業でより厚い手取りを得られます。見積もりの金額を上げる交渉は難しくても、手取りの厚さは取引の形を変えるだけで動きます。この構造は、単価交渉に疲れている人ほど意識する価値があります。

海外の発注者から業務システムの案件を受ける場合は、見積書の形式や通貨、支払い条件が国内と異なります。実務の進め方はUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法で整理されており、国内案件との違いを把握する手がかりになります。長く現場を経験した人が独立して受託を始めるケースについては、定年後のフリーランス独立｜退職金を活かした起業プランと注意点に、事業として組み立てる際の注意点がまとまっています。

見積もりの精度は記録でしか上がらない

最後に、見積もりの精度を上げる方法はひとつしかありません。出した見積もりと、実際にかかった工数を突き合わせて記録することです。この差分を案件ごとに残していけば、自分がどの工程を甘く見積もる癖があるのかが分かります。

多くの場合、テスト工数と、コミュニケーションにかかる時間が慢性的に不足しています。実装の工数はそれほど外れません。外れるのは、実装以外の全部です。この傾向を数字で確認できれば、次の見積もりでは該当工程に係数を掛けるという具体的な対処ができます。

記録は複雑な仕組みでなくてかまいません。案件名、工程、見積もり工数、実績工数の4列の表があれば十分です。案件が5件も溜まれば、自分の傾向は見えてきます。見積もりの出し方は、方法論を覚えることよりも、自分のデータを持つことで安定していきます。

よくある質問

Q. 概算見積もりはどのくらいの精度で出せばよいですか？

要件が固まっていない段階の概算は、上下に幅があることを明示したうえで出します。一円単位まで書くと確定金額として受け取られるため、丸めた数字で提示し、精度の幅と次の見積もりを出すタイミングを併記します。「要件定義完了後にあらためて提出します」という一文を入れておくと、後で金額が動いても値上げとは受け取られません。