IT企業 M&A PMI｜100日プランと統合実務ガイド

IT企業 M&A PMIは、契約締結後に思いついたシステムを統一する作業ではありません。社員・顧客の信頼を守り、買収目的を実現するために、経営、事業、人材、開発、クラウド、データを優先順位付きでつなぐ経営プロセスです。

地域SIer、SES、Web制作会社、SaaS、MSPでは、止めてはいけない業務も、統合すべき資産も違います。会計やメールを早く一本化しても、顧客対応が途切れ、キーパーソンが退職し、開発権限が混乱すればM&Aの価値は失われます。本稿では、クロージング前の準備、統合初日、100日プラン、その先の定着までを、IT業界の現場単位で整理します。

IT企業 M&A PMIとは何か

PMIは買収後の経営統合の略で、M&A成立後に経営や事業を統合・すり合わせし、取引目的を実現するプロセスです。中小企業庁のPMIを実施するでは、PMIをM&Aの目的を実現し、統合効果を最大化するために必要なプロセスと説明しています。

「統合」という語から、法人、制度、システムを一つにそろえることだけを想像しがちです。しかしPMIの本質は、買収目的に照らして、残すもの、つなぐもの、変えるもの、廃止するものを選ぶことです。優れた開発文化や地域顧客との関係を壊してまで、買い手の標準へ合わせる必要はありません。

成約はスタートライン

デューデリジェンスでは限られた期間と情報で対象会社を理解します。クロージング後にはじめて分かる実務も多く、M&Aの投資仮説は、社員、顧客、契約、システムの現実と照合されます。PMIは、調査で挙がった課題を処理するだけでなく、投資仮説を実行可能な計画へ変える役割を持ちます。

100日プランは法定期限ではない

100日プランは、クロージング後の初期統合を見通す管理上の時間軸です。すべてを100日以内に完了する義務や、どの案件にも共通する工程ではありません。中小企業庁の資料も、成立後100日から1年程度までの取組を扱い、実践ツールは自社の優先順位に応じたカスタマイズを前提としています。

IT企業 M&A PMIでは、統合初日で事業継続を守り、初期に事実を把握し、100日までに優先課題を安定運用へ移す、という節目として使います。基幹刷新やプロダクト統合が長期に及ぶなら、100日までに意思決定、責任者、移行方式、検証条件を固め、その後のロードマップへ接続します。

譲渡企業にもPMIの準備が必要

PMIは買い手だけの仕事ではありません。譲渡企業の経営者は、顧客関係、キーパーソン、暗黙の運用、例外契約、地域で守る条件を説明します。引継ぎ期間と役割を曖昧にすると、旧経営者に判断が集中したまま新体制へ移れません。売却前から業務と権限を可視化することが、社員定着と買収後の価値保全につながります。

IT企業 M&A PMIを失敗させない基本原則

買収目的から逆算する

人材獲得、地域進出、顧客基盤、SaaS成長、技術獲得、事業承継では成功の定義が異なります。PMI項目を網羅する前に、M&Aで何を実現し、何を守るかを一文で定義します。社員向け、顧客向け、社内承認向けで言い方が変わっても、中心となる目的は一致させます。

守る統合と変える統合を分ける

顧客窓口、サービス稼働、給与、請求、障害連絡などは、切替で止めてはいけません。一方、重複ツール、曖昧な権限、脆弱な運用、採算不明の例外は改善対象です。安定運用を守る領域と変革する領域を同じ工程表で扱うと、変革の遅れか事業停止のどちらかが起きます。二つのレーンに分けます。

統一より相互運用を先に考える

メール、チャット、ソース管理、チケット、CRM、会計をすぐ同じ製品へ移す必要はありません。まず連絡、検索、権限、レポートが両社をまたいで機能する状態を作ります。統一にはデータ移行、教育、契約、監査、停止時間が伴います。目的を満たす最小の接続を先に実現し、統一の便益が費用とリスクを上回るか評価します。

意思決定の速度と現場の安全性を両立する

PMIは決めないことでも停滞しますが、現場確認なしの即断でも壊れます。可逆的な変更は小さく試し、不可逆的な変更は移行・ロールバック・承認条件を設けます。プロダクト廃止、データ移転、雇用条件、顧客契約変更は、経営判断だけでなく法務・技術・顧客影響を確認します。

事実・仮説・決定を分離する

「開発が遅い」は評価であり、事実ではありません。リリース頻度、未完了作業、レビュー待ち、障害、担当者を確認します。買い手の仮説、現場で確認した事実、会議で決めた内容を別欄で管理すると、文化的な非難を避けられます。

機密性と知る必要性を守る

クロージング前は両社が別企業であり、共有できる情報には契約・法令・競争上の制約があります。秘密保持契約があっても、顧客情報、個人情報、価格、将来戦略を無制限に渡しません。必要に応じて弁護士の助言のもと、開示範囲、閲覧者、クリーンチーム、データルーム、ログを設計します。

クロージング前：統合初日を安全に迎える準備

IT企業 M&A PMIはクロージング後に正式実行しますが、準備は成約前から始まります。中小企業庁のPMI実践ツール活用ガイドブックも、従業員説明や主要取引先への挨拶など、成立後速やかに行う事項があるため、成立前に計画を策定することが望ましいと説明しています。

統合初日の準備リストを作る

• 従業員、顧客、金融機関、主要取引先への説明順序と担当者
• 給与、支払、請求、入金、経費、勤怠を継続する担当者
• 障害、セキュリティ、顧客クレームの緊急連絡網
• 代表権、銀行、電子契約、稟議、購買の権限
• クラウド、ドメイン、ソース、決済、請求の管理者
• 公開情報、社内FAQ、顧客向けFAQ、問い合わせ窓口
• クロージング条件と未解決課題の引継ぎ

前提条件を一覧にする

株式取得が完了する、主要契約の同意が得られる、資金が実行される、役員変更が登記されるなど、統合初日の前提を明示します。前提が満たされない場合に延期、代替措置、限定運用のどれを選ぶか決めます。クロージング日がずれても連絡文や権限変更が先に動かないよう統制します。

開示前提のデータルームを分ける

デューデリジェンス資料とPMI実行資料は同じではありません。DDではリスク判断に必要な抜粋が中心でも、PMIでは運用に必要な台帳、手順、担当者が要ります。一方、クロージング前に従業員の個人情報や顧客データを過剰共有しないよう、匿名化、集約、段階開示を使います。

統合しない事項も決める

ブランド、社名、オフィス、顧客契約、開発ツール、評価制度を当面維持する場合、期限と見直し条件を定めます。「触らない」は放置ではありません。責任者、監視KPI、例外時の承認、次回判断日を設定します。

旧経営者の引継ぎを業務単位にする

「半年間支援する」といった期間だけでは足りません。顧客挨拶、見積承認、採用、資金、障害、技術判断、協力会社、地域団体など、旧経営者が担う仕事を分解します。新責任者、共同期間、単独移行の判定条件を決め、旧経営者が永続的なボトルネックにならないようにします。

統合初日：変える日ではなく、安心を届ける日

統合初日の最優先は、事業が続き、誰に聞けばよいかが分かり、不利益を勝手に決めないと関係者へ伝えることです。新しいロゴ、ツール、組織図を一度に発表するより、給与、顧客対応、サービス、意思決定を確実に継続させます。

経営メッセージに入れる内容

