システム会社のM&Aの現状と成功ポイントや事例を解説

受託開発・システム開発会社のM&A｜売却相場と企業価値の評価ポイント

受託開発・システム開発会社のM&Aを、売却を検討する経営者向けに解説します。元請け比率、主要顧客への依存度、エンジニアの定着率、継続案件、著作権など、企業価値を左右するポイントを整理。年買法・EBITDA倍率による価格の考え方、買い手の種類、下請け構造の影響、契約上の注意点、売却前に必要な準備まで紹介します。

目次:

1. 受託開発・システム開発会社のM&Aの現状
2. 受託開発会社のM&Aで評価される6つのポイント
3. 受託開発会社を買収する企業の種類と目的
4. 受託開発会社の売却相場と価格の考え方
5. 二次請け・三次請け中心の受託開発会社でも売却できるか
6. 株式譲渡の前に確認したい契約・著作権・労務のリスク
7. 受託開発会社の売却前に準備しておきたいこと
8. 受託開発会社とSES・アプリ事業のM&Aの違い
9. まとめ

▶目次ページ：業種別M&A（様々な業界でのM&A）

受託開発・システム開発会社のM&A（合併・買収）では、売上や利益だけでなく、元請け比率、顧客との取引関係、エンジニアの定着率、継続案件の多さが売却価格を左右します。

特に従業員数十名規模の会社では、買い手が重視するのは「現在の利益が、経営者の交代後も続くか」という点です。二次請け・三次請け中心の会社でも売却は可能ですが、主要顧客への依存や特定の技術者への業務集中がある場合は、価格や譲渡条件に影響します。

この記事では、受託開発会社のM&Aの状況、企業価値の評価ポイント、買い手の種類、売却相場の考え方、契約上の注意点を解説します。自社がどのように評価されるのか、売却前に何を準備すべきかを判断するためにお役立てください。

システム開発会社のM&Aを考える際は、IT業界全体の動向と、受託開発会社ならではの事情を分けて見る必要があります。

IT業界には、受託開発、SES、自社パッケージ、SaaS、保守運用など、異なる収益構造の会社があります。

受託開発会社は、顧客から依頼を受けてシステムを設計・開発する会社です。案件ごとの売上が中心となるため、買い手は開発技術だけでなく、継続的に仕事を受注できる仕組みを確認します。

企業がデジタル技術を使って業務や事業を変革するDXの取り組みは、システム開発会社にとって事業機会となります。

独立行政法人情報処理推進機構（IPA）が2025年6月26日に公表した「DX動向2025」では、日本の調査対象企業のうち、DXを推進する人材が不足していると回答した企業の割合が8割を超えています。

出所：IPA「DX動向2025」（2025年6月26日公表）

https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html

また、IPAが2026年7月16日に公表した国内企業のDX・AI活用動向の調査結果では、AI導入が大企業を中心に広がる一方、企業価値の創出につながるDXの成果には課題が残ることが示されています。

出所：IPA「国内企業のDX動向・AI活用動向のポイントを公表」（2026年7月16日）

https://www.ipa.go.jp/pressrelease/2026/press20260716.html

こうした状況では、開発人材や業務知識を持つ企業を買収し、自社の開発体制を強化することが買い手の選択肢になります。

ただし、これらの調査は受託開発会社のM&A成約件数や売却価格を直接示すものではありません。IT人材不足を理由に、すべてのシステム会社が高く売れると判断することはできません。

生成AI、データ分析、クラウド、情報セキュリティなどの分野は、買い手が開発能力を検討する際の重要な対象です。

ただし、「AI開発に対応可能」「クラウド技術に強い」といった説明だけでは、企業価値の根拠として十分ではありません。

買い手は、実際にどのような案件を受注し、どの工程を担当し、どの程度の利益を確保できたかを確認します。

例えば、クラウド環境への移行案件について、設計から構築、運用まで継続して担当している会社は、開発後の保守収益も含めて説明できます。

