システム開発キックオフで決めるべきこと — 補助金案件のチェックリスト

システム開発でトラブルになるプロジェクトの多くは、技術的な難しさよりも「キックオフで詰め切らなかった合意」が後から効いてくるパターンに収束します。スコープの曖昧さ、変更管理のフロー不在、著作権の帰属確認漏れ——どれも初期に2時間使えば防げる論点ばかりです。補助金を活用する案件ではさらに、交付決定日と発注タイミングの順序、実績報告に必要な証拠書類、補助対象経費の区分という「制度側の制約」が重なります。本記事では、システム開発のキックオフで必ず合意したい7項目と、補助金案件で追加すべき論点を、実務目線で整理します。なお、補助金申請業務は行政書士法人Treeが、システム開発はTechSyncが担当する分業体制で、改正行政書士法（2026年1月施行）に沿った業務分担を行っています。

通常案件で必ず合意したいキックオフ7項目

補助金の有無に関係なく、システム開発のキックオフで詰めておきたい論点は、おおむね次の7項目に集約できます。順序にも意味があり、上から順に決めていくと、後の項目の前提が固まっていく構成です。

1. スコープと「やらないこと」リスト

「何を作るか」と同じくらい重要なのが、「何を作らないか」を明文化することです。たとえば「将来的なスマホアプリ化」「外部CRMとの双方向連携」「多言語対応」など、議論の途中で名前が挙がった項目をスコープ外として合意書に列挙しておきます。後から「言った言わない」の議論を避けられるだけでなく、補助金案件では「補助対象範囲はどこまでか」を明確化する根拠資料にもなります。

2. 成功の定義と完了基準

「成功」と「完了」は分けて考えるのが実務的です。成功は事業上の指標（KGI／KPI）で、たとえば「半年後にオンライン受注比率を30%にする」など、システムが事業にどう貢献するかを示します。完了基準は機能要件・非機能要件をクリアしたかどうかで、「注文完了メールが5秒以内に届く」「月間500件の受注処理に耐える」のように数値で測れる条件で定義します。両方を最初に握っておくと、リリース後の評価会議の論点が揃います。

3. コミュニケーション方法と頻度

週次進捗報告の形式、緊急連絡先、レビュー会の頻度、議事録の担当者を最初に決めます。変更依頼の受付ルートも合わせて合意し、口頭だけで進めず、チケット・メール・議事録など記録に残る形で管理する運用にします。チャットツールを併用する場合でも、決定事項は議事録やチケットに転記する習慣をつけておくと、後から経緯を追えます。

4. 変更管理プロセス

開発中に要件が変わるのは普通のことなので、「変わらない前提」ではなく「変わったときにどう処理するか」を決めておきます。一般的なフローは「変更依頼書の提出 → 影響範囲の見積もり → 工数・費用・スケジュールの提示 → 承認 → 着手」です。補助金案件では、変更が補助対象経費・事業計画・納品物に影響する場合、補助対象として認められるかの確認が追加で必要になるため、変更管理フローに「事務局・補助金担当への確認ステップ」を明示的に組み込みます。

5. 検収・テストの責任分担

「ベンダーが単体テスト・結合テスト・システムテストを行い、クライアントが受入テスト（UAT）を行う」という分担を、テスト項目書のサンプルとセットで合意します。UATの期間、不具合の重大度区分（致命的・重要・軽微）、修正サイクルも事前に決めておくと、検収段階で揉めにくくなります。補助金案件では、ここでの納品物・検収書・画面キャプチャがそのまま実績報告の証拠書類になります。

6. ソースコードの著作権・所有権

意外に見落とされがちな論点が著作権の帰属です。著作権法上、プログラムの著作権は創作した人に原始的に発生し、開発会社の従業員が業務として作成した場合は職務著作（著作権法15条）として開発会社（ベンダー）に帰属するのが原則です。発注しただけではクライアントへ自動的に移転しないため、クライアントへ譲渡したい場合は契約書で明示が必要で、二次的著作物の作成・利用に関わる著作権法27条・28条の権利についても、譲渡の対象に含む旨を明記しなければ譲渡対象外と推定されます。経済産業省の情報システム・モデル取引契約書でも、知的財産権は契約上の重要論点として整理されています。既存モジュール・汎用部品・OSSライブラリは切り分け、ライセンス条件と二次配布の可否を別途確認します。

7. 本番環境・インフラ費用の負担

AWS・GCP・Azure等のインフラ費用を誰が負担するか、初期設定費・月額利用料・保守費用をどの範囲まで開発費に含めるかを明確にします。クラウド利用費は、運用フェーズに入ると毎月発生し続けるため、補助事業期間が終わった後の負担まで含めて合意しておきます。外部API（決済、SMS、メール配信など）を組み合わせる場合は、API経済圏の考え方を整理した記事も参考に、ランニングコストの予測を共有しておくと安心です。

補助金案件で追加すべきキックオフ論点

ここから先は、補助金を活用するプロジェクトで追加すべき論点です。これらを見落とすと「採択されたのに補助金を受け取れない」という最悪のケースに直結します。補助金ごとに細部は異なりますが、共通する考え方は「制度のスケジュールにシステム開発のスケジュールを合わせる」ことに尽きます。

