取引中の開発会社に廃業・撤退の予兆はあるか。中小企業が平時からできる備え

毎月きちんと保守費を払い、大きなトラブルもなく回っている。それなのに、ある日突然「担当者の退職に伴い、本サービスは終了いたします」というメールが届いたら——。取引中の開発会社・保守会社が廃業したり、その事業から撤退したりするリスクは、契約書を交わした瞬間から常に存在します。しかし多くの中小企業では、このリスクへの備えは「もし連絡が取れなくなったら、そのとき考える」という事後対応任せになっています。

結論から言うと、取引中の開発会社・保守会社の経営状態に、外からある程度察知できる予兆はあります。そして、予兆が出てから慌てて対応するのではなく、予兆の有無にかかわらず平時から準備しておける対策があります。この記事では、①取引先の経営状態を確認する一般的な方法、②開発会社・保守会社特有の予兆、③予兆の有無に関わらず今日から整えられる備えの3段構成で、当事者である発注側の視点から解説します。

すでに連絡が取れなくなってしまった、あるいは廃業が確定してしまった場合の対処法は、『開発会社と完全に連絡が取れなくなった。廃業・音信不通時の放置システム対処法』と『昔の開発会社が倒産していた。ソースコードがない場合の選択肢』で扱っています。この記事はそれより手前の段階、まだ取引が続いている「平時」に何ができるかに焦点を当てます。

この記事で分かること

取引中の開発会社・保守会社について、外部から経営状態を確認する一般的な信用調査の手法と、IT・システム開発業界特有の事業撤退の背景を解説します。そのうえで、予兆を発見してから動くのではなく、予兆の有無にかかわらず平時のうちに整えておける具体的な準備を、権利関係・情報・複数の連絡経路という3つの観点から示します。

読み終える頃には、「今の取引先が万が一いなくなっても、システムの運用を止めずに次の一手を打てる状態」に自社が近いのか遠いのかを判断でき、遠い場合に何から手をつければよいかが分かる状態を目指します。

なぜ「取引中」に考える必要があるのか

危険な開発会社を選ばないための見極め方は、『危険な開発会社のサイン10選』のように発注前の話として語られることが多く、いったん契約して取引が始まった後は、経営状態への関心が薄れがちです。

しかし、発注時点では健全だった会社が、数年の取引期間中に経営状態を悪化させることは珍しくありません。東京商工リサーチの調査によると、2024年の「情報通信業」の倒産件数は425件で前年比21.7％増、2013年以来11年ぶりに400件を超えました。このうち「ソフトウェア業」が223件と過半数の52.4％を占め、前年比12.0％増となっています。倒産理由の約70％は「販売不振」（293件）で、資本金1,000万円未満の小規模事業者が258件と全体の60％を占めています。

情報通信業の倒産は425件（前年比21.7％増）で、2013年（450件）以来11年ぶりに400件を超えた。

—— 東京商工リサーチ「『情報通信業』の倒産 11年ぶり400件超」（2025年1月29日発表）

自社が取引している開発会社・保守会社がこの統計に含まれる可能性は、決して低くありません。特に、中小企業の営業利益率は5.7％（大企業11.4％、中堅企業11.1％）にとどまり、赤字企業の割合も22.0％と唯一上昇傾向にあることから、小規模な開発会社ほど経営体力に余裕がないケースが多いという構造も見えてきます。

この統計が示すのは、「取引先が危ない会社かどうか」という個別の見極めだけでなく、「業界全体として、取引中に相手が姿を消すリスクは構造的に一定確率で存在する」という前提です。この前提に立つと、対策の考え方も変わります。個別の予兆を見抜く努力に加えて、予兆を見逃した場合でも困らない備えを並行して進める方が、実務上は現実的です。

一般的な信用調査の手法を確認する

まず、開発会社・保守会社に限らない、取引先の経営状態を確認する一般的な手法を押さえておきます。三井住友銀行のビジネス情報サイトによれば、信用調査（与信調査）にはいくつかの手法があります。

• 直接調査：実際にオフィスを訪問し、経営者や従業員との対話、オフィス環境の様子などから状況を把握する方法
• 間接調査：過去の取引先や取引銀行への問い合わせを通じて、支払い実績などを確認する方法
• 外部資料の活用：商業登記簿・決算公告などの公開情報から、資本金の増減や経営状況を確認する方法
• 依頼調査：信用調査会社などの第三者機関に調査を依頼する方法

中小企業がすべての取引先に対してこの水準の調査を継続するのは現実的ではありませんが、主要な保守委託先1〜2社に限っては、年1回程度、簡易な確認を行うことは十分に実行可能です。具体的には、次のような確認から始められます。