一方、最新技術を扱っていても、担当者が一人しかおらず、その人が退職すると案件を継続できない場合は、評価が慎重になります。

技術の新しさよりも、組織として継続的に提供できることが重要です。

受託開発会社の企業価値を考えるうえでは、利益額に加えて、受注の安定性と開発体制の引継ぎやすさを確認します。

特に重要なのは、顧客への依存度、元請け比率、エンジニアの定着率、保有資格、継続案件、自社の技術資産です。

これらは一般的な評価の方向性です。どの項目が価格に強く影響するかは、買い手の買収目的によって変わります。

出所：矢野経済研究所の資料を編集部にて加工

受託開発会社では、長年取引している大口顧客が売上の大部分を占めることがあります。

安定した取引先があること自体は強みですが、その顧客との契約が終了すると売上が大きく減る場合、買い手は慎重になります。

売却を検討する際は、過去3期程度の顧客別売上を整理し、主要顧客の構成比と取引の継続状況を確認するとよいでしょう。

同じ顧客への売上が大きくても、複数の部門と取引している場合と、一人の担当者との関係だけで受注している場合では、リスクが異なります。

重要なのは売上構成比だけでなく、経営者が交代しても取引が継続する根拠を説明できることです。

元請けとは、システムを利用する顧客から直接仕事を受注する立場です。

元請けに近い会社は、顧客の課題を直接把握し、要件定義や基本設計などの上流工程に関わりやすくなります。

また、開発後の追加改修や保守運用についても、直接提案できる場合があります。

一方、二次請け・三次請け中心の会社では、間に複数の事業者が入るため、受注単価や利益率に制約が生じることがあります。

ただし、下請けであることだけを理由に、企業価値が低いとは限りません。

例えば、大手SIerから継続的に案件を受注し、特定技術に強い開発チームを持つ会社は、買い手にとって魅力があります。

反対に、元請け案件が多くても、見積りが甘く赤字案件を繰り返している会社は、高く評価されるとは限りません。

元請け比率と併せて、案件別の利益率、受注の継続性、価格交渉の余地を確認することが大切です。

受託開発会社では、エンジニアやプロジェクトマネージャーが重要な経営資源です。

ただし、買い手は単純な人数だけで企業価値を判断しません。

開発言語や技術領域、経験年数、担当工程、プロジェクト管理能力などを確認します。

特に、主要顧客との折衝を担う人材や、複数の開発案件を管理できる人材がいる会社は、事業の継続性を説明しやすくなります。

一方、社長自身が営業、設計、顧客対応、品質管理のすべてを担っている場合は、譲渡後の事業運営に不安が残ります。

売却前には、技術者別のスキル一覧、退職者数の推移、教育体制、案件ごとの責任者を整理しておくとよいでしょう。

情報処理技術者試験の合格者、クラウド関連の認定資格保有者、情報セキュリティに関する認証などは、会社の技術力や管理体制を説明する材料になります。

ただし、資格の数だけで売却価格が決まるわけではありません。

買い手は、資格を持つ人材が実際にどの案件を担当しているか、資格や認証が顧客からの受注条件になっているかなどを確認します。

特定の資格保有者が退職すると取引を継続できなくなる場合には、その点もリスクとして考慮されます。

受託開発では、新規開発案件の売上と、保守運用・継続改修による売上を分けて考えることが重要です。

新規開発案件は、納品が完了すると売上が途切れる場合があります。

一方、保守運用契約や定期的な改修契約がある会社は、翌期以降の売上を予測しやすくなります。

ただし、継続取引があるだけで、将来の売上が保証されるわけではありません。

契約期間、自動更新の有無、解約条件、過去の更新実績を確認し、どの程度の収益が継続すると見込めるかを説明する必要があります。

受託開発会社では、過去に開発したプログラムや設計書を、別の案件でも利用していることがあります。

再利用できる共通部品や開発ツールを保有していれば、開発効率や利益率の向上につながります。

ただし、顧客に著作権を譲渡した成果物を、許可なく別の案件に使えるとは限りません。