• M&Aの目的と、両社が目指す顧客価値
• 変わること、当面変わらないこと、未決定のこと
• 雇用、処遇、勤務地等について現時点で確定している範囲
• 顧客・プロジェクト・サービス継続の方針
• 質問、相談、匿名意見の窓口
• 次に情報を更新する時期と方法

分からないことを無理に断定しない

「何も変わりません」と言い切った後に制度変更を発表すると信頼を失います。決定済み、検討中、変更予定なしを分けます。検討中の項目には、判断基準、関係者、見込み時期を示します。答えがない質問も記録し、回答担当と期限を設定します。

管理権限を確認する

銀行、会計、給与、電子契約、クラウド、ドメイン、DNS、証明書、コード署名、アプリストア、決済、広告、SNSなど、法人運営とサービス継続に必要な権限を確認します。統合初日に一律でパスワードを変更すると自動処理や緊急対応が止まるため、資産ごとの変更計画を使います。

緊急時の指揮系統を一本化する

障害や情報漏えいが起きたとき、旧会社と買い手のどちらが判断し、誰が顧客へ連絡するかを決めます。インシデント中に組織図を議論しないよう、暫定指揮者、技術責任者、法務・広報、顧客窓口を指名します。

IT企業 M&A PMIの100日プラン

以下は法定期限ではなく、初期統合を管理するための標準例です。案件の規模、開示時期、システム、許認可、顧客契約に応じて変更します。大規模な移行を100日に押し込むのではなく、100日後に「事業が安定し、優先課題の責任者と長期計画が確立した状態」を目指します。

最初の段階：聞く、守る、見える化する

経営者、管理職、キーパーソン、顧客窓口へヒアリングし、DD仮説を更新します。顧客別収益、案件、受注残、人員、クラウド、契約、アカウントを台帳化します。すぐ改善できる課題と、設計が必要な課題を分けます。

中盤：クイックウィンを選ぶ

両社の連絡先表、重複会議の削減、見積承認の明確化、バックアップ確認、退職者権限の削除など、価値が明確で可逆性の高い改善を選びます。派手な統合より、現場が困っていた問題を解くとPMIへの信頼が生まれます。

後半：仕組みへ移す

個人の頑張りで回した初期対応を、会議、権限、手順、KPIへ移します。暫定責任者を正式化するか、既存部門へ引き渡します。未完了の基幹・クラウド・プロダクト統合は、予算、体制、移行判定、ロールバックを含む長期計画へします。

100日レビュー

買収目的に対する進捗、顧客、社員、財務、技術、セキュリティをレビューします。完了件数だけでなく、期待効果、想定外の損失、現場負荷を確認します。計画を守ることより、前提変化を反映して優先順位を更新することが重要です。

PMI推進体制：誰が決め、誰が実行するか

IT企業 M&A PMIは、経営企画だけでも情報システム部だけでも進みません。経営、事業、財務、人事、法務、開発、インフラ、セキュリティ、顧客対応の責任を結びます。中小企業では兼務が多いため、役職名より意思決定権と稼働時間を確認します。

ステアリングコミッティ

経営レベルの会議では、買収目的、優先順位、予算、重大リスク、部門間対立を扱います。詳細なタスク確認に時間を使わず、現場では解決できない決定を行います。決定事項、条件、責任者を記録します。

PMI責任者

全体計画、依存関係、課題、会議、経営報告を管理します。対象会社の現場を尊重しつつ、曖昧な宿題を放置しない役割です。すべてを自分で実行せず、ワークストリーム責任者が動ける環境を作ります。

ワークストリーム責任者

人事、顧客、財務、開発、クラウド等の領域ごとに、両社から責任者を置きます。買い手側だけで決めると対象会社の例外運用を見落とし、譲渡企業側だけに任せると全社方針と接続しません。共同責任と最終決裁者を分けます。

意思決定ログ

決定日、論点、選択肢、根拠、決裁者、影響、見直し条件を残します。同じ議論の繰り返しを防ぎ、退職・異動後も経緯を追えます。暫定決定には期限を付けます。

社員説明と定着：情報の空白をつくらない

社員は、会社の将来だけでなく、自分の仕事、上司、報酬、勤務地、評価、顧客、技術がどうなるかを見ています。発表の美しい理念より、具体的な不安へ継続的に答えることが定着の基盤です。

一回の全社会議で終えない

全社説明、部門説明、個別面談、FAQ、匿名質問を組み合わせます。初日は驚きで質問が出ないこともあります。情報更新の周期を示し、同じ質問へ同じ回答が返るよう管理します。管理職には説明資料だけでなく、答えてよい範囲とエスカレーション先を渡します。

キーパーソンを肩書だけで選ばない

顧客が信頼する担当、デプロイできる人、古いシステムを直せる人、請求例外を知る人、チームの相談役など、組織図に表れないキーパーソンがいます。業務、ネットワーク、技術、文化の四方向で把握します。特定者だけへ情報と報酬を集中すると、周囲の意欲を損なうため、チーム全体の設計も必要です。

リテンション施策を金銭だけにしない

継続報奨は選択肢ですが、役割、裁量、成長機会、技術方針、評価の公平性、働き方が不明なら定着しません。誰に何を期待し、どの期間・条件で評価するかを明確にします。法的・税務的な設計は専門家へ確認します。

文化を優劣で語らない

「買い手は管理が強い」「対象会社はスピードが速い」というラベルでは足りません。意思決定、会議、レビュー、失敗報告、顧客優先、品質、残業、文書化の行動を観察します。統合後に必要な行動原則を共同で定め、どちらの慣行を採用するか理由を説明します。

雇用承継はスキームで異なる

株式譲渡では通常、雇用主である法人自体は継続します。一方、事業譲渡や会社分割では手続が異なります。厚生労働省の企業組織再編に伴う労働関係の案内は、事業譲渡における労働契約承継には労働者の真意による承諾を得ること等、各手法の留意事項を示しています。案件のスキームに合わせて専門家へ確認し、説明順序を設計します。

顧客・取引先説明：安心と価値を相手別に伝える

顧客は、契約が続くか、担当者が変わるか、データは安全か、価格やロードマップはどうなるかを気にします。M&Aの戦略用語より、提供中のサービスと契約への影響を先に説明します。

顧客を重要度と懸念で分類する

売上額だけでなく、解約影響、紹介、地域信用、共同開発、規制、個人情報、SLAを考慮します。主要顧客は経営者と担当者が個別訪問し、一般顧客は担当者連絡や文書を組み合わせます。一斉メールの前に重要顧客が報道で知ることを避けます。

説明の基本構造

• 取引の目的と顧客にとっての価値
• 契約、担当、請求、サポート、SLAの変更有無
• データ管理、再委託、クラウド等への影響
• プロダクト・サービスの継続とロードマップ
• 問い合わせ窓口と次の説明時期

約束できないシナジーを売らない

買い手の商品をすぐ使える、サポートが必ず強化されるなど、未確定の便益を約束しません。検討中の連携は、評価・試行・提供開始の条件を示します。既存サービスの品質を守ることを優先します。

契約上の通知・同意を確認する

支配権変更、譲渡、再委託、データ保管、担当者、価格、ブランド変更について通知・同意が必要な場合があります。契約台帳で条項と期限、送付先、証跡を管理します。法的に通知不要でも、関係維持のため説明すべき顧客を事業判断で選びます。

