新事業進出補助金の交付決定後にシステム開発を進める手順｜新市場向け要件と計画変更

最初に分けるべき4つの書類と、分けてはいけない案件情報

最初に集めるのは、交付決定通知など制度の決定書、申請・交付申請時の事業計画、開発会社の見積と契約、そして実施期限が分かる資料です。これらを別フォルダーに置くだけでは不十分で、同じ開発項目がどの書類のどこに書かれているかを表にします。

表の列は、計画上の目的、システム機能、経費区分、見積金額、発注日、納品・検収日、支払日、報告書類です。空欄がある列は、開発会社か事務局に確認すべき未確定事項です。金額だけが一致していても、成果物や期限が一致していなければ安全とはいえません。

この段階で申請時の説明と現場の要望が変わっている場合、開発会社に先に着手を依頼するのではなく、変更理由と影響額を整理します。採択と交付決定の違いを確認し、発注可能な状態かを通知書と公募要領で再確認してください。

• ・通知書の対象経費と上限
• ・申請時計画と成果物
• ・見積・契約・発注の関係
• ・完了・報告・支払いの期限
• ・変更時の相談先

発注前に行う工程判定：期限から逆算して実装を小さくする

実施期限までの残日数を見て、要件定義、設計、開発、テスト、導入、検収、支払い、実績報告準備を横に並べます。各工程に担当者と完了条件を置き、休日・承認待ち・事務局への相談期間を含めます。開発会社が示す納期だけで逆算すると、検収と支払いが期限外に落ちることがあります。

期限が厳しい案件では、機能を削る前に「補助事業の目的を満たす最小成果物」を決めます。削除する機能、後回しにする機能、代替運用にする機能を分け、削減後も事業計画・効果指標・対象経費の説明が通るかを確認します。

納期の変更やスコープ縮小が制度上の計画変更に当たる可能性があれば、承認や届出の要否を先に問い合わせます。自己判断で発注内容を変えず、実施期限に間に合わないときの5点確認を使って、相談資料を作ってください。

• ・残日数から報告提出日を引く
• ・検収の合格条件を先に決める
• ・支払いサイトを工程に入れる
• ・必須機能と後回し機能を分ける
• ・変更承認の要否を確認する

見積・契約・成果物を照合するチェック表

見積の確認は総額の比較から始めません。工程別の作業、作業量、単価、前提条件、除外事項、納品物、検収条件が記載されているかを見ます。「開発一式」だけでは、どこまで作るのか、何が追加費用になるのかを実施前に判断できません。

契約書には、成果物の定義、検収期間、修正回数、仕様変更の扱い、データやアカウントの帰属、納期遅延時の連絡方法を置きます。補助金の制度資料と契約書は役割が違いますが、契約の成果物が交付決定の対象経費と対応していることは、報告時の説明に影響します。

開発中は、週次の進捗、課題、決定事項、変更理由を残します。完成時にまとめて書類を作ると、日付や担当者の記憶がずれます。実績報告で落ちない証憑チェックリストを早い段階から開発会社と共有してください。

• ・工程×作業×工数×単価
• ・対象経費と対象外経費
• ・成果物と検収条件
• ・仕様変更と承認記録
• ・納品・請求・支払いの証憑

経営者・士業・開発会社の責任分界を決める

経営者は、事業目的、予算、優先順位、最終承認を担います。士業・支援機関は、申請・交付・報告の制度手続きと顧客への説明を担います。開発会社は、技術的な実現方法、工数、成果物、進捗、検収に必要な説明を担います。誰か一人が全責任を背負う形にしないことが重要です。

特に「補助対象になるか」「この変更は認められるか」「この機能をいつまでに作れるか」は、制度判断・契約判断・技術判断が混ざりやすい質問です。回答者と根拠資料を記録し、推測で進めないルールを決めます。

士業が実装パートナーを探す場合は、紹介料や顧客関係を曖昧にせず、案件受付、守秘、責任分界、顧客窓口を先に合意します。補助事業実装パートナーの案内と提携運用ルールを確認し、案件の立場を明らかにして相談してください。

• ・経営者：目的・予算・承認
• ・士業：制度手続き・説明
• ・開発会社：技術・工数・成果物
• ・事務局：制度上の確認・承認
• ・全員：変更記録と期限共有

今日作る1枚と、GXOへ相談するときの資料