買い手は、どの技術が自社の資産で、どの技術が顧客に帰属するのかを確認します。

権利関係が明確で、継続的に活用できる技術資産があることは、企業価値を説明する材料になります。

受託開発会社の買い手は、同業のシステム開発会社だけではありません。

大手SIer、異業種の事業会社、投資ファンドなども候補になります。

ただし、買い手によって求める技術、人材、顧客基盤、利益水準は異なります。

同業企業は、開発人材の確保、技術領域の拡大、営業地域の拡張などを目的に買収を検討します。

例えば、業務システムの開発を中心とする会社が、クラウド開発に強い会社を迎えることで、対応できる案件を広げる場合があります。

同業の買い手は、開発工程や案件管理の仕組みを理解しているため、技術力や顧客との関係を具体的に評価しやすい傾向があります。

一方、事業内容が重なる場合には、顧客の競合関係や人員配置の調整が課題になることがあります。

大手SIerは、大規模なシステム開発や運用を手掛ける企業です。

買収の目的としては、開発体制の強化、専門技術の獲得、特定地域での事業拡大などが考えられます。

二次請け・三次請け中心の受託開発会社でも、大手SIerのグループに入ることで、より上流工程の案件に関わる機会が生まれる可能性があります。

ただし、買収後に必ず元請け案件が増えるわけではありません。

買い手がどのような案件を持ち、自社のエンジニアをどの工程で活用する計画なのかを確認する必要があります。

IT業界以外の企業が、システム開発会社を買収する場合もあります。

目的の一つは、これまで外部に委託していたシステム開発を自社グループ内で行う内製化です。

例えば、物流会社が物流管理システムの開発経験を持つ会社を迎える場合、業務知識と開発力の両方を活用できる可能性があります。

こうした買い手にとっては、最新技術だけでなく、特定業界の業務を理解していることが強みになります。

ただし、買収後に自社向け開発が増えることで、既存顧客向けの受託事業が縮小する可能性もあります。

売り手は、従業員の仕事の内容やキャリアがどう変わるのかまで確認することが大切です。

投資ファンドは、企業への投資を通じて事業価値の向上を目指す買い手です。

受託開発会社では、営業体制の強化、採用の改善、管理体制の整備、他社との事業統合などが検討されます。

経営者が一定期間残り、買収後の成長に関わる取引も考えられます。

一方、将来の株式売却や経営体制の変更を想定している場合があるため、売り手は投資方針と経営への関与の程度を確認する必要があります。

買い手の種類だけで優劣を決めず、自社の事業や従業員に合う相手を選ぶことが重要です。

関連：M&A業種別ニーズと動向2024年最新版｜成功事例から学ぶ戦略

受託開発会社の売却価格に、すべての企業へ当てはまる一定の相場はありません。

同じ売上や利益の会社でも、顧客構成、商流、エンジニアの定着率、契約上のリスクによって評価が変わります。

価格を考える際には、年買法と呼ばれる簡便な方法や、EBITDA倍率を使った方法などが参考になります。

ただし、いずれも計算結果がそのまま成約価格になるわけではありません。

年買法は、会社の純資産に一定年数分の利益を加えて株式価値の目安を求める、実務上の簡便な考え方です。

純資産とは、会社の資産から負債を差し引いた金額です。

計算の基本的な形は次のとおりです。

 株式価値の目安＝修正純資産＋評価対象利益×加算年数

修正純資産は、決算書上の資産・負債を必要に応じて実態に合わせて見直したものです。

評価対象利益には、営業利益などを基に一時的な損益や役員報酬の調整を検討した利益が使われる場合があります。

例えば、次の条件を仮定します。

 修正純資産：5,000万円

 評価対象利益：年間2,000万円

 利益の加算年数：3年

この場合、計算上の目安は次のとおりです。

 5,000万円＋2,000万円×3年＝1億1,000万円

これは計算方法を示すための仮定であり、実際の成約事例や受託開発業界の平均価格ではありません。

また、3年という年数が標準と決まっているわけでもありません。