顧客の声を100日プランへ戻す

面談内容を、継続意向、懸念、要望、競合動向、次回対応に分けます。営業個人のメモで終わらせず、顧客リスク台帳へ反映します。解約兆候があれば、責任者と対応期限を決めます。顧客説明は広報行為ではなく、PMI仮説の検証です。

事業・財務・管理業務を止めずに統合する

IT企業 M&A PMIでは、プロダクト統合に注目が集まりやすい一方、見積、受注、請求、入金、給与、外注支払が止まれば事業は続きません。まず日次・月次・年次の管理カレンダーを作り、責任者と締切を確認します。

顧客・案件・サービスの採算をそろえる

両社で売上区分、原価、工数、粗利の定義が違う場合、早期に共通レポートを作ります。会計システムをすぐ統一しなくても、顧客、案件、サービス、部門の対応表があれば連結して見られます。定義変更で過去比較ができなくならないよう、旧定義も残します。

見積と値引き権限を明確にする

クロージング直後に、誰が価格、納期、SLA、再委託を承認するか曖昧になりがちです。通常案件と例外案件の基準、承認期限、緊急時の代理を定めます。統合効果を急いでクロスセルしても、原価・責任・顧客窓口が不明なら赤字を増やします。

月次決算を共通言語にする

科目体系、売上認識、仕掛、前受、外注、ソフトウェア開発費、関係会社取引を確認します。初期は組替表で対応し、統一会計方針とシステム移行は専門家を交えて計画します。管理用KPIと財務会計を混同せず、差を説明できるようにします。

シナジーと統合費用を別管理する

共同営業の売上、購買改善、重複費削減などの効果と、移行、採用、外部支援、退職、契約解約などの費用を別に追います。通常業績へ混ぜると、買収効果が見えません。シナジーには責任者、基準値、実現時点、反作用を設定します。

開発組織・プロダクト統合：コードを先に混ぜない

開発統合の目的は、リポジトリを同じ場所へ移すことではありません。顧客価値、リリース品質、開発速度、人材の成長を高めることです。技術スタックが違っても、互いのプロダクトが独立して価値を生むなら、統一しない選択があります。

プロダクトポートフォリオを整理する

顧客、課題、売上、粗利、成長、技術、ロードマップ、担当チームを一覧化します。重複して見える製品も、顧客層や導入方式が違う場合があります。統合、連携、共存、終了の選択肢を比較し、顧客移行と契約を含めて判断します。

開発プロセスの事実を比べる

アジャイルかウォーターフォールかという名称ではなく、要求、優先順位、設計、レビュー、テスト、リリース、障害対応の実態を確認します。リードタイム、変更失敗、未完了作業、レビュー待ち、手戻りを観察します。片方の方法を標準と決める前に、各プロダクトの制約を理解します。

リポジトリ移行は権限・履歴・自動化と一体

コードだけでなく、Issue、Pull Request、CI/CD、Secrets、成果物、署名、Webhook、アクセス権、監査ログを対象にします。移行前後でビルド・テスト・デプロイが再現できるか確認します。旧環境を止める条件と保管期間を決めます。

技術負債を共同で棚卸しする

古い言語やライブラリを一律に否定せず、顧客影響、障害、セキュリティ、変更頻度、人材、更新費用で優先順位を付けます。買い手の技術基準へ適合させる費用も統合予算に入れます。対象会社へ「負債の説明」だけを求めず、買い手側システムも同じ尺度で見ます。

ロードマップの空白を防ぐ

PMI会議が増えると開発が止まりやすくなります。顧客約束、法令・セキュリティ、保守、成長施策を分類し、PMI対応工数を明示します。プロダクト責任者が経営判断を待つ項目には期限を設定します。

クラウド・インフラ統合：構成より責任境界を先に見る

クラウドアカウントを一つにまとめれば管理が簡単になるとは限りません。障害範囲、権限、請求、契約、データ所在、顧客要求が変わります。まず現状構成と責任境界を把握し、接続、共同監視、請求統合、アカウント移行を分けます。

クラウド資産台帳

契約主体、アカウント、組織、リージョン、サービス、用途、データ、責任者、費用、予約・長期契約、サポート、管理者を一覧化します。個人カードや個人メール、退職者アカウント、用途不明リソースを確認します。

接続前にネットワーク境界を設計する

両社ネットワークを急いで常時接続すると、攻撃面と障害範囲が広がります。必要通信、認証、名前解決、ログ、監視、遮断方法を設計し、小さな範囲で検証します。開発・検証・本番の境界も維持します。

バックアップと復元を確認する

バックアップが存在するだけでなく、対象、頻度、保管、暗号化、権限、世代、復元手順、復元テストを確認します。IPAの中小企業の情報セキュリティ対策ガイドライン第4.0版は、バックアップを基本的な取組に加え、資産管理、インシデント対応、クラウド利用等を段階的に扱っています。PMIでは両社の基準差を把握し、重要システムから改善します。

費用最適化と移行を混ぜない

予約契約、ボリューム割引、重複ツールの削減は効果になり得ますが、先に契約をまとめると解約・移管制約を抱える場合があります。利用量、顧客別原価、移行費、為替、サポート、障害範囲を比較します。削減額だけでなく、運用負荷とリスクを含めます。

クラウドサービスの選定を再確認する

IPAの中小企業のためのクラウドサービス安全利用の手引きを参考に、利用目的、責任分担、可用性、データ、契約終了、サポート等を確認します。買い手指定サービスへ移す場合も、対象会社の顧客契約と要求を満たすか検証します。

ID・セキュリティ・インシデント対応のPMI

セキュリティ統合は、監査のためだけでなく事業継続のために行います。経済産業省のサイバーセキュリティ経営ガイドラインVer.3.0は、経営者のリーダーシップと組織的な取組を示しています。IT企業 M&A PMIでは、買い手CISOへ丸投げせず、対象会社のサービス責任者と共同で優先順位を決めます。

IDを人・機械・顧客に分ける

従業員ID、特権ID、サービスアカウント、APIキー、証明書、顧客IDを分けます。人事異動と入退社に連動するIDは統合しやすい一方、本番サービスの機械IDを一括変更すると停止リスクがあります。所有者、用途、期限、保管、ローテーションを台帳化します。

最小権限と緊急権限

管理者権限を減らすだけでなく、障害時に誰がどの手続で権限を取得するか決めます。共有アカウントは個人識別可能な方式へ移し、操作ログを残します。買い手担当者へ対象会社の本番権限を即時付与するのではなく、必要性と承認を確認します。

脆弱性とパッチの基準差を埋める

資産重要度、脆弱性の深刻度、インターネット公開、悪用状況、代替策、顧客契約から対応期限を決めます。ツール導入だけでなく、発見、評価、修正、例外承認、再確認の流れをそろえます。対応不能な古いシステムには隔離、監視、更新計画を設けます。

インシデント計画を一本化する

検知、初動、封じ込め、証拠保全、復旧、顧客・当局連絡、再発防止の役割を確認します。IPAのセキュリティインシデント対応の手引きも参照し、両社の連絡先と判断基準を統合します。クロージング直後に演習を行い、連絡不能や権限不足を発見します。

セキュリティ例外を隠さない

買い手基準をすぐ満たせない場合、例外の対象、リスク、代替統制、責任者、期限を承認します。「PMI中だから」という無期限例外を作りません。重大リスクは顧客影響と事業継続を含め経営会議へ上げます。

