システム開発の見積もりは妥当か｜見積書を行ごとに読む質問と、生成AIで縮む工程・縮まない工程

複数の会社から取った見積もりの金額が倍以上違っても、金額だけでは、どれが妥当かは決められません。差の多くは、どこまでを作る範囲に入れたか、テストやデータ移行をどれだけ見込んだか、発注する側がどの作業を受け持つ前提か、という前提の違いから生まれるからです。妥当かどうかは、見積書を行ごとに分け、各社の前提をそろえてから比べて判断します。

行ごとに確かめるのは、要件定義、設計・開発（画面と帳票の数、ほかのシステムとつなぐ数）、テスト、データ移行、保守、そして「前提条件」「対象外」の欄です。期間は、日本情報システム・ユーザー協会（JUAS）が公開している標準工期の式を使えば、工数に比べて短すぎないかを確かめられます。「生成AIで作るので安く早い」と説明された見積もりは、どの行が縮んだのかを聞けば読めます。

ここでは、紙・FAX・Excelで回している受発注や在庫、日報などの業務をシステムにしようとして、2〜3社から見積もりを受け取った発注担当者を想定しています。根拠には、IPA（情報処理推進機構）のモデル契約、JUASの調査、東京商工会議所の調査など、公開資料で確かめられるものを使いました。相場の金額表は、自社の条件がその幅のどこに入るかが分からないと判断に使えないため、載せていません。

金額の差は、たいてい前提の差

見積もりを作る側は、依頼の資料に書かれていないことを、自社の経験で埋めて金額にします。取引先ごとの単価や締め日の違いを何通り見込むか、Excelの台帳を誰が整えて移すか、発注側の担当者がテストにどれだけ時間を割ける前提か。この置き方が違えば、同じ依頼から出た見積もりでも金額は大きく離れます。安く見える見積もりが、作業の一部を発注側の受け持ちにしているだけ、ということもあります。

見積もりには段階もあります。IPAが公開している「情報システム・モデル取引・契約書」は、要件にあいまいさが残る段階の見積もりを、要件がはっきりした段階で見積もり直す「再見積り」と、工程ごとに契約を結ぶ「多段階契約」の考え方をとっています。解説では、見積もりの段階をおおむね次のように分けています（IPA「情報システム・モデル取引・契約書」第二版）。

要件を固める前に取った見積もりは、この図でいえば試算か概算です。1社は概算のつもりで幅を見込み、別の1社は試算のつもりで低めに出している、ということも起こります。比べる前に、どの段階の見積もりで、何を前提にした金額なのかを、各社に書いてもらいます。モデル契約が示す提案書の記載事項にも、見積もりの前提になった条件と、発注側・開発側それぞれの役割が含まれています。

見積書を行ごとに読む

BI・ダッシュボードの構築の見積もりを、設計・データ接続・前処理・画面・権限・更新の行ごとに読む方法は「BI・ダッシュボードの構築を外注する費用は、ライセンスより『数字の定義を揃える作業』で決まる」で解説しています。

前提をそろえるには、見積書を工程の行に分けてもらい、行ごとに中身を聞きます。「開発一式」の1行しかない見積もりなら、工程ごとの工数（人日、または1人が1か月働く量を1とする人月）に分けてもらうよう頼みます。分けられないという会社の見積もりは、ほかの会社と並べて比べることができません。

「要件定義」の行：何日で、誰に何を聞く予定か

要件定義は、業務のどこをどうシステムにするかを決める工程です。IPAのモデル契約は、要件を主体的に決めて明確にするのは発注側で、開発会社はその作業を専門家として支援する、という分担をあるべき形としています（IPA「情報システム・モデル取引・契約書」第二版）。見積書のこの行が、開発会社のどんな作業の時間なのかを、次の点で確かめます。

• 打ち合わせは何回で、受注・倉庫・経理など、誰に話を聞く予定か
• 終わったときに何が手元に残るか（業務の流れ図、画面・帳票の一覧、取引先ごとの例外の一覧など）
• 発注側で、決める役を誰が担う前提か

JUASの「ソフトウェア・メトリクス調査2025」では、要件定義は全体の工数の13%でしたが、期間では20%を占めていました。JUASは、要件定義は作業を分担して進めにくいため、期間の比率が大きくなると見ています（JUAS「ソフトウェア・メトリクス調査2025」ガイドブック）。人を増やしても縮みにくい工程なので、ここの日数がほかの会社より極端に少ない見積もりは、聞き取りを省いていないかを確かめます。

