---
title: "M&AのPMIとは：100日プランとシステム統合をDay1から1年で進める手順"
url: "https://www.issoh.co.jp/column/details/19338/"
published: 2026-11-05
updated: 2026-11-05
categories: ["IPO"]
publisher: "株式会社一創"
---

# M&AのPMIとは：100日プランとシステム統合をDay1から1年で進める手順

M&AのPMI（Post Merger Integration）は、買収や合併が成立した後に、経営・業務・システムを一つの会社として動かせる状態へ寄せていく統合作業です。中小企業庁の中小PMIガイドラインは、成立後の約1年を集中して取り組む期間と定め、最初の100日に体制づくりと現状把握を終えるよう求めています。この記事では、プレPMI・PMI・ポストPMIの3段階を整理したうえで、100日プランをDay1・Day30・Day100の区切りでどう組むかを、基幹システム・会計・顧客データ・アカウントの統合工程に落とした解説です。システム統合を急がない方がよい場面と、例外的に早く手を入れるべき場面も条件付きで示します。

## まとめ：M&AのPMIは100日で現状を固め、システム統合は1年で決める

PMIの最初の100日でやることは、システムを入れ替えることではありません。業務を止めずに引き継ぎ、誰が何を管理しているかを把握し、統合の方針を決める材料をそろえる期間です。

システム面の優先順位ははっきりしています。Day1までに受発注・請求・給与など止められない業務を特定し、Day30までに管理者アカウントとライセンスの名義を確かめ、Day100までに勘定科目と月次報告の型をそろえる。基幹システムをどちらかに寄せるか、新しく作るかの判断は、その後の集中実施期の後半から1年の中で行います。

例外はサポートが切れたOSやソフトウェア、ライセンス違反の疑いがある利用です。これらは統合方針を待たずに、見つけた時点で手当てします。逆に、買収した会社を独立した子会社として運営する計画なら、基幹システムの統合そのものを見送るのが妥当です。

## M&AのPMIとは何か：プレPMI・PMI・ポストPMIの3段階と取組範囲

### 中小PMIガイドラインが定めるPMIの範囲とDay1・Day100の数え方