データ・個人情報統合：利用目的から逆算する

データを一つの分析基盤へ集めればシナジーが出るとは限りません。誰の、どのデータを、どの目的で、誰が使い、どこに保存し、いつ削除するかを確認します。技術的に移せることと、契約・法令・顧客約束上使えることは別です。

データカタログを作る

顧客、従業員、見込客、製品利用、ログ、ソース、会計、サポート等のデータについて、所有者、保存先、利用目的、法的根拠、機微性、委託先、保持期間、削除を整理します。列単位の完璧な台帳から始めず、重要データセットと高リスク用途を優先します。

事業承継時の利用目的を確認する

個人情報保護委員会の個人情報保護法ガイドライン通則編は、合併、分社化、事業譲渡等による事業承継で取得した個人情報を、承継前の利用目的達成に必要な範囲内で扱う場合の考え方と、範囲を超える場合の同意を説明しています。個別案件では法務専門家へ確認し、データ統合をM&Aという理由だけで正当化しません。

公開した利用目的をサービス別に確認する

個人情報保護委員会の合併や組織再編等を行う事業者への注意情報は、事業内容に変更・追加がある際、ホームページ等で通知・公表している利用目的が正しく反映されているか、サービスごとに確認するよう促しています。プライバシーポリシーを買い手の文面へ機械的に置換せず、実際のサービスと整合させます。

移行の完全性を検証する

件数、合計、ハッシュ、サンプル、参照整合性、文字コード、時刻、履歴、権限を確認します。移行前後で業務レポートが一致するか、削除対象が復活していないかを検証します。旧システムの閲覧期限と廃棄証跡も決めます。

分析シナジーは仮説から始める

クロスセル予測や解約分析を行うなら、利用目的、データ品質、バイアス、アクセス、モデル評価を確認します。全データを先に集めず、必要最小限の項目で試行し、顧客価値とリスクを検証します。

契約・ライセンス・アカウント統合

IT企業の事業資産は、物ではなく契約とアカウントに分散しています。クラウド、ソース管理、ドメイン、証明書、アプリストア、決済、広告、CMS、フォント、OSS、販売代理、業務委託を台帳化します。

支配権変更・譲渡・再委託

株式譲渡でも支配権変更条項があり、事業譲渡では契約移転の同意が必要になる場合があります。ライセンスが法人、ユーザー、端末、売上等のどれにひも付くか確認します。通知・同意の要否は弁護士と契約ごとに判断します。

名義と実態の不一致

ドメインが創業者個人、クラウドが元社員メール、広告が代理店、決済が別法人というケースがあります。名義、請求、管理者、回復手段を確認し、移管順序を決めます。多要素認証を変更する前に緊急回復を検証します。

OSSと第三者素材

コンポーネント、バージョン、ライセンス、修正、配布、通知を整理します。ソースコードを統合すると適用条件や配布範囲が変わる可能性があります。法的判断は専門家へ確認し、開発チームが継続管理できる仕組みにします。

ベンダー統合はサービス影響から判断する

重複ベンダーを減らす前に、顧客要件、障害対応、データ移行、解約費、代替性を確認します。価格だけで選ぶと対象会社の運用知識を失います。統合候補、維持候補、終了候補に分け、切替条件を置きます。

SaaS事業のPMI：KPI定義と顧客体験をそろえる

SaaS企業の統合では、ARR、MRR、解約、NRR、CAC等の定義が両社で違うことがあります。数字を合算する前に、対象契約、測定日、一時売上、従量課金、値引き、休止、解約の定義をそろえます。

ARRブリッジを共通化する

期首、新規、アップセル、ダウンセル、解約、価格変更、期末の流れを顧客別に作ります。請求、契約、会計売上へ突合します。統合後のクロスセルを新規か拡張か定義し、二重計上を防ぎます。

カスタマーサクセスを混ぜる前に役割を比較する

導入、活用、サポート、更新、アップセルの責任境界を確認します。同じCSという名称でも営業寄り、サポート寄り、導入寄りの場合があります。顧客セグメントと必要能力に合わせ、窓口変更を段階化します。

価格・プラン統合を急がない

既存顧客の契約、割引、機能、サポート、更新時期を確認します。新規顧客から新プランを試す、更新時に選択肢を示すなど、移行方式を比較します。システム上可能でも、顧客価値と契約を無視した一括変更は解約を招きます。

ロードマップと営業約束を照合する

買収発表後、両社営業が未確定の連携を提案しないよう、販売可能、試行、計画、未決定を区分します。CRMの商談とプロダクトバックログを接続し、顧客約束を承認します。

地域IT企業のPMI：関係資産を壊さずに広げる

地域SIerやWeb会社の価値は、顧客業務の理解、現地対応、元請・協力会社、学校・採用との関係にあります。買い手の全国標準を入れるだけでは、この関係資産を失う可能性があります。IT企業 M&A PMIでは地域で残すものを明示します。

顧客関係を複線化する

旧経営者と顧客の個人的関係を否定せず、新責任者、現場担当、買い手側専門家を段階的に紹介します。顧客固有の年間行事、予算、更新、障害連絡を顧客カルテへします。社名・窓口変更の時期は顧客の繁忙期を避けます。

自治体・医療・教育の制約を尊重する

入札、再委託、個人情報、セキュリティ、データ保管、従事者資格を契約・制度に沿って確認します。買い手のクラウドやグループ会社を使うことが再委託・保管場所変更になるかを法務と顧客窓口で確認します。

協力会社を統合の対象ではなくパートナーとして見る

主要協力会社へ、案件、契約、支払、窓口の変更を説明します。集中購買による単価引下げだけを先に求めると、地域の供給力を損なう可能性があります。専門性、繁忙対応、顧客関係を評価し、代替性と継続意向を確認します。

地域採用ブランドを守る

買い手ブランドへ即時変更する前に、学校、紹介、求人、社員認知への影響を確認します。買い手の研修・キャリア機会を加えつつ、勤務地、顧客に近い仕事、柔軟な働き方という強みを維持します。

何を地域に残すかをKPI化する

拠点、雇用、顧客、協力会社、社名、地域活動を残す方針があるなら、抽象的な宣言ではなく責任者と確認指標を置きます。価格だけでなく、譲渡企業が重視した承継条件をPMIレビューに含めます。

PMI KPI：完了率ではなく、価値と安定を測る

タスク完了率だけでは、顧客が不安になり、社員が疲弊していても「順調」に見えます。買収目的、事業安定、関係者、統合実行の四層でKPIを設計します。

買収目的KPI

顧客拡大、人材、地域、プロダクト、収益等、取引目的に直結する指標です。買収前の投資仮説と同じ定義を使い、統合による効果と外部環境を分けて説明します。

事業安定KPI

売上、粗利、受注残、ARR、解約、障害、SLA、請求遅延、資金を確認します。初期は異常を早く発見する指標を優先します。指標が悪化したら、誰が何を止めるか決めます。

社員・顧客KPI

キーパーソン定着、退職兆候、質問、説明実施、顧客面談、更新、クレームを確認します。アンケートだけでなく、個別面談と行動データを組み合わせます。個人情報とプライバシーに配慮します。

技術・セキュリティKPI

重大脆弱性、特権ID、バックアップ復元、障害、変更失敗、未所有アカウント、移行テストを確認します。件数を減らすための分類変更を防ぎ、定義と基準値を固定します。

