M&A後のテナント統合から始める情シス外注：スポット案件を継続代行に繋げる導線設計

M&A（合併・買収）の件数は、中小企業の事業承継需要を背景に増加傾向が続いています。しかし、M&Aが成立した後の「IT環境の統合」は、多くの企業にとって想定以上に複雑で時間がかかるプロジェクトです。

特にMicrosoft 365のテナント統合は、メール・ファイル・Teams・アカウント管理を一気に移行する大規模な作業であり、通常の情シス業務と並行して行うのは困難です。そのため、テナント統合のタイミングで情シス外注を検討する企業が増えています。

この記事では、テナント統合のスポット案件を起点に、継続的な情シス代行へ移行する設計思想と、テナント統合プロジェクト自体の進め方を解説します。

テナント統合が情シス外注の「入口」になる理由

理由1：社内だけでは対応できない高度な専門性が必要

Microsoft 365のテナント統合には、Entra ID（旧Azure AD）のドメイン統合、Exchange Onlineのメールボックス移行、SharePoint/OneDriveのファイル移行、Teams環境の統合、条件付きアクセスポリシーの再設計など、M365の各サービスに関する深い知識が必要です。

一般的な情シス担当者がテナント統合を経験する機会は少なく、手探りで進めるとデータ損失やメール停止などの重大なトラブルを引き起こすリスクがあります。

理由2：統合後の「運用」を見据えた設計が必要

テナント統合は「移行して終わり」ではありません。統合後のIT環境をどう運用していくかを見据えた設計が必要です。たとえば、買収した子会社の社員のアクセス権限をどう管理するか、セキュリティポリシーをどのレベルに統一するか、SaaSの契約をどう集約するか——これらは統合プロジェクトの段階で設計しておかないと、統合後に改めて大きな手戻りが発生します。

テナント統合を手がけた外部パートナーは、統合後のIT環境を最も深く理解しています。そのまま継続的な情シス代行に移行すれば、ゼロから環境を把握し直す必要がなく、シームレスに運用フェーズに入ることができます。

理由3：M&Aで組織が拡大し、情シス体制の見直しが必要になる

M&Aによって従業員数が増加すると、IT運用の業務量も増加します。元々「ひとり情シス」で回していた企業が、買収先の社員分のアカウント管理やヘルプデスク対応まで担うのは現実的ではありません。

このタイミングで情シスの外部委託を導入すれば、増加した業務量を吸収しつつ、統合後のIT環境を安定運用に乗せることができます。

テナント統合プロジェクトの全体像

テナント統合プロジェクトは、大きく5つのフェーズで構成されます。

フェーズ1：現状調査・アセスメント（2〜3週間）

統合対象の両テナントのIT環境を詳細に調査します。

調査対象は以下のとおりです。

• Microsoft 365のライセンス構成（プラン、ユーザー数、アドオン）
• Entra IDの構成（カスタムドメイン、ユーザー/グループ、条件付きアクセスポリシー）
• Exchange Onlineの構成（メールボックス数、配布リスト、メールフロールール、共有メールボックス）
• SharePoint/OneDriveのデータ量とサイト構成
• Teamsのチーム/チャネル構成
• 利用中のSaaS/クラウドサービスの一覧と認証連携状況
• オンプレミスのActive DirectoryとEntra IDの同期状況
• セキュリティポリシーの比較（パスワードポリシー、MFA設定、デバイス管理）

このフェーズの成果物は「統合計画書」です。移行方針（吸収統合 or 新規テナント構築）、移行対象と移行順序、スケジュール、リスクと対策を明文化します。

フェーズ2：統合設計（2〜3週間）

統合後のIT環境のあるべき姿を設計します。

• ドメイン統合方針（どちらのドメインを残すか、新ドメインにするか）
• Entra IDの設計（OU構成、グループ構成、ロール設計）
• 条件付きアクセスポリシーの統一設計
• Exchange Onlineのメールフロー設計（ドメイン移行の切り替え手順）
• SharePointのサイト構成とアクセス権設計
• Teamsのガバナンスポリシー
• Intune（MDM）のデバイス管理ポリシーの統一
• SaaSの統合・廃止判断とSSO連携設計

このフェーズでは「統合後にどう運用するか」を意識した設計が重要です。テナント統合のプロジェクトだけを見て設計すると、統合後の運用で不整合が生じます。

