補助金・実装

補助金案件で開発会社を変更する引き継ぎチェックリスト|回収すべき成果物12点

補助事業の開発会社が撤退・遅延・交代するとき、ソース、設計書、アカウント、データ、契約、証憑を回収し、残期間で引き継げるか判定する方法を解説します。

公開日:2026-07-21

最終更新日:2026-07-21

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

ARTICLE BODY

記事本文

ここから、判断に必要な確認項目と実務の進め方を解説します。

補助金案件で開発会社を変えるとき、最初に探すのは新しい会社ではありません。現ベンダーから何を回収できるか、契約上どこまで受領済みか、残期間で新会社が再現できるかを先に判定します。成果物がないまま会社だけ替えると、同じ要件定義をやり直し、期限と予算を二重に失います。

引き継ぎは技術、契約、補助事業の3本を同時に扱います。技術的に動いてもソースやアカウントがない、契約上利用できても交付計画と違う、制度上変更可能でも残期間で検収・支払いまで終わらない、といった分断を防ぎます。

この記事では回収物12点、引継ぎ可能性スコア、旧新ベンダー会議、事務局照会の順番を示します。変更承認の一般判断は計画変更・ベンダー変更の記事を先に確認してください。

最初の48時間:停止・保全・権限確認を先に行う

障害や関係悪化があっても、感情的にアカウントを停止したり契約解除通知だけを先行させたりしません。まず本番サービスへの影響、バックアップ、ログ、ドメイン、クラウド、ソース管理、決済、外部連携の管理者を確認します。止めると復旧できない権限があります。

現状の稼働版、開発版、申請時想定を分けて保存します。画面だけでなく、構成、データ、設定、バージョン、未解決課題、直近バックアップ時刻を記録します。引き継ぎ前の基準点を作らなければ、移管後の不具合責任を切り分けられません。

補助事業の完了期限と報告期限から、引き継ぎ判断に使える日数を算出します。新会社選定、調査、再設計、開発、検収、支払いを置き、全部入りで間に合わなければ、移管対象を絞るか中止・変更を含めて事務局へ相談します。

回収すべき成果物12点:ファイル名でなく再現可能性を見る

「ソース一式を受け取った」だけでは不十分です。第三者が同じ環境を構築し、データを安全に移し、要件と試験結果を追えるかで判定します。最新版、履歴、実行手順、利用権限をセットで確認します。

契約書に納品物として書かれていないものは、追加交渉が必要な場合があります。著作権、利用許諾、第三者ライブラリ、クラウド契約、秘密情報を確認し、受領できると決めつけません。必要に応じ法律・契約の専門家へ確認します。

  • 1. 要件定義書・機能一覧・申請計画との対応表
  • 2. 画面・帳票・API・データ・権限の設計書
  • 3. ソースコード、履歴、ブランチ、ビルド・デプロイ手順
  • 4. クラウド構成、環境変数一覧、契約名義、管理者権限
  • 5. データベース定義、バックアップ、移行・復元手順
  • 6. ドメイン、DNS、証明書、メール、外部サービスの権限
  • 7. テスト仕様、結果、不具合、未完了、既知制約
  • 8. 操作手順、運用手順、障害対応、監視・ログ
  • 9. 見積、契約、発注、変更、議事録、承認履歴
  • 10. 納品、検収、請求、支払い、写真・画面等の証憑
  • 11. OSS・商用ライセンス、再配布・利用条件
  • 12. 残タスク、優先順位、担当、期限、問い合わせ先

引継ぎ可能性スコア:0・1・2点で移管、縮小、停止を分ける

12点それぞれを、0点=存在しない・権限不明、1点=存在するが最新版・再現性が未確認、2点=第三者が閲覧・復元・実行できる、で採点します。合計だけでなく、ソース、データ、クラウド権限、契約、期限は必須項目にします。

20点以上かつ必須項目が2点なら通常移管候補、12〜19点または必須項目に1点があれば限定スコープ移管、11点以下または必須0点があれば再構築・中止・計画変更を含めて経営判断します。これは制度可否ではなく、技術移管の一次判定です。

点数表には確認者、証拠URL、確認日を残します。「あると聞いた」では1点にせず、実ファイルや権限で確認します。証憑チェックリストと対応させると、移管後の実績報告準備にも使えます。

旧新ベンダー会議と事務局照会の順番

旧ベンダーには回収物、未完了、引き渡し方法、質問期間を確認します。新ベンダーには不足物、再調査工数、再利用可能範囲、最小成果物、検収条件を回答させます。事業者は契約と予算、支援者は制度照会を担当します。

事務局へは「ベンダー変更できますか」だけでなく、変更前後の事業者、機能、方式、経費、期限、効果、既発注・支払い、代替案を提出できる形にします。新契約や実装前に承認・届出の要否を確認します。

旧ベンダーとの紛争や契約解除は、補助事業の変更承認とは別です。制度上進められても契約上の権利がない場合があり、その逆もあります。技術・契約・制度の三列で判断を分けます。

新ベンダーへ出す引き継ぎRFP:不足を隠さず見積条件にする

新会社への依頼書には、完成希望だけでなく、回収済み資産、欠落、既知不具合、現行環境、利用者、残期間、補助事業の必須成果物を記載します。調査前に固定総額を求めると、欠落分が追加費用か未対応として後から戻ります。

見積は調査・保全、再現環境、必須修正、移行、検収、報告資料を分けます。調査ゲート後に確定見積へ移る二段階契約も検討し、調査だけで期限を使い切らない上限日と終了条件を置きます。

比較表には価格だけでなく、回収物の再現確認、欠落時の代替、担当体制、境界試験、ソース・アカウントの納品、質問受付期間を入れます。交付申請見積の7項目と同じ粒度で、移管費と実装費を分けます。

  • 調査終了条件:再現可否、不足、残工数、最小成果物を提示
  • 移管終了条件:第三者権限、復元試験、運用手順、納品一覧を確認
  • 実装終了条件:要件ID、試験、検収、証憑、残課題を照合

まとめ:会社変更より先に再現可能性を確保する

安全な引き継ぎは、次の会社の実績ではなく、現行資産を第三者が再現できるかから始まります。12点の回収物、必須項目、残期間を見れば、移管・縮小・再構築・停止を早く分けられます。

交付決定済みでベンダー撤退・遅延がある場合はレスキュー窓口で状況を確認し、案件受付へ回収済み項目、期限、発注・支払い状態を送ってください。

よくある質問

ソースコードがあれば引き継げますか?

ソースだけでは足りません。履歴、ビルド手順、環境、データ、権限、ライセンス、テスト、未完了を第三者が再現できる必要があります。

旧ベンダーとの契約解除を先にすべきですか?

稼働・権限・バックアップ・納品義務への影響を確認してから判断します。契約と制度の専門家を交え、回収不能になる順序を避けます。

新ベンダーへの変更は事務局承認が必要ですか?

一律には判断できません。機能、方式、経費、期限、効果への影響を差分表にし、新契約・実装前に事務局へ確認してください。

期限が短い場合は何を優先しますか?

補助事業目的を満たす最小成果物、検収、支払い、報告準備を優先し、残りを自費の後続開発へ分けられるか確認します。

出典・公式情報

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