システム開発会社のM&Aの留意点を徹底解説｜売り手・買い手別DD・PMI・スキーム選択まで

「M&Aでシステムエンジニアはそのままついてくるのか。ITの会社を買収する場合、ソースコードの著作権は誰のものになるのか」「SES契約が多い会社を買収して問題はないのか」——システム開発会社のM&Aを検討する経営者・担当者から、こうした専門的な疑問や不安を多く耳にします。

システム開発会社のM&Aは、一般的なM&Aとは異なるIT業界固有の論点が多数存在します。ソースコードや知的財産権の帰属確認、SES（システムエンジニアリングサービス）契約の偽装請負リスク、技術的負債の定量評価、主要エンジニアの離職リスクといった問題は、M&Aの専門家であっても、IT業界の実務を知らなければ見落としやすい落とし穴です。M&A後にこれらのリスクが顕在化すれば、想定外のコストや訴訟リスク、事業継続の危機につながりかねません。

本記事では、システム開発会社のM&Aを検討する売り手・買い手の双方を対象に、市場動向・売却相場の解説から始まり、売り手・買い手それぞれの視点でのIT業界特有の留意点を網羅的に解説します。デューデリジェンスのチェックリスト、M&Aスキームの選択基準、PMI（統合後管理）の具体的な施策、さらにはM&Aとアライアンス・資本業務提携の使い分けまで、実務レベルの情報をお届けします。

1. システム開発会社のM&A市場動向と活発化する背景

IT人材不足と「2025年の崖」がM&Aを後押しする理由

システム開発会社のM&Aが急増している最大の背景のひとつが、深刻なIT人材不足です。経済産業省が発表した「IT人材需給に関する調査」（2019年）によると、2030年には最大で約79万人のIT人材が不足すると予測されています。需要が拡大する一方で供給が追いつかず、即戦力のエンジニアを採用することは多くの企業にとって困難を極めています。

こうした状況の中で注目されているのが、システム開発会社のM&Aを通じた「アクハイアリング（Acqui-hiring）」という手法です。アクハイアリングとは、M&Aによって企業（会社）ごと人材を獲得する戦略を指します。採用コスト・研修コスト・定着リスクを削減しながら、即戦力のエンジニアチームを一括で取り込めることから、IT人材獲得の手段としてM&Aの価値は高まっています。

また、「2025年の崖」と呼ばれる問題も、M&A需要を押し上げています。経済産業省が指摘したこの問題は、多くの日本企業が老朽化した基幹システム（レガシーシステム）の刷新を先送りにしており、2025年以降に技術的・経済的な限界を迎えるというものです。DX（デジタルトランスフォーメーション）推進のためのシステム刷新需要が急増する中、社内にITリソースを持たない事業会社がシステム開発会社をM&Aで取り込む動きが加速しています。

ポイント：IT人材不足×DX投資がM&A需要を構造的に押し上げ
ITエンジニアの有効求人倍率は全職種平均を大きく上回る水準が続いており、新規採用での人材確保が困難な状況が続いています。自社でエンジニアを育成する時間的余裕がない事業会社にとって、システム開発会社のM&Aはエンジニアチームを「即買い」できる最短ルートとなっています。

後継者問題とSES多重構造の変化がもたらすM&A需要

IT人材獲得需要が買い手側のM&A動機であるとすれば、後継者問題は売り手側の主要なM&A動機です。帝国データバンクの「全国企業後継者不在率動向調査（2022年）」によると、日本の中小企業の後継者不在率は57.2%に達しています。システム開発会社の多くは中小企業であり、創業者・経営者の高齢化と後継者不在を背景に、事業承継の手段としてM&Aを選択するケースが増えています。

また、SES（システムエンジニアリングサービス）業界特有の多重下請け構造の変化も、M&Aを後押しする要因となっています。大手IT企業が内製化を進める動きや、クライアント企業がDX戦略上の理由からベンダーを絞り込む傾向が強まったことで、3次・4次の下請けポジションにあるSES会社の受注が細りつつあります。こうした構造変化に直面したSES会社が、元請けポジションを持つ会社との統合を選択するケースも増えています。

さらに、クラウドコンピューティングの普及・AI・生成AIの台頭によって、システム開発会社に求められる技術スタックが急速に変化していることも、業界再編を促進しています。従来のオンプレミス・ウォーターフォール型開発を中心としていた企業が、クラウドネイティブ・アジャイル開発に強みを持つ企業とのM&Aで競争力強化を図るという動きも顕在化しています。

国内ITサービス市場の規模とM&A件数推移

国内のITサービス市場は着実に拡大を続けています。IDC Japanの調査によると、国内ITサービス市場は2028年に8兆円を超える規模に達すると予測されています。総務省「情報通信白書令和4年版」では、日本の民間企業IT市場が2020年度で12兆9,700億円規模であることが示されており、矢野経済研究所は2025年度の国内ITサービス市場を約15兆5,300億円と予測しています。

市場規模の拡大とともに、システム開発会社を対象にしたM&A件数も増加傾向にあります。レコフデータの調査によると、IT・情報通信分野のM&A件数は近年で年間400〜500件規模で推移しており、国内M&A全体の中でも最も件数の多い業種のひとつです。市場の成長性・人材獲得ニーズ・後継者問題の三つが重なり、システム開発会社を対象にしたM&Aはしばらく活発な状況が続くと見込まれています。

2. システム開発会社M&Aの売却相場とバリュエーション

年倍法（EBITDA・営業利益ベース）による概算

システム開発会社のM&Aにおける売却相場を把握するには、主に「年倍法（EV/EBITDA倍率法）」が活用されます。年倍法とは、EBITDA（税引前利益＋減価償却費）または営業利益に一定の倍率を掛けて企業価値を算出する方法です。システム開発会社の場合、一般的なEBITDA倍率は3〜7倍程度が目安とされていますが、事業の安定性・収益性・成長性によって大きく変わります。

