IT M&Aの売却・事業承継ガイド｜6事例・業界動向・評価倍率

公表された事実と当センターの分析を区別して記載しています。数値モデルの金額・倍率・条件は理解のための仮定です。実際の成約条件やIT業界全体の一律相場を示すものではなく、個別の取引では契約、会計・税務、労務等を確認します。

IT M&Aを考える出発点は、退任後にも顧客との約束を果たせるか

株式を手放す理由と、経営を離れたい理由を分ける

IT会社のオーナーが売却を考えるとき、最初に整理したいのは、所有者を変えたいのか、毎日の判断から離れたいのかという違いです。資金調達や販路の拡大が目的なら経営を続ける組み合わせもあります。一方、夜間の障害対応や大口顧客との調整まで社長が抱えている場合、株式を売るだけでは負担が終わらない可能性があります。まず、離れたい仕事と関わり続けたい仕事を分けます。

その整理には、役職名よりも最近実際に行った判断が役立ちます。値引きの承認、要件追加への回答、納期の変更、開発者の配置、本番環境の例外的な操作などを振り返ってください。営業と技術の両方に精通した創業者ほど、短い会話で問題を解決している場合があります。その判断が記録されていなければ、後任は顧客との合意や過去の設計意図を探すところから始めることになります。

当センターは、売却検討の初期段階では「契約上の約束を、人と技術が次の経営者の下で履行できるか」を軸に考えることが有用だと考えます。積み重ねた判断を組織が使える状態にし、顧客への約束と退任の希望を両立させるためです。希望する売却金額に加え、退任後の連絡窓口、稼働できる期間、技術判断に関わる範囲まで整理すると、相手に求める条件が具体的になります。

経営を続ける選択には、次の技術投資を引き受ける意思が必要

独立経営の継続は、既存の顧客関係や開発方針を自分で守れる選択肢です。ただし、現在の利益が続く前提だけでは判断できません。対応する基盤の更新、監視体制の維持、採用と教育、主要担当者が休める配置など、今後も資金と判断を求められる仕事があります。オーナー自身が次の投資判断に取り組みたいかを、業績の良し悪しとは別に確かめてください。

会社売却と継続経営を比較するときは、「売らなければ現状のまま」という想定を置かないことが大切です。継続する場合にも、外部の経営人材を迎える、営業責任者へ価格決定を任せる、技術責任者に更新予算を持たせるといった選択があります。その体制を自社で維持できるなら、所有権を変えずに負担を減らせるかもしれません。ただし、採用しても意思決定を任せなければ負担は残ります。

継続案を考える際は、守りたい競争力と、自社だけで抱える必要のない機能を分けます。特定業務への理解や顧客との設計対話は残しつつ、採用実務や経理を外部へ委ねる方法もあります。ただし、開発の中核まで外部に任せる場合は、発注を管理し品質を判断する能力が自社に必要です。資金が不足しているのか、判断できる人が不足しているのか、それともオーナーの時間が不足しているのかによって、求める解決策は変わります。

親族・従業員への承継は、技術力と経営権限を別々に考える

優秀なエンジニアが社内にいることと、その人が会社を引き継ぎたいことは同じではありません。資金繰りや営業、採用まで求めると、専門性を深めたい本人の希望とずれることがあります。親族が経営を担う場合も、開発や運用を理解する責任者との役割分担が必要です。後継者候補を決める前に、所有、経営、技術のどの役割を本人が望み、どの役割には補佐が必要なのかを丁寧に確認することが重要です。

社内承継の準備としては、後継者が自分の名義で判断を完結できる場面を増やす方法が考えられます。例えば、一定の範囲の追加開発を受けるか断るか、遅延しそうな案件へ誰を配置するかを任せ、その理由と結果を振り返ります。社長が顧客と別の約束をすれば、権限の移管が曖昧になります。後継者が迷ったときの相談経路は残しながら、最終的に誰の判断に従うかを顧客と社内の双方に伝えられる状態を目指します。

外部への承継を候補に残すことは、社内の後継者を否定することではありません。後継者が経営を担いながら、外部の資本や専門機能を利用する組み合わせも検討できます。ただし、外部株主が加われば、予算や役員人事の決定方法が変わる可能性があります。「今までどおり任せる」という説明だけで進めず、後継者の裁量、報告の負担、技術方針を変えるときの協議方法を具体化することが、本人の意欲と事業の継続を支えます。

IT M&Aの買い手は、補ってほしい機能から考える

第三者への承継を選ぶ場合、相手の売上規模や知名度だけで比較すると、自社の課題との接点が見えにくくなります。直販営業が不足している受託会社と、導入支援が追いつかないSaaS会社では、必要な支援が異なります。候補先が何を持っているかに加え、その機能を自社に割けるか、担当者や予算は誰が決めるかまで考えてください。顧客基盤が大きくても、自社製品を販売する具体策がなければ期待が先行します。

技術的な相性は、使う言語だけでは決まりません。変更を小さく頻繁に出す会社と、顧客ごとの検収を重視する会社では、品質確認や責任の取り方が違う場合があります。自社が顧客に約束した手順を新体制でも守れるかが論点です。共通化する開発環境や承認手続があるなら、現場の負担と顧客対応への影響を見積もり、どこから合わせるかを話し合う必要があります。

当センターの見解では、買い手選びに有効なのは「この会社に入れば成長できる」という大きな説明を、具体的な仕事へ分けることです。誰が提案書を作り、誰が設計を承認し、誰が障害時に判断するのかを並べると、補完できる部分と調整が必要な部分が見えます。相手が新規受注を増やせても、既存案件を遂行する担当者を営業支援へ回すなら、短期的には納期に影響し得ます。支援の内容と現場の余力を合わせて考えます。

段階的な退任には、期間に加えて完了条件を置く

売却後に一定期間残る方法は、主要顧客への紹介や技術的な引継ぎに使えます。ただし、「落ち着くまで残る」という条件では、退任できる状態が分かりません。顧客の更新交渉を後任が主導できた、本番障害を通常の指揮系統で処理できた、設計変更を責任者が説明できたなど、役割ごとの到達点を置く方法があります。引継ぎの完了を評価する人と確認方法も決めておきます。

一部の株式を手元に残して売却する場合も、日常の仕事への関与が自動的に決まるわけではありません。株主としての意見と、現場への直接の指示は分けて考えます。創業者の一言で開発の優先順位が変わる状態が続くと、新しい経営者や責任者が判断しにくくなります。残る持分の意味、経営上の役割、現場との接点を整理し、社員が複数の指示のどちらに従うか迷わない関係をつくることが大切です。

完全退任を目指す場合、知識の文書化を無期限の作業にしない工夫も必要です。頻度は低くても止まると影響が大きい仕事を優先し、後任が手順を実行して、足りない判断材料を補います。創業者が説明しただけで終わらず、後任が顧客へ説明できるかまで確かめると実務に近づきます。一方、退任後も専門家として関わりたいなら、相談対象と応答の範囲を絞り、経営責任との境界を明確にしておきます。

IT M&Aでは、事業モデルごとに引き継ぐ約束と収益の源泉が違う

受託開発・SIは、受注残と残る作業を一緒に説明する

受託開発やSIでは、受注残の金額だけを示しても、将来の利益は読み取れません。要件が固まっている案件と、顧客の意思決定待ちで作業が増える可能性のある案件では、同じ残額でも必要な対応が異なります。何を完成とするか、途中の変更を誰が承認するか、いつ検収するかを案件ごとに整理すると、買い手は引継ぎ後に負う仕事を把握しやすくなります。技術者の予定も含め、契約と作業をつなげて説明します。

受託会社の売却で強みを伝えるなら、過去に作ったシステムの数に加え、難しい条件を整理して合意へ導く力を示したいところです。見積時の前提、変更依頼の扱い、品質確認の責任分担が組織に残っていれば、担当者が替わっても判断をたどれます。反対に、社長が無償対応を約束して案件を収めていた場合、その関係調整も引継ぎ対象です。契約書の本文だけで表れない運用は、根拠を確かめて説明できるようにします。

顧客の業務を理解していることは強みですが、特定の人だけが詳しい場合は承継時の制約になります。業務上の例外、月末処理の順序、停止できない時間帯などを、画面仕様と別に整理する方法が役立ちます。買い手が共通部品や開発基盤を持っていても、業務上の事情まで代替できるとは限りません。新しい技術で作り直す案と、顧客が安心して使い続けられる案の違いを説明できることが、自社の価値を伝えます。

SESでは、所属人数から契約継続を支える技能へ視点を移す

SESでは技術者数や稼働率が経営の目安になりますが、それだけで引継ぎ後の収益は説明できません。顧客が必要とする技能、担当者が担う役割、契約の更新単位、配置が変わるときの手順を確認する必要があります。SESは実務上の呼称であり、名称だけで契約や就業の条件を決めつけることは避けます。取引の実態に即して、社員、協力会社の要員、顧客との関係を分けて把握することが出発点です。

継続受注の理由が「特定の担当者が詳しいから」なのか、「会社として代替要員や教育を用意できるから」なのかによって、承継の課題は変わります。前者では本人の意思と業務負荷を確かめ、後者では育成や引継ぎに必要な時間を説明します。社員を顧客ごとの売上の付属物として扱うと、本人が望む働き方や成長機会が見えなくなります。配置に加え、今後どの仕事に挑戦できるかも重要です。

承継によって取引先や案件の選択肢が増えても、それが社員全員に望ましいとは限りません。勤務地、在宅勤務、担当分野、評価の方法が変わる可能性があるためです。買い手が期待する配置転換と、社員が続けたい専門性の間にずれがあれば、統合の効果を急いで見込まない方が適切です。オーナーは人数を維持できると約束するより、これまでの育成方針と希望の把握方法を説明し、新体制での対話の土台を残すことができます。

IT M&AでSaaSを見るときは、契約額と利用の定着を結び付ける

SaaSは継続課金が特徴ですが、契約の有無と、顧客が使い続けたいかは別です。導入作業が終わっていない顧客、特定の担当者だけが利用している顧客、日常業務へ組み込まれた顧客では、更新までに必要な支援が異なります。オーナーは契約金額の推移に加え、利用が定着するまでの手順と、どこで支援が止まりやすいかを説明できるようにします。解約理由も、料金、機能、導入負担などに分けて考えると具体的です。

サービスを動かす費用は、サーバー料金だけではありません。問い合わせ対応、外部サービスの利用料、セキュリティ更新、請求や回収、障害時の連絡にも人と時間が必要です。顧客ごとの個別開発が増えている場合、共通製品として更新できる部分と、特定顧客のために維持する部分を分けます。販売件数が増えるほど運用が複雑になる構造なのか、標準的な支援で利用を広げられる構造なのかによって、買い手が必要とする体制は変わります。

