予算が決まっていないときのシステム開発費の考え方｜相場表より先に、社内で上限を決める材料

システム開発の費用相場を調べると、業務システムの規模別や種類別の金額の表が見つかります。けれども、その表のどこに自社が入るかは、何をどれだけ作るか、どの会社に頼むか、見積もりに何を含めるかが決まるまで分かりません。予算がまだ決まっていない段階で先に決めるのは、相場の金額ではなく、社内で出せる上限です。上限は、いま手作業にかけている時間、今払っている保守やライセンスの費用、使う年数、止まったときの影響という、社内にある材料から決められます。

決める順番にも要点があります。使う年数のあいだに出せる総額を先に決め、そこから作った後に毎年かかる費用（保守、サーバーやクラウド、変更のたびの開発）を引いて、残りを最初に作る費用の上限にします。2024年10〜11月に東京商工会議所が行った調査（主に東京23区の中小企業が対象）でも、デジタル化の費用のうち、すでに入っているシステムを保つための費用が新しく入れる費用を上回る、と答えた企業が47.2%ありました（東京商工会議所「中小企業のデジタルシフト・DX実態調査」集計結果（詳細版）、2025年1月10日）。作った後の費用は、初期費用に後から足すものではなく、先に取り分けておくものです。

この記事では、相場表の金額に幅がある理由、公開データで見る費用の骨格、上限を決める材料の集め方、作った後の費用の見方、見積もりが上限を超えたときの範囲の削り方、補助金を当てにする前に確かめること、見積もり依頼への金額の書き方を順に説明し、最後に稟議の下書きに使える表を載せます。Aurant Technologiesは、受発注・在庫などの業務の仕組みを、既製のサービスで足りる部分は既製のまま使い、合わない部分だけを作る形で支援していますが、ここでは作り方にかかわらず使える上限の決め方を書きました。調査の数字には、いつ、どんな会社を対象にしたデータかを添えています。自社の案件の金額としてそのまま当てはめるためのものではありません。

相場表の金額に幅があるのは、違うものが同じ欄に並ぶから

相場表の一つの欄には、条件の違う案件の金額がまとめて入っています。システム開発の金額は、作る量（何人が何か月働くか。1人が1か月働く量を1人月と数えます）に1人月あたりの単価を掛け、ライセンスやサーバーなどの費用を足して決まります。同じ欄の中の金額の違いは、主に次の三つから生まれます。

作る量は、画面や帳票がいくつあるか、ほかのシステムといくつつなぐか、今の台帳からどれだけデータを移すかで決まり、取引先ごとの例外が多いほど増えます。受発注の仕組みなら、数え方は「受発注システムの開発費は、取引先と例外の数で決まる」で順を追って説明しています。単価は、頼む会社と担当する人の経験で変わります。含む範囲は、同じ「開発費」という名前でも、要件を決める打ち合わせやデータの移し替えを含むか、保守やクラウドの費用を何年分含むか、税込か税抜かで変わります。

三つのうち、作る量と含む範囲は、発注する側が決められます。単価は頼む会社によって違いますが、上限を決めておけば、その額の中で何を作れるかという同じ問いを各社に出せます。相場表の中で自社の位置を探すより先に、社内で決められるものを決めておくほうが、届いた見積もりを比べやすくなります。

公開データで見る費用の骨格：総費用は、ほぼ工数で決まる

相場表に並ぶ単価や金額には、出典が書かれていないものが多くあります。費用と作る量の関係を確かめられる公開データとしては、日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025」ガイドブック（2025年4月発行）が使えます。JUASは195件のプロジェクトを分析し、開発の総費用（万円）がおよそ127.14×全体工数（人月）になるという関係を示しています。

総費用のばらつきの92%は工数で説明できる、というのがJUASの分析です（自由度調整済み決定係数0.92）。JUASはこの195件について、人月単価は127万円とみるのが妥当としています。金額を大きく動かすのは、単価よりも作る量だということです。

ただし、127万円を自社の案件の単価として使うことはできません。データの性格が次のように違うからです。

• 対象の会社と開発の形：システムの開発や保守を続けてきた企業から、JUASがアンケートで集めたデータです。JUAS自身、このデータが当てはまるのは主に従来のウォーターフォール型の開発だと断っています。
• 対象の案件：費用と工数の分析は、1人月あたりの費用が50万円以上400万円以下のプロジェクトに絞っています。言い換えると、同じ1人月でも、かかる費用には案件によって幅があるということです。
• 案件の大きさ：外注コストが記載されたスクラッチ開発（一から作る開発）99件のうち、10人月未満は6件、50人月未満を合わせても29件です。小さな案件はわずかしか入っていません。
• 数え方：同じガイドブックでも、外注コストが記載されたスクラッチ開発99件の加重平均単価は96万円で、127万円とは違います。対象の件数、何を何で割ったか（総費用か外注コストか）、計算の仕方が違うためです。