たとえば、年間営業利益が5,000万円のシステム開発会社の場合、EBITDA倍率5倍で計算すると企業価値は2億5,000万円となります。ここから純負債（借入金－現金）を差し引いたものが株式価値（売却価格の目安）となります。ただし、これはあくまで概算であり、実際の売却価格は企業固有の要素（顧客構成・技術力・エンジニアの質・成長見通し）によって上下します。

なお、受託開発中心かSES中心かによっても倍率の評価軸が異なります。受託開発はプロジェクト単位の収益変動が大きいため安定性が評価されにくい一方、SESはエンジニアの稼働率が安定収益に直結するため、安定したキャッシュフローを持つSES会社は比較的高い倍率がつきやすい傾向があります。

ポイント：売却相場は「事業の質」で大きく変わる
EBITDA倍率はあくまで出発点です。元請け比率が高い・長期契約の顧客が多い・モダンな技術スタック（クラウド・AI対応）を持つ・エンジニアの定着率が高い、といった要素が評価を押し上げます。逆に、特定顧客への売上依存度が高い・技術的負債が多い・キーマン依存が強いといった要素は評価を引き下げます。

エンジニア単価ベースのバリュエーション手法

システム開発会社・特にSES企業のM&Aでは、エンジニア1人あたりの価値から企業価値を逆算するアプローチも用いられます。これは「エンジニア単価ベースのバリュエーション」とも呼ばれ、アクハイアリング（人材獲得目的のM&A）の場合に特に有効な評価手法です。

エンジニア1人を新規採用する場合、採用コスト（エージェント報酬・求人広告）・入社後の研修コスト・定着リスクを合計すると、一般的に100万〜300万円程度のコストがかかります。ミドル・シニアクラスのエンジニアや希少な専門領域（AI・セキュリティ・クラウドアーキテクト等）の場合はさらに高くなります。エンジニアの質と規模によっては、1人あたり200〜500万円の採用コストを基準に「エンジニア価値」を計算し、それに企業の将来収益価値を加えた評価額が交渉の土台となることもあります。

買い手側が「人材獲得コスト」の観点でM&Aを評価する場合、通常の財務バリュエーションより高い評価額を提示するケースもあります。エンジニア市場の逼迫度合いや、M&A対象企業のエンジニア技術レベル・専門性によっては、財務的な評価額を大幅に上回る価格での売却が実現した事例も少なくありません。

評価額を左右する要因〜元請け比率・技術スタック・顧客構成〜

システム開発会社のM&A評価額を大きく左右する非財務指標のうち、最も重要なものが「元請け比率」です。元請け（クライアントから直接受注）の案件比率が高いほど、利益率・交渉力・顧客との関係性が安定しているため、評価額は高くなる傾向があります。逆に、多重下請けの3次・4次ポジションが中心のSES会社は、利益率が低く・元請け企業の方針変更に左右されやすいため、評価額が抑えられやすいです。

次に重要なのが「技術スタック」の評価です。Python・Go・TypeScriptといったモダンな言語・フレームワークへの対応力、AWS・GCP・Azureのクラウドアーキテクト資格を持つエンジニアの有無、AI・機械学習・データ分析領域の開発実績——こうした技術力は買い手から高く評価されます。一方、COBOLや古いJava・Perl等のレガシー技術に偏っている場合、市場での希少性はある一方で、将来の事業継続性に疑問が持たれ評価が下がるケースもあります。

顧客構成の安定性も重要な評価軸です。売上の上位3社で全体の70%以上を占めている場合は「顧客集中リスク」とみなされ、評価額の押し下げ要因となります。特定の大手クライアントとの長期継続契約が主要な売上源である場合は、そのクライアントとの関係維持がM&A後の最重要課題のひとつとなります。

3. 売り手（売却側）が知るべき留意点

ソースコード・知的財産権の帰属確認と整理【最重要】

システム開発会社M&Aにおいて、他業種のM&Aと決定的に異なる最大の特徴が「知的財産（IP）の帰属問題」です。一般的に、受託開発で作成されたソフトウェアの著作権は、契約内容によってクライアント（発注者）に帰属する場合と、システム開発会社（受注者）に帰属する場合があります。M&Aの対象企業が保有していると思っていたシステム・ソースコードが、実はクライアントに著作権が帰属していて「保有資産」にならないケースは業界でよく見られます。

売り手側が最初に行うべきなのは、自社が開発・保有するソフトウェア・システムについて、著作権帰属の状況を全件棚卸しすることです。具体的には以下の観点で整理します。

• 自社名義で著作権を保有しているプロダクト・パッケージソフトウェア
• 受託開発した成果物のうち「著作権は受注者帰属」と契約書に明記されているもの
• 著作権帰属が曖昧・未記載の成果物（追加交渉・契約補完が必要）
• オープンソースライセンス（GPL・MITなど）が適用されているコードの有無
• 従業員・フリーランスが作成したコードの著作権帰属（就業規則・業務委託契約で職務著作を規定しているか）

特に注意が必要なのは、フリーランスやSES契約のエンジニアが開発に関与したコードです。会社の従業員が職務上作成したプログラムは「職務著作」として会社が著作権を持ちますが、フリーランスや業務委託の場合は、契約書で明示的に著作権を会社に移転する旨を定めていなければ、個人（フリーランス）に著作権が残ります。こうした権利関係が整理されていないまま売却すると、買い手がコードを利用できないというトラブルに発展しかねません。

注意点：著作権の「不整備」はM&A交渉を頓挫させる最大の地雷
受託開発成果物の著作権帰属が曖昧な場合、DDの過程で発覚し、買い手が取引を中断・価格を大幅に引き下げるリスクがあります。売却を検討するなら、早期に弁護士とともに既存契約を見直し、著作権の帰属・移転条項を整備しておくことが不可欠です。

主要エンジニアへのキーマンリスクと開示タイミング

