要約

  • Google Cloudのプロジェクトを別組織へ移しても、元のCloud Billingアカウントとの関連付けは維持される。
  • Cloud Marketplaceで直接購入した有効な注文の移管には顧客とソフトウェア販売元の同意が必要で、1週間以上かかる場合がある。
  • 手続き中に移管先アカウントで同じ販売元の製品を購入すると、移管は実行不可能になる。調達の順序まで引き継ぎ計画に含める必要がある。

事業の売却が決まり、クラウド上のプロジェクトも買い手の組織へ移る。管理画面だけを見れば、引っ越しは見事に終わっている。ところがGoogle Cloudでは、そのプロジェクトの費用を元の請求先アカウントが払い続けることができる。新しい表札は付いた。生活費はまだ実家持ちだ。

これは手続き漏れが起きたという顧客事例ではなく、Googleが示している製品の仕組みだ。プロジェクト移行の説明によると、組織間の移行では上位リソースを示すメタデータが変わる。プロジェクトID、番号、データ、リソースは維持される。プロジェクトに直接付与されたIAMロールも、請求先アカウントもそのまま残る。

Cloud Billingアカウントは、組織をまたいでプロジェクトの費用を負担できる。所属を変える操作と、費用負担者を変える操作を分けているわけだ。事業を受け取る側にとって、管理上の配置が完了したことと、運営条件を自分たちで引き受けたことは別の成果になる。

管理権限と支払う権限は別々に配る

権限も一括で移るわけではない。旧組織から継承したIAM権限は失われ、新組織のポリシーが適用される。直接付与されたロールは残るため、何が継承で何が直接指定だったかが実際のアクセスを左右する。リソースが存続することだけで、アプリケーションのアクセス経路や依存関係をすべて説明することはできない。

移行に必要なロールの文書は、プロジェクトを移動する権限と請求先を変更する権限を分けて扱う。後者には、移行先アカウントのBilling Account Userや、プロジェクトのProject Billing Managerといったロールが登場する。請求に特化した文書では、閲覧、関連付けの解除、新しい関連付けに必要な権限も詳述される。プロジェクトを動かせる担当者が、そのまま新しい財布を使える設計ではない。

財布の状態は運営に直結する。請求設定の変更に関する文書では、プロジェクトの課金を有効にするには、関連付けたアカウントが有効で正常な状態にあることを求めている。閉鎖または停止されたアカウントでは、有効化したサービスを利用できない。無料利用の条件を満たすサービスも含まれる。

旧会社が支払っているからといって、IAM上の操作権限まで自動的に持つわけではない。支払いを維持する役割とプロジェクトを管理する権限が、分かれて存在する。事業分離で見落としやすいのは、この二つがそろって初めて運営条件が整うという点だ。

注文の引き継ぎはメールの返事を待つ

購入済みソフトウェアには、さらに別の当事者がいる。プロジェクトの請求設定を変える文書は、関連するMarketplaceの購入を先に移管するよう求める。Marketplaceの請求管理文書は、移管先アカウントで必要なリソースを購入済みであることを要求し、不足があればコンソールが警告すると説明している。プロジェクトが同時に関連付けられる請求先アカウントは一つだ。

Cloud Marketplaceから直接購入した製品について、有効な注文の請求先変更手続きは顧客と独立系ソフトウェア販売元の合意を必要とする。Billing Account Administratorのロールを持つ顧客が販売元に依頼する。販売元が承認するとGoogleへ申請し、Googleが処理して承認メールを送る。関係者全員が承認の返信をした後、移管を完了して通知する流れだ。

Googleは、この手続きに1週間以上かかる場合があるとしている。7日で終わる保証ではない。移管できる条件を満たしていることも必要になる。技術担当者の作業時間を短くしても、他の当事者の同意まで短縮できるわけではない。

調達部門が知るべき制約は、その待ち時間の中にある。移管中に移管先アカウントで同じ販売元の製品を購入すると、移管は実行不可能になる。同一製品の重複購入だけを避ければよいという話ではなく、販売元が同じであることが条件だ。

新会社の調達を早く独立させようとする行動が、既存注文の承継を妨げる。各担当者が自分の仕事を急いでも、全体の引き継ぎは進まないことがある。この場合に必要なのは、管理者権限の追加よりも、購入する人と移管する人の予定を合わせることだ。

残る事業の割引も動く

請求先の変更後にも、旧アカウントには費用が届く。変更前に発生した利用分は、まだ報告されていなくても旧アカウントの請求となる。サービスによっては報告に最大2日かかる。これは古い利用分の計上が遅れるという意味であり、変更後の新しい利用をさらに2日間負担するという規則ではない。

Supportのように、特定プロジェクトに割り当てられないアカウント単位の費用もある。移行したプロジェクトの一覧だけでは、旧アカウントの残る支出を把握し切れない。

逆に、費用の優遇は移動する場合がある。請求先を変更するプロジェクトに含まれるCompute Engineのリソースベースの確約では、割引は移行先アカウントで適用され、旧アカウントのプロジェクトはその確約の恩恵を受けなくなる。移行先での共有範囲はそちらの設定によって決まる。売却される事業だけでなく、会社に残る事業の予算にも影響する仕組みだ。

Cloud Armor Enterprise Annualにも具体的な条件がある。移行先アカウントに同じ年間サブスクリプションがなければ、そのプランに加入していたプロジェクトはStandardへ戻る。リソースが同じでも、利用条件のすべてが同じままとは限らないことを、明確な商品単位で確認できる。

旧アカウントを残すという経営判断

支払いのつながりを残すことには、経済的な理由もある。Googleが2023年5月2日に公開した事業分離時のリソース構成に関する記事は、架空のRemainCoとNewCoを使い、既存の確約契約を履行するために元の請求先アカウントによる資金負担を維持する選択を説明している。販促クレジットやサポートパッケージも、新会社や新アカウントに自動で広がるわけではない。

意図して残した過渡的な資金関係と、気付かず残した未処理事項は、管理画面では似て見える。違いは、誰が費用を負担し、何をもって関係を終えるかが合意されているかどうかにある。

個別の引き継ぎを評価するには、実際のIAM設定、請求先の関連付け、購入内容、承認記録が必要で、公開文書にはその顧客資料はない。

ただ、完了判定に誰が必要かは分かる。プロジェクトを管理する担当者、資金を引き受ける担当者、注文を移管する販売元だ。新しい組織図を確認するだけでは、このうち一部の仕事しか終わっていない。運営の独立を宣言するなら、表札を掛け替えた人だけで記念撮影を済ませるわけにはいかない。