中小企業庁は「PMIを実施する」のページで、PMIを「主にM&A成立後に行われる統合に向けた作業」であり、M&Aの目的を実現させ統合の効果を最大化するためのプロセスだと説明しています。令和4年3月に公表された[中小PMIガイドライン（中小企業庁・PDF）](https://www.chusho.meti.go.jp/zaimu/shoukei/download/pmi%5Fguideline.pdf)は、この取組を時期で3つに分けています。

| 段階         | ガイドラインの定義       | システム面で主にやること            |
| ---------- | --------------- | ----------------------- |
| プレPMI      | M&A成立前の取組       | DDでIT資産・契約・データの所在を把握    |
| PMI（集中実施期） | 成立後から一定期間（1年程度） | 業務継続、名義確認、会計の統一、統合方式の決定 |
| ポストPMI     | その後に継続する取組      | 統合・刷新の実行と効果検証           |

日付の数え方も決まっています。成立後の初日をDay.1、100日目をDay.100と呼びます。100日プランは、この集中実施期の前半を区切った計画のことです。

### 経営統合・信頼関係構築・業務統合のうちITシステムが入る位置

ガイドラインは取組を、経営の方向性や体制をそろえる経営統合、従業員や取引先との信頼関係の構築、事業機能と管理機能をそろえる業務統合に分けています。ITシステムは業務統合の中の管理機能に入り、人事・労務、会計・財務、法務と並ぶ4分野の一つです。

この位置付けが示すのは、システム統合が単独のプロジェクトではないという点です。会計の勘定科目をそろえる話も、人事の勤怠ルールを合わせる話も、最後はシステムの設定やデータ項目に降りてきます。PMIの体制を組む段階で、各分野の担当とシステムの担当を同じ会議体に入れておくと、決めた方針が設定に反映されないまま放置される事態を防ぐことが可能です。ガイドラインはITシステム分野の支援機関としてITベンダーやスマートSMEサポーターを挙げています。

## プレPMIで決める統合方針とDDから引き継ぐシステム情報の範囲

### クロージング前に集中実施期の計画を立てておく理由と引継ぎ資料

ガイドラインは、クロージング前に「何が把握できていないか」を洗い出し、「M&A成立後の集中実施期に何をするか」を予め計画しておくよう求めています。成立後は経営者の面談、従業員への説明、取引先対応が一度に押し寄せるため、計画を一から作る余裕がありません。

計画の材料として引き継ぐ資料は、企業概要書（IM）、DD調査報告書、譲渡側へのQ&Aシートなどです。M&Aの交渉を担った担当とPMIの推進チームが別の人になる場合、これらの資料が手元に届かないことが起こります。ITの調査結果も同じ扱いで、DDで聞き取ったシステム一覧を推進チームの共有フォルダに移すところまでをプレPMIの作業に含めてください。

### DD報告書とQ&Aシートから拾うべきIT資産・契約・データの項目

システム統合の可否を決めるのは、技術よりも契約とデータの状態です。DDの段階で次の項目を一覧にしておくと、成立後の現状把握が数週間単位で短くなります。

- 利用中のシステムとクラウドサービスの名称、契約名義、請求先、更新日
- 管理者アカウントの保有者（前経営者や退職者の個人名義になっていないか）
- 保守委託先と作業範囲、ソースコードや設計書の所在
- 顧客・取引先・従業員の個人データの保管場所と取得時の利用目的
- サポート期間が終了したOSやソフトウェアの有無

このうち最優先は管理者アカウントの保有者です。管理者権限が個人に残っていると、成立後に契約の変更も退職者の削除もできません。一覧の作り方は[IT資産管理の目的とツール機能・運用判断の解説](https://www.issoh.co.jp/column/details/15216/)にまとめています。

## 100日プランの作り方：Day1・Day30・Day100で区切るシステム工程

### Day1までに止めてはいけない業務とシステムを切り分ける手順

Day1の目標は「何も変えずに、何も止めない」ことです。株式譲渡なら会社の器が残るので、多くの契約はそのまま続きます。一方で、親会社の共通システムやグループ契約を使っていた事業を切り出して譲り受ける場合は、Day1から使えなくなるものが出ます。

1. 受発注・出荷・請求・入金消込・給与支払の5業務で、使っているシステムを特定する
2. 各システムについて、Day1以降も同じ契約と同じアカウントで動くかを確認する
3. 動かなくなるものは、旧親会社との暫定利用の取り決めか、代替手段をDay1前に用意する
4. Day1当日の問い合わせ窓口と、障害時に誰が判断するかを決めて周知する

判断の基準は「止まったときに売上か支払が止まるか」です。そこに当たらない社内ポータルやファイル共有の移行は、Day30以降に回して構いません。

### Day30までに終える管理者アカウントとライセンスの名義確認

最初の1か月でシステム面に必ず入れる作業は、管理者アカウントとライセンスの名義の確認です。ガイドラインが挙げる失敗例には、譲渡側の従業員が有償ソフトウェアを購入や課金をせずに使っており、従業員個人と企業の双方に罰金が科された事例があります。

アカウントの統合は、この段階では始めません。両社のメールやグループウェアをすぐ一本化すると、取引先とのやり取りが途切れます。Day30でやるのは、管理者を法人と推進チームの担当に付け替え、退職者のアカウントを止め、誰がどの権限を持つかの台帳を作るところまでです。統合後のID管理の設計は、[人事マスタ連携と既存のADやIDaaSを併存させる統合ID管理の構成](https://www.issoh.co.jp/column/details/18708/)が参考になります。

### Day100までに決める勘定科目の統一と親会社への月次報告の型

会計は、システムを統合しなくても数字の定義を先にそろえられる分野です。ガイドラインの会計・財務分野は、処理の適正性、両社の手続の連携、業績等の管理を取組として並べています。100日でまず決めたいのは、勘定科目の対応表と、月次で親会社へ報告する数字の項目と締め日です。

実務では、譲渡側の会計ソフトはそのまま使い、勘定科目の対応表で親会社の科目に読み替えて報告する形から始めるのが無理のない順番です。締め日を合わせる方法は[月次決算を5営業日で締める手順とシステム化の判断](https://www.issoh.co.jp/column/details/16567/)で、親会社側で連結を組む場合の修正仕訳は[連結会計の修正仕訳とExcel運用の限界](https://www.issoh.co.jp/column/details/18411/)で扱っています。

買い手が上場企業か上場準備中の会社なら、取得した子会社が翌期以降の内部統制の評価範囲に入る可能性を前提にしておきます。会計システムのアクセス権限や変更管理の記録がない状態は、[IT全般統制（ITGC）の4領域と評価手続](https://www.issoh.co.jp/column/details/19336/)で不備として扱われる典型です。

### 中小企業庁のPMI実践ツール3種を100日プランの台帳にする方法

計画の様式を自作する前に、中小企業庁が公開している道具を確かめておく価値があります。[中小企業庁「PMIを実施する」のページ](https://www.chusho.meti.go.jp/zaimu/shoukei/sme%5Fpmi%5Fguideline%5Fcourse.html)では、PMI分析ワークシート、PMIアクションプラン、統合方針書の3つのツールと、その使い方をまとめたガイドブック、実証事業に参加した55件の取組事例集を配布しています。

システム担当にとって使いやすいのはPMIアクションプランです。「いつ・誰が・何を行うか」を一覧にして進捗を管理する様式なので、前の3つのh3で挙げたDay1・Day30・Day100の作業をそのまま行として書き込めます。人事や会計の作業と同じ台帳に載せておけば、システムの作業だけが別管理になって遅れに気づけない事態を避けられます。

## PMIのシステム統合で詰まる箇所：顧客データ・二重入力・方式決定

### 顧客データの移転を個人情報保護法18条2項と27条5項2号で判断

顧客リストを買い手の営業システムへ移してよいかは、PMIで必ず出る質問です。[個人情報保護法（e-Gov法令検索）](https://laws.e-gov.go.jp/law/415AC0000000057)の27条5項2号は、合併その他の事由による事業の承継に伴って個人データが提供される場合を第三者提供に当たらないとしています。この点では本人の同意は要りません。

ただし同法18条2項により、承継前の利用目的の達成に必要な範囲を超えて扱うことはできません。譲渡側が「製品の保守連絡」の目的で集めた顧客情報を、買い手の別商品の案内に使うなら、利用目的の変更か本人同意の手続きが別に必要です。データを統合する前に、移行対象の項目ごとに取得時の利用目的を確認する工程を入れてください。条番号は2026年11月2日施行の改正後の版で照合しています。

### 表計算ソフトと会計システムの二重入力を残す期間と段階的な解消の順番

中小企業のM&Aで多いのは、譲渡側の業務が表計算ソフトと紙に散らばっている状態です。ガイドラインの失敗例にも、経営や業務の情報がすべて個人管理の表計算ソフトにあり、項目や形式がばらばらで、把握に多大な時間がかかった事例が載っています。

同じガイドラインの取組事例では、配管工事業の会社が専門工事業の会社を譲り受けた後、会計システムへの入力と表計算ソフトでの工事別原価集計という二重入力を、会計システムと連携できる工事原価ソフトの導入で解消しています。この例が示す順番は、まず二重入力のまま業務を続けて手順を把握し、次に連携できる製品で入力を一つにすることです。大きな基幹システムへの統合を、この段階でいきなり始めてはいません。

### 基幹システムの統合方式はDay100以降に決める理由と判断材料

基幹システムの扱いを決めるのは、100日で業務とデータ項目の差が見えてからです。ガイドラインは、譲受側のシステムを譲渡側に入れたところ、業務に必要なデータ項目の差が大きく改修コストがかさみ、不要な入力項目も増えて効率が落ちた失敗例を挙げています。現状把握の前に方式を決めると、この失敗をそのままなぞります。

方式は大きく、片方のシステムに寄せる、両方を残して連携だけ作る、新しく作り直す、の3つです。どれを選ぶかの条件は[事業承継とM&Aの違いとシステム・データ・IT契約の引継ぎ](https://www.issoh.co.jp/column/details/17934/)で比較しています。寄せる場合も作り直す場合も、工程の半分を占めるのはデータ移行と切替の計画です。移行方式の種類は[システム移行の方式と失敗を防ぐ判断基準](https://www.issoh.co.jp/column/details/15261/)で、統合後のリプレイスを外部に相談する場合は[一創のシステムマイグレーション・リプレイス](https://www.issoh.co.jp/service/system/migration/)で対応範囲を確認できます。

## M&AのPMIでシステム統合を見送るべき場面と早く手を入れる例外

### 子会社として独立運営する買収では基幹システムを統合しない判断基準

買収の目的が「譲渡側の事業をそのまま続けてもらうこと」で、経営陣も残る計画なら、基幹システムは統合しません。統合で得られるのはライセンス費用の削減と報告の手間の軽減程度で、業務の作り直しと従業員の学習負担がそれを上回ります。この場合のPMIは、会計の報告様式と権限管理をそろえるところで止めるのが正しい判断です。

見送る判断には期限を付けます。「次の決算期まで現状維持し、そのとき報告の手作業が月に何時間かかっているかで再判断する」のように、数字で見直せる条件を統合方針書に書いておくと、なし崩しの併存を避けられます。

### サポート切れOSとライセンス違反は統合方針の決定を待たず是正する

統合方式の決定を待たずに対処すべき対象もあるため、統合の検討とは別に確認が必要です。サポート期間が終了したOSやソフトウェアは修正プログラムが出ないため、外部からの攻撃に対して無防備なまま残ります。ガイドラインもこの点を挙げ、対策の参照先として[IPAの中小企業の情報セキュリティ対策ガイドライン](https://www.ipa.go.jp/security/guide/sme/about.html)を示しています。

ライセンス違反の疑いも同じ扱いです。どちらも見つけた時点で、更新・購入・利用停止のいずれかを決めます。100日プランの台帳には「統合待ち」と「即時是正」の列を分けておくと、急ぐべき作業が統合の議論に埋もれません。

### 買い手のシステムを押し付けるPMIが失敗する構造と現場の反発を防ぐ方法

PMIの失敗に共通するのは、買い手のシステムが標準だという前提で、譲渡側の業務を合わせにいく進め方です。改修費が膨らむだけでなく、譲渡側の従業員が「仕事のやり方を否定された」と受け取り、離職のきっかけになります。ガイドラインが集中実施期に、早く成果が出る取組（クイック・ヒット）を優先するよう勧めているのも、この反発を抑えるためです。

システムで言えば、譲渡側の日報や受注入力の手間を減らす小さな改善が、クイック・ヒットに当たります。統合の大きな判断はその後に置き、最初の100日は譲渡側の現場が楽になる変更だけに絞ってください。

## よくある質問

M&AのPMIについて、システム統合を中心によく寄せられる質問に答えます。

### M&AのPMIとは何ですか？

PMIはPost Merger Integrationの略で、M&Aの成立後に経営・業務・システムを統合し、M&Aの目的を実現するための一連の取組です。中小企業庁の中小PMIガイドラインは、成立前のプレPMI、成立後1年程度のPMI、その後に続くポストPMIの3段階に分けています。経営体制や人事制度だけでなく、会計や基幹システム、顧客データの扱いまでが対象に含まれます。

### PMIの100日プランには何を書けばよいですか？

Day1・Day30・Day100などの区切りごとに、取組の内容、担当者、期限、完了の条件を書きます。中身は推進体制の確立、従業員や取引先との関係づくり、現状把握が中心です。システム面では、Day1に止めない業務の特定、Day30の管理者アカウントとライセンスの名義確認、Day100の勘定科目と月次報告の統一を入れておくと、後の統合判断の材料がそろいます。

### PMIでシステム統合はいつ始めるべきですか？

現状把握はM&Aの検討段階から始め、基幹システムの統合方式は成立後100日で業務とデータ項目の差を把握してから決めます。実際の移行や刷新は、集中実施期の後半からポストPMIにかけて行うのが一般的な順番です。サポート切れのソフトウェアやライセンス違反は例外で、見つけた時点で是正します。

### 中小企業のPMIは誰に相談すればよいですか？

中小PMIガイドラインは分野別に支援機関を挙げています。経営統合と事業機能は中小企業診断士や経営コンサルタント、人事・労務は社会保険労務士や弁護士、会計・財務は公認会計士や税理士、法務は弁護士や司法書士、ITシステムはITベンダーやスマートSMEサポーターです。システム統合を相談する場合は、移行と切替の実績がある開発会社を選びます。

### M&A後に顧客データを統合するには本人の同意が必要ですか？

合併や事業の承継に伴う個人データの提供は、個人情報保護法27条5項2号により第三者提供に当たらず、その時点での同意は要りません。ただし同法18条2項により、承継前の利用目的の範囲を超えて使うことはできません。買い手の別サービスの案内に使う場合などは、利用目的の変更や同意の取得が別途必要になります。

## 関連記事

- [事業承継とM&Aの違い：親族内承継とM&Aで変わるシステム・データ・IT契約の引継ぎ](https://www.issoh.co.jp/column/details/17934/)：片寄せ・併存・刷新の方式判断と、事業譲渡での契約承継を詳しく扱います。
- [金融機関のシステム統合｜片寄せ・新設・連携の方式選択と移行検証の進め方](https://www.issoh.co.jp/column/details/17155/)：経営統合に伴う大規模なシステム統合の進め方を業種別に解説しています。
- [物流のシステム統合｜合併・拠点統合・3PL受託でWMSとTMSを寄せる方式と切替計画](https://www.issoh.co.jp/column/details/18762/)：合併後に現場システムを寄せる切替計画の実例です。
- [システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説](https://www.issoh.co.jp/column/details/15261/)：統合方式を決めた後の移行計画を立てる前提になります。
- [IT全般統制（ITGC）とは：4領域の統制項目・評価手続と不備の扱いを実施基準で解説](https://www.issoh.co.jp/column/details/19336/)：上場企業が子会社を取得した後に整える統制の範囲です。

---

出典: [M&AのPMIとは：100日プランとシステム統合をDay1から1年で進める手順](<https://www.issoh.co.jp/column/details/19338/>)（株式会社一創）
