システム開発を外注する費用｜規模別の料金相場と見積もりで確認すべき項目

2026年4月5日

朝比奈蒼

この記事のポイント

✓システム開発を外注したい発注者向けに
✓費用相場を規模別・工程別に整理しました
✓失敗しない依頼先の選び方

「システム開発を外注したいけれど、いくらかかるのか見当がつかない」。この記事は、まさにそこで止まっている発注者のために書いています。先に結論だけ言うと、業務システムなら300万円から1,000万円、Webシステムなら200万円から800万円、スマホアプリなら100万円から2,000万円、基幹システムの刷新なら1,000万円以上が一般的な相場です。この幅の広さこそが、相場を分かりにくくしている最大の原因です。

金額がここまで開くのは、システム開発の価格が「モノの値段」ではなく「どんな役割の人が、何人で、何ヶ月動くか」で決まるからです。逆に言えば、この計算式さえ理解すれば、提示された見積もりが高いのか安いのか、どこを削れば予算に収まるのかを、発注者自身が判断できるようになります。

この記事では、まずシステム種別ごとの費用相場を一覧で示し、次にその金額がどう積み上がっているのかを人月単価と工数に分解します。そのうえで、外注先の類型ごとの費用感の違い、要件定義から検収までの進め方、見積書で必ず確認する項目、相見積もりを取るときの依頼文の骨子、契約形態による費用リスクの違い、そして費用を抑える具体策までを、すべて発注する側の視点で整理します。読み終えるころには、「自分の案件はいくらで、どこに、どう頼めばいいか」の判断材料が一通りそろっているはずです。

システム開発を外注する費用相場【システム種別の早見表】

まず、発注者が最初に知りたい「いくらかかるのか」に答えます。以下は、システムの種類ごとの費用相場と、そこにかかる期間・体制の目安です。要件次第で上下しますが、予算感をつかむ出発点として使ってください。

システムの種類	費用相場	開発期間の目安	想定チーム規模
業務システム（勤怠、在庫、顧客管理など）	300万円から1,000万円	3ヶ月から6ヶ月	3名から5名
単機能ツール（フォーム、予約、集計など）	50万円から300万円	1ヶ月から3ヶ月	1名から2名
Webシステム（会員機能や決済を含む）	200万円から800万円	3ヶ月から6ヶ月	3名から5名
スマホアプリ（情報表示・通知中心）	100万円から300万円	2ヶ月から4ヶ月	2名から3名
スマホアプリ（SNS機能や決済を伴う）	500万円から2,000万円	6ヶ月から12ヶ月	5名以上
ECサイト（既製プラットフォーム利用）	50万円から100万円	1ヶ月から2ヶ月	1名から2名
ECサイト（フルスクラッチ）	300万円から1,000万円以上	4ヶ月から8ヶ月	4名以上
受発注システム（EDI連携を含む）	400万円から1,500万円	4ヶ月から10ヶ月	4名から8名
基幹システムの刷新（ERP相当）	1,000万円から数千万円以上	8ヶ月から18ヶ月	10名以上
既存システムの改修・機能追加	30万円から300万円	2週間から2ヶ月	1名から3名

この表を見ると、同じ「システム開発」でも桁が2つ違うことが分かります。ここで発注者が誤解しやすいのは、「安い相場の会社を探せば安く作れる」という発想です。実際には、金額を決めているのは会社ではなく、作るものの中身です。次のセクションで、この金額がどう組み立てられているのかを分解します。

費用は「人月単価 × 工数」の掛け算で決まる

システム開発の見積もりでほぼ必ず登場するのが「人月（にんげつ）」という単位です。これは「エンジニア1人が1ヶ月フルタイムで働く作業量」を1人月と数える考え方で、費用は「人月単価 × 必要人月数」で計算されます。たとえば人月単価が80万円のエンジニアが3ヶ月作業すれば、その人の工数だけで240万円という具合です。

システム開発費用の大半を占めるのは、機材でもソフトウェアのライセンスでもなく、人件費です。参考として、開発会社の解説では次のように説明されています。

システム開発費用の大半を占めるのが人件費です。一般的に、全体の約8割を占めるともいわれています。開発する規模にもよりますが、システム開発は1人のエンジニアだけでできるものではありません。プロジェクト全体の舵取りを行うプロジェクト・マネージャー（PM）や、その手助けをするプロジェクト・マネジメント・オフィス（PMO）などの管理系人員、さらには実際に手を動かしてシステムを作り上げるシステム・エンジニア（SE）や、プログラマー（PG）がチームを組むことによってプロジェクトを進められます。そのため、システム開発の費用において、人件費が大半を占めます。

つまり、発注者が払っているお金の8割は「人が動いた時間」です。この構造を押さえると、見積書に並ぶ金額が急に読めるようになります。逆に言えば、費用を抑える方法も「関わる人数を減らす」「期間を短くする」「単価の高い管理層を薄くする」という3方向に集約されます。安く済ませたいなら、まずこの3つのレバーのどれを引けるかを考えるのが近道です。

役割ごとの人月単価の目安（発注者が払う金額）

人月単価は担当者のスキルや役割で変わります。ここで示すのは、発注者が開発会社に支払う金額の水準であり、エンジニア本人の手取りではありません。間に会社が入るほど、支払額と本人の報酬の差は開きます。

役割	主な担当工程	人月単価の目安	発注者から見た位置づけ
ITコンサルタント・上流担当	企画、業務分析、RFP支援	120万円から200万円	要件が固まっていない段階で入る。ここを削ると後工程で手戻りが増える
プロジェクトマネージャー（PM）	進行管理、品質管理、折衝	80万円から160万円	大規模ほど必須。小規模なら兼任で薄くできる
システムエンジニア（SE）	要件定義、基本設計、詳細設計	60万円から100万円	設計品質を決める中核。ここが薄い見積もりは危険
プログラマー（PG）	実装、単体テスト	40万円から80万円	人数と期間がそのまま金額に直結する
テスター・QA	結合テスト、総合テスト	40万円から70万円	削ると納品後の不具合修正費で跳ね返る
インフラエンジニア	サーバー構築、運用設計	60万円から110万円	クラウド利用で圧縮しやすい

ここで重要なのは、「人月単価が高い＝ぼったくり」ではないという点です。上流工程を担える人が多く関わるほど単価は上がりますが、その分だけ要件定義の精度や進行管理の質も上がります。発注者が見るべきなのは単価の絶対値ではなく、「その単価の人が、何人月分、どの工程に投入されているか」の妥当性です。

