2 つが 1 つになる: 合併または買収後の Google Cloud 上の組織の統合

Google Cloud Japan Team
※この投稿は米国時間 2022 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。
おめでとうございます。あなたの会社は他の組織の買収または合併を終え、その歴史で重要となる新たな一歩を踏み出したところです。しかし多くの商取引と同様に、細部には予想外の面倒が潜んでいます。2 つの会社のクラウド ドメインと組織を統合する場合は、特に大変になります。このブログ投稿では、Google Cloud の観点から、合併と買収(M&A)への取り組み方を説明します。これらは Google Cloud テクニカル アカウント マネージャーが実践しているベスト プラクティスです。統合を実施する場合は、これらのベスト プラクティスに従うことをおすすめします。
M&A にはさまざまなシナリオがありますが、ここでは次のような最も一般的な 2 つのシナリオに焦点を当てます。
M&A に携わる両当事者が Google Cloud を使用していて、ある程度の統合を求めている
当事者の一方のみが Google Cloud を使用していて、最良の連携方法を検討している
2 つの会社を統合するためのアプローチは、状況に応じて大きく異なります。
両方の会社が Google Cloud を使用している場合
最初のシナリオで、会社 A が会社 B を買収していると仮定します。M&A 以前、両社に独自の Google Cloud 組織(Google Cloud リソース階層の最上位構造)があり、それぞれ 1 つ以上の請求先アカウントが関連付けられています。各 Google Cloud 組織の下には、さまざまなフォルダとプロジェクトもあります。このシナリオでは、次のような重要な質問を行います。
2 つの異なる Google Cloud 組織をどのように統合するのか?
請求体系をどのように整理するのか?
2 つの組織の下でプロジェクトをどのように扱うのか?
2 つの組織の ID 管理戦略はどうなるのか?
これらの重要な質問のそれぞれについて、詳細な行動計画を策定してください。Google Cloud プレミアム サポートを通じてテクニカル アカウント マネージャー サービスにアクセスできる場合は、お問い合わせいただき、この計画をさらに発展させることもできます。
Google Cloud 組織を理解する
M&A の各当事者に独自の Google Cloud 組織がある場合、組織統合の観点からは、統合なし、部分統合、完全統合と、さまざまな選択肢があります。
統合なし - B 社が A 社から独立した事業体として運営される場合、移行は必要ありません。注意すべきことは、A 社が Google Cloud と交渉のうえ、より良い価格条件 / 割引やサポート パッケージを利用しているかどうかです。その場合、Google Cloud のアカウント担当者と連携してアフィリエイト付属契約に署名することで、B 社に同じメリットを享受させることができます。


部分統合 - 一部のプロジェクトは会社 B から会社 A に移行しますが、他は会社 B に残ります。2 社間での共有アクセスが可能であり、各組織は既存の ID プロバイダを引き続き使用できます。部分統合は、2 社の複雑さと、2 社間で行う必要のあるプロジェクトの移行の数に応じて、セルフサービスになる場合もあれば、Google Cloud との有料サービス エンゲージメントになる場合もあります。


完全統合 - 会社 B は会社 A に完全に組み込まれます。つまり、請求、Google Workspace ID、プロジェクトを会社 B から会社 A に完全に移行することになります。完全統合は複雑なプロセスになる可能性があるため、Google Cloud のアカウント担当者を関与させて、この移行を行うための有料サービス エンゲージメントを検討することを強くおすすめします。