システム開発会社の最大の資産は「人材（エンジニア）」です。特定の技術領域・顧客プロジェクトで中核を担う「キーマンエンジニア」が離職した場合、事業に多大な影響を及ぼします。このキーマンリスクは、M&A交渉において買い手が最も神経質になる問題のひとつです。

売り手側の経営者は、自社のキーマンエンジニアを事前に把握し、以下の点を整理しておく必要があります。

• 社内で代替不可能な技術・知識を持つエンジニアは誰か
• そのエンジニアが離職した場合に影響を受ける顧客・プロジェクトはどこか
• M&A情報が社内に漏れた際に離職リスクが高いエンジニアは誰か
• 引き留めに必要な処遇（給与・役職・裁量）を提供できる体制か

M&AはM&A成立まで秘密保持が原則です。従業員・エンジニアへの開示は、M&Aが成立（クロージング）した後が基本です。しかし、キーマンエンジニアが事前に情報を察知して離職するリスクを考えると、クロージング直前の段階でキーマンへのサウンディング（非公式な意向確認）と、M&A後の処遇提示を行うことが実務上は有効です。

買い手側もDDでキーマンエンジニアのリテンション計画を求めることが多く、M&A交渉の中で「キーマンへのストックオプション付与」「役員就任」「賃金テーブルの改善」といったリテンション施策をセットで取り決めるケースが増えています。

ポイント：キーマンエンジニアの引き留めプランをM&A条件に組み込む
M&A成立後にキーマンエンジニアが離職しないよう、クロージング前に主要エンジニアとの個別面談・処遇改善案の提示を行い、M&A契約書（最終合意書）にリテンションボーナス条件を盛り込む交渉も有効です。エンジニアのリテンション施策をM&A条件として明示することで、買い手側の不安を払拭しやすくなります。

顧客・取引先への開示と秘密保持の管理

M&Aの情報は極めて機密性が高く、交渉段階での情報漏えいは売り手・買い手双方に深刻なダメージをもたらします。特に、システム開発会社の場合、顧客（取引先）への情報漏えいによって「開発委託先の変更」「発注量の削減」といった影響が生じるリスクがあります。

M&A交渉を始める段階では、相手先との秘密保持契約（NDA）の締結が最初のステップです。NDAにはM&Aの検討事実そのものを第三者に開示しない旨を明確に規定します。また、売り手側社内でM&Aを知る人物の範囲を最小限（経営者・CFO・顧問弁護士のみ等）に絞ることが重要です。

クロージング後の顧客への通知は、契約書で規定された手続きに従って行います。主要顧客への挨拶回りは、経営者が直接行うことが望ましく、「経営体制は変わるが、担当エンジニア・サービス内容・品質に変化はない」という点を丁寧に説明することで、取引継続への不安を最小化することができます。

情報漏えいリスク〜DD段階でのデータ開示範囲〜

M&Aのデューデリジェンス（DD）では、買い手側が対象企業の機密情報（財務資料・顧客情報・契約書・技術資料）を精査します。システム開発会社の場合、ソースコード・顧客の業務ロジックを含むシステム仕様書・エンジニアの個人情報など、高い機密性を持つ情報が含まれます。

• ビューアールーム（データルーム）にアップロードする資料の範囲を段階的に絞る（初期DDは概要資料のみ→基本合意後に詳細資料）。
• ソースコードの開示はDD後期〜クロージング直前に限定し、技術顧問やCTOによるレビューのみに留める
• 顧客名を伏せたマスキング版の契約書・売上明細で初期対応し、基本合意後に顧客名を開示する。
• データルームへのアクセスログを管理し、情報の持ち出しを防ぐ。
• M&Aが不成立になった場合の資料返却・廃棄を義務付ける条項をNDAに盛り込む。

特にSES企業では、常駐エンジニアの配属先クライアント情報が極めて重要な機密情報です。クライアントに無断でM&A情報を開示することは、SES基本契約の守秘義務違反となりかねないため、開示範囲と時期には細心の注意が必要です。

注意点：DD段階でのソースコード開示は段階的・限定的に
DDの過程でソースコードを全開示すると、M&Aが不成立になった場合に技術情報が流出するリスクがあります。ソースコードレビューは、基本合意書締結後の後期DDに限定し、NDAの範囲・目的外使用禁止条項を厳格に定めたうえで実施することが原則です。

4. 買い手（買収側）が知るべき留意点〜デューデリジェンスの重点項目〜

技術的負債・コード品質のDD（レガシーシステム対応コスト）

システム開発会社のM&Aにおいて、買い手側が財務DDと同等かそれ以上に重要視すべきなのが「技術的負債の調査」です。技術的負債とは、開発スピードを優先するために将来的な修正・改善が困難な設計・実装を積み重ねた結果、システムの維持管理コストが膨張している状態を指します。

技術的負債の調査（テクニカルDD）では、以下の観点からシステムの現状を評価します。

• コードの可読性・テストコードのカバレッジ率（テストが存在しないコードは修正リスクが高い）
• ドキュメントの整備状況（設計書・API仕様書・運用手順書の有無と最新性）
• 依存しているOSS・ライブラリのバージョン（EOL＝サポート終了のものが多いと脆弱性リスク）
• レガシー言語・フレームワークへの依存度（COBOL・古いPHP・サポート切れのJavaなど）
• クラウド移行の進捗（オンプレミス中心の場合、クラウド移行コストが発生）
• CI/CD（継続的インテグレーション・デリバリー）パイプラインの整備状況

技術的負債の解消コストが想定より大きかった場合、M&Aの買収価格を引き下げる交渉の根拠となります。逆に、技術的負債が少なく・テストカバレッジが高く・CI/CDが整備されているシステムは「高品質な技術資産」として評価額を引き上げる要因となります。テクニカルDDの実施には、外部のITエンジニア・CTO経験者・テクニカルアドバイザーを活用することを強く推奨します。