創業者が製品の方向を決めている場合は、機能一覧の引継ぎだけでは足りません。どの顧客の課題を優先するか、標準機能に含める範囲はどこか、個別要望を断るときに何を説明するかという判断が残ります。買い手の販売網で顧客層が変われば、求められる機能やサポートも変わるでしょう。現在の製品が対応できる顧客像と、追加投資が必要な顧客像を区別すると、販売拡大の期待と開発負担を同じ話として検討できます。

ライセンス販売・運用保守を混ぜずに事業の構造を示す

自社製品、他社ライセンスの再販売、導入支援、運用保守を組み合わせる会社では、売上が増えていても収益の仕組みは一つではありません。他社サービスの料金改定による販売額の増加と、自社の付加価値が評価された単価上昇は分けて考えます。契約更新の条件や仕入先との関係も異なるため、全体を単純に「継続収益」とまとめず、何を提供して対価を受け取り、どの費用が伴うかを見える形にします。

運用保守では、月額契約が長く続いていることに加え、どの時間帯に何を約束しているかが重要です。監視だけを担うのか、復旧作業まで行うのか、顧客の判断を待つ場面があるのかで必要な体制が変わります。創業者が個人の携帯電話で休日も相談を受けているなら、その対応を標準契約のサービスと混同させない整理が必要です。正式な窓口へ移すために、顧客への説明と準備を考えます。

売却交渉で複合型の事業を伝える際には、部門ごとの売上を並べるだけでなく、顧客がどの順番でサービスを利用するかを示すと関係が分かります。ライセンス販売が導入案件につながり、その後の運用支援が次の刷新の相談につながることもあります。ただし、その流れが担当者の個人的な営業に依存しているなら、同じ循環を新体制でも維持する方法が必要です。契約間のつながりと、それを動かす役割の両方を説明します。

一部事業の承継は、共有している人と技術から考える

特定製品や開発部門だけを譲る案は、オーナーが別の事業へ集中したい場合に候補になります。ただし、社内で売上を分けられることと、独立して提供を続けられることは別です。共通の認証基盤、顧客データ、リポジトリ、開発環境、問い合わせ窓口などを複数事業が使っている場合、分離後の利用方法を考える必要があります。営業や請求を含めた周辺機能まで見ると、必要な範囲が分かります。

人の切り分けにも同じ問題があります。新規開発を担う技術者が既存顧客の重大障害にも対応しているなら、その人を一方の事業へ移すだけでは、残る会社のサービスが不安定になる可能性があります。実際に呼び出される仕事から確認してください。一定期間だけ相互に支援する案を考える場合も、応答できる時間や優先順位が必要です。両社から同時に緊急依頼を受ける場面を想定すると条件を具体化できます。

当センターは、一部事業の承継が規模の小ささだけで簡単になるとは考えません。独立性を高める準備が、全社の承継より重くなる場合もあるためです。一方、責任範囲が明確な製品を、その顧客や技術を理解する相手へ引き継げれば、開発の継続に適した組み合わせになる可能性があります。譲渡対象を先に固定せず、残す事業と譲る事業の双方が顧客への約束を守れる境界を探るのが適切です。

IT M&Aの業界動向は、自社の受注と履行負担へ読み替える

情報サービス業の売上増を、自社の利益増と混同しない

総務省統計局「サービス産業動態統計調査結果」の2026年6月速報では、情報サービス業の月間売上高は前年同月比7.7%増でした。公表日は2026年8月24日で、同年9月14日時点の最新速報です。これは税込みの名目売上を示す統計であり、利益や受注見込みを表すものではありません。受託開発、SES、SaaSそれぞれの成長率を示す区分でもなく、自社と比べる際は対象を揃えます。^[1][2]

買い手への説明で業界の伸びを使うなら、自社の売上変化を先に分解します。稼働した人数や時間が増えたのか、同じ仕事の単価を改定したのか、外部ライセンスの販売が増えたのか、検収時期が動いたのかを確認してください。人件費や外注費の増加を伴う売上増と、作業の標準化による収益改善では意味が違います。市場の成長は対話の背景にはなりますが、自社が同じ速度で伸びる根拠にはなりません。

同調査は2025年1月に旧調査を統合して始まっており、長期比較には公式の調整方法への注意が必要です。^[2] オーナーが社内資料を作る際も、決算期の売上、月次の検収額、入金額を同じグラフに混ぜると誤解が生じます。受注が好調でも入金までの期間が延びれば、運転資金の必要額は変わります。外部統計は需要環境の確認に用い、買い手に説明する見通しは、自社の案件進行と契約条件から組み立てることが適切です。

IT M&Aと生成AIの普及を結ぶのは、顧客が予算を付ける仕事

IPAが2026年7月30日に公表した「DX動向2026」では、生成AIを導入しているとの回答は2025年度調査で44.0%でした。調査は2026年に実施され、報告書では2025年度調査と呼ばれています。日本企業1,799社の有効回答に基づく結果であり、IT事業者の売上増加率ではありません。^[3] 事業計画へ結び付けるには、自社の対価がどの業務から生まれるかを明確にします。

顧客がAIを試したい段階と、日常業務に組み込みたい段階では、求められる仕事が異なります。前者では小規模な検証や選択肢の整理、後者では既存システムとの接続、データの整備、利用者の教育、運用後の改善などが論点になります。実証の成果が良くても本番化の予算がなければ、継続受注は決まっていません。商談件数を示すときも、予算の所在と意思決定の段階を添えることで、期待と確定した仕事を分けられます。

自社開発でAIを使う場合、コード作成の時間が短くなることと、案件全体の採算が改善することを分けて確認します。生成結果の確認、テスト、顧客の利用条件への対応、外部サービスの費用が増えることもあり得ます。定額で成果物を納める仕事と、作業時間を基準に対価を受け取る仕事では、時間短縮の収益への表れ方も異なります。ツールを導入した事実より、品質と契約条件を守ったうえで何が変わったかを説明する方が具体的です。

クラウド普及後の需要は、新規導入以外にも目を向ける

総務省が2026年5月29日に公表した「令和7年通信利用動向調査」の概要では、クラウドを一部でも利用する企業の割合は83.5%でした。調査時点は2025年8月末、企業調査の対象は公務を除く常用雇用者100人以上の企業で、公表概要は無回答を除いて算出しています。^[4] この利用率は支出金額やSaaS市場の成長率ではなく、小規模企業を含む全企業の状況でもありません。

利用が広がる市場では、未導入企業への初回提案に加え、既に使っている環境をどう改善するかが営業の論点になります。複数サービス間のデータ連携、権限の整理、使われていない契約の見直し、問い合わせ窓口の統合など、顧客の課題は導入後にも残ります。ただし、課題が存在しても外注されるとは限りません。顧客が自社で行う部分と、費用を払って任せたい部分を分け、提案が実際の契約につながる条件を確認します。

IT M&Aでクラウド関連の強みを示す際は、取扱製品の数だけでなく、顧客の運用が続く理由を説明します。特定サービスに詳しい技術者がいるのか、移行時の停止を抑える手順があるのか、利用部門と情報システム部門の合意を支援できるのかによって、買い手が期待する役割は変わります。既存サービスの利用率が高いから自社契約も更新される、という説明にはせず、解約や切替えを含む顧客の選択肢を理解した提案力を考えます。

人材不足の数字から、必要な職務と育成期間へ進む

「DX動向2026」では、DXを推進する人材の量が不足しているとの回答は85.5%でした。これはDXに取り組むと回答した企業について、「やや不足」と「大幅に不足」を合わせた割合です。^[3] IT企業全体の採用難度やエンジニアの不足人数を示す数字ではありません。売却を考えるオーナーにとっては、自社が不足している職務を具体化し、それを採用、育成、外部連携のどれで補うかを考える材料として扱います。

必要なのが実装を担う人なのか、顧客の業務を整理する人なのか、設計や品質を判断する人なのかで、採用後に成果が出るまでの道筋は異なります。経験者を迎えても、顧客固有の事情や既存システムを理解する時間は必要です。採用人数だけを成長計画へ置かず、教育を担当する人の稼働も考慮してください。教育役が大型案件の責任者を兼ねているなら、新しい人が加わった直後は、既存案件に使える時間が減る可能性もあります。

IT M&Aによる人材面の補完を考えるなら、買い手の採用力と、自社で活躍できる環境をつなげて確認します。採用広報が強くても、仕事の進め方や評価の基準が伝わらなければ定着は保証されません。反対に、現在の社員が買い手の研修や専門チームへアクセスできれば、担える仕事の幅が広がる可能性があります。人数の足し算だけで説明せず、どの職務を誰が担い、育成中の負担をどの部門が引き受けるかまで考えることが有用です。

IT M&Aの技術更新は、保守継続と新しい開発を両立させる

IPAの「2025年度ソフトウェア・モダナイゼーション委員会報告書」は、2026年3月24日に公表され、ソフトウェアの価値を継続的に高める方向を論じています。^[5] これは市場規模の実績統計や、すべての会社が同時に開発方式を変える期限を示すものではありません。自社の判断では、古い技術という名称だけで廃止を決めず、顧客が必要とする機能、維持できる体制、移行に要する作業を合わせて考える必要があります。

刷新の仕事を受ける場合、既存システムの保守と新しい環境の開発が並行する期間に注意します。新しい画面が完成しても、データ移行や周辺システムとの連携が終わるまでは、旧環境を止められないことがあります。売却の説明では、刷新案件を成長機会として示すだけでなく、並行運用を担う人と終了条件を整理します。買い手が新技術を持っていることと、既存顧客が安心して移行できることの間には、具体的な実行計画が必要です。

IPAの「情報セキュリティ10大脅威2026」では、組織向けの2位にサプライチェーンや委託先を狙った攻撃が挙げられています。2025年の事案等を基に専門家らが選定した順位で、個社の被害確率ではありません。^[6] 当センターは、顧客環境への接続権限や障害時の連絡体制を、売却直前だけ整える書類として扱わず、サービス提供を続けるための機能として考えます。その維持に必要な時間と費用も次の経営者へ伝えます。

IT M&Aの売却時期は、受注・更新・開発投資の節目で考える

大型受注の直後と検収の後では、買い手に説明する材料が変わる

大型案件の受注直後は将来の仕事を示しやすい一方、必要な作業や採算に不確定な部分が残っている場合があります。検収後なら遂行した結果を説明できますが、次の案件がなければ担当者の稼働見通しが論点になります。要件の確定、主要な技術課題の解消、顧客の承認、入金など、どの節目を越えると見通しが改善するかを考え、売却準備と案件管理を同じ予定表に置くと判断しやすくなります。