今日作る1枚は、案件名、制度名、公募回、交付決定日、完了期限、補助対象上限、発注状況、残工程、変更点、次の確認先を並べた案件サマリーです。1枚で不明点が見えるようにし、資料を読んだ人が「次に誰へ何を聞くか」を判断できるようにします。

GXOへ相談する場合は、交付決定通知、事業計画、最新見積、契約の有無、進捗、期限、困っている点を添付してください。未整理でも構いませんが、個人情報や機密情報は必要最小限にし、公開情報・社内情報・開発会社から受け取った資料を区別します。

案件の状態が交付決定済みで発注先未定・変更検討中なら案件受付フォーム、まず整理したいならレスキュー窓口が入口です。採択保証や補助額の確約は行わず、制度の最終判断は事務局と公式資料に基づいて進めます。

判断を止めるべき4つのケースと、確認する順番

次の4ケースでは、開発会社への追加発注や仕様確定をいったん止めます。①交付決定通知と最新見積の対象経費が一致しない、②完了期限から検収・支払い・報告の期間を引くと余裕がない、③計画の目的や効果指標が変わる、④既存ベンダーの成果物・アカウント・設計資料を引き継げない、のいずれかです。

確認の順番は、制度資料で承認・届出の要否を確認し、次に契約書で責任と成果物を確認し、最後に技術担当と実現可能な工程を確定します。技術的に作れることと、補助事業として認められることは別の判断です。

判断結果は「継続」「事務局確認後に継続」「スコープを縮小」「発注先を変更」の4分類で記録します。分類、根拠資料、確認日、確認者、次の期限が残っていれば、担当者が変わっても同じ説明を再現できます。

• ・対象経費と見積の不一致
• ・期限から逆算した余裕不足
• ・目的・効果指標の変更
• ・成果物・アカウントの引継ぎ不能
• ・根拠・確認日・次期限の記録

証憑を後から集めないための対応表

実績報告の直前に書類を集めると、日付、宛名、金額、成果物名の不一致が見つかっても修正できません。発注前に案件番号を決め、見積・契約・発注・納品・検収・請求・振込・報告の各ファイル名と台帳の行番号をそろえます。

システム開発では、完成画面だけでなく、要件定義書、仕様変更履歴、テスト結果、利用開始記録など、何を作り何を確認したかが分かる資料を残します。制度ごとに必要書類が異なるため、最終的には該当する公募要領・手引き・実績報告ガイドを根拠にします。

以下の対応表を案件開始時に作り、空欄を「未取得」ではなく「取得担当者・取得予定日」まで具体化してください。空欄を放置したまま納品日を迎えることが、減額や報告遅延の最も早い兆候です。

• ・見積書：作業・工数・単価・前提
• ・契約書：成果物・検収・変更条件
• ・納品物：版数・受入基準・テスト結果
• ・請求・振込：金額・日付・宛名
• ・報告：制度様式・根拠ファイル・確認者

相談前に行う最終セルフチェック

相談を申し込む前に、制度名と公募回、交付決定日、実施期限、現在の発注段階、残予算、変更点、困っている判断を1枚にまとめます。資料が揃っていない場合も、不足資料を明記すれば初期整理は進められます。

セルフチェックで一つでも「不明」が残る場合は、開発会社に作業を急がせるより、制度上の確認先と技術上の確認先を分けて質問します。回答を口頭だけで終わらせず、資料名、ページ、回答日を記録してください。

GXOへの相談では、制度判断を代行するのではなく、案件情報を整理して実装可否、工程、責任分界、次の確認事項を可視化します。採択保証・補助額保証・制度事務局の代替ではないことを前提に、必要な専門家へつなぎます。

• ・制度名・公募回・基準日
• ・交付決定日・実施期限
• ・発注・開発・検収の現在地
• ・変更点と影響額
• ・次に聞く相手と質問

よくある質問

出典・公式情報

• ・中小企業新事業進出補助金 交付決定された方（公募要領・交付決定後の手続きは公募回ごとに確認）
• ・補助金等に係る予算の執行の適正化に関する法律（e-Gov）（補助金執行の基本法）
• ・中小企業庁 補助金・支援情報（制度の最新案内を確認）

制度の要件・金額・期限は年度や公募回で変わります。最終更新日（2026-07-21）時点の公式情報に基づいて執筆していますが、申請・契約の前に必ず公式サイトで最新情報をご確認ください。