ポイント：テクニカルDDには外部のCTO・技術顧問を活用する
M&A専門のFAや弁護士・会計士は財務・法務の専門家ですが、ソースコードやインフラアーキテクチャの品質評価には限界があります。テクニカルDDには、対象企業の技術スタックに精通した外部エンジニア・CTOアドバイザリーサービスを活用することで、見えにくいリスクを表面化させることができます。

SES契約の実態と偽装請負リスクの確認

SES企業を買収する際に、買い手側が最も注意すべき法的リスクのひとつが「偽装請負」の問題です。偽装請負とは、形式上は業務委託（SES）契約であるにもかかわらず、実態は派遣労働（指揮命令）が行われているケースを指します。労働者派遣法に違反する偽装請負は、発注者側（クライアント）・受注者側（SES会社）双方が行政処分・業務停止命令の対象となりえます。

• エンジニアがクライアント先に常駐し、クライアントの指揮命令下で業務を行っていないか（業務委託の場合、指揮命令はSES会社が行うのが原則）。
• SES基本契約書に「業務の範囲・成果物・作業場所・指揮命令系統」が明確に定義されているか。
• 「準委任契約」として締結されているSES契約で、実態が請負になっていないか（成果物の完成責任を負わせる形での擬似請負）。
• 過去に労働基準監督署・都道府県労働局の調査・指摘を受けた実績がないか。
• クライアント先でのエンジニアの労働時間管理がSES会社側でできているか。

偽装請負が発覚した場合、M&A後に行政処分（事業停止命令）が下される可能性があり、売上の大部分がSESで成り立っているビジネスモデルの会社では致命的なリスクとなります。DDの段階でSES契約書を全件確認し、法律専門家（労働法に精通した弁護士）と連携して実態調査を行うことが不可欠です。

注意点：SESの偽装請負は売上消失・行政処分のリスクに直結
SES会社のM&AでDDを省略・簡略化すると、偽装請負の実態が発覚せずに買収してしまうリスクがあります。特に、クライアント常駐型のSES案件が多い企業については、労働法専門の弁護士による法務DDを必ず実施してください。

知的財産・ライセンス・特許のIP調査

買い手側のDDにおける知的財産調査（IP-DD）では、対象企業が保有する知的財産の状況を網羅的に確認します。システム開発会社においてIP-DDが必要な理由は、「買収後に実際に利用・活用できる知的財産がどれほどあるか」が企業価値に直結するためです。

• 自社プロダクト・パッケージソフトウェアの著作権帰属（会社名義であることの確認）
• 特許出願・登録状況（技術特許がある場合は有効期間・権利範囲を確認）
• オープンソースソフトウェア（OSS）の利用状況と使用ライセンス（GPL等のコピーレフトライセンスが含まれていないか）
• 社内で利用している有償ソフトウェア・開発ツールのライセンス（M&A後に承継できるライセンス契約か）
• 「ソースコード共有禁止」等の契約制限がついているクライアント案件のコードが混在していないか
• 従業員・フリーランスが作成したコードの著作権帰属（職務著作規定の確認）

OSSのGPLライセンスが適用されたコードが商用プロダクトに組み込まれている場合、そのプロダクトのソースコード全体を公開する義務が生じる可能性があります。こうしたライセンスの問題は、特殊な法的知識が必要となるため、IT法務に精通した弁護士・技術顧問の関与が不可欠です。

クラウドインフラ・ツールライセンスの承継確認

現代のシステム開発会社はAWS・GCP・Azureをはじめとするクラウドインフラや、JiraやGitHub・Slack・Figma等の開発・コミュニケーションツールを日常的に利用しています。M&Aに際しては、これらのサービス契約・ライセンスがM&A後に承継できるかどうかを事前に確認することが重要です。

• クラウドサービス（AWS・GCP・Azure）の利用契約：法人名義での契約であればM&A後も利用継続可能なケースが多いが、株式譲渡か事業譲渡かによって手続きが異なる。
• GitHub等のソースコード管理サービス：Organizationとして管理されているか（個人アカウントベースだとリスクあり）。
• SaaSツール（Slack・Jira・Confluenceなど）：ライセンス数・契約形態の確認と、M&A後の統合計画。
• クラウド上のデータ（DB・ストレージ）の所有権・管理権限：クライアントデータが混在していないか。
• 特定のエンジニアの個人アカウントで管理されているサービス・ドメイン・DNSがないか（属人化リスク）。

特に問題になりやすいのが、エンジニアの個人アカウントでクラウドリソースやドメインが管理されているケースです。そのエンジニアが退職すると、重要なシステムにアクセスできなくなるリスクがあります。DD段階でこの属人化リスクを把握し、M&A後のガバナンス移行計画を明確にしておくことが重要です。

サイバーセキュリティ体制のDD

システム開発会社はクライアントの機密情報・個人情報・業務ロジックを扱うことが多く、高いセキュリティ基準が求められます。M&A後にセキュリティインシデント（情報漏えい・不正アクセス）が発生した場合、旧経営体制下でのセキュリティ管理の不備に起因するものであっても、買い手側がその責任を負うことになります。

• 情報セキュリティ管理規程・ポリシーの整備状況（ISMS認証の取得有無）
• 過去のセキュリティインシデント（情報漏えい・不正アクセス）の発生履歴と対応記録
• 開発環境・本番環境のアクセス権限管理（最小権限の原則が守られているか）
• 脆弱性診断・ペネトレーションテストの実施状況と結果
• クライアントデータの取り扱い規定と実態（個人情報保護法・GDPR対応）
• 退職者アカウントの即時無効化プロセスが整備されているか

特にクロスボーダーM&Aの場合、買収対象企業がGDPR（EU一般データ保護規則）の適用対象となるEU圏の顧客データを扱っている場合は、GDPRコンプライアンス体制の確認が必要です。GDPRへの不適切な対応は多額の制裁金リスクをはらんでいます。