たとえば、社内5人が使う簡易な在庫管理ツールに、単価160万円のPMが3人月分計上されていれば過剰です。逆に、10部署が関わる基幹システムの刷新でPMがゼロなら、進行が破綻して結局は追加費用が出ます。単価表は、削る場所と削ってはいけない場所を見分けるための道具として使ってください。

オフショア・国内フリーランスとの単価差

同じ工程を担ってもらう場合でも、どこに発注するかで単価は大きく変わります。発注者から見た支払額の水準を並べると、次のようになります。

発注先	PG相当の人月単価	SE相当の人月単価	支払額に含まれるもの
大手SIer	80万円から120万円	100万円から160万円	実作業費、管理費、下請けのマージン、品質保証体制
中堅・中小の開発会社	50万円から90万円	70万円から110万円	実作業費、管理費、社内の間接費
オフショア（東南アジア）	25万円から50万円	40万円から70万円	実作業費、ブリッジSE費、通訳・翻訳コスト
オフショア（ニアショア含む国内地方）	40万円から70万円	60万円から90万円	実作業費、管理費
国内フリーランスへ直接依頼	40万円から80万円	60万円から100万円	実作業費のみ（管理は発注者側が負担）
フリーランスをエージェント経由で調達	55万円から100万円	75万円から120万円	実作業費、エージェント手数料（おおむね20%から35%）

この表で発注者が注目すべきは、右端の「支払額に含まれるもの」の列です。オフショアの単価が低いのは技術力が低いからではなく、人件費水準の違いによるものですが、そのかわりに仕様書の翻訳、時差を挟んだやり取り、認識ズレの手戻りといった見えないコストが発生します。実務では、単価差ほどには総額が下がらないケースが多いのが実情です。

一方、国内フリーランスへの直接依頼は、エージェント手数料や元請けのマージンが乗らない分、支払額を素直に圧縮できます。そのかわり、進行管理と品質確認は発注者側が担うことになります。つまり価格差の正体は「自社でどこまで面倒を見るか」の差です。この点を理解せずに「安いほうがいい」と選ぶと、社内工数という別のコストで支払うことになります。

なぜ同じ機能でも見積もりが2倍違うのか

複数社に相見積もりを取ると、金額が2倍以上開くことは珍しくありません。この差は主に4つの要因から生まれます。1つ目は開発体制の規模で、大手SIerは中間マージンや管理費が乗るため、同じものでもフリーランスや小規模開発会社の1.5倍から2倍になることがあります。2つ目は要件の解釈差で、片方は「最低限動くもの」を、もう片方は「拡張性や保守性まで考慮したもの」を想定していると、当然工数が変わります。

3つ目は使用する技術や開発手法の違い、4つ目はテスト・ドキュメント・保守までを見積もりに含めているかどうかです。だからこそ、金額だけを横並びで比較するのは危険です。安い見積もりは「何が含まれていないか」を、高い見積もりは「何に手厚くコストをかけているか」を必ず確認してください。同じ土俵で比べられていない見積もりを比較しても、判断を誤るだけです。

【規模別】システム開発の費用相場と発注時の勘所

早見表で全体像をつかんだところで、規模ごとにもう少し踏み込みます。参考として、小規模チームで稼働する場合の月額の目安について、開発会社の解説では次のように述べられています。

システム開発費用の相場は、工程や開発するシステムによって異なります。下記は小規模なチーム体制（エンジニア複数名）で稼働する場合の月々の料金目安となります。

小規模開発（300万円まで）：単機能ツール・簡易システム

問い合わせフォーム、予約管理、在庫管理といった「特定の業務を1つ効率化する」レベルのシステムは、おおむね50万円から300万円が相場です。既存のテンプレートやフレームワークを活用でき、関わる人数も1名から2名、期間も1ヶ月から3ヶ月程度で済むケースが多いためです。

このレンジは、個人事業主や中小企業が「まず1つ、手作業を自動化したい」というときに最も現実的な選択肢になります。たとえば、Excelで管理していた顧客リストをWebで検索・編集できるようにする、といった案件です。注意点として、この価格帯では「作って終わり」になりがちで、後からの機能追加や保守が別料金になることが多い。最初の見積もり段階で「追加改修の単価」「納品後の不具合対応の範囲」を確認しておくと、後々のトラブルを避けられます。小規模だからこそ、フリーランスや個人開発者への直接依頼が費用対効果で有利になりやすい領域でもあります。

中規模開発（300万円から1,000万円）：業務システム・BtoB向けサービス

複数の業務を横断的に管理する業務システム、会員機能や決済を備えたWebサービス、社内の複数部署が使う管理システムなどは300万円から1,000万円が目安です。要件定義から設計、開発、テストまで一通りの工程が必要になり、PM・SE・PGでチームを組んで3ヶ月から6ヶ月ほどかけて開発します。

この規模になると、要件定義の巧拙が総費用を大きく左右します。「あれもこれも」と機能を盛り込むと、あっという間に1,000万円を超えます。逆に、最初のリリースでは必要最小限の機能に絞り、使いながら育てていく「スモールスタート」を選べば、初期費用を数百万円単位で圧縮できます。正直なところ、最初から完璧なシステムを一発で作ろうとする発注者ほど、予算オーバーと納期遅延に苦しむ傾向があります。まず小さく作って検証する、という発想が費用面でも品質面でも合理的です。

大規模開発（1,000万円以上）：基幹システム・大規模Webサービス

全社の業務を統合する基幹システム（ERP）、多数のユーザーが同時アクセスする大規模Webサービス、金融・医療など高い信頼性が求められるシステムは1,000万円を超え、数千万円から億単位になることもあります。多人数のチームで半年から1年以上かけて開発するため、人件費の総額が跳ね上がります。

この規模では、費用管理そのものがプロジェクトの成否を分けます。要件変更が1つ入るだけで数百万円動くこともあるため、契約形態（後述の請負か準委任か）や変更管理のルールを事前に詰めておくことが不可欠です。中小企業がいきなりこの規模に挑むケースは多くありませんが、事業の中核を担うシステムを刷新するような場面では避けて通れません。大規模案件こそ、見積もりの内訳を工程単位で分解し、どこにいくらかかっているかを発注者側が把握しておく必要があります。

スマホアプリ・ECサイトの費用感

