システム開発の失敗から立て直す｜途中で止まった開発、連絡が取れない開発会社への対処と判断の順番

開発が途中で止まったら、原因探しより先に確保すること

約束の納期を何ヶ月も過ぎている。開発会社の担当者から返事が来ない。納品されたシステムを触ると、画面が開かない。外注した開発がこうした状態になると、発注担当者は社内への説明と、相手への怒りと、この先の見通しの無さを同時に抱えることになります。

このとき最初にやりがちなのが、相手の非を問う長いメールを書くことです。気持ちは自然ですが、関係が決裂した後に「ソースコードがどこにあるか分からない」「サーバーのログイン情報を持っていない」と気づくと、立て直しの選択肢が大きく減ります。責任の話は、記録と資産を確保してからでも遅くありません。

一般に「システム開発の失敗」と呼ばれるのは、システムが完成しない、納期や予算を大きく超える、完成しても品質が低く業務で使えない、といった状態です。遅延そのものは珍しい出来事ではありません。日本情報システム・ユーザー協会 (JUAS) の 企業 IT 動向調査 2025 (24 年度調査) は、東証上場企業とそれに準じる企業を対象とした調査 (回答 981 社) です。システム開発の工期について「予定より遅延」と答えた割合は、100 人月未満で 16.6%、100〜500 人月未満で 33.8%、500 人月以上で 43.7% でした (ほかの選択肢は「予定どおり完了」「ある程度は予定どおり完了」)。

本記事は、開発が 途中で止まった緊急の状況 に絞って、発注者が取る行動を順番に整理します。平時に開発会社を乗り換える手順は システム引き継ぎの進め方、失敗につながる兆候の自己診断は システム導入が失敗する 12 の兆候 で扱っています。契約や紛争の話も出てきますが、本記事は一般的な情報の提供であり、個別の案件に対する法的助言ではありません。

最初の 1 週間で手元に確保する 4 つのもの

開発会社との関係がこれ以上悪くなる前に、次の 4 つが自社の管理下にあるかを確かめます。すべてを今日そろえる必要はありませんが、どれが欠けているかは今日中に把握します。

確保するもの	具体例	確認の仕方
その時点のソースコード	GitHub などのリポジトリ、最新のコードの複製	自社アカウントで閲覧できるか。できなければ複製の提供を依頼する
環境とサービスの権限	サーバー・クラウドの管理画面、ドメイン、外部サービスの契約	契約名義と支払い元が自社か、管理者として入れるか
仕様と意思決定の記録	要件定義書、画面案、議事録、メール・チャット、課題管理のチケット	共有フォルダやチャットの履歴を自社側でエクスポートしておく
契約書と支払いの記録	基本契約、個別契約、発注書、見積書、検収書、請求書、振込記録	何の対価として、いつ、いくら払ったかを 1 枚の表にまとめる

権利の整理は システム開発の著作権は誰のもの？ に譲り、ここでは現物の確保を優先します。

やり取りと支払いは、日付・出来事・決めたこと・根拠の記録 (メールやチケットの所在)・支払い、の列を持つ時系列表にまとめておきます。同じ表を、交渉にも、弁護士への相談にも、次の会社の調査にも使えます。

FIXIT

まず怒りのメールを送りたいんだけど、それじゃだめなの？

Shiori

だめではないですが、整理すると先にコードと権限と記録の確保です。

状況を診断する ─ 遅れているのか、止まっているのか、動かないのか

「開発がうまくいっていない」という一言には、性質の違う状態が混ざっています。どれに当たるかで、次に打つ手が変わります。

状態	よく見られる様子	開発会社に書面で確認すること
遅れているが進んでいる	納期は過ぎたが、画面や機能は少しずつ増えている	残作業の一覧、再見積もりした完了時期、遅延の理由
作業が止まっている	数週間、成果物もリポジトリの更新もない	作業を続ける意思、担当者と体制、再開の予定
連絡が取れない	返事が来ない、担当者が退職した、会社として応答がない	窓口の変更、契約の継続可否
納品物が動かない	検収前後で、主要な操作がエラーになる	不具合の一覧、修正の計画、テストの実施状況