IT M&Aを意識して受注を増やす場合も、納期を守れる体制が伴うかを先に確認します。実績を大きく見せるために不慣れな領域を受けたり、顧客の要望を広く受け入れたりすると、承継後に追加負担が表れる可能性があります。売却前の営業方針は、売上を増やすことと、引き受ける責任を明確にすることを合わせて考えます。受注を断った理由も、得意領域や品質管理の基準を示す材料になるため、単なる機会損失として扱う必要はありません。

準備の段階では、案件の色分けを「順調」「注意」だけで終わらせないことが役立ちます。顧客の判断待ちなのか、仕様が変わったのか、担当者の不足なのかを分けると、経営者が対応すべき仕事が明確になります。すべての案件を完了させて売る必要はありませんが、未解決事項と次の行動は説明できるようにします。問題を抱えたままでも、必要な対応を把握している状態と、把握できていない状態は違います。

更新契約は、締結日だけでなく顧客が判断する時期を見る

保守やSaaSの更新が重要な会社では、契約の満了日だけを並べても意思決定の時期を読み違えることがあります。顧客はその前に予算を決め、代替サービスを比較し、利用部門の意見を集めているかもしれません。更新の見込みを整理するときは、顧客の検討段階、利用状況、未解決の要望、価格変更への反応を確認します。自動更新の条項があっても、解約や条件変更の選択肢までなくなったと考えないことが大切です。

IT M&Aと主要契約の更新が重なる場合、オーナーがどこまで説明を担い、いつ後任へ窓口を移すかを考えます。顧客への説明時期は取引の進め方や契約条件に応じて調整が必要ですが、社長の退任とサービスの変更が同時に伝わると、顧客は影響を判断しにくくなります。体制変更の影響と、契約上提供を続ける内容を整理しておくと、説明を組み立てやすくなります。事実が固まる前の断定的な約束は避けます。

更新前に料金を見直す場合は、売却に向けて収益を高く見せる発想より、提供する仕事との釣り合いを整える発想が適切です。問い合わせが増えた、外部サービスの費用が変わった、対応範囲を広げたなど、理由を説明できるようにします。改定後の契約額だけで判断せず、利用の縮小や解約、追加対応の有無も確認してください。買い手に見せる資料では、改定を申し入れた段階と、合意して適用された段階を分けることが重要です。

開発投資は、完成させる価値と途中で引き継ぐ価値を比較する

新製品や大型機能を開発中の場合、「完成してから売るべきか」は悩みやすい論点です。完成すれば提案できる相手が増える可能性がありますが、追加費用がかかり、顧客の反応が想定と違うこともあります。反対に、開発途中でも買い手の製品戦略と合えば、その体制で続ける案が考えられます。完成という一つの時点だけを目標にせず、顧客の検証、技術的な確認、販売開始など、意思決定に必要な情報が増える段階を見極めます。

IT M&Aの準備投資は、買い手がすぐに自社方式へ変更する可能性のあるものと、どの体制でも必要なものを分けて考えます。製品名や管理画面の見た目を大きく変える投資は、相手の方針次第でやり直しになるかもしれません。一方、再現できない構築手順の整理や、重大な不具合への対応は、日常の事業にも役立ちます。売却だけを理由に急いで全面改修するのではなく、顧客への影響と作業の効果を確かめて優先順位を決めます。

開発者を準備作業へ回す際は、支払額に加え、通常業務が遅れる影響も考えます。手順書の作成で顧客対応が滞れば、準備の目的から離れます。既存のチケットや設計記録を使い、繰り返し質問される部分から補う方が進めやすい場合があります。成果を文書のページ数で測らず、後任が環境を構築できた、別の担当者が変更理由を説明できたなど、実際の仕事が可能になったかで確かめます。

AI導入の効果は、小さく確かめてから売却説明へ反映する

AI導入を売却までに進める場合、全社展開の宣言より、対象を絞った検証から始める方法が考えられます。社内文書の検索、テスト案の作成、問い合わせの分類など、目的と確認方法を定めます。短縮できた作業だけでなく、確認や修正に増えた時間も把握してください。扱う情報や顧客との約束によって利用できる範囲は変わるため、便利だった試行を、そのまますべての案件に適用できる前提で語らないことが重要です。

検証結果を比較する際は、難易度の違う案件や異なる担当者の時間を単純に比べない工夫が必要です。同じ種類の仕事で、品質を確認する条件も揃えると、改善点を説明しやすくなります。AI利用で作業が速くなっても、顧客との承認待ちが長ければ納期全体は変わらないこともあります。開発工程の一部の効果と、契約上の納期や費用への効果を分けておくことで、過度な期待を含まない事業説明になります。

当センターの見解では、売却準備でAIを扱う際の価値は、最新ツールの名前を並べることより、採用と中止を判断する基準があることにあります。効果が小さい試行をやめられるか、利用料が変わったときに見直せるか、提供元の障害時に代替手段を取れるかを考えます。買い手が別の基盤を採用している場合にも、検証の目的と結果が残っていれば比較できます。特定のツールに依存した説明より、判断材料が引き継げる形が有用です。

退任日から逆算し、通常業務の中で引継ぎを試す

退任したい時期が決まっているなら、その直前に重なる仕事を早めに確認します。主要顧客の更新、年次の大きなリリース、繁忙期の運用、基盤サービスの変更などが集中していると、オーナーの引継ぎにも余裕がなくなります。売却交渉の日程だけでなく、事業側の予定を並べて検討することが必要です。予定どおりに進まない場合に、どの仕事を延期でき、どの約束は守る必要があるかまで考えると、退任条件を現実的に整えられます。

引継ぎを試すには、オーナーが通常の会議や判断から一歩離れ、後任が処理した結果を確認する方法があります。顧客から社長へ直接来た相談を新しい窓口へつなぎ、後任が回答できたかを確かめます。ただし、顧客やサービスに影響する問題を放置する実験にはしません。支援を用意し、過去の知識が必要になった判断を記録します。残った課題を具体化できれば、引継ぎ期間を漠然と延ばす以外の対策を考えられます。

売却時期の判断では、すべてを整えてから相談するという順序にこだわる必要はありません。自社で解消すべき課題と、相手の方針を確認してから決める課題があるためです。準備の優先順位は、顧客への約束を守るうえでの重要性、改善に要する時間、オーナーが関われる期間を合わせて決めます。どの会社にも当てはまる最高の売り時を探すより、自社の契約と開発の節目を説明できる状態にすることが、選択肢を比較するための土台になります。

IT M&Aの公表事例から、買い手が評価した事業の違いを読む

GlobalLogicの大型買収と、公表倍率に付いた条件

日立製作所は2021年3月31日、GlobalLogicの親会社を取得する契約を公表しました。発表時の合意株式価値は約85億米ドル、企業価値は約95億米ドル、有利子負債返済を含む買収総額の見込みは約96億米ドルです。これらは同じ金額概念ではありません。完了発表は日本時間7月14日で、実際の取得は米国時間7月13日。買収用子会社を利用した現金対価の逆三角合併により、親会社の全株式を取得しています。^[7][8]

公表されたEV／EBITDA倍率は、2021年予想調整後EBITDAに対して約37.4倍、2022年予想に対して約29.4倍でした。いずれも暦年で、株式報酬と非経常的な一時費用を調整し、相乗効果を含めない単独事業の予想値が分母です。過去の確定利益に対する倍率や、日立全体の利益に対する倍率ではありません。比較には対象期間と調整内容の確認が欠かせません。^[7]

IT M&Aを検討する中小オーナーが、この倍率を自社へ直接当てはめるのは適切ではありません。本稿では、国際的な顧客基盤と設計開発能力を組み込む大型取引と、地域の受託会社の成長条件を区別します。日立は2026年1月にも、GlobalLogicとHitachi Digital Servicesの業務統合を同年4月に開始する計画を公表しています。価値を生む体制づくりは、取得後も続く課題です。^[9]

OECとヒューマンソフトから、専門性と組織の承継を考える

クレスコは2021年6月にOECの取得を決議し、7月1日に全株式を取得しました。対象は組込型ソフトウェアや業務アプリケーションの開発会社で、主な売主は個人でした。翌年の有価証券報告書に示された現金取得対価は17億1,000万円、外部アドバイザリー報酬は424万円です。買い手は専門技術と顧客基盤の拡充を企図しました。その後OECは2023年10月にクレスコ・ネクシオへ商号変更しています。^[10][11][12]

アクシスによるヒューマンソフト取得は2021年3月15日に発表され、4月1日に全株式取得が実行されています。発表時の内訳は株式対価4億1,500万円、取得に伴う費用の概算3,800万円、合計概算4億5,300万円でした。合計全額を売主が受け取る株式代金と読むことはできません。対象はシステム開発やSES等を手掛け、2023年1月1日にはアクシスへ吸収合併されています。^[13][14][15]

両事例からは、技術分野と運営単位をセットで説明する重要性が読み取れます。得意な言語や人数だけでなく、設計判断、レビュー、顧客との調整を誰が担うかが承継の実質を左右します。取引先との直接契約があっても、担当者一人が離れれば継続できない状態なら補強が必要です。また、法人の名前を残すこと、チームを残すこと、従業員の役割を残すことは、別の希望として交渉した方が具体的になります。

A-STARの事例は登録人数と収益の関係を問い直す

SHIFTは2021年3月29日、フリーランスエンジニアのマッチング事業を営むA-STARの全株式取得を発表しました。発表時の取得価額は非開示で、その後の公式発表でも同年3月のグループ参画が確認できます。対象は開発案件と人材を結ぶ仕組みであり、登録者全員を雇用する会社を買う取引とは違います。買い手は案件情報とエンジニア情報を結び付ける事業の拡大を狙っていました。^[16][17]

IT M&Aでこの事例を読む際は、取扱高と自社の売上を分けることが重要です。案件全体で顧客が支払う額と、仲介や支援の手数料として会社に残る収入は一致しません。登録者が多くても、最近稼働した人、継続して利用する顧客、契約ごとの収益を確認しなければ評価はできません。案件の獲得、紹介、更新を支える運営を次の経営者も再現できるかが、本稿の着眼点です。

SHIFTは2023年12月、A-STARとの合併契約を公表し、翌年3月1日を効力発生予定日としました。これを踏まえると、買い手が法人を独立させ続けることを当然の前提にはできません。売主が残したい価値は、法人格なのか、サービス名なのか、顧客との接点なのかを整理する必要があります。登録情報の利用範囲、連絡手段、契約主体が変わる際の運用も、統合計画で確認しましょう。^[17]

Mikatusでは株式交換の対価と製品統合を分けて見る