Webシステムとは別に、需要が多いスマホアプリとECサイトの相場も押さえておきましょう。スマホアプリは、シンプルな情報表示・通知系のアプリで100万円から300万円、SNS機能や決済を伴う本格的なアプリで500万円から2,000万円が目安です。iOSとAndroidの両対応にすると、単純計算で工数が増える点にも注意が必要です。発注者としては、初期リリースを片方のOSに絞る、あるいは1つのソースコードで両OSに対応できる開発手法を提案してもらうことで、初期費用を圧縮できます。

ECサイトは、既製のプラットフォームを使えば50万円から100万円程度、独自機能を作り込むフルスクラッチだと300万円から1,000万円以上になります。ここでの発注者側の判断ポイントは、「本当にフルスクラッチが必要か」です。既製サービスで実現できる要件をわざわざゼロから作ると、初期費用も保守費用も膨らみます。標準機能で足りるなら既製を、独自の業務フローが競争力の源泉なら作り込みを、と切り分けるのが賢い予算配分です。

受発注システム・基幹システム刷新の費用感

取引先との受発注をシステム化したい、というニーズも増えています。自社の発注担当者が使う画面だけを作るのであれば400万円から700万円程度で収まることが多い一方、取引先ごとに異なるデータ形式へ変換して連携する仕組み（いわゆるEDI連携）まで含めると、800万円から1,500万円規模になります。取引先の数と、それぞれのデータ形式のばらつきが、そのまま工数に跳ね返るためです。

基幹システムの刷新は、費用構造がさらに特殊です。新規開発と違い、既存システムの調査（現行の仕様を読み解く作業）、データ移行、旧システムとの並行稼働という3つの追加工程が発生します。この3つで全体の3割前後を占めることも珍しくありません。刷新を検討する段階で、既存システムの設計書が残っているか、開発した会社と連絡が取れるかを確認しておくと、調査工程の費用を抑えられます。ドキュメントが一切残っていない場合、調査だけで数百万円かかることもあります。

システム開発の外注先はどこがいいか【5類型の比較】

「システム開発外注」と調べている段階の発注者にとって、金額の次に大きな問いが「どこに頼むか」です。外注先はおおまかに5つの類型に分かれ、それぞれ費用感と得意分野が異なります。

外注先の類型	費用水準	得意な案件	発注者の負担	注意点
大手SIer	高い	大規模、基幹系、高い信頼性が必要な案件	小さい	下請け構造でマージンが積み上がる。小規模案件は受けてもらえないことも
中堅・中小の開発会社	中程度	業務システム、Webサービス全般	中程度	得意技術の幅に会社差が大きい。実績分野の確認が必須
オフショア開発会社	低い	仕様が明確な大量実装、保守運用	大きい	仕様書の精度が品質を左右する。時差と言語の壁
フリーランス・個人開発者	低い	小規模から中規模、改修、特定技術のスポット	大きい	稼働可能量に上限がある。進行管理は発注者側
ラボ型（専任チームの月額契約）	中程度	要件が動く継続開発、内製化の橋渡し	中程度	成果物ではなく稼働に払う。目的が曖昧だと空回りする

大手SIerに頼むべきケース

全社の基幹業務を止められない、監査対応が必要、関わる部署が多いといった案件では、大手SIerの体制が生きます。要件定義から運用保守までを一社で引き受け、担当者が変わっても引き継げる仕組みを持っているためです。そのかわり、費用は他の選択肢の1.5倍から2倍を見ておく必要があります。

発注者が意識すべきは、支払額のうちどれだけが実作業に使われているかです。大手に発注した案件が二次請け、三次請けへ流れる構造は珍しくなく、各層で管理費が乗ります。契約前に「実際に手を動かすのはどこの会社か」「再委託の範囲はどうなっているか」を確認しておくと、費用の妥当性を判断しやすくなります。

中堅・中小の開発会社に頼むべきケース

300万円から1,000万円規模の業務システムは、この層が最も競争力を持つ領域です。社内にPMとSEを抱えつつ、大手ほどの間接費がかからないため、価格と体制のバランスが取りやすいのが理由です。

選定で見るべきは、会社の規模ではなく実績分野の一致です。同じ「業務システムが得意」でも、製造業の生産管理に強い会社と、小売業の在庫管理に強い会社では、要件定義の勘所がまったく違います。自社と近い業種・業務の開発実績があるかを、提案依頼の段階で必ず聞いてください。業務理解がある会社は要件定義が速く、それがそのまま費用の圧縮になります。

オフショア開発を選ぶべきケース

仕様が固まっていて、実装量が多い案件では、オフショアの単価差が効きます。一方、要件が曖昧なまま丸投げすると、認識ズレの手戻りで単価差が吹き飛びます。オフショアが向くのは「何を作るかが決まっていて、作る量が多い」案件だと理解してください。

費用面で見落としがちなのが、日本語と現地語の橋渡しをする担当者（ブリッジSE）の費用です。この人の単価は現地エンジニアより高く、月額で数十万円が上乗せされます。小規模案件でオフショアを使うと、この固定費の比率が高くなり、結果的に国内発注と変わらない総額になることがあります。

フリーランス・個人開発者へ直接依頼するケース

小規模から中規模の案件、既存システムの改修、特定技術のスポット対応では、フリーランスへの直接依頼が費用対効果で有利になります。中間マージンが発生しないため、同じ実力のエンジニアを、会社経由より低い支払額で確保できるからです。

発注者側の条件は、仕様を自分の言葉で説明でき、進捗を定期的に確認できることです。フリーランスは1人で動くため、進行管理まで期待すると負荷が偏ります。逆に、社内に業務を理解した窓口担当者がいるなら、この形態は非常に相性がいい。実際にどんなエンジニアに依頼できるのかは、Web・業務システム開発のお仕事で、Webシステムや業務システムの開発を担う人材の業務範囲を確認できます。AI活用やマーケティング連携まで含めた開発を検討しているなら、AI・マーケティング・セキュリティのお仕事も参考になります。

ラボ型（専任チームの月額契約）を選ぶケース

ラボ型は、特定のエンジニアやチームを月額で一定期間おさえ、その稼働時間を買う契約形態です。費用は「1人あたり月額 × 人数 × 契約月数」で、成果物の完成ではなく稼働に対して支払います。要件が走りながら変わる継続開発や、将来的な内製化に向けて自社に知見をためたい場合に向いています。