赤・黄・緑だけで終わらせない

ステータスには事実、影響、次の行動、責任者、期限を付けます。黄色が何週も続く場合のエスカレーション条件を決めます。都合の悪い情報を早く上げた人を責めない運営が必要です。

100日アクションプランを実行可能な形にする

100日プランは、やることを大量に並べた一覧ではありません。M&Aの目的、優先課題、具体的行動、責任者、期限、依存関係、完了条件を一つの流れにした経営計画です。中小企業庁のPMI実践ツールは、分析ワークシート、アクションプラン、統合方針書を分けています。この順番を使うと、他社のToDoをコピーするのではなく、自社の目的から行動へ落とせます。

目的を成果へ分解する

「地域の開発力を獲得する」という目的なら、社員定着、主要顧客継続、共同提案、開発案件、採用力など、観察可能な成果へ分けます。「SaaSを成長させる」なら、解約を増やさず、販売チャネルを検証し、プロダクト供給力を維持するという条件を置きます。目的を売上目標だけにすると、短期営業が顧客体験や開発を傷つける可能性があります。

課題を症状と原因に分ける

月次決算が遅いという症状に対して、会計システムを変える前に、請求締め、仕掛、工数、承認、担当者不足のどこが原因かを見ます。リリースが遅い場合も、技術負債だけでなく、優先順位、レビュー、顧客個別対応、テスト環境、承認が影響します。原因仮説と確認方法をアクションプランへ入れます。

一つのタスクを一人の責任へ置く

実行には複数人が関わっても、結果を追う責任者は一人にします。「人事部」「開発チーム」だけでは、誰が更新するか分かりません。責任者の上司、協力者、承認者も区分します。兼務者にはPMIへ使える時間を確保し、通常業務との優先順位を経営が決めます。

完了条件を成果物と運用で定める

「アカウントを統合する」ではなく、「対象アカウント台帳が承認され、新しい認証で利用者テストが完了し、旧環境の停止と復旧手順が承認された」と定義します。社員説明なら、会議開催ではなく、資料配布、質問回収、回答公開、未回答事項の責任者まで含めます。

依存関係を先に表示する

顧客データ移行には、利用目的、契約、データ品質、アクセス権、移行環境が必要です。メール統合には、ドメイン、認証、端末、アーカイブ、顧客の許可リストが関係します。前提タスクが未完了なら、開始しない判断を明確にします。

負荷を平準化する

同じキーパーソンへ顧客挨拶、資料作成、システム移行、通常開発を集中させないよう、人別の負荷を見ます。統合会議の時間もコストです。説明を録画・文書化し、質問を集約し、外部支援を使うなど、ボトルネックを減らします。

意思決定待ちをタスクと分ける

選択肢、推奨案、判断者、判断期限、判断しない場合の影響を課題票にします。現場が調査を続けても、経営判断がなければ進まない項目があります。重大な決定を週次の進捗会議へ埋めず、決裁会議へ上げます。

アクションプランの列

IT企業 M&A PMIの週次レビュー

週次レビューでは、期限超過の追及だけでなく、前提の変化、顧客・社員の反応、技術リスク、意思決定待ちを確認します。担当者が悪い知らせを隠さないよう、早期報告を評価します。計画変更には理由と影響を残し、基準線を無言で書き換えません。

カーブアウト・分離を伴うPMIの設計

会社全体の株式取得と、事業の一部を切り出す取引ではPMIの難しさが異なります。事業譲渡や会社分割、子会社化前の切出しでは、人、契約、データ、システム、ブランド、オフィスが譲渡企業グループと共有されている場合があります。IT企業 M&A PMIでは、統合より先に安全な分離を設計します。

共有資産をサービス単位で把握する

会計、人事、メール、ネットワーク、クラウド、ソース管理、ヘルプデスク、購買、法務、広報について、誰が何を提供し、対象事業がどれだけ依存しているかを整理します。契約名義が譲渡企業本体でも、運用は対象事業の社員が担っていることがあります。名義、費用、担当、データ、障害責任を分けます。

TSAの役割

移行サービス契約、いわゆるTSAは、クロージング後も一定期間、譲渡企業が対象事業へ共有サービスを提供する設計に使われます。対象サービス、品質、時間帯、情報セキュリティ、費用、変更、終了、延長、障害時責任を明確にします。契約の要否と内容は専門家へ確認します。

TSAは移行を先送りする道具ではありません。終了日から逆算し、買い手側の受入環境、データ移行、利用者テスト、並行運用、切替判定を計画します。サービスごとに終了条件が違うため、全体を同じ日に止める必要はありません。

共有テナントからの分離

メール、ID、ファイル、チャット、CRMが譲渡企業グループの同一テナントにある場合、対象ユーザーだけ移す技術・契約上の可否を確認します。共有チャネル、グループ、配布先、アプリ連携、監査ログ、保持ポリシー、訴訟保全などが分離へ影響します。

データの境界を決める

対象事業に必要なデータ、譲渡企業に残すデータ、双方が一定期間参照するデータを分類します。複製後の更新、訂正、削除、問い合わせ対応を誰が担うか決めます。不要データを一括コピーせず、契約、利用目的、保存期間に従います。

ソースコードと共通ライブラリ

対象製品が譲渡企業共通ライブラリ、CI/CD、社内API、開発者ツールに依存する場合、権利と技術を分けます。ライセンス供与、複製、代替開発、一定期間の利用など選択肢を比較します。ビルドが通るだけでなく、保守・脆弱性・将来更新の責任を決めます。

顧客契約とブランド

一つの契約に複数事業が含まれる場合、どの法人が請求・提供・保証するかを整理します。ブランドを一定期間使う場合、表示、ドメイン、品質、終了時の変更を定めます。顧客へ契約主体と問い合わせ先を分かりやすく説明します。

分離の完了条件

• 対象事業が単独で給与、請求、支払、決算を行える
• 顧客サービスと障害対応が譲渡企業依存なしで続く
• 必要データが移行され、不要な相互アクセスがない
• クラウド、ドメイン、コード、証明書の管理者が明確
• TSA終了のテストと承認が完了している
• 残存データとアカウントの削除・保管証跡がある

PMIコミュニケーション計画の作り方

情報が少ない時期ほど、噂が空白を埋めます。コミュニケーションは、決定事項を発表する広報ではなく、信頼を維持し、現場情報を経営へ戻す双方向の仕組みです。社員、顧客、取引先、株主、金融機関、地域関係者で関心と開示可能範囲が違います。

一つのメッセージハウス

中心にM&Aの目的と顧客価値を置き、その下に社員、顧客、取引先向けの要点を整理します。相手別に説明を変えても、矛盾しないようにします。法務・広報だけで作らず、現場が実際に答えられる表現にします。

情報の順序

法令、契約、適時開示等を専門家へ確認しつつ、社内、主要顧客、一般顧客、取引先、地域への順序を設計します。ウェブ公開や報道で初めて知る関係者を減らします。時差、勤務形態、客先常駐、休職者も考慮します。

チャネルを役割で使い分ける

経営メッセージは全社会議、詳細は文書、個別不安は面談、更新はポータル、質問はフォームというように役割を分けます。チャットだけでは情報が流れ、会議だけでは欠席者が取り残されます。正式な最新情報の置き場所を一つ決めます。