freeeは2022年5月にMikatusの完全子会社化を発表し、6月30日に現金対価の簡易株式交換による取得を完了しました。株式交換という名称でも、売主が買い手の株式を受け取るとは限りません。決算短信の千円単位の開示では、現金取得対価は20億7,524万7,000円、取得関連費用は3,075万6,000円です。また、取得完了と旧株主への代金支払の時期は区別して案内されていました。^[18][19][20]

同じ決算短信には、取得時ののれんと顧客関連資産を全額減損したことも記されています。この会計処理だけで、顧客が消失した、対価がゼロだった、減損額と同じ現金が追加で流出したとは判断できません。Mikatusは同年9月30日にfreeeへ吸収合併されています。株式取得の完了、会計上の評価、製品と組織の統合は別の出来事であり、一つの出来事だけで承継の成果は断定できません。^[19][21]

売主が参考にできるのは、会計事務所との接点と、税務・会計・給与の開発知識を承継する視点です。ソフトウェアの引渡しはソースコードを渡すだけでは終わりません。法改正への対応方法、問い合わせの判断基準、顧客ごとの利用状況が運営を支えています。自社製品を統合する提案を受けた場合は、既存利用者への提供継続、移行費用、開発担当者の役割まで具体化することで、価格の背景を議論できます。

HiTTOから考える機能補完と買い手固有の価値

マネーフォワードは2021年11月30日にHiTTOの取得を決議し、12月22日に全株式を取得しました。決算短信の現金取得原価は19億9,851万6,000円、取得関連費用は1,808万2,000円です。対象は社内向けAIチャットボットで、人事労務製品との連携や顧客基盤の活用を狙っていました。2024年3月1日には本体へ吸収合併されています。当時の製品や市場での位置づけは、現在と区別します。^[22][23][24]

IT M&AでSaaSの売主が説明できる強みは、売上の継続性に加え、買い手が持っていない業務領域を埋める機能です。ただし、機能が補完的であることと、連携すればすぐに収入が増えることは同じではありません。利用者の権限設計、データ形式、認証、サポート窓口を揃える投資が必要な場合があります。自社だけで生む収益と、買い手の製品や営業網を要する収益を分け、実現の負担を議論しましょう。

六つの取引は、金額の順位を作るための比較ではありません。大型の国際開発会社、専門的な受託会社、人材のマッチング基盤、業務特化型SaaSでは、利益を生む構造が違います。本稿の見解として、オーナーが事例から持ち帰るべきものは、自社と同じ倍率ではなく、何を買い手へ渡せば顧客への提供が続くかという問いです。技術、契約、担当者、運用知識を結び付け、自社が渡す価値を具体化しましょう。

IT M&Aの正常収益を、受注・人員・開発投資から組み立てる

オーナー退任後の費用まで含めて利益を調整する

会社売却の評価資料では、決算上の利益から、承継後に続く利益へどのように移ったかを示します。経営者が営業責任者とCTOを兼務している会社なら、退任に伴い必要になる仕事を洗い出すことが先です。役員報酬を除くだけでは、技術判断や採用、障害時の対応を誰が引き継ぐのかが抜けます。現在の報酬と後任費用との差額を計算し、同じ仕事の人件費を二度差し引かないようにします。

以下は実案件ではない説明用モデルです。営業利益3,500万円に減価償却・償却費1,000万円を加えたEBITDAを4,500万円と置きます。一過性の費用などを調整し、後任CTO、採用、クラウド利用に必要な追加費用を反映すると、正常EBITDAは4,000万円になります。EBITDAは償却等の影響を除く収益指標であり、税金や運転資金、開発投資を控除した現金とは異なります。

一過性として加算する費用には、内容と再発可能性の根拠が必要です。今回の仮定では、既に終了した単発の資本政策対応費300万円と、事業に関係しない私的費用100万円を加えています。一方、毎年の採用費や顧客監査への対応費は、発生月が偏っていても通常運営に必要なら安易に除けません。売却後は発生しないと判断した根拠を、証憑と業務条件で示しましょう。

表は横にスクロールできます。

受託開発は検収と残作業をプロジェクト単位で確かめる

受託開発の売上は、請求書を発行した日だけでは評価できません。契約上の約束、収益認識の方針、検収の状況、残る作業を照合する必要があります。売上計上と入金がずれる案件では、未請求額と回収待ちの債権を分けます。受注総額が大きくても、既に投入した原価と完成までに必要な原価が分からなければ、買い手は承継後に残る利益を判断できません。

受託案件の利益を調べるときは、見積り時の工数と最新の完了見込みを並べます。追加要件が無償対応になっていないか、外注費や検証環境の費用が漏れていないか、主要担当者の異動で再作業が増えないかを確認します。顧客との変更合意や課題管理の記録があれば、利益見込みを裏付けられます。「もうすぐ終わる」という説明には、残る成果物と判断待ち事項による裏付けが必要です。

不採算案件を一度限りの損失として正常利益へ足し戻す場合も、原因が取り除かれているかを見ます。見積りの甘さや仕様変更の管理不足が続く会社なら、今回だけの例外とは言いにくくなります。既に完了した案件の損失と、進行中の案件で追加発生し得る損失も分けなければなりません。本稿では、次の受注で同じ失敗を繰り返さない契約・見積り・管理体制が、正常収益の根拠になると考えます。

SESは稼働率だけでなく採用と待機の循環を見る

SESの稼働率を見るときは、分母に誰を含めたかを明らかにします。新入社員、研修中、休職中、次の案件まで待機している人を除いた数字と、全社員を含めた数字は比較できません。技術分野や経験年数ごとに、単価、稼働、給与、外注の比率を分けると、会社の収益構造が見えます。買い手は現在の満員状態だけでなく、契約が終わった人を次の案件へ配属する能力まで引き継ぐ必要があります。

売却後は採用費を削れると説明する前に、その費用が成長用か、退職者を補う維持用かを分けましょう。採用を止めた直後は利益が増えても、その後の人員減少で売上が下がる可能性があります。入社から配属までの教育費と待機給与、配属後の定着、紹介料の支払時期も含めて検討します。買い手の採用ブランドを使えば改善するという期待は別に置き、自社単独で収益を維持するための採用負担を正常利益へ反映します。

取引先が同じでも、窓口や契約の経路が変われば売上が続くとは限りません。顧客との直接契約か、他社を介した契約か、更新時に誰が条件を交渉するかを整理します。技術者本人の希望、リモート勤務の条件、勤務地の変更も継続に関係します。人数を固定したまま単価だけが上がる計画には、単価改定の合意や技術習得の根拠が必要です。これらの説明があれば、人員離脱の想定を具体的に検討できます。

SaaSの継続収益を解約とクラウド原価へつなげる

ARRは、ある時点の継続的な契約収益を年換算して捉える指標で、過去一年の会計売上や、その年に入った現金と同じではありません。一過性の初期導入費や個別開発は継続料金と分け、従量料金や無料期間の扱いは定義を明示します。集計日を示し、契約台帳から再計算できるようにします。将来の更新を当然とした数字である場合には、その前提も読み手が分かるようにします。

SaaSの売却評価を支えるのは、総契約額だけでなく、その残り方です。新規契約、既存顧客への追加販売、減額、解約を分け、顧客の利用開始時期別に更新の傾向を見ます。大口顧客一社の拡大が全体を押し上げている場合と、多数の顧客が継続している場合ではリスクが違います。更新率の定義、対象顧客、休眠や未入金の扱いを揃え、継続収益を追跡できる状態にします。

クラウド利用料、外部API、監視、顧客対応にかかる原価も、利用者が増えた後の水準で確認します。期間限定のクレジットや割引に支えられた原価率を、そのまま次年度へ延ばしてはいけません。生成AI機能を提供する場合には、処理量の増加が費用へどう連動するかも検討対象になります。売上と粗利が同率で伸びるとは限りません。利用量と料金体系、顧客別のサポート負担から計画を組み立てます。

資産計上した開発費と必要な現金投資を別に示す

ソフトウェア開発に使った支出がすべて、その年度の費用になるとは限りません。会計基準と開発目的、進捗に応じた処理によって資産計上され、後の期間に償却されるものがあります。したがって、EBITDAが同じ会社でも、開発費を費用計上する会社と資産計上する会社では比較に注意が必要です。資産へ振り替えた費用、償却額、当期の現金支出、完成後の保守費を一緒に示します。

買い手へ継続開発の負担を説明する際は、現行製品を維持する更新と、新製品に成長を求める投資を分けます。セキュリティ対策、外部サービスの仕様変更、法改正への対応など、止めれば既存収益を維持できない仕事があります。償却を利益へ足し戻したからといって、この支出が不要になるわけではありません。正常EBITDA4,000万円のモデルでも、その後に必要な開発投資や運転資金を確認して初めて、残る現金を判断できます。

開発費の資産計上は、売却前に利益を増やすため自由に選べる調整ではありません。既存の会計方針と適用根拠を確認し、途中で処理を変更した場合は理由と影響を説明します。買い手との比較では、同じ範囲の開発負担を揃える必要があります。資産計上済みの金額を価値へ上乗せしながら、将来の利益を維持する投資をゼロと置く構成には無理が生じます。開発の成果と残る作業を、会計と技術の両面から説明しましょう。

IT M&Aの評価方式を選び、事業価値と株式価値をつなぐ

倍率の前に分母と対象事業を揃える

「利益の何倍」という言葉だけでは、評価方法は決まりません。営業利益、EBITDA、税引後利益のどれを使うかで数字が変わり、株式対価と企業価値でも倍率の意味は違います。受託開発とSaaSが混在する会社では、共通の開発者や販売費をどう配分したかも影響します。一括評価か事業別評価かを決め、共通費の計上漏れと重複を避けます。

IT M&Aを想定した計算例では、正常EBITDA4,000万円に説明用の5倍を掛け、事業価値を2億円とします。この5倍は、業界平均、相場、当社の成約倍率、公表6事例の平均のいずれでもありません。前提を変えた場合に金額がどう動くかを確認するための仮定です。GlobalLogicで公表された予想調整後EBITDA倍率などを、中小企業の直近利益へ直接使うものでもありません。規模と利益の定義を区別します。

倍率の違いを説明する材料には、顧客の継続性、契約の集中、経営者への依存、技術の陳腐化、成長余地などがあります。ただし、顧客数が増えれば倍率を一段上げるといった機械的な計算はできません。買い手の必要な機能と自社の強みが合うこと、維持に必要な投資を負担できることも関係します。価格を負担する買い手が、どの事業計画で回収を見込めるかが交渉の材料になります。

株式価値は会社に残る現金と負債まで確認する

説明用モデルの事業価値2億円に、営業へ不要な余剰現金3,000万円を加え、有利子負債6,000万円を引くと、株式価値は1億7,000万円になります。式は「4,000万円×5倍＋3,000万円－6,000万円」です。これは全株式を売る場合の仮定価値であり、税金と売主負担費用を引く前の金額です。事業価値2億円が、そのままオーナーへ入金されるわけではありません。

