補助金・助成金を活用したシステム開発で必要になりやすいドキュメント一覧
補助金・助成金を活用して新規事業や業務改善のシステム開発を進める場合、開発会社に求められるのは実装だけではありません。
申請前には、何をどこまで作るのかを説明できる見積もりや資料が必要になります。採択後は、契約、納品、検収、支払いの流れを、制度上確認できる形で残す必要があります。
もちろん、必要書類は制度や公募回によって変わります。最終的には各制度の公募要領、交付規程、補助事業の手引きを確認する前提です。
そのうえでこの記事では、開発会社の立場で用意を求められやすいドキュメントに絞って整理します。
まず全体像。必要資料は3段階に分かれる
補助金・助成金を活用したシステム開発では、資料を次の3段階で考えると整理しやすいです。
- 申請前に、開発内容を説明する資料
- 採択後に、発注と進行を証明する資料
- 完了後に、納品と支払いを証明する資料
制度によって名称は変わりますが、開発会社が関わる実務はおおむねこの流れに集約されます。
1. 申請前に必要になりやすい資料
見積書
最初に求められやすいのが見積書です。
ただし、補助金案件では単に金額が書かれていればよいわけではありません。制度によっては、金額の妥当性や内訳の明確さが見られます。
開発見積では、少なくとも次のような粒度に分けておく方が安全です。
- 要件定義
- 基本設計
- 画面設計
- バックエンド開発
- フロントエンド開発
- インフラ構築
- テスト
- プロジェクト管理
「システム開発一式」のような書き方だけでは、後で説明が難しくなります。実際、補助金の手引きでは、金額に複数項目が含まれる場合は内訳を示すことや、「一式」のみでは不十分とされる例があります。
開発概要資料
申請者側の事業計画では、「そのシステムで何を実現するのか」を説明する必要があります。
その補助資料として、開発会社側では次のような資料が役立ちます。
- 開発目的
- 解決したい業務課題
- 対象ユーザー
- 実装予定の主要機能
- 導入後に変わる業務フロー
これは厳密な要件定義書まで作り切る前の段階でも構いません。申請時点では、開発内容を第三者に説明できる水準まで構造化されていることが重要です。
要件定義書または仕様整理資料
制度によっては、価格の妥当性を確認するために仕様書等の提出を求められる場合があります。
開発案件でいうと、次のような資料がこれに近い役割を果たします。
- 要件定義書
- 機能一覧
- 画面一覧
- 権限一覧
- 外部連携の有無
- データ項目や帳票の概要
補助金の申請段階から、すべてを詳細設計まで落とし込む必要はありません。ただし、見積金額の根拠が説明できる資料は用意しておいた方が後工程で詰まりにくくなります。
開発スケジュール
補助事業には実施期間があります。開発期間が制度のスケジュールに収まるかを見せるために、工程表が必要になります。
最低限、次の工程が見える状態にしておくと整理しやすいです。
- 要件定義
- 設計
- 実装
- テスト
- 納品
- 検収
補助金案件では、採択後に着手する前提や、完了期限までに納品・検収を終える必要があるケースもあります。開発スケジュールは「いつ作るか」ではなく、制度上いつまでに何を完了させるかまで含めて考える必要があります。
2. 採択後に必要になりやすい資料
契約書、発注書、受注書
採択後に開発を進める段階では、発注関係の証跡が必要になります。
一般的には、次のいずれかです。
- 契約書
- 発注書と受注書
- 業務委託契約書
制度ごとに求め方は異なりますが、重要なのは、誰が、何を、いくらで、いつまでに発注したかが追えることです。
仕様確定資料
申請時点の資料から内容が更新されることは珍しくありません。
その場合でも、補助対象として説明していた内容と、実際に発注・開発した内容が大きくずれないように整理する必要があります。
開発会社側では、次のような資料があると確認しやすくなります。
- 最終機能一覧
- 画面構成
- データ設計の概要
- 外部サービス連携の整理
- 非機能要件の概要
制度によっては計画変更の手続きが必要になることもあるため、仕様変更が出たときに「何が変わったか」を説明できる状態にしておくことが重要です。
3. 完了後に必要になりやすい資料
納品書または引渡書
システム開発では、成果物が物理的な機械のように見えにくいため、納品の証跡を明確にしておく必要があります。
たとえば、
- システム一式の納品
- ソースコードの納品
- 設計書一式の納品
- 管理画面、利用者画面、APIなどの納品対象
を文書上で明確にします。
検収書
補助事業の手引きでは、検収書または検収の事実が分かる資料を求める例があります。
システム開発の場合も、
- 納品物を確認した日
- 受領者
- 問題なく受領した旨
を記録しておくことが大切です。
成果物が分かる資料
開発費を補助対象として説明する場合、何が実際に作られたかを示す資料が必要になることがあります。
開発案件では次のようなものが候補です。
- 画面キャプチャ
- 画面一覧
- 設計書
- テスト結果
- 利用マニュアル
- 実装された機能の説明資料
実際にどこまで求められるかは制度によります。ただ、あとから慌てて集めるより、納品時点で「成果物一覧」をそろえておく方が安全です。
請求書、支払証跡
完了後には、請求書と支払証跡も重要になります。
補助金の実績報告では、契約、納品、検収、請求、支払いの流れが整合しているかを確認されることがあります。
開発会社が直接用意するものは請求書ですが、申請者側で必要になる銀行振込記録や支払証跡とつながるよう、請求内容と見積・契約内容に齟齬がないことが重要です。
実務上、特に詰まりやすいポイント
見積書が粗すぎる
あとで最も説明に困りやすいのが、見積書の粒度です。
「開発一式」「設計一式」だけだと、なぜその金額なのか説明しにくくなります。見積段階から、工程と対象範囲を分けておく方が、申請にも採択後の確認にも使いやすくなります。
申請資料と実際の仕様がずれる
申請時は粗く、採択後に仕様が具体化する。これは普通に起きます。
ただし、申請時に示した事業内容と、実際に発注する内容の差が大きいと、確認が必要になる場合があります。開発会社側でも、変更点を説明できるようにしておくと進行が安定します。
納品と検収が曖昧
Webサービスや業務システムは、完成の境界が曖昧になりがちです。
補助金案件では「いつ納品したか」「何をもって完了としたか」が重要になるため、納品書、検収書、成果物一覧を最初から意識して進める必要があります。
最低限そろえたい一覧
最後に、開発会社側で意識したい資料を一覧で整理します。
申請前
- 見積書
- 開発概要資料
- 要件定義書または仕様整理資料
- 機能一覧
- 画面一覧
- 開発スケジュール
採択後
- 契約書または発注書・受注書
- 仕様確定資料
- 変更点の整理資料
完了後
- 納品書または引渡書
- 検収書
- 成果物一覧
- 設計書、画面キャプチャ、テスト結果などの成果説明資料
- 請求書
まとめ
補助金・助成金を活用したシステム開発では、開発会社にも通常案件以上の説明責任が求められます。
重要なのは、単に「書類を出す」ことではありません。
- なぜその開発が必要か
- 何を作るのか
- なぜその金額なのか
- 何を納品したのか
を、第三者が追える形で残すことです。
JUICE UPでは、補助金・助成金を活用したシステム開発について、見積もり、要件整理、設計資料、審査時の確認対応、採択後の開発まで一貫してご相談いただけます。制度要件や申請手続きの確認が必要な場合は、必要に応じて専門家とも連携します。