顧客との契約が継続するか、開発人材が残るか、利益に再現性があるかによって、加算年数や評価対象利益の考え方は変わります。

EBITDAは、利息、税金、減価償却費などの影響を除いて、事業の収益力を比較するための指標です。

簡便には、営業利益に減価償却費を加えて計算することがあります。

EBITDA倍率を用いる方法では、正常化したEBITDAに倍率を掛けて事業価値の目安を求めます。

 事業価値の目安＝正常化EBITDA×評価倍率

ここでいう正常化とは、一時的な費用や収益などを調整し、継続的な事業の稼ぐ力を把握することです。

例えば、役員報酬を調整する場合でも、売却後に経営者の業務を引き継ぐ人材の費用が必要なら、その費用を考慮しなければなりません。

倍率は、比較対象となる企業や取引事例、成長性、リスクなどを踏まえて検討します。

受託開発会社と自社SaaS企業では収益構造が異なるため、同じ倍率をそのまま使うことは適切ではありません。

また、EBITDA倍率によって求めた事業価値は、株式譲渡価格と同じではありません。

株式価値を検討する際には、有利子負債、余剰現預金、その他の資産・負債などの調整が必要になります。

業界平均の倍率を一つ当てはめるより、自社と比較可能な事業の収益構造やリスクを確認することが重要です。

受託開発会社では、案件ごとの採算管理が企業価値に直結します。

例えば、前期の利益が大きくても、大型案件の検収が集中したことによる一時的な利益であれば、翌期も同じ利益が続くとは限りません。

反対に、一時的な開発費用や採用費用によって利益が減少している場合は、その内容を説明することで、買い手の理解を得られる可能性があります。

重要なのは、決算書の利益と実際の収益力の違いを説明できることです。

案件別の売上、外注費、人件費、開発工数、利益率を整理し、赤字案件が発生した原因と再発防止策を明らかにしておく必要があります。

特に、進行中の案件について追加費用が発生する見込みがある場合は、売却前に把握しておくことが重要です。

オーナー経営者が株式を譲渡する場合、売却価格がそのまま手元に残るわけではありません。

株式の取得費や譲渡費用などを考慮した譲渡益に対する税金のほか、M&A仲介会社などへの報酬が発生する場合があります。

また、役員退職金の支給、役員貸付金や役員借入金の整理、個人保証の解除なども、取引条件として確認する必要があります。

株式譲渡と事業譲渡では、課税関係や資金の受取人も異なります。

そのため、売却価格の目安を把握する段階から、どのような方法で譲渡するか、税引後にいくら残るかを試算しておくことが大切です。

二次請け・三次請け中心の会社でも、M&Aによる売却は可能です。

ただし、買い手は商流の深さそのものより、継続的な受注と利益を確保できるかを確認します。

下請け構造が企業価値に影響するのは、主に受注の安定性と価格交渉力に問題がある場合です。

例えば、特定の元請け企業から案件を紹介してもらうだけで、自社に営業機能がない会社は、取引先との関係が変わると売上が減少する可能性があります。

また、受注単価を自社で交渉できず、人件費や外注費の上昇を価格に反映できない場合、利益率が低下しやすくなります。

買い手は、主要取引先との契約期間、単価改定の実績、受注予定案件、取引先との関係を確認します。

一方、下請け中心でも、特定の技術や業務に強みを持つ会社は買収対象になります。

例えば、金融システムの特定領域に精通している会社や、製造業向けの基幹システム開発を長年担当している会社などです。

買い手が自社にない技術や開発チームを求めている場合、元請け比率が低くても買収の目的に合うことがあります。

重要なのは、単に「技術者が何人いるか」ではなく、「そのチームを迎えることで、買い手がどのような案件を受注できるようになるか」を説明することです。

また、元請け企業との関係を維持しながら、開発工程の一部をより上流へ広げられる可能性があるかも検討材料になります。

売却前に無理に商流を変更する必要はありませんが、案件ごとの利益率と自社の技術的な役割を明確にしておくことが重要です。