余剰現金3,000万円は、預金残高をすべて加えたものではありません。給与、外注費、クラウド料金、税金など、通常運営に必要な資金を残した後の金額と仮定しています。モデルでは、借入以外に調整すべき債務類似項目や余剰資産はないものとします。実案件で年額契約の前受金が多い場合には、将来のサービス提供費用も考える必要があります。前受金を一律に借金扱いせず、運転資金と対価の定義を揃えます。

取引の実行直前に決算を調べる目的は、利益の確認だけではありません。未払外注費、賞与、未請求の契約資産、回収に不安のある債権などで、渡す会社の資金状態が変わります。価格調整の対象を定め、基準日と実行日を区別します。売主が期末に現金を配当で引き出す場合も、その分を価格へどう反映するかが必要です。同じ現金を配当と株式価格の両方で受け取る前提にはできません。

仮定の感応度で交渉の金額差を把握する

下表は、正常EBITDA4,000万円、余剰現金3,000万円、有利子負債6,000万円を固定し、倍率だけを4倍、5倍、6倍へ変えています。株式価値はそれぞれ1億3,000万円、1億7,000万円、2億1,000万円です。倍率1倍の違いが4,000万円の価格差になる関係を示します。各倍率は説明のために置いたものであり、売却可能な価格帯や業界の標準水準を示す表ではありません。

表は横にスクロールできます。

利益の調整にも同じように価格への影響があります。別の感応度として、倍率5倍を固定し、正常EBITDAが4,000万円ではなく3,500万円と認められた場合、事業価値は1億7,500万円、ほかの前提を変えない株式価値は1億4,500万円です。500万円の利益差が2,500万円の価値差になります。後任費用や採用費の扱いにも、倍率と同様の価格への影響があります。

価格交渉では、同じリスクを利益の減額と倍率の低下の両方へ重ねていないかも確認します。主要顧客の解約が既に利益予想へ反映されているのに、同じ影響をもう一度大きく価格へ引けば、調整の説明が必要になります。一方で、減収後も別の不確実性が残るなら倍率の議論はあり得ます。どの事実をどの計算へ反映したのか、根拠ごとに確認して話し合います。

ARRとDCFは将来の収益構造を確かめて使う

SaaSでARRを評価の補助指標とする場合も、ARRに何を含めたかが前提になります。契約が解約可能か、利用料が固定か、導入作業が別途必要か、更新時の値引きが大きいかで、同じARRでも残る収益は違います。粗利率と成長に必要な販売・開発費を確かめず、ARRへ一律の倍率を掛けるだけでは価格を支えにくくなります。継続契約が現金を生む過程を、価格の根拠にします。

DCF法は、将来の事業から生まれるキャッシュフローを、時期とリスクを考慮して現在の価値へ換算する考え方です。赤字の成長事業や、開発投資が先行する会社では、利益がいつ現金へ変わるかを明示するのに役立ちます。ただし、細かい計算表を作っても、解約率、単価、人員、投資の仮定が楽観的なら結論も変わります。顧客獲得の遅れと追加資金の必要性も計算に反映しましょう。

受託、SES、自社SaaSを持つ会社では、事業別に予測する方が分かりやすい場合があります。受託は受注と完了工数、SESは人員と稼働、自社SaaSは契約更新と原価を基礎に置きます。そのうえで共通の営業、技術管理、総務などの費用を一度だけ負担させます。成長事業を育てる人員が受託売上も支えているなら、両方へ同時にフル稼働させる計画は成立しません。人員の時間配分も検証しましょう。

コードや顧客契約を価値へ二重に加えない

利益やキャッシュフローから継続事業を評価する場合、その利益を生むソフトウェアや顧客契約の価値は既に含まれていることがあります。帳簿上のソフトウェア残高を追加で全額上乗せすると、同じ収益力を二度数える可能性があります。一方、事業に使わない資産が売却可能なら別に検討する余地はあります。取得する権利と収益維持に要する追加投資を確かめ、評価の対象範囲を揃えます。

IT M&Aでソフトウェアの価値を説明するときは、開発に費やした金額と、次の経営者が活用できる価値を分けます。古い環境への依存、保守できる人材の不足、顧客専用部分の多さによって、再利用できる範囲が限られる場合があります。権利の帰属や外部ライセンスの条件も関係します。買い手が一から作らずに済むという説明には、動作する成果物、設計資料、保守方法と利用権限を示すことが必要です。

純資産を基にした見方も、利益による評価と照合する材料になります。ただし、回収困難な債権、利用しないソフトウェア、未払費用などを調べずに帳簿だけで判断はできません。逆に、優良顧客との関係や組織の開発能力は帳簿へ十分表れないことがあります。複数の方式で異なる結論が出たら、その差がどの資産、利益、将来条件から生じたのかを説明します。単に方式の平均を取るだけでは根拠になりません。

IT M&Aの提案を、代金・引継ぎ・将来責任まで比較する

一括現金と分割・追加対価の提案を同じ表で比べる

ここでは株式対価1億7,000万円を実行時に全額現金で支払うA案と、最大2億1,000万円のB案を仮定します。B案は実行時1億3,000万円、一年後の固定分割金3,000万円、将来業績に応じた追加対価が最大5,000万円という構成です。B案の最大額は大きくても、最初の受取額はA案より4,000万円少なくなります。両案とも税金・売主費用前の架空の提案です。

提案の比較では、無条件の分割金と業績条件付きの追加対価を分けることが重要です。一年後に払う義務が確定していても、買い手が支払えないリスクや、回収まで資金を使えない負担は残ります。業績連動部分は、条件に届かなければ金額自体が減る可能性があります。最大対価を確定財産のように考えず、支払期限、条件、保証、紛争時の扱いを確認し、必要資金と照合します。

提案書に書かれた「総額」には、オーナー貸付の返済や役員退職金、一定期間の報酬が含まれる場合があります。株式対価だけの提案と比較するなら項目を揃えなければなりません。会社から支払うお金が会社の純資産と対価にどう影響するかも確認します。買い手の負担総額、会社から出る資金、個人が受け取る額は同じではありません。支払者と受取者を対応させ、総額に含まれる条件を読み解きましょう。

表は横にスクロールできます。

追加対価の指標を、売主が確認できる条件にする

アーンアウトと呼ばれる業績連動の追加対価は、将来の成長への見方が違う場合に、その差を条件へ置き換える方法になり得ます。受託会社なら売上だけでなく完成原価、SaaSなら契約の更新や減額の扱いによって結果が変わります。どの顧客と製品を対象とし、どの期間、どの会計方針で測るかを契約に落とす必要があります。最大額だけを決めて計算方法を後回しにすると、合意額が不明確に残ります。

IT M&Aで追加対価を設計する際は、買い手の判断が指標をどう変えるかを見ます。既存製品を別製品へ移行すれば対象売上が減り、共通の開発費を多く配賦すれば利益も変わります。売主が価格や人員、開発順序を決められない場合、自分では達成を管理できない条件になり得ます。方針変更時の計算方法、運営資源、報告頻度を決め、事業範囲と評価条件を結び付けます。

業績の確認には、売主が必要な資料へアクセスできる仕組みも必要です。契約管理、請求、会計の数字を誰が照合し、異議がある場合にどう処理するかを定めます。顧客情報を無制限に閲覧するという意味ではなく、守秘義務と必要性に合わせて確認範囲を設計します。固定対価の割合を下げて将来へ委ねるなら、その期間に売主が担う役割と、受け取れない場合の生活設計まで検討しておくことで、選択の意味が明確になります。

CTOや営業責任者として残る役割を具体化する

オーナーが売却後もCTOや顧問として残るなら、コードレビュー、顧客との折衝、障害対応、採用面接のどこまでを担当するかを決めます。平日の助言と、夜間休日の緊急対応では負担が異なります。勤務時間、報酬、決裁権、終了時期を別契約も含めて整理し、買い手のチームへ権限を渡す段階を示すと引継ぎ計画になります。売却代金が高くても、役割と期間が曖昧な勤務条件には注意が必要です。

IT M&Aの引継ぎには、仕様書に書かれていない判断を共有する仕事があります。なぜその設計を選んだか、特定顧客の要望をどこまで約束したか、過去の障害で何を変更したかなどです。ただし、いつまでも元社長へ聞けばよい状態では承継が進みません。後任が判断できる範囲と、実際に担当を交代させる時期を決めましょう。買い手が担う採用や教育は、担当者と投入時期を確認します。

競業避止や勧誘禁止を含む条項は、売却後に何をしたいかと照合します。新しいソフトウェアの開発、別領域の顧問、投資先への技術支援などが一括して制限されると、引退後の計画が変わります。対象となる顧客、業務、地域、期間、関わり方を具体化し、法的な有効性や文言は専門家と確認します。守りたい顧客関係と売主の今後の活動を説明し、実行できる条件を作ります。

顧客対応と知的財産の責任を対価から切り分ける

契約後に不具合や未対応の要望が見つかった場合、誰がどこまで負担するかを整理します。納品済みの成果物に対する保証、運用サービスの水準、過去の障害対応、外注先への請求権などで条件は異なります。売主が把握していた問題と、取得後の変更から生じた問題も区別する必要があります。未解決事項を一覧にし、価格へ織り込むのか個別補償とするかを決め、負担の重複を避けます。

IT M&Aの補償では、ソースコードや著作権の帰属、外部ライセンス、個人情報の取扱いなど、対象会社の事実をどの範囲で約束するかが問題になります。全件を確認できていないのに例外なしと断言すると、売却後の責任につながり得ます。調査範囲と判明した事項を開示し、補償の期間、上限、請求手続、既知の事項の扱いを確認します。第三者の権利や顧客の同意は、両社の合意だけで処理できません。

会社の借入に個人保証を付けている場合には、株式を売っただけで解除されるとは限りません。どの債権者が、いつ、どの条件で解除するかを確認し、買い手の予定と実際の承諾を区別します。銀行だけでなく、契約上の個人責任や担保が残らないかも点検が必要です。保証解除が実行条件か、実行後の対応かによって売主のリスクは変わります。入金後も個人に残る義務を確認しましょう。

税金・費用・資金拘束を踏まえて受取額を判断する

株式価値1億7,000万円のモデルも、提案比較の最大2億1,000万円も、税金と売主側費用を控除する前の金額です。株式を個人で売る場合と、会社が事業を譲渡する場合では、代金が最初に入る主体が異なります。事業譲渡後に会社から個人へ資金を移す方法も含めて、税負担と時期を確認する必要があります。取得費や持株の状態も影響するため、総額に一つの税率を掛けるだけでは手取りは決まりません。