連絡が取れない場合は、表の確認事項を内容証明郵便など記録が残る手段で送ります。

ここで見たいのは、相手に悪意があるかどうかではありません。今の開発会社が、現状と見通しを具体的に説明できるか です。残作業と完了時期を根拠付きで示せるなら、条件を見直して続ける余地があります。説明が出てこない、あるいは説明のたびに完了時期だけが延びるなら、発注者は他の選択肢を並べて比べる段階に入っています。

発注側にも、この段階で振り返っておきたい点があります。誰の落ち度かを決めるためではなく、原因の見当によって次の章で重く見る選択肢が変わるためです。よくある原因は次の 4 つです。

よくある原因	見られる様子	次に重く見る選択肢
要件が固まっていない	仕様の確定待ちや、途中での大きな要望追加が続いた	続行・体制見直しの前に、範囲と優先順位を再合意する
技術選定・設計の問題	機能を足すたびに不具合が増え、修正が追いつかない	途中成果物の評価を重く見て、引き継ぎか作り直しを選ぶ
進捗管理と報告の不足	完了時期だけが延び、残作業が見えない	体制見直し (報告の頻度と形式、担当者)
発注側の任せきり	確認の場がなく、仕様の判断を相手に委ねていた	どの選択肢でも、発注側の確認者と判断の場を決める

原因と兆候の詳しい整理は システム導入が失敗する 12 の兆候 と AI 駆動開発で失敗しない進め方 で扱っています。

続行・体制見直し・引き継ぎ・作り直しを選ぶ判断軸

診断の結果をもとに、選択肢を 4 つに分けて比べます。どれか 1 つが常に正しいわけではなく、判断の材料は「途中成果物が使えるか」と「今の開発会社が説明責任を果たせるか」の 2 つです。

flowchart TD
  A["開発が途中で止まった"] --> B{"今の開発会社は<br/>残作業と完了時期を<br/>根拠付きで説明できるか"}
  B -- できる --> C{"条件の見直しで<br/>合意できるか"}
  C -- できる --> D["続行<br/>(スコープ・期限・報告を再合意)"]
  C -- できない --> W{"会社として<br/>続ける意思があるか"}
  W -- ある --> E["体制見直し<br/>(担当者・進め方・契約形態の変更)"]
  W -- ない --> F
  B -- できない --> F{"途中成果物は<br/>第三者が読んで動かせるか"}
  F -- 使える --> G["他社への引き継ぎ"]
  F -- 使えない --> H["作り直し<br/>(資料と業務知識を引き継ぐ)"]

選択肢	向いている状況	発注者が負う主なコスト
続行	遅れの原因が特定され、残作業と完了時期に根拠がある	延びた期間の事業影響、追加費用の交渉
体制見直し	会社としては続ける意思があるが、担当者や進め方に問題がある	再計画の期間、契約の変更手続き
引き継ぎ	関係の継続が難しく、途中成果物の多くが使える	現状調査の費用、引き継ぎ期間、前の会社との調整
作り直し	途中成果物が読めない・動かない、または設計が業務と合っていない	これまでの投資の一部を諦める判断、再開発の費用

作り直しは、これまでの費用を無駄にする選択に見えて避けたくなります。ただ、動かない土台の上に機能を足し続けると、追加で払う費用のほうが大きくなる場合があります。判断を感情に任せないために、4 つの中から選ぶ前に、途中成果物の評価を済ませます。

途中成果物を評価する ─ 動く部分と捨てる部分を見極める

途中成果物の評価は、今の開発会社の自己申告だけに頼らず、利害関係のない第三者に依頼するのが基本です。何を調べてもらうかを知っておくと、調査の依頼と結果の読み取りが楽になります。

設計書がなくても、次の 6 点は調べられます。

1. ソースコードから、アプリケーションをビルドして起動できるか
2. 本番や検証の環境へ、手順書どおりにデプロイできるか
3. データベースの設計が、業務で扱う情報と矛盾していないか
4. テストが書かれていて、実行すると通るか
5. 仕様書や課題管理と照らして、完成している範囲と未着手の範囲はどこか
6. 認証や個人情報の扱いに、すぐ直すべき問題がないか