注意点は、目的が曖昧なまま契約すると「毎月お金は出ていくが、何が進んだのか分からない」状態になりやすいことです。ラボ型を選ぶなら、月次で何を達成するかを発注者側が決められる体制が前提になります。裏を返せば、その体制が作れるなら、都度見積もりを取り直す請負より総額を抑えやすい形態でもあります。

システム開発を外注する流れ【要件整理から検収まで】

「どこに頼むか」が決まっても、進め方が分からなければ費用は膨らみます。ここでは、発注者が実際にたどる工程を、お金が動くタイミングとあわせて整理します。

ステップ1：社内の課題を言語化する（費用ゼロ、ただし最重要）

最初にやるのは、開発会社への相談ではなく、社内での言語化です。「今どんな業務を、誰が、どれだけの時間をかけてやっているか」「それによって何が起きているか」「システム化で何を減らしたいか」を書き出します。ここが曖昧なまま相談に行くと、開発会社は不確実性を織り込んで高めに見積もらざるを得ません。

この工程に社内で1週間かけるだけで、後の要件定義費用が数十万円単位で変わります。費用がかからないのに効果が最も大きい工程が、ここです。

ステップ2：RFP（提案依頼書）を作って相見積もりを取る

複数社を同じ土俵で比較するには、各社に同じ情報を渡す必要があります。そのための文書がRFP（提案依頼書）です。立派な体裁は不要で、A4で3枚から5枚あれば十分機能します。骨子は次の通りです。

・依頼の背景と目的：どんな業務課題を解決したいのか。システム化のゴールを1行で書く・対象範囲：どの業務、どの部署、何人が使うのか。対象外の範囲も明記する・必須機能とあったら嬉しい機能：優先度をAとBに分けて列挙する。ここを分けるだけで見積もりの精度が上がる・現行の業務フロー：今どうやっているか。図でなくても箇条書きで足りる・想定利用者数と想定データ量：同時に何人が使い、年間どれだけデータが増えるか・既存システムとの連携要否：連携先の名称と、連携したいデータの種類・予算のレンジと希望納期：上限額を伝えることを恐れない。伝えないほうが工数が読めず高くなる・提案してほしい内容：工程別の工数と単価、体制図、想定スケジュール、保守運用の条件・回答期限と選定スケジュール：いつまでに提案がほしく、いつ発注先を決めるか

特に効果が大きいのが、予算のレンジを開示することです。「予算を言うと足元を見られる」と考える発注者は多いのですが、実際には逆で、予算が分からないと開発会社は安全側に振って高く見積もります。上限を伝えたうえで「この範囲で何ができるか提案してほしい」と依頼するほうが、現実的な提案が集まります。

相見積もりは3社程度が適量です。多すぎると比較の手間が増え、少なすぎると相場観がつかめません。

ステップ3：提案を比較して発注先を決める（この時点ではまだ費用は発生しない）

各社の提案がそろったら、金額の高低ではなく、工程別の工数配分と体制を比べます。同じ機能で工数が倍違うなら、その理由を必ず質問してください。多くの場合、含まれている範囲が違うか、想定している品質水準が違うかのどちらかです。

ステップ4：要件定義（全体費用の1割前後）

発注先が決まったら、何を作るかを文書に落とし込む工程に入ります。ここで作られる要件定義書が、以降のすべての基準になります。発注者が最も時間を投じるべき工程であり、ここでの決定漏れが後の追加費用を生みます。

大規模案件では、要件定義だけを先に別契約（準委任）で発注し、その成果物をもとに開発を請負契約で見積もり直す進め方もあります。要件が固まっていない段階で全体を一括見積もりさせると、不確実性の分だけ上乗せされるためです。

ステップ5：設計、開発、テスト（全体費用の8割）

要件定義書をもとに、画面や処理の設計を行い、実装し、テストします。発注者の関与が薄くなりがちな期間ですが、ここで放置すると検収時に「思っていたものと違う」という最悪の事態が起きます。2週間に1度は動くものを見せてもらう約束を、契約時に取り付けておいてください。

ステップ6：検収と稼働（全体費用の1割前後）

完成したシステムが要件定義書の通りに動くかを確認し、問題がなければ検収します。検収書に押印すると、そこから先の修正は原則として有償になります。検収前に確認すべきは、要件定義書の全項目が満たされているか、想定データ量で動作が耐えられるか、マニュアルやドキュメントが納品されているか、ソースコードの引き渡し条件はどうなっているかの4点です。

支払いは、契約時に着手金として3割から5割、検収後に残額、という分割が一般的です。全額前払いを求められた場合は、その理由を確認してください。

システム開発費用の内訳と算出方法

見積書を受け取ったとき、総額だけを見ていては妥当性を判断できません。内訳を工程ごとに分解して見る習慣をつけると、「どこにコストがかかっているか」「削れる余地はどこか」が見えてきます。システム開発費用は大きく「初期費用（開発費）」と「ランニング費用（保守・運用費）」に分かれます。

工程別の費用配分の目安

一般的なシステム開発は、要件定義、設計、開発（プログラミング）、テスト、導入・リリースという工程で進みます。総額500万円の案件を例に、費用配分の目安を金額に落とすと次の通りです。

工程	全体に占める割合	総額500万円での金額	発注者の関与度	削減余地
要件定義	10%前後	50万円前後	非常に高い	事前準備で圧縮できるが、削りすぎは危険
基本設計・詳細設計	20%前後	100万円前後	高い	機能を減らせば直接減る
開発（実装）	40%前後	200万円前後	低い	機能数と作り込みの深さで決まる
テスト	20%前後	100万円前後	中程度	削ると納品後の修正費で跳ね返る
導入・移行・その他	10%前後	50万円前後	高い	社内作業に振り替えれば圧縮できる

ここで見落としがちなのが要件定義とテストの重要性です。発注者からすると「開発（プログラミング）にお金を払っている」感覚になりがちですが、実際には要件定義の精度がプロジェクト全体の品質と費用を決めます。要件が曖昧なまま開発に進むと、後工程での手戻りが発生し、結果的に総費用が膨らみます。テスト工程を削る見積もりも要注意で、テストが薄いシステムは納品後に不具合が噴出し、その修正費用が別途かかることになります。工程別の内訳を見て、要件定義とテストが極端に薄い見積もりは、むしろ警戒したほうがいいでしょう。

ランニング費用（保守・運用費）を見落とさない

