事業承継とM&Aの違い：親族内承継とM&Aで変わるシステム・データ・IT契約の引継ぎ

事業承継とM&Aの違いは「目的と手段」の関係で語られることが多いものの、承継した翌月から現場で困るのは、基幹システムのログインや保守契約、顧客データの扱いです。この記事では、親族内承継・従業員承継・M&A（株式譲渡と事業譲渡）の型ごとに、システム・データ・IT契約の引継ぎがどう変わるかを比較します。そのうえで、M&A後のシステム統合（PMI）で詰まりやすい箇所と、承継後のシステムを片寄せ・併存・刷新のどれにするかの判断基準を、中小企業庁の中小PMIガイドラインと民法・個人情報保護法の条文で整理します。

まとめ：事業承継とM&Aの違いをITの引継ぎ負荷で見たときの結論

事業承継は「経営を次の担い手へ引き継ぐこと」そのもので、M&Aは第三者へ引き継ぐときの手段の一つです。この整理は変わりません。ITの引継ぎで差が出るのは、承継の相手よりも「会社の器ごと移るか、事業だけが移るか」の違いです。

親族内承継と従業員承継、M&Aの株式譲渡では、会社そのものが残るため、ライセンスや保守契約は原則としてそのまま続きます。落とし穴は、管理者アカウントや契約窓口が先代経営者の個人名義になっている状態です。

M&Aの事業譲渡では、契約は個別に移し替えになり、相手方の承諾が要ります（民法539条の2）。顧客データは事業承継に伴う提供として本人同意なしで移せますが、使える範囲は承継前の利用目的までです。

統合の方式は、譲受側のシステムへ寄せる片寄せ、当面は併存させる、両社で作り直す刷新の3択です。業務の型とデータ項目の差が大きいのに片寄せを急ぐと、改修費と現場の入力負荷が同時に膨らみます。クロージング直後は併存で業務を止めず、統合の方針は現状把握のあとに決めるのが順序です。

事業承継とM&Aの違いを親族内・従業員・第三者への承継の3類型で整理

最初に言葉の関係を固めておきます。検索結果の多くが同じ説明をしているため、ここでは違いがITの引継ぎにどう響くかに絞って書きます。

事業承継は目的でM&Aは第三者承継の手段という位置付けの違い

事業承継は、後継者の決め方で親族内承継、従業員承継（役員・従業員への承継）、社外への引継ぎの3つに分かれます。M&Aは、このうち社外への引継ぎを実行するときに使う手段です。「m&a 事業承継」「事業承継型M&A」と呼ばれるのは、後継者のいない会社が第三者へ会社や事業を譲るケースを指します。

第三者への引継ぎについては、中小企業庁が中小M&Aガイドライン（2024年8月に第3版へ改訂）を出しています。仲介者やFAの手数料の説明、経営者保証の扱いなど、売り手が確認すべき事項をまとめた資料です。一方、成立後の統合作業は別冊の中小PMIガイドラインの領分で、ITシステムの扱いもこちらに書かれています。

株式譲渡と事業譲渡で変わる会社の器と引き継がれるIT契約の範囲

M&Aの手法は大きく株式譲渡と事業譲渡に分かれます。株式譲渡は株主が替わるだけで、会社という法人格は同じです。取引契約、ソフトウェアのライセンス、保守契約、クラウドサービスの利用契約は、会社が当事者のまま残ります。

事業譲渡は、事業に属する資産・契約・従業員を個別に選んで移す手法です。契約を移すには、民法539条の2が定めるとおり、契約の相手方の承諾が必要になります（民法の条文（e-Gov法令検索））。ベンダーが承諾しなければ、買い手側で新たに契約を結び直すことになります。

事業承継の課題で後継者不在の次に表面化するIT資産の属人化の実態

事業承継の課題として真っ先に挙がるのは後継者不在と株式・税の問題です。そこが片付いたあとで表面化するのが、情報とシステムが先代や特定の担当者の頭の中にしかない状態です。

中小企業庁の中小PMIガイドライン（令和4年3月）は、ITシステム分野の失敗例として、経営や業務の情報がすべて個人管理の表計算ソフトに保存され、項目や形式がバラバラだった事例を挙げています。紙だけで管理された情報も多く、必要な情報の把握に多大な時間と労力がかかったとされています。M&Aの事例として書かれていますが、親族内承継でも起きる構造は同じです。

