進め方

補助金×システム開発は誰が何を担うか:士業と開発会社の役割分担

補助金を使うDX・システム開発では、制度・税務・労務の確認と、要件定義・開発・検収の実務が別レーンで走ります。士業と開発会社の分担表の作り方を解説します。

公開日:2026-06-24

最終更新日:2026-07-03

編集:はたらく士業さん編集部(GXO株式会社)

補助金を使ってシステム開発やDXを進めるプロジェクトでは、「制度・税務・労務の確認」と「要件定義・開発・検収の実務」という2本のレーンが同時に走ります。結論を先に言うと、前者は税理士・行政書士・社労士といった士業の領域、後者は開発会社の領域であり、発注者である企業側がこの分担表を最初に作っておくことが、プロジェクトを止めないための最重要ポイントです。

分担が曖昧なまま走り出すと、「補助対象経費の線引きを誰も確認していなかった」「検収書の日付が支払いと整合しない」といった、どちらの専門家の守備範囲でもない空白地帯で問題が起きます。この記事では、士業が担う領域、開発会社(GXOのような実装パートナー)が担う領域、そして発注者自身にしかできないことを分けて整理します。

なぜ空白地帯で事故が起きるのか

士業は制度と法令の専門家ですが、システムの要件定義や検収の技術的な妥当性は判断しません。開発会社は作ることの専門家ですが、その支出が補助対象経費に当たるか、会計・税務上どう処理すべきかは判断しません。つまり、補助金×システム開発のプロジェクトには、どちらの職域にも属さない接続部分が構造的に存在します。

典型的な事故は、この接続部分で起きます。たとえば、開発途中で仕様変更が発生したのに交付申請時の計画との差分を誰も制度側へ照会していなかった、開発会社の請求書の費目名が公募要領上の経費区分と対応しておらず実績報告で説明に窮した、といったケースです。個別の運用は制度ごとに異なるため、変更時の手続きは必ず各事務局の公式情報で確認する必要がありますが、「誰が確認するか」を決めていなければ確認自体が漏れます。専門家を増やせば解決する問題ではなく、接続部分の担当を名指しで決めることが解決策です。

士業レーンが担うこと

士業レーンの中心は、制度要件・お金・人にかかわる判断の確認です。税理士は、投資の資金繰り、補助金入金までのつなぎ資金、採択後の会計処理・税務上の取り扱いを見ます。行政書士は、申請書類・事業計画書の作成支援や、許認可がからむ場合の手続き確認を担います。導入するシステムが勤怠・給与など労務領域に触れるなら、就業規則や労働時間管理との整合を社労士に確認します。

どの士業に何を聞くべきかの詳しい切り分けは補助金は税理士・行政書士・社労士の誰に相談すべきかの特集で扱っていますが、要点は「制度・法令に照らした適否の判断は士業に集約する」ことです。制度情報そのものはミラサポplusや各事務局サイトで一次情報を確認し、金額や締切を伝聞で扱わないことも徹底してください。

開発会社レーンが担うこと

開発会社レーンの中心は、投資対象そのものを形にする実務です。具体的には、現状業務のヒアリングと要件整理、開発範囲と成果物の定義、概算見積の作成、開発・テスト、検収条件の設計、稼働後の保守運用体制までが含まれます。補助金プロジェクトでは特に、申請書に書いた計画と実際に作るものが乖離しないよう、要件の解像度を申請前に上げておくことが重要です。

GXOのような開発会社がこのレーンで果たせるもう一つの役割が、スケジュールと成果物の管理、いわゆるPMO(プロジェクトマネジメントオフィス:進行管理の専任機能)です。交付決定から実績報告までの期限は制度側で決まっているため、開発の遅延はそのまま補助金の受給リスクに直結します。要件整理や概算見積の段階から相談したい場合は、開発の概算見積窓口を早めに使い、見積の内訳を経費区分と対応づけられる形で出してもらうと、士業レーンとの接続が滑らかになります。

