中小企業の社内アプリはいくら？開発費・運用費と補助金を見積り前に整理する
中小企業が社内アプリを作る費用は、まず一つの業務を選び、既製の業務ツール、ローコード、個別開発を同じ条件で見積もると比べられます。補助金を検討する場合は、依頼先を決める前に、対象事業者、対象のツール・経費、契約できる時期を公募要領で確かめてください。補助金がなくても続けられる運用費まで見るのが出発点です。
「社内アプリがほしい」を、止まっている業務に置き換える
社内アプリといっても、日報の提出だけと、権限管理や会計システム連携を含む稟議では仕事が違います。最初に、入力する人、承認する人、結果を使う人を書き、何をもって完了とするかを決めます。今の方法でどんな手戻りが起きるかを見れば、必要な機能と後回しにできる機能を分けられます。
たとえば架空の工事会社で日報の確認が止まる場合、現場担当が作業内容を登録し、管理者が未提出を確認して、月末に集計できれば最初の業務は終わります。写真添付、通知、会計連携は必要な理由を別に書きます。通信が途切れる現場で使うなら、下書き保存や復帰後の動作が必要かを確かめます。現場の通信条件が変われば見積りに影響します。
同時に、扱う情報と誰が見られるかを決めます。部署外の閲覧や退職者のアクセスをどう扱うか、入力を間違えたときに誰が戻せるか、データの保存期間と出力方法はどうするか。ここが未決定なら、見積りの前提として保留と明記します。画面の数だけで発注すると、公開直前に必要になった作業が追加見積りになりがちです。
初期費と毎月の費用を、同じ条件で並べる
金額の目安は、自社で使う人数・業務・権限・連携をそろえた見積りから作ります。初期には業務整理、画面とデータの設計、設定や開発、データ移行、テスト、担当者向けの説明が含まれるか確認します。AIで試作画面を早く作れても、権限やデータ移行が正しいか、間違った入力でどうなるかを確かめる工程は残ります。試作費と本番運用に向けた開発費を分けてもらうと比較しやすくなります。
毎月の支出は利用者ライセンス、ホスティング、外部連携、保守や問い合わせ窓口に分けます。従業員が増えたときに何が増額されるか、障害や仕様変更は月額に含まれるか、バックアップから復旧できるかを確認します。既製ツールでもデータ移行や利用者の教育は必要です。個別開発でも、連携先の仕様変更や利用量で運用費が変わります。
比較期間を社内で決めたら、初期費に月額と利用月数の積、必要な追加開発や移行・終了の費用を足します。社内担当者が費やす時間は、外部へ支払う金額とは別の欄に置きます。税区分、契約期間、対象人数、含まれない作業を見積書の同じ行で並べ、価格差がどの範囲から生まれたかを確認します。
外部への依頼では、納品後に自社で設定できること、データを取り出せる形式、担当交代時に必要な資料、終了時の移管を確認します。運用担当が不明な場合は、契約前に担当者を決めるか、保守の範囲を明記します。外部が対応する場合も、誰が異常を見つけて連絡するかを自社で決めておくと引き継ぎやすくなります。
補助金は対象経費と契約できる時期を先に確認する
デジタル化・AI導入補助金2026の通常枠を検討する場合は、該当する回の公募要領を開き、申請者の要件、対象となる業務や登録ITツール、IT導入支援事業者の条件を確認します。『AIで作った』『社内のDXに使う』という説明だけで対象とは判断できません。既製の登録ツールと個別開発が混在する見積りなら、対象か確認できた明細と対象外・未確認の明細を分けます。
経済産業局の申請フローでは、交付決定の連絡が届く前に発注、契約、支払いなどを行うと交付を受けられない点に注意を促しています。申請を検討している段階では、見積りの取得と契約・発注を区別し、対象の制度に適用される順序を確かめます。急いで着手する必要があるなら、補助金を使わずに始める場合との事業判断を先に行いましょう。
採択と入金も分けます。対象経費や実績報告、支払いの証拠、入金の時期を確認し、補助金が入るまでの資金を用意できるかを経理担当と確認します。制度や申請枠で要件は異なり、時期によって更新されます。募集の締切、補助率、上限、対象サービスの登録有無は、申請する時点の公式資料と支援事業者で確認します。
予算を作るときは、補助金を引く前の支払額を先に記載し、補助対象と確認した額、自己負担、入金までに必要な資金を別欄にします。未確認の経費を補助対象に入れず、申請しない場合も使える最小範囲を残します。制度を使うことが目的になると、必要性の低い機能や契約を追加しやすくなります。
相見積りのために、依頼書の項目をそろえる
依頼書では、業務の開始から完了までを、担当者が見ても同じ手順に読めるように書きます。日報の例なら、スマートフォンから登録する人、提出を確認する人、修正を許可する人を分けます。『一覧を作る』だけでなく、未提出を確認したいのか、部署ごとに集計したいのか、別の作業にデータを渡したいのかを明確にします。それぞれが別の画面や権限の要件になる場合があります。
受け入れの条件は、正常に動く場合と、例外を起こした場合で書きます。登録できたこと、承認されたこと、担当外の人に見えないこと、間違えた入力を直せること、操作履歴が必要なら追えることを確認します。既存の表計算ファイルから移す場合は、重複や欠損を誰が整理するか、過去のデータを全部移すかを先に決めます。移行作業を見積りから外す場合も、誰かがやる仕事として残します。
複数の見積りを受け取ったら、作業ごとに『含む』『含まない』『要確認』をつけます。特に、受入テストで見つかった不具合の直し方、新しい要望を追加する時の見積り、納品後に担当が設定を変えられる範囲を確認します。安い見積りが悪いわけではありません。比較するべきなのは、外部へ支払う額と、自社に残る仕事が同じ条件で説明されているかです。
最初の案に採用しない機能には、見送る理由と再検討する条件を書きます。たとえば会計連携は、日報の入力と承認が安定し、どの項目を会計へ渡すか確定してから考える、という決め方ができます。判断基準を残しておくと、試作を見た人から要望が増えても、その場で契約範囲を膨らませずに済みます。
補助対象と確認できないときは、案を分ける
同じ業務でも、既製ツールの導入と、固有の業務に合わせた個別開発は別の費目になります。補助金に合わせて案を組み替えるなら、採択されなかった場合に自社だけで継続できるかを比べます。対象と確認できたライセンスがあっても、外部の連携や移行、対象期間後の利用料まで含むかは別の判断です。事業者の説明をそのまま予算表へ移さず、公式資料の該当箇所と、確認した日時を控えます。
着手期限が先に決まっている場合は、制度の結果を待てる作業と待てない作業を整理します。先に契約してしまえばよいと判断する前に、申請枠ごとの交付決定前の取扱いを確認します。見積りの有効期限が短いなら、金額の再提示が必要になる時期を依頼先に聞き、申請のためだけに希望と違う作業を約束しないようにします。
見積り相談に持っていくのは、現状と完了の条件
対象業務、現在のツール、利用する部署、取り扱うデータの種類、必須の連携、いつまでに何を動かしたいかをまとめます。実名や顧客データが入った資料は送らず、列名と架空データで説明できます。補助金を調べている場合は候補の制度名と枠、未確認事項、発注予定日も分けて伝えます。
そのうえで、現状のツールを整える案と、新規に作る案の両方を検討します。先に一業務で使える状態を確認してから、他部署や別の連携へ広げると、予算をかける根拠が明確になります。着手前に、何を試し、どんな結果なら次に進むかを決めておきましょう。
比較表
| 方式 | 初期に確認 | 運用・終了時に確認 |
|---|---|---|
| 既製の業務ツール | 初期設定、データ移行、利用者教育 | ライセンス、追加ユーザー、データ出力 |
| ローコード | 画面・権限の設定、連携、テスト | プラン制限、保守担当、連携の変更、移管 |
| 個別開発 | 要件整理、設計、実装、移行、受入確認 | ホスティング、保守・修正、復旧、引き継ぎ |
よくある質問
社内アプリを発注すると補助金が使えますか？
発注だけで対象とは判断できません。対象事業者、登録ITツール、経費、申請枠と契約の時期を公式の公募要領で確認します。
見積りで初期費用だけを比べてもよいですか？
同じ利用人数、期間、機能、運用範囲で、初期費と月額、移行や追加対応を分けて比較します。
開発会社に相談するとき、仕様書は必須ですか？
対象業務、利用する人、困っている場面と、何ができれば完了かがあれば、選択肢の整理を始められます。