注意点：セキュリティ体制の不備はM&A後に買い手の「負債」となる
M&A前のセキュリティ管理の不備（脆弱性・パスワード管理不足・アクセス権の野放し）は、M&A後のインシデント発生時に買い手が全責任を負う事態になりえます。セキュリティDDは専門のセキュリティベンダーに依頼し、脆弱性スキャンや設定レビューを必ず実施してください。

5. M&Aスキーム選択の留意点

株式譲渡 vs 事業譲渡 〜IT業界特有の判断基準〜

M&Aのスキーム（手法）の選択は、税負担・リスク承継範囲・手続きコスト・取引のスピードに大きな影響を与えます。システム開発会社のM&Aで最も多く用いられるスキームは「株式譲渡」と「事業譲渡」の2種類です。それぞれの特徴と、IT業界特有の判断基準を解説します。

株式譲渡の特徴とIT業界での向き・不向き

株式譲渡は、対象会社の株式（全部または一部）を買い手が取得するスキームです。株式を取得することで会社そのもの（権利義務を含む一切）を承継します。IT業界における株式譲渡のメリットは、既存の取引先との契約・SES基本契約・ソフトウェアライセンス・エンジニアの雇用契約がすべてそのまま継続される点です。顧客への個別通知や契約の巻き直しが不要なケースが多く、スムーズな事業継続が可能です。一方、簿外債務・潜在的なリスク（偽装請負・セキュリティインシデント・税務リスク）を含む会社全体を承継するため、DDによる徹底的なリスク洗い出しが不可欠です。

事業譲渡の特徴とIT業界での向き・不向き

事業譲渡は、会社の特定の事業（資産・契約・従業員等）を選択的に買い手に移転するスキームです。不要な負債やリスクを引き継がずに「欲しい部分だけ」を取得できるため、リスク管理の観点では優れています。ただし、システム開発会社の場合、既存のSES基本契約・ソフトウェアライセンス・雇用契約を個別に移転する必要があり、クライアント・エンジニアそれぞれに個別の同意取得が必要となります。クライアント数が多い・エンジニアが多い場合は事務的な負担が大きく、手続きに時間がかかる点がデメリットです。

会社分割・合併が有効なケース

会社分割は、会社の特定事業を分割して別会社に移転するスキームです。システム開発会社の場合、例えば「受託開発事業」と「SES事業」を分離して、受託開発事業のみを買い手に売却する際に活用されます。会社分割は株式譲渡と同様に包括承継ができるため、個別の契約移転の手続きが不要です。

合併（吸収合併・新設合併）は、2社以上の会社を1つに統合するスキームです。買い手側の法人に対象企業を吸収するケースが一般的です。IT業界での合併活用例として、グループ会社として傘下に置いていたシステム開発子会社を、PMI後の一定期間を経てから本体に吸収合併するケースが挙げられます。合併はPMIが完了し組織文化・システム統合が進んだ後のフェーズで検討されることが多いです。

SES事業・受託開発事業の取り扱いとスキーム選択

SES事業と受託開発事業では、M&Aスキーム選択に際して考慮すべき要素が異なります。SES事業は「人材（エンジニア）」と「クライアントとのSES基本契約」が主な資産です。株式譲渡であればSES基本契約はそのまま継続されますが、事業譲渡の場合はクライアントごとに契約移転の同意が必要となります。クライアント数が多いSES企業では、事業譲渡の事務負担が膨大になるため、株式譲渡が選択されるケースがほとんどです。

受託開発事業のM&Aでは、進行中のプロジェクト（仕掛品）の取り扱いが重要です。株式譲渡なら進行中のプロジェクトもそのまま引き継がれますが、事業譲渡の場合は個別プロジェクトごとにクライアントの同意が必要です。また、受託開発の成果物（ソースコード）の著作権帰属が複雑な場合、事業譲渡で「著作権が会社に帰属していない成果物」を誤って「資産」として移転しようとすると法的問題が生じます。株式譲渡・事業譲渡いずれの場合も、進行中プロジェクトとその権利関係の棚卸しは必須です。

6. PMI（統合後管理）の留意点〜開発文化の融合と人材定着〜

エンジニアの離職防止とリテンション施策の具体策

システム開発会社のM&Aにおいて、クロージング（取引成立）後に最も多く発生する問題が「エンジニアの大量離職」です。M&A情報が開示された直後、処遇・職場環境・開発スタイルの変化への不安からエンジニアが転職活動を始めるケースは珍しくありません。特に、優秀なエンジニアほど早期に行動を起こします。

• M&A公表と同時（またはクロージング直後）に経営陣からエンジニア全員への直接説明会を実施する（M&A後のビジョン・処遇方針を明確に伝える）。
• リテンションボーナス：M&A後1〜2年間在籍を条件に特別賞与を支払う（金額の目安は年収の20〜50%程度）。
• ストックオプション・株式報酬：統合後の会社成長に連動したインセンティブを付与する。
• 賃金テーブルの改善：買い手側の給与水準が高い場合は早期に統一し、エンジニアの不満を解消する。
• 技術ビジョンの提示：「M&A後にどんな技術・プロジェクトに取り組めるか」を具体的に示し、技術者としての成長機会をアピールする。
• 個別面談の実施：全エンジニアに対してM&A後3カ月以内に1on1を行い、個別の懸念・希望を把握する。

エンジニアがM&Aに不安を感じる最大の理由は「情報の不確実性」です。M&Aがどのように自分の仕事・処遇に影響するかが分からないと、最悪の事態を想定して行動します。オープンなコミュニケーションと、具体的な処遇改善策の早期提示が離職防止の最善策です。

ポイント：PMI最初の100日間がエンジニアリテンションの勝負どころ
M&Aクロージング後の100日間は、PMIにおいて最も重要な時期です。この期間にエンジニアの不安を解消し、新体制への納得感を醸成できるかどうかが、その後の定着率を大きく左右します。100日間のコミュニケーション計画（説明会・1on1・経営層との対話機会）を事前に策定し、PMI初日から実行することが成功の鍵です。