プロジェクトの移行を計画する
どのような最終状態を目指している場合でも、プロジェクトの移行には綿密な計画が必要です。繰り返しになりますが、テクニカル アカウント マネージャーが割り当てられている場合は、この移行を開始する前に連絡を取り、ベスト プラクティスについて話し合ってください。
セルフサービス アプローチを採用している場合の全般的なアドバイスとして、Resource Manager API を利用してプロジェクトの移行を管理することをおすすめします。このアプローチにはいくつかの前提条件があり、実践する前にここに記載されている必要な権限を割り当てなければならないことに注意してください。
さらに、以下の請求と ID 管理に関する考慮事項を必ず読んで、こうした移行に関連するすべてに対し万全に備えていることを確認してください。選択内容によって、Google Cloud のフットプリントが根本的に変わる可能性があります。
請求に関する考慮事項
組織と請求先アカウントの構成方法を決定する際には、常に組織ノードの数を制限し、フォルダー構造を使用し、その中で部門 / チームを管理することをおすすめします。組織ノードの追加が推奨されるのは、ビジネス上の特別な理由で、特定のプロジェクトを中央管理からある程度分離する必要がある場合のみです。たとえば、買収された会社がすでに独自の組織ノードを所有していて、これを独立した事業体として稼働させるビジネス上の正当な理由がある場合などです。
警告: 複数の組織ノードがある場合は、すべての組織のリソースを一元的に表示することはできません。また、さまざまな組織ノードにわたるポリシー管理が煩雑になる可能性があるので注意してください。また、複数の Workspace アカウントを管理し、それぞれで ID を管理することも必要になります。これは特に大規模な運用の場合、困難になる可能性があります。
請求先アカウント管理の観点から、組織ノード内には一元管理された請求先アカウントを 1 つ作成し、タグとラベルを組み込むことで、詳細に管理することをおすすめします。ただし、次のように、請求先アカウントの追加作成が正当化されるビジネスケースもあります。
法的または会計上の目的から、料金を分割する必要がある
請求書が複数の通貨で支払われる
使用量を分割して、Google Cloud のプロモーション クレジットを有効活用する
子会社には独自の請求書が必要である
確定利用割引や支出ベース割引、プロモーション クレジットは、請求先アカウント間で共有できず、請求先アカウントごとに割り当てられることに注意してください。そのため、請求先アカウントが増えると、これらの割引やクレジットを活用するのが難しくなる可能性があります。
ID 管理
ご想像のとおり、2 つの事業体を統合すると、ID 管理に影響が及びます。Cloud Identity は、ユーザー ID とグループ ID を管理するために Google Cloud が活用するソリューションです。買収された会社が Google Workspace の一部である生産性向上プロダクトのみを使用している場合でも、ID は Cloud Identity によって管理されます。
Google Workspace に関する考慮事項
大量のコンテンツを Google Workspace ドメインに移行するには、最終目標とデータの複雑さに応じて、次の 3 つのオプションのいずれかをおすすめします。
一般的な移行の場合: Google Workspace Migrate を利用して、別の Workspace ドメインまたはサードパーティの生産性向上ソリューションから、目的の Workspace ドメインにデータを移行する
手動移行の場合: エクスポート ツールを使用して組織のデータを Cloud Storage アーカイブに書き出し、エクスポートしたデータをユーザーとサービスごとに選択的にダウンロードできるようにする
複雑な Google Workspace シナリオの場合: 範囲を限定したカスタム エンゲージメントを使用して、ビジネスを中断することなく 2 つの Google Workspace 環境を統合できるかどうかについて、Google Cloud テクニカル アカウント マネージャーに相談する
一方の会社のみが Google Cloud を使用している場合
次は、A 社のみが Google Cloud を使用していて、B 社は使用していないシナリオを考えてみましょう。この 2 つの組織を統合するために採用するアプローチは、目的とする最終状態、つまり完全統合か、部分統合か、統合なしかによって大きく異なります。
最終的に B 社を A 社に統合する計画の場合、ここでのアプローチは、上記の「完全統合」オプションと多くの類似点があります。ただし、似ているのは途中の時点からです。
また、B 社が別のクラウド プラットフォームを使用していて、Google Cloud との間でリソースの移行が必要となるシナリオも考えられます。繰り返しになりますが、上で説明した部分統合オプションと同様に、目的とする最終状態の複雑さに応じて、有料のエンゲージメントが適している場合もあれば、セルフサービスによる実施が適している場合もあります。
サポート
合併や買収はどの企業にとっても記念すべき重要な出来事ですが、慎重な管理を必要とする出来事でもあります。これらの考慮事項を入念に検討してから、組織の行動計画を作成してください。また、目的の結果を達成するために、有料のエンゲージメントであれば Google のプロフェッショナル サービスを、セルフマネージド プロセスであれば Google のテクニカル アカウント マネジメント サービスを利用することもできます。
組織で M&A を実施している、あるいは M&A を検討しているが、上で説明したシナリオと異なるというお客様は、Google のアカウント担当者にお問い合わせいただくか、https://cloud.google.com/contact までご連絡ください。
- Cloud カスタマー エクスペリエンス担当テクニカル アカウント マネージャー、Sharath Subrahmanya
- Cloud カスタマー エクスペリエンス担当テクニカル アカウント マネージャー、Jose Parakkat