費用の見積りは、対象となる金額と支払条件まで確認します。株式対価だけで報酬を計算するのか、負債や別の給付を含むのか、最低額や着手時の支払があるかで負担は変わります。技術調査への対応、契約整理、必要な権利処理などの作業も、誰が支払うかを決めます。支出を個人と会社に分け、消費税を含む支払予定から、入金前の必要資金と売却後の利用可能資金を把握します。

最終的には、実行時に使える現金、将来の分割金と条件付き対価、残る勤務、補償、個人保証を並べて判断します。同じ名目価格でも、製品を続ける役割を担う売主と、経営から離れる売主では適した条件が違います。本稿の見解では、買い手を選ぶ基準は最高額だけでなく、自分が渡したい事業と残したい役割が契約に合っていることです。家族の生活と次の活動に必要な資金も踏まえて選びましょう。

IT M&Aで顧客・社員との約束を次の経営体制へつなぐ

顧客への約束から次の責任体制を決める

会社の売却でオーナーが引き継ぐものには、契約書に書かれた納品物だけでなく、顧客が毎月の業務で頼りにしている対応があります。月末処理の立会い、年度更新への準備、障害時の連絡などです。まず主要顧客ごとに、誰に、何を、いつまでに約束しているかを一枚にまとめます。営業上の説明、契約上の義務、担当者の好意で続けてきた対応を区別し、買い手に維持してほしい範囲を言葉にします。

受託開発ではリリース予定だけでなく、顧客による仕様確定や検収の予定も承継計画に入れます。SaaSでは次の更新日と、営業が伝えた機能追加の予定を照合します。運用保守では監視対象、受付時間、復旧の判断者を確かめます。売上高が同じ顧客でも、引継ぎに必要な作業と失敗した場合の影響は異なります。売上順位だけで説明の順番を決めず、止まると顧客の仕事が続けられない関係を先に拾います。

当センターの見解として、承継の説明は「これまでどおり」という言葉だけでは足りません。変更しないサービス、変更を検討するサービス、その判断時期を示す方が、社員も顧客も質問できます。現時点で決められない内容は、誰がいつ回答するかを置きます。答えを出す責任者が決まっていない約束を、そのまま買い手の経営方針として説明すると、現場が後から修正を求められるためです。

IT M&AでPMと技術責任者の権限を引き継ぐ

プロジェクトマネジャーが在籍し続けることと、その人が案件を運営できることは別です。オーナーが追加工数の承認、採用、顧客への値上げ説明まで握っている会社では、PMだけを残しても判断が止まります。次の体制では、顧客と納期を調整する人、技術上の出荷可否を判断する人、予算を決める人を分けて確認します。一人が複数を担う場合も、役割ごとの代理者と相談先を決めておきます。

技術責任者については、設計の知識だけでなく、どの危険を誰に伝えてきたかを引き継ぎます。例えば古い基盤を延命している理由、復旧できるデータの範囲、個別顧客だけ異なる設定は、構成図だけでは理解できないことがあります。変更の理由と却下した案も残し、次の責任者が同じ判断を再現できるようにします。引継ぎの完成は資料の受領日ではなく、受け手が判断の根拠を説明できた時点で確かめます。

売却交渉では、売り手側が守りたい裁量と買い手が統一したい管理を、具体的な承認事項に置き換えます。採用の人数枠を維持しても、給与の承認に時間がかかれば人員確保は難しくなります。逆に全てを旧体制のまま固定すると、必要な投資も進みません。以下は話合いのための整理例です。役職名より、判断できる範囲と例外時の連絡先を比べることで、候補先ごとの差が見えてきます。

表は横にスクロールできます。

社員への説明は処遇と仕事の見通しを具体化する

社員が知りたいのは会社名の変更だけではありません。担当案件、評価者、働く場所、待機時の扱い、学習時間、当番負担など、翌月の仕事に関係する内容です。買い手の制度を紹介する前に、現在の条件と変更を検討している条件を並べます。確定していない昇給や昇格を残留の材料として約束せず、確認中の事項には回答時期を置きます。質問を全員の前で言いにくい人のため、個別に確認できる機会も用意します。

株式譲渡では通常、雇用主である法人は変わりませんが、それだけで将来の労働条件変更が自由になるわけではありません。事業譲渡で労働契約を移す場合は、本人の承諾を含む対応を検討します。厚生労働省の事業譲渡等指針は2026年5月25日から改正内容が適用されています。取引方法に応じて説明・協議の内容と時期を専門家に確認し、会社分割など異なる制度の手続を混ぜないことが必要です。^[25]

重要人材に協力を求める場合は、残ってほしい理由と担当してほしい仕事を具体化します。単に「顧客があなたを信頼している」では、責任だけが増えると受け取られることがあります。引継ぎの支援者、業務量の調整、処遇の検討者まで示すことが大切です。特定の社員の残留を売却条件に入れるなら、その人の意向を確認する前に確約しません。本人の選択を前提に、複数人で支えられる仕事の分担も並行して考えます。

顧客と協力会社へ伝える順序を設計する

取引の公表時期は、顧客への説明時期と必ずしも一致しません。支配関係の変更や契約移転について事前の通知・承諾を求める条項があれば、公表前の調整が必要となる場合があります。先に基本契約と個別注文書を確認し、顧客ごとの窓口、必要資料、回答までの期間を整理します。重要顧客への確認を最後に残すと、承諾が得られるか不明なまま実行日だけが近づくことになります。

説明の場では、買収の理由に加え、担当者、契約の相手方、請求先、サービスの連絡窓口がどうなるかを伝えます。顧客担当者が社内稟議や委託先審査を進めるには、情報セキュリティ体制や再委託範囲の回答が必要なこともあります。オーナーだけが挨拶して終わらず、今後回答を担う人を同席させます。ただし、競争上機密性の高い取引条件を、説明に不要な相手へ広げることは避けます。

協力会社やフリーランスについても、発注が続くという説明だけで安心は得られません。単価交渉の窓口、支払日、開発環境への接続、成果物の扱い、問い合わせ先を確認します。旧オーナーとの個人的な関係で優先対応してもらっていたなら、その優先順位が維持できるかを聞く必要があります。買い手の購買制度へ移すことで小口発注が遅くなる場合は、緊急対応の発注手順を先に合意しておきます。

IT M&Aの実行は契約・技術・資金の条件をそろえて判断する

IT M&Aの契約対象を顧客契約と受注残から定める

受注残の一覧には金額に加え、未着手、開発中、顧客確認待ち、検収済み未請求という状態を記します。基本契約を渡しただけでは、変更発注や追加対応の経緯が伝わらないためです。IPAのモデル契約も、仕様や検収、プロジェクト管理などの共通理解を重視しています。実際の契約と議事録を照合し、売却日時点で残る作業、顧客の協力が必要な事項、支払条件を案件単位で説明できるようにします。^[26]

株式譲渡と事業譲渡では、会社、契約、資産が動く仕組みが異なります。取引方法だけで全てを判断せず、契約の承諾条項、解除権、再委託の制限などを個別に確認します。売上の大きい顧客に契約更新の回答を求めている途中なら、回答前提の見込みと確定済みの受注を分けます。承諾待ちの契約が残る場合は、その契約を欠いても事業を運営できるか、取引条件の変更や実行延期が必要かを判断します。

ソースを保有することと利用できることを分ける

会社のリポジトリにコードが保存されていても、全ての権利を自社が持つとは限りません。顧客向けの成果物、外注者の制作物、共通部品などについて、権利の帰属と利用できる範囲を確かめます。著作権の譲渡では二次的利用に関する権利の扱いも確認が必要で、著作者人格権は譲渡できません。文化庁の解説を手掛かりに、所有していると説明する範囲を、実際の契約と作成過程に結び付けます。^[27]

ソフトウェアを承継する際は、使われているOSSを一覧にしただけで権利確認を完了させません。製品の実態と一覧の対象が一致するか、残る対応を誰が行うかまで買い手と共有します。経済産業省のSBOM手引も、継続した管理や当事者間の責任整理を扱います。具体的な調査方法はOSS・SBOMのデューデリジェンス解説を参照し、本取引で必要な是正の期限を決めます。^[28]

クラウドと個人データの移管条件を確認する

クラウド環境は、管理者権限を渡せば契約も移るとは限りません。契約者、請求先、サポート窓口、利用料の割引条件、第三者サービスとの連携を確認します。個人データについても、クラウド事業者がそのデータを取り扱う契約かどうかなど、実際の提供形態で整理が変わります。個人情報保護委員会のQ&Aを確認し、アクセス権の変更と、契約・安全管理上の確認を別々の作業として管理します。^[29]

顧客から預かっているデータを、自社が自由に使える営業資産や学習データとして買い手へ説明することはできません。取得や利用の目的、委託元との約束、再委託の条件を確認します。事業承継に関する個人情報保護法上の扱いも、承継後の無制限な利用を認めるものではありません。検討段階の開示では、必要性に応じた対象の限定、利用目的、管理方法、不成立時の処理を整理して進めます。^[30]

一部事業だけを切り出して譲るなら、共通の認証基盤や監視契約を当面利用する期間が必要な場合があります。その間に利用できる範囲、料金、障害対応、終了条件を決めます。具体的な分離作業はカーブアウト・TSA・Day 1の実務解説で確認できます。売り手は仮の運用を続けられる期間を見積もり、終了日だけ決めて担当者を空欄にしないことが大切です。

表は横にスクロールできます。

障害発生時と引継ぎ未完了時の負担を決める

引継ぎ中に障害が起きたとき、原因の帰属を確定する前に復旧作業が必要になることがあります。売却契約の責任分担と、顧客を支える初動の手順を分けて用意します。誰が指揮を執るか、旧担当者へ連絡できる時間、外部業者を呼べる人、費用の仮負担を決めます。原因調査が終わるまで対応を止めない仕組みを作り、実施した作業や承認を記録して、後の負担協議につなげます。

例えば、旧版の不具合が売却後に表面化し、同時に買い手側の設定変更も行われていたとします。これは説明用の想定であり、責任を一律に決められる例ではありません。対応記録、引継ぎ時点の状態、既知の問題の開示がなければ、原因を議論する材料自体が不足します。既知の障害、未解決の問い合わせ、保守期限を一覧にし、相手が読んだことと、対応の負担を合意したことを区別して管理します。

売り手が譲渡後の技術支援を引き受ける場合は、期間だけでなく作業の範囲と上限を具体化します。通常の問い合わせへの助言と、新機能開発や大規模障害の復旧を同じ報酬に含めると、退任後の生活計画も崩れます。追加支援を依頼する手順、費用、連絡できないときの代替先を決めます。売却契約上の補償責任とは別の約束として整理し、不明確なまま「必要な協力を続ける」とだけ記載しないよう確認します。

