補助金を使うシステム開発の進め方 ── 交付決定からの逆算スケジュールと事業計画づくりの実務

· · 補助金, システム開発, 受託開発, 事業計画, 資金繰り, システム開発契約, スケジュール管理, BtoB

前回の記事「システム開発の外注に補助金は使えるか」では、目的別にどの制度を検討すべきかを整理しました。

この記事はその続編です。制度を選んだ後、実際にどう進めるかを扱います。

補助金を使うシステム開発は、通常の開発と2つの点で決定的に違います。

  • 交付決定日より前に発注した経費は補助対象外になる
  • 補助金は後払い(精算払い)で、開発費はいったん全額自社で立て替える

この2つのルールが、スケジュールの組み方から契約のタイミング、資金繰りまで、計画のすべてを規定します。逆に言えば、この2つを軸に逆算して計画すれば、大きな失敗は避けられます。

なお、手続きの詳細は制度・公募回ごとに異なります。この記事は2026年7月時点の一般的な流れを整理したもので、実際の計画は必ず利用する制度の公募要領に合わせてください。

1.まず結論

補助金を使うシステム開発の計画で押さえるべき要点は、次のとおりです。

  • スケジュールは希望納期からではなく、「交付決定日(発注可能日)」と「事業実施期限(検収・支払いの完了期限)」の2点から逆算して組む。実績報告はその後の別期限
  • 「採択」と「交付決定」は別の手続き。発注してよいのは原則、交付決定の後
  • 着手から入金まで1年前後かかる前提で資金繰りを計画する(必要ならつなぎ融資)
  • 事業計画書の主体は発注側。ベンダーに頼めるのは開発に関する事実資料の提供まで
  • 証憑(契約書・納品書・検収書・支払記録)は実績報告で必ず使う。発生の都度そろえる
  • 補助金がなくてもやる価値のある投資かどうかを、申請前に一度自問する

2.全体の流れを知る ── 開発は工程の一部にすぎない

補助金を使う場合、システム開発は次のような一連の手続きの中に組み込まれます。

公募要領の確認・制度選び
        ↓
申請準備(事業計画書・見積書・gBizID等)   … 1〜2か月
        ↓
公募締切 → 審査 → 採択発表               … 数か月
        ↓
交付申請 → 交付決定                       ← ここから発注できる
        ↓
契約・発注 → 開発 → 検収 → 支払い        … 事業実施期限までに完了
        ↓
実績報告 → 確定検査(補助金額の確定)
        ↓
精算払請求 → 補助金入金                    … 精算払い
        ↓
事業化状況報告など                         … 完了後も数年間続く

※ ものづくり補助金・省力化投資補助金(一般型)など「採択発表→交付申請」の2段階を踏む制度の例です。デジタル化・AI導入補助金のように、最初の申請自体が交付申請で、審査の結果として交付決定が出る(採択発表という中間段階がない)制度もあります。

通常の開発なら「発注→開発→検収」で終わる流れの前後に、申請と報告の工程が付きます。特に注意したいのは次の3点です。

採択と交付決定は別物です。ものづくり補助金や省力化投資補助金(一般型)などでは、採択発表は「事業計画が選ばれた」という通知にすぎず、その後に経費内容を精査する交付申請の手続きがあり、交付決定が出て初めて発注できます。手続きの段数は制度によって違いますが、発注できるのは交付決定の後という点はどの制度でも共通です。デジタル化・AI導入補助金の手続き案内でも、交付決定後にITツールの発注・契約・支払いを行うことが明記されています。フライング発注した経費は、原則として救済されません。

事業実施期間には期限があります。交付決定から補助事業の完了までの期間(事業実施期限)が制度ごとに定められており、この期限までに開発を完了し、検収と支払いまで済ませる必要があります。実績報告の提出期限はその後に別途設定されますが、経費として認められるのは事業実施期限までに支払いを終えたものです。開発が遅れて事業実施期限を越えると、補助金を受け取れなくなる恐れがあります。

入金は最後です。実績報告の確認が終わるまで補助金は入りません。しかも、確認が終われば自動で振り込まれるわけではなく、ものづくり補助金などでは補助金額の確定後に精算払請求を申請者が提出して初めて支払われます。請求の提出期限も制度ごとに定められているため、実績報告を出して安心して放置しないことです。着手から入金まで1年前後を見込み、その間の開発費全額を自社資金または融資で賄う計画が必要です。

3.スケジュールは2点から逆算する

