こんにちは。技術本部でSaaSの管理やヘルプデスク対応をしているヘルプデスクオペレーターの戸田です。
今回の内容が、ヘルプデスク向けかというとそんなことは一切ないのでご容赦ください。情シスの業務の一環になるので、GWSの複数テナントに悩む情シス担当者、テナント統合を検討している人の参考になれば幸いです。
またGWSの移行に関する記事は下記の記事があります。 様々な理由でGWSのアカウントやテナントを統合する場合は、これらの記事を参考にすることでより理解が深まると思います。（実際に自分は深まりました）
- GMOペパボさん
- Ubieさん
- ふみふみさん
1. どうしてテナント統合をすることになったか
当時の弊社の環境を簡単に説明しますと、タイトルにもあるようにそもそも弊社が契約していたテナントがなんと50個近くありました。 通常であれば、1社1テナントであることが多いと思いますが、今思い出してもとんでもない数でした。
詳しく記載すると、大枠2つのパターンがありました。
- 会社用のテナント
- 業務委託用のテナント
会社用のテナントの環境を簡単に説明すると、 弊社はグループ会社であるため、子会社を抱えておりまして、その関係で1社ずつGWSのテナントを用意してました。 またグループ会社ということもあり、グループ内で出向をする方も少なくない状況下でした。 その結果、出向元と出向先でGoogleのアカウントを持つという状況になってました。(途中で出向した人とかは過去のメールアドレスを使いたいなども要望も当時はあったと思います)
複数テナントを管理・複数IDのデメリットは以下のとおりです。
- コストがかかる
- Googleカレンダーが使えない（どちらのアカウントを付与していいかわからない・弊社のグループは同じオフィスを使うので、会議室のリソースが使えない）
- 共有ドライブへのアクセス権の制御できていない
- 設定が漏れやすくなる（実際設定値はばらばらでした）
などなどカオスな環境下でした。 参考までに弊社の環境は、当時こんな環境でした。
- 本社のユーザーアカウント：900名近く
- 子会社のユーザーアカウント：5~200名近く（子会社によりけり）
外部委託用のテナントについては、一人の外部委託のためにテナントを1個契約をしてました。（管理アカウントと払い出し用のアカウントもあったので、2重のコストがかかってました） 50近くあるうちの30個以上は外部委託用のテナントでした。衝撃ですね。
そんなカオスな状況下だったため、まずGWSの環境整理とテナント統合を進める形になりました。
2. テナント整理プロジェクトの全体像
統合の図としては、ざっくりこんな感じです。
進め方としては、まずは本社のテナント環境の整理をしたあとに、テナントをまとめていきました。
- 本社環境の整理
- 組織部門の整理
- 共有ドライブの整理と「信頼ルール」の設定
- テナントの統合
- 移行先の仮アカウントの作成
- Google利用サービスの移行準備
- メールデータの転送
- OAuthの洗い出し
- 共有ドライブの整理・引っ越し
- 当日のドメインの切り替え
- その後の後片付け
といった流れでテナントの統合をすることにしました。
3. 本社のGWS環境の整理
組織部門の整理と外部委託用アカウントの整備
まず、統合の大本の環境の組織部門の整理をすることにしました。
組織部門は、設定を区分けすることでアクセス権の整理や設定値の反映もできるので、なるべく考えうるパターンを網羅できるように考えて、このような設定値にしました。
組織部門にある通り、外部委託という組織部門を用意したので、精査して移行先のアカウントを払い出す対応も同時に行いました。
※ ただ今思うと、別の設定がいいかなと思ってますので変更しようと思っている最中です。
共有ドライブの整理 と 信頼ルールの設定
このタイミングでなぜ直接的に関係ない共有ドライブを整理することになったのでしょうか。
当時なんとドライブの数が900件近くありました。（普通はどのくらいあるんですかね）
部署用のドライブもあれば、運用がされてないようなドライブも様々でした。 流石にこの状態で統合するとアクセス権の管理どころの話ではなくなってしまうと思い、まず共有ドライブの整理しました。
各部署にヒアリングし、900件のドライブを対象に、各部署への使用状況ヒアリングを実施しました。併せて一部フォルダの設計も見直しながら整理を進めた結果、100件くらいには整理ができました。
ちょうど今年に入ったタイミングから整理していまして、Geminiの利用が活発になってきたタイミングでもあったため、環境を整理することでAIの活用をできるきっかけにもなったと思っております。
ある程度整理が終わったタイミングで統合を見据えて「信頼ルール」を設定しました。 信頼ルールでできることに関しては、自分が解説するよりもすでに解説されてある記事がありますので、そちらを参照ください。
ざっくり説明すると、ドライブ上にあるファイルへのアクセス制御を組織やグループ単位などで制御できる機能になります。
そもそもなぜ設定することになったかというと、同じ一箇所のテナント内に統合すると、情報にアクセスすることが容易になります。 しかし、それは会社間で情報のガバナンスを担保できないという課題でもありました。
具体的な設定値は書けないのですが、方針としては以下のとおりです。
- 会社1から他会社にデータを共有できないようにする（会社間で簡単にデータを共有できないようにしました）
- グループ内という組織部門配下に共有ドライブを設定すればグループ会社内で共有できる
- 信頼済みドメインの組織部門に許可された会社のみ共有できる
上記の方針をとり、信頼ルールに落とし込みました。
4. テナント統合の実際の流れ
ある程度本社の環境の整理ができたタイミングで、本社テナントへ統合を始めました。
ここからがこのブログの本編です。
弊社のテナント統合で行わないといけないと判断されたのが、以下の対応です。
- 移行先の仮アカウントの作成
- Google利用サービスの移行準備
- メールデータの移行
- SaaSとGoogleアカウントの連携
- 共有ドライブの整理・引っ越し
- 当日のドメインの切り替え
順番に説明していきます。
※ 今回のブログに記載しないこと
- 今回移行のタイミングでGASを使ってますが、Geminiにお願いしながらだったので、スクリプト等は割愛します。
- Google Calendarは移行当時利用していなかったので、移行方法についてはわからないです。（新しく作り直すことになるんだろうなと思ってます）
移行先の仮アカウントの作成
統合するまでに事前に移行元環境にユーザーを作成します。将来的には、ちゃんとしたドメインに変更しますが、仮のドメインでアカウント作成します。 移行先の環境にアカウントがあれば、あえて作りません。
また、移行元のアドレスの一覧と切り替えた後のメールアドレスの一覧をスプレッドシートに用意します。これが、メールデータの移行時やテナントの統合時に必要になります。
Google利用サービスの移行準備
今回対象になったのが、以下のサービスです。
- Google Group
- Looker Studio
- Google 広告
Google Group
テナントをまたぐ場合は移行できないので、Google Groupは作り直すことになります。
テナント内のGoogle Groupの一覧と参加しているメンバーを出力します。（もちろんGASでやります）
移行先のテナントで作り直す場合、メンバーも移行先のアカウントで作り直す必要があるので、仮ドメインで作ったグループに移行先のアカウントを追加します。
Looker Studio
弊社はそこまで活用している人がいませんでしたので、使っている人がいれば作り直しの案内をしておりました。
アカウントが異なる環境になるため、データへの認証がそもそも変わることとLooker Studioの場合マイドライブのような環境にあるため、テナントを超えての移動ができませんでした。
Google 広告
Google広告を利用している場合、GWSとは別の環境のようです。オーナーが残っていれば、その環境が残るようなので、移行先のアカウントを事前に招待しておく必要があります。
これはAPI経由ではできそうにないので、地道な手作業が必要です。
メールデータの移行
メールの移動方法については、過去のメールデータの移動に関しては新しく追加された機能の「データの移行（新規）」機能を利用しました。
機能に関してはこちらの記事を参照してください
記事では、一度に移行できるアカウント数が100と記載されてますが、執筆時点では1000アカウントまで対応しているので、こちらで対応することにしました。
この機能は、今までのメールデータを転送はできますが、転送を開始した移行のメールデータは転送はしてくれないので、何度も転送を再開しないといけません。 それはめんどくさいので、移行先のアカウントに先に「受信者アドレスマップを使用したメール転送」を使って、いま来ているメールを転送することにしました。
ちなみに、元のアカウントのメールの利用が多ければ多いほど移行に時間がかかるので、直近1年だけ移動する方法や統合後に気長に転送をするという手段を取ることができます。
SaaSとGoogleアカウントの連携
Googleのアカウントに紐づいているものでかなり利用されているものがあるのが、GoogleアカウントのOAuthの連携でした。
これに関してはしょーーーじき、SaaSごとに仕様が異なるので確認するのが手間です。
GoogleアカウントのUID (Googleアカウント固有の内部ID)を見ているパターンもあれば、メールアドレスを見ているパターンもあります。このため、実際にそのサービスに試すかサポートに聞くかしないといけませんでした。
これに関しては、地道な確認しかないです。（すべてSSOをしていたらこんな悩みはないのでしょうか....）
他のSaaSのパターンでGoogleアカウントを使うのが、Slack等のワークフローでの認証系です。基本的に前のアカウントに紐づくので連携が解除される可能性があります。事前に告知はしましたが、すべての利用箇所を把握していないため、問題があれば都度対応するという方針にしました。
共有ドライブの整理・引っ越し
共有ドライブの利用は、その企業ごとにばらばらでした。使っているところもあれば、マイドライブでやっているとこもあるので、こちらも本社同様の整理と設計する必要がありました。
マイドライブに関しては各自でデータの移動をお願いしました。 仕事で使っているデータに関しては、新しい共有ドライブに移動してもらいました。
移行手順は以下のとおりです。
- 設計した共有ドライブを移行先のドライブに用意する
- 一時的にそのファイルの両方を管理者にすることでデータ移動できる状態にする
- 子会社に移行方法の案内を出し、そちらにファイルを移動してもらう(もし移行できない等のトラブルがあれば、対応する)
※管理者ロールを用意しないとデータが移動できないかと思っていましたが、弊社の環境ではフォルダ単位でマイドライブから共有ドライブにデータの移動をしていました。
実際にあった珍しいファイルが移行できなかった事案
ものすごく稀有なパターンだと思いますが、こんなことがありました。
GWSのマイドライブ上にスプシが作成されており、そのオーナーがGoogle Cloudで作成されたサービスアカウントになっていました。そのため、マイドライブ環境から移動ができないという摩訶不思議な状況に出会いました。
マイドライブからの移動は、オーナーでないとできないのですがそのオーナーがサービスアカウントとなっており、人の手で移動ができない状態で手詰まりかと思いました。
代理店に相談の上、スクリプトを提供してもらい解決できました。
当日のドメインの切り替え
実際にドメインを切り替えした際の手順について話していきます。
弊社が取った流れは以下のとおりです。 1. 一週間くらい前にDNSのMXレコードのTTLを短くする & 前の環境にサブドメインを登録しておく 2. 前日にMXレコードの向き先を弊社管理のメールサーバーに変更し、メールをためておく 3. 当日に移行元アカウントとグループのドメインを一括で置換&エイリアスからも削除をし、プライマリドメインを変更する 4. 移行先に移行したいドメインを登録して、アカウントとグループのドメインを一括で置換する 5. MXレコードを移行先（Google）に向け直す 6. メールサーバーの設定でホールドしていたメールを解放することで、正しいアカウントに向かってメールが飛ぶ
実際の対応について、社員の方が使ってない時間帯と土日に対応いたしました。
ドメインの切り替えをする際にどうしても避けては通れない問題であるメールのダウンタイムどうする問題に弊社が取った対応についてまとめさせていただきます。
まず、TTLを短くする理由ですが、デフォルトだと3600なので一時間も反映を待たないといけません。その間にドメインの切り替えをしてしまうとメールデータをロストする可能性があるので、なるべく短い時間に変更をしました。 とはいってもTTLを1にするわけにはいかないので、1週間くらい前から60で設定をしてます。
移行時の準備ですが、なぜ向き先をメールサーバーにしたかというと、そこにしか送る先がなかったからです。 他の記事では、Exchange Onlineを活用していたりしますが、弊社だと送れる環境が存在しませんでした。
そして、弊社は令和時代でもメールサーバーを運用しており知見を持った人もチーム内にいたため、一時的にメールサーバーを準備してメールを保持するようにしました。
数時間経ってからMXレコードの切り替えをした理由は、念の為保持する期間を長めに取ろうという方針を取ったためです。保持することを確認したら、切り替えをしちゃってもいいかもしれませんが、そこは方針次第だと思います。
弊社としては、メールをロスすることなく、切り替えをしました。
※ 数十分の間なら別にロストしてもいいというのであれば、この対応は不要ではありますが、なかなかそんな会社はいないでしょう。
アカウントの設定についても、あらかじめ用意しておいた統合先の元のメールアドレスと変更先のメールアドレスをもとにGeminiで作ったGASにお任せしました。
統合前の環境からドメイン消す際は、ユーザーやグループで対象のドメインを使っていると消せないので、別のドメインに変更します。その際、サブドメインに変更だけすると予備のメールアドレスに自動的に登録されてしまいます。なので、予備のメールアドレスからも消す必要があるので忘れないようにしましょう。
GASには一度メールアドレスを変更してから、数分あけてから予備のメールアドレスを一括して消す処理にしました。
こんな処理もすぐ作ってくれるGemini様々です。
問題ないかの確認し終わったら、対象者に終わったことを連絡して当日の作業は完了です。
最後の方は慣れてきたこともあり、だいたい30分未満くらいでできました。
5. その他の後片付け
残りの後片付けですね。
今まで使っていた環境を契約を終わらせないとコストはかかったままになるので、クロージング作業です。
もう使っていない環境であれば退職者のデータ等を移行先の環境に集約する必要があるので、アカウントを消しつつデータを避難させました。
中にはまだデータが前のテナントに残っていたという方もいらっしゃるので、そういった対応もしつつ、最終的にはテナントを削除してさよなら。というお片付けですね。
おわりに
実際の統合作業に関しては、1月から始まり年内に何個もの会社をテナント統合を実現しました。
正直会社の皆さんが対応してもらえないとできないことだらけでしたので、周りの人の協力あって整理できたなという気持ち半分、もうお腹いっぱいという気持ち半分です笑
テナント統合したいなーという方に、もし弊社の知見がお役に立てればと思います。
