二つのテナント、一つの会社：シンガポールの買収後Microsoft 365移行ガイド

要点： シンガポールのテクノロジー企業が買収を完了し、二つ目のMicrosoft 365テナントを引き継いだとする。半年後、二つのテナントはまだ並行して稼働している。難しいのはメールボックスの移行ではなく、何も移す前に、どちらのセキュリティとライセンスの基準を残すかを決めることだった。

あるシンガポールのテクノロジー企業が、規模の小さい地域の競合企業を買収した。取締役会が重視するあらゆる指標において、これは成功した取引だった。新しい顧客、新しいエンジニアリング人材、そして半年前には存在しなかった市場への足がかりを手に入れた。ところが統合計画がIT責任者の手元に届くと、誰も予算に織り込んでいなかった一項目が浮かび上がる。被買収企業は独自のMicrosoft 365テナントを運用しており、独自のID基盤、独自のセキュリティポリシー、そして更新日の異なる独自のライセンス契約を持っていた。組織図と銀行口座の上では、二つの会社はすでに一つになっている。ディレクトリサーバーの上では、まだ二つのままだ。

これは実在の顧客ではなく複合的なシナリオだが、そのパターン自体はBrocentが香港、シンガポール、大中華圏で繰り返し手がけてきたものだ——二つの会社が買収によって一つになったことを理由に実施された、フルスタックのテナント間移行とゼロダウンタイムの統合。Brocentは2007年に北京で創業し、2016年から香港にオフィスを構え、2021年からシンガポールに本社を置いている。ここで説明する買収主導のテナント統合は、シンガポールのテクノロジー企業がMicrosoft 365を自社だけで抱え続けるのをやめ、マネージドITプロバイダーに初めて相談する、よくあるきっかけの一つだ。

シンガポールのテクノロジー業界は買収で成長し、そのしわ寄せをITが引き受ける

シンガポールのテクノロジー・ソフトウェア業界は、多くの他市場とは違う成長の仕方をする。自然な採用だけに頼るのではなく、中堅規模のシンガポールのテクノロジー企業は、規模の小さい地域チームを買収することで日常的に成長する——マレーシアやインドネシアに足場を持つ競合企業、買収側が採用しきれなかった人材を抱える小規模開発会社、あるいは独自の顧客基盤を持つ地域リセラーなど。国内市場が小さく、隣に大きな対応可能地域が広がっているという条件のもとでは、これは合理的な成長の仕方であり、例外というより認識できるパターンと呼べるほど頻繁に起きている。

このような形の取引は、業界や規模にほぼ関係なく、同じ産物を生む。独自のユーザー、独自のメールフロー、独自のファイルライブラリ、独自のセキュリティ構成を持つ二つ目のMicrosoft 365テナントが、買収側のテナントと並んで存在するようになる。Brocentは香港、シンガポール、大中華圏の顧客において、このまったく同じパターンを繰り返し扱ってきた——出発点となる状況は毎回同じではないが、根底にある構造はいつも同じだ。二つのテナント、二つのID基盤、そして取引が完了すれば技術的な統合は自然に片づくと思い込んでいる経営陣。それが自然に片づくことはめったになく、「買収が法的に完了している」ことと「二つの会社が実際に一つの会社として機能している」ことのあいだのギャップは、社内のどの部門よりもITにおいてほぼ常に大きい。

シナリオ：従業員120名、二つのテナント、更新日の異なる二つのライセンス契約

複合的な想定はこうだ。従業員約90名のシンガポールのテクノロジー企業が、約30名の小規模な地域チームを買収し、合計で約120名の体制になる。買収された側のチームは、取引完了後の数週間、ほぼこれまでどおり働き続ける。買収を経たばかりのチームをこれ以上混乱させたくないという事情があり、移行期における安定にも一定の合理性があるからだ。彼らのノートパソコンは、いまも元のテナントにサインインしている。彼らのメールボックス、Teamsチャネル、SharePointライブラリ、そしてIDは、すべて元の場所にとどまったままだ——親会社とは独立して構築・管理されている、別のMicrosoft 365テナントに。