FAQを生きた文書にする

質問、回答内容、回答日、対象、責任者、次回更新日を管理します。個人事案と全社事案を分けます。未決定の場合は、判断基準と予定を回答します。古い回答には無効表示を付け、検索で誤情報が出ないようにします。

管理職を情報の中継点にする

管理職が全社発表と同時に初めて聞くと、部下の質問へ答えられません。可能な範囲で事前ブリーフィングを行い、話す内容、話せない内容、相談先を共有します。対象会社の管理職だけに説明負担を負わせず、買い手側も同席します。

反応を測る

質問数の減少を安心と解釈しません。面談、短いサーベイ、欠勤、退職相談、顧客問い合わせ、商談停滞を組み合わせます。発言しにくい社員や協力会社の声を拾う窓口を設けます。個人を監視する運用にならないよう配慮します。

悪い知らせの伝え方

サービス終了、役割変更、拠点変更など不利益を伴う判断は、理由、選択肢、影響、支援、問い合わせ、実施時期を具体的に伝えます。決定を小出しにして不安を長引かせない一方、法的手続と個別説明を尊重します。

IT企業PMIで起きやすい失敗パターンと対処

失敗1：統合初日を発表イベントにする

発表準備に集中し、給与、顧客対応、障害連絡、権限が未整備になります。対処は統合初日の準備リストを事業継続から作り、広報を一つの領域として扱うことです。

失敗2：買い手標準を即時強制する

承認、ツール、開発、評価を理由なく統一すると、対象会社の速度と強みを失います。目的、便益、移行費、顧客影響を比較し、相互運用や期限付き維持も選びます。

失敗3：旧経営者へ依存し続ける

重要事項をすべて旧経営者に聞く状態では、引継ぎが進みません。業務を分解し、新責任者、共同実施、単独移行、確認の段階を置きます。

失敗4：キーパーソン以外を見ない

指定した数人だけを特別扱いし、チームの不公平感と退職を招きます。業務がチームで再現されるよう、役割、育成、引継ぎ、報酬を組織全体で設計します。

失敗5：シナジー売上を先に約束する

共同営業の責任、商品、価格、サポートが未整備なのに目標だけを置くと、顧客へ誤案内します。小さな顧客群で仮説検証し、失注・負荷も測ります。

失敗6：クラウドをコストだけで統合する

割引のためにアカウントをまとめ、権限、障害範囲、顧客契約が悪化します。構成、データ、責任、移行、ロールバックを確認してから費用最適化します。

失敗7：データを全部コピーする

利用目的、契約、品質、保持を確認せず集約すると、法務・セキュリティ・分析品質の問題になります。目的に必要な最小データで試行し、専門家へ確認します。

失敗8：課題を赤にしない

経営者へ良い報告だけが上がり、顧客解約や移行遅延が遅れて判明します。赤色の責任追及ではなく、支援と意思決定の入口にします。早期報告の行動を評価します。

失敗9：通常業務の余力を無視する

PMIタスクを既存業務へ上乗せし、開発・顧客対応が遅れます。人別負荷を見える化し、優先順位変更、外部支援、停止タスクを経営が決めます。

失敗10：100日で解散する

初期計画の完了と、買収目的の実現は同じではありません。未完了課題、KPI、責任者、予算を通常部門へ引き渡し、半年・年度など事業の節目で効果を検証します。

失敗11：対象会社だけを変える

買い手側の遅い承認、サイロ、技術負債を放置し、対象会社へ改善を求めると信頼を失います。両社を同じ尺度で診断し、優れた慣行をグループへ広げます。

失敗12：契約と実運用を別々に見る

契約上は可能でも、顧客との個別約束や現場慣行で移行できない場合があります。契約台帳と顧客・運用ヒアリングを結び、必要な同意と説明を整理します。

譲渡企業がM&A前にできるPMI準備

IT企業 M&A PMIの成否は、候補先が決まる前の組織化にも影響されます。売却のために全制度を整える必要はありませんが、何が誰に依存し、何を地域・社員・顧客のために残したいかを示せると、買い手選定と契約条件が具体的になります。

事業継続マップ

売上、請求、支払、給与、顧客対応、障害、デプロイについて、責任者、代理、手順、利用システムを一枚にします。代表者が担う項目を色分けし、引継ぎ候補を決めます。

顧客引継ぎカルテ

契約、担当、意思決定者、システム、更新、採算、懸念、地域関係を整理します。個人情報・機密情報は適切に管理し、初期段階の候補先には匿名化した情報を共有します。

キーパーソンとチーム

技術、顧客、運用、文化のキーパーソンと、代替・育成状況を確認します。本人へ不必要に売却情報を早期開示せず、守秘と説明計画を専門家と設計します。

IT資産台帳

クラウド、ドメイン、DNS、証明書、ソース、CI/CD、決済、広告、SaaS、端末、データを整理します。契約主体と管理者が会社になっているか確認します。

例外・問題の先出し

権利帰属、未払残業、顧客解約、障害、脆弱性、赤字案件などを隠さず、影響、原因、対策をまとめます。問題がない会社を装うより、管理できる会社であることを示します。

承継条件

社員雇用、拠点、社名、顧客、協力会社、旧経営者の関与、個人保証解除について、希望と優先順位を整理します。候補先のPMI方針と照合し、価格以外の条件を基本合意・最終契約で専門家と検討します。

買い手のPMI能力を見る

買収経験だけでなく、責任者、初期計画、対象会社への権限、社員・顧客説明、技術統合、予算を確認します。「買った後に考える」という候補より、残す価値と変える理由を具体的に話せる候補を評価します。

業態別PMIプレイブック：同じIT企業でも順番は違う

IT企業 M&A PMIの共通項目はあっても、価値を生む工程は業態ごとに異なります。受託開発では案件完遂、SESでは社員と客先契約、SaaSでは継続収益とプロダクト運用、MSPでは権限とSLAが優先されます。業態名だけで決めず、売上が生まれて現金化されるまでの流れに100日プランを合わせます。

地域SIer・受託開発会社

最初に、進行案件、受注残、検収、追加作業、保守、顧客窓口を確認します。PMI会議によってPMやエンジニアが通常案件から離れ、納期遅延を起こさないよう、案件ごとの繁忙期とPMI負荷を重ねます。

買い手の営業網を使うクロスセルは魅力的ですが、見積能力、要件定義、開発キャパシティ、保守責任がなければ赤字案件になります。共同提案の承認基準、責任分界、案件別粗利、顧客窓口を先に決めます。既存顧客には、担当と契約がどう継続するかを優先して説明します。

技術統合では、開発標準を一律に変えず、顧客契約、納品物、環境、検収に合わせます。新規案件から共通テンプレートを試し、進行案件の工程変更は顧客同意とリスクを確認します。地域固有の業務知識を担当者だけでなく設計書・運用手順へ移します。

SES・IT人材会社

社員説明、客先説明、契約、勤怠、給与、稼働を最優先にします。客先常駐者が社内説明へ参加できず、報道や顧客から先に知ることがないよう、時間帯と個別連絡を設計します。上位会社、エンド、再委託の商流ごとに通知・同意を確認します。

技術者別の単価、給与、稼働、待機、契約期間、スキルを共通フォーマットにします。評価制度をすぐ統一すると、現在の昇給・案件配属との期待差が生まれます。当面の評価と将来制度を分け、変更時期、移行措置、質問先を説明します。