「設計・開発」の行：画面の数と、つなぐ先の数に分けてもらう

金額がいちばん大きく動くのはこの行で、中身はおおむね次の3つで決まります。

• 画面と帳票の数：取引先が注文を入れる画面、社内の受注一覧、在庫、出荷、請求データの出力、日報なら入力画面と集計表など。取引先ごとに単価・締め日・品番の呼び方が違うほど、画面の分かれ目や処理が増えます。
• つなぐ先の数と方法：会計ソフト、販売管理、倉庫のシステム、ECサイトなど。システム同士が自動でデータをやり取りするのか、CSVを人が取り込むのか、1日に何回受け渡すのかで工数が変わります。
• 使う人の種類と人数：社内の担当者だけか、取引先もログインするか。役割ごとに見られる画面を分けるなら、その分の設計と確認が要ります。

各社に画面・帳票の一覧とつなぐ先の一覧を出してもらい、1件ごとの工数を並べてもらいます。IPAのモデル契約が示す提案依頼書（RFP）の記載事項でも、依頼の範囲は、範囲の外になる部分まで詳しく示すこととし、業務の中身は業務の流れ図や画面・帳票の一覧などで表すとよいとしています。一覧を並べると、1社は取引先向けの画面を見積もりに入れていない、別の1社は会計ソフトとの連携を手作業のCSVで済ませている、といった範囲の差が見えてきます。

「テスト」と「移行」の行が薄くないか

プログラムを作る行に比べて、テストとデータ移行の行は見落とされやすい行です。JUASの調査では、工数の配分は要件定義15：設計から結合テストまで60：総合テスト25（5刻みに丸めた値）で、総合テストのうち、利用する側が参加して行うユーザー総合テストだけでも工数の13%ありました。調査の対象は従来型の開発が中心ですが、テストは開発の付け足しではなく、仕上げの総合テストだけでも全体の4分の1ほどを占める、という目安にはなります。

IPAのモデル契約が示す提案書の記載事項も、開発のスケジュールに、テストとは別に、移行（移行計画書・データ移行計画）、操作・教育（マニュアル作成など）、発注側の検収を並べ、発注側の担当分も含めて書くことにしています。見積書にこれらの行が無ければ、入っていないのか、ほかの行に含めているのかを聞きます。

とくに差が出やすいのがデータ移行です。Excelや紙の台帳にある取引先・品目・単価・在庫を新しい仕組みに入れるには、重複や表記の揺れを直す作業が要ります。この整理を開発会社が受け持つのか、発注側の作業として見積もりの外に置いているのかで、金額も社内の手間も変わります。発注側の作業は見積書の金額に出てこないので、何人が何日ほど割く前提かも聞いておきます。

「保守」の行：月額に何が含まれ、項目を一つ足すといくらか

システムは作った後も費用がかかります。東京商工会議所が2024年10〜11月に行った調査では、デジタル化にかかる費用の内訳について、新しく入れるシステムの費用より今あるシステムの維持・運営の費用のほうが多いと答えた企業が47.2%でした（主に東京23区の中小企業が対象。この設問は、口頭・電話・帳簿での業務が多いと答えた企業を除く1,002社の集計。東京商工会議所「中小企業のデジタルシフト・DX実態調査」）。初期費用だけで比べると、この部分を見落とします。

保守の行では、月額に含まれる作業と、含まれない作業を分けてもらいます。

• 月額に含まれるか：不具合の調査と修正、問い合わせへの回答、サーバーやOS・部品（ライブラリ）の更新、バックアップ、障害のときに対応する時間帯
• 別料金になるもの：項目を1つ足す、画面や帳票を直す、取引先を増やすといった変更の単価と、見積もりの出し方
• 引き渡しの後、無償で直してもらえる期間と範囲
• 保守をほかの会社や社内に移すとき、プログラムと資料を渡してもらえるか（権利がどちらに残るか）

IPAのモデル契約が示す提案依頼書の記載事項でも、保守の条件として、無償で保守する期間や、時間外の保守の単価と条件などを示すよう挙げています。受発注や在庫の仕組みは、取引先や品目が増えるたびに手を入れることになるため、項目を1つ足すといくらかかるのかは、契約の前に聞いておきたい質問です。

「前提条件」「対象外」の欄と、変更の扱い