買い手の履行能力と個人保証の解除を実行条件にする

買い手を評価するときは、提示額と資金の裏付けを分けて確認します。資金調達の条件、決裁状況、支払日、分割払いの場合の対応に加え、買収後の給与やクラウド利用料を支えられるかも重要です。買い手の説明に疑問があるときは、支援者を通じて根拠資料を確認します。実行を急がせる理由だけで納得せず、売り手が負う責任に見合う情報がそろった時点で判断することを勧めます。

個人保証は、買い手が解除すると約束したことと、債権者が解除を認めたことを区別します。中小M&Aガイドラインも、成立前の金融機関への相談や最終契約での整理を求めています。借入ごとに解除・移行の条件と確認書類を確かめ、未確認なら保証から解放されたとは扱いません。オフィスやリース等に個人保証がないかも確認します。売却代金を受け取った後まで義務が残る条件は、実行前に把握しておく必要があります。^[31]

IT M&Aに向けた12か月の準備と最初に集める資料

IT M&Aの準備を契約更新と開発計画に合わせる

準備期間を決めるときは、希望する売却月から逆算するだけでなく、顧客の契約更新、年度予算、主要リリース、採用の時期を重ねて見ます。更新交渉と経営者変更の説明が重なると、顧客側の確認事項が増えることがあります。一方、新たな体制で更新後の支援を説明できれば安心につながる場合もあります。事業の節目と関係者の判断日を並べ、どこに承継の作業を置けるかを検討します。

以下の12か月は実行順序を考えるための例であり、成約期間を保証するものではありません。既に契約整理が進んでいる会社と、旧オーナーの個人アカウントに業務が集まる会社では必要な期間が違います。全ての問題を解決してから相談する必要はありませんが、解決に相手方の承諾が必要な項目は早く見つけます。自社で決められる作業と、顧客・金融機関・権利者の回答を待つ作業を区別することが出発点です。

最初の資料を少数の原本からそろえる

売却に向けた初期準備では、見栄えのよい会社紹介資料を作る前に、判断の根拠となる資料の所在を確認します。次の10点は全てを初回相談で提出するという意味ではありません。保存先、更新日、作成者、欠けている期間を書いた目録を作り、必要な順に確認できる状態にします。初期の検討では金額の集計や匿名化した概要を用い、顧客情報や技術情報の詳細は目的と開示先に応じて段階的に扱います。

資料同士の数字が一致しない場合は、担当者に都合のよい数値へ合わせてもらうのではなく、対象期間や集計の違いを確認します。請求基準の売上と検収基準の管理表、社員の所属人数と案件の稼働人数などは、そのままでは比較できないことがあります。原本を保存し、差異の理由を別に記録します。数字を完全にそろえることより、買い手の質問に対して同じ根拠から答えられる状態を目指します。

表は横にスクロールできます。

月ごとの節目で準備の効果を確かめる

最初の1〜3か月は、契約、案件、権利、担当者を突き合わせ、将来の経営者が困る箇所を探します。全ての資料を同時に清書する必要はありません。オーナーが一週間不在だった場合に止まる判断を洗い出し、最も影響の大きい顧客から代理者を置きます。同時に、希望条件を共同株主や家族と共有します。売却後も続けたい仕事と退きたい仕事が混ざっている場合は、この時期に書き分けます。

4〜8か月は、見つけた課題を日常業務の中で直します。追加発注の確認を案件管理に組み込み、顧客会議に次の窓口担当者を参加させ、当番の交代で障害対応を試します。契約の更新時期に権利や再委託条項を確認するなど、相手方に不自然な依頼を集中させない進め方も考えます。毎月、未解決の項目が減ったかだけでなく、再発していないかを見ます。新たな案件で同じ問題が増えるなら、運用の変更が必要です。

9〜12か月は、実際の候補先が示す経営体制と準備した条件を照合します。条件が具体化している場合は、顧客承諾、金融機関との調整、社員説明、初日の運用確認を実行日へ結び付けます。まだ候補先が決まらなければ、準備の成果を次の決算や契約更新へ反映します。期限を迎えたから売るのではなく、引継ぎに必要な情報と判断がそろったかを確認する節目にします。無理な日程で主要リリースの品質を落とさないことも必要です。

売却を延期する条件も書き残す

第三者への承継を検討し始めたときに、進める条件だけでなく、再検討する条件も決めておきます。例えば顧客の利用を継続できない、譲渡後の支援範囲が無制限になる、買い手の資金の裏付けが不足する、といった状態です。全てを絶対条件にすると候補先を比較できないため、譲れない事項と追加対応で受け入れられる事項を区別します。面談を重ねて判断が変わった場合も、その理由を記録しておきます。

延期する場合は、単に「条件がよくなるまで待つ」で終えず、何を改善すれば判断が変わるかを定めます。主要顧客の更新を確認する、権利関係を整理する、代理者が案件を運営できることを確かめる、といった到達点です。改善の担当者と確認日を置き、保有を続ける間の資金とオーナーの稼働を見積もります。待つ期間にも開発投資や人材流出が起こり得るため、延期の負担を売却条件と一緒に考える必要があります。

準備の進み具合は書類の冊数だけで測れません。次の担当者が顧客の質問に答えられる、緊急連絡に代理者が応答できる、契約と実際の作業範囲の差を説明できる、といった行動で確かめます。当センターの見解では、こうした確認は買い手のためだけの作業ではありません。外部売却を選ばず社内承継へ進む場合にも使えます。選択肢が変わっても残る準備から着手すれば、オーナーは結論を急がず比較しやすくなります。

IT M&Aを検討するオーナーからの具体的な疑問

IT M&Aは少人数の開発会社でも検討できるか

人数だけで可能性は決まりません。少人数でも、顧客との関係が継続し、提供する技術やサービスに再現性があれば検討の材料になります。まず、同じ人数で維持できる売上なのか、オーナーの無償作業や長時間労働が前提なのかを確認します。買い手に不足する技能や顧客接点を補える場合もありますが、その効果は候補先によって異なります。「小さいから評価できない」「少人数だから高収益」と先に結論を置かないことです。

初期資料では総人数に加え、案件を受ける人、見積もる人、実装する人、顧客の問い合わせに答える人を示します。同じ人が兼務している場合も隠す必要はありません。買い手側の管理部門や開発要員と組み合わせれば解消できる不足なのか、退職すると維持できない技能なのかを分けます。売却前に採用人数を増やすべきかは、その人件費を事業で負担できるかも含めて判断し、売却のためだけの採用を先行させません。

赤字のSaaSで開発を続けながら相談できるか

相談に向けては、赤字を一つの数字で説明せず、既存顧客を支える費用と新たな成長のための支出を分けて整理します。開発を止めれば短期の損失が減っても、顧客への約束や製品の安全性を守れなくなるなら、その削減は継続的な改善とはいえません。新機能、保守、基盤更新ごとの目的と残作業を示し、買い手が支出を続けるべき部分を判断できるようにします。何か月の運営資金があるかも同時に確認します。

IT M&Aの価格を考える際には、開発費の会計処理によって利益の見え方が変わる点にも注意します。具体的な整理はソフトウェア開発費と正常収益力の解説を参照できます。オーナーが最初に用意したいのは、製品ごとの開発の目的、支払額、稼働する人、今後の支出予定です。過去の支出額をそのまま製品の売却価格と考えないことが大切です。

創業者しか顧客窓口を持たない場合はどうするか

いきなり担当者を交代させるより、創業者が同席する顧客会議で、次の担当者が案件状況を説明する機会を作ります。顧客が創業者に求めているのが業界知識なのか、決裁の速さなのか、緊急時の連絡なのかを観察します。求められる役割が分かれば、資料で補う部分と権限移譲が必要な部分を分けられます。名刺を交換した回数だけでは承継の進捗にならず、顧客が次の担当者へ実際に相談できるかを確かめます。

顧客の反応が慎重でも、直ちに売却が難しいと決める必要はありません。対応品質への不安なら試行期間を設け、契約上の懸念なら条件を確認し、決裁者が不明なら窓口を整理します。創業者がいつでも最終判断する状態を続けると、次の担当者は育ちません。小さな変更依頼などから回答権限を渡し、重要な決定だけを確認する運用に移します。退任時期は、この試行の結果を見て候補先と調整します。

取引先に知られず候補先を探せるか

初期の候補先探索では、社名を出さず業態、規模、地域などの概要で関心を確認する方法があります。ただし、地方で特定業種向けのシステムを一社だけ提供している場合など、特徴の組合せから会社が推測されることがあります。匿名であることと特定できないことは同じではありません。顧客数、特殊な機能、所在地の粒度などを調整し、必要な魅力が伝わる範囲で情報を限定して進めます。

IT M&Aを最後まで顧客への確認なしで進められるとは限りません。承諾や通知が必要な契約があれば、適切な段階で説明する必要があります。候補先にどこまで情報を開示するかと、顧客へいつ説明するかを別の計画にします。オーナーとして最初に決めたいのは、連絡に使うメールや電話、社内で知る人、問い合わせが来たときの回答者です。秘密保持契約の締結だけに頼らず、日常の連絡経路から管理します。

競合する買い手にソースコードを開示してよいか

買い手の確認目的を先に聞きます。機能の存在を確認したいのか、保守できる技術か判断したいのか、権利や脆弱性を調べたいのかで必要な情報が異なります。最初から全リポジトリを渡す必要があるとは限りません。概要資料、画面説明、管理された環境での確認、対象を限定した専門家の調査などを検討します。顧客データ、秘密鍵、認証情報がコードや設定に含まれていないかも、開示の前に確認します。

開示を進める段階では、閲覧者、目的、複製の可否、保存先、利用期間、検討終了時の扱いを決めます。買い手の全ての開発者が必要とするとは限らず、調査者と営業部門を分ける方法も考えられます。社外に渡す権限を自社が持つかは、顧客や外注先との契約によっても変わります。開示範囲を狭めたことで判断できない点が残る場合は、その不確実性を価格や契約条件でどう扱うかを協議します。

SES案件が多いと売却できないのか

SESという呼称だけでは、提供するサービスも契約上の立場も分かりません。派遣、請負、準委任などの契約と、実際の指揮命令を確認する必要があります。厚生労働省の疑義応答集は、アジャイル開発でも形式ではなく実態で判断すると示しています。一方、対等な協働の下で技術的な助言や情報共有を行うことが、直ちに偽装請負となるわけでもありません。名称で判定せず、案件ごとの運用を整理します。^[32]