買い手案件へ配置転換する場合、本人の能力・希望、契約、勤務地、労働条件、教育を確認します。売上シナジーだけで人を移さず、顧客との関係と本人の定着を同じKPIで見ます。IT企業 M&A PMIでは、人員表を在庫のように扱わない姿勢が重要です。

Web制作・EC支援・広告運用

顧客ごとのドメイン、DNS、サーバー、CMS、解析、広告、SNS、決済、素材、保守契約を台帳化します。個人メール、個人カード、制作担当者の多要素認証へ依存していないか確認します。買い手ツールへ移す前に、顧客所有と制作会社所有を分けます。

単発制作と月額保守・運用では統合方針が違います。単発案件は納品・検収を守り、保守は問い合わせ窓口、対応範囲、採算を確認します。広告アカウントの移管は配信停止や学習への影響を伴うため、顧客と専門担当者を交えて計画します。

制作物、写真、動画、フォント、テンプレート、プラグインの利用条件を確認します。買い手グループ内での再利用が許されるとは限りません。権利の不足があれば、代替、追加許諾、利用範囲の限定を専門家と検討します。

SaaS・自社プロダクト

統合初日ではサービス、サポート、請求、監視、障害対応を変えずに継続させます。次にARR定義、顧客別契約、解約、粗利、ロードマップ、クラウド、開発体制を確認します。買収発表を理由に既存顧客が不安にならないよう、データとサービス継続を具体的に説明します。

プロダクト統合は、機能重複だけで判断しません。顧客層、利用頻度、契約、データ、API、サポート、価格、技術を比較します。片方を終了する場合は、移行先の機能同等性、データ移行、顧客選択、返金・解約、サポート期間を設計します。

共同販売は小さな顧客群で検証し、新規ARRだけでなく解約、導入工数、サポート負荷、粗利を測ります。NRRが上がっても顧客満足や粗利が悪化していないか確認します。IT企業 M&A PMIの成功を短期ARRだけで判定しません。

MSP・クラウド運用・セキュリティ支援

顧客環境への特権アクセス、監視、オンコール、SLA、障害連絡、クラウド再販を最優先で把握します。買い手担当へ一律に権限を付与せず、顧客承諾、契約、必要性、操作ログを確認します。緊急権限と通常権限を分けます。

監視ツールやチケットを統合する場合、アラート欠落、重複、通知遅延をテストします。並行運用期間を設け、旧監視を止める条件を決めます。過去インシデントと顧客別エスカレーションを新体制へ引き継ぎます。

クラウド仕入契約、予約利用、最低利用、再販マージン、サポートレベルを確認します。購買統合の値引きだけでなく、顧客契約より長く残る原価や為替を見ます。資格者やベンダーパートナー条件の維持も責任者を置きます。

パッケージソフト・オンプレミス保守

バージョン、保守期限、顧客環境、ライセンス、カスタマイズ、ソース分岐を把握します。顧客ごとの個別版が多い場合、標準化には長期計画が必要です。古い環境でも顧客業務の中核なら、即時終了せず、保守人材と部材・開発環境を確保します。

買い手のSaaSへ移行する戦略があっても、データ、機能、ネットワーク、規制、予算の制約を確認します。移行診断、試行、並行稼働、顧客承認を計画し、販売側だけで終了日を約束しません。

ITコンサルティング・データ／AI支援

売上を生む専門家、顧客責任者、提案資産、データ利用、成果物権利を確認します。個人の評判とネットワークへ依存する場合、共同提案、後継者、ナレッジ化を段階的に進めます。買い手のブランドへ変えることで顧客が期待する中立性が変わらないかも見ます。

AI・データ案件では、学習・評価データの利用目的、顧客契約、モデル、外部サービス、再利用範囲を確認します。過去成果を買い手の別顧客へ転用できると決めつけません。モデルの性能だけでなく、再現環境、監視、説明、更新責任を引き継ぎます。

複数業態を持つ会社

受託、SES、SaaS、再販が同じ会計科目・チームに混在する場合、サービス別に顧客、契約、粗利、工数を分けます。SaaSを伸ばすため受託人員を移すと、既存顧客とキャッシュ創出を損なう可能性があります。事業間の人材・顧客・技術の依存関係を図示します。

IT企業 M&A PMIでは、法人単位の統合計画だけでなく、価値を生む業態単位のプレイブックを組み合わせます。共通管理はまとめても、顧客提供は異なる速度で変える設計が有効です。

100日後から年度計画へ：PMIを通常経営に移す

100日レビューでPMIは終わりません。初期の緊急課題が落ち着いた後は、PMI専用会議と暫定体制を通常の経営・事業運営へ移します。移管が曖昧だと、長期課題がPMI責任者の個人メモに残り、買収効果を検証できません。

未完了課題を三つに分ける

通常部門で継続する課題、経営プロジェクトとして継続する課題、前提が崩れて中止する課題に分けます。各課題へ責任者、予算、次の節目、KPIを設定します。「遅れているから継続」ではなく、今もM&A目的に必要か再評価します。

暫定権限を正式な規程へ移す

統合初日に設けた代理承認、緊急権限、例外ルートを棚卸しします。継続するものは職務権限や手順へ反映し、不要なものは廃止します。個人へ付けたクラウド・銀行・契約権限が残らないよう、人事・IT・法務の台帳を照合します。

PMI会議を減らす基準

通常の経営会議、開発会議、顧客会議で課題を扱え、重大事項のエスカレーションが機能するなら、PMI会議を統合します。単に会議回数を減らさず、意思決定ログ、課題台帳、KPIの保管先と責任を引き渡します。

シナジーを会計・顧客・業務で検証する

共同売上は、M&Aがなければ得られなかった売上かを確認し、値引き、導入、サポート、クラウド原価を差し引きます。コスト削減は、解約費、移行費、品質低下を含めます。数字だけでなく、顧客が価値を感じ、社員が再現できる仕組みになったかを確認します。

当初の投資仮説を更新する

クロージング後に分かった顧客、技術、人材、競争の事実を使い、投資仮説を更新します。買収時の計画を守るために悪い事実を無視しません。仮説変更、期待効果、追加投資、撤退条件を経営会議で決めます。

制度統合は影響評価後に行う

評価、報酬、福利厚生、会計、購買、ブランドなど長期統合は、初期の社員・顧客反応を踏まえて設計します。差異を残すコストと、統一で失う強みを比較します。法的手続と個別説明は専門家へ確認します。

技術ロードマップを事業計画へ埋め込む

リポジトリ、クラウド、データ、プロダクトの長期移行を、IT部門だけの計画にしません。顧客ロードマップ、売上、採用、予算、セキュリティ、廃止費用と結び付けます。移行のために何を開発しないかも明示します。

譲渡企業との引継ぎ完了を共同確認する

旧経営者が残る場合、顧客、採用、見積、資金、技術、地域関係を新責任者が担えるか確認します。未解決事項を理由に関与を無期限延長せず、追加支援の範囲と対価を契約に沿って整理します。

IT企業 M&A PMIの事後レビュー

何が計画どおり進み、何を見落とし、どの意思決定が価値を生んだかを記録します。次のM&Aへ流用できるのはToDo一覧ではなく、判断基準、データ、失敗、成果物です。対象会社社員もレビューへ参加し、一方的な評価にしません。