半年後、二つのテナントはまだ稼働している。統合期間中の一時的な橋渡しのはずだったものが、いつの間にか実際の運用モデルになっている。被買収企業のライセンス契約は、親会社とは異なる契約のもと、異なる更新日に、異なる一人あたり単価で更新される。条件付きアクセスポリシーがあるとしても、そのテナントを最初に構築した誰かが設定したものであり、親会社の基準と比較されたことは一度もない。メールボックスの保持設定、多要素認証の適用状況、デバイスコンプライアンスルールも、すべて独立して存在し、誰かがわざわざ調べない限り親会社のIT部門からは見えない。

この問題が最終的に表面化するきっかけは、セキュリティインシデントであることはめったにない。もっと多いのは、ありふれていて目に見えやすい出来事だ。買収された側の営業担当者が、親会社のSharePoint上の共有提案書を見られない。そこにアカウントがないからだ。あるプロジェクトマネージャーは、二つのTeamsテナントがチャネルをうまく共有できないせいで、金曜の午後を丸ごと使って二つの受信トレイのあいだで添付ファイルを手作業で転送する。新しい共同顧客のアカウントが、二つのメールボックスにそれぞれ重複して作られる。どれ一つを取っても危機ではない。しかしそれらが積み重なると、経営陣は当然の疑問を抱くようになる。同じ会社であるはずの社員が、なぜいまだに同じファイルを開けないのか。そして、なぜ取引が完了する前に誰もそれを解決する計画を立てなかったのか、と。

現実の問題その一：ゲストアクセスは応急処置のはずが、いつの間にか恒常化する

たいていのIT部門がまず頼る対処法は、Microsoft 365自体が持つゲストアクセス機能だ。被買収テナントのユーザーをゲストとして親会社テナントのTeamsとSharePointに招待し、完全な移行を約束することなく、少なくとも共有ドキュメント上で二つのチームが協働できるようにする。「ファイルが共有でき、会議が設定できる」という狭い意味では、これは機能する。しかし別の見方をすれば、これはほとんど、本当に必要な決断を先送りするための決断でもある。

ゲストアクセスは、顧客、業務委託先、パートナー企業といった、たまに発生する外部との協働のために設計されたものであり、統合後120名の会社の日常的な社内協働を恒久的に支えるためのものではない。クロステナントアクセス設定を誰かが意図的に構成しない限り、ゲストアカウントはネイティブアカウントと同じ条件付きアクセスの適用を受けず、余裕のないIT部門の多くは、それをきちんと構成するところまで手が回らない。ゲストユーザーはTeamsやSharePointの権限リストに蓄積され続け、被買収企業側で誰かが退職しても、ほとんど整理されない。退職時の手続きは、もともと一つのテナントを前提に設計されており、二つを前提にはしていないからだ。そして、技術的には「痛みが止まる程度に機能している」ため、どのテナントを最終的に残すかという本当の決定と優先順位を争うことがない。18か月後には、ゲストアクセスが本来6週間で終わるはずだった役割をいまだに担い続け、より多くの人がより多くのリソースへのアクセスを求めるにつれて静かに拡大し、誰が何にアクセスできるのかを自信を持って言える人がいない、という状態になっているのがよくある光景だ。

現実の問題その二：ライセンスの重複は毎月、実際のお金を食う

二つのMicrosoft 365テナントが並行して稼働するということは、二つのライセンス契約が並行して走るということであり、それは直接的かつ継続的なコストを生む。多くの場合、誰かがわざわざ計算するまで、そのコストは目に見えない。両方のテナントは通常、メール、Teams、SharePoint、セキュリティアドオンといった、おおむね似た構成の一人あたりライセンスに対して料金を支払っており、それが対応しているのは、組織図上は一つの会社である合計120名だ。どちらの契約も、120席の統一契約が本来得られるはずのボリューム価格や交渉力を得られない。更新日がそろうこともめったになく、経理部門は年間を通じて異なる二つの時期に、異なる二つの営業担当者を相手に、二つの別々の契約を交渉することになる。しかもお互いの契約の全体像は見えていない。