受託開発会社のM&Aでは、買い手がデューデリジェンスと呼ばれる買収前調査を行います。

財務状況だけでなく、顧客との契約、ソースコードの権利、エンジニアの働き方、情報管理なども確認対象です。

株式譲渡では、原則として対象会社が契約主体として存続しますが、株主が変わることによって契約上の問題が生じる場合があります。

システム開発では、請負契約と準委任契約がよく利用されます。

請負契約は、原則として仕事の完成を目的とする契約です。

準委任契約は、一定の業務を行うことを目的とする契約で、必ずしも成果物の完成を約束するものではありません。

ただし、契約書に「請負」「準委任」と記載されていれば、必ず適法な業務運営になるわけではありません。

例えば、顧客先に常駐するエンジニアが、実際には顧客から直接業務上の指揮命令を受けている場合、労働者派遣に該当する可能性があります。

厚生労働省は、労働者派遣と請負の区分について、契約の形式ではなく実態に即して判断することを示しています。

出所：厚生労働省「労働者派遣・請負を適正に行うためのガイド」

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000077386_00020.html

買い手は、契約書と現場の実態が一致しているかを確認します。

特に、顧客先で誰が作業指示を出しているか、勤務時間を誰が管理しているか、業務の進め方を誰が決めているかは重要です。

受託開発会社でも、常駐開発や準委任契約がある場合には、売却前に確認しておく必要があります。

受託開発会社では、ソースコード、設計書、仕様書などの著作権が重要な論点になります。

顧客との契約で著作権を譲渡している場合、対象会社が自由に利用できるとは限りません。

また、自社で開発した共通部品と、顧客専用に開発した成果物が混在している場合もあります。

売却前には、主要な開発契約を確認し、次の点を整理します。

・成果物の著作権が自社と顧客のどちらに帰属するか

・自社の共通部品を他の案件で再利用できるか

・外注先が開発した部分の権利処理が済んでいるか

・第三者のソフトウェアを利用する条件に問題がないか

特に、オープンソースソフトウェアは、利用するライセンスによって守るべき条件が異なります。

すべてのオープンソースが商用利用に不向きというわけではありませんが、利用条件や再配布時の義務を把握していない場合は、買い手の調査で問題になる可能性があります。

ソースコードの管理台帳や利用ライセンスの一覧を整備しておくと、確認を進めやすくなります。

株式譲渡では、対象会社の法人格は原則として変わらず、顧客との契約も通常は対象会社に残ります。

しかし、契約書にチェンジ・オブ・コントロール条項がある場合は注意が必要です。

これは、会社の支配権や株主構成が変わるときに、取引先への通知や承諾などを求める条項です。

例えば、主要顧客との契約に株主変更時の事前承諾が必要と定められている場合、その対応がM&Aの進行に影響することがあります。

特に、売上の多くを占める顧客との契約では、承諾が得られない場合の影響を慎重に検討する必要があります。

ただし、すべての契約に同じ条項があるわけではありません。

主要顧客との契約書を確認し、通知・承諾の要否、期限、違反した場合の取扱いを整理することが重要です。

顧客への説明は、秘密保持と取引継続の両方を考慮し、買い手と協議して時期を決めます。

受託開発会社では、案件の一部を協力会社やフリーランスへ外注することがあります。

そのため、買い手は外注契約の内容、支払条件、再委託の可否、情報管理などを確認します。

2026年1月1日には、従来の下請法が改正され、中小受託取引適正化法（取適法）が施行されました。

公正取引委員会によると、同日以降に発注する適用対象取引には、取適法の規定が適用されます。

出所：公正取引委員会「取適法施行に当たり事業者の皆様に御留意いただきたい事項」（2026年1月施行）

https://www.jftc.go.jp/toriteki/toriteki_ryuijiko/

受託開発会社が外注先へ業務を発注する場合は、取引内容や当事者の規模などに応じて、法の適用対象となるか確認する必要があります。