IT企業 M&A PMI実務チェックリスト

経営・ガバナンス

• M&Aの目的と成功定義を一文で説明できる
• 統合する・接続する・維持する・終了する基準がある
• 経営会議、PMI責任者、領域責任者が決まっている
• 意思決定ログ、課題台帳、変更管理がある
• 統合費用とシナジーを別管理している
• 100日後の長期ロードマップへの移管方法がある

社員・組織

• 社員説明、FAQ、匿名質問、個別面談を準備した
• 変更済み・検討中・維持を分けて伝える
• キーパーソンを業務・技術・顧客・文化で把握した
• 役割、権限、評価、報酬、勤務地の説明計画がある
• 旧経営者の引継ぎを業務単位で定めた
• スキーム別の労働手続を専門家へ確認した

顧客・事業

• 顧客を重要度と懸念で分類した
• 契約の通知・同意・支配権変更を確認した
• 顧客説明の順序、担当、FAQがある
• 見積、値引き、SLA、再委託の承認権限がある
• 顧客別・案件別・サービス別の採算を見られる
• 顧客の声をリスク台帳へ反映している

開発・プロダクト

• プロダクトの統合・共存・終了方針がある
• ロードマップと営業約束を照合した
• リポジトリ、CI/CD、Secrets、成果物を把握した
• 知的財産とOSSライセンスを確認した
• 技術負債を事業影響で優先順位付けした
• 移行テスト、ロールバック、停止条件がある

クラウド・セキュリティ

• クラウド資産、契約、管理者、費用を台帳化した
• ネットワーク接続の必要通信と遮断方法がある
• 人・機械・顧客IDを分けている
• 特権ID、退職者権限、緊急権限を確認した
• バックアップ復元を検証した
• インシデント指揮、連絡、顧客対応を統合した

データ・契約

• 重要データの利用目的、保存、委託、削除を把握した
• 事業承継後の利用目的を専門家と確認した
• 移行件数・整合性・権限・削除を検証する
• ドメイン、決済、証明書等の名義を確認した
• ライセンスの譲渡・支配権変更条件を確認した
• 旧環境の停止・保管・廃棄証跡を定めた

IT企業 M&A PMIに関するよくある質問

Q1．PMIはクロージング後に考えればよいですか？

成立後にしか実行できない事項はありますが、統合初日の社員・顧客説明、支払、権限、緊急対応は事前準備が必要です。法令・契約・競争上の制約に配慮しながら、クロージング前に計画と体制を作ります。

Q2．100日以内に全システムを統合すべきですか？

いいえ。100日は管理上の節目であり、一律の期限ではありません。大規模な基幹・クラウド移行は、要件、テスト、ロールバックを優先します。100日までに責任者、方式、予算、判断条件を固める方が安全です。

Q3．統合初日で最初に行うことは何ですか？

社員と顧客へ、目的、変わること、変わらないこと、問い合わせ先を伝え、給与、請求、サービス、障害対応を継続します。検証なしの一括システム変更は避けます。

Q4．社員にはどこまで説明すべきですか？

守秘や個人情報に配慮しつつ、自分の仕事へ影響する決定事項、検討事項、判断時期を具体的に伝えます。「何も変わらない」と断定せず、質問窓口と次の更新時期を示します。

Q5．キーパーソンへ報奨金を出せば定着しますか？

金銭は選択肢の一つですが、役割、裁量、成長、評価、働き方が不明なら十分ではありません。チーム全体の公平性と事業継続を考え、法務・税務を専門家へ確認します。

Q6．顧客への説明は一斉メールで十分ですか？

重要顧客、規制顧客、共同開発先等は個別説明が適します。契約、担当、サービス、データへの影響を伝え、懸念を100日プランへ戻します。説明順序も重要です。

Q7．買い手のツールへ統一した方が早いですか？

統一が最適とは限りません。まず相互運用と可視化を確保し、移行便益、顧客要件、データ、教育、停止リスク、契約を比較します。維持する判断にも見直し条件を置きます。

Q8．開発組織の統合は何から始めますか？

プロダクトの顧客価値と継続方針を確認し、要求からリリース・障害までの実態を比較します。コードやリポジトリの移行は、権限、CI/CD、Secrets、履歴、ロールバックと一体で計画します。

Q9．クラウドアカウントはすぐ集約すべきですか？

まず契約、データ、管理者、ネットワーク、顧客要件、予約契約を把握します。共同監視や請求可視化を先に行い、アカウント移行はテストと障害範囲を確認して進めます。

Q10．M&Aなら顧客データを買い手の分析基盤へ移せますか？

M&Aという理由だけで無制限に利用できるわけではありません。取引スキーム、承継前の利用目的、契約、本人同意、安全管理を確認します。個人情報保護委員会の公式資料を参照し、個別案件は専門家へ相談してください。

Q11．セキュリティ基準は買い手側へ即時統一しますか？

重大リスクは早期対応しますが、機械的な一括変更でサービスを止めないよう、資産重要度と移行リスクで順序を決めます。満たせない項目は代替統制、責任者、期限を承認します。

Q12．文化統合はどう測れますか？

抽象的な相性ではなく、意思決定速度、会議、報告、レビュー、顧客対応、質問、退職兆候などの行動を確認します。統合後に必要な行動原則と具体例を共同で定めます。

Q13．旧経営者にはどれくらい残ってもらうべきですか？

期間だけでは決められません。顧客、見積、採用、資金、技術、地域関係など引継ぎ業務を分解し、新責任者が単独で担える判定条件を置きます。契約条件は専門家へ確認します。

Q14．PMIの進捗はタスク完了率で見ればよいですか？

完了率に加え、買収目的、売上・解約・障害、社員定着、顧客懸念、統合費用を確認します。完了しても価値を生まないタスクや、現場負荷を高める施策を見直します。

Q15．譲渡企業はPMIにどう関与しますか？

暗黙の業務、顧客関係、キーパーソン、例外契約、地域で守る条件を説明し、共同引継ぎを行います。買い手へ任せきりにせず、同時に旧経営者依存を計画的に解消します。

Q16．小規模IT企業でもPMOは必要ですか？

大きな専任組織は不要でも、全体責任者、領域担当、会議、課題台帳、決定ログは必要です。兼務の場合はPMIに使える時間と優先順位を経営者が明確にします。

まとめ：100日で「統合完了」ではなく、価値が続く経営へ

IT企業 M&A PMIでは、統合初日に事業と信頼を守り、初期に事実を把握し、100日プランで優先課題を仕組みへ移します。会計やツールの統一だけでなく、社員、顧客、開発、クラウド、ID、データ、契約を買収目的から逆算します。

重要なのは、速さと安全を対立させないことです。可逆的な改善は早く試し、不可逆的な移行は責任者、テスト、顧客影響、ロールバックを設計します。買い手標準へ一律に合わせず、対象会社の地域関係、開発文化、顧客価値を残す選択もPMIです。

中小企業庁が公表するPMI分析ワークシート、アクションプラン、統合方針書は、目的確認、優先課題、担当・予定、社内外説明を整理する出発点になります。ひな形を埋めることをゴールにせず、自社の重要業務とリスクへ合わせて使います。

IT企業のM&A全体像はIT企業・Web事業のM&A支援、当センターの方針は私たちについてもご覧ください。売却準備段階から引継ぎ・PMIを見据えることで、候補先選定と契約条件を具体化できます。