システムは作って終わりではありません。サーバー代、ドメイン代、外部サービスの利用料、そして不具合対応や機能改善を行う保守費用が、稼働後も継続的にかかります。保守費用の相場は、一般的に初期開発費用の5%から15%を年額で見ておくのが目安です。開発費が500万円なら、年間25万円から75万円程度の保守費が発生する計算です。

保守契約の中身も、金額によって範囲が変わります。おおまかな目安は次の通りです。

保守の水準	年額の目安（開発費500万円の場合）	含まれる内容
最低限（不具合対応のみ）	25万円前後（初期費の5%）	障害発生時の調査と修正。平日日中のみ対応
標準（監視と軽微な改修を含む）	50万円前後（初期費の10%）	稼働監視、バックアップ確認、軽微な修正、問い合わせ対応
手厚い（改善提案と定期改修を含む）	75万円以上（初期費の15%以上）	上記に加え、月次の定例会、小規模な機能追加枠、24時間対応

これとは別に、サーバーやクラウドの利用料が月額数千円から数万円、外部サービスの従量課金がかかります。5年間使うシステムなら、初期費用と同額程度のランニング費用が積み上がる計算になることを、最初の予算計画に織り込んでください。

この保守費用を見積もり段階で確認せず、初期費用の安さだけで契約すると、後から想定外の出費に直面します。「納品後の保守は含まれるのか」「含まれる場合、どこまでの対応が範囲か」「別料金ならいくらか」を必ず確認してください。特に、開発を請け負った会社としか保守できない設計になっていると、足元を見られて保守費が高止まりするリスクもあります。ドキュメントの整備状況やソースコードの引き渡し条件も、長期的なコストに直結する確認項目です。

費用を自分で概算する簡易な方法

厳密な見積もりは開発会社に依頼するとして、発注前に自分でざっくり概算する方法を知っておくと、提示された金額が妥当かどうかの感覚がつかめます。最もシンプルなのは、前述の「人月」で概算する方法です。作りたい機能を洗い出し、それぞれに必要な作業量を人月で見積もり、想定単価を掛けます。

たとえば「要件定義に0.5人月、設計に1人月、開発に3人月、テストに1.5人月」で合計6人月、平均単価を70万円とすれば、概算で420万円という具合です。もちろん実際の見積もりはもっと精緻ですが、この概算を持っておくだけで、極端に高い・安い見積もりに気づけます。機能を減らせば人月が減り、費用も下がる。この関係を体感できるのが人月概算の効用です。予算が限られているなら、「どの機能を削れば何人月減るか」を開発会社と一緒に検討すると、現実的な着地点が見えてきます。

見積書で必ず確認する項目チェックリスト

複数社から見積もりを受け取ったら、金額の高低ではなく、次の観点で中身を精査してください。発注者が見積書を「読める」ようになることが、適正価格で発注する最短ルートです。まず、契約前に必ず確認する項目を一覧にしておきます。

・工程ごとに工数（人月）と単価が明記されているか。「一式」表記になっていないか・要件定義書に書いた必須機能が、すべて見積もりの対象に入っているか・テスト工程（単体、結合、総合）が含まれ、どこまでのテストを行うかが書かれているか・納品物の一覧があるか（ソースコード、設計書、操作マニュアル、テスト結果）・ソースコードの著作権と利用権が、どちらに帰属するか・納品後の不具合対応（契約不適合責任）の期間と範囲・仕様変更が発生した場合の追加費用の算定方法と、その単価・保守運用費が別建てか込みか。別建てならその年額と対応範囲・サーバーやクラウド、外部サービスの利用料が誰の負担か・契約形態が請負か準委任か。検収の基準は何か・支払い条件（着手金の比率、支払いタイミング）・再委託の有無と、実際に作業する会社・見積もりの有効期限と、前提条件の記載

この13項目のうち1つでも空欄や曖昧な表現があれば、契約前に文書で回答をもらってください。口頭の合意は、費用トラブルになったときに何の役にも立ちません。

チェック1：内訳が工程ごとに分解されているか

まず見るべきは、見積もりが「一式」でまとめられていないかです。「システム開発一式 500万円」のような大雑把な見積もりは、内訳がブラックボックスで、妥当性を判断できません。信頼できる見積もりは、要件定義・設計・開発・テスト・保守といった工程ごとに、工数（人月）と単価が明記されています。

内訳が分解されていれば、「なぜこの工程にこれだけかかるのか」を質問でき、交渉の余地も生まれます。逆に、内訳の開示を渋る開発会社は、その時点で警戒対象です。発注者として「工程別の内訳と、各工程の人月・単価を出してほしい」と依頼するのは正当な要求であり、これに誠実に応じるかどうかで、その会社の姿勢も見えてきます。

チェック2：要件と見積もりが一致しているか

安い見積もりには、たいてい理由があります。多いのが、テスト工程やドキュメント作成、保守対応が見積もりから抜けているパターンです。目先の金額が安くても、後から「それは別料金です」と追加請求されれば、結局は高くつきます。見積書を受け取ったら、自分が依頼したい要件がすべて含まれているかを1つずつ照合してください。

特に確認すべきは、テスト範囲、納品後の不具合対応期間（契約不適合責任の範囲）、ドキュメントの納品有無、ソースコードの著作権の帰属です。これらが曖昧なまま契約すると、後々トラブルの火種になります。複数社を比較する際は、各社に同じ要件定義書やRFPを渡し、同じ前提で見積もってもらうことで、初めてフェアな比較ができます。

チェック3：契約形態（請負か準委任か）で費用リスクが変わる

システム開発の契約には主に「請負契約」と「準委任契約」があり、どちらを選ぶかで費用とリスクの構造が変わります。発注者から見た違いを整理すると次の通りです。

比較項目	請負契約	準委任契約
支払う対象	成果物の完成	作業（稼働時間）の提供
費用の変動	原則固定。変更のたびに追加見積もり	稼働量に応じて変動する
完成責任	受注側が負う	負わない（善管注意義務のみ）
向いている状況	要件が固まっている	要件が走りながら変わる
発注者の負担	小さい（ただし要件変更が高くつく）	大きい（方向づけを発注者が担う）
費用リスク	見積もり時に上振れ分が上乗せされやすい	期間が伸びるとそのまま総額が伸びる
検収の基準	要件定義書との一致	稼働報告書の確認