また、従業員の未払い残業代、労働時間の管理、36協定、有給休暇の管理なども買収前調査の対象です。

労務上の問題が見つかると、将来の支払負担や人材の定着に影響するため、価格の減額や譲渡条件の変更につながることがあります。

受託開発会社のM&Aを円滑に進めるには、買い手が確認したい情報を早い段階で整理しておくことが重要です。

決算書だけでなく、案件別の採算、顧客との契約、技術者の配置、開発資産などを説明できる状態にしておきます。

まず、過去数期の決算書に加え、案件別の売上と利益を確認します。

売上が大きい案件でも、追加開発や手戻りが多く、利益がほとんど残っていない場合があります。

一方、小規模な案件でも、保守運用や追加改修が続き、安定した利益を生んでいる場合があります。

案件別の利益率を把握することで、買い手に自社の収益構造を説明しやすくなります。

進行中の案件については、契約金額、進捗、残りの開発工数、追加費用の見込みなどを確認します。

従業員数十名規模の受託開発会社では、社長が営業や顧客対応の中心になっていることがあります。

しかし、社長が退任すると主要顧客との関係が途切れる場合、買い手は引継ぎに不安を感じます。

そのため、主要顧客の担当者を複数にする、案件管理を現場責任者へ移す、見積りや受注の判断基準を文書化するなどの準備が有効です。

社長が売却後も一定期間残る場合でも、いつまでに何を引き継ぐかを明確にすることが大切です。

受託開発会社の企業価値は、エンジニアの継続勤務に大きく左右されます。

M&Aの成約後、給与制度、評価制度、リモートワーク、使用する開発ツールなどを急に変更すると、従業員の不安が高まる場合があります。

そのため、買い手との交渉では、売却価格だけでなく、従業員の処遇や開発体制についても確認することが重要です。

特に、主要顧客を担当するプロジェクトマネージャーや技術責任者には、買収後の役割やキャリアを丁寧に説明する必要があります。

PMIとは、M&A成立後に経営や業務を統合していく取り組みです。

受託開発会社では、成約後の統合方法によって、開発品質や従業員の定着率が変わることがあります。

例えば、買い手の管理制度へ急に切り替えると、案件管理や顧客対応に混乱が生じる可能性があります。

そのため、統合する業務と、当面は従来の方法を維持する業務を分けて考えることが大切です。

営業、採用、教育、情報管理、会計処理などについて、買い手と売り手が協力して優先順位を決めます。

買収後の成長を実現するには、買い手だけで計画を作るのではなく、売り手の経営者や現場責任者も参加することが重要です。

IT関連企業のM&Aでは、事業の種類によって評価の中心が異なります。

受託開発会社では、顧客からの受注を継続できるか、開発案件の利益を管理できるか、技術者を引き継げるかが重要です。

SES企業では、エンジニアの稼働率や契約単価、契約と実際の働き方の整合性が重要になります。

自社アプリやSaaSなどの事業では、利用者数、継続率、解約率、収益化の仕組みなどが評価の中心になる場合があります。

IT業界全体のM&A動向と、個別の事業モデルにおける評価方法は分けて考える必要があります。

複数の事業を営む会社では、売上と利益を事業別に分けて整理すると、買い手が企業価値を判断しやすくなります。

例えば、受託開発とSESを兼業している会社では、案件請負による利益と技術者の稼働による利益を区別します。

また、自社パッケージを保有している場合は、受託開発事業と製品販売・保守事業を分けて説明することが重要です。

受託開発・システム開発会社のM&Aでは、売上や利益だけでなく、元請け比率、顧客への依存度、エンジニアの定着率、継続案件、技術資産の権利関係が企業価値を左右します。二次請け・三次請け中心でも売却は可能ですが、受注の安定性や技術的な強みを説明できることが重要です。売却を検討する際は、年買法やEBITDA倍率による価格の目安だけで判断せず、案件別の採算、主要顧客との契約、労務管理、売却後の従業員の処遇を整理し、自社の強みを評価できる買い手を検討しましょう。