1. 決算公告の確認：株式会社であれば決算公告の義務があり、官報や自社サイトで確認できる場合があります（非公開の場合も多いため過信は禁物です）
2. 商業登記簿の確認：法務局で登記事項証明書を取得すれば、資本金・役員構成・本店所在地の変更履歴などが分かります
3. 担当者・窓口の変化の観察：後述する業界特有の予兆と合わせて、日々のやり取りの中で確認できる変化に注意を払う
4. 有料の企業信用調査サービスの活用：取引額が大きい・自社の基幹システムに関わるなど重要度が高い相手には、専門の信用調査会社への依頼も選択肢になります

これらは「疑ってかかる」ための調査ではなく、平時のリスク管理として、多くの企業が取引先全般に対して行っている一般的な実務です。開発会社・保守会社だからといって特別扱いする必要はなく、他の重要な取引先と同じ水準の確認を、システムという止められない業務インフラを担う相手だからこそ怠らない、という位置づけで考えるとよいでしょう。

なお、経理・購買部門が仕入先・販売先向けにすでに与信管理の仕組み（信用調査サービスの契約、取引信用保険の加入など）を持っている会社であれば、その対象リストに開発会社・保守会社を加えるだけで済む場合もあります。情シス担当者が単独で新しい調査体制を立ち上げる前に、社内の経理・購買部門に「開発会社もこの与信管理の対象に含められないか」と相談してみる価値はあります。専門部署が持つ調査の型を流用できれば、ひとり情シスが個別に信用調査会社を探すより効率的です。

開発会社・保守会社特有の予兆

一般的な信用調査に加えて、IT・システム開発業界特有の事情から生まれる予兆もあります。日々のやり取りの中で気づきやすいものから紹介します。

連絡・対応の質が変化する

最も分かりやすい予兆は、日常のコミュニケーションの変化です。

• 電話やメールへの返信が、以前より明らかに遅くなった
• 担当者が頻繁に交代する、あるいは「担当が不在」という回答が増える
• 見積もり依頼や軽微な問い合わせへの返答が滞るようになった
• 定例ミーティングの日程調整に、以前より時間がかかるようになった

これらは、開発会社側の人員縮小や事業整理の初期段階で起きやすい変化だと指摘されています。1回や2回の遅れであれば単なる繁忙期かもしれませんが、この状態が数ヶ月単位で継続する場合は、注意すべきシグナルとして受け止めます。

業界構造から見た背景

なぜIT業界でこうした変化が起きやすいのかについては、業界構造の変化も背景にあります。ユーザー企業側での内製化の進展や、エンジニアの人件費高騰により、特に中小規模のソフトウェア開発会社は収益を圧迫されやすい環境にあります。生成AIの登場によって簡単な業務システムを発注企業自身が作れるようになったことも、受託開発中心のビジネスモデルを持つ会社にとっては、長期的な受注減少の要因になり得ます。

こうした構造的な逆風の中では、特定の技術・特定の顧客層に依存している小規模な開発会社ほど、事業の継続性にばらつきが出やすいという傾向は念頭に置いておくとよいでしょう。ただし、これは業界全体の傾向であり、個別の取引先が実際にどうかは、前述の一般的な確認方法と組み合わせて判断する必要があります。

契約・請求まわりの変化

経営状態の悪化は、契約や請求の実務にも表れることがあります。

• 支払いサイトの短縮や、前払いへの変更を打診される
• 保守契約の更新時期が近いのに、更新の話が向こうから出てこない
• 見積もりの単価が、明確な理由の説明なく大きく上がる（『システム開発の見積もりがなぜ年々高くなるのか』で扱った一般的な単価上昇とは別に、特定の相手だけ急激に変化する場合は個別要因を疑います）
• 複数の契約をまとめて短期契約に切り替えたがる

これらは必ずしも倒産の予兆とは限らず、単なる営業方針の変更であることも多いものです。1つの兆候だけで結論を出さず、複数の兆候が重なっているかどうかで判断する姿勢が大切です。

「事業撤退」は倒産だけではない

もう1点、見落とされがちなのが、倒産や廃業ではなく「事業の選択と集中」による撤退のケースです。会社自体は存続していても、次のような形で特定の顧客・特定のサービスから手を引くことがあります。

• 大手による買収・M&Aの結果、非中核事業として保守サービス部門が縮小・廃止される
• 特定の技術領域（古い言語・特定のパッケージ製品など）のサポートチームを解散する
• より利益率の高い大口顧客に人員を集中させ、小口の保守契約が後回しにされる