見積書の前提条件と対象外の欄（備考欄に書かれていることもあります）は、金額の行と同じ重さで読みます。前提条件に、データは発注側で整えたものを受け取る、テストは発注側で行う、といった記載があれば、その作業は金額に入っていません。

変更の扱いも確かめます。IPAのモデル契約では、工程ごとに、完成を約束する請負か、完成までは約束せず作業を適切に行うことを約束する準委任かを選びます。画面や帳票が決まった後の要件追加や仕様変更は、変更の手続きを通して費用と納期を協議する形です。見積もりが一括の固定額でも、変更が出たときに何を基準に追加費用を決めるのか（単価、手順、誰が承認するか）が書かれているかを見ます。

期間を公開データで確かめる（JUASの標準工期と、その使いどころ）

見積書の期間が妥当かは、JUASが公開している標準工期の式で目安をつけられます。開発に取り組んできた企業へのアンケートで集めた232件の実績から、JUASはプロジェクト全体の工数と期間のあいだに次の関係を求めています（JUAS「ソフトウェア・メトリクス調査2025」ガイドブック）。

標準工期（か月）＝ 3.23 × 全体工数（人月）の立方根

全体工数が8人月なら、8の立方根は2なので、標準工期は約6.5か月です。27人月なら立方根は3で、約9.7か月になります（JUASのガイドブックの例では、125人月で16.15か月）。

同じ調査では、実際にかかった期間は標準工期のおよそ1.08倍で、50人月未満の小さめのプロジェクトでは56%が標準工期を超えていました。また、計画した期間が標準工期より短かった115件は、稼働後の初期対応の段階で見つかった平均欠陥数が11.2で、標準工期以上で計画した109件の5.94を上回っています。JUASは、期間が短いと使い方の検討が浅くなったり、例外への配慮が足りなくなったりするためと見ています。

見積書と照らし合わせるときは、次の順に進めます。

1. 各社に、全体の工数（人月）と、要件定義から稼働後の初期対応までの期間を書いてもらう。期間に含まれる範囲がそろっていないと比べられません。
2. 工数から標準工期を計算し、見積もりの期間と並べる。
3. 見積もりの期間が標準工期よりかなり短ければ、短くできる理由を聞く。既製のサービスを組み合わせる、画面を先に作って確かめながら進める、生成AIで実装を縮める、といった理由はありえます。そのうえで、要件定義やテスト、移行の期間まで一緒に縮めていないかを確かめます。

ただし、JUASのガイドブック自身が、これまで集めたデータの適用範囲は従来のウォーターフォール型の開発が中心で、パッケージやクラウドを使う開発、アジャイル型の開発などについては改めて検討が要るとしています。既製のサービスを設定して使う提案や、画面を先に作りながら進める提案に、この式をそのまま当てはめることはできません。期間を短くした分、どの工程を削ったのかを聞くための物差しとして使います。

生成AIを使う会社の見積もりで確かめること

生成AIで開発するのでほかより安く早い、という説明は、それだけでは妥当とも過大とも言えません。コードを書く作業が速くなることを示した実験はあります。GitHub Copilotを使えるグループは、決められた課題（JavaScriptでHTTPサーバーを作る）を、使えないグループより55.8%速く終えました（Peng ほか、2023年）。一方で、熟練の開発者が、長く関わってきた大規模なオープンソースのプロジェクトで作業した別の実験では、2025年前半の時点で、AIを使うと作業時間が19%延びました（METR、2025年7月）。実施したMETRは2026年2月に、今はもっと速くなっている可能性が高いとしつつ、追加の実験からは信頼できる数字を得られなかったと説明しています（METRの2026年2月の報告）。縮む幅は、作業の中身と時期によって大きく変わるということです。

見積もりの行ではなく開発費の全体で見て、生成AIでどこまで下がりうるかは、工程の比率をもとに「生成AIでシステム開発費はどこまで下がるか」で整理しています。

見積書で見るのは、AIでどの行が縮んだかです。縮みうるのは、決まった仕様をプログラムにする行です。業務を聞き取って例外を決める、実際の注文データで確かめる、台帳を整えて移す、現場や取引先に使い方を伝える、といった行は、発注側の人の時間と判断が要るため、AIを使っても同じようには縮みません。

実装の行が小さいのに、テストや移行の行まで同じ割合で小さくなっている見積もりは、発注側の作業が増える前提になっていないかを確かめます。反対に、実装が速くなった分を、試作を触ってもらう回数や例外の確認に回している見積もりなら、AIの使い方として筋が通っています。

