「IT企業(SES企業)を買収したものの、ふたを開けたらエース級のエンジニアが次々に辞め、当てにしていた案件まで一緒に抜けていった」——IT・SES領域のM&Aで、買い手側から最もよく聞く後悔がこれです。
製造業や小売業の買収と違い、IT・SES企業の価値は工場や在庫ではなく、ほぼ「人(エンジニア)」と「その人が抱える案件・契約」に宿っています。だからこそ、買収後の統合(PMI)を誤ると、貸借対照表には残っているのに“中身”だけが流出する、という事態が起きます。
結論から言えば、IT企業(SES企業)のM&A・PMIの成否は、「エンジニアの定着」「案件・顧客の引き継ぎ」「契約・単価の統合」という3つの論点を、買う前から統合を前提に設計できるかで決まります。本記事では、公的なIT業界のM&A動向を押さえたうえで、私たちキュリオシティがSES・IT企業のBPR(業務改革)やシステム統合の現場で複数の統合案件を支援してきた経験から、“人が資産の業界”特有の勘所を、匿名の実例を交えて解説します。
結論:IT・SES企業のPMIは「人・案件・契約」の三点統合
IT・SES企業のPMIを、一般的な組織・制度の統合と同じ手順で進めると必ずつまずきます。この業界のPMIで最初に手当てすべきは、次の3点です。
- 人(エンジニア)の定着:買収後の不安・文化の違い・処遇の変化でエース級が流出する。人が抜ければ価値は消える
- 案件・顧客の引き継ぎ:売上は「誰がどの現場に入っているか」に紐づく。商流とキーマンを止めない
- 契約・単価の統合:準委任か請負か、単価テーブル、パートナー(BP)契約——契約の実態が見えないと稼働も請求も止まる
この3点は独立していません。エンジニアが辞めれば案件が抜け、案件が抜ければ契約と売上が消える、という連鎖で価値が毀損します。だからPMIの設計は「人 → 案件 → 契約」の順で優先度をつけ、しかもDay1(統合初日)を待たず、買収前の検討段階から定着策を織り込むのが鉄則です。統合全体の型はPMIコンサルティングの解説も併せてご覧ください。
そもそもなぜIT・SES企業のM&Aは増えているのか
論点に入る前に、なぜこの領域でM&Aが活発なのかを押さえます。動機を理解すると、「何を守るべきか」が明確になるからです。
2025年(暦年)の国内M&A件数は5,115件と前年比8.8%増で、初めて5,000件を突破しました(レコフデータ)。なかでもIT業界は、技術力と人材の獲得を目的とした案件が突出しています。背景にあるのが深刻なIT人材不足です。経済産業省の「IT人材需給に関する調査」(2019年公表。同省の代表的な試算として現在も広く参照されています)では、IT人材の不足は2030年に最大で約79万人に達すると見込まれています。
つまり、IT・SES企業を買う最大の目的は、多くの場合「即戦力のエンジニアチームを、採用より速く・確実に手に入れること」にあります。採用で一人ずつ集めるより、機能しているチームを丸ごと獲得するほうが効率的だという判断です。
この動機が示すのは、買収した瞬間に守るべき資産は“人”そのものだという単純な事実です。にもかかわらず、財務・法務のデューデリジェンス(DD)に比べて「買った後に人がどう動くか」の設計は手薄になりがちです。私たちの支援経験でも、M&Aは成約がゴールではなく、期待した価値が毀損するのはほぼ例外なく統合(PMI)局面です。とりわけIT・SES企業では、この“人リスク”が大きく出ます。
IT・SES企業のPMIが特に難しい3つの理由
同じPMIでも、IT・SES企業には他業種にない難しさがあります。
1. 資産が「人」に紐づき、貸借対照表に載らない
工場や店舗と違い、SES企業の価値はエンジニアの技術・経験・顧客との信頼関係に宿ります。これらは資産計上されず、しかも本人の意思ひとつで“持ち出せる”資産です。買収後の不安から一人が辞め、それを見た周囲が連鎖的に動く——という流出は、この業界のPMIで繰り返し起きます。
2. 売上が「商流」と「常駐先」に埋め込まれている
SESの売上は、エンジニアが客先に常駐して初めて発生します。しかも案件は、エンドユーザー→元請け→二次請け…という多重の商流の中にあり、単価も責任分界もその商流に依存します。買収側から見ると「誰が・どの現場に・どの商流で入っているか」を正確に把握しないと、売上の源泉そのものが見えません。
3. 契約が準委任中心で、実態が書面に表れにくい
SES契約の多くは準委任契約で、指揮命令は雇用元(SES企業)に残ります。この形態は柔軟な一方、単価改定や契約更新が口頭・慣行ベースで運用されているケースが多く、契約書を集めただけでは実態がつかめません。ここを軽視すると、統合後に「契約が名義変更されておらず請求できない」といった事故が起きます。
これら3つは、買収後にシステムをどう統合するかだけでなく、組織・文化の統合とも密接に絡みます。以下、論点ごとに打ち手を見ていきます。
買収前に見抜く|IT企業のM&A・PMIで確認するDDのチェック観点
IT企業のM&A・PMIは、Day1(統合初日)ではなく買収前のデューデリジェンス(DD)から始まっています。財務・法務DDと並行して、上記3論点それぞれに“人リスク・案件リスク・契約リスク”を先に見抜いておくと、統合後の事故を大きく減らせます。最低限、買収前に確認したいのは次の観点です。
- 人(定着):エンジニアの年齢・スキル・勤続と離職率の推移/評価・報酬制度と自社との差/“この人が抜けたら終わる”キーマンは誰か
- 案件・顧客:主要顧客の売上依存度/案件が特定個人に紐づいていないか/商流(元請け/何次請け)と契約更新月
- 契約・単価:準委任/請負/派遣の別と偽装請負の芽/単価テーブルと改定履歴/パートナー(BP)・フリーランス契約の名義と更新条件
この「人/案件・顧客/契約・単価」の3ブロックは、そのまま本記事末尾で配布する「PMI失敗要因チェックシート」の構成に対応しています。DD段階でここを潰しておくほど、後述の統合が楽になります。
【論点1】エンジニア定着|買収後に流出させないリテンション設計
最優先はエンジニアの定着です。ここが崩れると、後述の案件も契約も意味を失います。
なぜ買収後にエンジニアは辞めるのか
現場を見ていると、離職の引き金はおおむね次の4つに集約されます。
| 引き金 | 現場での現れ方 |
|---|---|
| 将来不安 | 「買収でどうなるのか説明がない」→ 転職サイトを見始める |
| 文化・評価の違い | 買い手の評価制度・稼働管理が急に降りてきて反発 |
| 処遇の変化 | 給与・単価還元・リモート可否など“働き方の前提”が変わる |
| キーマン依存 | 中心人物が去ると、慕っていたメンバーが後を追う |
定着のための打ち手
- Day1前のコミュニケーション設計:クロージング直後に、経営者から「なぜこの統合か」「あなたたちの何を評価して買ったのか」を直接伝える。沈黙が最大のリスク
- 処遇の“激変緩和”:評価・単価・働き方は一定期間(目安6〜12か月)現状維持とし、変える場合も理由と移行スケジュールをセットで示す
- キーマンの役割を先に設計する:技術リーダー・営業の要となる人物には、統合後の役割・権限・インセンティブを買収前から握っておく(いわゆるキーマン引き留めの設計。統合契約にキーマン条項やアーンアウトを絡めることもある)
- 成長機会の提示:買い手側の大型案件・新技術・キャリアパスなど、「買収されたことでむしろ広がるもの」を具体的に見せる
現場の一次情報(匿名):ある準委任中心のSES企業(社員数十名規模)の統合支援では、買収発表の“伝え方の順番”が定着を左右しました。当初は人事制度の説明から入る予定でしたが、順番を変えて経営者がまず「技術者としてのキャリアをどう伸ばすか」を語ったところ、発表直後に離職・転職活動をほのめかしていた中核メンバーの多くがそのまま残留。私たちが当初懸念していた“一人が辞めて周囲が連鎖する”流出は起きませんでした。複数の統合案件を支援してきた実感として、人が資産の業界では制度より先に“意味”を伝える——これが定着設計の起点です。
(※守秘のため企業名・実数値は伏せ、傾向のみ記載しています)
【論点2】案件・顧客の引き継ぎ|商流と稼働を止めない
エンジニアが残っても、案件と顧客が引き継げなければ売上は立ちません。
まず「案件の棚卸し」で商流を可視化する
買収後すぐにやるべきは、案件の棚卸しです。私たちが現場で使っているのは、案件を次の列で1枚に並べる可視化フォーマットです。
| エンジニア | 客先 | 商流 | 単価 | 契約更新月 | キーマン依存度 |
|---|---|---|---|---|---|
| Aさん | ○○社 | 二次請け | 標準 | 3月 | 高(引き継ぎ不可) |
| Bさん | △△社 | 元請け直 | 高 | 9月 | 中 |
この6列で並べるだけで、「更新月が近い高単価案件」「特定個人に依存した高リスク案件」が一目で浮かび上がります。ここが曖昧なままだと、契約更新のタイミングを逃したり、キーマンの離脱で商流ごと失ったりします。棚卸しの型は業務棚卸しの手順の考え方がそのまま応用できます。
稼働を止めない引き継ぎの打ち手
- 顧客への共同あいさつ:主要客先には、売り手・買い手が“一緒に”あいさつに回る。担当交代の不安を先回りで消す
- 商流上の元請け・パートナーへの通知:名義や請求フローが変わる場合、商流の上流・下流に早めに通知し、稼働と請求を途切れさせない
- キーマンの契約更新タイミングを把握:常駐案件は更新月が命綱。更新前後3か月はキーマンを動かさない
- 属人化した案件情報の引き出し:案件の勘所が特定個人の頭の中にある状態を放置しない。属人化の解消の観点で、引き継ぎ資料化を統合タスクに組み込む
現場の一次情報(匿名):あるSES企業の統合支援では、主要客先への“あいさつの順番”がそのまま案件維持を左右しました。買い手が単独で交代あいさつに行こうとしていたのを、売り手の営業担当と一緒に回る形へ変更。「担当は変わっても座組みは続きます」と二人で伝えたことで、更新月を控えていた複数の常駐案件がそのまま更新されました。逆に、あいさつが遅れた商流の上流では一時的に不信が生じ、火消しに追われた——案件は“契約書”ではなく“関係”で動く、と痛感した事例です。(※守秘のため企業名・実数値は伏せています)
【論点3】契約・単価の統合|準委任・単価テーブル・BP契約
3つ目の論点が、見落とされがちな契約・単価の統合です。
契約の棚卸しで“実態”を突き合わせる
準委任か請負か、契約主体は誰か、単価改定の履歴はどうか——SESでは契約の実態が慣行に埋もれがちです。買収側の契約フォーマットと突き合わせ、次を整理します。
- 契約形態:準委任/請負/派遣のどれか。指揮命令・責任分界が実態と合っているか(偽装請負の芽がないか)
- 単価テーブル:エンジニアのスキル・商流ごとの単価をどう統一するか。急な統一は反発を生むため移行期間を設ける
- パートナー(BP)契約:協業フリーランス・パートナー企業との契約の名義変更・更新条件。ここが漏れると稼働が止まる
単価・評価の統合は“段階的に”
買い手と売り手で単価水準・還元率・評価基準が異なるのは当然です。これを一気に揃えようとすると、エンジニアの手取りや納得感に直結して離職を誘発します。「契約・請求の名義は速やかに、単価・評価の中身は段階的に」が原則です。この順序は、制度統合全体の考え方をまとめた経営統合の進め方とも共通します。
現場の一次情報(匿名):契約の名義変更を後回しにして実務が止まった例もあります。エンジニアは客先で稼働しているのに、契約主体が旧会社のままで請求の起票ルートが宙に浮き、月末に請求書が出せず現場が数日空転しました。「人と案件は動いているのに、契約という“配管”だけが旧いまま」——これはSES統合で驚くほど多い詰まり方です。名義・請求フローの切替は、単価の議論より先に、最優先で片づけるべきだと考えています。(※守秘のため詳細は抽象化しています)
IT・SES企業のPMI|100日ロードマップ
3論点を、統合初期の100日にどう配置するかを整理します。詳細な作り方はPMIの進め方(100日プラン)を参照してください。
| 時期 | 人(定着) | 案件・顧客 | 契約・単価 |
|---|---|---|---|
| 〜Day1 | 統合の“意味”を経営者が直接説明/キーマンの役割合意 | 主要案件・商流の一覧化 | 契約形態・単価の棚卸し着手 |
| 1〜30日 | 個別面談で不安を吸い上げ/処遇は現状維持を明言 | 顧客・元請けへ共同あいさつ | 名義変更・請求フローの切替 |
| 31〜60日 | 評価・キャリアの移行方針を提示 | 更新月の管理・稼働率の維持 | 単価テーブルの統合方針を策定 |
| 61〜100日 | 定着状況をモニタリング/早期離職の芽を潰す | 属人案件の資料化・引き継ぎ | 単価・評価の段階移行を開始 |
よくある失敗と、チェックの勘所
最後に、IT・SES企業のPMIで繰り返される失敗を挙げます。PMIの失敗事例にも通じるパターンです。
- 人事制度から入ってしまう:制度説明が先行し、エンジニアが「管理される」と感じて離反。まず“意味”と“キャリア”を語る
- 単価を早期に統一しようとする:手取りに直結する変更を急ぎ、エース級が流出。中身の統合は段階的に
- 契約の名義変更を後回しにする:稼働しているのに請求できない事故。名義・請求フローは最優先で切り替える
なお、IT・SES企業は中小規模のケースが多く、大企業同士の統合とは勘所が異なります。中小ならではの進め方は中小企業のPMIで押さえる勘所も併せてご確認ください。買収が事業承継を兼ねる場合は、事業承継後の経営で最初にやることの視点も有効です。
PMI支援を外部に頼むべきか|自社で回す範囲と使いどころ
すべてを外部に頼む必要はありません。目安として、次のように切り分けると判断しやすくなります。
- 自社で回せる範囲:案件・契約の棚卸し、日常のコミュニケーション、稼働管理など「自社の事業として当然やること」
- 外部支援が効く範囲:離職リスクの見極めと定着設計、商流・契約の実態調査(買収前DD)、統合タスクの設計とPMO、属人化した案件情報の可視化——つまり“経験がないとツボを外す”領域
初めてのIT・SES企業の買収や、社内にPMI経験者がいない場合は、買収前のDD段階から外部の目を入れておくと、統合後の手戻りコストを大きく抑えられます。費用感の考え方はPMIコンサルの費用相場にまとめています。
支援先を選ぶ際は、SES特有の「商流・準委任契約・常駐稼働」に踏み込めるかを見てください。一般的なPMI支援は組織・制度・会計の統合が中心で、SESの売上を支える商流や案件の属人性まで扱えないことが少なくありません。私たちキュリオシティは、この業界固有領域に現場主義で踏み込み、上記の案件棚卸しフォーマットのような“可視化の型”と、AIを使った属人情報の吸い出しで統合を加速させます。まずは自社で「PMI失敗要因チェックシート」を使って抜け漏れを点検し、埋まらない論点だけを外部に相談する、という順番が現実的です。
まとめ|“人が資産”のPMIは、買う前から始まっている
IT・SES企業のM&A・PMIは、「エンジニアの定着」「案件・顧客の引き継ぎ」「契約・単価の統合」の三点統合です。共通するのは、価値が人に紐づくがゆえに、買収前・Day1前からの設計が勝負を分けるという点です。財務・法務のDDと同じ熱量で、「買った後に人がどう動くか」を先に描いておく——それがこの業界のPMIの核心です。
私たちキュリオシティは、SES・IT業界のBPR(業務改革)やシステム統合を複数社で支援し、“人が資産の業界”特有の定着・案件・契約の統合に伴走してきました。監修者の大槻伸夫(キュリオシティ株式会社 代表取締役CEO)自身、事業承継・買収を経営テーマとして取り組んでおり、本記事の3論点はいずれも現場で繰り返し直面してきたものです。現場主義 × AIで、属人化した案件情報の可視化から統合タスクの管理までを支援します。
まずは自社の統合リスクを点検したい方へ、「PMI失敗要因チェックシート」を無料でご用意しています。本記事で挙げた「人/案件・顧客/契約・単価」の3ブロックが、そのままチェック項目になっています。買収前・統合初期の抜け漏れを、ダウンロードしてセルフチェックしてみてください。
自社のケースに引き寄せて論点を整理したい場合は、お気軽にご相談ください。