もう一つ、より目立たないコストがある。取引完了後にはもはや意味をなさないライセンス種別だ。被買収企業の一部の社員が、親会社の基準では使っていない上位のセキュリティやコンプライアンス系アドオンを保有していることもあれば、逆に、親会社が必須と考える階層を欠いていることも同じくらいよくある。これを整理し、単一のライセンス基準を決め、重複する契約を解約し、統合後の全員を一つの交渉済み契約に移すことは、テナント統合プロジェクトの中で最も具体的かつ最も数値化しやすい節約であることが多く、実際にライセンス整理を手がけたことのあるプロバイダーとの料金に関する相談は、最初のレビューの段階でこの数字を明らかにできることが多い。

現実の問題その三：二つのセキュリティ基準はほぼ一致せず、弱い方が実際のリスクを決める

すべてのMicrosoft 365テナントは、誰かがそう意識しているかどうかにかかわらず、独自のセキュリティ構成を持っている——条件付きアクセスルール、多要素認証の適用状況、デバイスコンプライアンス要件、情報漏えい対策ポリシー、メールボックスやSharePointの既定の共有設定など。二つの会社が統合すると、それぞれ独立して、異なる人物が、異なる時期に、異なるリスク許容度のもとで構築した二つの構成が持ち込まれる。それらがぴったり一致することはほぼない。一方のテナントはすべてのサインインでMFAを強制し、レガシー認証プロトコルを完全にブロックしているかもしれない。もう一方のテナントではMFAが任意設定のままで、誰も対応する時間を取らなかったためにレガシープロトコルが依然として開いたままかもしれない。

ゲストアクセスや共同プロジェクトでつながった二つの不一致な基準を並行して稼働させることの気まずい真実は、会社の実際のセキュリティリスクが、強い方ではなく弱い方の基準によって決まってしまうということだ。攻撃者は、よく構成されたテナントを直接突破する必要はない。防御の弱いテナント経由の経路——過剰な権限を持つゲストアカウント、被買収テナント上で開いたままのレガシープロトコル、一度も厳格化されなかったデバイス登録ポリシー——さえあれば十分だ。これはまさに、マネージドITセキュリティサービスが買収の場面で見つけ出すために設計されているギャップだ。なぜなら、それはどちらの部門の日常的な視点からもほとんど見えないからだ。親会社のIT部門は自社のテナントを安全だと捉えており、その評価自体は正しいかもしれないが、それは今静かにつながっているもう一方のテナントについては何も語っていない。

現実の問題その四：決定が先送りされているあいだに、Teamsと共有メールボックスの乱立が積み重なる

決定が一か月先送りされるたびに、二テナント環境は臨時的な状態に近づくのではなく、少しずつ固定化していく。会社をまたぐプロジェクトのために新しいTeamsが必要になり、既存のチームへのゲストアクセスをすぐに設定するのが面倒なので、新しく作ってしまう。共有メールボックスは、その週に設定する人にとって都合の良い方のテナント上に、統一された命名規則もなく、どこに何が存在するかを示す一元的な一覧もないまま作られていく。配布リストは統合されるのではなく重複して作られる。統合するにはどちらのテナントを選ぶかを決めなければならず、それこそが計画なしに誰も下したくない決断だからだ。

これは特定の誰かの過失ではない。より難しいガバナンスの課題が未解決のまま上に乗っている状態で、二つの会社が日々の業務を回さなければならないことの自然な結果だ。しかし、その代償は積み重なっていく。この状態が長く続くほど、いざ移行が始まったときに整理すべきTeams、メールボックス、権限付与、重複コンテンツが増え、どのバージョンのドキュメント、どのTeamsチャネル、どの配布リストが実際に現在使われているものなのかを見分けるのがますます難しくなる。18か月目に着手する統合が、3か月目に着手する同じ統合よりもはるかに大きなプロジェクトになるのは、まさにこの理由による。