補助事業の開発スケジュールは、次の2つの日付を先に押さえ、その間に開発を収める形で組みます。

  • 起点:交付決定日(見込み) ── これより前に発注できない
  • 終点:事業実施期限(補助事業完了期限) ── これまでに検収・支払いを終える。実績報告の提出はその後の別期限

3.1.逆算の例

仮に、交付決定が4月、事業実施期限(検収・支払いの完了期限)が11月末で、実績報告をその後に提出する制度だとします。

時期 補助金の手続き 開発側の動き
前年10〜11月 公募要領確認、申請準備 要件の粗整理、概算見積、構成図の作成協力
前年12月 申請
2〜3月 採択発表、交付申請 見積の確定、契約条件のすり合わせ
4月 交付決定 契約・発注、要件定義開始
5〜9月 設計・実装・テスト
10月 受入テスト・検収
11月 事業実施期限 支払い完了(期限までに)
12月 実績報告(提出期限は制度の定めによる) 証憑の提供に協力
翌年以降 確定検査・精算払請求・入金、事業化状況報告

ここで重要なのは、検収と支払いを事業実施期限の1〜2か月前に置くことです。業務システムの受入テストでは、実データを流して初めて見つかる問題が必ず出ます。期限ぎりぎりに検収を設定すると、手直しの時間がなく、「期限に間に合わせるために不十分なまま検収する」という本末転倒が起きます。

3.2.交付決定前にできること・できないこと

交付決定前に契約はできませんが、何もできないわけではありません。

交付決定前にできる 交付決定前にしてはいけない
要件の整理、業務フローの棚卸し 開発契約の締結、発注書の発行
ベンダーからの見積取得、相見積・提案の比較 着手金の支払い
事業計画書の作成 開発作業の開始(先行着手)
gBizIDプライムの取得、電子申請の準備 ライセンス・機材の先行購入

むしろ、要件整理と見積の精度を申請前に高めておくほど、交付決定後の開発はスムーズに始められます。申請時の見積と実際の開発内容が大きくずれると、交付申請や計画変更の手続きで時間を失うためです。

なお、電子申請に必要なgBizIDプライムのアカウント取得には審査があり、時間がかかる場合があります。申請直前ではなく、制度を検討し始めた段階で取得しておくのが安全です。

3.3.工程と契約の整合

補助事業だからといって、開発契約の考え方が変わるわけではありません。要件定義を準委任、設計以降を請負とする多段階契約(「IPAモデル取引・契約書に学ぶ契約の結び方」参照)を採る場合は、どの契約のどの経費が補助対象かを交付申請の内容と対応させておく必要があります。契約を分けるなら、見積書もその単位で明細化しておくと、実績報告時の突合が楽になります。

4.資金繰り ── 精算払いに備える

補助金は前受金ではありません。開発費の支払いは全額先行し、補助金は実績報告の確認後に入金されます。

計画時に確認すべきことは次のとおりです。

  • 開発費全額(補助対象外の経費も含む)を、入金までの期間立て替えられるか
  • 立て替えが難しい場合、金融機関のつなぎ融資を利用できるか(採択通知を基に相談できる場合があります)
  • 補助率が1/2なら残り1/2、2/3なら残り1/3は恒久的な自己負担であること
  • 稼働後の保守費・運用費は通常、補助対象外であり、毎年の自社負担になること。ただし例外もあり、例えばデジタル化・AI導入補助金では登録ITツールのクラウド利用料を一定期間分(通常枠では最大2年分)補助対象にできます。ものづくり補助金にもクラウドサービス利用費の経費区分があります。どの運用費がどの期間まで対象になるかは制度ごとに公募要領で確認してください

特に最後の2点は見落とされがちです。「補助金が出るから」と開発範囲を膨らませると、自己負担分と保守費が膨らみ、補助事業が終わった後の負担として残ります。補助金がなくても投資判断として成り立つかを一度自問してから申請するのが、結局は安全です。

5.事業計画書づくり ── 発注側が書くもの、ベンダーが出せるもの

補助金の審査は事業計画書で行われます。そして、この計画書の主体は申請者である発注側です。

5.1.発注側にしか書けないこと

  • 自社の経営課題(何に困っていて、なぜ今解決するのか)
  • 数値目標(労働生産性、付加価値額、賃上げなど、制度が求める指標)
  • 実施体制(誰が責任者で、誰が業務側の窓口か)
  • 資金計画(自己資金・融資の別)