承継の型ごとに引き継ぐシステム・データ・IT契約の違いを比較する一覧

ここからが、仲介や税務の解説記事では扱われない部分です。承継の型を横に並べ、ITまわりで何が自動的に続き、何に手続きが要るかを比べます。

親族内承継・従業員承継・株式譲渡・事業譲渡の4類型のIT引継ぎ比較表

契約と個人データの扱いは民法と個人情報保護法の規定から、統合の要否は一般的な傾向として整理しています。

株式譲渡の「条項確認」は、契約書に支配権の変更（チェンジ・オブ・コントロール）を解除事由や通知事由とする条項が入っている場合を指します。会社が同じでも、この条項があれば株主の交代で契約の見直しが発生します。表のうち全類型に共通するのが、個人名義の管理者アカウントの名義変更です。

事業譲渡でライセンスや保守契約が自動で移らない民法539条の2の承諾

事業譲渡では、譲渡契約書に「保守契約を承継する」と書いても、それだけでは移りません。民法539条の2は、契約の当事者の一方が第三者と契約上の地位を譲渡する合意をした場合、相手方が承諾したときに地位が移転すると定めています。

実務では、譲渡対象の事業で使っているソフトウェアとサービスを洗い出し、ベンダーごとに承諾の要否と手続きの期間を確認します。パッケージソフトの使用許諾は、約款で譲渡や再許諾を禁じている製品もあり、その場合は承諾ではなく新規購入を求められます。この確認はクロージング前、遅くとも最終契約の締結前に済ませる工程です。

個人情報保護法27条5項2号と18条2項で読む顧客データ移転の条件

事業譲渡で顧客データを買い手に移すとき、本人の同意は必要か。個人情報保護法27条5項2号は、合併その他の事由による事業の承継に伴って個人データが提供される場合、提供を受ける者は第三者に当たらないとしています。本人同意なしで移せる根拠がこの規定です。

ただし同法18条2項により、承継で取得した個人情報は、承継前の利用目的の達成に必要な範囲を超えて扱えません。買い手が自社の別商品の案内に使うなら、利用目的の変更か本人同意の手続きが要ります。データ移行の設計時点で、どの項目をどの目的で使うかを決めておくことが必要です。解釈の詳細は個人情報保護委員会のガイドライン（通則編）で確認できます。

親族内承継で見落とされる先代名義のアカウントと保守契約の棚卸し

親族内承継と従業員承継は会社が変わらないため、ITの引継ぎは「何もしなくてよい」と思われがちです。実際に手が止まるのは、名義と文書の2か所です。

ドメインやクラウド・会計ソフトの管理者が先代個人である状態の点検

中小企業では、独自ドメインの登録者、クラウドストレージやグループウェアの特権管理者、会計ソフトの契約者が、先代経営者の個人メールアドレスになっていることがあります。先代が引退後に連絡を絶つ、あるいは亡くなってから気付くと、パスワード再設定の通知が誰にも届かず、管理画面に入れなくなります。

中小PMIガイドラインは、中小企業ではITシステムの調達・運用保守・情報セキュリティの責任者が不在であることが多いと指摘し、管理責任者を明確に定めておくことが望ましいとしています。承継前の棚卸しでは、サービス名・契約名義・管理者アカウント・請求先・更新日の5項目を一覧にし、名義を法人の共有アドレスと後継者へ移すところまでを承継計画に入れます。

口頭で続いてきた保守委託と改修履歴を承継前に文書へ起こす手順

地元の開発会社に長年保守を頼んでいる会社では、契約書が古いまま、改修の依頼は電話で済ませてきたというケースも珍しくありません。先代と担当者の人間関係で回っていた保守は、代替わりで途切れやすい部分です。次の順で文書に起こします。

1. 現行の保守契約書と、直近の請求書に書かれた作業範囲を突き合わせる
2. 過去の改修依頼と対応内容を、メールや見積書から時系列で一覧にする
3. ソースコード・設計書・サーバーの管理者権限が誰の手元にあるかを確認する
4. 後継者と保守会社の担当者で、上記の一覧を前提に契約を結び直す

3番目で「ソースコードは保守会社だけが持っている」と分かった場合、保守会社の廃業や担当者の退職で改修できなくなります。承継を機に、ソースコードの引渡しか預託を契約条項に入れておくと、その後の刷新や乗り換えの自由度が残ります。

