依頼していたシステム開発会社から、突然「プロジェクトを続けられない」と告げられた。あるいは連絡が取れなくなった。もしかしたら倒産の噂を聞いた——。
このような状況は、決して珍しいことではありません。特に中小企業では、開発会社との力関係から、撤退を告げられても何もできないまま時間だけが過ぎてしまうケースも多く見られます。
では、開発会社に撤退された発注者は、何をどの順番でやればよいのでしょうか。この記事では「今すぐやるべき初動対応」から「損害賠償の進め方」「次の開発会社への引き継ぎ準備」まで、発注者の立場から実務的に解説します。
なお、ここでいう「撤退」には、開発会社からの一方的な契約解約・倒産・連絡途絶のいずれも含みます。それぞれのケースで対応が異なる部分は、該当するセクションで補足します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
開発会社が「撤退する」とはどういう状況か
撤退のパターン（3種類）
開発会社の撤退には、大きく3つのパターンがあります。
① 契約途中での一方的解約
最も多いケースです。開発が予想より難航した、採算が合わなくなった、担当エンジニアが退職したなどの理由で、開発会社側から「これ以上続けられない」と通告されます。
② 開発会社の倒産・廃業
開発会社が経営破綻するケースです。倒産の場合は破産管財人が介在するため、対応の流れが他のケースとは異なります。
③ 担当者消失・連絡途絶
フリーランスや小規模な開発会社に多いケースです。担当者が突然連絡に応じなくなる、Slackが既読にならない、といった形で実質的に業務が止まります。法的には契約関係はまだ存在しているため、書面での確認が必要です。
発注者が直面するリスク
撤退が起きると、発注者には以下のリスクが同時に降りかかります。
- 支払い済み費用の損失: 前払いした開発費用の回収が困難になる可能性
- ソースコード・設計書の喪失: 成果物を受け取れないまま終わるリスク
- リリーススケジュールの崩壊: ビジネス計画に直接影響
- 稼働中システムの保守空白: 既存システムを任せていた場合、誰も保守できない状態に
これらのリスクに優先順位をつけ、初動で何を確保するかを即断することが重要です。
撤退が発覚したら最初の48時間にやること
撤退を告げられた直後の行動が、その後の権利確保に大きく影響します。以下の4つを48時間以内に着手してください。
①証拠と通知の保全
撤退を告げるメッセージ・メール・Slackの通知は、すべてスクリーンショットと原文でバックアップしてください。将来の交渉や法的手続きで証拠として機能します。
口頭のみで告げられた場合は、「先ほどご連絡いただいた件について、書面（メール）にて確認させてください」と即座に書面化を要請してください。証拠のない口頭通知は交渉を不利にします。
②ソースコード・成果物の即時要求
開発途中のソースコード・設計書・要件定義書・環境情報（サーバー・DB構成・認証情報）の引き渡しを、書面で即日要求してください。
GitHubリポジトリのアクセス権がある場合は今すぐクローンしてバックアップを取ってください。サーバーへのアクセス権がある場合も同様です。撤退後に開発会社がリポジトリのアクセス権を削除するケースがあります。
③著作権の確認（契約書を読む）
ソースコードの著作権が誰に帰属するかを契約書で確認してください。以下のパターンがあります。
- 発注者帰属: 契約書に「成果物の著作権は発注者に帰属する」と明記されている場合 → 成果物の引き渡しを強く要求できます
- 開発会社帰属または不明: 契約書に明記がない場合 → 「著作権の取り扱い」について書面で合意を取りに行く交渉が必要です
著作権の帰属が不明確なまま開発会社が消えると、成果物を使い続けることが法的リスクになります。契約書の記載を確認のうえ、必要であれば弁護士への相談を検討してください。著作権の仕組みや帰属ルールの詳細については「システム開発の著作権は誰のもの？発注者が知っておきたい権利帰属と契約のポイント」で詳しく解説しています。
④支払いの状況確認（未払い残額がある場合）
未払い残額がある場合は、支払い手続きを一時停止してください。未払い分は、損害賠償請求の際に相殺に使える可能性があります。ただし、支払い保留の判断は法的なリスクも伴うため、金額が大きい場合は弁護士に確認してから判断することを推奨します。
クレジットカードで前払いしている場合は、カード会社への「チャージバック（決済取り消し）」申請も選択肢の一つです。ただし期限（多くは60日以内）があるため、早めの確認が必要です。
損害賠償・返金請求の進め方
開発会社に責任がある場合（債務不履行）
請負契約の場合、開発会社は「仕事の完成」を義務とします。納期までに完成できなかった場合や、プロジェクトの継続が不可能になった場合は、「債務不履行」として契約解除と損害賠償請求が可能です。
請求できる損害の範囲は以下の通りです。
- すでに外部に支払った費用（前払い開発費・サーバー費用など）
- 別の開発会社に再構築を依頼する費用
- プロジェクトのために生じた自社の人件費
- 逸失利益（立証が難しい場合が多い）
なお「ユーザー側に原因がある」場合（仕様の頻繁な変更・必要資料の未提出など）は、損害賠償請求が難しくなります。責任の帰属は一方的ではないケースも多いことを念頭に置いてください。
請負契約と準委任契約の違いと対応
請負契約の場合:「仕事の完成」を義務とするため、未完成での解除はベンダーの債務不履行になります。「催告解除（解除前に一定期間の是正を求める通知）」を行ったうえで契約解除・損害賠償請求に進むのが一般的な流れです。
準委任契約の場合:「作業の遂行」が義務であり、完成義務はありません。ただし、善管注意義務（専門家として適切な注意を払って業務を行う義務）違反があれば損害賠償を請求できます。フェーズ分けで準委任契約を結んでいるケースは多く、契約書の種別を確認してください。
請負契約と準委任契約の詳しい違いや選び方については「システム開発の請負契約と準委任契約の違いと選び方｜発注者のためのリスク判断ガイド」もあわせて参照してください。
倒産の場合の特殊対応
開発会社が倒産した場合は、通常の損害賠償交渉ではなく「債権申告」の手続きが必要です。
- 裁判所の公告または管財人からの通知で、倒産を確認する
- 破産管財人に債権者として申告する（申告期限が設定されている）
- 回収額は他の債権者との優先順位によって決まる（一般的には少額に留まるケースが多い）
倒産の場合は費用の全額回収は現実的に難しいことが多いです。ソースコード・成果物の確保を優先する判断が合理的です。
弁護士に相談すべきタイミング
以下のいずれかに該当する場合は、内容証明の作成や交渉代理の依頼を含めて弁護士への相談を検討してください。
- 損害が50万円以上と見込まれる場合
- 相手方が交渉に応じない場合
- 契約書の解釈に争いがある場合
- ソースコードの著作権帰属が不明確で使用継続リスクがある場合
IT系の法律問題を扱う弁護士（IT法務専門）に相談すると、より実務的なアドバイスが得られます。
次の開発会社への引き継ぎ準備
損害賠償と並行して、できるだけ早く「次の開発会社をどう選び、何を引き継ぐか」の準備を進めましょう。
引き継ぎに最低限必要なものリスト
引き継ぎ先の開発会社に渡すべきドキュメントの最小セットは以下の通りです。
カテゴリ | 内容 |
|---|---|
ソースコード | GitHubリポジトリのURL またはZIPファイル |
要件定義・仕様書 | 画面設計・機能一覧・API仕様 |
環境情報 | サーバー構成・DB構成・認証情報（環境変数を含む） |
開発進捗 | 完成済みの機能一覧・未完成の機能一覧 |
既知の問題 | バグリスト・技術的な課題・懸念点 |
これらが揃っていないほど引き継ぎの難度が上がり、追加費用と期間が発生します。前の開発会社から可能な限り受け取っておくことが重要です。
引き継ぎを受け入れてもらえる開発会社の条件
すべての開発会社が「他社が作ったシステムの引き継ぎ」を受け入れるわけではありません。以下の条件を満たす会社を選んでください。
- 他社引き継ぎ実績がある: Webサイトや問い合わせで実績を確認する
- コードレビュー・技術調査から始められる: 最初に現状把握フェーズを設けてくれる会社は信頼できる
- ドキュメントが不完全でも受け入れてくれる: ドキュメントゼロのシステムを調査した経験がある会社が望ましい
秋霜堂株式会社では、前任の開発会社が不在でドキュメントなしの既存システムの調査・改善対応を行った実績があります（詳細は事例紹介をご覧ください）。
引き継ぎの費用・期間の目安
引き継ぎには以下の期間と追加費用を見込んでください。
フェーズ | 期間 | 費用目安 |
|---|---|---|
新ベンダー選定・提案 | 2〜4週間 | — |
技術調査・コードレビュー | 2〜4週間 | 30〜80万円 |
開発再開・引き継ぎ完了 | 1〜2ヶ月 | 当初見積の30〜50%程度の追加 |
ドキュメントの整備状況・コードの品質・システムの複雑度によって大幅に変わります。
引き継ぎの具体的な手順・チェックリスト・ドキュメント準備については「システム引き継ぎの方法・手順・費用ガイド」で詳しく解説しています。
同じ失敗を繰り返さない契約書のポイント
最後に、今後の外注で同じリスクを繰り返さないための契約書チェックポイントを整理します。
契約書に必ず盛り込むべき5項目
① ソースコードの著作権帰属（発注者帰属を明記）
「本契約に基づき作成した成果物の著作権は発注者に帰属する」と明記してください。この一文があるだけで、撤退時の交渉力が大きく変わります。
② 中途解約時の成果物引き渡し義務
「いかなる理由で契約が終了する場合も、その時点での成果物（ソースコード・設計書・環境情報を含む）を発注者に引き渡す」という条項を入れてください。
③ 開発状況の定期報告義務
月次または隔週の進捗レポートを義務化してください。報告が止まることは撤退の前兆であることが多く、早期察知につながります。
④ マイルストーン払い（一括前払いを避ける）
開発を「要件定義完了・基本設計完了・開発完了」のマイルストーンで区切り、各フェーズ完了後に支払う形にしてください。一括前払いは発注者にとって最もリスクが高い支払い方法です。
⑤ 秘密保持・アクセス権管理の範囲
契約終了時に「発注者のシステムへのアクセス権限をすべて失効させる」条項を入れてください。撤退後も旧開発会社がアクセス権を持ったままになるリスクを防ぎます。
システム開発の保守契約における契約条項の詳細については「システム保守契約の種類と内容｜準委任・請負の選び方と記載すべき条項」もご参照ください。
まとめ: 撤退時の対処は「初動の速さ」が鍵
開発会社に撤退された場合の対処法をまとめます。
- 48時間以内: 証拠保全・ソースコード確保・著作権確認・支払い保留
- 1週間以内: 損害賠償の可否を判断（弁護士相談を含む）・次の開発会社の選定開始
- 1〜2ヶ月: 引き継ぎ先への移行・開発再開
最も重要なのは初動の速さです。証拠が消え、ソースコードへのアクセスが失われてからでは、できることが大幅に減ります。撤退を告げられたその日から、今日やるべきことを一つひとつ進めてください。
引き継ぎの具体的な進め方については「システム引き継ぎの方法・手順・費用ガイド」もあわせてご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