フェーズ3：移行準備・テスト（2〜4週間）

実際の移行作業に入る前の準備フェーズです。

• テストユーザーでの移行リハーサル
• メールの共存期間の設定（両テナントでメールが届く状態の構築）
• SharePoint/OneDriveの移行ツールの検証
• DNS切り替えの手順書作成と切り戻し計画の策定
• 社員向けの移行ガイド（新しいログイン方法、Outlookの再設定手順等）の作成
• 関係者（経営層、部門責任者）への移行スケジュールの共有

フェーズ4：移行実行（2〜6週間）

実際のデータ移行とアカウント切り替えを実施します。通常は段階的に移行します。

一般的な移行順序としては、まずEntra IDのユーザーアカウントの移行（認証基盤の統一）、次にExchange Onlineのメールボックス移行（ドメインの切り替え）、続いてSharePoint/OneDriveのファイル移行、最後にTeams環境の移行という流れです。

移行は可能な限り業務時間外（夜間や週末）に実施し、社員の業務への影響を最小化します。移行直後は問い合わせが急増するため、一時的にヘルプデスクの体制を強化する必要があります。

フェーズ5：安定化・運用引き継ぎ（2〜4週間）

移行後の環境を安定化させるフェーズです。ここが「スポット案件」から「継続代行」への移行ポイントになります。

• 移行後の動作確認（メール送受信、ファイルアクセス、Teams通話）
• 残存課題の対応（移行漏れ、権限設定の修正、旧環境のクリーンアップ）
• 統合後のセキュリティポリシーの適用確認
• 運用手順書の完成・引き渡し
• 月次運用レポートの提供開始
• SLAの合意と継続契約への移行

スポットから継続代行への移行設計

テナント統合のスポット案件から継続的な情シス代行へ移行する際のポイントは3つです。

ポイント1：統合プロジェクトの契約に「運用移行期間」を含める

テナント統合の契約を「移行完了まで」で終わらせず、移行後2〜3ヶ月の安定化期間を含めた形にします。この期間中に継続代行のSLAや対応範囲を具体化し、安定化期間終了後にシームレスに月額契約へ移行します。

ポイント2：統合プロジェクトで作成したドキュメントを運用に活用する

テナント統合のプロジェクトでは、両社のIT環境を詳細に調査・文書化します。この成果物（ネットワーク構成図、アカウント台帳、SaaS一覧、セキュリティポリシー等）は、そのまま継続代行の運用ドキュメントとして活用できます。

通常の情シス代行で初期費用として必要になる「現環境の調査・棚卸し」が、テナント統合のプロジェクト内で完了している状態です。これにより、継続代行への移行時の初期コストを大幅に圧縮できます。

ポイント3：統合後のIT運用課題をプロジェクト中に洗い出す

テナント統合を進める中で、「統合後に継続的に対応が必要な課題」が多数見つかります。たとえば、旧テナントで使われていたSaaSの廃止計画、セキュリティポリシーの統一後の運用、買収先の社員向けIT教育プログラムなどです。

これらの課題を統合プロジェクトの完了報告書に「継続対応事項」として明記し、そのまま継続代行の初期スコープに組み込むことで、自然な移行が実現します。

M&Aを控えている経営者が今やるべきこと

M&Aの計画段階（デューデリジェンス前後）から、IT環境の統合を意識しておくことが重要です。

デューデリジェンスの段階で確認すべきこと： 買収対象企業のIT環境の概要（利用中のクラウドサービス、ドメイン、アカウント数、セキュリティ対策の状況）。これが統合の難易度とコストを大きく左右します。

成約から統合開始までにやるべきこと： テナント統合の専門家を含む情シス外注先の選定。成約後すぐに動き始めれば、3〜6ヶ月でテナント統合を完了し、継続代行に移行できます。

まとめ

M&A後のテナント統合は、単なるITの移行作業ではなく、統合後のIT環境の「あるべき姿」を設計する経営課題です。そして、テナント統合を手がけたパートナーがそのまま継続的な情シス代行を担うことで、統合後の運用品質を最大化できます。

情シス365は、Microsoft 365テナント統合の設計・実行から、統合後の継続的なIT運用代行までワンストップで対応しています。M&Aの検討段階、テナント統合の計画段階、あるいは統合後の運用に困っている段階——どの段階でもご相談いただけます。まずは60分の無料相談で、御社の状況をお聞かせください。