交付決定日と発注・契約・支出のタイミング

補助金案件で最も重要なのが、交付決定日と発注・契約・支出の順序です。小規模事業者持続化補助金の公式FAQでも、交付決定日以後でなければ発注・契約・支出は補助対象とならないことが明示されています。「採択発表＝開発開始」と誤解すると、その時点での発注・契約はすべて補助対象外になり、自己負担となります。キックオフでは、申請 → 採択 → 交付申請 → 交付決定 → 発注・契約・着手 → 納品・検収 → 支払い → 実績報告という流れを関係者全員で確認します。

実績報告で必要になる証拠書類群

「実績報告は補助金案件の本番」と言われるほど、書類の整備が結果を左右します。一般的に必要となる証拠書類は、見積書、発注書、契約書または請書、納品書、検収書、請求書、支払証憑（振込控）、領収書、成果物確認資料（画面キャプチャ・公開URL・操作マニュアル等）です。「完了証明書」という単一様式があるわけではなく、補助金や事業内容により様式名や必要書類は異なります。キックオフで「誰がいつ発行・受領し、どこに保管するか」を担当者単位で決めておくと、実績報告フェーズでの再収集を防げます。

補助対象経費と対象外経費の区分

保守費・ライセンス継続費・サーバー費用などは、補助金により扱いが分かれます。小規模事業者持続化補助金では原則として保守費・継続費は対象外ですが、ものづくり補助金やデジタル化・AI導入補助金（旧IT導入補助金。2026年の事業から名称変更）では、補助事業実施期間内のクラウド利用料やSaaS利用料が一定期間（後者は最大2年分）対象となる場合があります。「対象になる前提」で見積もりに含めてしまうと、後から外す調整に時間がかかるため、見積書の段階で対象・対象外の欄を分けて記載しておくと安全です。

補助事業実施期限と実績報告期限の把握

補助事業実施期限と実績報告期限は別物です。実施期限までに「発注・契約・納品・検収・支払い」を完了させ、そのうえで実績報告期限までに必要書類を提出する流れになります。キックオフで両方の日付をプロジェクト管理ツールに明示し、納品スケジュールから逆算して「実装完了」「UAT完了」「支払い完了」「実績報告提出」の各マイルストーンを引いておきます。

申請業務とシステム開発業務の役割分担

補助金申請書類の作成は、改正行政書士法（2026年1月1日施行）により、行政書士または行政書士法人の独占業務として明確化されています。TechSyncを含むシステム開発会社が、報酬を得て申請書類を作成・補正することはできません。本案件では、申請関連業務は行政書士法人Tree、システム開発はTechSyncという分担を最初に共有し、依頼者側の窓口が混乱しないようにしておくのが安全です。

変更時の事務局確認フロー

事業内容や経費区分に影響する変更が発生した場合、補助金事務局への計画変更申請が必要になることがあります。キックオフで「軽微な変更（事務局確認不要）」と「重要な変更（事務局確認・承認必要）」の区分目安をすり合わせ、変更管理フローに「事務局・補助金担当への確認ステップ」を明示します。判断が難しい場合は早めに事務局に問い合わせるのが鉄則で、後から「やってしまった」変更ほど対象外判定のリスクが高くなります。

トラブル事例から学ぶキックオフ設計の勘所

実際にキックオフ不足から発生しがちなトラブルを、3つのパターンで紹介します。どれも「最初の2時間」で防げる類のものです。

スコープ膨張による補助対象範囲のズレ

当初「ECサイトの基本機能」で合意していた案件で、開発中盤に「SNS連携」「定期購入」「越境配送」が次々と追加され、結果として補助対象に申請していた構成と納品物が乖離してしまうケースがあります。事業計画書に書いた機能と納品物が一致しないと、実績報告で補助対象として認められないリスクがあります。対策は、スコープ変更のたびに「事業計画書の記載との整合性」を確認するチェックポイントを設けることです。持続化補助金でEC構築する際の論点を整理した記事もあわせてご覧ください。

交付決定前の発注による補助対象外化

「採択されたから安心して開発委託契約を結んだ」が、実は交付決定はその数週間後だった、というケースは少なくありません。採択発表と交付決定は別タイミングで、交付決定日より前の発注・契約・支出は原則として補助対象外になります。対策は、契約書の発行日・押印日を交付決定日以後にすることと、見積書を「お見積もり」段階で止めておき、交付決定後に正式な発注書を発行する運用にすることです。

著作権譲渡条項の漏れによる二次利用トラブル

「納品されたシステムを社内で改修したい」「別ベンダーに引き継いで機能追加したい」というニーズが発生したとき、契約書に著作権譲渡や利用許諾の条項がないと、原則としてベンダー側の同意が必要になります。さらに、譲渡条項があっても著作権法27条・28条の権利を含む旨が明記されていないと、二次的著作物の作成・利用について争いが残ります。対策は、契約書のドラフト段階で著作権条項のテンプレートを共有し、キックオフで「譲渡か利用許諾か」「既存モジュール・OSSの扱いはどうか」を関係者全員に説明することです。

よくある質問

※ 本記事は執筆時点の情報をもとに作成しています。補助金の制度・要件は変更されることがあります。最新情報は各省庁・公募要領を必ずご確認ください。