この記事の目次
- この記事の結論（先に要点だけ）
- 引き継ぐのは「契約・人・権利・アカウント」の4つで、株式譲渡か事業譲渡かで動き方が変わる
- 株式譲渡は契約と権利が会社に残り、事業譲渡は11項目を一つずつ移す
- チェンジオブコントロール条項と再委託禁止条項は、顧客の承諾が要る入口になる
- SESの準委任が偽装請負と見られるおそれは、指示の経路と勤怠の実態で決まる
- 準委任の再委託は委任者の許諾が前提で、多重下請けは契約と取適法の両面で見られる
- 外注成果物の著作権と、代表者個人名義のアカウントは、売る前に会社へ移す
- OSSライセンスと開発ドキュメントは、買い手が「保守できるか」を判断する資料になる
- 売り手の棚卸しチェックリストは、契約・実態・権利・アカウントの4つの順に埋める
- 買い手のDD着眼点は、承諾が要る契約と、実態が契約と合っているかの2つに集まる
- まとめ：株式譲渡と事業譲渡の違いは、契約書の束と現場の実態を並べて初めて確かめられる
- よくある質問（FAQ）
- 出典
システム開発会社のM&Aで買い手が見るのは、設備ではなく契約・人・権利・アカウントです。ところが、この4つは「会社が持っているはず」と思われているだけで、実際には顧客の承諾が要る契約、外注先に残っている著作権、代表者個人名義のアカウントとして散らばっていることがあります。この記事は、株式譲渡と事業譲渡で何がそのまま残り、何を一つずつ移す必要があるのかを表にし、そのうえでSES（準委任）に固有の論点である偽装請負のおそれと再委託・多重下請けを、条文と厚生労働省の資料で整理します。
この記事の対象は「システム開発会社（法人）を譲渡するとき」です。 業界全体の見方はシステム開発会社のM&A DATA、売却価格の考え方はシステム開発会社の売却相場、実際の事例はシステム開発会社のM&A事例にまとめています。著作権法15条2項・61条2項、民法539条の2・625条1項といった共通の条文の詳しい説明は、Web制作会社のM&Aで著作権とソースコードは引き継げる？に譲り、ここでは要点だけを書きます。
この記事の結論（先に要点だけ）
- 株式譲渡なら、契約・雇用・権利の当事者は会社のまま変わりません。事業譲渡なら、顧客契約は相手方の承諾を得て、エンジニアは一人ひとりの承諾を得て、権利は個別に移します。
- ただし株式譲渡でも、顧客との契約にチェンジオブコントロール条項や再委託禁止条項があれば、顧客の同意や通知が要ることがあります。 契約書の文言を読まないと、どちらの方式でも確かめきれません。
- SESは、契約が準委任でも、顧客がエンジニアに直接作業を指示している実態があれば、偽装請負と見られるおそれが論点になります。 厚生労働省の37号告示と疑義応答集が見る観点は、DDでそのまま確認資料になります。
- 準委任の再委託は、民法644条の2により委任者の許諾が前提です。 多重下請けの階層が深い会社は、契約の再委託条項と取適法の適用の両面で見られます。
- 売る前にできる最初の一手は、権利とアカウントの所在を書き出すことです。 外注先に残っている著作権と、代表者個人名義のGitHub・AWS・ドメインは、売り手が自力で直せます。
※本記事は条文・官庁資料に基づく一般的な整理です。個別の契約の有効性・適法性や、特定の働き方が偽装請負に当たるかどうかの判断は行いません。個別の判断は弁護士・社会保険労務士などの専門家へご相談ください。
引き継ぐのは「契約・人・権利・アカウント」の4つで、株式譲渡か事業譲渡かで動き方が変わる
システム開発会社には、許可証や設備のように「これを引き継げば事業が続く」というものがありません。事業を成り立たせているのは、次の4つです。
- 契約：顧客との基本契約・個別契約、保守・運用契約、SES（準委任）契約、外注先との契約
- 人：エンジニアの雇用契約、フリーランスとの業務委託契約
- 権利：自社で作ったソースコードの著作権、外注先が作った成果物の権利、ソフトウェア・OSSのライセンス
- アカウント：クラウド、GitHub、ドメイン、SaaSの契約者名義
構造の違いは次のとおりです。
- 株式譲渡は、会社の持ち主が変わるだけで、法人格は変わりません。会社が契約当事者・権利者であるものは、原則としてそのまま残ります。
- 事業譲渡は、事業を構成する資産・契約・人を個別に移す取引です。契約上の地位は、民法539条の2により、相手方が譲渡を承諾したときに移転します[1]。使用者の権利を第三者に譲り渡すには、労働者の承諾が要ります（民法625条1項）[1]。
Web制作会社と同じ構造ですが、システム開発会社にはSES・保守契約・再委託先という、顧客や第三者の承諾・実態の確認が絡む項目が加わります。次の表は、そこに字数を使います。
株式譲渡は契約と権利が会社に残り、事業譲渡は11項目を一つずつ移す
条件で答えが変わる部分なので、表にします。自分の会社に当てはまる行だけを読んでください。
| 項目 | 株式譲渡 | 事業譲渡 | 確認する資料 |
|---|---|---|---|
| 顧客との基本契約・個別契約 | 契約当事者は会社のまま。ただしチェンジオブコントロール条項があれば同意・通知等が要ることがある | 契約ごと移すには相手方の承諾が要る（民法539条の2）[1] | 基本契約書、個別契約書、発注書・検収書の束、COC条項・譲渡制限条項の有無 |
| 保守・運用契約 | 同上 | 同上。顧客ごとに承諾を取る。承諾が取れない契約は移らない | 保守契約書、SLA、更新履歴、障害対応の記録 |
| SES（準委任）契約 | 同上。加えて、契約の実態（誰が指示しているか）が見られる | 同上。承諾を得て移したあとも、実態は引き継がれる | 契約書、作業指示の経路が分かる資料、勤怠・稼働の管理資料、座席・入退室の取り決め |
| エンジニアの雇用 | 雇用契約の当事者が変わらないので継続 | 労働者の承諾が必要（民法625条1項）[1] | 雇用契約書、就業規則、36協定、給与台帳、退職・休職の状況 |
| 業務委託（フリーランス）契約 | 契約当事者は会社のまま。再委託禁止やCOC条項があれば確認 | 契約上の地位の移転に相手方（フリーランス）の承諾が要る | 業務委託契約書、成果物の権利条項、秘密保持の定め |
| 外注・再委託先との契約 | 契約当事者は会社のまま。顧客との契約の再委託条件を満たしているかを確認 | 契約ごと移すには相手方の承諾が要る | 外注契約書、再委託の承諾記録、外注先の一覧と階層 |
| 自社開発のソースコード | 会社が持っていればそのまま | 個別に譲渡する。移す対象を契約書で特定する | リポジトリ一覧、プロジェクトごとの権利者、開発環境の一覧 |
| 著作権（従業員作成・外注成果物） | 従業員が職務上作ったプログラムは、別段の定めがない限り会社が著作者（著作権法15条2項）[2]。外注成果物は、譲渡の合意が無ければ会社の権利ではない | 会社が持っている権利を個別に譲渡する。翻案権等（27条・28条）の特掲に注意（同法61条2項）[2] | 雇用契約・就業規則の職務著作の定め、外注契約の権利帰属条項、顧客との契約の権利条項 |
| クラウド・GitHub・ドメインなどのアカウント | 会社名義ならそのまま。個人名義なら会社の資産ではない | 名義変更・移管が必要。個人名義なら個人から会社へ、会社から買い手へ | 契約者名義の一覧、請求先、管理者権限（オーナー）の保有者、2要素認証の端末 |
| ソフトウェア・OSSライセンス | 契約当事者は会社のまま。ライセンス契約に譲渡・支配権変動の定めがあれば確認 | ライセンスごとに移転の可否を確認する。承諾が要るものがある | 利用ソフトの一覧、ライセンス契約、OSSの利用一覧とライセンス名 |
| 開発ドキュメント | 会社が持っていればそのまま | 個別に引き渡す | 設計書・仕様書・運用手順書・ID/パスワードの管理表、保管場所 |
見落とされやすいのは、表の左の「そのまま」が成立する前提が、会社名義で書面があることだという点です。株式譲渡でも、名義が個人のアカウントや、書面の無い保守契約は、そのままでは会社の資産として評価されにくくなります。
チェンジオブコントロール条項と再委託禁止条項は、顧客の承諾が要る入口になる
株式譲渡は「何もしなくてよい」方式ではありません。顧客との契約に、次の2種類の条項があるかを先に確認します。
| 条項 | 何を定めるか | どこで引っかかるか |
|---|---|---|
| チェンジオブコントロール（COC）条項 | 支配権（株主構成など）が変わったときに、相手方への通知・同意、または解除権を定める | 株式譲渡。会社の契約当事者は変わらないのに、株主が変わっただけで相手方の同意や解除が論点になる |
| 再委託禁止（制限）条項 | 受託した業務を第三者に再委託することを禁止、または発注者の承諾を条件にする | 外注・SES・多重下請け。再委託の承諾記録が無い案件が、DDで見つかる |
| 契約上の地位の譲渡禁止条項 | 契約上の地位や権利の譲渡を禁止または制限する | 事業譲渡。民法の承諾に加えて、契約書そのものが譲渡を制限している |
COC条項の考え方はチェンジオブコントロール条項とはで整理しています。システム開発会社で実務上大きいのは、上位顧客の基本契約にこの条項があるかどうかです。売上の大半を占める顧客の契約にあれば、買い手は、顧客への説明と同意の取り方を、クロージングの条件に組み込もうとします。
売り手がやるのは、全顧客の基本契約から、これらの条項を拾い出した一覧表を作ることです。条項の有無と、顧客の承諾が必要になる場合の窓口の担当者が分かれば、買い手の質問の大半に答えられます。条項があるからといって取引が止まると決まるわけではなく、個別の有効性・効果は契約書の文言次第です。
SESの準委任が偽装請負と見られるおそれは、指示の経路と勤怠の実態で決まる
SESでは、エンジニアが顧客の現場に常駐して作業します。契約は準委任であることが多く、契約上は、顧客がエンジニアに直接指示を出さない前提です。ところが、現場の実態が違えば、DDで「偽装請負と見られるおそれ」として指摘されます。偽装請負とは、実態は労働者派遣なのに、請負や準委任などの形式をとっている状態を指す言葉として使われています。
厚生労働省の基準が見ているのは、契約書の題名ではなく実態
「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）は、請負の形式による契約で自社の労働者を従事させる事業主について、一定の要件のすべてに当てはまる場合を除き、労働者派遣事業を行う事業主とすると定めています（第2条）[3]。要件は大きく2つです。
- 労働力を自ら直接利用していること：業務の遂行方法や評価に関する指示その他の管理を自ら行うこと、始業・終業の時刻、休憩、休日、残業などの管理を自ら行うこと（単なる把握を除く）、服務規律や労働者の配置等の決定・変更を自ら行うこと[3]
- 業務を契約の相手方から独立して処理していること：業務の処理に要する資金を自らの責任で調達すること、事業主としての法律上の責任を負うこと、自己の機械・設備・材料を使うか、自ら行う企画や専門的な技術・経験に基づいて処理すること[3]
さらに第3条は、これらに当てはまっていても、法の規定に違反することを免れるため故意に偽装されたもので、真の目的が労働者派遣を業として行うことにあるときは、労働者派遣事業を行う事業主であることを免れられないとしています[3]。
厚生労働省の疑義応答集のページは、労働者派遣と請負のどちらに当たるかは、契約の形式ではなく、37号告示に基づいて実態に即して判断されるという趣旨を説明し、疑義応答集に載っていない事例は、各都道府県労働局が実態に即して個別に判断するとしています[4]。
注意点として、37号告示の条文は「請負の形式による契約」と書いています。ただ、厚生労働省の疑義応答集（第3集）は、委任・準委任も請負と同様であり、準委任契約で行われる場合でも、実態として発注者と受注者側の労働者との間に指揮命令関係があれば、契約の形式を問わず労働者派遣事業に該当し、37号告示に基づき実態に即して判断されるとしています（Q1）[8]。この考え方はアジャイル型開発以外のシステム開発にも当てはまるとされ（Q8）[8]、2021年5月13日付の事務連絡も、疑義応答集のQ10・Q11の考え方がシステム開発を請負業務とする場合にも当てはまると回答しています[5]。そのため、DDでは準委任の常駐にも同じ観点で実態を確認します。
疑義応答集の記述から、DDで見られる実態を読む
疑義応答集（第1集）は、次のように整理しています[6]。
- 作業の順序・方法の指示：発注者が作業工程の順序・方法等を指示したり、労働者の配置や一人ひとりへの仕事の割付を決めたりすることは、請負事業主が自ら指示その他の管理を行っていないことになり、偽装請負と判断される（Q7）。口頭に限らず、作業の内容・順序・方法を文書等で詳細に示し、そのとおりに作業させている場合も同様とされている
- 業務内容の変更の指示：日常的な軽微な変更について、発注者が請負労働者に直接変更を指示することは偽装請負にあたる。一方、発注者から請負事業主に変更の説明・指示をしていれば問題ない（Q11）
- 技術指導：新しい設備の使い始めなど一定の例に限って、発注者による説明を受けさせても、それだけで偽装請負と判断されるものではない（Q10）
- 日常的な会話・クレーム対応：業務に関係のない日常的な会話は指揮命令にあたらない（Q1）。作業工程の見直しの要求を請負事業主に対して行うことは、直接の指揮命令ではない（Q2）。ただし、発注者が請負労働者に直接指示した場合は直接の指揮命令に該当する
システム開発の現場に置き換えると、DDで確認される実態は次のようになります。
| 告示・疑義応答集の観点 | 確認する資料 | 気になる状態（おそれ） |
|---|---|---|
| 作業の指示を誰が出しているか（告示2条1号イ、Q7・Q11） | チャットの運用ルール、課題管理ツールの権限、朝会・定例の参加者と議事録 | 顧客の担当者が、エンジニア個人に直接タスクを割り付けている。自社の責任者を経由していない |
| 始業・終業・休憩・残業の管理（同ロ） | 勤怠システムの承認者、残業の指示の経路、休日出勤の承認記録 | 顧客が出勤時間や残業を直接指示・承認している。自社は事後に把握しているだけ |
| 服務規律と配置の決定・変更（同ハ） | 配置換えの決定記録、現場のルールの出所 | 顧客がエンジニアの交代や配置を直接決めている |
| 自社の責任者の関与（疑義応答集Q4の趣旨） | 現場責任者の任命書、自社の責任者と顧客の窓口の連絡記録 | 現場に自社の責任者がおらず、顧客と本人が直接やりとりしている |
| 作業場所の区分（Q5） | 座席表、入退室の取り決め | 座席が混在していること自体では判断されない。ただし混在が原因で顧客が必然的に直接指示してしまう場合は問題になりうる |
売り手がやるべきことは、現場ごとに「指示の経路」を書き出すことです。契約を直すのではなく、実態を整理します。実態に差がある現場が見つかったときは、M&Aの前に、契約の形式（準委任・請負・派遣）を実態に合わせるのか、現場の運用を契約に合わせるのかを、社会保険労務士・弁護士と決めておくことになります。派遣として整理する場合は、許可の有無も確認の対象になります。
買い手は、このおそれを簿外債務の可能性として見ます。見つかった場合に備えて、表明保証や補償の条項で手当てできるかが、交渉の論点になります。
準委任の再委託は委任者の許諾が前提で、多重下請けは契約と取適法の両面で見られる
SESやシステム開発では、自社のエンジニアだけでなく、パートナー企業やフリーランスにも作業を再委託することが少なくありません。DDでは、この再委託が契約上許されているかと、取引の相手方との関係で守るべきルールに触れていないかの2つが見られます。
民法644条の2：復受任者は、委任者の許諾かやむを得ない事由が要る
準委任は、法律行為でない事務の委託で、委任の規定が準用されます（民法656条）[1]。受任者が他人に再委託するときは、民法644条の2第1項が、受任者は、委任者の許諾を得たとき、またはやむを得ない事由があるときでなければ、復受任者を選任することができないと定めています[1]。
DDで確認されるのは、次の資料です。
- 顧客との契約書に、再委託の可否と条件（事前の書面承諾、再委託先の範囲、責任の所在）が書かれているか
- 再委託している案件ごとに、顧客の許諾の記録（メール、承諾書）があるか
- 再委託先との契約が、顧客との契約と同じ条件（秘密保持、権利帰属、再再委託の禁止）を引き継いでいるか
システム開発会社では、顧客の承諾の記録が無いまま、パートナーを現場に入れているケースがあります。これは買い手が契約違反として見つける典型的な箇所です。個別の契約が違反に当たるかどうかは、その契約の条文によるので、この記事では判断しません。
取適法：2026年1月1日から、下請法が変わっている
下請法は、2026年1月1日に施行された改正で、「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」（通称：取適法）になりました。公正取引委員会のリーフレットは、題名・用語の変更に加えて、従来の資本金基準に従業員基準が追加されたこと、「協議に応じない一方的な代金決定」と手形払等が禁止されたことを挙げています[7]。取引の類型には「情報成果物作成委託」があり、リーフレットはその資本金・従業員の基準を、プログラム作成か、それ以外かで分けて示しています[7]。
システム開発会社に関係するのは、次の2点です。
- 自社が委託する側のとき：パートナーやフリーランスにプログラム作成を委託している場合、取引の相手方の規模によっては取適法の対象になりえます。発注内容の明示、支払期日、代金の協議などのルールを守れているかが、DDで確認されます
- 自社が受託する側のとき：自社が元請や上位の会社から受けている発注が、対象になりうるかを整理しておくと、買い手の質問に答えやすくなります
どの取引が対象になるかは、委託する業務の内容と、双方の資本金・従業員数で決まります。準委任の人月契約がどの類型に当たるかは、委託する業務の中身によって整理が分かれるため、この記事では判断しません。公正取引委員会の取適法ガイドブックと、中小企業庁の資料で確認してください。
外注成果物の著作権と、代表者個人名義のアカウントは、売る前に会社へ移す
外注成果物の著作権
従業員が職務上作ったプログラムは、別段の定めがない限り会社が著作者になります（著作権法15条2項）[2]。一方、外注先が作ったコードは、原則として作った側に権利が残り、会社が使うには契約が必要です。さらに、著作権を譲渡する契約で、翻案権等（27条・28条）が特掲されていないときは、これらは譲渡した者に留保されたものと推定されます（61条2項）[2]。詳しい整理はWeb制作会社のM&Aで著作権とソースコードは引き継げる？にあります。
システム開発会社で、この問題が特に重くなる場面は次のとおりです。
- 顧客向けの受託開発で、顧客との契約では権利を顧客に渡す約束なのに、外注先から会社への譲渡の合意が無い。会社も顧客に渡せる権利を持っていない状態になりえます
- 自社プロダクトの一部をフリーランスに書かせたが、業務委託契約に権利条項が無い
- 顧客と権利の帰属を決めずに納品した案件の保守を、会社が続けている
売り手の作業は、案件ごとに、顧客との契約の権利条項、外注先との契約の権利条項、従業員の雇用契約・就業規則の3つを並べて見ることです。権利条項が抜けている案件は、売る前に外注先と覚書を結べるかどうかが論点になります。結べない案件は、買い手に事前に開示して、売却対象から外す選択肢もあります。
代表者個人名義のGitHub・AWS・ドメイン
小さな会社では、創業時に代表者が個人で作ったアカウントを、そのまま会社の開発に使い続けていることがあります。
| アカウント | 個人名義だと起きること | 売る前にやること |
|---|---|---|
| GitHub（組織のオーナー権限） | 組織のオーナーが代表者個人のアカウント1つだけで、会社の資産として認識されない | 会社のメールアドレスでオーナーを複数にする。個人リポジトリを組織に移す |
| AWSなどのクラウド（ルートアカウント） | 契約者が代表者個人で、請求も個人のカード。会社の資産・費用として説明できない | 契約者を法人に変更し、ルートアカウントのメールと2要素認証を会社管理にする |
| ドメイン（登録者） | 登録者が代表者個人。顧客のサービスのドメインが個人名義のまま | 登録者を法人に移す。更新の請求先と通知先を会社にする |
| SaaS・ライセンス（契約者） | 退職したエンジニアの個人アカウントで契約している | 会社名義へ契約を移し、管理者を複数にする |
買い手は、クロージング後に、すぐ開発を続けられるかを見ます。ルートアカウントや組織のオーナー権限を、売り手の代表者だけが持っている状態は、引継ぎの最後の関門になります。クロージングの日までに、買い手が管理者になれる状態を作っておくことを、スケジュールに入れてください。
OSSライセンスと開発ドキュメントは、買い手が「保守できるか」を判断する資料になる
最後の2行です。権利そのものの有無ではなく、買った後に保守を続けられるかを見る項目です。
- ソフトウェア・OSSのライセンス：自社のコードに組み込んだOSSと、そのライセンス名、商用ソフトの契約者と期間を一覧にしておきます。ライセンスごとに、再配布や改変した場合の条件が違うため、一覧が無いと、買い手は全件調べるか、補償条項で手当てするしかなくなります。顧客に納品した成果物に組み込まれたOSSも、同じ一覧に入れます
- 開発ドキュメント：設計書・仕様書・運用手順書が、どこにあり、誰が更新しているかを確認します。社長やキーパーソンの頭の中にしか無い手順は、会社の資産として引き継げないものとして扱われます。ID・パスワードの管理表も、この資料に含まれます
売り手の棚卸しチェックリストは、契約・実態・権利・アカウントの4つの順に埋める
売る・売らないを決める前にできる作業です。全部埋まっている必要はありません。空欄が分かれば、直すべき箇所が分かります。
| 区分 | 書き出すもの | 空欄・不明のときにやること |
|---|---|---|
| 契約 | 全顧客の契約書の一覧（基本契約・個別契約・保守契約）と、COC・再委託禁止・譲渡禁止条項の有無 | 契約書が無い取引は、売る前に書面を整える |
| 契約 | SES案件の一覧と、契約形態（準委任・請負・派遣） | 形態が曖昧な案件は、専門家と整理する |
| 実態 | 現場ごとの、作業指示・勤怠管理・配置決定の経路 | 顧客が直接指示している現場を洗い出す |
| 再委託 | 外注・パートナー・フリーランスの一覧と、顧客の承諾の記録 | 承諾の記録が無い案件を洗い出す |
| 人 | エンジニアの雇用契約・就業規則の職務著作の定め、フリーランスの業務委託契約 | 契約が無い人、権利条項が無い契約を洗い出す |
| 権利 | 案件別の、ソースコードと成果物の権利者（会社・顧客・外注先） | 外注先に残っている権利を、覚書で会社に移せるか確認する |
| アカウント | クラウド・GitHub・ドメイン・SaaSの契約者名義と管理者 | 個人名義のものを、会社名義に移す |
| ライセンス | 商用ソフトとOSSの一覧とライセンス名 | 一覧が無いプロジェクトから作る |
| ドキュメント | 設計書・運用手順書・ID管理表の所在 | 社長だけが知っている手順を文書にする |
自社の場合を確認する 棚卸しの前に、自社の事業の価値の見え方を確かめたい場合 → 事業価値を確認する
買い手のDD着眼点は、承諾が要る契約と、実態が契約と合っているかの2つに集まる
同じ表の裏側です。買い手が何を見て、何を条件に入れるかをまとめます。
| 着眼点 | 見る資料 | 条件に入れやすいもの |
|---|---|---|
| 上位顧客の契約にCOC条項・再委託禁止条項があるか | 上位顧客の基本契約書 | 顧客の同意取得をクロージングの前提条件にする |
| 事業譲渡で、承諾が取れない契約があるか | 契約ごとの承諾状況 | 承諾が取れない契約を譲渡対象から外す、価格に反映する |
| SES現場の実態が契約形態と合っているか | 指示の経路、勤怠の管理、配置の決定の資料 | 偽装請負と見られるおそれに備えた表明保証・補償 |
| 再委託に顧客の承諾があるか | 再委託の承諾記録、外注先の階層 | 承諾が無い案件の是正をクロージング前の条件にする |
| 取適法の対象取引で、発注・支払のルールを守れているか | 発注書面、支払サイト、価格協議の記録 | 違反が見つかった場合の補償 |
| 成果物の権利が会社に揃っているか | 権利条項の一覧、外注先の覚書 | 権利の移転を、クロージング前の条件にする |
| 買い手が管理者になれるか | アカウントの名義と管理者権限 | クロージング時にアカウントの管理者を移す手順を契約に入れる |
| キーパーソンが残るか | 雇用契約、競業避止・秘密保持の定め | 重要エンジニアの在籍をクロージングの条件にする |
買い手の関心は、「権利や契約が会社にあるか」と「SESの現場が適法に運用されているか」に集約されます。どちらも、売る前に自力で直せる種類の問題です。
まとめ：株式譲渡と事業譲渡の違いは、契約書の束と現場の実態を並べて初めて確かめられる
株式譲渡と事業譲渡で何が動くかは、表の構造として整理できます。実際に動くかどうかは、顧客の契約書の条項と、現場の実態で決まります。偽装請負と見られるおそれ、再委託の許諾、外注成果物の権利、個人名義のアカウントは、いずれも売り手が自力で整えられます。DDで見つかってから直すのではなく、見つかる前に書き出して整理しておくことが、交渉の主導権を保つ方法です。
よくある質問（FAQ）
Q1. 株式譲渡なら、顧客との契約は何もしなくてもそのまま続きますか？ A. 契約の当事者は会社のまま変わらないので、原則として契約は続きます。ただし、契約書にチェンジオブコントロール条項があれば、株主が変わったことで相手方の同意や通知が必要になる場合があります。条項の有無と内容は契約書ごとに違うため、上位顧客の契約書から順に確認してください。個別の効果は判断しません。
Q2. 事業譲渡で顧客との保守契約を買い手に移すには、どうすればよいですか？ A. 民法539条の2により、契約の当事者の一方が第三者との間で契約上の地位を譲渡する旨の合意をした場合に、契約の相手方がその譲渡を承諾したときは、契約上の地位がその第三者に移転します。顧客ごとに承諾を取る必要があり、承諾が取れない契約は移りません。個別の進め方は専門家にご相談ください。
Q3. SESで顧客がエンジニアに作業を直接指示していると、偽装請負になりますか？ A. 契約の題名ではなく実態で見られます。厚生労働省の37号告示は、業務の遂行方法の指示、始業・終業や残業の管理、配置の決定などを事業主が自ら行っていることを、請負と見る要件に挙げています。疑義応答集も、発注者が請負労働者に直接指示した場合は直接の指揮命令に該当するとしています。特定の働き方が当たるかどうかの個別の判断は、この記事では行いません。労働局や専門家にご確認ください。
Q4. 外注先が書いたコードの著作権は、M&Aで買い手に引き継げますか？ A. 外注先に権利が残っている場合、会社はその権利を持っていないので、買い手に移すこともできません。会社が権利を持つには、外注先との契約に譲渡の定めが必要で、翻案権等（27条・28条）を含めるかどうかは同法61条2項で扱いが変わります。条文の整理はWeb制作会社のM&Aで著作権とソースコードは引き継げる？にあります。
Q5. 代表者個人のGitHubやAWSのアカウントで開発しています。売却前にどうすればよいですか？ A. 契約者名義・管理者権限・請求先を会社に移すのが基本です。GitHubは組織のオーナーを会社のアドレスで複数にし、AWSはルートアカウントの契約者とメール・2要素認証を会社管理にします。ドメインは登録者を法人にします。買い手はクロージング後にすぐ開発を続けられるかを見るため、管理者を移せる状態にしておくと引継ぎが進みます。
Q6. 準委任で受けた業務を、パートナー企業に再委託してもよいですか？ A. 民法644条の2により、受任者は、委任者の許諾を得たとき、またはやむを得ない事由があるときでなければ、復受任者を選任できません（準委任には同法656条により委任の規定が準用されます）。顧客との契約書に再委託の条件が書かれていれば、その条件にも従う必要があります。個別の契約が許しているかどうかは契約書の文言によるため、専門家にご確認ください。
Q7. 取適法は、システム開発会社の外注にも関係しますか？ A. 2026年1月1日に下請法から取適法に変わり、適用基準に従業員基準が加わりました。取引の類型には情報成果物作成委託があります。パートナーやフリーランスへの委託が対象になるかは、委託する業務の内容と、双方の資本金・従業員数で決まります。詳しくは公正取引委員会の取適法ガイドブックで確認してください。
出典
- e-Gov法令検索「民法」（明治二十九年法律第八十九号）第539条の2・第625条・第644条の2・第656条 https://laws.e-gov.go.jp/law/129AC0000000089
- e-Gov法令検索「著作権法」（昭和四十五年法律第四十八号）第15条・第61条 https://laws.e-gov.go.jp/law/345AC0000000048
- 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号、最終改正 平成24年厚生労働省告示第518号）第2条・第3条 https://www.mhlw.go.jp/content/000780136.pdf
- 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」 https://www.mhlw.go.jp/bunya/koyou/gigi_outou01.html
- 厚生労働省 職業安定局 需給調整事業課 事務連絡（令和3年5月13日）「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37号告示）に係る疑義応答集について」 https://www.mhlw.go.jp/content/000780139.pdf
- 厚生労働省「37号告示に関する疑義応答集（第1集）」 https://www.mhlw.go.jp/content/001328443.pdf
- 公正取引委員会「取適法リーフレットNo.01」（令和7年8月） https://www.jftc.go.jp/file/toriteki_leaflet.pdf
- 厚生労働省「37号告示に関する疑義応答集（第3集）」 https://www.mhlw.go.jp/content/001704257.pdf