開発文化の統合（アジャイル vs ウォーターフォール）

システム開発会社のPMIにおいて見落とされやすい重要課題が「開発文化の統合」です。買い手側の会社がアジャイル開発（スクラム・カンバン）を採用している場合でも、買収した会社がウォーターフォール型開発を中心としている場合、開発プロセスの統合には相当の時間と摩擦を要します。

アジャイルとウォーターフォールの違いは単なる「開発手法」の差ではなく、仕事の進め方・コミュニケーションスタイル・成果の定義・チームの自律度の違いに根ざしています。ウォーターフォール文化で育ったエンジニアにとって、「要件定義が曖昧なまま開発を始めて繰り返し改善する」アジャイルのアプローチは、最初は強いストレスとなります。

• 文化の強制統合は避ける：M&A直後から一方的に「全員アジャイルに切り替え」は混乱を招く。移行ロードマップを6〜18カ月スパンで設計する。
• パイロットチームを設ける：新しい開発手法を全社展開する前に、有志エンジニアによるパイロットチームで試行し、学習・調整を行う。
• エンジニアリングマネージャーの役割を明確にする：文化融合のリード役となるEM（エンジニアリングマネージャー）を配置し、現場レベルでの摩擦解消を促進する。
• 技術勉強会・社内ハッカソンで交流機会を作る：両社のエンジニアが互いの技術・文化を学び合う機会を設け、一体感を醸成する。

技術スタック統合ロードマップの策定

2社が統合した場合、使用する開発言語・フレームワーク・クラウド環境・開発ツールが重複・競合するケースが生じます。「AチームはフロントエンドにVue.js、BチームはReact」「AチームはAWS、BチームはAzure」といった状況が発生すると、システム統合・共同開発時のコストが増大します。

• 現状把握：両社の全システム・プロダクトで使用している言語・フレームワーク・インフラ・ツールをリスト化する。
• 優先度付け：重複している技術スタックのうち、統一すべきもの・共存させてよいものを判断する（顧客プロジェクトへの影響を最小化する順序で進める）。
• 移行計画策定：どの技術スタックを主軸にするかを決定し、移行期間・担当チーム・学習コストを計画に盛り込む。
• ガードレールの設定：新規プロジェクトから採用する技術スタックを標準化し、旧来の技術は既存プロジェクトの保守に限定する方針を定める。

技術スタックの統合は、エンジニアの学習コスト・既存プロジェクトへの影響・移行コストを丁寧に考慮しながら進める必要があります。性急な統合はエンジニアの不満・バグ増加・品質劣化につながります。

オフショア拠点・海外子会社の統合リスクへの対応

近年、コスト削減・人材確保を目的にベトナム・インド・フィリピン・中国などにオフショア開発拠点を持つシステム開発会社が増えています。そうした会社をM&Aで取得する場合、オフショア拠点の統合には国内PMIとは異なる固有リスクが伴います。

• 言語・コミュニケーションの壁：現地エンジニアと日本側のコミュニケーション体制を維持・強化するため、ブリッジSE（日本語と現地語の双方に通じるエンジニア）の役割を確認・引き継ぐ。
• 現地法規制・労働法の確認：雇用契約・解雇規制・税務（移転価格問題）は国ごとに異なり、専門の現地弁護士・会計士との連携が必須。
• 知的財産権の所在確認：オフショアで開発したコードの著作権・秘密情報管理の契約が適切に整備されているかを確認する。
• カントリーリスク：地政学的リスク・外交関係の変化が事業継続に影響する可能性を評価する（特に中国子会社の場合）。
• 品質管理体制：オフショア拠点のコード品質管理・テスト体制・セキュリティ体制を日本本社側の基準で評価・改善する計画を立てる。

オフショア拠点は適切に統合すれば大きなコスト競争力となりますが、統合プランなしに放置すると品質・セキュリティ・コンプライアンス上の問題が生じるリスクがあります。DD段階でオフショア拠点の実態調査（現地訪問を含む）を行うことを推奨します。

7. M&AとアライアンスS・資本業務提携の使い分け

完全M&Aが最適なケースと判断基準

M&Aによる完全な経営統合（株式の過半数以上の取得・支配権の確保）は、以下のようなケースで最も有効です。

• 後継者不在・廃業リスクのある優良なシステム開発会社を承継したい場合（事業承継型M&A）
• 対象会社のエンジニアチームを自社グループに完全に組み込み、内製化・アクハイアリングを実現したい場合
• 対象会社の既存顧客基盤・売上を完全に取り込み、スケールメリットを追求したい場合
• 技術プラットフォーム・プロダクトを完全取得し、競合他社に渡ることを防ぎたい場合

一方、完全M&Aには多額の買収資金が必要であり、DDコスト・統合コスト・PMIリスクも高いというデメリットがあります。不要なリスク・コストを引き受けずに目的を達成できる選択肢がある場合は、アライアンスや資本業務提携を先に検討することが賢明です。

業務提携・アライアンスが有効なケース

完全なM&Aではなく、業務提携（アライアンス）が適しているケースには以下のようなものがあります。

• 技術協力・共同開発：特定の技術領域で強みを持つシステム開発会社と共同で新しいプロダクト・サービスを開発したいが、完全統合までは必要ない場合。
• 販売チャネルの相互活用：お互いの顧客基盤・販売チャネルを共有することで、追加投資なしに売上拡大を目指す場合。
• リソースシェアリング：繁閑差のある業務でお互いのエンジニアリソースを融通し合うことで、コスト効率を高める場合。
• PoC（概念実証）段階での協業：M&Aを最終目標としつつ、まずはアライアンスで相互の相性・文化の合致を確認するステップとして活用する場合。

