M&A時のIT統合（PMI）で失敗しないために、買収前に確認すべきITデューデリジェンス

「買ってから、想像と違うIT実態が次々に出てきた」を防げていますか

念願のM&Aを成立させ、いざ統合のフェーズに入る。ところが買収先の社内に足を踏み入れた途端、「サーバーが何台あるか誰も正確に把握していない」「主要業務が15年前の自社開発システムでしか動かない」「肝心の顧客データが、誰の管理下にあるのか不明」——こうした想定外が次々と顔を出し、統合プロジェクトが当初の計画から大きくぶれていく。M&Aを経験した買い手の多くが、PMI（Post Merger Integration、買収後統合）の現場でこの種の現実に直面しています。

経営や財務のデューデリジェンスは厳格に行われたのに、ITだけは「まあ、買ってから整えればいい」と扱われてしまう。あるいは、技術的な話が分かりにくく、専門家任せにしているうちに、肝心のリスクが見落とされる。結果として、買収後の統合期に追加コストが膨らみ、想定していたシナジーも遅れ、最悪の場合は買収そのものの正当性が問い直されます。M&Aの成否は契約書にサインした瞬間ではなく、その後の統合がうまく走るかで決まる——その統合を最初に左右するのが、買収前にITをどこまで見抜けていたかです。

IT統合の失敗は「買収後の頑張り」では取り戻せません

最初に申し上げておきたいのは、PMIにおけるIT統合の失敗の多くは、買収後の対処能力の不足が原因ではない、ということです。実際には、契約前のITデューデリジェンスで、見るべきものを見ていなかったことに、ほとんどの問題の根が埋まっています。

買収前に分からないままサインしたITリスクは、買収後にすべて買い手側のコストとして顕在化します。古い基幹システムの刷新費用、ライセンスの整理費用、セキュリティの是正費用、データ移行の難航、ベンダーロックインによる解約違約金——これらは、買ってしまった後では「やるしかない」ものに変わり、価格交渉のテーブルにも乗せられません。だからこそ重要なのは、買収後の統合プランの精度を上げることよりも、契約前に何を確認し、どのリスクを価格や契約条件に織り込むかです。逆に言えば、ここさえ押さえれば、PMIは「想定の範囲内」で進められます。IT統合の難易度は、契約前の数週間の見方ひとつで、大きく変わります。

この記事は「契約前に見ておくべき4領域」を整理します

そこでこの記事では、ITデューデリジェンスで買収前に必ず確認しておくべき4つの領域を整理します。専門用語を並べるのではなく、経営層や事業責任者でも自分で質問・確認できるレベルの観点に絞り、何を見て、何を聞き、どこにリスクの値札をつけるべきかをお伝えします。

ポイントは、ITデューデリジェンスを「監査」ではなく「統合のための調査」として捉え直すことです。減点法でリスクを並べるだけでは、買うか買わないかの判断にしかつながりません。そうではなく、「買った後、何にいくらかかり、どこから手をつけるか」をシミュレーションするための情報を取りに行く——この視点でデューデリジェンスを設計すれば、契約後の初動が一気に滑らかになります。読み終える頃には、自社のM&A検討に持ち込める、現実的なIT観点のチェックリストが手元にある状態を目指します。

契約前の調査で統合シナリオを描いておく

買収前に必ず確認すべき4つのIT領域

ここからが本題です。PMIで火を噴きがちなポイントを逆算して、契約前のITデューデリジェンスで見ておくべき領域を、4つに整理してお伝えします。

領域1：システム資産の全体像と老朽化の度合い

最初に確認すべきは、買収先がどんなシステムを、どれだけ、どんな状態で持っているかという、IT資産そのものの全体像です。ここが曖昧なまま契約してしまうと、統合後に「実は基幹システムが社長の親族しか触れない代物だった」といった事態に直結します。

具体的には、(1) 業務で使われている主要なシステムの一覧（基幹、会計、販売管理、顧客管理、生産管理など）、(2) それぞれが自社開発か、パッケージか、クラウドサービスか、(3) 導入時期と、最後に大きく改修したのはいつか、(4) サーバーは社内かクラウドか、その台数とおおよそのスペック——この4点をまず把握します。注目すべきは「年齢」と「依存度」です。10年以上前に作られた自社開発システムが基幹を担っている場合、ドキュメントは失われ、改修できる人材も限られ、ハードウェアの保守期限も迫っている——という三重苦になっているケースが少なくありません。ここに該当する資産があれば、買収後の刷新コストとして、価格交渉のテーブルに乗せるべきリスクです。

領域2：ベンダー・ライセンス・契約の縛り

次に重要なのが、買収先が外部のベンダーやライセンスとどう契約しているかという、契約面の縛りです。経営DDでは契約書一覧を確認するのが当然ですが、IT契約はその性質上、見落とされがちなトラップが潜んでいます。