この骨格から言えることは二つです。一つは、上限に収めたいときは、単価の交渉だけに頼るより、作る量を減らすほうが金額を大きく動かせること。もう一つは、相場の人月単価から自社の金額を逆算するのではなく、決めた上限でどの範囲まで作れるかを開発会社に聞く形にできることです。

なお、このデータは生成AIを使った開発を前提にしていません。生成AIで縮む可能性があるのは主に、決まった仕様を画面や処理にする実装の工数で、業務の聞き取り、テスト、データの移し替えは縮みにくい工程です。生成AIを使う会社に頼む場合でも、上限の中で何を作るかを発注する側が決める作業は変わりません。生成AIで開発費がどこまで下がりうるかは、「生成AIでシステム開発費はどこまで下がるか」で工程の比率から計算しています。

予算を立てていない会社は珍しくない

デジタル化の予算を立てないまま検討を進めている会社は、少なくありません。2026年3〜4月に東京商工会議所が行った調査（主に東京23区の中小企業）で、今年度のデジタル化の予算を前年度と比べて尋ねたところ、集計に入った959社のうち29.9%が「予算は立てていない」と答えています（東京商工会議所「中小企業のデジタルシフト・DX実態調査」集計結果、2026年6月17日）。この集計には、口頭の連絡・電話・帳簿での業務が多い段階の企業は入っていません。紙と口頭の連絡をITに置き換えている途中の企業（371社）に限ると、38.8%です。

集計の対象は959社で、デジタル化がまだ口頭や電話、帳簿中心だと答えた企業は外されています。デジタル化が進んだ企業ほど予算を立てている傾向は読み取れますが、どの段階にも、予算を立てずに進めている企業はいます。

気をつけたいのは、上限を決めないまま見積もりを頼んだときに起きることです。どこまで作るかは開発会社ごとの想定で決まるので、届いた金額の違いが範囲の違いなのか単価の違いなのかを見分けにくくなります。

IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」では、発注する側が、要件を決める前の計画の段階で開発の体制・予算・スケジュールを定め、経営層の承認を受けてから要件定義に進む流れになっています。この段階で開発会社から受け取る見積もりは、予算の計画を立てるための参考値という扱いです。モデル契約は発注する側が大手企業である取引を主な想定にしたものですが、見積もりを受け取ってから予算を考えるのではなく、予算の枠を決めてから見積もりで確かめる、という順番は会社の規模にかかわらず使えます。

上限を決める材料を、社内で集める

予算の決め方の中心は、この上限を決めることです。上限は経営の判断で決めるものですが、判断の材料は社内で集められます。集めるのは次の四つです。

いま手作業にかけている時間

仕組みにしたい業務ごとに、誰が、月に何時間かけているかを書き出します。転記、突き合わせ、問い合わせへの回答、間違いの直しを分けて数え、繁忙期がある業務はその月も数えます。時間は、経理に1時間あたりの人件費（給与に加えて、会社が負担する社会保険料なども含めた額）を出してもらい、年額に直します。仕組みにしたあと、浮いた時間を何に回すのか（残業を減らすのか、別の仕事に充てるのか）も一緒に書いておくと、稟議で数字の意味を説明しやすくなります。

今払っている費用

今の業務のために払っている費用を、請求書と契約書から拾います。使っているソフトの利用料と保守料、Excelやマクロの手直しを外部に頼んでいる費用、紙やFAXにかかる費用などです。拾ったものは、新しい仕組みにしたら止められるものと、そのあとも残るものに分けます。止められる費用は、作った後にかかる費用の一部を受け持つ財源の候補になります。

使う年数

何年使うつもりかを決めます。法人税の決まりでは、自社利用のソフトウェアの耐用年数は5年です（国税庁 タックスアンサー No.5461）。稟議で年数の根拠を問われたときに示しやすい区切りです。取引先や業務のやり方が数年で大きく変わりそうなら、短めに見ておきます。税務上の扱いは、顧問の税理士にご確認ください。

止まったときの影響

今のやり方が止まったら何が起きるかを書き出します。担当者しか触れないExcel、作った人がもういないマクロ、古いパソコンに入っている台帳が使えなくなったら、受注や出荷は何日止まり、どの取引先に影響が出るか。反対に、新しい仕組みが止まったときに、紙や電話に戻して回せるかも書いておきます。IPAのモデル契約も、計画の段階で考える業務上の要求の一つに事業継続性を挙げています。止まったときの影響が大きい業務ほど、作った後の保守（問い合わせに応じる時間帯やバックアップ）にかける費用を厚くする理由になります。