例えば中小企業省力化投資補助金(一般型)では、労働生産性の向上や賃上げに関する目標(使われる指標・数値は公募回で異なり、複数の指標から選択する方式の公募回もあります)を含む事業計画が求められ、申請時に設定した目標が未達の場合の返還条項もあります。これらは経営そのもののコミットメントであり、ベンダーが肩代わりできる性質のものではありません。

5.2.ベンダーが提供できる事実資料

一方、開発に関する事実部分は、ベンダーの協力が得られます。

  • 開発内容の説明資料(何を作り、どの業務がどう変わるか)
  • システム構成図(現行と導入後)
  • 経費区分に合わせて明細化した見積書
  • 工数削減効果の試算根拠(現状の作業時間の測り方、削減の計算方法)

このうち審査で効くのは、意外にも最後の「試算根拠」です。「業務が効率化される」という定性的な記述より、「受注1件あたりの入力時間が平均◯分、月◯件だから月◯時間。このうち自動取込に移る◯割が削減対象」という積み上げのほうが、計画の説得力は上がります。この積み上げは、発注側の業務データとベンダーの設計知識の共同作業でしか作れません。

5.3.書き方の支援が必要なら公的窓口へ

計画書の書き方そのものの支援は、開発ベンダーの業務範囲ではありません。商工会議所・商工会、よろず支援拠点、ミラサポplusで紹介されている支援機関、中小企業診断士などの専門家に相談してください。成功報酬型の申請代行業者を使う場合は、手数料率と契約条件を冷静に確認することをおすすめします。

6.実績報告に備える ── 証憑は発生の都度そろえる

実績報告では、発注から支払いまでの一連の証憑を提出します。一般に必要になるのは次のような書類です。

  • 相見積書(ものづくり補助金や省力化投資補助金(一般型)などでは、一定金額以上の調達について原則、複数者からの見積書が必要です。1者からしか取得できない場合は、業者選定理由書などの説明資料を求められます)
  • 契約書または発注書・請書
  • 納品書、検収書(日付が事業実施期間内であること)
  • 請求書、振込記録(ものづくり補助金や省力化投資補助金(一般型)では、支払いは原則として申請者名義の銀行振込とされ、現金払いは補助対象になりません。領収書があっても振込記録の代わりにはならないため、支払方法は最初から銀行振込にしておきます)
  • 仕様変更があった場合の変更契約書・覚書

ここでつまずくパターンは決まっています。後からまとめて作ろうとすることです。日付の整合(交付決定日以降の発注か、期間内の支払いか)が確認されるため、後付けで書類を整えることはできませんし、してはいけません。発注・納品・検収・支払いの各時点で、日付の入った書類をその都度確定させ、ファイルしておく。これだけで実績報告の負担は大きく減ります。

開発側から見ると、これは通常の受託開発でも本来やるべき文書管理と同じです。補助事業では、それが補助金を受け取る条件として明文化されているだけとも言えます。

また、入金後も事業化状況報告のように数年間の報告義務が続く制度があります。報告に使う指標(生産性、工数、売上など)は、システム稼働後に測り始めるのではなく、開発時点で記録の仕組みを組み込んでおくと、毎年の報告が楽になります。

7.よくあるつまずきと対策

つまずき 対策
採択直後に発注してしまい、経費が対象外に 発注可能になる時点(通常は交付決定後)を公募要領で確認し、それまで契約しない
開発が遅れ、事業実施期限に間に合わない 検収を事業実施期限の1〜2か月前に置く。受入テストの手直し期間を最初から計画に入れる
申請時の見積と開発内容がずれて手続きが増える 申請前に要件整理と見積の精度を上げる。変更が生じたら早めに事務局へ計画変更を相談
入金前の資金繰りが苦しくなる 全額立て替えを前提に計画。必要なら採択後すぐに金融機関へつなぎ融資を相談
実績報告の書類が足りない 証憑は発生の都度確定・保管。日付の整合を毎回確認する
補助金ありきで開発範囲が膨張 補助金なしでも成り立つ投資かを自問。自己負担分と稼働後の保守費で判断する

まとめ

  • 補助金を使う開発の計画は、交付決定日(発注可能日)と事業実施期限(検収・支払いの完了期限)の2点からの逆算で決まる。実績報告はその後の別期限
  • 採択と交付決定は別物。発注は原則、交付決定の後
  • 補助金は後払い。全額立て替える資金繰りを先に固める
  • 事業計画書の主体は発注側。ベンダーからは開発内容・構成図・見積・効果試算の根拠という事実資料を引き出す
  • 証憑は後からまとめず、発生の都度そろえる
  • 制度の詳細は公募回ごとに変わるため、必ず最新の公募要領で確認する