調査結果は「すべて使える」「すべて捨てる」の二択にはなりにくく、画面は作り直すがデータ構造は残す、といった部分ごとの判断になるのが普通です。調査の依頼時に「残せる部分と作り直す部分を分け、その根拠を示してほしい」と伝えておくと、結果を交渉や再計画にそのまま使えます。仕様書が不足している場合の進め方は 仕様書のないレガシーを AI で読み解く を参照してください。

契約形態で変わる途中解約・支払い・責任 ─ 請負と準委任

開発を途中でやめる、または相手に続けてもらえない場合、支払いと責任の考え方は契約の種類で大きく変わります。まず契約書の中途解約・解除・成果物の引き渡しの条項を読みます。民法の規定の多くは契約で別の定めを置けるため、民法は契約書に定めがない部分を考える手がかりとして使います。

失敗の責任が開発会社と発注者のどちらにあるかは、一律には決まりません。契約書で何を約束していたかに加え、要件定義・設計・実装といった段階ごとに、双方がいつ何を決め、何を提供したかという経緯をもとに判断されるのが一般的です。どちらか一方の落ち度と決めつける前に、記録を時系列にそろえることが先です。

次の表は、e-Gov 法令検索の民法 の条文をもとに、発注者に関係する部分を要約したものです。

論点	請負 (仕事の完成を約束する契約)	準委任 (事務の処理を委ねる契約)
発注者からの途中解除	完成前なら、発注者はいつでも損害を賠償して解除できる (第 641 条)	各当事者がいつでも解除できる。相手に不利な時期の解除などは損害賠償が必要な場合がある (第 651 条)
途中までの作業の報酬	完成前に解除された場合、分けて使える部分で発注者が利益を受けるなら、その割合に応じて報酬を請求できる (第 634 条)	途中で終了した場合、既に履行した割合に応じて報酬を請求できる (第 648 条第 3 項)。成果に報酬を払う型は第 634 条を準用 (第 648 条の 2)
相手の不履行による解除	相当の期間を定めて催告し、その期間内に履行がなければ解除できる (第 541 条)。履行を拒む意思が明確な場合などは催告なしで解除できる場合がある (第 542 条)	同左

請負で仕事が完成し、引き渡された後に不具合が見つかった場合は、契約不適合責任の問題になり、発注者が不適合を知った時から 1 年以内に通知しないと請求できなくなる定めがあります (第 637 条第 1 項)。ただし、引き渡しの時点で開発会社が不適合を知っていた、または重大な過失で知らなかった場合は、この 1 年の制限は適用されません (同条第 2 項)。納品物が動かない状態で検収を求められている場合は、検収書に押印する前に、不具合の一覧を書面で返しておくことが大切です。

実務の契約は、要件定義を準委任、実装を請負にするなど、段階ごとに形態を分けていることも少なくありません。IPA の 情報システム・モデル取引・契約書 (第二版) も中途解除時の報酬を扱っています。契約形態の違いそのものは AI 開発の契約は準委任と請負どちらが正解か で詳しく整理しています。

裁判の前に取れる選択肢 ─ 交渉・ADR・弁護士への相談

裁判を考える段階まで来ていても、訴訟だけが手段ではありません。多くの場合、次の順番で検討します。

手段	内容	向いている場面
書面での交渉	経緯と要求 (成果物の引き渡し、精算、解約条件) を書面で示して話し合う	相手が応答しており、合意の余地がある
ADR (裁判外紛争解決)	中立の第三者が入り、話し合いによる解決や判断を助ける	技術的な争点が多く、非公開で解決したい
訴訟	裁判所の判決で解決を図る	交渉や ADR で解決できず、請求額や争点が訴訟の負担に見合う

ソフトウェア分野の ADR として、一般財団法人ソフトウェア情報センターが運営する ソフトウェア紛争解決センター があります。法務省の かいけつサポート で認証を受けた事業者として掲載されています。同センターの案内では、システム開発における成果物の機能的な不具合や納期遅延による費用負担が対象の例に挙がっており、和解あっせん・仲裁・中立評価・単独判定の 4 種類の手続きがあります。和解あっせんは話し合いの手続きなので、相手方が応じることが前提です。手数料と手続きの詳細は同センターの案内で確認してください。

