10年以上使い続けてきた業務パッケージのベンダーが、ある日突然倒産。サポート窓口は閉鎖、法改正への対応も止まり、社内では「いつまで動かし続けて良いのか」「明日にも止まったらどうするのか」という不安が広がる——中小企業の経営者にとって、これほど神経をすり減らす場面はそうありません。本記事ではパッケージベンダーが倒産・サポート停止した時に、慌てて次のシステムへ飛びつかず、3年単位で次の一手を組み立てるための整理術を、経営者目線で解説します。
この記事の結論（3行）
- 倒産直後に焦って新パッケージに飛び込むと、同じ失敗を繰り返す。まず3カ月の「現状凍結」期間を取る
- データ・ライセンス・ソースコード・契約書の4点をその週のうちに社内へ確保する
- 移行先は「同等パッケージ」「クラウド型SaaS」「個別開発」の3択で、業務本数と運用人数で振り分ける
なぜパッケージベンダーの倒産はこれほど怖いのか
業務パッケージは、自社で作り込んだものと違って「使う」ことに特化しています。日常運用ではブラックボックスでも問題になりませんが、ベンダーが倒産した瞬間、そのブラックボックスが一気に重しに変わります。
- 内部の作りを誰も読み解けない
- データの取り出し方が標準化されていない
- ライセンス認証サーバーが止まれば動かなくなる可能性がある
業務が止まらないように見えても、半年・1年単位で「制度改正に追随できない」「障害時の復旧手段がない」状態が立ち上がってきます。ここで焦って次のパッケージへ飛び込むと、同じ構造の問題を抱えたまま3〜5年後にまた同じ場面に直面します。
「いま動いているから大丈夫」が一番危険
ベンダーが倒産しても、システム自体は当面動き続けます。これが判断を遅らせる最大の罠です。「動いているうちはこのまま」と先送りにすると、1年後の税制改正・社会保険料率の変更で動かなくなり、その時点で慌てて移行することになります。慌てた移行は工数の積算が雑になり、市場相場の1.3〜1.5倍を払うことが珍しくありません。
データを取り出せないリスクが最大
パッケージシステムの多くは、独自のデータベース構造で動いています。CSV出力機能があっても、取り出せるのは画面に表示している項目だけで、内部の関連テーブルや履歴データは取り出せない設計が一般的です。ベンダーが倒産した時点で、データ移行を支援してくれる窓口は消えています。
ライセンス認証サーバーが止まる時限爆弾
オンライン認証型のパッケージは、ベンダーの認証サーバーが停止した瞬間に動かなくなる可能性があります。倒産直後はサーバー維持費が払われずに止まるケースもあり、3〜6カ月の猶予が現実的な見込みです。この時間軸を最初に把握することが、次の手の前提条件になります。
ベンダー倒産時にその週のうちにやる4つの確保
ベンダー倒産の一報を受けた経営者が、まず1週間以内に動いておくべき項目を4つに整理します。
| 確保項目 | 期限 | 担当 | 効果 | |---|---|---|---| | データの全件エクスポート | 即日〜3日 | 情シス・現場担当 | 動かなくなっても業務継続 | | ライセンス・認証情報の控え | 1週間以内 | 経理・情シス | 認証停止までの猶予が把握できる | | ソースコード・カスタマイズ仕様書 | 1週間以内 | 情シス | 移行先選定の判断材料 | | 契約書・破産管財人連絡先 | 即日 | 経営・総務 | 法的な権利関係の整理 |
特にデータと契約書は、その日のうちに動いてください。破産手続きが進むとアクセス自体ができなくなるリスクがあります。社内のリソースで難しい場合は、第三者の整理として業務改善・システム見積もりAI適正診断で何を最優先に確保するか整理する手も使えます。
データの全件エクスポート
パッケージの画面で取り出せる範囲を全てCSV化してください。日次データ・月次集計・マスタ系全て対象です。取り出せない項目があれば、画面のスクリーンショットで業務を回せる状態に持っていきます。「使うかどうか分からないデータも全部出す」が原則です。
ライセンス・認証情報の控え
ライセンスキー、認証用ID/パスワード、シリアル番号、サーバー名を全て紙とデジタルで二重に保管してください。ベンダーが消えた後、再発行の窓口はありません。クラウド型認証の場合は、認証サーバーがいつまで生きているかをサポート窓口に確認できる最後のタイミングです。
ソースコード・カスタマイズ仕様書
カスタマイズを入れている場合、その仕様書をベンダーから受け取れる最後の機会です。破産管財人を通せば一定の協力が得られるケースもあります。ソースコードの所有権が自社にあるか、ベンダーにあるかも契約書で確認してください。
契約書・破産管財人連絡先
ベンダーとの契約書類を全て揃え、破産管財人の連絡先を控えてください。データの取り出しやライセンスの継続利用について、管財人と交渉できる場合があります。法的な助言が必要なら、顧問弁護士へ早めに相談を回してください。
次の手を選ぶ3つの選択肢
データを確保した後、次の手を3カ月かけて検討します。選択肢は大きく3つに分かれます。
| 選択肢 | 初期費用 | 月額 | 期間 | 適しているケース | |---|---|---|---|---| | 同等パッケージへ乗り換え | 200〜800万円 | 5〜20万円 | 3〜6カ月 | 業務をパッケージに合わせられる中小規模 | | クラウド型SaaS | 50〜300万円 | 3〜15万円 | 2〜4カ月 | 標準業務が中心で運用人数が少ない | | 個別開発（カスタム） | 500〜2,500万円 | 2〜8万円 | 6〜12カ月 | 業務が独特で標準化が難しい中規模以上 |
業務本数・運用人数・現行カスタマイズ量で適性が変わります。3つの中から1つを選ぶ段階で、3社以上のベンダーから項目別に整理した見積もりを取って比較してください。
選択肢1：同等パッケージへ乗り換え
機能が近い別ベンダーのパッケージへ乗り換える選択肢です。業務フローを変えずに済むため移行期間は短く、現場の混乱は最小限になります。デメリットは、別のベンダーロックインに乗り換えるだけになり、3〜5年後に同じ問題に直面するリスクが残ることです。乗り換え先のベンダーが小規模なほどリスクは高まります。
選択肢2：クラウド型SaaS
会計・販売・在庫など、標準化された業務領域ならSaaS型サービスへ移行できます。初期費用が安く、ベンダー倒産のリスクは大手SaaSなら相対的に低くなります。デメリットは、自社の業務フローをSaaSの標準に合わせる必要があり、慣れるまでに3〜6カ月の混乱期間が発生する点です。
選択肢3：個別開発
業務が独特で標準化しにくい場合、カスタム開発で作り込む選択肢です。費用と期間はかかりますが、データ構造もソースコードも自社の資産になり、将来のベンダーロックインを根本的に解消できます。中小企業でも、業務本数が3〜5本に絞れて運用人数が10人前後ならNext.js + Supabase構成で500〜800万円の予算で立ち上げられるケースが増えています。
経営者目線で考える「ベンダー倒産を次の経営判断に変える」発想
ここからは経営の話です。ベンダー倒産は確かに不運な出来事ですが、見方を変えれば「10年積み上がった業務システムを見直す絶好の機会」でもあります。日々の業務に追われている時には誰も触らない聖域だったシステムが、強制的に俎上に乗ったわけです。
経営者として持っておきたい視点は3つです。第一に、「今のシステムを同じ構造で作り直すと、3〜5年後にまた同じ場面に立つ」という時間軸の認識。第二に、「業務本数を絞れば、個別開発の予算は半分以下に圧縮できる」というスコープ調整の発想。第三に、「データを自社で持つ仕組みに切り替えれば、ベンダーロックインを根本的に解消できる」という長期視点。
特に2つ目が肝心です。現行パッケージの全機能を再現しようとすると、どの選択肢を取っても費用は青天井になります。「いま毎日使っているのは何機能か」「月1回しか使っていないものは捨てられるか」を経営判断として切り分けることで、移行先の予算規模は大きく変わります。
ぷらすわんの実例：個別開発でロックインを解消した中堅製造業の話
ぷらすわんでは、業務システムの個別開発で「ベンダーに依存しない構造」を意識した設計を進めています。ここでは、ある中堅製造業A社の生産管理パッケージが倒産で止まった際の架空ケースを紹介します。
A社は10年使ってきた生産管理パッケージのベンダーが倒産し、半年後に動かなくなる見込みになりました。同等パッケージへの乗り換え見積もりは1,200万円、別の大手SaaSは月額12万円で初期200万円。一方でぷらすわんが個別開発で見積もったのは初期650万円・月額3万円でした。
差を生んだのは「使われている機能の絞り込み」と「データを自社で持つ設計」です。現行パッケージには120画面がありましたが、毎週使われているのは35画面、毎月使われているのは50画面でした。残り70画面は「念のため」存在しているだけで、移行対象から外しました。データベースはSupabaseで構築し、自社管理下に置くことで将来のロックインを回避しました。Next.jsのフロントエンドと組み合わせて、6カ月で稼働開始です。
この発想は同等パッケージへの乗り換えでも応用できます。「全機能を再現する」を捨てれば、見積もりは3〜5割下がります。手元のパッケージシステムを診断する場合は、まず「機能の絞り込み余地」から整理することをお勧めします。
次の手を成功させる5つの実践
最後に、パッケージベンダー倒産後の次の手を「3年後も同じ場面に立たない形」で着地させるための、5つの実践ポイントをお伝えします。
- 移行判断は3カ月の猶予を持って行う
- 現行機能を「毎週使う／毎月使う／使わない」で仕分ける
- 移行先候補は3社以上から見積もりを取る
- データ所有権が自社に残る契約形態を選ぶ
- 運用費を3年単位で総額比較する
この5つは、どれも倒産後の「次の手」段階で効果が出る項目です。慌てて1社の言い値で発注すると、いずれも漏れがちな観点ばかりです。
移行判断は3カ月の猶予を持って行う
ベンダー倒産の一報直後の1カ月はデータと契約の確保、次の1カ月で現行業務の棚卸し、最後の1カ月で移行先候補の比較、というスケジュールが現実的です。慌てて1カ月で決めると、後で「あの機能が抜けていた」事故が起こります。
現行機能を「毎週使う／毎月使う／使わない」で仕分ける
機能棚卸しの精度が、移行費用を大きく左右します。週次・月次・未使用の3段階で仕分け、未使用機能は移行対象から外してください。「念のため」を全部移行に含めると、見積もりは1.5〜2倍に膨らみます。
移行先候補は3社以上から見積もりを取る
パッケージ・SaaS・個別開発の各カテゴリから最低1社ずつ、合計3社以上から見積もりを取って比較してください。1社見積もりは交渉材料がなく、結果として割高になります。比較項目は初期費用・月額・データ所有権・契約解除条件の4点です。
データ所有権が自社に残る契約形態を選ぶ
次の移行先と契約する際は、データの所有権・取り出し権・契約終了時のデータ返却条件を契約書に明記してください。今回の苦い経験を次に活かす、最も重要な学びです。曖昧な記述のまま契約すると、また同じ場面に立つことになります。
運用費を3年単位で総額比較する
初期費用だけで比較すると、月額が高いSaaSが不利に見えがちですが、3年総額で比較するとSaaSが安いケースも多くあります。逆に初期費用が安く見えるパッケージが、保守費用込みで3年見ると最も高くつくことも。発注前に他社見積もりとの比較を依頼する際は、必ず3年総額で並べてください。
まとめ
パッケージベンダーの倒産は中小企業の経営者にとって大きな試練ですが、3カ月の猶予を取って整理を進めれば、次の手は十分に打てます。まずは1週間以内にデータ・ライセンス・ソースコード・契約書を確保し、3カ月かけて同等パッケージ・SaaS・個別開発の3択を比較してください。
大事なのは、倒産を「同じ構造を作り直す機会」ではなく「業務とシステムの関係を見直す経営判断の機会」として扱うことです。機能を絞り込み、データ所有権を自社に残す契約形態を選べば、3〜5年後にまた同じ場面に立つリスクは大きく下がります。次の手を整理したい経営者の方は、現状を項目別に整理してから判断する流れをお勧めします。