四つがそろうと、上限を置く位置を説明できるようになります。いま手作業にかけている時間の年額と、新しい仕組みで止められる費用の年額を足し、使う年数を掛けた額は、今のやり方のまま同じ年数を続けた場合にかかる費用の目安です。これは上限そのものではなく、上限を置く位置を説明するための物差しです。上限を物差しより高くするなら、止まったときの影響や、取引先を増やしたいといった別の理由を稟議に書きます。

作った後にかかる費用を、最初に作る費用より先に見る

最初に作る費用に使える額は、使う年数のあいだに出せる総額から、作った後にかかる費用を引いた残りです。作った後の費用は最初の見積もりの陰に隠れやすいのですが、多くの会社で小さくない額になっています。

冒頭で触れた2024年の東京商工会議所の調査で、費用の内訳を尋ねた設問を見ると、今あるシステムを保つ費用のほうが多い企業が47.2%だったのに対し、新しく入れる費用のほうが多い企業は25.5%、同じくらいの企業は21.8%でした（口頭や電話、帳簿が中心の企業を除いた1,002社）。

2026年の東京商工会議所の調査は、直近1年間のデジタル化の予算額を、新しいシステムの導入と、今あるシステムの維持・運営に分けて尋ねています。二つを並べると、分布はよく似た幅に広がっています。

新しいシステムの導入では、0円と50万円未満を合わせるとおよそ半数で、1,000万円以上は7.5%でした。維持・運営に予算を充てなかった企業（0円）は13.1%で、新しいシステムの導入の18.8%より少なく、100万円以上500万円未満の企業はどちらも約2割でした。会社ごとの1年間の予算の分布で、一つのシステムの費用ではありませんが、今あるシステムを保つための予算を組んでいない企業は少数にとどまることが分かります。

IPAのモデル契約も、中小企業が使う場合の注意として、開発の費用を早く確定させたいという事情があっても、保守や運用の費用との釣り合いを考え、システムを使い終えるまでの全体で投資の効果を見て進める必要があるとしています。作った後にかかる費用として、年額で見込むのは次のものです。

• 保守：不具合の調査と修正、問い合わせへの対応、OSや部品の更新、バックアップ
• サーバーやクラウドの費用
• 既製のサービスや外部の部品を組み合わせる場合の利用料（使う人数や件数で増えるものがあります）
• 変更のたびの開発：取引先や項目を足す、帳票の形を変える、制度の変更に合わせる
• 社内の担当者の時間：設定の変更、問い合わせの取り次ぎ

見積もりが届く前の段階では、この欄は金額で埋まりません。そこで、見積もりを頼むときに、作った後の費用を年額で出してもらうよう依頼に書いておきます（書き方は後の節で扱います）。届いた年額に使う年数を掛けて総額から引き、その残りと、最初に作る費用の見積もりを見比べます。

見積もりが上限を超えたら、単価より先に範囲を削る

見積もりが上限を超えたとき、まず見直すのは作る範囲です。JUASのデータで総費用のばらつきの大半が工数で説明できたように、金額を大きく下げられるのは、作る量を減らしたときです。削る順番の目安は次のとおりです。

1. 最初に動かす業務を一つにする。手作業の時間を数えた結果から、いちばん時間のかかっている業務を選びます。
2. 年に数回しか起きない例外は、手作業に残す。取引先ごとの特別な決まりを全部仕組みに入れると、その分だけ画面と処理とテストが増えます。
3. 既製のサービスで足りる部分は既製のまま使い、足りない部分だけを作ってつなぐ。作り方ごとに5年間の総額を並べる方法は「業務システムは買うか作るか」で説明しています。
4. 後に回したもの（2つ目からの業務、使い始めてから要るかを確かめたい画面や帳票など）は、次の段階の一覧として残す。上限の外に出しただけで、要らなくなったわけではありません。

反対に、削らないものもあります。テストと実際のデータでの確かめ、データの移し替え、使う人への説明、今のやり方と並べて動かす期間、そして作った後に取引先や項目を足すための予備です。IPAのモデル契約は、工程ごとに見積もり直して進める場合について、全体の予算が決まっているときは後の工程にしわ寄せが行き、重要な開発を終えられなくならないよう、全体の予算の管理に気をつけるよう注意しています。範囲を削って上限に収めるときも、削る先は作る範囲にとどめ、後ろの工程の分は残しておきます。

画面を先に作り、触って確かめながら広げていく進め方では、先に優先順位を決めておくことがとくに大切です。モデル契約は、こうした反復して作る開発について、実現する機能の優先順位と、当初の見積もりを超えたところで契約を見直すといった量の上限を、契約書に書いておく必要があるとしています。上限は社内の稟議だけでなく、開発会社との取り決めにも入れておくものです。

補助金を当てにする前に確かめること