確認したいのは、(1) 主要システムごとのベンダー、保守契約の内容と年額、(2) ライセンスの種類（買い切り型か、年額サブスクか、ユーザー数連動か）と、その上限・余裕、(3) 自動更新条項や、解約に伴う違約金・データ持ち出し条件、(4) 知的財産の帰属——特に自社開発を外注した場合、ソースコードや成果物の権利が誰のものになっているか。落とし穴になりやすいのは、「契約は安いがベンダーロックが強烈で、他社に切り替えると数千万円の移行費用がかかる」「ユーザー数ライセンスが既に上限ギリギリで、統合で社員が増えると即追加費用」といったケースです。ここを契約前に把握しておけば、買収価格の調整や、契約後すぐの対応プランに反映できます。

領域3：セキュリティ・データの状態・コンプライアンス

3つ目は、最も「見えにくく」かつ「事故ったときの被害が大きい」、セキュリティとデータの状態です。買収先の情報漏洩リスクや、データ管理の杜撰さは、買った後にすべて買い手の責任に転じます。

押さえるべきは、(1) 顧客データや個人情報の保管場所と、アクセスできる人の範囲、(2) バックアップの有無、頻度、保管場所（社内のみか、社外にも複製があるか）、(3) 過去のセキュリティインシデントの有無と、対応の記録、(4) 業界によっては求められる規格（Pマーク、ISMS等）の取得状況、(5) 退職者のアカウントが残ったままになっていないか——といった点です。とくに、退職者アカウントの放置、共有パスワードの常態化、外部公開サーバーへのパッチ未適用、といった「日常の油断」は、契約後にあぶり出されると、是正に時間も費用もかかります。発覚済みのインシデントよりも、「まだ気づかれていない穴」を見抜くつもりで質問を重ねるのが、この領域のコツです。

領域4：属人化・運用体制と、IT担当者の継続意向

4つ目は、システムそのものではなく、それを動かしている人と運用の状態です。実は、ハードウェアやソフトウェア以上に、ここがPMIの初期を左右します。

確認したいのは、(1) 社内のIT担当者は誰で、何人いて、どこまで業務をカバーしているか（情シス機能が社長や経理担当の兼務になっていないか）、(2) その担当者は、M&A後も継続して在籍する意向か、(3) 主要システムの仕様や操作手順が、属人的な「あの人しか知らない」状態になっていないか、(4) 障害対応や定期メンテナンスの体制——休日夜間に何かあったとき、誰がどう動くのか。ここに「特定の1人に全てが集中している」状況があると、その人が退職した瞬間にIT運用が崩れ、統合どころではなくなります。買収後の早い段階で属人性を解きほぐし、運用を内側から立て直すには、外部の伴走支援を組み合わせるのが現実的です。情シス機能を月額制でアウトソースしながら社内のリテラシーも同時に育てていける月額制自社DX推進部のような仕組みを使えば、買収先の運用を引き継ぎつつ、PMI初期の混乱を抑えながら統合体制を整えていけます。

資産・契約・セキュリティ・運用の4領域

こんな立場の方に、このITデューデリジェンス観点をおすすめします

M&Aで会社を買う側として、IT統合（PMI）の初動でつまずきたくない経営層・事業責任者の方
過去のM&Aで「買収後にITの想定外コストが膨らんだ」苦い経験があり、次は契約前にリスクを見極めたいと考えている方
自社にIT専門人材が少なく、ITデューデリジェンスを誰にどこまで委ねるか、判断の物差しを持ちたいDX推進担当・経営企画の方

ITデューデリジェンスは、契約書にサインする前にしか効果を発揮しません。契約後に分かったITリスクは、価格にも条件にも反映できず、ほぼ全額が買い手のコストになります。逆に、契約前にリスクを正しく値札としてつけられれば、買収価格の調整、契約条項の追加、統合後100日プランの精度向上——その全てに直結します。「IT領域は契約後に整える」という発想を、「IT領域こそ契約前に見抜く」へと切り替えることが、PMI成功の最初の分岐点です。

まとめ

契約前のIT観点を押さえて統合をスムーズに進める買い手の姿

PMIにおけるIT統合の失敗の多くは、買収後の対処能力の不足ではなく、契約前のITデューデリジェンスで見るべきものを見ていなかったことに起因します。だからこそ重要なのは、契約後の統合プランの精度を上げることよりも、契約前に何を確認し、どのリスクを価格や契約条件に織り込むかです。

押さえるべきは、(1) システム資産の全体像と老朽化の度合い、(2) ベンダー・ライセンス・契約の縛り、(3) セキュリティ・データの状態・コンプライアンス、(4) 属人化と運用体制——この4領域です。いずれも「監査として減点する」ためではなく、「買った後、何にいくらかかり、どこから手をつけるか」というシミュレーションのための情報を取りにいく、という視点で進めるのがコツです。

まずは、検討中の案件について「契約前に必ずこの4領域の状態を確認する」と決めて、買収先に質問する項目を一覧化してみてください。一覧をつくる過程で、自分たちが今まで漠然と捉えていたITリスクが、具体的な確認事項に変わっていきます。M&Aの成否を分けるのは、ディールメイクの巧みさだけではなく、契約前の数週間で、ITの実態をどこまで解像度高く描けるかです。その解像度こそが、PMI初動の混乱を抑え、シナジーを当初計画どおりに刈り取るための、最も確実な投資になります。