発注者としては、要件がかっちり決まっているなら請負、走りながら固めたいなら準委任、と使い分けるのが基本です。実務でよく使われるのは、要件定義フェーズだけを準委任で契約し、要件が固まった時点で開発フェーズを請負で契約し直す組み合わせです。この分け方は、不確実な段階で一括見積もりさせることによる上乗せを防げるため、費用の観点でも合理的です。

契約形態を理解せずに進めると、「変更が有料だと知らなかった」「作業しただけで成果物が中途半端」といったミスマッチが起きます。契約書を交わす前に、自分がどちらの契約で、何に対してお金を払っているのかを説明できる状態にしておいてください。

チェック4：担当者の受け答えが具体的か

最後は、金額の話から少し離れますが、極めて重要なポイントです。見積もりの質は、担当者の質と相関します。要件についての質問に曖昧な返答しかできない、こちらの業務を理解しようとしない、専門用語で煙に巻く、といった担当者が出す見積もりは、後々の認識ズレを生みやすい。

逆に、「その機能は本当に必要ですか」「この部分は既製サービスで代替できます」と、発注者の予算を守る提案をしてくれる担当者は信頼できます。安く見せるために必要な工程を削る会社より、必要なものと不要なものを正直に切り分けてくれる会社を選ぶべきです。見積もりの数字だけでなく、そこに至るまでのやり取りの誠実さを、選定の判断材料に加えてください。

追加費用が発生しやすい典型ポイント

予算オーバーの多くは、契約時に見えていなかった費用から生まれます。よくあるパターンを、事前に潰せる形で整理します。

追加費用が出る場面	金額のインパクト	事前に潰す方法
開発開始後の機能追加・仕様変更	大きい。数十万円から数百万円	必須機能と希望機能を契約前にAとBで分ける
画面デザインの作り直し	中程度。数十万円	開発着手前に画面イメージを合意し、修正回数の上限を決める
既存システムとのデータ連携	大きい	連携先の仕様書を事前に入手し、見積もり範囲に含める
過去データの移行	中程度から大きい	データ件数と形式を早期に共有し、移行の要否を明確にする
想定を超える利用者数・データ量	大きい	想定値をRFPに数字で書く
操作マニュアル・研修の作成	中程度	納品物の一覧に含まれているかを確認する
検収後に見つかった不具合	契約次第	契約不適合責任の期間と範囲を契約書で確認する
セキュリティ診断・脆弱性対応	中程度	必要かどうかを要件定義で判断し、必要なら最初から入れる
サーバーやライセンスの費用	小さいが継続的	誰の名義で契約し、誰が払うのかを決めておく
開発会社の担当者交代による引き継ぎ	見えにくい	体制図と、キーパーソンの稼働率を契約時に確認する

このうち発注者側で最も防ぎやすいのが、上から3つです。要件を固め、画面イメージを先に合意し、連携先の仕様を事前に渡す。この3つを準備するだけで、追加費用の大半は回避できます。

システム開発の費用が高くなる原因

「見積もりが予想より高い」と感じたとき、その原因を理解しておくと、削減の交渉や仕様の見直しがしやすくなります。費用が高騰する原因は、発注者側に起因するものと、案件の性質に起因するものがあります。

要件が固まっていない・途中で変わる

費用が膨らむ最大の原因は、要件の曖昧さと途中変更です。発注時点で「何を作りたいか」が固まっていないと、開発会社は不確実性を織り込んで高めに見積もらざるを得ません。さらに開発が始まってから「やっぱりこの機能も」と追加すると、設計のやり直しや手戻りが発生し、追加費用が積み上がります。

正直なところ、システム開発のコストトラブルの多くは、この要件変更から生まれます。発注者側で「絶対に必要な機能」と「あったら嬉しい機能」を事前に切り分け、優先順位をつけておくだけで、無駄な出費をかなり抑えられます。要件が固まらないまま見積もりを急がせるより、社内で「このシステムで何を解決したいのか」を言語化する時間を取るほうが、結果的に安く済みます。

過剰な品質・オーバースペック

「せっかく作るなら、あらゆるケースに対応できるものを」という発想は、費用を跳ね上げる典型です。想定するユーザー数が数十人なのに数万人規模の同時アクセスに耐える設計にする、使うか分からない機能まで先に作り込む、といったオーバースペックは、そのまま人件費に跳ね返ります。

必要な品質レベルは、システムの用途によって決めるべきです。社内の数人が使うツールと、不特定多数の顧客が使う決済システムでは、求められる堅牢性がまったく違います。過剰品質を避けるには、「このシステムは誰が、何人、どう使うのか」を明確にし、それに見合った品質で発注することです。開発会社に「最高品質で」と丸投げすると、当然コストは最大化します。

発注先の体制と中間マージン

同じ機能でも、どこに頼むかで費用は大きく変わります。大手SIerに一次請けとして発注すると、その下に二次請け・三次請けと下請け構造が連なり、各層でマージンが乗ります。最終的に手を動かすエンジニアの人月単価が同じでも、間に入る会社が多いほど発注者の支払額は増えるのです。

ここに、発注者が費用を抑える大きな余地があります。仲介会社や元請けを介さず、実際に開発するフリーランスや小規模チームへ直接依頼すれば、中間マージンが発生しない分、同じ品質でも支払額を抑えられます。小規模から中規模の案件であれば、この直接依頼のメリットは特に大きく、大手経由の見積もりから数割安くなることも珍しくありません。もちろん、直接依頼には発注者側の管理負荷やパートナー選定の目利きが求められますが、コスト面のインパクトは無視できません。

システム開発費用を抑える実践的な方法

ここまでの内容を踏まえ、発注者が実際に費用を抑えるための具体策を整理します。やみくもに値引き交渉をするのではなく、費用の構造に沿って合理的に削るのがポイントです。

要件に優先順位をつけてスモールスタートする

最も効果的なのは、機能を絞って小さく始めることです。前述の通り、費用は機能の数と工数に比例します。最初のリリースでは「これがないと業務が回らない」という必須機能だけに絞り、「あると便利」な機能は後回しにする。この判断だけで、初期費用を大幅に圧縮できます。

システムは実際に使ってみて初めて「本当に必要な機能」が見えてきます。使うか分からない機能を先に作り込むより、最小構成でリリースし、現場のフィードバックを見ながら育てるほうが、無駄な開発費を払わずに済みます。開発会社に「予算内で優先度の高い機能から実装したい」と伝え、機能ごとの工数を出してもらえば、予算と要件の折り合いをつけやすくなります。