訴訟については、最高裁判所の 裁判の迅速化に係る検証に関する報告書 (第 11 回・概要) によると、令和 6 年の地方裁判所の民事第一審訴訟全体の平均審理期間は 9.2 ヶ月です。これはあらゆる民事訴訟の平均で、システム開発に限った数字は公表されていません。控訴されれば、さらに期間が延びます。

大型の例に、スルガ銀行が日本 IBM に委託した基幹系システムの開発が頓挫し、損害賠償を求めた訴訟があり、スルガ銀行の公表資料 によると、第一審で約 74 億円が認容された後、2013 年 9 月の東京高等裁判所判決で約 41 億円に減額されました。ソフトウェア情報センターのセミナーで公開された 判決の検討資料 が紹介するとおり、この判決でも責任はプロジェクトの段階ごとに検討されています。

FIXIT

ここまで揉めたら、もう裁判しかない気がするんだけど。

Shiori

裁判を選ぶかの分かれ目は、求めるのがお金か、コードか、事業の再開かです。

FIXIT

事業の再開だったら？

Shiori

裁判を待たずに、弁護士への相談と並行して立て直しを進めます。

弁護士に相談するときは、最初に確保した契約書・支払いの記録・やり取りの時系列と、第三者調査の結果を持参すると、相談の時間を事実の整理ではなく方針の検討に使えます。

立て直しを次の会社に依頼するときの進め方

引き継ぎや作り直しを選んだ場合、次の会社への依頼の仕方で、立て直しの成否が大きく変わります。止まった開発の続きをすぐに頼みたくなりますが、次の順番を守るほうが、立て直しは結果的に早く進みます。

1. 期間と作業範囲を区切った現状調査を依頼する
2. 調査結果をもとに、残す部分・作り直す部分・後回しにする機能を決める
3. 再開後の計画は、短い区切りで動くものを確認できる段階契約にする

2 の段階では、当初の計画をすべて取り戻そうとせず、業務を再開するのに最低限必要な範囲へ絞り込むことが大切です。止まっていた期間の分だけ社内の期待は膨らんでいますが、範囲を広げたまま再開すると、同じ遅延が起きやすくなります。再開後は、完了時期の報告だけでなく「何が終わっていないか」を定期的に確認します。

前の開発会社との関係が続いている場合は、引き継ぎへの協力を有償で依頼する選択肢もあります。平時の乗り換えにおける並行期間の置き方は システム引き継ぎの進め方、保守・運用だけを移す場合は システム保守の引き継ぎ、大規模な刷新に広がる場合は システムリプレイスの進め方 を参照してください。

FIXIT の運用 ─ 止まった直後の相談では、確保できた範囲から調べ始める

FIXIT は、途中で止まった開発の立て直しのご相談でも、続きの開発を見積もる前に、範囲を区切った現状調査から始めることをおすすめしています。止まった直後に手元で確保できたコード・権限・記録の範囲から調べ始め、全体像を早くつかむ進め方をとっています。残せる部分と作り直す部分を、根拠とあわせて整理することを調査の目的にしています。

契約や紛争に関する判断は弁護士の領域です。FIXIT がお手伝いできるのは、コードと構成の技術的な整理と、契約書の権利条項が実際の構成 (リポジトリやサーバーの名義など) と合っているかの突き合わせまでで、法的な判断はしません。刷新まで視野に入る場合の進め方は システム刷新・リプレイス をご覧ください。

開発が止まった直後は、やるべきことが多すぎて手が止まりがちです。まずは、ソースコード・環境の権限・やり取りの記録・契約と支払いの記録の 4 つがどこにあるかを、今日中に一覧にしてください。どこから手を付けるべきか判断がつかない場合は、その状態のままでも構いません。お問い合わせ から、開発が止まった経緯と手元にある資料を共有いただければ、現状調査の範囲を一緒に整理します。