目次
「来月、A社と合併することになったから。顧客データ、いい感じに統合しておいて」
経営層や事業部門から降ってくるこの一言が、データ管理者にとってどれほどの地獄の始まりか。彼らは知りません。 「いい感じ」とは何でしょうか。重複を消すこと？ 取引履歴を引き継ぐこと？ それとも、システムIDを統一すること？
M&A（合併・買収）、事業譲渡、分社化。これらは法的な手続きであると同時に、データガバナンスにおける**「最大級の災害」**です。 今回は、教科書的な「PMI（Post Merger Integration）」の話ではなく、もっと泥臭い、現場のデータ担当者が直面する「IDと履歴の処理」に絞って、実用的な解法を提示します。
1. 「上書き」は絶対にやってはいけない
最も初歩的で、かつ取り返しのつかない失敗。 それは、**「吸収される側の会社（消滅会社）のデータを、存続会社のデータで上書きしてしまう」**ことです。
例えば、A社がB社を吸収合併するとします。 「B社はなくなるんだから、B社の顧客マスタの社名をA社に書き換えればいいじゃないか」
これをやると何が起きるか。 **「B社時代に販売した製品のサポート責任」や「B社時代に締結した契約書の日付」**との不整合が発生します。
2023年にB社として売った商品の履歴データ上の販売元が、システム上で一斉に「A社」に変わってしまうと、「2023年にはA社はこの製品を扱っていなかったはずだ」という会計監査上の矛盾や、PL（製造物責任）法上のトラブル時に「当時の記録がない」という事態を招きます。
鉄則：データは「時点」とともに管理せよ
- Before: B社コード
9999/ 社名株式会社B - After: B社コード
9999/ 社名株式会社B（※2024/4/1 A社へ合併）/ フラグ無効(Dissolved)
消滅会社のレコードを削除したり、IDを再利用したりしてはいけません。 「無効フラグ」を立て、備考欄や別テーブルで「合併先ID：A社」へのポインタを持たせる。これが基本です。
2. 3つのパターン別・現実的な処理フロー
M&Aの形態によって、とるべきデータ処理は異なります。
ケースA：吸収合併（A + B → A）
B社が消滅し、A社が残るパターン。これが一番多いです。
- 顧客マスタ:
- B社の既存顧客がA社にも存在する場合（重複）：A社のIDを正とし、B社のIDには「統合済み」フラグを立ててA社のIDを紐付ける（名寄せ）。
- B社独自の顧客の場合：A社のID体系で新規採番し、顧客属性に「旧B社顧客」というタグを付与する。
- 取引履歴:
- 過去の履歴データの「顧客ID」カラムを書き換えるべきか？ 否です。
- 履歴データは「事実」の記録です。書き換えずに、参照する際のマッピングテーブル（旧ID→新ID変換表）をシステム側に噛ませるのが安全です。
ケースB：新設合併（A + B → C）
A社もB社も消滅し、新会社Cができるパターン。 これはシステム的には**「全データ移行」**です。
- A社システム、B社システムのどちらかを「新システム」として採用する場合でも、ID体系は一新されることが多いです。
- この場合、旧A社ID、旧B社ID、新C社IDという「3つのID」が並走する期間が必ず発生します。
- **「旧ID変換API」**を社内マイクロサービスとして用意し、どのシステムの検索窓に旧IDを入れても新IDのデータが引けるようにする工夫が、現場の混乱を防ぎます。
ケースC：事業譲渡（A社のα事業 → B社へ）
これが一番厄介です。会社ごとではなく、「特定の事業に関連するデータだけ」を切り出して渡す必要があります。
- 問題点：ある顧客X社が、A社の「譲渡対象のα事業」と「残留するβ事業」の両方と取引があった場合。
- 処理：X社の顧客マスタデータは、A社に残しつつ、B社にもコピー（複製）して渡す必要があります。
- 法的な注意点として、**「個人情報保護法」**における第三者提供の特例（事業承継）に該当するかを確認し、必要であれば顧客への通知（オプトアウト機会の提供など）を行うフローを組み込む必要があります。システム担当者だけで進めると、ここで法務リスクを踏みます。
3. 「名寄せ」の泥沼を回避するキー項目
合併時のデータ統合で必ず発生するのが「名寄せ（De-duplication）」です。 A社の「鈴木商店」とB社の「（株）鈴木商店」は同一か？
AIやマッチングアルゴリズムに頼るのも良いですが、最終的に頼りになるのは**「外部識別子」**です。
- 法人番号（国税庁）:
- 国内法人同士の統合なら、これが最強のユニークキーです。合併前に、A社・B社双方の顧客マスタに対して「法人番号付与」のクレンジングをかけておくこと。これが統合コストを劇的に下げます。
- 適格請求書発行事業者登録番号（インボイス番号）:
- 経理データとの突き合わせが必須なら、こちらも有効です。
- 電話番号:
- 法人番号がない個人事業主や小規模事業者の場合。結局、電話番号一致が最も実用的です。ただし「03-xxxx」と「03(xxxx)」の表記揺れ正規化は必須です（これはPythonあたりで簡単に書けますね）。
4. 契約管理システムの罠
CRM（顧客管理）やSFA（営業支援）の話ばかりしましたが、忘れがちなのが**「契約管理システム」**です。
合併によって「契約の主語」が変わります。 契約書自体を巻き直す（再締結する）のか、「承継通知書」を送って済ませるのかによって、システム上の登録データの扱いが変わります。
- 覚書/通知で済ませる場合: 契約データの「契約者名」は旧社名のまま残し、「承継フラグ」を立てる。
- 巻き直す場合: 旧契約を「解約/満了」扱いにし、新会社名義で「新規契約」を登録する。この際、旧契約IDと新契約IDの紐付け（Parent-Child関係）を持たせないと、契約更新のタイミングを見失います。
まとめ：システム統合は「断捨離」の好機
M&A時のデータ処理は面倒ですが、見方を変えれば長年蓄積したゴミデータ（休眠顧客、重複、不完全データ）を公式に葬り去る絶好のチャンスです。
「とりあえず全部移行しましょう」という判断が一番危険です。 移行コストはデータ量に比例します。
- 移行するデータ（Active）
- アーカイブするデータ（Cold）
- 捨てるデータ（Trash）
この3つを、新会社の業務要件に基づいて冷徹に仕分けること。 エンジニアやデータ管理者が、ビジネスサイドに対して「このデータ、本当に新システムに必要ですか？ 維持費かかりますよ？」と突きつける勇気を持つことが、成功への第一歩です。