フェーズを分割して発注する

1,000万円の案件を一括で発注するのと、300万円のフェーズ1、400万円のフェーズ2、300万円のフェーズ3に分けて発注するのとでは、費用リスクがまったく違います。分割発注の利点は3つあります。

1つ目は、フェーズ1の成果を見てから続きを判断できることです。相性が合わなければ、フェーズ2から別の会社に切り替える選択肢が残ります。2つ目は、不確実性の上乗せが減ることです。開発会社は先が見えない範囲ほど余裕を持って見積もるため、確度の高い範囲だけを切り出したほうが単価あたりの見積もりは締まります。3つ目は、フェーズ1で得た学びをフェーズ2の要件に反映でき、無駄な機能を作らずに済むことです。

デメリットは、フェーズごとに契約と検収の手間がかかること、全体の設計思想を通す責任が発注者側に寄ることです。それでも、初めて外注する発注者にとっては、いきなり全額をコミットするより現実的な進め方だと言えます。

既製サービス・SaaSと作り込みを比較する

ゼロから作る（フルスクラッチ）前に、既製のSaaSやパッケージ、ノーコードツールで実現できないかを検討してください。予約管理、在庫管理、顧客管理といった一般的な業務は、月額数千円から数万円の既製サービスで十分まかなえることが多い。独自開発すれば数百万円かかる機能が、月額利用料だけで使えるなら、そちらのほうが合理的です。

判断の目安として、5年間の総額で比較してみてください。月額3万円のSaaSを5年使うと180万円です。同等の機能を作り込むと初期500万円に加えて保守が年50万円かかり、5年で750万円になります。この差が4倍あるなら、既製サービスを選ばない理由を説明できなければいけません。

もちろん、自社の業務フローが競争力の源泉で、既製品では実現できない独自要件があるなら、作り込む価値があります。判断基準は「その機能が事業の差別化に直結するか」です。差別化に関係しない汎用業務は既製サービスに任せ、開発費は本当に独自性が必要な部分に集中投下する。この切り分けが、限られた予算を最大限に活かすコツです。

発注者側でできる作業を巻き取る

見積もりに含まれている作業のうち、社内でできるものを引き取れば、その分の工数がそのまま減ります。具体的には、テストデータの準備、既存データの整形、操作マニュアルの作成、社内向けの研修、稼働後の問い合わせ一次対応などです。これらは開発会社に頼めば工数が積まれますが、業務を知っている社内の人がやったほうが速いことも多い。

見積書を受け取ったら、「この項目を自社で対応した場合、いくら下がりますか」と聞いてみてください。誠実な会社なら、削れる項目と削れない項目を切り分けて答えてくれます。

仲介を通さず直接依頼して中間マージンを省く

費用の内訳を思い出してください。大手SIerや仲介会社を経由すると、実際に開発するエンジニアの人件費に加えて、各層の管理費とマージンが上乗せされます。小規模から中規模の案件であれば、実力のあるフリーランスや小規模開発チームへ直接依頼することで、この中間マージンを丸ごと省けます。

在宅ワーク求人サイトや業務委託マッチングサービスを使えば、開発スキルを持つフリーランスに直接コンタクトできます。仲介手数料が発生しないプラットフォームを選べば、発注者・受注者の双方にとって費用面のメリットが大きくなります。ただし直接依頼では、契約書（NDAを含む）の取り交わしや進行管理を自社で担う必要があるため、その手間とコスト削減効果を天秤にかけて判断してください。

補助金・助成金の活用を検討する

システム開発は、国や自治体の補助金・助成金の対象になることがあります。代表的なのがIT導入補助金で、中小企業・小規模事業者が業務効率化のためにITツールを導入する際、費用の一部が補助されます。要件を満たせば、実質的な負担額を大きく下げられます。

補助金は年度ごとに公募要件や補助率が変わるため、最新情報を確認することが重要です。中小企業向けの支援施策は、所管する公的機関の公式サイトや、各自治体の産業振興窓口で公開されています。補助金の申請には事業計画書の作成など手間がかかりますが、開発会社によっては申請サポートを行っているところもあります。数百万円規模の開発なら、補助金の有無で最終的な負担額が大きく変わるため、発注前に一度は確認する価値があります。

発注前に決めておくべき「業務範囲」の考え方

費用を適正化するうえで、意外と見落とされがちなのが「どこまでを外注し、どこからを自社でやるか」の線引きです。この業務範囲の設計が甘いと、想定外のコストが発生したり、逆に自社でできることまで高いお金を払って外注したりします。

「丸投げ」は高くつく

「専門的なことは分からないから、全部お任せで」という丸投げ姿勢は、一見ラクですが費用面では不利です。要件の整理、業務フローの説明、テスト時の確認、運用開始後の社内展開といった、発注者側でしかできない部分まで開発会社に委ねると、その分の工数が費用に上乗せされます。しかも、業務を最もよく知っているのは発注者自身なので、丸投げされた開発会社は手探りで進めることになり、認識ズレのリスクも高まります。

コストを抑えたいなら、発注者側でできる準備は自分で行うことです。作りたいシステムで解決したい課題、現状の業務フロー、必須機能とあったら嬉しい機能の切り分け。これらを事前に整理して渡すだけで、要件定義の工数が減り、見積もりも下がります。開発会社に依頼するのは「技術的な実現」であって、「自社の業務を理解する作業」まで丸投げすべきではありません。

保守・運用フェーズの体制を先に決める

開発が終わった後、誰がシステムを運用し、不具合が出たら誰が対応するのか。この保守・運用体制を発注前に決めておかないと、稼働後に慌てて高額な保守契約を結ぶことになります。開発会社に継続保守を依頼するのか、簡単な運用は自社で行い重大な不具合だけ外注するのか、選択肢は複数あります。

ここで役立つのが、社内にどれだけITの知見を持つ人材がいるかの把握です。ソフトウェア開発に関わる人材の市場での費用感を知りたい場合は、ソフトウェア作成者の年収・単価相場で、開発人材を採用・委託する際の相場観をつかめます。開発を外注しつつ、運用の一部を担える人材を業務委託で確保する、といった組み合わせも現実的な選択肢です。保守体制を先に設計しておくことで、稼働後のランニングコストを予測可能な範囲に収められます。

発注者側の担当者を明確にする