現実の問題その五：PDPAの義務が、いまや管理体制の異なる二つの環境にまたがっている

シンガポールの個人情報保護法（PDPA）は、買収のために一時停止したりはしない。どちらかの会社がシンガポールの個人に関する個人データ——顧客記録、従業員データ、同法の対象となるあらゆる情報——を保有している場合、統合後の会社が負うデータ保護義務は、二つの環境が整理されているかどうかにかかわらず、両方のテナントに及ぶ。これは具体的で実務的な問題を生む。合理的なセキュリティ体制、同意と目的制限に関する管理、そして弁明可能なデータ侵害対応プロセスを、異なる管理体制、異なる監査ログを持ち、ある顧客のデータが実際にどこに存在するかという基本的な問いにさえ二つの異なる答えが返ってくるかもしれない環境の中で示さなければならない。

データアクセス請求、データ侵害調査、あるいはPDPCからの照会は、「買収が法的に完了しているので二つのテナントはもう関係ない」という組織図上の建前を尊重してはくれない。実際にデータが存在するテナントがどちらであれ、会社の実際の管理体制を検証する。保持ポリシー、アクセスログの設定、デバイスコンプライアンスの状態がそれぞれ異なる二つのテナントは、一つのテナントで一つの統治された基準がある場合に比べて、この問いに自信を持って答えることをはるかに難しくする。これは、法務やコンプライアンス部門の誰かが実際にこの問いを投げかけた瞬間に、テナント統合が「いつかやる」から「今四半期中にやる」へと変わる、より具体的で締め切りのある現実的な理由の一つだ。

Brocentの視点：移行そのものは、実はいちばん簡単な部分だ

メールボックス、Teamsのコンテンツ、SharePointのファイルを一つのMicrosoft 365テナントから別のテナントへ移す技術的な手順は、すでによく確立されている。マイクロソフトはツールと参照アーキテクチャを公開しており、力のあるエンジニアリングチームであれば、何も新しく発明することなくクロステナント移行を実行できる。テナント統合がうまくいかなくなるのは、ここではない。これははっきり言っておく価値がある。というのも、この立場にある企業の多くが実際に心配しているのは、そこではないからだ。

うまくいかなくなるのは、ガバナンスの判断がカットオーバーの後ではなく、後回しにされたときだ。どちらのテナントを移行先として残すか——規模が大きく体制が整っているという合理的な想定のもと買収側のテナントを残すのか、あるいは被買収企業のテナントの方がたまたま構成が新しい場合には、そちらを残すのか。テナントが一つだけになったとき、どちらのセキュリティ基準を全社標準にするのか——誰かが実際に二つの構成を一行ずつ比較して決めるのか、それとも統合後の会社は、たまたま生き残ったテナントが持っていた基準をそのまま引き継ぐだけなのか。何をそのまま移行し、何を整理・アーカイブして丸ごとは持ち越さないのか、そして統合テナントが稼働開始する初日から、ID——プロビジョニング、デプロビジョニング、アクセスレビュー——を誰が所有するのか。これらは技術的な手順ではなく判断であり、そのどれもが、何も移す前に意図的に決めておく方が、誰も確認したことのない前提の上に構築されたテナントで120人がすでに働き始めた後に巻き戻すよりも、はるかにコストが低い。

Brocentが香港、シンガポール、大中華圏の顧客において、買収に伴うフルスタックのテナント間移行とゼロダウンタイム統合を実施してきた経験は、毎回同じ結論を指し示している。順調に進むプロジェクトは、最初のメールボックスが動く前に、ワーキングセッションでガバナンスの問いに答えを出しているプロジェクトだ。そして予定を超過するプロジェクトは、ほぼ常に、まだ並行して議論されている判断に対して、技術的には健全な移行計画だけが先に走り出してしまったプロジェクトだ。

段階的なテナント間移行は、実際にはどのようなものか

ガバナンスの判断が先送りではなく実際に下されると、移行そのものは予測可能な段階を踏んで進む。おおむね次のような流れになる。