M&A後のシステム統合（PMI）で詰まる箇所と中小PMIガイドラインの方針

M&Aの場合、ITの引継ぎは契約の移し替えで終わらず、2社のシステムをどう扱うかという統合の問題になります。中小企業庁のPMIを実施するページでは、ガイドラインの解説動画と実践ツールも公開されています。

中小PMIガイドラインが示すITシステム導入の3パターンと選び方

中小PMIガイドラインは、ITシステムの導入方針に3つのパターンがあるとしています。譲受側のITシステムを譲渡側に導入する、譲渡側の業務に適合したITシステムを導入する、譲受側・譲渡側一体で新たなITシステムを導入する、の3つです。目的や費用対効果から選ぶよう書かれています。

同じガイドラインは、そもそもシステム化の必要があるか、目的に合う機能は何か、譲渡側の利用者を譲受側がどう運用面で支えるか、という3つの観点で検討するよう求めています。パターンを先に決めるのではなく、譲渡側の業務とデータの実態を把握してから選ぶ順序です。

譲受側システムを押し付けて改修費と入力負荷が増えた失敗例の構造

ガイドラインの失敗例の一つが、譲受側のITシステムを譲渡側に導入したケースです。業務上必要なデータの差が多く、不足する項目の追加に改修コストがかかりました。さらに譲渡側にとって不要な入力項目が画面に多く表示され、業務効率が下がったとされています。

この失敗は、業務の型が違う会社に同じ画面を渡したことに原因があります。受注生産と見込生産、個別原価と総合原価のように、業務の前提が違えば必要な項目も異なるためです。片寄せを選ぶ前に、両社の主要帳票とマスタの項目を並べて差分を数えることが、改修費を見積もる最初の作業になります。

ライセンス違反とサポート切れソフトをDDの段階で拾う確認項目

ガイドラインは、管理機能のITシステム分野で取り組む項目として、ライセンス等違反の抑止、情報セキュリティ対策、ITシステム管理方針の明確化を挙げています。失敗例には、譲渡側の従業員がライセンスを購入せずに有償ソフトを使っていて、従業員個人と企業に罰金が科された事例もあります。

• 有償ソフトのライセンス数と実際のインストール数の差
• サポート期間が終了したOSやソフトウェアの利用有無
• 従業員が個人の裁量で契約・課金しているクラウドサービス
• 基幹システムの保守契約の期限と解約予告期間

これらはクロージング後に見つかると、是正費用が買い手の負担になります。M&Aの調査工程でIT面も対象に入れる方法はデューデリジェンス（DD）の種類と進め方で、ライセンスとPCの台帳づくりはIT資産管理の目的とツール機能で整理しています。

承継後のシステムを片寄せ・併存・刷新のどれにするかを決める判断基準

ここでは判断を言い切ります。前提は、ガイドラインの3パターンを「片寄せ」「併存」「刷新」の3択として読み替えることです。

片寄せを採るのは業務の型が近くデータ項目の差が小さい場合に限る

片寄せ（譲受側のシステムへ寄せる）を採るのは、同業の水平統合で業務の流れが近く、主要マスタと帳票の項目差が小さい場合です。項目差を数えた結果、追加項目が一握りで画面の追加改修が不要なら、ライセンスと保守の二重払いを早く解消できる片寄せが有利です。

逆に、業種や生産方式が違う垂直統合で片寄せを選ぶのは見送ります。項目追加の改修費に加え、譲渡側の現場が新しい画面に慣れるまでの生産性低下が重なるためです。方式の選び分けは業種によらず共通で、金融機関のシステム統合で使われる片寄せ・新設・連携の方式選択も同じ考え方で整理しています。

システムを併存させて連携だけ作るのが妥当な場面と見直し期限の置き方

クロージング直後の数か月は、原則として併存を選びます。ガイドラインも、成立直後の集中実施期は新たに生じる課題への対応と並行して取組を進めることになるとしており、この時期に基幹システムを入れ替えると、受注や請求の停止が経営の混乱に直結します。

併存中は、会計の連結や売上の集計に必要なデータだけを連携させます。ただし併存を恒久化すると、保守費の二重払いとデータの二重入力が残り続けます。併存を選んだ時点で、片寄せか刷新かを決める期限を統合計画に書き込んでおくことが条件です。

承継後に刷新を選ぶ条件とシステム費用を補助金に載せられる枠の違い

