PMIの遅延は、技術統合で最も拡大する

PMI（Post Merger Integration）が計画通りに終わるケースは少ない。私たちが見てきた案件では、計画の1.5倍から2倍の期間がかかることが多く、遅延の原因を分解すると、技術統合のフェーズに集中する傾向がある。

中堅企業の国内案件に限れば、組織統合は数ヶ月で形ができることが多い。人事制度の統一、レポートラインの再設定、オフィスの統廃合。やることは多いが、判断基準が明確で、前例もある。財務統合も同様で、会計システムの一本化、連結決算への組み込みは手順が確立している。

技術統合だけが異質だ。「何がどうなっているのか」の把握に3ヶ月かかり、「どう統合するか」の設計にさらに3ヶ月、実行に6ヶ月以上。最初の一歩が調査であるという点が、他の統合領域と根本的に違う。

技術統合が後回しにされる理由

PMI計画の初期段階で技術統合の優先度が下がりやすい構造がある。

1つ目は、意思決定者がシステムの内部を見えていないこと。M&Aの意思決定層はCEO・CFO・事業部門長であることが多く、システムは「動いていれば問題ない」という前提で扱われる。テクノロジーDDを実施していない案件では、システムの全体像を把握している人間が買い手側に存在しないまま統合が始まる。

2つ目は、技術統合の見積もりが難しいこと。組織統合のコストは人件費ベースで見積もれる。財務統合はシステム導入費用で見積もれる。だが技術統合は、既存システムの状態によって工数が10倍変わる。正確な見積もりには調査が必要で、その調査自体にコストと時間がかかるという循環がある。

3つ目は、統合しなくてもしばらく動くこと。2つのシステムが並行稼働する状態は非効率だが、業務は止まらない。この「止まらない」という事実が、技術統合の緊急度を下げる。結果として、組織と財務が統合された後に、2つのシステムを1つにするという最も複雑な作業が残る。

中堅企業の買収案件で頻出する技術統合の課題を整理する。

システム重複の整理。買い手と売り手がそれぞれCRM、会計、在庫管理を持っている状態では、どちらに寄せるか、新システムに移行するかの判断が必要になる。この判断にはデータ移行の工数見積もりが不可欠で、それには両方のシステムのデータ構造を理解しなければならない。

認証・権限の統合。2つの会社が別々のActive DirectoryやSSOを持っている場合、全従業員のアカウント統合が必要になる。これは組織統合の「レポートライン変更」とは別の話で、メールアドレス、アクセス権限、VPN設定、SaaS契約のすべてに波及する。

データ移行の不確実性。売り手のデータベースが正規化されていない、文字コードが混在している、重複レコードが大量にある。データの品質問題は、実際に移行を試みるまで正確な規模が分からない。テスト移行で初めて判明する問題が全体スケジュールを狂わせる。

技術統合の遅延はシステムの問題だけではない。システムを知っている人が離れる問題でもある。

買収後にキーパーソンが退職すると、システムの全体像を把握している人間がいなくなる。暗黙知——どのバッチ処理がどの業務に影響するか、なぜこの設定になっているか——が一緒に消える。技術統合の見積もりが狂う最大の要因は、システムの複雑さそのものではなく、それを理解していた人がいなくなることだ。

組織統合で人間関係が壊れ、関係資本が流出し、その結果として技術統合も遅れる。技術と人の問題は連動している。

テクノロジーDDをM&Aの検討段階で実施していれば、PMI計画の精度は大幅に上がる。システムの全体像、技術負債の規模、属人性のリスク、データ資産の状態。これらが事前に分かっていれば、技術統合の工数見積もりが現実に即したものになる。

逆に、テクノロジーDDなしでPMIに入ると、統合の初期フェーズがそのまま調査フェーズになる。買収後に「思っていたより大変だった」が起きるのは、買う前に見ていなかっただけだ。

私たちはテクノロジーDDからPMIまでを一貫して支援する。検討段階で把握した技術情報をそのままPMI計画に引き継ぐことで、調査の二度手間をなくし、統合期間を短縮する。M&Aの成功は成立した瞬間ではなく、統合が完了した時点で決まる。