• ディスカバリーとライセンス整理。 両テナントの完全な棚卸し——ユーザー、メールボックス、Teams、SharePointサイト、共有メールボックス、配布リスト、ライセンスの種別と数、セキュリティ構成——を並べて比較し、二つの更新日、二つの契約、重複または不整合なライセンスを、誰も並べて見たことのなかった二枚の請求書からではなく、一つの明快な全体像として把握する。
• 目標基準の決定。 データが動く前に、経営陣とIT部門が、どちらのテナントを残すか、どちらのセキュリティ構成を標準とするか、そして統合後の会社が実際に採用する命名規則、保持ポリシー、共有の既定値をどちらの会社のものにするかを合意する。これはガバナンスのセッションであり、技術タスクではない。取引のスケジュール圧力のもとで最も省略されやすい一歩でもあり、まさにそれが省略されやすいからこそ、統合が予定より大幅に長引く最も一般的な原因になっている。
• IDとドメインのカットオーバー計画。 被買収企業のユーザーが目標テナント上でどのようにIDを取得するか——新規アカウント、ディレクトリ同期、あるいは段階的なハイブリッド方式——を決め、メールが途切れず、誰のメールアドレスも移行の途中で壊れないよう、ドメインとメールルーティングの変更を計画する。
• 共存期間を挟んだ段階的なメールボックスとファイルの移行。 一度きりの週末カットオーバーではなく、メールボックス、Teamsのコンテンツ、SharePointライブラリを計画されたバッチ単位で移行し、その間、メールフロー、カレンダーの空き時間照会、共有ドキュメントが最後のバッチが完了するまで両方の環境で正しく機能し続ける共存期間を設ける。これこそが、性急な一括週末カットオーバーが招きがちなダウンタイムやリンク切れの混乱から実際に守ってくれる部分だ。
• カットオーバー後の強化とアダプション支援。 最後のバッチが移行し終わったら、旧テナントは背景で静かに稼働し続けるのではなく正式に廃止され、目標テナントのセキュリティ基準が移行済みの全ユーザーに適用・検証され、そして新しく統合された社員は、実際に機能するヘルプデスクや、何が変わったのかについての明確な案内といった、実務的なサポートを受ける。これこそが、統合後の会社が本当に新しい環境を使いこなすのか、それとも翌年一年間、回避策を探し続けることになるのかを左右する部分だ。

決める前に、選択肢を整理する

二つのテナントと、すでに遅れ気味の取引スケジュールを前にして、多くの経営陣は、明確にそう位置づけているかどうかにかかわらず、実際には三つの現実的な選択肢の中から選んでいる。二番目の選択肢は、多くの企業が想像する以上に魅力的で、しかもよくある選択肢であるため、三つとも名前を挙げておく価値がある。それぞれの正直なトレードオフは、誰かがそのうちの一つに既定のまま流されてしまう前には、めったに言語化されない。

二つのテナントをゲストアクセスのまま無期限に併存させる vs 自力での週末一括カットオーバー vs 目標基準を先に決めた段階的なテナント間移行（Brocentのモデル）

• 二つのテナントをゲストアクセスのまま無期限に併存させる — 短期的な混乱が最も少ない道であり、誰も積極的に選んだわけではないという理由だけで既定路線になることも多い。代償はここまで述べてきたとおりだ。無期限に続く重複ライセンスコスト、二つの基準のうち弱い方によって決まるセキュリティ態勢、整理の進んでいない二つの環境にまたがるPDPA義務、そして四半期を重ねるごとに悪化するTeamsと共有メールボックスの乱立。これは何も解決せず、すべてを先送りするだけだ。
• 自力での週末一括カットオーバー — 進捗を示す圧力にさらされた社内IT部門が、事前のガバナンス判断も共存期間もないまま、マイクロソフト純正の移行ツールを使って一つの週末ですべてを移そうとする。小規模でシンプルな環境であれば、これは実際に可能だ。しかし、実際のライセンスの複雑さと二つの相反するセキュリティ構成を抱える120名規模では、通常、メールフローの不具合、権限の欠落、月曜朝の混乱したユーザーを生む。そして目標基準が実際には一度も決められていないため、最終的なセキュリティ構成は、誰かが選んだものではなく、たまたま残ったテナントに設定されていたものになってしまう。
• 目標基準を先に決めた段階的なテナント間移行（Brocentのモデル） — 何かを動かす前に、ワーキングセッションでガバナンスの問いに答えを出す。完全なディスカバリーとライセンス整理を行う。プロジェクト途中で何も壊れないよう共存期間を設けた段階的な移行を行う。そしてカットオーバー後の強化により、統合後の会社は、たまたま引き継いだ基準ではなく、誰かが実際に選んだセキュリティ基準の上で稼働することになる。正直なトレードオフは、ガバナンスの作業を先に行う分、週末カットオーバーより着手までに時間がかかることだ。しかし、後でやり直しが必要になる可能性ははるかに低い。

