想定事例について：公開情報にみられる取引類型と歯科M&Aの一般的な実務論点を基に再構成した想定事例です。特定の企業・医療法人・取引を示すものではありません。
本記事では、歯科医院向けの業務支援サービスを提供する会社を、複数の歯科事業を展開するデンタルグループが買収するケースを想定します。実在する会社の買収実績ではありません。顧客契約、継続課金、解約率、知的財産、ソースコード、クラウド環境、従業員、外部委託、情報セキュリティ、販売チャネル、買収後の統合といった、サービス会社のM&Aで中心となる論点を整理します。
歯科関連サービス会社は歯科業界を顧客としていても、歯科医院そのものではありません。その価値を診療所の設備や診療実績で評価するのではなく、契約収益の持続性、サービスを提供し続ける組織・技術、顧客との関係、法令・契約に適合したデータ管理を確認する必要があります。本想定事例でも、医院承継の論点とサービス会社買収の論点を明確に分けます。
想定する会社と取引の前提
売り手は、歯科医院向けにクラウド型の業務支援サービスと導入支援を提供する非上場会社とします。収益は月額利用料、初期導入料、追加サポート料で構成され、営業、カスタマーサクセス、開発、運用を少人数で担っています。創業者が商品企画と主要顧客との関係を主導しており、組織の属人性が課題になっているという設定です。
買い手は、歯科医院の運営に加えて、教育、採用、購買等の周辺事業を持つデンタルグループとします。グループ内での利用だけでなく、外部顧客へのサービス提供を継続し、製品開発と販売網を強化したい考えです。一方、買い手が自ら顧客と競合するように見える場合、既存顧客が情報利用や中立性へ不安を持つ可能性があります。
| 項目 | 想定設定 | 確認する論点 |
|---|---|---|
| 事業 | 歯科医院向けクラウドサービス | 収益モデル、継続率、提供範囲 |
| 顧客 | 単院、医療法人、関連事業者 | 契約、集中度、解約、販売経路 |
| 技術 | 自社開発と一部外部委託 | 知的財産、ソースコード、依存サービス |
| 人員 | 営業、カスタマーサクセス（CS）、開発、運用 | キーパーソン、雇用、採用、引継ぎ |
| データ | 顧客アカウントと利用ログ | 利用目的、権限、保管、委託 |
| 買い手 | 複数事業を持つデンタルグループ | 中立性、情報遮断、統合方針 |
買収を検討する目的を具体化する
買い手が「デジタル事業を強化したい」と述べるだけでは、買収後の判断基準が定まりません。本想定事例では、第一にグループ内の業務改善、第二に外部顧客向け事業の成長、第三に開発人材と運用ノウハウの獲得という三つの目的を設定します。目的ごとに必要な資産、投資額、統合範囲を分けます。
グループ内利用を優先しすぎると、外部顧客への開発やサポートが後回しになり、解約につながる可能性があります。反対に、外販の成長だけを重視すれば、グループ内で想定した業務改善が実現しないかもしれません。買収前に、製品ロードマップ、予算配分、顧客セグメント、意思決定者を定めます。
売り手側も、創業者の引退、成長投資の確保、採用力の強化、顧客への長期提供など、譲渡目的を整理します。希望対価だけでなく、ブランドを残すか、従業員をどう扱うか、創業者がどの期間・役割で残るか、既存顧客への約束を何にするかを優先順位にします。
株式譲渡と事業譲渡を比較する
株式譲渡では、対象会社の株主が変わる一方、会社が締結している契約や雇用関係は原則として会社に残ります。ただし、顧客契約やクラウド利用契約に支配権変更時の通知・承諾条項がある場合は対応が必要です。また、過去の債務や法令違反リスクも会社に残るため、デューデリジェンスが重要になります。
事業譲渡では、対象事業に必要な契約、知的財産、従業員、データ、設備等を個別に移転します。不要な事業やリスクを切り分けやすい反面、顧客・ベンダーの承諾や雇用手続きが増え、サービスを止めない移行計画が必要です。
どちらを選ぶかは、対象会社の事業構成、契約、許認可、税務、偶発債務、買い手の統合方針によって異なります。本想定事例では株式譲渡を基本案としますが、スキームを決め打ちせず、弁護士・税理士等の専門家と比較します。
継続課金と収益の質を確認する
月額課金があるだけで安定収益と評価することはできません。月次経常収益（MRR）・年次経常収益（ARR）の定義、有料アカウント数、平均単価、割引、無料期間、解約、休止、返金、未収、契約期間を確認します。売上計上のルールと契約内容が一致しているかも点検します。
解約率は集計方法で見え方が変わります。顧客数ベース、売上ベース、月次、年次、総解約、アップセル・ダウンセルを含むネットリテンションを分けます。直近の平均値だけでなく、導入時期別、顧客規模別、販売チャネル別のコホートを見ると、サービスの定着度を把握しやすくなります。
初期導入料や個別開発が売上の大きな割合を占める場合、その売上が毎年再現するとは限りません。継続課金、単発売上、受託開発、代理店手数料を分け、粗利と必要工数を確認します。買収後の成長計画は、契約数だけでなくサポート能力と開発能力を踏まえて作ります。
収益分析で確認する指標
- MRR、ARR、有料顧客数、平均単価
- 新規契約、解約、休止、アップセル、ダウンセル
- 売上総利益率、クラウド原価、サポート工数
- 顧客獲得費用、回収期間、販売チャネル別効率
- 上位顧客への売上集中度
- 契約期間、更新率、未収、返金、値引き
顧客契約と中立性を確認する
顧客契約では、サービス範囲、料金、更新、解約、サービス水準合意（SLA）、損害賠償、データ、再委託、知的財産、支配権変更、譲渡禁止を確認します。申込書、利用規約、個別見積り、営業担当者のメールで条件が異なっていないかも点検します。
買い手が歯科医院を運営している場合、外部顧客は自社の利用状況や業務情報が競合するグループへ共有されるのではないかと懸念する可能性があります。本想定事例では、対象会社を独立運営し、顧客データへのアクセスを業務上必要な担当者へ限定する設計とします。グループ会社へのデータ共有を当然の前提にしません。
買収公表前後の顧客コミュニケーションでは、サービス継続、契約、価格、サポート窓口、データ利用、中立性を説明します。「何も変わらない」と断定せず、決定済み、検討中、変更予定なしを区別します。主要顧客には契約上の通知・承諾と営業上の説明を分けて対応します。
顧客集中と販売チャネル
上位数社への売上依存が高い場合、一社の解約が事業価値へ大きく影響します。売上集中度だけでなく、契約期間、利用部門、担当者との関係、競合製品、更新見込みを確認します。ただし更新を確実なものとして扱わず、複数のシナリオで計画します。
代理店、紹介会社、業界団体、メーカー等を通じて販売している場合、紹介契約、手数料、顧客帰属、競業、解約後の取扱いを確認します。営業担当個人の関係に依存しているチャネルは、買収後も継続できるとは限りません。
マーケティングでは、ウェブサイト、ドメイン、広告アカウント、メール配信、ウェビナー、資料、SNSの所有者と管理者権限を点検します。個人アカウントや代理店名義になっている場合は、移管可否と代替策を確認します。
知的財産と開発資産
サービス名称、ロゴ、ドメイン、ソフトウェア、画面デザイン、マニュアル、営業資料等について、対象会社が必要な権利を持つか確認します。創業者、従業員、外部開発会社が作成した成果物の権利帰属が契約で明確になっているかを点検します。
ソースコードがリポジトリで管理されていても、すべてが自社所有とは限りません。オープンソースソフトウェア、商用ライブラリ、外部システム連携（API）、テンプレート、画像・フォント等のライセンス条件を確認します。買収や再配布で条件が変わるサービスもあります。
技術デューデリジェンスでは、コード品質だけでなく、設計資料、テスト、リリース手順、障害対応、バックアップ、監視、開発環境、管理者権限を確認します。特定の開発者しか本番環境を変更できない状態は、継続性のリスクになります。
クラウド環境と外部ベンダーへの依存
インフラ、データベース、認証、決済、メール配信、分析、チャットサポートなど、多数の外部サービスを利用している場合があります。契約名義、料金プラン、管理者、二要素認証、請求先、利用規約、データ保存地域、解約時のデータ取得を一覧化します。
一社のクラウドや外部APIに強く依存している場合、値上げや仕様変更が粗利とサービス継続へ影響します。代替可能性、移行工数、停止時の運用、ベンダーのサポート条件を確認します。買収後にグループ標準環境へすぐ移すのではなく、リスクと顧客影響を評価します。
外部開発会社やフリーランスが重要部分を保守している場合、契約期間、再委託、秘密保持、成果物、引継ぎ義務、単価、継続意向を確認します。担当者の協力を前提にした計画には、代替人員と資料化を組み込みます。
個人情報・顧客データの管理
対象会社が扱うデータの種類、取得元、利用目的、保存場所、閲覧者、第三者提供、委託、保存期間、削除方法をデータマップにします。顧客企業の担当者情報、利用ログ、問い合わせ内容、決済情報などを区別します。予約等の機能を通じて患者様に関する情報を扱う場合は、要配慮個人情報に該当し得る情報を含むかも確認します。
プライバシーポリシーや利用規約に書かれている内容と、実際のシステム・業務が一致しているかを点検します。アクセス権限が広すぎる、退職者アカウントが残る、テスト環境へ実データを複製する、外部委託先の管理が不明確といった問題は、買収前後の是正計画に反映します。
株主が変わることを理由に、グループ各社がデータを自由に利用できるわけではありません。利用目的、契約、法令、顧客への説明を確認し、必要に応じて情報遮断と承認手続きを設けます。デューデリジェンス時のデータ閲覧も、集計・匿名化・マスキングを優先します。
情報セキュリティと事業継続
セキュリティ確認では、アカウント管理、権限、二要素認証、脆弱性対応、ログ、バックアップ、暗号化、端末、インシデント対応を点検します。認証規格や診断結果がある場合も、取得時点や対象範囲を確認し、運用実態を別途見ます。
障害履歴は、発生日時、影響範囲、原因、復旧時間、顧客連絡、再発防止を確認します。障害があったこと自体より、記録がなく原因を説明できないことや、同じ障害を繰り返していることが大きなリスクになります。
事業継続計画では、主要担当者の不在、クラウド停止、サイバー攻撃、データ破損、自然災害を想定します。復旧時間と復旧時点の目標、代替連絡、手動運用、顧客への告知を定めます。買収直後は権限変更が集中するため、変更管理を強化します。
従業員と組織の承継
サービス会社の価値は、開発者、カスタマーサクセス、営業、運用担当の知識に大きく依存します。組織図だけでなく、担当業務、顧客関係、システム権限、代替可能性、退職意向を確認します。個人情報の開示は必要最小限にし、説明時期を管理します。
株式譲渡で雇用主が変わらない場合でも、評価制度、報告先、働き方、製品方針が変わる不安があります。買い手は買収目的、組織方針、維持する制度、検討中の事項、問い合わせ窓口を説明します。曖昧な将来保証や過度な残留圧力は避けます。
創業者の残留は、期間、役割、権限、評価指標、競業、知的財産、退任条件を明確にします。創業者がすべての製品判断と主要顧客対応を続ける前提では、組織化が進みません。段階的に責任を移し、複数の管理者を育てます。
財務・税務デューデリジェンス
決算書、申告書、総勘定元帳、月次推移、売掛金、前受収益、未払費用、借入、補助金、固定資産、資本化した開発費を確認します。継続課金の契約期間と売上計上、初期費用、返金、無料期間が会計処理と整合しているかを見ます。
正常収益力の検討では、創業者報酬、一時的な開発投資、外注費、採用費、クラウド割引、関連当事者取引を調整します。買収後に必要となるセキュリティ、管理、人材投資を差し引かずに将来利益を見積もらないようにします。
税務上の繰越欠損金、消費税、源泉、ストックオプション、株主間取引等は、スキームにより取扱いが変わります。買収価格と税引後手取りを同じものと捉えず、税理士と確認します。
法務デューデリジェンス
定款、登記、株主名簿、株主間契約、取締役会・株主総会議事録、資本政策、ストックオプション、重要契約、訴訟・苦情を確認します。株式の権利関係や譲渡承認手続きを早めに整理します。
顧客・代理店・ベンダー・業務委託・雇用・賃貸借の契約を重要度で分類します。支配権変更、譲渡禁止、最低利用、独占、競業避止、保証、損害賠償、準拠法を確認し、同意取得がクロージング条件になるかを判断します。
広告表示、営業資料、導入効果の表現、知的財産侵害、個人情報事故、クレーム履歴も確認します。売り手の説明だけでなく、契約書、チケット、社内記録等の証憑と照合します。
価格と条件の設計
サービス会社の評価では、収益倍率、利益倍率、割引キャッシュフロー法（DCF）等の考え方が用いられる場合がありますが、一つの指標だけで価格が決まるわけではありません。成長率、継続率、粗利、顧客集中、技術負債、人材、必要投資、競争環境を反映して交渉します。
対価の一部を将来業績に連動させる場合、ARR、売上、粗利、顧客数等の定義を明確にします。買い手が価格、販売、投資を変更できるため、測定期間中の運営ルール、情報閲覧、会計方針、紛争解決も定めます。売り手が制御できない指標へ過度に依存しないよう専門家と設計します。
価格以外に、従業員の処遇、創業者の役割、ブランド、開発ロードマップ、既存顧客への提供、情報遮断、オフィス、外部委託の継続を条件化します。意向表明書と基本合意の段階から、金額と非金銭条件を並べて比較します。
買収後100日の統合計画
クロージング前
顧客通知、従業員説明、権限変更、銀行・決済、契約同意、広報、問い合わせ窓口を準備します。機密性を保ちながら、初日に必要な担当者だけを統合準備へ参加させます。
初日から30日
サービスの安定運用と顧客対応を最優先にします。組織変更、価格改定、システム移行を同時に行わず、障害、解約、問い合わせ、従業員負荷を日次で確認します。重要なアクセス権限とバックアップを再点検します。
31日から100日
製品ロードマップ、販売チャネル、採用、開発体制、セキュリティ改善を優先順位づけします。グループ内導入は外部顧客向けの運用を圧迫しない範囲で進め、利用目的とデータアクセスを分けます。
100日以降
統合効果を、売上だけでなく解約率、サポート応答、障害、開発速度、従業員定着、顧客満足で評価します。当初仮説と実績の差を振り返り、投資計画を更新します。
サービス会社M&Aで起こりやすい失敗
月額売上をすべて安定収益とみなす
無料期間、値引き、短期解約、未収、個別開発を分けないと、収益の質を誤ります。契約と請求データを突合し、コホート別に確認します。
創業者が残れば引継ぎできると考える
属人性を残したままでは、退任時に再びリスクが表面化します。権限、顧客関係、製品判断、技術知識を複数人へ移します。
グループ統合を急ぎすぎる
ドメイン、クラウド、認証、組織を一度に変えると障害と顧客不安が増えます。依存関係を確認し、段階的に移行します。
顧客データをグループ資産として自由に使う
利用目的、契約、法令を無視した共有は信頼を損ないます。アクセス制御と情報遮断を設け、必要な説明・手続きを行います。
重要業績評価指標（KPI）と会計数値を照合する
経営資料に記載されたARRや解約率が、請求・入金・会計と一致するかを確認します。本想定事例では、顧客ID、契約開始日、プラン、月額、割引、請求、入金、解約日を結び付け、サンプルだけでなく全体の整合を検証する設計とします。KPIの定義変更があった場合は、期間をまたいだ比較ができるよう注記します。
営業管理ツールと会計システムで顧客名や金額が異なることがあります。代理店経由、複数拠点契約、無料アカウント、テスト契約を区別し、重複計上を除きます。ダッシュボードの数字だけを受け取らず、元データから再計算できる状態にします。
買収後のモニタリング指標も契約前に決めます。売上、粗利、解約だけでなく、サポート応答、障害、開発リードタイム、従業員定着を確認します。数字を増やすために定義を変えないよう、計算式とデータソースを文書化します。
営業パイプラインと受注見込み
商談一覧には、顧客、案件規模、段階、次の行動、受注予定日、失注理由を記録します。ただし営業担当者の主観的な確度を、そのまま将来売上として評価しません。契約書の締結、予算承認、試用、セキュリティ審査など客観的な段階へ置き換えます。
大型案件が買収価格の前提になっている場合は、その案件が失注・延期したシナリオも作ります。受注後に導入支援や個別開発が集中する場合、売上が増えても人員不足で既存顧客対応が悪化する可能性があります。営業計画と提供能力を同じ表で確認します。
製品ロードマップと技術的負債
今後の機能一覧だけでは、開発の実現性を判断できません。顧客要望、法令対応、障害対策、保守、基盤更新を分類し、担当者、工数、依存関係を確認します。創業者の口頭判断だけで優先順位が変わる場合は、意思決定プロセスを整えます。
技術的負債には、古いライブラリ、テスト不足、手作業のリリース、担当者しか分からない構成、容量不足などがあります。すべてを買収前に解消する必要はありませんが、事業継続へ影響する項目と改善費用を見積もり、価格・投資計画へ反映します。
買い手の既存システムとの連携をシナジーとして見込む場合は、API、認証、データモデル、セキュリティ基準を確認します。「技術的に連携できる」と「短期間・低コストで本番運用できる」は異なります。
カスタマーサクセスとサポートの承継
問い合わせ件数だけでなく、内容、優先度、初回応答、解決時間、再発、担当者を確認します。解決済みに見えても、同じ不具合を顧客ごとに個別対応している場合は製品課題が残っています。チケット、電話、個人メールなど窓口が分散していないかも見ます。
導入支援の手順、研修資料、権限設定、データ移行、利用定着の確認を整理します。特定担当者が顧客ごとの設定を暗記している状態では、担当変更で品質が下がります。顧客別の注意事項は、必要な権限と目的に限定して管理します。
買収後に窓口や担当者を変更する場合は、顧客へ事前に案内し、旧窓口からの転送期間を設けます。グループ内の一般窓口へ統合して専門性が失われないよう、一次対応と製品専門対応を分けます。
価格体系と個別条件を整理する
標準料金表があっても、創業期の値引き、無期限割引、無償オプション、個別開発、代理店経由など、顧客ごとに条件が異なる場合があります。契約単価だけでなく、提供工数と粗利を確認し、将来の価格改定が必要な顧客を把握します。
買収直後の一律値上げは、顧客離反とブランド毀損につながる可能性があります。契約上の改定手続き、提供価値、競合価格、顧客への移行期間を確認します。既存顧客と新規顧客で料金を分ける場合は、運用負荷と説明可能性を検討します。
競争環境と市場での位置づけ
競合比較では機能数だけでなく、対象顧客、導入時間、サポート、価格、連携、セキュリティ、解約理由を見ます。自社に都合のよい比較表だけに依存せず、失注記録や顧客ヒアリングから選ばれる理由と選ばれない理由を整理します。
買い手グループの販売網を使えば自動的に成長するとは限りません。グループと関係のない顧客が中立性を懸念する場合もあります。販売先をグループ内、提携先、外部市場に分け、ブランドと営業体制を設計します。
カーブアウトと移行支援が必要な場合
対象事業が売り手の他事業と共通の会計、メール、クラウド、オフィス、従業員を使っている場合、事業譲渡では切り離し計画が必要です。どのサービスをいつまで共用し、誰が費用を負担し、どの基準で終了するかを移行支援契約で定めることがあります。
移行期間が短すぎるとサービス停止の危険があり、長すぎると売り手への依存が残ります。アカウント、データ、契約、請求、サポートをワークストリームに分け、完了条件を具体化します。売り手環境からのデータ削除とバックアップの取扱いも確認します。
買収後のガバナンスと意思決定
対象会社を独立運営する場合も、予算、採用、価格、製品、セキュリティ事故について、誰が決裁するかを定めます。すべてを買い手本部承認にすると開発速度が落ち、すべてを旧経営陣へ委ねると統制が効かない可能性があります。
取締役会・経営会議の頻度、報告KPI、投資基準、関連当事者取引、グループ内データ共有の承認を決めます。シナジーを理由に対象会社へ不利なグループ取引を押し付けないよう、価格と意思決定を記録します。
専門家と調査チームの役割
サービス会社のM&Aでは、財務・税務・法務に加え、技術、情報セキュリティ、個人情報、知的財産、人事の専門性が必要です。各チームが同じ質問を重ねないよう、論点、資料、担当、結論を一つの台帳で管理します。
技術的に可能でも契約上認められない、法的に可能でも顧客説明上のリスクが高い、といった論点があります。専門家の回答を個別に並べるだけでなく、買収価格、契約条項、100日計画へどのように反映したかを確認します。
サービス会社の案件設定を詳細化する
本想定事例の対象会社は、歯科医院の予約・問い合わせ・院内業務を支援するクラウドサービスと、導入時の設定・研修を提供している設定です。顧客は単院、複数院を運営する医療法人、歯科関連企業に分かれます。製品はウェブアプリ、管理画面、通知、外部連携で構成され、一部の開発・監視を外部ベンダーへ委託しています。
従業員は、営業、カスタマーサクセス、開発、インフラ運用、管理で構成されます。創業者が製品責任者と主要営業を兼ね、技術責任者が本番環境の重要権限を持つため、二人の継続と権限移管が中心的な課題です。
買い手はグループ内に複数の歯科関連事業を持ちますが、対象会社の外部顧客への中立性を維持する方針とします。買収後も対象会社を独立法人として運営し、顧客データへのアクセスを対象会社の担当者へ限定することを基本案にします。
ビジネスモデルを収益源別に分解する
月額利用料、初期導入料、オプション、個別開発、研修、代理店経由売上を分けます。同じ顧客からの売上でも、継続性、粗利、必要人員が異なります。月額売上に一時的な設定費を混ぜず、契約と請求項目を突合します。
利用量に応じた従量課金がある場合は、単価、最低料金、上限、季節変動を確認します。外部APIやメール送信等の原価も利用量に応じて増えるため、増収が同じ割合で利益になるとは限りません。
個別開発は顧客獲得へ有効でも、標準製品の複雑化と保守負担につながります。案件別に売上、外注、社内工数、再利用可能性を見て、製品売上と受託売上を区別します。
顧客セグメント別の採算
単院顧客、医療法人、関連企業では、単価、導入期間、問い合わせ、解約理由が異なります。売上だけでなく、営業工数、設定、サポート、クラウド原価を配賦してセグメント別の粗利を確認します。
大口顧客は単価が高くても、個別機能、専任サポート、長いセキュリティ審査が必要な場合があります。小規模顧客は一社当たり売上が低くても、標準化されたセルフサービスで高い粗利を得られる可能性があります。
買い手の成長計画では、どのセグメントを優先するかを定めます。すべての顧客へ同じ機能とサポートを提供する計画は、組織能力と整合しない可能性があります。
契約収益の元データを作る
顧客ID、契約主体、プラン、利用拠点、開始日、更新日、月額、割引、オプション、請求周期、支払方法、解約日を一行で追えるデータを作ります。請求システム、営業管理、会計で顧客名称が異なる場合は共通IDで結びます。
一つの医療法人が複数拠点を契約している場合、法人一社と拠点数を区別します。無料の検証環境、デモ、休止、未収を有料稼働へ含めません。買収候補へ提示するKPIの定義を資料へ明記します。
データは特定時点のスナップショットだけでなく、月次推移を作ります。契約開始と解約が同じ月に集中していないか、価格改定やキャンペーンで一時的に数字が膨らんでいないかを確認します。
MRRとARRの定義を統一する
MRRへ年額契約を月割りで含めるか、従量課金、初期費用、個別開発を除くかを決めます。ARRは単純に最新MRRを十二倍する方法と、契約済み年額を積み上げる方法で差が出ることがあります。
買い手と売り手が異なる定義を使うと、価格調整やアーンアウトで紛争になります。定義、対象、為替、税込・税抜、休止、未収、値引きを契約別紙に記載します。
ARRを将来売上の保証として扱いません。途中解約、更新拒否、利用縮小があり得るため、契約条項と過去継続率を併せて評価します。
解約率を複数の角度で測る
顧客数ベースのロゴチャーン、売上ベースのグロスレベニューチャーン、アップセルを含むネットレベニューリテンションを分けます。月初と月末のどちらを母数にするか、休止を解約へ含めるかも定義します。
導入後三か月以内の解約が多い場合、営業時の期待と製品体験が合っていない可能性があります。長期顧客の解約が増えている場合は、競合、価格、機能、サポートの変化を調べます。
解約理由は選択式だけでなく、解約面談、サポート記録、利用ログと照合します。「経営都合」と分類されていても、利用定着不足が背景にある場合があります。
コホート分析で定着を確認する
契約開始月ごとに、三か月、六か月、十二か月後の残存率と売上を見ます。古い顧客が残っている一方、新しい顧客の解約が多ければ、最近の販売対象や導入方法に課題がある可能性があります。
代理店別、プラン別、顧客規模別にも比較します。ただし母数が少ないコホートを一般化せず、件数と期間を併記します。
買収後のシナジーを見込む際は、既存コホートとグループ紹介顧客を分けます。グループ内導入を外部市場での製品適合性の証明として扱いません。
顧客獲得費用と回収期間
広告、展示会、代理店手数料、営業人件費、無料トライアル、導入支援を含めて顧客獲得費用を算定します。費用を支出月だけでなく獲得した顧客へ合理的に配賦します。
顧客生涯価値は粗利と継続を前提に計算し、楽観的な解約率だけを使いません。顧客獲得費用の回収期間が長い場合、成長するほど運転資金が必要になります。
買い手の販売網で獲得費用が下がる仮説は、紹介可能件数、営業人員、成約率を検証します。買収前の計画書にシナジーの責任者と期限を記載します。
導入プロセスの容量を測る
受注後の設定、データ取込、研修、稼働確認に必要な日数と担当工数を測ります。営業が多数受注しても導入担当が不足すれば、稼働開始と売上計上が遅れます。
顧客側の準備遅れと対象会社側の遅れを区別し、停滞案件を可視化します。個別設定が多い場合は標準テンプレートと例外承認を設けます。
買収後にグループ内へ一斉導入する場合、外部顧客の導入を圧迫しない人員計画を作ります。
サポート原価とサービスレベル
問い合わせ件数、顧客数、プラン、チャネル、優先度、解決時間を分析します。電話、メール、チャット、個人連絡へ分散している場合は、すべての実績を集約します。
SLAを契約している顧客について、応答・復旧実績を確認します。達成率の計算で営業時間外や特定案件を恣意的に除外していないかを見ます。
買収後にサポート窓口を統合する場合、製品知識を持つ二次対応を残します。一次対応のコスト削減だけで顧客の解決時間が延びないようにします。
アップセルとダウンセルを区別する
拠点追加、上位プラン、オプション、利用量増加をアップセルとして分けます。価格改定による増収と顧客の利用拡大を同じ成長として扱いません。
下位プランへの変更、拠点減少、オプション解約をダウンセルとして記録します。完全解約だけを見ると顧客満足低下を見逃す可能性があります。
買い手のクロスセル計画は、顧客同意、営業負担、ブランド中立性を確認します。対象会社の顧客情報をグループ営業へ無断で渡す前提にしません。
代理店・紹介チャネルの経済性
チャネルごとに紹介料、継続手数料、最低件数、独占、顧客帰属、解約後支払を確認します。売上総額だけでなく手数料控除後の粗利を比較します。
主要代理店一社へ依存している場合、契約更新と担当者関係がリスクになります。買収による支配権変更を理由に契約が見直されないかを事前に確認します。
代理店へ顧客データを共有する範囲と根拠も点検します。営業便宜のためにサービス利用情報を過度に共有しません。
製品アーキテクチャを可視化する
利用者画面、管理画面、API、データベース、認証、決済、通知、分析、監視の関係を図にします。各構成要素の責任者、提供会社、障害時影響を記載します。図が古い場合は本番環境と照合します。
単一障害点を特定します。一つのアカウント、一台のサーバー、一人の担当者に依存している場合、代替と権限移管を計画します。
買い手の技術チームが設計を理解できるよう、コードだけでなく運用、リリース、復旧を説明します。
ソースコードリポジトリの確認
リポジトリ、ブランチ、レビュー、アクセス権限、退職者アカウントを確認します。本番コードがリポジトリ外の端末だけに存在していないかを点検します。
コミット履歴から開発が特定人物へ集中しているか、重要変更がレビューされているかを見ます。個人の生産性を単純比較せず、組織継続のリスクを確認します。
買収前の閲覧では営業秘密を含むため、技術専門家の範囲を限定し、コピー・利用を制限します。
オープンソースライセンス
使用ライブラリとバージョンを一覧化し、許諾条件、表示義務、ソース開示義務、商用利用を確認します。依存関係のさらに下位にあるライブラリも可能な範囲で把握します。
ライセンス違反が疑われる場合は、代替、更新、表示、専門家確認を行います。問題を価格だけへ反映し、違反状態を継続しません。
外部APIとプラットフォーム依存
予約、決済、メール、SMS、地図、認証等のAPIについて、契約、単価、制限、停止条件、支配権変更を確認します。提供会社の仕様変更で主要機能が止まる可能性を評価します。
APIキーの保存、権限、ローテーションを点検します。開発者個人の契約やカードで支払われているサービスは、法人名義へ移します。
クラウド原価の構造
計算資源、保存、転送、バックアップ、監視、外部サービスを分け、顧客数・利用量との関係を確認します。一時的な割引やクレジットで原価が低く見えていないかを見ます。
顧客増加シナリオで容量と費用を試算します。単価が増収より速く上がる部分があれば、設計改善または価格体系へ反映します。
可用性と障害履歴
稼働率の定義、計測方法、除外時間を確認します。計画停止をすべて除外して高い数字を示すのではなく、顧客が利用できなかった時間を把握します。
重大障害について、検知、影響、原因、復旧、顧客連絡、再発防止を確認します。同じ根本原因が残っている場合は投資計画へ入れます。
バックアップと復旧テスト
取得頻度、保存場所、暗号化、保持期間、権限を確認します。バックアップが存在するだけでなく、実際に復元できるか定期テストの記録を見ます。
復旧時間目標と復旧時点目標を事業影響に合わせて定めます。買収直後に設定変更を行う前に、復旧可能な状態を確認します。
脆弱性管理
依存ライブラリ、OS、クラウド設定、アプリケーションの脆弱性をどのように検知・優先付けしているかを確認します。診断報告書がある場合は対象範囲と未対応項目を見ます。
重大度だけでなく、外部公開、扱うデータ、悪用可能性を考慮します。買収前に修正するもの、クロージング条件、PMIで対応するものへ分類します。
認証・アクセス権限
顧客管理、開発、本番、クラウド、サポートの権限を職務別に確認します。全従業員が本番データを閲覧できる状態や、共有管理者IDを是正します。
入社、異動、退職時の権限変更を手順化します。買収日に一斉変更して業務を止めず、必要な権限と停止時期を計画します。
ログと監査証跡
顧客データへの閲覧、設定変更、エクスポート、管理者操作を記録できるかを確認します。ログの保存期間、改ざん防止、閲覧権限を定めます。
事故調査に必要なログが短期間で消える場合、保存費用とプライバシーを考慮して改善します。目的なく無期限に保存しません。
データマップを作成する
入力元、データ項目、保存先、利用目的、閲覧者、外部提供、委託、保存期間、削除を一覧化します。顧客担当者情報、サービス利用ログ、問い合わせ、決済等を分けます。
患者様に関する情報を扱う機能がある場合、その内容と流れを特に確認します。対象会社がデータ処理者として顧客の指示で扱うのか、自ら利用目的を決めるのかを契約と実態で整理します。
プライバシーポリシーと実態の一致
取得情報、利用目的、第三者提供、委託、Cookie、開示請求について、公開文書とシステムを照合します。買収前後で新しいグループ利用を追加するなら、既存目的の範囲内かを法務確認します。
文書を買収日に形式的に書き換えるだけでなく、必要な通知・同意、システム権限、社内教育を実施します。
データ処理契約と委託先管理
顧客とのデータ処理条件、外部ベンダーへの再委託、事故通知、データ返却・削除を確認します。利用規約と大口顧客の個別契約が異なる場合を整理します。
委託先の安全管理、所在地、再委託、契約終了時の削除を確認します。委託先一覧が実際のクラウド利用と一致しているかを見ます。
国外移転・保存地域
外国にある事業者やデータセンターを利用する場合、契約、法令、顧客説明を確認します。サービスの企業所在地と実際の保存地域を区別します。
買い手がグループ標準の国外サービスへ移す計画がある場合は、移転前に法務・セキュリティ・顧客契約を確認します。
データ保持と削除
解約顧客、無料試用、問い合わせ、バックアップの保存期間を定めます。削除依頼を受けた際、どの環境まで対応できるかを確認します。
買収調査用に受け取った顧客データは、取引が中止された場合の返却・削除を記録します。候補先が自社営業へ転用することを禁止します。
インシデント対応
検知、初動、封じ込め、調査、顧客・本人・行政への連絡、復旧、再発防止の責任者を定めます。技術担当だけで法的通知を判断しない体制にします。
過去事故の有無だけでなく、軽微として処理された事象とヒヤリハットを確認します。記録がない場合は報告文化と監視能力も評価します。
組織図と実際の意思決定を照合する
肩書だけでなく、製品、価格、顧客対応、本番変更、採用を誰が決めているかを確認します。正式な責任者と実質的な決裁者が異なる場合、買収後の権限移行に影響します。
会議体、承認、例外処理を一覧化し、創業者が不在でも意思決定できるかを見ます。すべてを形式的な承認に置き換えて速度を落とさない設計も必要です。
従業員名簿と雇用条件
職種、雇用形態、入社日、給与、賞与、勤務場所、勤務時間、在宅勤務、休暇、社会保険を確認します。候補先への個人情報開示は段階と必要性を管理します。
口頭で約束した昇給、役割、株式報酬がないかを聞き取り、書面と実態を照合します。買い手が守れない約束を承継後に初めて知ることを避けます。
キーパーソン分析
顧客関係、ソースコード、本番権限、営業、会計等の重要業務について、主担当、副担当、資料、代替期間を確認します。売上貢献だけで人を順位づけず、業務停止への影響を見ます。
残留意向は確定事実として扱いません。条件と買収目的を説明できる段階で本人の意向を確認し、同意を急かしません。
リテンション施策の設計
残留賞与を用いる場合、対象、条件、支払時期、退職時、税務を専門家と確認します。金銭だけでなく、役割、裁量、製品方針、成長機会を説明します。
一部の人だけへ秘密に施策を行うことで組織の不信が生じる可能性があります。機密性を守りつつ、選定基準と全体方針の整合を確認します。
未払残業と勤怠
在宅勤務、障害対応、リリース、顧客対応の実態を勤怠と照合します。チャットやコミット履歴だけで労働時間を断定せず、規程と本人への確認を含めます。
固定残業代、管理監督者、裁量労働等の適用は専門家へ確認します。是正が必要なら、価格調整だけでなく今後の勤務管理を改善します。
業務委託・副業人材
開発、デザイン、営業、サポートの委託契約を確認します。契約名が委託でも、指揮命令等の実態が異なる場合は労務・法務上の確認が必要です。
成果物の知的財産、秘密保持、再委託、競業、契約終了、引継ぎを整理します。個人の私物端末やアカウントに会社情報が残らないようにします。
ストックオプションと資本政策
発行済株式、潜在株式、ストックオプション、転換権、株主間契約を確認します。買収時に誰の同意と手続きが必要か、失効・行使・買取の扱いを弁護士・税理士へ確認します。
従業員が期待する経済条件を誤解しないよう、売り手が正確な説明を行います。買い手が将来制度を用意する場合も確定事項と予定を分けます。
会社法上の手続き
定款の譲渡制限、取締役会・株主総会の承認、株券、株主名簿、登記を確認します。名義株や相続未整理など権利関係の疑義はクロージング前に解消します。
署名権限、議事録、委任状を準備し、資金決済と株式移転の順序をクロージング手順書へ記載します。
重要契約の法務レビュー
顧客、代理店、クラウド、決済、開発、賃貸借、借入の契約を金額と事業影響で分類します。支配権変更、譲渡、解約、最低購入、独占、責任制限を確認します。
標準利用規約だけでなく、個別覚書、注文書、メールでの例外を探します。営業担当者の口頭約束が常態化している場合は、主要顧客へ確認する範囲を検討します。
表明保証と補償
株式、財務、税務、契約、知的財産、労務、データ、セキュリティ、紛争について、確認した事実を契約へ反映します。売り手が知り得ない事項を無制限に保証しないよう、知識限定や重要性を検討します。
補償の上限、下限、期間、第三者請求、保険を定めます。セキュリティ事故等は発見まで時間がかかる可能性も踏まえ、専門家と交渉します。
開示資料と開示事項一覧
大量のデータルームを渡すだけでなく、表明保証の例外や重要リスクを開示事項一覧へ整理します。資料名、箇所、説明を特定します。
追加資料を更新した際は、候補先が閲覧した版を記録します。古い契約と新しい契約を同じファイル名で上書きしません。
訴訟・苦情・規制対応
顧客の損害請求、返金、知的財産警告、個人情報照会、労務紛争等の履歴を確認します。解決済みでも再発可能性と契約上の義務を見ます。
不具合や広告表示に関する苦情が集中している場合は、製品・営業・サポートの根本原因を評価します。売り手の責任範囲と買い手の改善計画を分けます。
マーケティング表示の適切性
導入効果、顧客数、満足度、セキュリティ、連携先の表示に根拠があるかを確認します。「必ず集患できる」「完全に安全」などの断定を避けます。
顧客ロゴ、事例、コメントに掲載許可があるかを確認します。買収後も許可が継続するか、ブランド変更時の扱いを見ます。
知的財産の権利関係
商標、著作権、特許、ドメイン、営業秘密を一覧化します。登録名義、更新期限、共同権利、担保を確認します。
製品名称が未登録でも、他社権利を侵害しないかの調査が必要になる場合があります。買収後の名称変更コストも評価します。
営業秘密の管理
ソースコード、価格、顧客一覧、アルゴリズムを秘密として管理する規程と実態を確認します。退職者、委託先、候補先への持出しを制限します。
秘密情報の表示だけでなく、権限、ログ、返却・削除が行われているかを見ます。買収調査で秘密性を失わないよう、開示範囲を段階化します。
保険の確認
サイバー、賠償、役員、財産等の保険について、対象、限度、免責、事故通知を確認します。買収で保険が終了・変更されるかを保険会社へ確認します。
過去事象に対応する保険と買収後の保険の間に空白がないよう、契約日と責任期間を調整します。
財務デューデリジェンスの基準日
決算期末だけでなく、直近月までの試算表と契約KPIを確認します。急成長中の会社では期末から数か月で売上・費用構造が変わるためです。
基準日後の大型契約、解約、採用、障害、資金調達を後発事象として整理します。好材料だけでなく悪材料も同じ基準で共有します。
売上計上と前受収益
年額料金を一括入金している場合、会計上の売上計上期間と契約上の提供義務を確認します。現金残高が多くても、将来サービス提供の負担が残る場合があります。
初期費用、個別開発、返金、無料延長の計上方法を確認します。契約、請求、仕訳、入金をサンプルで突合します。
売掛金と未収
顧客別の年齢表を作り、長期未収、請求停止、紛争、回収見込みを確認します。自動引落し失敗やカード期限切れを有料契約へ含め続けていないかを見ます。
買収後に回収する債権について、価格と運転資金の調整を検討します。顧客関係を損なう急な回収手法を前提にしません。
費用の正常化
創業者の個人的費用、一時的な展示会、開発投資を調整する一方、買収後に必要な管理、監査、セキュリティ、人員費を追加します。都合のよい足戻しだけを行いません。
外注単価が創業者との関係で低く抑えられている場合、契約更新後の市場価格を見込みます。クラウド割引の終了も反映します。
運転資金の季節性
年額契約の更新月、展示会、賞与、外注支払によって現金が変動します。基準日だけで必要運転資金を決めず、月次推移を確認します。
クロージング時の現預金、債権、債務、前受をどのように価格調整するかを定義します。
評価方法の比較
ARR倍率、売上倍率、利払い前・税引き前・減価償却前利益（EBITDA）倍率、DCF等が参照される場合があります。倍率は成長、解約、粗利、顧客集中、技術、人材で大きく異なります。
DCFでは、売上成長、粗利、人員、設備投資、運転資金、割引率、永続成長の前提を示します。精緻な表でも不確実性が消えるわけではないため、複数シナリオを用います。
評価は交渉の材料であり成約価格の保証ではありません。税務・会計上の評価と取引上の価格を専門家と区別します。
顧客集中の価格影響
上位顧客の売上割合だけでなく、解約可能日、利用部門、担当者、競合、価格を確認します。一社が複数部署で利用している場合も、契約主体が一つなら集中リスクが残ります。
主要顧客への確認を行う場合は、秘密保持と取引の確度を考慮します。買収情報が漏れることで解約を誘発しないよう、質問と説明者を計画します。
技術負債の価格・投資反映
必要な改修を、即時、十二か月以内、長期へ分類し、費用と人員を見積もります。買収価格を下げるだけで改修予算を用意しなければ、リスクは解消しません。
売り手がクロージング前に修正する項目は、完了基準とテストを定めます。表面的な対応で根本原因が残っていないかを確認します。
アーンアウトの指標設計
ARRを指標にする場合、買い手による価格改定、グループ内売上、無料提供、解約、買収後の追加事業をどう扱うかを定義します。
EBITDAを使う場合、グループ配賦、採用、投資、役員報酬で結果が変わります。売り手が合理的に確認できる情報権と会計方針を定めます。
アーンアウトは将来の対立を生みやすいため、期間、上限、支払、紛争解決を弁護士・税理士等と詳細に設計します。
エスクロー・価格留保
特定リスクへ備えて対価の一部を留保する場合、金額、期間、解除、利息、請求を定めます。売り手の資金計画へ影響するため、対象リスクと釣り合う設計にします。
一般的な不安を理由に無期限・無制限の留保を設けません。表明保証保険等を検討する場合も対象・免責を確認します。
株式譲渡契約の前提条件
主要顧客・ベンダー同意、役員退任、株式権利、融資、重要人員、是正事項を一覧化します。完了資料と確認者を定めます。
条件未達時に延期、放棄、解除のどれを選べるかを契約で確認します。データ保護や法令対応に関する条件を安易に放棄しません。
クロージング手順書
署名、承認、資金、株式、役員、銀行、登記、権限、広報を時系列に並べます。各項目の担当、代替担当、完了証憑を記載します。
資金決済前に買い手が本番権限を取得しすぎず、決済後に売り手が重要権限を保持しすぎないよう順序を調整します。
顧客への買収説明
買収目的、サービス継続、契約、価格、窓口、データを説明します。買い手グループの医院運営事業との情報遮断を具体的に示します。
主要顧客には個別面談、その他顧客にはメール・ウェブ等を使い分けます。通知の前にサポート担当が質問へ答えられるようよくある質問を準備します。
従業員への買収説明
発表前の情報管理、発表当日の全体説明、個別面談を計画します。役割、報告先、雇用条件、オフィス、在宅、製品方針について、確定と未確定を分けます。
経営陣だけが長期間知り、従業員が顧客から聞く状態を避けます。一方、未確定の噂を広げないよう契約の確度と説明時期を調整します。
買収発表時の広報
買収金額が非公表なら非公表とし、事実でない成長効果を断定しません。顧客、従業員、取引先へ必要な説明が済んだことを確認して公開します。
導入社数や市場シェアを記載する場合は、基準日と定義を明示します。対象会社の顧客名を許可なく掲載しません。
独立運営と統合の境界
製品、顧客対応、データは独立性を維持し、人事・会計・法務等を段階的に連携するなど、機能ごとに方針を定めます。「独立運営」と言いながら全決裁を本部へ移す矛盾を避けます。
統合しない理由と見直し時期も記載します。永久に二重コストを残すのではなく、顧客信頼と効率を定期評価します。
承継後統合の準備体制
統合責任者、対象会社責任者、製品、営業、CS、技術、セキュリティ、人事、財務の担当を置きます。すべての情報を全員へ共有せず、クロージング前の機密性に合わせてチームを段階化します。
論点表には決定、未決定、前提、期限、責任者を記載します。買収契約の交渉とPMI準備で異なる前提を使わないよう、重要変更を同期します。
承継初日の優先順位
顧客が通常どおり利用できること、サポートが応答すること、従業員が働けること、重要権限が安全に引き継がれることを優先します。ロゴ変更や組織再編を初日の成功条件にしません。
経営陣、顧客、従業員、ベンダー向けのメッセージをそろえます。問い合わせ窓口と緊急連絡を用意し、回答不能な質問には期限を示します。
アクセス権限の承継初日計画
銀行、会計、クラウド、リポジトリ、ドメイン、決済、顧客管理の管理者を一覧化します。買い手側担当の追加、旧役員権限の変更、二要素認証を時系列で行います。
全パスワードをメールで共有せず、安全な管理ツールと受領確認を使います。権限変更に失敗した場合の代替連絡も準備します。
30日までの安定化
解約、問い合わせ、障害、従業員離職、権限事故を日次または週次で確認します。通常範囲の変動と買収影響を区別するため、過去基準を用います。
大規模な価格、製品、インフラ変更は原則として安定後へ置きます。法令・安全上すぐ必要な是正は例外として優先します。
60日までの組織移行
報告先、会議、予算、採用、評価を具体化します。旧経営陣への依存業務を副担当へ移し、顧客・技術の知識移転を確認します。
対象会社独自の強みを失わないよう、買い手標準の制度を一律導入せず、差異と理由を評価します。
100日までの成長計画
製品ロードマップ、販売、サポート、技術負債、セキュリティ、採用を優先順位づけし、予算と責任者を付けます。買収時のシナジー仮説を実測値で見直します。
目標未達を対象会社だけの責任とせず、買い手側の意思決定遅延や統合作業負担も評価します。
製品ロードマップの統合
外部顧客向け要望、グループ内要望、保守・セキュリティを別レーンで管理します。グループ内の大きな要望が外部顧客の改善を押しのけない配分を決めます。
優先順位は顧客数だけでなく、法令、安全、解約、技術依存を考慮します。変更理由を開発・営業・CSへ説明します。
営業統合
買い手営業が製品を販売する前に、対象顧客、価格、デモ、契約、個人情報、できないことを研修します。過度な効果保証や未実装機能の販売を防ぎます。
リード共有では利用目的と顧客同意を確認します。対象会社の顧客一覧を買い手の別事業へ一括配布しません。
カスタマーサクセス統合
顧客の健康度、利用、問い合わせ、更新をどのシステムで追うかを決めます。複数システムへ同じ情報を二重入力する期間を最小化します。
主要顧客の担当変更は、旧担当と新担当の共同面談、引継ぎ記録、フォローの順で行います。買収を機にすべて変更しません。
財務・会計統合
月次締め、請求、入金、経費、予算、連結報告の日程を合わせます。対象会社の少人数体制へ買い手の詳細報告を一度に追加しないよう、移行期間を設けます。
ARR等の経営KPIと会計売上の差異を毎月説明できるようにします。買収時の定義を統合後も継続します。
人事制度統合
等級、評価、給与、福利厚生、勤怠、在宅の差を一覧化します。買い手制度が常に有利とは限らないため、従業員ごとの影響を確認します。
変更がある場合は経過措置と問い合わせ窓口を設けます。買収前に提示した条件との整合を確認します。
ブランド戦略
対象会社ブランドを維持、共同ブランド、統合の三案を比較します。顧客中立性、検索、契約、採用、費用を評価します。
名称変更ではドメイン、メール、アプリ、契約、プライバシー文書、ストア、資料を一覧化し、転送と移行期間を設けます。
顧客中立性を担保する統制
競合する医院を運営する買い手グループと、対象会社の顧客データをシステム・規程・人員で分離します。グループ役員でも目的なく個別データを閲覧できない権限にします。
集計データを経営報告に使う場合は、顧客を特定しない範囲と利用目的を定めます。例外アクセスは承認とログを残します。
関連当事者取引
グループ内利用料、紹介料、開発委託、共通費の条件を第三者取引と比較できるよう記録します。対象会社の利益を恣意的に移すと、アーンアウトや従業員評価へ影響します。
承認者と利益相反管理を定め、売り手が将来対価を受ける期間は特に透明性を確保します。
承継後統合中のセキュリティ変更
ネットワーク、認証、端末、クラウドを変更する際は、一つずつテストし、切戻しを準備します。買い手標準へ急いで移し、顧客サービスを停止させないようにします。
新しい委託先や国外サービスを使う場合は、契約・プライバシー・顧客通知を先に確認します。
統合効果の測定
売上、粗利だけでなく、解約、導入期間、応答、障害、開発速度、従業員定着を測ります。買収前の基準値と定義を保存します。
効果が出ない場合は仮説、実行、外部環境を分けます。都合よく指標定義を変えて成功と見せません。
承継後統合のリスク台帳
顧客解約、キーパーソン退職、障害、権限事故、統合遅延、ブランド混乱を記載し、予防、検知、対応、責任者を定めます。
週次で状態を更新し、発生可能性が上がったリスクへ予算・人員を移します。取締役会へ重大リスクを定期報告します。
従業員コミュニケーション
定期説明会、匿名質問、個別面談を設けます。すべての質問へ即答せず、確認期限と責任者を示します。
退職者を否定的に扱わず、引継ぎと情報返却を適切に行います。残る従業員への過度な業務集中を防ぎます。
顧客コミュニケーション
買収後の更新、機能、価格、障害について一貫した窓口を使います。営業、CS、広報で回答が異ならないようよくある質問を更新します。
顧客から中立性やデータ利用の質問があれば、抽象的に安全と言うだけでなく、権限と規程を説明します。
ベンダーコミュニケーション
支配権変更の通知・承諾、請求先、管理者を確認します。重要ベンダーには買収後の利用継続と担当者を説明します。
買い手の調達方針で契約を切り替える場合、サービス影響と移行を評価してから通知します。
創業者の退任計画
顧客、製品、採用、文化の責任を段階的に移します。各領域の後継者と完了基準を定めます。
退任日だけでなく、退任後の問い合わせ、顧問、競業、知的財産を契約化します。善意の無期限支援に依存しません。
100日後の取締役会レビュー
買収目的、KPI、リスク、顧客、組織、技術、予算を比較します。未達事項は次四半期の計画へ移し、責任者と予算を付けます。
成功例だけでなく、買収時に見落とした前提を記録し、今後の投資判断と統合手順へ反映します。
デューデリジェンスの資料台帳
資料名、対象期間、版、担当、機密度、開示先、回答質問を一つの台帳で管理します。技術資料と顧客資料は閲覧権限を分け、候補先の全員がすべてを閲覧できる状態を避けます。
資料が存在しない場合は、存在するように作り直した過去記録を示さず、不存在と代替確認方法を説明します。買収後に必要な整備をPMIへ入れます。
顧客契約レビューのサンプリング
売上上位、古い契約、最近の契約、代理店経由、個別条件、解約予定を含むサンプルを選びます。標準契約だけを見て全顧客へ同じ条件が適用されると考えません。
サンプルで例外が多い場合は対象範囲を拡大します。支配権変更、データ、責任制限、価格が価格評価とPMIへ与える影響を記録します。
コードと顧客データの開示を分ける
技術調査にソースコードが必要でも、顧客の本番データは通常必要ありません。コード閲覧環境とデータ閲覧環境を分け、調査目的に合う権限を設定します。
候補先が競合製品を持つ場合は、クリーンチームや外部専門家を検討し、取引中止時の知識利用を制限します。
価格改定計画の検証
値上げによる増収を計画へ入れる場合、契約上の通知、顧客セグメント、解約影響、競合価格を確認します。全顧客が値上げ後も残る前提にしません。
価格改定と同時にブランド・窓口・機能を変えると原因分析が難しくなります。変更時期を分け、顧客へ価値と選択肢を説明します。
サポート品質の承継チェック
- 未解決チケットと重大度を確認したか
- 主要顧客の個別運用を記録したか
- 緊急連絡と当番を移管したか
- 回答テンプレートを新体制へ更新したか
- 顧客データの閲覧権限を限定したか
- 買収発表向けよくある質問を準備したか
- 旧担当から新担当の共同対応期間を設けたか
- サポート指標の定義を保存したか
技術承継チェック
- リポジトリと本番コードが一致するか
- 管理者権限と二要素認証を確認したか
- リリースと切戻しを実演できるか
- バックアップ復元をテストしたか
- 外部APIとライセンスを一覧化したか
- 重大脆弱性の対応期限を決めたか
- 障害連絡と顧客通知を準備したか
- 退職者・委託先の権限を更新したか
よくある質問
買い手が歯科医院を運営していても顧客情報は守られますか
守るための具体的な情報遮断、権限、ログ、規程が必要です。買収しただけでグループ各社へ自由に共有できるわけではありません。
ARRが同じ会社なら価値も同じですか
同じとは限りません。成長、解約、粗利、顧客集中、契約期間、技術負債、人材で持続性が異なります。
買収前に顧客へ連絡しますか
契約上の承諾・通知、取引の確度、情報漏えいリスクを踏まえて決めます。主要顧客への確認が条件になる場合もあります。
個別開発した機能の権利は誰にありますか
顧客契約、委託契約、成果物の作成者によります。標準製品へ組み込まれていても自社所有と断定せず確認します。
クラウドアカウントは買い手へそのまま移せますか
サービス規約と契約名義によります。株式譲渡でも管理者・請求・二要素認証を安全に変更する手順が必要です。
創業者がすぐ退任しても買収できますか
可能性はありますが、顧客、製品、技術、組織の依存度と買い手の代替体制を確認します。必要な引継ぎを契約条件にします。
外部顧客向けサービスをグループ内専用へ変えられますか
契約、顧客説明、解約、ブランド、事業価値へ大きく影響します。買収前の目的と整合し、既存顧客の権利を尊重する必要があります。
セキュリティ診断で指摘が出たら取引は中止ですか
指摘の重大度、悪用可能性、影響、是正可能性によります。クロージング前是正、条件、投資計画等で対応できるか判断します。
従業員の個人メールに顧客情報がある場合はどうしますか
事実を確認し、会社管理環境への移行、削除、再発防止を行います。個人端末の調査は労務・プライバシーへ配慮して専門家と進めます。
買収後すぐ値上げできますか
契約上可能でも顧客信頼と解約へ影響します。通知、移行期間、提供価値、競合を確認して判断します。
アーンアウト期間中に買い手が投資を減らしたらどうなりますか
将来対価へ影響するため、運営義務、予算、指標、情報権を契約で定めることがあります。個別設計は専門家へ相談してください。
買収後のデータ利用目的を変更できますか
既存の利用目的、契約、法令を確認し、必要な通知・同意・システム変更を行います。買収を理由に自動的に拡張できません。
製品名を残すべきですか
顧客認知、中立性、契約、検索、費用を比較して判断します。変更する場合は長い移行期間と転送を用意します。
代理店契約は買収後も続きますか
契約条項と代理店の意向によります。支配権変更、独占、手数料、顧客帰属を確認します。
PMIはいつから準備しますか
基本合意・デューデリジェンスの段階から、機密性を守りながら準備します。成約後に初めて担当者を決めるとサービス継続へ影響します。
最終投資判断会議
価格、顧客、契約、技術、データ、組織、資金、PMIを同じ前提で確認します。各分野が個別に「問題なし」としても、必要投資の合計と実行能力が買収計画に合うかを見ます。
未解決事項を明記し、契約条件、クロージング前是正、100日計画のどこで扱うかを決めます。分からない事項を楽観的な数値へ置き換えません。
売り手側チェックリスト
- 契約別のMRR・ARRと売上計上を整理したか
- 顧客別・チャネル別の解約と継続率を確認したか
- 顧客・代理店・ベンダー契約を一覧化したか
- 知的財産と外部成果物の権利帰属を確認したか
- ソースコード、インフラ、管理者権限を整理したか
- 外部サービスと委託先への依存を可視化したか
- データマップとプライバシー文書を更新したか
- 障害・事故・苦情の履歴を整理したか
- キーパーソンの業務と代替担当を把握したか
- 創業者の残留条件と権限移管を検討したか
- 顧客・従業員への説明計画を作成したか
- 税引後手取りと専門家費用を確認したか
買い手側チェックリスト
- 買収目的と統合しない領域を明確にしたか
- 顧客中立性と情報遮断の方針を決めたか
- 技術・セキュリティの専門調査を行えるか
- キーパーソン退職時の代替計画があるか
- クラウド・外部APIの追加投資を見込んだか
- 顧客契約の承諾・通知を確認したか
- 外部顧客への提供を維持する予算があるか
- 価格改定やブランド変更を急がない計画か
- 権限変更とインシデント対応を準備したか
- 100日間の統合責任者と会議体を決めたか
よくある質問
この事例は実在するサービス会社の買収ですか
いいえ。公開情報にみられる取引類型と一般的なM&A実務を基に再構成した想定事例です。特定の会社、医療法人、取引を示しません。
歯科関連会社なら医院と同じ評価方法ですか
異なります。サービス会社では、契約収益、顧客継続、粗利、知的財産、技術、人材、データ管理等が中心になります。
月額課金があれば高く評価されますか
月額課金だけでは判断できません。解約率、値引き、粗利、顧客集中、未収、サポート工数等を確認します。
顧客契約は株式譲渡なら確認不要ですか
会社に契約が残る場合でも、支配権変更時の通知・承諾、解約、データ利用等の条項を確認する必要があります。
買収後に顧客データをグループで共有できますか
当然に共有できるわけではありません。利用目的、契約、法令、顧客への説明、アクセス権限を確認します。
外部委託したソースコードも会社の資産ですか
契約上の権利帰属によります。業務委託契約、成果物、著作権、ライセンス条件を確認します。
創業者には残ってもらうべきですか
事業の属人性と買い手の体制によります。残留する場合も、期間、役割、権限、報酬、退任条件を具体化します。
従業員にはいつ説明しますか
案件の確度と説明可能な条件を踏まえて決めます。遅すぎる説明による不信と、早すぎる情報拡散の双方を考慮します。
技術デューデリジェンスでは何を確認しますか
コード、設計、テスト、インフラ、セキュリティ、外部依存、運用、権限、障害対応、開発組織等を確認します。
買収後すぐグループのシステムへ統合できますか
依存関係と顧客影響を確認せずに統合すると障害リスクが高まります。段階的な移行計画が必要です。
価格の一部を将来業績に連動できますか
検討できますが、指標定義、測定期間、買い手の運営裁量、情報閲覧、紛争対応を詳細に定める必要があります。
成約後に最初に優先することは何ですか
サービス継続、顧客対応、従業員の安定、アクセス権限とセキュリティです。大規模な統合は安定を確認してから進めます。
まとめ
歯科関連サービス会社のM&Aでは、顧客契約と継続課金、知的財産、開発・クラウド環境、データ管理、従業員、販売チャネルを一体として確認します。歯科業界向けであっても、診療所承継の指標を持ち込まず、サービス会社としての収益性、継続性、技術、顧客信頼を評価することが重要です。
本記事は一般的な論点を整理した想定事例であり、個別案件の法務、税務、労務、会計、個人情報保護等の判断を代替しません。実際の取引では、弁護士、税理士、公認会計士、社会保険労務士、情報セキュリティ専門家等へ確認してください。