業務提携は資本関係を持たないため、解消のハードルが低く・リスクが限定的という利点があります。ただし、拘束力が弱いため、相手先が競合他社との提携を選択した場合に優先順位が下がるリスクもあります。

資本業務提携・少数株主として連携するメリット

資本業務提携とは、業務提携に加えて株式の一部取得（少数株主としての出資）を組み合わせたスキームです。完全M&Aと業務提携の中間に位置するこの手法は、以下のような状況で有効です。

• 将来のM&Aを視野に入れながら、まず少数株主として関係を深め、相手企業の実態・文化・エンジニアの質を見極める「ステップM&A」として活用する場合
• 売り手の経営者がまだ会社に関与し続けたい・完全売却はしたくないが、成長資金や事業提携は必要という場合
• 対象企業の株式の20〜49%を取得し、持分法適用会社として取り込むことで財務上のメリットを得る場合

資本業務提携は、お互いの信頼関係を段階的に構築しながら連携を深めることができるという意味で、文化的な距離がある企業間のM&A準備段階として非常に有効です。特に、創業者が活躍中のスタートアップや、家族経営の中小システム開発会社に対するアプローチとして多く活用されています。

8. システム開発会社M&Aのメリット（売り手・買い手別）

売り手のメリット〜後継者問題の解決・事業継続・従業員雇用保護〜

①後継者問題の解決と事業継続

経営者の高齢化・後継者不在という問題を抱えていても、M&Aを通じて事業を継続させることができます。廃業を選択すれば、長年かけて構築した顧客基盤・エンジニアチーム・システムが消滅します。M&Aによる第三者承継は、事業・従業員・顧客を守りながら経営者がリタイアできる最善の選択肢のひとつです。

②まとまった売却益の獲得

M&Aによって、オーナー経営者は会社の株式価値に相当する対価を一括で受け取ることができます。長年の経営の成果を「株式価値」として現金化することで、引退後の生活資金・新しい事業への投資・相続対策に活用することができます。

③従業員・エンジニアの雇用維持

廃業や倒産とは異なり、M&Aでは基本的に従業員の雇用が維持されます。長年ともに働いたエンジニアたちの雇用を守ることができる点は、多くの経営者にとって重要な判断基準となっています。大手・中堅グループの傘下に入ることで、給与水準の改善・福利厚生の充実・より大きなプロジェクトへの参画機会という形でエンジニアに恩恵をもたらすことも可能です。

④事業規模の拡大・信用力の向上

大手・中堅グループの傘下に入ることで、グループの信用力を背景に大型案件の受注が可能になったり、グループ内のリソース・技術を活用して事業を拡大したりできるというメリットもあります。単独では取れなかった大手企業からの発注を、グループとして受けられるようになるケースもあります。

買い手のメリット〜アクハイアリング・技術獲得・顧客基盤の拡大〜

①アクハイアリング（人材獲得）

IT人材不足が深刻な現在、既存のエンジニアチームを丸ごと獲得できるM&Aは、採用コスト・時間を大幅に節約できる手法として高く評価されています。特に、AI・クラウドアーキテクト・セキュリティ専門家など希少なスキルを持つエンジニアを一括で取得できることは、通常の採用活動では達成困難な人材獲得を実現します。

②技術力・開発ノウハウの獲得

自社にないシステム開発技術・専門ドメイン知識・特定業界向けシステムのノウハウを持つシステム開発会社を取得することで、技術ポートフォリオの拡充が図れます。DX推進・AI活用・クラウドネイティブ開発といった分野での技術力を、自社育成よりも短期間・低コストで獲得できる点が大きなメリットです。

③既存顧客基盤と安定収益の取得

長期契約・継続取引の顧客を多数持つシステム開発会社の買収は、安定したキャッシュフローの確保につながります。特にSES企業の場合、月次の定期収益（エンジニアの稼働費用）が安定しているため、財務的な安定性という観点でも魅力的なM&A対象です。

④内製化・DX推進の加速

IT・DX投資を内製化で進めたい事業会社にとって、システム開発会社のM&Aは「内製化の最短ルート」です。外注コストの削減・システム開発スピードの向上・自社IT部門の競争力強化を同時に実現できます。

9. M&Aの基本フローと専門家の活用

システム開発会社M&Aの標準的な流れ

システム開発会社のM&Aは、以下のフローで進行します。大まかなスケジュール感としては、秘密保持契約の締結から最終契約・クロージングまで、早いケースで4〜6カ月、DDや交渉に時間を要する場合は12〜18カ月程度かかることもあります。

• STEP 1：M&Aの方針策定・準備（売り手：企業価値評価・情報整理、買い手：買収基準・予算の設定）
• STEP 2：秘密保持契約（NDA）の締結（お互いの情報を安全に開示するための前提条件）
• STEP 3：ノンネームシート・企業概要書（IM）の開示（売り手の事業概要・財務情報を匿名で開示し、買い手候補を絞り込む）
• STEP 4：トップ面談（経営者同士の相互理解・文化の相性確認。M&A成功の鍵となる重要ステップ）
• STEP 5：意向表明書・LOI（Letter of Intent）の提出（買い手の買収意向・希望価格・条件を書面で表明）
• STEP 6：基本合意書の締結（主要条件（スキーム・価格・独占交渉権期間）を合意する）
• STEP 7：デューデリジェンス（DD）（財務・法務・技術・労務・セキュリティのDD。システム開発会社では技術DDが特に重要）
• STEP 8：最終交渉・最終合意書（SPA等）の締結（DDの結果を踏まえて最終価格・条件を確定）
• STEP 9：クロージング（株式譲渡代金の決済・株式移転の実行）
• STEP 10：PMI（統合後管理）の開始（エンジニアリテンション・技術統合・顧客への通知等）

弁護士・公認会計士・M&Aアドバイザーの役割と選び方

M&Aアドバイザー（FA）・仲介会社の役割