この場合、会社そのものは倒産していないため、信用調査で経営危機の兆候を見つけることは難しく、ある日突然「◯◯事業部は◯月末をもって終了します」という通知が届く形で発覚することが多いのが特徴です。中小企業庁が公開する事業承継・M&A関連の情報でも、IT・ソフトウェア業界では後継者不在や事業の選択と集中を背景としたM&Aが活発になっていることが指摘されており、取引先が別会社に買収されること自体は、決して珍しい出来事ではありません。買収後も同じ体制でサービスが継続される場合もあれば、契約の巻き直しや条件変更を求められる場合もあります。

この種の撤退は事前の予兆をつかみにくい分、次章で述べる「予兆によらない備え」の重要性がより高くなります。

予兆があってもなくても今日からできる備え

ここまで予兆の見つけ方を見てきましたが、実務上より重要なのは、予兆に気づけるかどうかに関わらず、いつ取引先が姿を消しても最低限困らない状態を、平時のうちに整えておくことです。予兆は見逃す可能性が常にありますが、備えは自社の努力だけで進められます。

備え1：権利関係を今のうちに確認しておく

開発会社が事業を継続している今のうちに、著作権・ライセンス・データという3つの軸で権利関係を確認しておくことが、最大の備えになります。相手が廃業・音信不通になってから確認しようとしても、聞く相手がいなくなってしまいます。

• ソースコード一式の納品を受けているか、契約書に著作権譲渡の条項があるか
• 使用しているOSS・外部ライブラリの一覧を把握しているか
• 保有データをCSV等の汎用形式でエクスポートする方法を確認済みか

これらの確認方法は『システムの権利関係の整理: 納品物・ライセンス・データ』で詳しく解説しています。「まだ元気に取引している今」こそが、この確認を落ち着いて行える最後のタイミングだと捉えてください。

備え2：システムの情報を自社側にも残しておく

開発会社の頭の中にしかない情報は、その会社がいなくなった瞬間に失われます。属人化を防ぐという観点からも、次の情報は自社側の管理台帳に記録しておきます。

• サーバー・ドメイン・SaaS等の契約名義とログイン情報の保管場所
• システムの全体構成が分かる図（開発会社に依頼すれば提供してもらえることが多い）
• 過去のやり取りの経緯が分かる議事録・メールのアーカイブ

自社に台帳の仕組みがまだない場合は、『社内システムの現状調査（棚卸し）のやり方』を先に参照し、棚卸しの型を作ってから、この記事の観点を反映させる順序をおすすめします。

備え3：複数の連絡経路と代替先の心当たりを持っておく

単一の担当者・単一の連絡先だけに依存していると、その担当者が退職した瞬間に連絡が完全に途絶えるリスクがあります。

• 担当者個人の連絡先だけでなく、会社の代表窓口の連絡先も控えておく
• 可能であれば、開発会社の会社概要・登記情報（所在地・代表者名）を控えておく
• 「もし今の会社と連絡が取れなくなったら、どこに相談するか」の心当たりを、時間のあるうちに1つでも持っておく（他の開発会社への相見積もりの経験があると、いざというときの選択肢になります）

これは特定の開発会社を疑っているという意味ではなく、取引先が自社の意思と無関係に事業を続けられなくなる可能性は常にあるという前提に立った、リスク管理としての備えです。

保守契約の内容もあわせて確認する

権利関係・情報・連絡経路の備えに加えて、現在結んでいる保守契約の内容そのものも、この機会に見直しておくとよいでしょう。契約書に、事業撤退や契約解除の際の引き継ぎ義務・通知期間が明記されているかどうかは、実際に事が起きたときの対応の余裕を大きく左右します。

契約書で確認したい引き継ぎ条項

次回の契約更新や、既存契約書の読み直しの際に、次の項目が入っているかを確認しておくと、いざというときの対応余地が変わります。

これらの条項が契約書に入っていない場合、すぐに危険というわけではありませんが、次の契約更新のタイミングで追記を交渉する価値はあります。既存の取引関係を良好に保ちながら交渉する具体的な進め方は、『月額保守費の相場と見直し方』でも扱っているので、あわせて参考にしてください。

複数ベンダーへの分散は「備え」になるか

「1社に依存するリスクを避けるため、最初から複数の開発会社に分けて発注してはどうか」という考え方もあります。これは有効な選択肢の1つですが、『マルチベンダー体制のメリット・デメリット』で解説している通り、責任の所在があいまいになる、調整コストが増えるといったデメリットも伴います。「今すぐ体制を分散する」判断と、「今の体制のまま、権利関係と情報の備えだけは整えておく」判断は別であり、多くの中小企業にとっては、まず後者から着手する方が現実的です。体制そのものの見直しは、実際に予兆を感じ取った段階や、既存契約の更新時期に合わせて検討すれば十分間に合います。