制度選びの全体像は前回の「システム開発の外注に補助金は使えるか」を、省力化投資補助金を使う具体例は「省力化投資補助金でFAX受注のWeb化はできるか」をご覧ください。

補助金を前提とした開発をご検討の方へ

合同会社小村ソフトでは、Windows業務アプリケーションを中心とした受託開発をお受けしています。補助金の利用を前提とする案件では、申請前の概算見積・構成図・工数削減効果の試算根拠づくりに協力し、交付決定後の開発は事業実施期限から逆算したスケジュールで計画します。

なお、当社は申請代行や採択可否の判断は行っていません。申請手続きは公的窓口や専門家にご相談いただいたうえで、開発の中身と進め方については、要件整理の段階からお気軽にご相談ください。

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

システム開発の外注に補助金は使えるか ── 目的別の制度マップと発注前に知っておきたい落とし穴(2026年度版)

システム開発の外注に補助金は使えるのでしょうか。「IT導入補助金でオーダーメイド開発」ができない理由から、ものづくり補助金・省力化投資補助金など目的別の制度マップ、交付決定前の発注禁止といった落とし穴まで、発注側の視点で2026年度の制度を整理します。

省力化投資補助金でFAX受注のWeb化はできるか ── 一般型を使う受発注システム投資の考え方

FAX受注のWeb化・自動取込は、人手不足対応の省力化投資として中小企業省力化投資補助金(一般型)の検討対象になり得ます。カタログ注文型と一般型の違い、受発注システムが省力化投資に当てはまる理由、工数削減効果の示し方、賃上げ要件などの注意点を解説します。

受託開発・運用保守の契約はどう結ぶべきか ── IPA「モデル取引・契約書」に学ぶ準委任と請負の使い分け

システム開発を外部に委託するとき、契約はどう結ぶべきでしょうか。IPAが公開する「情報システム・モデル取引・契約書」をもとに、多段階契約の考え方、準委任と請負の違い、運用保守契約で決めておくべきことを、発注側にも分かりやすく解説します。

「何秒で動けば満足か」を決め忘れないために ── IPA「非機能要求グレード」で非機能要件を整理する

システム開発で「速度が遅い」「障害対応が想定外」と揉める原因の多くは、非機能要件の決め忘れです。IPAが公開する「非機能要求グレード」の6大項目、グレード表とモデルシステムの使い方、中小企業の業務アプリでの現実的な活用方法を、発注側にも分かりやすく解説します。

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

採択されたらすぐに開発を発注してよいですか?
ものづくり補助金などの多くの制度では、採択発表の後に交付申請という手続きがあり、事務局の審査を経て交付決定が出ます。デジタル化・AI導入補助金のように最初の申請自体が交付申請となる制度もありますが、いずれの場合も補助対象になるのは原則として交付決定日以降に契約・発注した経費です。採択直後の発注はまだ早い場合があるため、自分の制度で発注可能になる時点を公募要領で確認し、それより前には契約しないでください。
補助事業のシステム開発は、通常の開発より期間がかかりますか?
開発作業そのものの期間は変わりませんが、前後の手続き期間が加わります。申請準備に1〜2か月、採択発表まで数か月、交付決定までさらに時間がかかり、開発完了後も実績報告と確認を経てから入金されます。着手から入金まで1年前後かかることも珍しくありません。また、事業実施期間の期限までに検収と支払いを終える必要があるため、開発期間はその期限から逆算して確保します。
事業計画書はベンダーに書いてもらえますか?
事業計画書の主体は申請者である発注側です。自社の経営課題、数値目標、実施体制は自社にしか書けません。ベンダーが協力できるのは、開発内容の説明、システム構成図、見積書、工数削減効果の試算根拠など、開発に関する事実部分の資料提供です。書き方そのものの支援が必要な場合は、商工会議所・よろず支援拠点や中小企業診断士などに相談してください。
実績報告ではどんな書類が必要になりますか?
制度により異なりますが、一般に契約書(発注書・請書)、納品書、検収書、請求書、振込記録など、発注から支払いまでの一連の証憑が必要です。日付の整合(交付決定日以降の発注か、事業実施期間内の支払いか)が確認されるため、開発の途中で仕様変更があった場合の変更契約書も含め、書類は発生の都度そろえておくことが重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

ブログ一覧に戻る