相見積もりを並べる表の作り方

各社の見積書を読んだら、同じ表に書き写して並べます。見積書の書式は会社ごとにばらばらなので、表の行は自社で決めておき、空欄になったところを各社に聞きます。

作り方の違う提案が混ざるときは、同じ年数の総額と、公開した後に直すのは誰かで比べます。既製のサービスやノーコードツールには、利用者1人あたりの月額で料金が決まるものがあり（例：kintoneの料金表）、使う人が増えるほど毎月の費用も増えます。専用に開発する提案は初期費用が大きくなりやすい一方、人数分の利用料がかからない作り方にできます。どの作り方でも、項目を足すときに社内で直せるのか、提供元や開発会社に頼むのかで、使い続ける費用が変わります。

当社は、既製のサービスでは業務に合わず人数分の利用料も重い、一から作る開発では費用と期間がかさむ、という両方の悩みの間を埋める作り方として、生成AI（Claude Code）を使い、画面を先に触っていただきながら業務に合わせたWebアプリを作る開発を提案しています。そのうえで、既製のサービスで足りる業務には、そちらをお勧めしています。

要件が固まる前に見積もりを頼むとき

表を作ってみて空欄が多いときは、前提をそろえて見積もりを頼み直します。予算も要件も決まっていない段階で相談するのは、珍しいことではありません。東京商工会議所の同じ調査では、デジタル化にかかる予算を前年度と比べて尋ねた設問で、「予算は立てていない」と答えた企業が42.6%ありました。段階別の集計で、紙や口頭のやり取りをITに置き換えている段階の企業を見ると、58.2%です（東京商工会議所「中小企業のデジタルシフト・DX実態調査」）。

この段階で取る見積もりは、先の図でいえば試算か概算です。IPAのモデル契約は、発注側が大手企業である取引を主な前提にしていますが、中小企業が使う場合の注意点も解説しています。社内の体制が十分でなく、要件を自社だけで固められない場合は、外部の支援を使うか、企画・要件定義と開発を別の契約にするのが望ましい、というものです（IPA「情報システム・モデル取引・契約書」第二版）。要件定義までを先に頼み、その成果をもとに開発の見積もりを取り直す進め方で、要件定義の成果物があれば、ほかの会社にも同じ条件で見積もりを頼めます。

最初の相談に持っていくと、各社の前提をそろえやすくなるものは次のとおりです。

• 今の業務の流れ：注文を受けてから出荷・請求までを、誰が何を使って進めているか（手書きの図で足ります）
• 現物：FAXの注文書、受注や在庫のExcel、日報の用紙、請求書など（個人情報や単価は伏せて構いません）
• 件数：1か月の注文件数、取引先の数、品目の数、使う人の数
• 例外：取引先ごとに違う単価・締め日・注文の書式・品番の呼び方
• つなぐ先：今使っている会計ソフトや販売管理と、そのうち残したいもの
• 困りごとの順番：いちばん手間のかかっている作業と、いつまでに変えたいか
• 予算の考え方：決まっていなければ、決まっていないと伝える
• 確認に時間を割ける人：試作を触り、例外の扱いを判断できる担当者

決まっていないことは、決まっていないと書いて渡します。空白を各社が別々の想定で埋めると、また前提の違う見積もりが並ぶからです。

見積もりの説明に、自社の業務の話が出てくるか

最後に、各社から見積もりの説明を受けたとき、自社の業務の話がどれだけ出てきたかを振り返ります。東京商工会議所の同じ調査で、ITベンダーを選ぶときに重視することを尋ねた設問（複数回答）では、導入コスト（58.0%）、運用コスト（57.6%）に続いて、「自社の業務フロー・業務課題の正確な把握」が54.5%でした（東京商工会議所「中小企業のデジタルシフト・DX実態調査」）。金額と並んで、業務を分かってもらえているかが選ぶ理由になっています。

取引先ごとの例外や締め日の扱い、FAXで注文してくる取引先が残ったらどうするか、といった質問を返してきた会社は、その答えを前提にして金額を出そうとしています。業務についての質問がないまま出てきた見積もりは、安くても高くても、前提を聞き直してから比べます。

受発注や在庫の仕組み化で、ほかの会社から出ている見積もりや提案書を、作る範囲と前提の面から整理したいときは、Aurant Technologiesの受発注・在庫管理システムの開発のページからご相談いただけます。