取引先の規模別に見る、備えの優先度

すべての取引先に同じ密度で備えるのは現実的ではありません。自社にとっての依存度に応じて、優先順位を分けて考えます。

基幹システムを預けている「主要1〜2社」

受発注・在庫・会計など、止まると業務が回らない基幹システムを預けている相手は、最優先で備えを固める対象です。この記事で紹介した3つの備え（権利関係・情報・連絡経路）はすべて実施し、年1回の簡易な信用調査も組み合わせます。契約更新のタイミングでは、引き継ぎ条項の有無も必ず確認します。

補助的なツール・SaaSを提供している相手

日々の業務に使ってはいるが、代替手段（他のSaaSへの乗り換え、Excelでの一時運用等）が比較的容易なツールを提供している相手については、権利関係とデータのエクスポート方法だけ確認しておけば、大きな支障は避けられることが多いです。すべての取引先に同じ工数をかけるのではなく、止まったときの業務インパクトの大きさで濃淡をつけることが、限られた時間の中で備えを進めるコツです。

すでに縁が薄くなっている「過去に発注した先」

現在はほとんどやり取りがないものの、過去に開発を依頼したシステムがまだ動いている、という相手も見落としがちです。この場合、相手の経営状態を日常的に観察する機会自体がないため、定期的な観察に頼らず、権利関係の確認だけでも先に済ませておく方が現実的です。特に、担当者が退職・異動していて社内に経緯を知る人がいない場合は、『社内システムの現状調査（棚卸し）のやり方』を参照し、まず自社側の記録を整えるところから始めてください。

実際に予兆に気づいたときの動き方

備えを整えたうえで、実際に複数の予兆が重なっていると感じた場合、どう動けばよいかも触れておきます。いきなり相手を問い詰めたり、契約を打ち切ったりするのは得策ではありません。

1. 事実関係を記録する：いつ、どのような変化があったかを日付とともにメモしておきます。後で状況を振り返る、あるいは万一のトラブル時に説明する際の材料になります
2. さりげなく状況を確認する：「今後の体制について確認させてください」といった形で、直接的すぎない聞き方で状況を尋ねてみます。健全な会社であれば、通常の質問として答えてもらえます
3. 権利関係の確認を前倒しする：まだ確認していない場合、この段階で『システムの権利関係の整理: 納品物・ライセンス・データ』の内容を急いで確認します
4. 代替先の情報収集を始める：契約をすぐに切り替える必要はありませんが、万一に備えて他の開発会社の情報収集や、簡単な相見積もりの依頼だけでも始めておくと、実際に事が起きたときの初動が大きく変わります

これらは「相手を疑って行動する」というより、「不確実な状況の中でも、自社の選択肢を確保しておく」という考え方に近いものです。杞憂に終わればそれでよく、備えたこと自体が無駄になるわけではありません。

事業承継・M&Aによる体制変更というケースも視野に入れる

前述の「事業の選択と集中による撤退」は、後継者不在等を背景にした中小企業のM&Aが増加している近年の傾向とも無関係ではありません。取引先が買収された、あるいは経営者の高齢化が話題に上ったといった話を耳にした場合、それ自体を危険視する必要はありませんが、この記事で紹介した備えを見直すきっかけとして活用するとよいでしょう。買収・承継そのものは中小企業にとって珍しい出来事ではなく、多くの場合サービスは継続されますが、体制変更のタイミングで契約条件の見直しが打診されることもあるため、通知を受けた際は内容を書面で確認し、記録を残す習慣をつけておくことをおすすめします。

まとめ：予兆探しより「困らない備え」を優先する

取引中の開発会社・保守会社について、外部から経営状態を察知する手がかり（連絡対応の変化、業界の構造的な逆風、契約・請求まわりの変化）は確かに存在します。しかし、これらの予兆は必ずしも確実ではなく、見逃す可能性も常にあります。

1. 一般的な信用調査：主要な保守委託先については、年1回程度、決算公告や登記簿の確認などの簡易な確認を行う
2. 業界特有の予兆：連絡・対応の質の変化、契約・請求まわりの変化を、複数の兆候が重なっているかで判断する
3. 予兆によらない備え：権利関係の確認、システム情報の自社側での保管、複数の連絡経路の確保を、取引先が元気なうちに整えておく

最も大切なのは、この3つの中でも3番目です。予兆に気づけるかどうかは相手の状況や運にも左右されますが、備えを整えるかどうかは完全に自社の努力の範囲にあります。まずは、現在の主要な保守委託先について、『システムの権利関係の整理: 納品物・ライセンス・データ』を参考に、権利関係の確認から始めてみてください。