IT M&Aの準備では、誰が作業を割り当て、勤務時間を管理し、休暇や交代要員を判断しているかを現場の記録で確かめます。契約書を書き換えるだけで実態の問題が解決するとは限りません。派遣事業の許可や取引方法の変更が関わる場合は、事業形態と手続を個別に確認します。問題が疑われる案件を単に売却対象から外すのではなく、顧客と社員への影響を整理し、是正の進め方を専門家と検討します。

主要エンジニアが退職を希望したら中止すべきか

まず、退職によって何ができなくなるかを特定します。製品の設計判断、顧客との要件整理、障害復旧、特定言語の実装では、補うための時間も方法も違います。退職理由と本人が協力できる範囲を確認し、既存社員への引継ぎ、買い手からの応援、外部支援の可能性を並べます。本人の意思を変えることだけを解決策にせず、退職予定を踏まえても顧客への責任を果たせる体制かを判断します。

買い手への説明も、退職予定の有無だけでは不十分です。引き継げる資料、残る作業、代替者の技能、必要な支援期間をまとめます。そのうえで、当初の候補先が補えるのか、条件の変更で継続できるのか、実行時期を見直すのかを協議します。残留してもらう条件を検討する場合は、本人との合意を尊重し、処遇や役割を具体化します。特定の社員が永久に残る前提で、事業の継続を買い手へ保証しないことが大切です。

外注先との権利契約が古いときは何から直すか

契約の締結日だけを見て一括で作り直すのではなく、現在提供している製品や顧客案件に使われる成果物から確認します。誰が何を作り、どの契約や注文書に基づいて納めたかをたどります。著作権の帰属が曖昧なもの、第三者への提供範囲が狭いもの、再利用の制限があるものを分けます。過去の合意が確認できない場合は、推測した内容を原本に書き加えず、確認できた事実と残る疑問を記録します。

権利者に追加の確認を求める際は、買い手へ渡したい範囲と今後の利用方法を説明できるよう準備します。全権利の譲渡だけが唯一の解決方法とは限らず、必要な利用を認める合意で対応できる場合もあります。一方、確認が取れないとサービス提供が制限されるなら、代替開発の費用や期間が必要になります。どの方法を選ぶかは法務と技術の両面で検討し、権利確認の完了予定を売却日程へ反映します。

個人名義のクラウドやドメインは売却前に移すべきか

まず、個人名義の契約と個人アカウントに付与された管理権限を分けます。会社契約でも創業者だけが復旧用メールを受信していれば、退任後に復旧できないことがあります。逆に名義変更を急いで実行すると、請求、証明書、連携サービスに影響する場合があります。利用規約と変更手順を確認し、承継先の受け皿、作業日、確認者を決めます。単純なパスワードの共有で移管を済ませず、個人に依存しない管理を設計します。

移管前後で確かめたいのは、ログインできるかだけではありません。請求メールが届くか、更新が継続されるか、緊急時にサポートへ連絡できるか、復旧用の認証が使えるかを確認します。ドメインや証明書の期限が近ければ、売却手続と更新作業の順序も検討します。移管によって過去の利用記録や監査情報を失わないよう保存し、旧オーナーの権限を外す時期は、次の管理者が必要な操作を確認した後に調整します。

IT M&A後も顧問として残る条件はどう決めるか

顧問として残るなら、役職名より担当する成果を先に決めます。主要顧客との面談、技術方針の説明、後継者への助言など、依頼する仕事を明らかにします。週の稼働時間、出張、夜間対応、報酬、経費、終了や延長の条件も確認します。株式を全て譲渡しても、無期限の障害対応が残れば実質的な退任になりません。自分が続けられる範囲と、買い手が必要とする支援の範囲を同じ書面で照合します。

残る期間中の判断権限も重要です。旧オーナーと新責任者が異なる指示を出すと、社員はどちらに従うか迷います。顧問は助言し、日常の承認は新責任者が担うなど、連絡の流れを具体化します。個別顧客が旧オーナーへ直接相談した場合の転送先も決めておきます。契約した支援期間の終わりには、未完了の引継ぎを確認し、延長が必要なら理由、追加業務、報酬を改めて協議する方法が考えられます。

売却を決めてから準備を始めても間に合うか

準備の量より、社外の判断を待つ項目がどれだけあるかで日程が変わります。契約承諾、権利者との合意、金融機関の保証審査は、自社だけで期限を確定できません。希望する退任日があるなら、その日までに必要な相手方の回答を先に洗い出します。短期間でも進められる作業はありますが、確認を省略して早めた結果、譲渡後に義務が残ることもあります。急ぐ事情は候補先と支援者へ早い段階で伝えます。

相談前の準備に時間を使い過ぎる必要もありません。特に運転資金が限られる場合や、主要人材の退職が迫る場合は、資料の完成を待つ間にも選択肢が変わります。足りない資料は何か、何日で集められるかを示せば、進め方を検討できます。取引を急ぐ費用やリスクと、保有を続ける負担を比べます。希望日だけを約束して顧客対応や社員説明を後回しにせず、実行可能な日程へ調整することが必要です。

IT M&Aの初回相談には何を伝えればよいか

最初は事業の種類、概算の売上と利益、社員数、主な収益の仕組み、売却を考える理由を整理すると話を進めやすくなります。正確な評価額が分からなくても構いません。退任したい時期、守りたい顧客対応、社員の処遇、自分が残れる期間など、価格以外の希望も伝えます。未整理の論点がある場合は「契約の確認が必要」「保証条件が未確認」と分け、確認済みであるかのように説明しないことが大切です。

初回から本番環境の認証情報や顧客の個人データを送る必要はありません。どの資料を何のために使い、誰に開示するかを確認してから詳細を共有します。支援者には候補先の探し方だけでなく、取引方法の比較、顧客承諾、保証解除、技術支援の条件を誰が担当するかも確認します。相談の結果として、売却へ進む、準備を続ける、別の承継を検討するという複数の判断ができるよう、まだ決めていない希望も伝えておきます。

IT M&Aの相談前に、残したい事業と手放したい役割を整理する

相談の段階で「いくらなら売る」と決め切る必要はありません。技術者の働き方、顧客へのサービス、製品名や開発方針など、守りたい条件を挙げると候補先を考えやすくなります。一方で、採用、資金調達、夜間の判断、営業の最終責任のうち、何から離れたいのかも具体化します。同じ会社でも、オーナーが経営から退く案と、技術や営業に役割を絞って残る案では、望ましい相手が変わります。

最初に揃える資料は、直近の決算と月次推移、業態別の売上・粗利、主な顧客契約の更新時期、開発・運用を支える人材、借入と個人保証の概要です。詳細が未確認なら、その旨を記して構いません。顧客名やソースコードまで初回から共有する必要はなく、開示する相手と範囲を決めながら説明を深めます。準備の目的は資料の量を増やすことではなく、どの条件なら事業を安心して渡せるかを判断できるようにすることです。

参考文献・公表資料

2026年9月14日に確認した公表資料です。統計の対象時点、取引の発表日・実行日、その後の組織変更を区別しています。制度や継続更新されるページについては、実際の検討時点の掲載内容も確認してください。

1. 総務省統計局「サービス産業動態統計調査 2026年6月分速報」。公表日：2026-08-24。対象：2026年6月。
2. 総務省統計局「サービス産業動態統計調査 用語の解説・利用上の注意」。2026年9月14日掲載版を確認。対象：定義・調査変更に関する説明。
3. 情報処理推進機構（IPA）「DX動向2026」。公表日：2026-07-30。対象：2026年実査、報告書の呼称は2025年度調査。
4. 総務省「令和7年通信利用動向調査の結果（概要）」。公表日：2026-05-29。対象：2025年8月末。
5. 情報処理推進機構（IPA）「2025年度ソフトウェア・モダナイゼーション委員会報告書」。公表日：2026-03-24。対象：2025年度委員会活動。
6. 情報処理推進機構（IPA）「情報セキュリティ10大脅威2026」。公表日：2026-01-29。対象：2025年発生事案を基に選定。
7. 日立製作所「日立がデジタルエンジニアリングサービスのリーディングカンパニー 米国GlobalLogic社を買収」。公表日：2021-03-31。
8. 日立製作所「日立が米国GlobalLogic社の買収を完了」。公表日：2021-07-14。
9. 日立製作所「Lumada 3.0のグローバル成長加速に向け、GlobalLogicとHitachi Digital Servicesを統合」。公表日：2026-01-29。
10. クレスコ「第34期 有価証券報告書」。公表日：2022-06-20。
11. クレスコ「沿革」。2026年9月14日掲載版を確認。
12. クレスコ「2022年3月期 第1四半期 決算短信〔日本基準〕（連結）」。公表日：2021-08-06。
13. アクシス「株式会社ヒューマンソフトの株式取得（子会社化）に関するお知らせ」。公表日：2021-03-15。
14. アクシス「2021年12月期 決算短信〔日本基準〕（連結）」。公表日：2022-02-10。
15. アクシス「第33回定時株主総会招集ご通知」。公表日：2024-03-04。
16. SHIFT「株式会社A-STARの株式取得（子会社化）に関するお知らせ」。公表日：2021-03-29。
17. SHIFT「A-STARとの合併契約締結に関するお知らせ」。公表日：2023-12-22。
18. freee「税理士向けサービスのMikatus株式会社、freeeグループジョインのお知らせ」。公表日：2022-05-09。
19. freee「2022年6月期 決算短信〔日本基準〕（連結）」。公表日：2022-08-12。
20. freee「Mikatus社、freeeグループへの参画完了のお知らせ」。公表日：2022-06-30。
21. freee「第11期定時株主総会招集ご通知」。2026年9月14日掲載版を確認。
22. マネーフォワード「HiTTO株式会社の株式の取得（完全子会社化）に関するお知らせ」。公表日：2021-11-30。
23. マネーフォワード「2021年11月期 決算短信〔日本基準〕（連結）」。公表日：2022-01-14。
24. マネーフォワード「Forward Map 2024（経営計画）」。公表日：2024-04。
25. 厚生労働省「事業譲渡等指針の一部改正について」。2026年9月14日掲載版を確認。
26. IPA「情報システム・モデル取引・契約書（第二版）」。2026年9月14日掲載版を確認。
27. 文化庁「著作権テキスト令和8年度版」。2026年9月14日掲載版を確認。
28. 経済産業省「SBOM導入の手引ver2.0の公表」。2026年9月14日掲載版を確認。
29. 個人情報保護委員会「Q7-53 クラウドサービス利用と個人データ」。2026年9月14日掲載版を確認。
30. 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」。2026年9月14日掲載版を確認。
31. 中小企業庁「中小M&Aガイドライン（第3版）」。2026年9月14日掲載版を確認。
32. 厚生労働省「37号告示に関する疑義応答集（第3集）」。2026年9月14日掲載版を確認。