補助金で費用を抑えたいと考える会社は多くあります。同じ2026年の東京商工会議所の調査で支援策について尋ねた設問では、今後利用したい支援策に「補助金・助成金」を挙げた企業が67.2%でした。一方で、直近3年以内に国や東京都のデジタル化の施策を活用したものはないと答えた企業が73.5%あり、活用しなかった理由の上位は「支援施策を知らない」（43.3%）、「活用できる制度か分からない」（34.0%）、「申請手続きの負担が大きい」（29.1%）でした（67.2%と73.5%は回答企業全体、理由は活用しなかった935社の複数回答）。

システムに使う補助金としてよく名前が挙がるのが、国のデジタル化・AI導入補助金（旧IT導入補助金）です。2026年の通常枠について、予算の組み方に関わる条件を、公式の資料で確かめられる範囲で挙げます。出典は、中小企業庁の「デジタル化・AI導入補助金2026」の概要（令和8年4月）と、事務局の公募要領（通常枠）です。

• 補助の対象は、事務局に登録されたITツールを入れる費用です。申請には、事務局に登録されたIT導入支援事業者（ツールを提供する事業者）の手助けが要ります。完成した製品ではなく一から作る開発（スクラッチ開発）を伴うソフトウェアや、特定の顧客のためだけのもので市販されていないソフトウェアは、ITツールとして登録できません（ITツール登録要領）。一から作る開発には使いにくい制度です。
• 補助率は2分の1以内（条件を満たすと3分の2以内）で、補助額は、ツールが受け持つ業務の工程（プロセス）の数に応じて、5万円以上150万円未満か、150万円以上450万円以下です。150万円以上には、4プロセス以上であることと、賃上げの計画などの要件が加わります。
• 月額・年額で払う利用料と保守サポートの費用は、最大2年分が対象です。3年目からは自社で払います。
• 消費税は補助の対象外です。
• 交付決定の前に契約・発注したものは対象になりません。契約・導入・代金の支払いは交付決定の後に行い、支払いは銀行振込かクレジットカードの一括払いです。補助金は、そのあとの実績報告を経て額が確定してから交付されます。代金は、いったん全額を自社で払うことになります。
• 申請すれば必ず採択されるわけではありません。中小企業庁の資料によると、IT導入補助金2025の通常枠は、申請23,672件に対して採択が8,936件でした。

ここから、予算の組み方として言えることは二つです。上限は補助金を入れずに組み、補助金は採択されたときに後から戻る分として扱うこと。そして、交付決定より前には契約できないので、使い始めたい時期から逆算した日程に、申請から交付決定までを待つ期間を入れておくことです。補助事業の実施と実績報告は、交付決定から6か月程度のうちに終えることになっています。ほかの補助金や助成金は対象も条件も違うので、制度と年度ごとに公募要領を読んで確かめます。

見積もり依頼には、上限の額と、その額に含むものを書く

上限が決まったら、見積もりを頼むときに金額をどう伝えるかを決めます。未定のまま頼むと、提案の範囲は開発会社ごとの想定で決まり、並べても比べにくくなります。上限を書けば、各社は同じ額の中で何を作るかを提案することになり、提案の違いを範囲と優先順位の違いとして読めます。

上限を書くときは、額と一緒に、その額に何を含むか（たとえば1年目の保守やクラウドの費用を含むか、税込か税抜か）を書きます。作った後の費用を年額で出してもらうことや、上限を超える部分の扱いも、同じ欄に書いておくと各社の答えがそろいます。

上限を書くと、上限いっぱいの見積もりばかりが届くのでは、という心配もあります。画面・帳票・つなぐ先・移すデータごとに工数を分けて出してもらえば、同じ額の提案でも、各社が何にどれだけの工数を見込んだかを比べられます。上限の全額を書かず、作った後の変更に備える分を手元に残しておくのも一つの方法です。届いた見積書の読み方は、見積書を行ごとに分けて前提をそろえる方法で扱っています。

IPAのモデル契約の解説は、とくに中小企業では、発注する側が提案依頼書（RFP）を自分で作れず、コンサルタントや今のシステムを作った会社が代わりに作ることが多いと書いています。依頼の文書を誰かに作ってもらう場合でも、上限の額と、その額に含むものは、社内で決めて渡します。

上限を決める稟議の下書き

最後に、ここまでの材料を稟議の下書きにまとめる表です。分からない欄は空けたままにし、見積もりが届いたら埋めます。

表が埋まると、上限をいくらにしたかだけでなく、なぜその額にしたのか、上限を超えたら何を削るのかまで説明できるようになります。見積もりを比べるときも、この表の上限と最初の範囲が基準になります。

Aurant Technologiesでは、受発注・在庫の仕組みづくりの進め方を受発注・在庫管理システムの開発のページに載せています。どの業務から始めるか、作った後の保守をどう分けるかを具体的に見たいときの参考にしてください。