刷新（両社一体で作り直す）を選ぶのは、両社のシステムがどちらもサポート終了や老朽化を抱えている場合、または統合後の業務の型が両社のどちらとも違う場合です。どちらかに寄せても結局作り直しになるなら、最初から新しい業務に合わせて設計するほうが総額は下がります。M&Aを機にした基幹システム開発の相談は、この条件に当てはまるかの確認から始まります。

財源の面では、事業承継・M&A補助金のPMI推進枠（事業統合投資類型）が、統合目的のシステム導入に係る外注費を対象にしています。親族内承継や従業員承継で使う事業承継促進枠では、外注によるシステム開発費は対象外です。枠ごとの違いは事業承継補助金の4枠とシステム投資が補助対象になる範囲で詳しく整理しています。

システム統合を急ぐべきでない場面と刷新で失敗しやすい2つの工程

採用しない判断も書いておきます。譲渡側の業務とデータの実態が把握できていない段階での片寄せと刷新は、どちらも見送りです。とくに、情報が個人管理の表計算ソフトや紙に散らばっている会社では、先にデータの棚卸しと項目の定義をしないと、要件定義が成り立ちません。

刷新を選んだ場合に失敗が集中するのは、データ移行と切替の2工程です。移行方式の選び方はシステム移行の方式と進め方で、工程別の失敗の型は基幹システム刷新の失敗事例と回避策で確認できます。

よくある質問

事業承継とM&A、承継後のシステムの扱いについて、検索されることの多い質問に答えます。法令は2026年9月時点の条文にもとづいています。

事業承継とM&Aの違いは何ですか？

事業承継は経営を次の担い手へ引き継ぐことそのもので、後継者の決め方によって親族内承継、従業員承継、社外への引継ぎの3つに分かれます。M&Aは、このうち社外の第三者へ会社や事業を引き継ぐときに使う手段です。ITの引継ぎの面では、会社ごと移る株式譲渡と、事業だけが移る事業譲渡のどちらを使うかで、契約とデータの手続きが大きく変わります。

株式譲渡ならソフトウェアのライセンス契約はそのまま使えますか？

株式譲渡では会社の法人格が変わらないため、ライセンス契約は原則として継続します。ただし契約書に、支配権の変更を解除事由や通知事由とする条項（チェンジ・オブ・コントロール条項）がある場合は、株主の交代に伴って通知や再契約が必要になることがあります。主要なソフトウェアとクラウドサービスの約款は、最終契約の前に確認しておくと安全です。

事業譲渡で顧客データを買い手に渡すと本人の同意が必要ですか？

個人情報保護法27条5項2号により、事業の承継に伴う個人データの提供は第三者提供に当たらず、本人の同意は要りません。ただし同法18条2項で、承継前の利用目的の達成に必要な範囲を超えて扱うことはできません。買い手が別の商品の案内などに使う場合は、利用目的の変更や本人同意の手続きが別途必要になります。

M&A後のシステム統合はいつ始めるべきですか？

現状把握はM&Aの検討段階から始め、統合そのものはクロージング直後に急がないのが基本です。成立直後は業務を止めないことを優先し、2社のシステムを併存させて必要なデータだけを連携させます。そのうえで両社の業務とデータ項目の差を把握し、片寄せ・併存・刷新のどれにするかを決める順序です。併存を選んだ場合も、方針を決める期限を統合計画に書き込んでおきます。

事業承継の課題としてITでは何から手を付ければよいですか？

最初に手を付けるのは、利用しているシステムとクラウドサービスの棚卸しです。サービス名、契約名義、管理者アカウント、請求先、更新日を一覧にし、先代経営者の個人名義になっているものを法人と後継者へ移します。あわせて保守契約の作業範囲と、ソースコードや設計書の所在を確認しておくと、承継後の改修や刷新で困る場面を減らせます。

関連記事

• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説：承継時に棚卸しする基幹システムの範囲を確認できます。
• 事業承継補助金とは：16次公募の4枠とシステム投資が補助対象になる範囲：承継やM&A後のシステム費用の財源を検討する記事です。
• デューデリジェンス（DD）とは？意味・種類・進め方とDD費用の補助【2026年】：M&Aの調査工程でIT面を確認する前提になります。
• システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説：片寄せや刷新で必要になる移行方式の選び方です。
• 基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解：統合後の刷新で避けたい失敗の型をまとめています。