発注者にしかできないこと

両レーンの専門家を揃えても、発注者自身にしか担えない仕事が残ります。第一に投資判断そのものです。補助金の有無にかかわらずこの投資をやるのかという意思決定は、外部の誰にも代行できません。補助金は投資額の一部を後から支援する仕組みであり、投資の成否そのものを保証するものではないからです。第二に社内の情報提供と体制づくりです。現場の業務実態、既存システムの契約状況、経理の締めルールといった情報は社内にしかなく、これが出てこないと両レーンとも止まります。

第三に、レーン間の橋渡し役の任命です。士業とのやり取り、開発会社とのやり取り、事務局への照会の窓口を誰が持つのかを決め、書類・証憑の保管場所を一元化します。専任でなくて構いませんが、「全体を見ている人」が社内に1人いるかどうかで、プロジェクトの安定度は大きく変わります。

キックオフ前に作る分担表のひな形

実務では、プロジェクト開始前に次のような項目を縦軸に、担当(社内・士業・開発会社)を横軸にした簡単な表を作ることをおすすめします。埋まらないマスがあれば、それが空白地帯です。表はスプレッドシート1枚で十分で、関係者全員が同じものを見られる状態にしておくことが大切です。

この表はキックオフ時に一度作って終わりではなく、交付決定・開発着手・検収といった節目ごとに見直します。プロジェクトの後半に進むほど証憑や報告書類の比重が増え、担当の重心が変わっていくためです。

  • 制度選定・公募要領の読み込み:社内+士業
  • 事業計画・申請書類の作成:社内+士業(書類作成支援)
  • 資金繰り計画・会計処理方針:社内経理+税理士
  • 要件定義・見積・開発・テスト:社内担当+開発会社
  • 仕様変更時の制度側への照会判断:士業(開発会社から変更情報を受領)
  • 検収・支払・証憑の整理:社内+開発会社(検収)+税理士(経理処理)
  • 実績報告書類の作成・提出:社内+士業

この体制をどう組み始めるか

既に顧問税理士や付き合いのある開発会社がいるなら、まず両者に「補助金を使う前提のプロジェクトである」ことを伝え、上記の分担表を叩き台に守備範囲を確認するところから始めてください。補助金案件だと最初に伝えるだけで、見積の書き方や書類の残し方が変わり、後工程の手戻りを減らせます。相談先がまだ決まっていない場合は、相談先診断で必要な専門領域を整理し、補助金対応の士業一覧から候補を比較する流れが使えます。

なお、電子申請の多くはjGrants経由で行われ、事業者側のGビズIDアカウントが必要です。アカウント取得には時間がかかる場合があるため、体制づくりと並行して早めに準備しておくことも、発注者側のタスクとして忘れないでください。

よくある質問

開発会社に補助金申請の支援まで頼んでもよいですか?

開発会社が制度情報の提供や見積の経費区分対応などで協力することはできますが、税務・労務・法令適合の判断は士業の領域です。「申請もまとめて任せられる」という営業トークだけで判断せず、制度・法令面の確認体制が別にあるかを確認してください。

小規模な案件でも分担表は必要ですか?

規模が小さくても、確認漏れが起きる構造は同じです。A4半分程度の簡単な表で十分なので、「誰も担当していない項目がないか」だけは着手前に確認することをおすすめします。

士業と開発会社が直接やり取りしてくれますか?

発注者が場を設定すれば可能ですし、仕様変更や経費区分の確認では直接連携が有効です。ただし契約関係はそれぞれ発注者との間にあるため、決定事項は必ず発注者を通す運用にし、言った言わないを防いでください。

GXOに相談すると士業も紹介してもらえますか?

はたらく士業さんは公開情報に基づいて相談先候補を探せるポータルであり、開発の相談と士業探しは別々に進められます。開発側の要件整理はGXOの見積窓口へ、制度・税務・労務の確認は本ポータルで探した士業へ、と入口を分けて使ってください。

出典・公式情報

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