M&Aアドバイザリー会社は、売り手と買い手のマッチング・交渉の進行管理・各専門家の調整といった全体のプロセス管理を担います。「仲介型」は売り手・買い手の双方から報酬を受け取り交渉を仲介しますが、「FA（財務アドバイザー）型」は一方の当事者に専属して利益を最大化するよう動きます。利益相反を避けるという観点からは、FA型を選ぶことが理想的です。

弁護士の役割

M&Aにおける弁護士の主な役割は、法務DDの実施・各種契約書（NDA・基本合意書・最終合意書）のドラフト・レビュー・クロージングに向けた法的手続きの確認です。システム開発会社のM&Aでは、著作権帰属の整理・SES契約の適法性確認・労働法務（偽装請負の調査）という特殊な法務課題が多いため、IT法務に精通した弁護士の関与が強く求められます。弁護士が主導する「弁護士主導M&A」の形態では、法務リスクを早期に特定・対処できるメリットがあります。

公認会計士・税理士の役割

財務DDの実施・企業価値評価（バリュエーション）・M&A後の税務ストラクチャーの最適化を担います。特に「売り手がどのスキームを選ぶと税負担が最小になるか」については、M&A開始前の段階から税理士に相談することで、有利な条件での売却を実現できることがあります。

技術顧問・テクニカルDDアドバイザーの役割

システム開発会社固有のテクニカルDDには、IT業界の実務を知る技術顧問の参加が不可欠です。ソースコードの品質評価・技術的負債の定量化・セキュリティ体制の評価・技術スタックの将来性分析など、財務・法務の専門家では代替できない専門的知見を提供します。

ポイント：弁護士主導M&Aでリスクを早期に特定・対処する
M&Aアドバイザーが主導する従来のプロセスでは、法務DDは後半ステップに位置づけられることが多く、法的リスクが遅れて発覚するケースがあります。弁護士をプロセスの最初から関与させ、NDA・情報開示の段階から法的リスク管理を行う「弁護士主導M&A」のアプローチは、システム開発会社のように法的論点が多い業種のM&Aにおいて特に有効です。

10. システム開発会社M&Aを成功に導くポイント

ここまで解説してきた留意点を踏まえ、システム開発会社のM&Aを成功に導くための5つのポイントをまとめます。

ポイント1：IT業界特有のDDを徹底実施する

財務・法務DDに加え、テクニカルDD（ソースコード品質・技術的負債）・IP-DD（著作権・ライセンス）・セキュリティDD・労務DD（SES偽装請負確認）を必ず実施することがシステム開発会社M&Aの大前提です。これらのDDで問題が発覚した場合、買収価格の調整交渉・表明保証条項の強化・価格調整条項（エスクロー）の設定といった形でリスクヘッジを図ります。

ポイント2：PMIをM&A交渉中から設計する

PMI（統合後管理）の計画はクロージング後に考えるのではなく、M&A交渉中から設計することが重要です。エンジニアのリテンション施策・技術スタック統合方針・開発文化の融合計画は、DD段階から収集した情報をもとにクロージング前に策定しておきます。「PMIの100日間計画」をクロージング前日までに完成させることを目標にしてください。

ポイント3：キーマンエンジニアのリテンションを最優先に動く

システム開発会社の価値は人材（エンジニア）に帰着します。買収後にキーマンエンジニアが離職すれば、買収対象の主要資産が失われるも同然です。クロージング直後の段階でキーマンへの個別面談・処遇提示・リテンションボーナス付与を最優先事項として実行することがM&A成功の要です。

ポイント4：IT法務の専門家を早期に関与させる

著作権帰属の整理・SES契約の適法性確認・オープンソースライセンスの問題・個人情報保護法対応など、システム開発会社M&Aには多くのIT法務論点が存在します。M&Aを検討した段階から、IT法務に精通した弁護士を関与させることで、問題の早期発見と対処が可能になります。

ポイント5：M&AかアライアンスかをゴールベースTで決める

M&Aは目的達成のための手段のひとつです。「何を達成したいのか」というゴールを明確にしたうえで、完全M&A・資本業務提携・業務提携（アライアンス）の中から最適な手法を選択してください。たとえば、技術力の取り込みだけが目的なら、多額のコストとリスクを伴うM&Aよりも、技術提携・共同開発アライアンスで十分な場合もあります。

11. まとめ

本記事では、システム開発会社M&Aにおける留意点を、売り手・買い手それぞれの視点から詳しく解説しました。最後に要点をまとめます。

• 市場背景：IT人材不足・2025年の崖・DX投資の加速・後継者問題を背景に、システム開発会社のM&Aは件数・金額ともに拡大傾向にある。
• 売り手の留意点：ソースコード・知的財産権の帰属整理、キーマンエンジニアのリテンション計画、情報漏えいリスクの管理が最重要。
• 買い手の留意点：技術的負債のテクニカルDD、SES偽装請負リスクの法務DD、IP・ライセンス・クラウドインフラ・セキュリティ体制の確認を怠らない。
• スキーム選択：SES企業・受託開発会社は株式譲渡が主流だが、事業の一部取得にはスキーム設計の工夫が必要。
• PMI：エンジニアの離職防止・開発文化の統合・技術スタック統合は、クロージング前から計画しクロージング直後100日間を最優先で取り組む。
• 専門家活用：IT法務弁護士・テクニカルDDアドバイザー・公認会計士・M&Aアドバイザーの連携チームで進めることが成功の条件。

システム開発会社のM&Aは、正しく準備し・適切な専門家を選び・PMIを丁寧に実行することで、売り手・買い手の双方に大きな価値をもたらします。一方で、IT業界固有の論点を見落とした安易なM&Aは、多額のコストと事業リスクを生む可能性があります。

弁護士・公認会計士・M&Aアドバイザーが連携するチーム体制で、システム開発会社M&Aの全プロセスをサポートしています。売却・買収・資本業務提携・アライアンス設計のいずれのご相談にも対応しておりますので、まずはお気軽にご相談ください。