「頼んでいる開発会社が、もし倒産したらどうなるのか」。ソフトウェア業の倒産が過去10年で最多ペースというニュースを目にして、外注中・外注予定のシステムが急に心配になった発注担当者は多いはずです。特に開発の途中で外注先が倒産すると、動くシステムも設計書も手元にないまま宙に浮き、支払ったお金も戻りにくくなります。頼む前に「この不安をどう減らせるか」を知っておきたいところです。
結論から言うと、受託開発の倒産リスクは、ゼロにはできないものの、発注前の会社の見極めと、契約・成果物の受け取り方でかなり小さくできます。カギは「倒産しても事業を止めないための備え」を、頼む前と開発中に仕込んでおくことです。この記事では、受託開発で外注先が倒産するとどうなるか、なぜ今ソフトウェア受託開発の倒産が増えているのか、そして倒産リスクに発注前から備える具体的な方法までを、発注者目線で整理します。
この記事のポイント
- ソフトウェア受託開発の倒産は過去10年で最多ペース。小規模・多重下請けの淘汰が進む
- 開発途中の倒産は「動くものも書類も無い」ぶん痛い。着手金・仕掛品・ソースが宙に浮く
- ソースコードや設計書は契約で受け渡しを定めないと手元に残らない
- 倒産しにくい会社の見極めと、分割検収・ソース定期受領・エスクロウで備える
目次
受託開発で外注先が倒産するとどうなるか
受託開発の倒産リスクを考えるとき、最初に押さえたいのは「実際に外注先が倒産すると、発注者に何が起きるのか」です。ここが具体的に分かっていないと、備えの優先度もつけられません。まずは業界の状況と、開発中・保守中それぞれで起きることを整理します。
ソフトウェア受託開発の倒産は過去10年で最多
「IT需要は好調なのに、なぜ倒産が増えているのか」と不思議に思うかもしれません。ですが実際、ソフトウェア業の倒産は増えています。帝国データバンクの調査によると、ソフトウェア業の倒産は2025年度に過去10年で最多ペースとなり、そのうち「ソフト受託開発」の倒産が大きな割合を占めています。参考までに、業界全体の動向は帝国データバンクのソフトウェア業倒産動向調査で確認できます。
特徴的なのは、倒産した会社の多くが負債1億円未満の小規模事業者だという点です。つまり、規模の小さい開発会社ほど淘汰されやすい状況になっています。背景には、多重下請け構造の中で価格を上げにくいこと、人手不足による人件費の高騰、そして発注側企業の内製化（自社開発への回帰）で受注が細っていることなどがあります。
発注者の立場でこの動向を翻訳すると、「安さや小回りだけで小規模な開発会社に頼むと、開発途中で相手が力尽きるリスクが以前より高まっている」ということです。もちろん小規模＝危険という単純な話ではありませんが、頼む相手の体力を確認する重要度は、確実に上がっています。仕事があるのに潰れる会社がある、という現実を前提に発注を考える必要があります。
開発途中で倒産すると発注者が困ること
倒産のダメージが一番大きいのは、システムがまだ完成していない「開発途中」の倒産です。この段階で外注先が倒産すると、発注者は複数の問題に同時に直面します。
まず、開発が止まります。作りかけのシステムは動く状態になっておらず、そのままでは使えません。次に、お金の問題です。着手金や中間金をすでに支払っていた場合、その分の成果が手元に残らないまま、資金だけが宙に浮くことがあります。倒産した会社から返金を受けるのは現実には難しく、他の債権者と同じ立場で扱われるのが一般的です。
さらに深刻なのが、仕掛品（作りかけの成果物）とソースコードが手元にないケースです。開発中のソースコードや設計書は開発会社の管理下にあることが多く、契約で受け渡しを定めていなければ、倒産と同時にアクセスできなくなります。そうなると、別の会社に引き継いでもらおうにも、ゼロから作り直すしかなく、支払った費用も期間も無駄になりかねません。開発途中の倒産は、「お金を払ったのに、動くものも書類も残らない」という最悪のパターンを招きうるのです。
下の表は、支払い方式ごとに開発途中の倒産でどこまで痛手を負いやすいかを整理したものです。あくまで一般的な傾向で、実際の扱いは契約内容によりますが、支払いと成果物の受け取りをどう設計するかが被害の大きさを左右する、という感覚をつかんでください。
| 支払い・受け取り方 | 開発途中で倒産したときの傾向 |
|---|---|
| 着手金を多く先払い・成果物は完成後にまとめて受領 | 先払い分が宙に浮きやすく、仕掛品も手元に残りにくい |
| 工程ごとの分割検収・出来高払い | 払った分の成果物は受領済みで、被害を途中までに抑えやすい |
| ソースコードを定期的に受領する取り決めあり | 作りかけでも他社が引き継ぎやすく、作り直しを避けやすい |
保守中に倒産した場合との違い
倒産は開発中だけでなく、システムを納品してもらった後の「保守中」にも起こりえます。開発途中の倒産と保守中の倒産では、困り方が少し違います。
保守中の倒産では、少なくとも動くシステムはすでに手元にあります。日々の業務は止まらないことが多いものの、不具合が出ても直せない、法改正やOS更新に追随できない、機能追加を頼めない、といった「その後の面倒を見てくれる人がいない」状態に陥ります。これに対し開発途中の倒産は、そもそも使えるシステムが無いため、事業計画そのものが振り出しに戻る痛みがあります。
どちらの段階でも共通して効いてくるのが、ソースコード・設計書・運用ドキュメントを手元に持っているかどうかです。納品後の保守をどう契約し、倒産・撤退にどう備えるかは受託開発の保守はどこまで頼むかを解説した記事で詳しく整理しているので、保守フェーズの備えはそちらもあわせて確認してください。本記事では、主に発注前〜開発中の備えに焦点を当てます。
受託開発の倒産リスクに発注前から備える方法
倒産リスクはゼロにはできませんが、頼む前と開発中の備えで、被害の大きさは大きく変わります。ここでは「どんな会社を選ぶか」と「どう契約し成果物を受け取るか」の2軸で、発注者ができる現実的な備えを整理します。
倒産しにくい受託開発会社の見極め方
まず入口となるのが、発注前に「この会社は開発をやり切れる体力があるか」を見ることです。完璧に予測はできませんが、いくつかの観点を確認するだけでも、明らかに危うい相手を避けやすくなります。
見ておきたいのは、第一に会社の規模と継続年数です。極端に小さい、あるいは設立して間もない会社に、長期・大規模な開発を丸ごと任せるのはリスクが高めです。第二に、特定の取引先や案件への依存度です。1社の大口案件に売上を頼っている会社は、その案件が切れると一気に傾きます。第三に、多重下請けへの依存、つまり受注した仕事を自社でほとんど作らず下請けに丸投げしていないかです。丸投げ構造は価格を圧迫しやすく、途中で連鎖的に止まる危険があります。頼んだ会社が本当に自社で作っているかは、契約前に体制図や担当者の顔ぶれで確認しておくと安心です。
加えて、相場からかけ離れた安値で受注しようとする会社にも注意が必要です。安さは魅力ですが、無理な受注はしわ寄せがどこかに出て、途中での破綻や品質低下につながりやすいものです。こうした「会社をどう選ぶか」の判断軸は、受託開発会社の選び方を解説した記事でも大手・中小の違いや体制の見極めとして整理しています。倒産リスクの観点も、会社選び全体の一部として考えると判断しやすくなります。
発注前に、品質・納期・コストだけでなくリスクや契約まで含めて外注先を点検する観点をまとめて確認したいときは、ベンダーコントロールパーフェクトガイドで、発注側が管理すべきポイントの全体像をつかめます。
契約と成果物で倒産に備える
会社を見極めたうえで、次に効くのが契約と成果物の受け取り方です。ここは発注者が主導権を持って設計できる部分で、倒産時の被害を最も直接的に小さくできます。
基本になるのが、工程ごとの分割検収・出来高払いです。着手金を大きく先払いし、完成後にまとめて受け取る形は、途中で倒産したときに払った分が宙に浮きやすくなります。工程ごとに成果物を検収して支払う形にしておけば、少なくとも「払った分の成果は受け取っている」状態を保てます。あわせて、要件定義書・設計書・作りかけのソースコードなどを、開発の区切りごとに定期的に受け取っておくと、万一のときに別の会社へ引き継ぎやすくなります。
忘れてはならないのが、ソースコードや成果物の権利です。開発費を全額払っていても、契約で定めない限り、ソースコードの著作権は自動的には発注者に移りません。倒産の有無にかかわらず、成果物やソースコードの権利・受け渡しを契約で明確にしておくことが前提になります。契約で確認すべき点は受託開発の契約で発注者が確認すべきことをまとめた記事で整理しているので、権利まわりはそちらも参考にしてください。
止まると事業に大きく影響する重要なシステムでは、ソフトウェア・エスクロウという手段もあります。これは、第三者機関にソースコードや設計書などを預けておき、開発会社が倒産するなど一定の条件が生じたときに、発注者がその預託物を受け取れるようにする仕組みです。日本ではSOFTIC（ソフトウェア情報センター）などがエスクロウの役割を担っています。すべての案件で必要なわけではありませんが、基幹システムのように止められないものほど、検討する価値が上がります。
発注前に確認したい倒産への備え
- 会社の規模・継続年数・特定取引先への依存度を確認する
- 受注を下請けに丸投げしていないか、自社の開発体制を確認する
- 工程ごとの分割検収・出来高払いにして先払いを抑える
- 設計書・ソースコードを区切りごとに受け取り、権利を契約で明記する
- 止められない重要システムはエスクロウ契約を検討する
よくある質問
- Q. 開発途中で外注先が倒産したら、着手金は戻ってきますか？
- A. 戻らないことが多いです。倒産した会社への返金請求は、他の債権者と同じ立場で扱われ、全額回収は現実には困難です。だからこそ、着手金を大きく先払いせず、工程ごとの出来高払いにしておく設計が有効です。
- Q. 倒産すると、作りかけのソースコードはもらえないのですか？
- A. 契約で受け渡しを定めていなければ、もらえないことがあります。開発中のソースは開発会社の管理下にあるためです。区切りごとにソースや設計書を受け取る取り決めをしておくと、他社への引き継ぎがしやすくなります。
- Q. エスクロウ契約は中小規模の案件でも必要ですか？
- A. すべての案件で必須ではありません。費用や手間もかかるため、止まると事業に大きく影響する重要なシステムに絞って検討するのが現実的です。多くの案件では、分割検収とソースの定期受領で十分に備えられます。
- Q. 倒産しにくい受託開発会社はどう見分ければよいですか？
- A. 会社の規模・継続年数、特定取引先への依存度、下請けへの丸投げ度合い、無理な安値受注の有無を確認します。財務や体制を完全に見抜くことはできませんが、これらの観点で明らかに危うい相手は避けやすくなります。
