LASSIC Media らしくメディア
M&A後のシステム統合(PMI)の要点
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- M&A後のシステム統合(PMI)は、統合効果の実現とリスク回避を左右する経営イベントです。
- ITデューデリジェンスから統合方針の決定、要件定義、移行、安定稼働までの進め方を整理します。
- 基盤系と業務系で統合の優先順位を分け、外部の専門支援をどこで活用するかが成否の分かれ目です。
目次
M&A後のIT統合が経営課題になる理由
M&Aシステム統合のPMI（Post Merger Integration、M&A成立後の統合プロセス）とは、買収・合併の成立後に両社のITシステム・業務基盤を一体運用できる状態へ移行させる取り組みを指します。財務や人事の統合と並び、事業運営の土台を支える工程です。
中小企業庁が2022年3月に策定した「中小PMIガイドライン」では、PMIの取組を「経営統合」「信頼関係構築」「業務統合」の3領域に分類しています*1。ITシステムは会計・人事労務・法務と並ぶ管理機能の一つとして、業務統合の領域に位置づけられます*1。
同ガイドラインは、PMI推進体制の確立・関係者との信頼関係構築・M&A成立後の現状把握について、成立から100日を目処に集中的に実行することが望ましいとしています*1。ITシステムの現状把握もこの初期100日の対象に含まれ、統合の遅れが後工程全体の遅延につながる点に注意が必要です。
IT統合が経営課題として重くなる理由は、統合効果（シナジー）の実現時期に直結するためです。会計・受発注・顧客管理などの業務システムが分断されたままでは、グループ間の情報連携や意思決定のスピードが上がりません。統合方針を誤ると、想定していたコスト削減や業務効率化が計画どおりに実現しない事態も起こり得ます。
ITデューデリジェンスで把握する3つの領域
ITデューデリジェンス（IT DD。買収前に対象企業のIT資産・リスクを調査する手続き）は、PMI本番の統合作業とは目的が異なります。DDは意思決定のためのリスク把握、PMIは決定後の実行フェーズという役割の違いを最初に押さえておく必要があります。
第一に把握すべきは、システム資産の全体像です。使用しているソフトウェア・ハードウェア・クラウドサービス、ライセンス契約の残存期間、保守ベンダーとの契約条件を棚卸しします。この段階で契約の解除条件や移管条項を確認しておかないと、統合実行段階で想定外の違約金や移行遅延が発生します。
第二に把握すべきは、セキュリティ・コンプライアンスの状態です。認証基盤の管理状況、アクセス権限の運用実態、過去のセキュリティインシデントの有無を確認します。買収対象企業側のセキュリティ水準が低い場合、統合後に自社グループ全体のリスクとして波及する可能性があるため、DD段階での発見が重要です。
第三に把握すべきは、業務システムと業務プロセスの対応関係です。会計・人事・受発注・顧客管理などの基幹システムが、どの業務プロセスをどこまでカバーしているかを確認します。システムの機能だけでなく、現場がどのようにカスタマイズして運用しているかまで含めて把握しないと、統合後の要件定義で漏れが生じます。
DDで判明した情報は、次章で説明する統合方針の決定に直接反映されます。DDの精度が低いまま統合方針を決めると、後工程での手戻りが発生しやすくなる点に注意が必要です。
片寄せ・ベスト・オブ・ブリード・共存 — 統合方針3パターンの選び方
IT PMIにおける統合方針は、実務上大きく3つのパターンに整理できます。どのパターンを選ぶかによって、必要な予算・期間・現場への影響が大きく変わります。
パターンAは、買収元のシステムへ統一する「片寄せ」です。買収された側のシステムを廃止し、買収元の基幹システムへ業務を移行します。新規システム導入のコストを抑えられる一方、買収された側の従業員にとっては業務フローの変更が大きくなります。
パターンBは、ベスト・オブ・ブリードと呼ばれる方式です。両社のシステムを比較し、機能・使い勝手・保守性で優れている側を採用します。単純な片寄せより統合後の業務効率は高まりやすい一方、比較検討と移行設計に要する工数は増えます。
パターンCは、当面の間、両社のシステムを共存させる方式です。統合の緊急度が低い業務領域や、統合コストが統合効果を上回ると判断された領域で選ばれます。ただし共存状態を長期化させると、二重管理のコストが継続する点に留意が必要です。
実務では、これら3パターンを業務領域ごとに使い分けるハイブリッド型が現実的です。メール・認証基盤・セキュリティ対策などの基盤系システムは、グループ全体のガバナンスに直結するため早期に統一する判断が一般的です。一方、会計・受発注・顧客管理などの業務系アプリケーションは、業務への影響が大きいため段階的に統合を進める考え方が実務上定着しています。
現状分析から安定稼働までの5段階プロセス
IT PMIの実行プロセスは、現状分析・統合方針決定・要件定義・移行・安定稼働の5段階に整理できます。前章までの内容を踏まえ、ここでは実行段階の流れを説明します。
最初の段階は、DDで把握した情報をもとにした詳細な現状分析です。DD時点では概要レベルだった情報を、統合実行に耐えられる粒度まで精緻化します。データ量・利用者数・業務上の依存関係を洗い出し、統合の難易度を業務領域ごとに評価します。
次の段階は、前章で整理した3パターンをもとにした統合方針の確定です。経営層・現場・情報システム部門が合意した方針を「統合方針書」として文書化し、以降の工程の判断基準とします。方針が曖昧なまま次工程に進むと、要件定義の途中で方針の揺り戻しが発生しやすくなります。
三段階目は、要件定義と設計です。統合方針に基づき、システムごとの機能要件・データ移行要件・スケジュールを具体化します。基盤系は影響範囲が広いため、切替時の業務停止時間や代替手順まで含めて設計する必要があります。
四段階目は、移行の実行です。テスト環境での検証を経て、本番環境への切替を行います。切替は業務影響を最小化するため、休日や業務閑散期に実施するケースが一般的です。
五段階目は、安定稼働への移行です。切替後一定期間はシステムの稼働状況を注視し、不具合や操作上の混乱に迅速に対応する体制を維持します。この段階を軽視すると、現場の定着が進まず、旧システムへの回帰要望が強まるリスクがあります。
Day1対応・データ移行・体制 — 陥りやすい失敗と回避策
IT PMIで繰り返し指摘される失敗パターンには共通点があります。ここでは代表的な3つと回避の考え方を整理します。
第一に、Day1（M&A成立初日）対応の準備不足です。成立日から従業員がメール・勤怠・給与計算といった最低限の業務を止めずに継続できる状態を整えておく必要があります。認証基盤やメール環境の統合方針が固まっていないままDay1を迎えると、業務が一時的に停止する事態が起こり得ます。基盤系システムの早期統一が実務上優先される理由の一つはここにあります。
第二に、データ移行の設計不足です。データ移行を誤ると、統合後の業務で必要な取引履歴や顧客情報が欠落し、業務が正しく回らなくなる可能性があります。移行対象データの範囲・移行後の検証方法・移行できなかったデータの扱いを、要件定義の段階で明確にしておく必要があります。
第三に、体制とキーパーソンの離脱です。買収された企業側で業務システムの内容を把握している担当者が、統合作業の途中で離職・異動すると、業務知識の空白が生じます。PMI推進責任者は、統合完了までキーパーソンが関与し続けられる体制を早期に確保することが求められます。
これら3つに共通するのは、対応を先送りにするほど手戻りのコストが大きくなるという性質です。統合作業を内製で完結させるには、システム調査・データ移行設計・切替リハーサルの各工程で相応の人員と期間を要します。社内の情報システム部門だけで対応が難しい場合、どの工程を外部に委ねるかを早期に判断することが、スケジュール遅延を防ぐ実務上のポイントです。
内製リソース不足を補う外部専門支援の活用
IT PMIは、通常の情報システム部門の業務に加えて発生する一時的かつ専門性の高い業務です。既存の運用保守業務と並行して対応する必要があるため、社内リソースだけで完結させることが難しい場面が少なくありません。
外部の専門支援を活用する場面は、大きく2つに分かれます。一つは、ITデューデリジェンスの実務支援です。買収検討段階から専門知見を持つ外部パートナーが関与することで、DD項目の抜け漏れを防ぎ、統合方針の検討材料をより正確にそろえられます。もう一つは、統合実行段階でのシステム開発・データ移行・切替作業の実装支援です。要件定義から設計・開発・テスト・移行までを担当し、社内の情報システム部門は意思決定と業務側との調整に専念できる体制を組めます。
外部支援を活用する際は、統合完了後の運用保守体制まで見据えて依頼範囲を決めることが重要です。移行作業だけを依頼し、統合後の保守体制を検討しないまま契約が終了すると、安定稼働段階で対応できる担当者が不在になる事態が生じます。ニアショア（国内地方拠点での開発体制）を含めた継続的な保守運用体制まで一体で相談できるパートナーを選ぶことで、統合後の運用リスクを抑えられます。
まとめ：IT PMIを進めるための3つの判断軸
本稿では、M&A後のシステム統合(PMI)における進め方と判断のポイントを整理しました。要点を3つに集約すると次の通りです。第一に、ITデューデリジェンスで資産・セキュリティ・業務対応関係を精緻に把握することが、統合方針決定の前提になります*1。第二に、統合方針は片寄せ・ベスト・オブ・ブリード・共存の3パターンを業務領域ごとに使い分け、基盤系は早期統一、業務系は段階統合という考え方が実務上定着しています。第三に、Day1対応・データ移行・体制維持という3つの失敗要因を早期に潰し込み、内製で対応が難しい工程は外部の専門支援を活用することが、統合効果の実現につながる判断軸になります。
よくある質問
IT PMIはM&A成立後どのくらいの期間で完了させるべきですか。
中小企業庁の「中小PMIガイドライン」では、体制確立・信頼関係構築・現状把握を成立後100日を目処に集中的に実行することが望ましいとされています*1。ただし基幹システムの全面統合まで含めると、業務範囲や既存システムの複雑さに応じて100日を超える期間を要するケースが一般的です。
ITデューデリジェンスとPMIの違いは何ですか。
ITデューデリジェンスは買収前にリスクと機会を把握し、意思決定を支える調査です。PMIは買収成立後、決定した方針に基づいてシステムを実際に統合する実行フェーズです。DDの精度が低いと、PMI段階での手戻りが発生しやすくなります。
基盤系と業務系はどちらを先に統合すべきですか。
メール・認証基盤・セキュリティ対策などの基盤系は、グループ全体のガバナンスに関わるため早期統一が優先されるのが実務上一般的です。会計・受発注などの業務系アプリケーションは業務影響が大きいため、優先順位を付けて段階的に統合を進める進め方が現実的です。
データ移行で特に注意すべき点は何ですか。
移行対象データの範囲、移行後の検証方法、移行できないデータの扱いを要件定義の段階で明確にしておくことが重要です。曖昧なまま移行を実行すると、取引履歴や顧客情報の欠落に気づかず統合後の業務に支障が出る可能性があります。
社内の情報システム部門だけでIT PMIに対応できますか。
既存の運用保守業務と並行してPMI対応を進める必要があるため、社内リソースのみで完結させることが難しい場面があります。ITデューデリジェンスの実務支援や、要件定義から移行までの実装支援を外部の専門パートナーに依頼し、社内は意思決定と業務調整に専念する体制も選択肢になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：中小企業庁「中小PMIガイドライン～中小M&Aを成功に導くために～」（2022年）https://www.chusho.meti.go.jp/zaimu/shoukei/download/pmi_guideline.pdf