システム開発を成功させ、費用を無駄にしないためには、発注者側に「窓口となる担当者」を1人立てることが重要です。複数人が思い思いに開発会社へ要望を出すと、要件が発散し、手戻りが増え、費用が膨らみます。窓口担当者が社内の要望を集約し、優先順位をつけて開発会社に伝える体制を作るだけで、プロジェクトの進行効率が大きく変わります。

この担当者は、必ずしも技術の専門家である必要はありません。自社の業務を理解し、社内調整ができ、開発会社と定期的にコミュニケーションが取れる人であれば十分です。業務内容を文書で正確に伝えるスキルは、こうした場面で重宝します。文書コミュニケーションの基礎を体系的に学びたい場合は、ビジネス文書検定のような資格の学習範囲が、要件を過不足なく伝える力の参考になります。窓口担当者がしっかり機能すれば、無駄な手戻りが減り、結果的に費用も抑えられます。

発注者が押さえておきたい費用トラブルの実例

ここで、発注する側として私自身が見聞きしてきた「費用面の失敗」を共有します。これから外注する方が同じ轍を踏まないための、実務的な教訓です。

私が初めて業務システムの外注に関わったとき、最も痛感したのは「安さだけで選ぶことの危うさ」でした。複数社から見積もりを取り、最も安い会社に依頼したのですが、その見積もりにはテスト工程と納品後のサポートがほとんど含まれていませんでした。開発自体は予算内で終わったものの、稼働後に細かい不具合が次々と出て、その修正のたびに追加費用が発生。最終的な支払総額は、当初2番目に安かった会社の見積もりを上回っていました。安い見積もりは「何が含まれていないか」を確認しなければ意味がない、と骨身にしみた経験です。

もう1つの教訓は、要件を固めきらないまま発注を急いだケースです。「早く作りたい」という焦りから、ざっくりした要望だけを伝えて開発を始めてもらったところ、途中で「この機能も必要」「この画面はこう変えたい」と変更が相次ぎ、そのたびに追加見積もりが積み上がりました。最初に時間をかけて要件を整理していれば、避けられた出費でした。システム開発では、発注前の準備にかけた時間が、そのまま費用の節約につながります。急がば回れ、というのはこの領域にこそ当てはまる格言だと感じています。

3つ目は、検収を急いだケースです。納期が迫るなか、細かい確認を後回しにして検収書に押印したところ、稼働後に見つかった不備がすべて有償対応になりました。検収は、発注者が持つ最後の交渉カードです。要件定義書と1項目ずつ突き合わせる時間を、スケジュールに最初から組み込んでおくべきでした。

「直接依頼」という選択肢を検討する

これまで見てきたように、システム開発の費用を左右する大きな要因の1つが「発注先の体制」でした。大手を頂点とする多層の下請け構造では、各層のマージンが積み上がり、同じ品質でも発注者の負担が増えます。逆に、実際に手を動かすエンジニアへ直接依頼できれば、この中間コストを削減できます。

在宅ワーク・業務委託のマッチング領域では、この「直接取引」の需要が着実に伸びています。フリーランスとして活動する開発者が増え、企業側も「必要なスキルを、必要な期間だけ、直接契約で確保する」という発注スタイルを取り入れ始めています。特に小規模から中規模のシステム開発では、仲介を挟まず個人のエンジニアやフリーチームへ直接依頼するほうが、費用対効果で有利になるケースが多く見られます。

直接依頼を選ぶ場合、発注者が用意すべきものは3つです。1つ目は、何を作ってほしいかを文書で説明できる要件のメモ。2つ目は、業務委託契約書と秘密保持契約書。3つ目は、週に1度でも進捗を確認する時間です。この3つさえ確保できれば、開発会社に頼むより支払額を抑えつつ、意思決定の速い開発が実現できます。

ソフトウェア開発人材の費用感については、ソフトウェア作成者の年収・単価相場で職種別の単価水準を確認できます。開発に付随してドキュメント作成やコンテンツ制作を依頼したい場合は、著述家，記者，編集者の年収・単価相場も参考になるでしょう。ネットワークやインフラの知見が必要なプロジェクトなら、CCNA（シスコ技術者認定）のような資格を持つ人材を探す視点も持っておくと、依頼先の目利きに役立ちます。

費用に関する判断は、システム開発に限った話ではありません。事業に関わるコスト構造を理解しておくことは、あらゆる外注・独立の場面で武器になります。たとえば、独立・開業のコストを具体的に知りたいなら行政書士の開業ガイド【2026年版】｜費用・集客・年収のリアルが、事業形態とコストの関係を学ぶならフリーランスの法人成り完全ガイド2026｜手続き・費用・最適なタイミングや法人化マイクロ法人設立の完全ガイド！メリット・費用・注意点が、費用の考え方を鍛える参考になります。作曲やジングルなど、システムに付随する制作物を外注したい場合は作曲・編曲・効果音・ジングルのお仕事も選択肢に入ります。

関連テーマとして、アプリ単体の外注費用を知りたい場合はアプリ開発を外注する費用相場｜機能とプラットフォーム別の料金目安 2026を、Webサイト側の制作費を比較したい場合はWeb制作を外注する費用相場｜規模別の料金内訳と見積の読み解き方 2026を、発注前の要件整理を具体的に進めたい場合は予約システム開発を発注する前の要件整理｜業種別に詰めるべき項目一覧 2026をあわせて参考にしてください。

システム開発の費用は、決して「言い値で払うもの」ではありません。費用の構造を理解し、規模に応じた相場観を持ち、見積もりの内訳を読み、契約形態を選び、そして発注先の体制を吟味する。この5つを押さえれば、発注者は主導権を持って適正価格での発注ができます。特に、仲介を通さない直接依頼という選択肢は、多くの中小企業や個人事業主にとって、費用を抑えながら質の高い開発を実現する現実的な一手になります。まずは自社の課題を1枚の紙に書き出し、必須機能とあったら嬉しい機能を分け、同じ資料を複数の依頼先に渡して比較することから始めてください。この最初の1週間の準備が、最終的な支払額を数十万円単位で変えます。

よくある質問

Q. システム開発の費用相場はどのくらいですか？

規模によって大きく異なります。単機能ツールなど小規模開発で50万〜300万円、業務システムなど中規模で300万〜1,000万円、基幹システムなど大規模で1,000万円以上が目安です。費用の約8割は人件費で、関わる人数と期間で総額が決まります。まずは作りたい機能を洗い出し、規模感を把握するのが第一歩です。