これが、残りのIT全体とどうつながるか

テナント統合が単独で発生することはめったにない。多くの場合、それはより広範な買収後IT統合の一部だ——マネージドITクラウドサービスのもとで両社のクラウドインフラとデバイス管理を一本化すること、両社のセキュリティ態勢を、独立して維持される二つの体制ではなく単一のマネージドプログラムのもとに揃えること、そして移行期間中に何か問題が起きたときに、新しく統合された社員が頼れる確かな窓口を用意すること——それこそがきちんとリソースを備えた24時間365日のヘルプデスクの存在意義だ。これらすべてを一度にやる必要はないが、三つの異なるチームが三つの異なるスケジュールで動かす別々のプロジェクトとしてではなく、まとめて計画したほうが恩恵は大きい。

買収後の統合に取り組むシンガポールのテクノロジー企業にとって、テナント統合は、しばしば他の議論を実際に動かすきっかけになる部分でもある。どちらのセキュリティ基準を残すかを誰かが決めなければならなくなった瞬間、その議論は自然にクラウドインフラ、デバイス管理、そして統合後のチームにどうサポートを届けるかという話にまで広がっていくからだ。

よくある質問

この規模の会社の場合、テナント間移行にどれくらい時間がかかるか

統合後の従業員数がおよそ120名の会社であれば、ディスカバリー、ガバナンスの判断、共存期間を伴う段階的な移行、カットオーバー後の強化まで含めた、きちんと段階を踏んだテナント間移行は、通常、一つの週末ではなく数週間にわたる。ただし正確な期間は、被買収テナント側にどれだけ整理が必要か、そして経営陣がガバナンスの判断にどれだけ早く合意できるかに大きく左右される。計画されたバッチ単位でメールボックスとファイルを移す技術的な移行部分は、通常もっとも速く進む部分だ。より遅く、より変動が大きいのはほぼ常にガバナンスと意思決定の段階であり、この段階を形式的な手続きとして扱い、実際の作業をおろそかにする会社は、移行が実際に始まってからスケジュールが大きく延びる傾向がある。

二つのテナントをそのまま残して、ゲストアクセスでやり過ごしてもよいか

技術的には可能だ。統合を強制するものは何もなく、ゲストアクセスは会社間の一時的な協働には実際に機能する。実務上の問題は、ゲストアクセスがまさにそのため——一時的で限定的な協働のため——に設計されており、統合後の会社の日常業務を無期限に支えるためのものではないという点にある。最初の数か月を超えて二つのテナントを稼働させ続ける会社は、重複するライセンスコスト、弱い方のテナントによって決まる整理されていないセキュリティ基準、そして誰も全体を把握していないゲストアカウント・共有メールボックス・Teamsの絡み合いを積み重ねていく傾向がある。短期的な橋渡しとしては機能する。長期的な運用モデルとしては望ましくなく、続ければ続けるほど、最終的な統合のコストは高くなる。

メールの履歴、Teamsのチャット、SharePointの権限はどうなるか

段階的なテナント間移行では、過去のメールを含むメールボックスのコンテンツはメールボックスとともに移行し、Teamsおよびの SharePointのコンテンツは移行期間中に計画されたバッチ単位で移行する。権限については、単純なコピーではなく意図的な対応が必要だ。SharePointの共有リンク、Teamsチャネルのメンバーシップ、メールボックスの代理アクセスは、すべて旧テナント内のIDに紐づいて構築されており、自動的に引き継がれると想定するのではなく、目標テナント内の対応するIDへ改めてマッピングする必要がある。この再マッピングの工程は、急いで行うと移行後のトラブルの中でも特によくある原因の一つだが、共存期間によって移行チームが一括ではなくバッチごとに検証する時間を確保できれば、比較的正しく行いやすい工程でもある。

どれくらいのダウンタイムを見込むべきか

共存期間を伴う段階的な移行であれば、個々のユーザーやメールボックスの計画的なダウンタイムは、通常バッチごとの短いカットオーバー時間枠——メールフローが完全に切り替わるまでの数分から数時間程度——に限定され、長時間の停止にはならない。これは、一括の週末カットオーバーを試みるのではなく、共存期間を伴うバッチ単位で移行を段階化することの主な利点の一つだ。統合後の全社員が一斉にオフラインになるのではなく、各バッチが移行している間も会社の大部分は通常どおり業務を続けられる。

重複または不整合なライセンスはどう扱えばよいか

これはディスカバリー段階のライセンス整理の工程で解決される。両テナントのライセンス種別と数を棚卸しし、統合後120名の会社に対する目標ライセンス階層を決め、二つではなく一つの契約を交渉する。実際には、統合プロジェクトが自らのコストの相当部分を回収できるのは、しばしばこの部分だ。重複する一人あたりライセンスをなくし、一つの交渉済み契約に統合することは、一度限りのプロジェクト費用ではなく、直接的かつ継続的なコスト削減になるためであり、現在両方の契約で実際にいくら支払っているかを、早い段階で率直な料金比較によって確認しておく価値がある。

データが二つの環境にまたがっている間、PDPAはどう適用されるか

シンガポールのPDPAは、ある個人データがどちらのテナントに存在するかにかかわらず、統合後の会社が負う義務に適用される。買収が猶予期間を生むわけではない。実務上これは、統合が完了するまで両方のテナントが、弁明可能なセキュリティ体制、アクセス管理、侵害対応プロセスを備えている必要があることを意味し、「一時的な」二テナント状態を無期限に続けるべきではない十分な理由でもある。異なる二つの管理体制を維持する月が一か月増えるたびに、統合後の会社全体で一貫したコンプライアンスを示すために、一つの環境を統治するのではなく二つの独立した環境を整理しなければならない月が一か月増えることになる。

統合後、IDとセキュリティポリシーは誰が所有すべきか

理想を言えば、目標テナントが稼働開始する日から、一つの決められた基準に基づいて動く一つのチームであるべきで、それぞれの元のテナントのポリシーを並行して管理し続ける二つのチームであるべきではない。実務上これは通常、親会社のIT部門、あるいはそのマネージドITプロバイダーが、統合後の会社に対するIDのプロビジョニング、デプロビジョニング、条件付きアクセス、デバイスコンプライアンスの所有権を持ち、移行のガバナンス段階で合意した目標基準を用いることを意味する。誰もその問いを気にしなくなった時点でたまたままだ稼働しているテナントの方へ、既定のまま流れていくのではなく。

何も動かす前に、ガバナンスの判断を済ませておく

買収後のテナント統合は、システム障害のように差し迫った緊急性を持つことはめったにない。だからこそ、誰も意図していなかったほど長く、二つのテナントを並行稼働させたままにしてしまいやすい。きれいに乗り越えている企業は、ガバナンスの問いを、移行そのものがいつか解決してくれるものとしてではなく、何も動かす前に意図的に決めるべき判断として扱っている企業だ。もし貴社が取引の後に二つのMicrosoft 365テナントを抱えたままで、その解決策がいまだに「いずれ」で止まっているなら、お問い合わせください。これを実際に前へ進める対話は、移行日程からではなく、ガバナンスの問いから始まります。