この記事は、 STORES PX Advent Calendar 2023 Spring の1日目の記事です。
はじめに
こんにちは、STORES のPX部門IT本部でマネージャーをしている中野（@howdy39）です。
IT本部ではプロダクトづくりを支える社内ITを構築・運営しているのですが、社名変更という全社的なビッグイベントを最近行ったので、その中でIT本部が行ったGoogle Workspaceにおける社名変更対応について書いていこうと思います。
まず背景を軽く説明しますと、2022年10月1日に、ヘイ株式会社から STORES 株式会社へと社名変更を行いました。それに伴い、会社として使用しているドメインもhey.jpからst.incへ変更することになりました。*1
ドメインが変わることで、個人アカウントのメールアドレスやグループアドレスの変更が必要になります。 当初はドメインエイリアスに新ドメインを追加し、メール対応だけを簡単に済ませようと考えていたのですが、この方法は採用しませんでした。 その代わりに新ドメインをセカンダリドメインとして追加し個人アカウントを旧ドメインと同じ数を作成。メールやドライブなどのリソースを新アカウントに移行する方式を採用しました。
なぜこのような方法を選んだのか、そして実際の移行手順について解説していきます。 今後このような対応を行う方の参考になれば幸いです。
またGWSの移行に関する記事として下記のような記事があります。 社名変更やその他の理由でGWSアカウントの移行が必要になった場合は、これらの記事も参考にすることでより理解が深まるのであわせてみることをおすすめします。
- GMOペパボさん
- Ubieさん
- ふみふみさん
参考までに、弊社のhey.jp GWSの利用状況はこんな感じでした。
- ユーザーアカウント数：約450
- グループアドレス数：約200
なぜドメインエイリアス追加ではなく、アカウントの引っ越しにしたのか
Google Workspaceに閉じた世界であれば、新ドメインであるst.incをドメインエイリアスとして追加するのが一番簡単です。当初はドメインエイリアスで進めようと調査を進めていましたが、デメリットが大きすぎると判断しました。
主なデメリットを下記に記載します。
- Google認証で作成されたSaaSアカウントのドメインがプライマリドメイン（=hey.jp）になる
- 様々なSaaSでhey.jpのアカウントが今後も残り続けるどころか、逆に増え続けてしまいます
- メール送信時に明示的にst.incアドレスを設定しないと、プライマリドメインのhey.jpアドレスで送信されてしまう
- STORES 株式会社と名乗っているにも関わらず、hey.jpアドレスから送信されるのは不適切です
- GWSへのサインインに使うアドレスがhey.jpアドレスになる
- カレンダー招待やファイル共有メール等がhey.jpアドレス宛に届く
- GWSのサービスで各種ユーザー選択時のメールアドレスにhey.jp, st.incの両方が表示される
- どちらのアドレスを使用すればよいのか？という混乱を生みます（エイリアスなのでどちらでも良いのですが）
これらの問題を抱えたまま仕事をするのは足かせをつけた状態のまま仕事をするようなものです。そのため、ドメインエイリアス追加ではなく、st.incアカウントを新規作成 → st.incアカウントに引越し → hey.jpアカウントの削除、という3ステップで進めることが最適だと判断しました。*2
社名変更におけるアカウント引越しの全体像
アカウントの引越しが必要になるということは、SSOの変更やGoogle認証で利用している多くのSaaSの引越しも必要になります。
そのため、下記のような引越しプロジェクト全体のタイムラインをまず作成しました。 本記事はその中のGWS部分だけを切り出して解説しています。
※ 実際のスケジュールはこの図よりかなり巻いて進められたので、12月末時点で旧ドメインであるhey.jpアカウントは削除までやりきりました
Google Workspace引越しタイムライン
Google Workspaceのアカウント引越しはGWS内の各種サービスの引越し順序が重要になってきます。
例えば、カレンダーより先にメールを停止してしまうと招待メールが届かなくなってしまう、Meetより先にドライブを停止してしまうと録画ファイルの置き場がなくなる、みたいなことが発生してしまいます。
主要サービスだけあげると、グループ→カレンダー（Meet）→ドライブ（Looker Studio）→メールの順番で引越しを行いました。
本記事では上記の引越しを実際に行った順でそれぞれ解説していきます。（細かいところではGCPやYouTubeなどの引越しもありましたが、それほどつまずくことはなかったので割愛します）
- st.incアカウント発行
- Googleグループの引越し
- Googleカレンダーの引越し
- Googleドライブ、Looker Studio、Google Apps Scriptの引越し
- Gmailの引越し
- hey.jpアカウント停止・削除
1. st.incアカウント発行
st.incアカウントの@前（ローカルパート）は、旧ドメインである@hey.jpと同じものを使って作ることにしました。新旧アドレスの変換ルールが簡単でなければ、引っ越し作業が難しくなると判断したためです。
st.incアカウントの発行手順は以下の通りです。
GAMを使ってhey.jpユーザー一覧をCSVでエクスポートします。
# アカウント一覧を取得するスクリプト gam print users primaryEmail firstname lastname ou suspended agreedToTerms aliases creationTime lastLoginTime orderby email > all_users.csv
ユーザー一覧CSVをスプレッドシートに取り込み、シート上でGAMで叩くアカウント発行スクリプトの文字列を作って実行します。
# アカウントを発行するスクリプト gam create user howdy39@st.inc firstname Tatsuya lastname Nakano org 'OU名';
Tips スクリプトの文字列はArrayFormula関数で作る
スプレッドシートで作るスクリプトの文字列は、ArrayFormula関数を使用して作成することをおすすめします。そうすることで誤って途中のセルを変更してスクリプトが壊れてしまうリスクを回避できます。
=ARRAYFORMULA("gam create user " & F2:F & " firstname " & D2:D & " lastname " & E2:E & " org 'OU名';")
Tips エイリアスに注意する
一部のユーザーにはエイリアスが設定されている可能性があります。
例えば、howdy39@hey.jpというアドレスには、howdy@hey.jpというエイリアスが付与されているかもしれません。
そのため、howdy39@st.incのエイリアスにもhowdy@st.incのエイリアスを設定することを忘れないでください。
※ アカウント一覧をエクスポートするスクリプトにaliasesを含めていたのは、この対応を行うためです。
Tips スクリプトの実行確認は確認用のスプレッドシートを作って確認する
スクリプトが正常に動作しているかを確認するために、差分確認用のスプレッドシートを事前に準備することをおすすめします。
例えばアカウント発行の場合ですと、スクリプトを実行する前にユーザー一覧を取得（A）、スクリプトを実行しアカウント発行した後にもう一度ユーザー一覧を取得（B）、Aのドメイン部をst.incに変更したアドレスをXLOOKUP関数でBから引き当てて存在をチェックするといった確認スプレッドシートを作ります。
これを作っておくことにより、リリース作業時間を短縮することにも繋がります。事前に数アカウントで実行してリリース作業をシミュレーションしておくとよいでしょう。
2. Googleグループの引越し
Googleグループの引越しはグループアドレスをそのままst.incにアドレス変更する形での引越し方法を取りました。
※ 旧ドメインであるhey.jpアドレスは自動でエイリアスになります
グループメンバーにはアカウントとグループの両方が存在します。
グループメンバーがグループだった場合は、グループアドレスを新ドメインに変更しているので特に気にする必要はありませんが、アカウントがメンバーだった場合は手動でメンバー登録しなおす必要があります。
また、ユーザー影響を少なくするためにhey.jp アカウントと st.inc アカウントを両方グループに残す期間を設けました。
そのためグループにst.incのアカウントを追加（A）→グループからhey.jpのアカウントを削除（B）の2段階にして移行しました。
また、この A と B の間は1ヶ月という短期間にすることで下記のような問題が起きる期間を短くしました。
- グループあてのメールが両方のアカウントに送信され続ける
- グループアドレスでhey.jpアカウントに共有している権限が残り続けると、旧アカウントであるhey.jpアカウントを使い続けてしまう
このとき使ったスクリプトの作り方をざっくりですが記載しておきます。
グループアドレス変更
グループ一覧をGAMで取得しアドレス変更スクリプトを作って実行します。
# グループ一覧取得スクリプト gam print groups name description aliases > all_grous.csv
# グループアドレス変更スクリプト gam update group hoge-group@hey.jp email hoge-group@st.inc;
グループメンバー追加・削除
全グループメンバーをスプシに出力するGASを適当に作成します。（GAMだとほしい形式にするのが難しかったため）
あとは、メンバー追加と削除のスクリプトを作って実行します。
# メンバー追加スクリプト gam update group hoge-group@st.inc add member user hoge-member@st.inc;
# メンバー削除スクリプト gam update group hoge-group@st.inc remove user hoge-member@hey.jp;
3. Googleカレンダーの引越し
Googleカレンダーは10月いっぱいを引越し期間としhey.jpのカレンダーを使ってもらう、11月からst.incのカレンダーを使ってもらう流れにしました。
引越し期間を1ヶ月にした理由は、1ヶ月以上先の予定はほとんどが繰り返し予定だったためです。繰り返し予定さえ引っ越しできれば単発予定の引越しはそこまで大変ではないかなと。
この図だけ見ると簡単そうにみえるかもしれませんが、引越し手順の作成はカレンダーが一番大変だったと思います。
これは以下のような理由があるためです。
- タイミングを合わせて一気に引っ越しする必要がある
- 450アカウントもあると全員に正しく手順を認識してやってもらうのが難しい
- 予定の引越し作業を複数人で行うと予定の重複が起きる可能性がある
- 会議室（カレンダーリソース）の予約も引っ越さないといけない
- ※ 単純に新しく予定を作っても、元の予定を消さない限り会議室が取れない
そのため引越手順を3つのSTEPにわけてスムーズに引越せる流れを作りました。
- STEP1
- 10月中はhey.jp、11月からst.incのカレンダーをそれぞれ使わせたいです。そのため全員のカレンダーに対して下記の予定登録をブロックするための予定を作って参加してもらいました。これによりゲスト招待しようとしても既に予定が入っている状態を作れます。
- hey.jp カレンダーに対しては11月以降の予定をブロックする予定
- st.inc カレンダーに対しては11月までの予定をブロックする予定
- 10月中はhey.jp、11月からst.incのカレンダーをそれぞれ使わせたいです。そのため全員のカレンダーに対して下記の予定登録をブロックするための予定を作って参加してもらいました。これによりゲスト招待しようとしても既に予定が入っている状態を作れます。
- STEP2
- 既存の繰り返し予定を10月末までに変更してもらい、そのまま11月以降にst.incアカウントで 同じ時間枠・会議室 で繰り返し予定を作成してもらいました。
- STEP3
- 11月以降の単発の予定を削除→そのままst.incアカウントで同一内容の予定を新規登録して引越してもらいました。
- ※ 予定のカレンダーと主催者をst.incアカウントに変更、でも行けそうな気がしますがその場合、MeetのURLもhey.jpアカウントに紐づくので再生成しないと使えなくなります。ややこしいので普通に新規登録したほうがベターです。
- 11月以降の単発の予定を削除→そのままst.incアカウントで同一内容の予定を新規登録して引越してもらいました。
- GOAL
- 10月末日にhey.jpアカウントのカレンダーとMeetのサービスを管理コンソールから閉じて引越し完了です。
Tips 予約枠 / 予約スケジュール / 共有カレンダー の引越しも必要
Googleカレンダーの機能にある予約枠や予約スケジュールの引っ越しも必要なので同時にアナウンスしました。
また、メールアドレスと同じ個人のメインカレンダーではなく、共有カレンダーをユーザーが作っている場合があります。弊社の場合、共有カレンダーを作りたいときは依頼してもらうフロー*3を作っていたのもあり大きな影響はありませんでしたが気をつけたほうが良さそうです。
Tips SlackのGoogleカレンダーアプリの引越し
GoogleカレンダーアプリとSlack連携しているユーザーが多かったので11月1日の切り替えタイミングでst.incアカウントで再連携してね。のアナウンスを入れました。
カレンダー連携してるアプリケーションは会社によって変わると思うので自社の利用状況に応じて適切なアナウンスを入れると良いかなと思います。
4. Googleドライブ、Looker Studio、Google Apps Scriptの引越し
ドライブ系も10月の1ヶ月で一気に引越すフローにしました。
Googleドライブには大きく分けて共有ドライブとマイドライブの2つがあるので、それぞれの引越し方法を書いていきます。
共有ドライブの引越し
共有ドライブに対する権限をグループで付けていた場合、そのままst.incグループに変わるので特に注意する点はありません。個人アカウントでドライブに権限が付いていた場合、権限が外れてしまわないようにすべての共有ドライブに対して新アカウントに同じ権限を付与をすることで対応しました。
まず、共有ドライブ一覧をGAMで出力します。
※ ポイントは最後のasadminで、これを入れることで実行ユーザーがドライブの管理権限を持っていなくても共有ドライブの操作が可能になります。*4
# 共有ドライブ一覧を出力するコマンド gam user howdy39@st.inc print shareddrives asadmin > all_drives_asadmin.csv
共有ドライブごとのメンバー一覧は上記で出したDriveのIDを使ってNode.jsでスクリプト書いて一括出力しました。（割愛）
※ 権限削除時はメールアドレスではなく権限に対するidでAPIを叩く必要があります、そのため権限idの取得は権限一覧を別で取得するNode.jsのスクリプトを書く必要がありました。
権限付与はGAMを使って下記のようなコマンドを実行します。
# hoge@st.incに閲覧権限を付与するコマンド gam user howdy39@st.inc add drivefileacl DRIVE_ID user hoge@st.inc role reader asadmin;
メンバー権限削除はGAMを使って下記のようなコマンドを叩きました。
# メンバー権限を削除するコマンド gam user howdy39@st.inc delete drivefileacl DRIVE_ID id:nnnnn asadmin;
マイドライブの引越し
マイドライブの引越しはGAMのコマンドを使い、各アカウントに対してData Transfer APIを叩いてまるごと移管しました。Looker StudioはDriveとは違う領域に保存されているのでそれぞれコマンドを叩く必要があるので注意しましょう。
また、同一ユーザーのTransferは一つしか動かせなかったのでどちらかのTransferが終わってからもう一方を動かす必要があります。
# Driveの引越しコマンド gam create datatransfer howdy39@hey.jp gdrive howdy39@st.inc privacy_level shared,private; # Looker Studioの引越しコマンド（ドライブが終わってから実行） gam create datatransfer howdy39@hey.jp datastudio howdy39@st.inc privacy_level shared,private;
移管の完了確認は、Transferを実行したユーザーに飛んでくる完了メールを使いました。GASを使ってメールの本文のメッセージから正規表現で引き抜く感じですね。
const plainBody = message.getPlainBody().replace(/ \r\n/g, ''); const [, old, new] = plainBody.match(/データ移管リクエスト.+?さん（(.+)）から.+?さん（(.+)）へのデータ移管/); // old にhey.jpアドレス、new にst.incアドレスがはいるのでスプシに出して確認
移管時間はファイル数によって大きくかわるため、数分で終わるアカウントもいれば5時間以上になったアカウントもありました。ある程度時間がかかるのは覚悟したほうが良さそうです。
また、あくまでマイドライブの移管はファイルオーナーを変更しているだけなことに注意が必要です。たとえば編集者としてhoge@hey.jpユーザーがついていたらhoge@st.incユーザーに付けなおす必要があります。 これは共有ドライブでのファイル単位での共有や、外部ドメインユーザーからのファイル共有でも同様になります。
Tips Looker Studio（データポータル）はデータセットの再接続が必要
Looker Studioはファイルのオーナーを変えたあとにデータの再接続が必要です。
※ スプレッドシートのIMPORTRANGE関数なんかも同様に再接続が必要になります
Tips Google Apps Script はトリガーやデプロイの再設定が必要
Google Apps Script はトリガーやWebアプリケーションのデプロイなどで再設定が必要です。
トリガーの引越しは https://script.google.com/home/triggers を新旧アカウントのそれぞれのブラウザを見比べながらやれば比較的ラクだと思います。
Webアプリケーションのデプロイをしている場合は、頑張って探してもらうしかなさそうです。日常的に使っているなら「動かなくなった！」ですぐに気づけると思います。
Tips GASからメールアドレス使ってSlackにメンション通知している場合、GASの修正が必要になる
GASからSlackでメンションを送りたい場合、こんなコードを書くと便利だよ。というコードを社内に布教していました。
GASからSlackIDではなくメールアドレスを使ってメンションを送る方法
今回、Slack上のメールアドレスもst.incに変更するため、hey.jpアカウントでフォーム送信した場合にメンションが動かなくなります。 そのため9月の頭には下記のようにGASのコードを書き換えておいてください。とアナウンスをして事前準備をしていました。
※ Slackのアドレス変更前に@st.incで送るとエラーになるので、それを利用してエラーをキャッチ→hey.jpで再送するコードです
function onFormSubmit(e) {
// ...
// emitSlackWorkflow(params); // 元のコード
emitSlackWorkflowWrapper(params);
}
function emitSlackWorkflowWrapper(params) {
try {
params.email = params.email.replace('@hey.jp', '@st.inc'); // @st.incアドレスで送信
emitSlackWorkflow(params);
} catch (e) {
if (e.message.includes('invalid_user_email')) {
params.email = params.email.replace('@st.inc', '@hey.jp'); // @hey.jpアドレスで送信
emitSlackWorkflow(params);
} else {
throw e;
}
}
}
5. Gmailの引越し
Gmailの引越しは下記の2つを必須要件としました。
- 今後も既存のhey.jpメールアドレス宛のメールを受信できること
- 既存の受信メールを引っ越しできること
hey.jpアドレス宛のメール受信はエイリアス付与ではなく、シンプルにメールのアドレスマップ転送を使うことにしました。 エイリアスにするとファイル共有時などで2つアドレスが出てきてしまったりするので使わないに越したことはないかなと。*5
問題は既存メールの引越しです。
メールの引越しはいくつか方法がありますが、今回はユーザー自身で引越してもらうことにしました。 これは下記のような理由のためです。
ユーザー作業としては下記のようになります。
- hey.jpアカウントでmboxファイルでエクスポート（バックアップ取りたいだけの人はここで終わり）
- Thunderbirdを使ってmboxファイルをインポート（メール検索したいだけの人はここで終わり）
- st.incのメールボックスに反映したい人はTunderbirdで同期まで実行（メールの数によっては同期作業に数日とかかかってしまうのでやりたい人だけにしました）
この手順は結構ややこしいので下記のような全体画像と手順書を作って共有しました。
6. hey.jpアカウント停止・削除
アカウント停止はGAMコマンドで行いました。
# アカウント停止コマンド gam update user howdy39@hey.jp suspended on;
アカウント削除はGAMコマンドではなく管理コンソールから手動で削除しました。
これはブランドアカウントを仮に持っていた場合に引き継がないとまずいと判断しためです。*7
振り返り
業務に大きな影響を与えるような問題は起きず年内でアカウント削除まで完了できました。
Google Wokrspace以外の引越し作業も進めつつもわずか3ヶ月という短期間で新ドメインのアカウントに完全移行できました、振り返ってみると爆速だったんじゃないかなと思います。
これは STORES のみんなが積極的に手伝ってくれたのが本当に大きいです。いい会社です。（宣伝）
あとは図を交えたわかりやすい手順書を書きまくったことがうまくいった要因かと思います。*8
本来は公式ドキュメントを参照させるのが良いのかもしれませんが、公式ドキュメントがわかりにくいと問い合わせだらけになって双方に対応コストがかかります。丁寧すぎたかな？ぐらいで丁度いい塩梅だったんじゃないかなと。
今回、社名変更対応をドメインエイリアス追加ではなくアカウント引越しの方法を選んだ関係で、手順書準備も実際に引越し作業をやってもらうのもかなり大掛かりなものになってしまいました。しかし結果的にドメインエイリアスで進めなくて本当に良かったと思います。旧ドメインであるhey.jpの存在を消して仕事できるのが本当に快適なので。
（追伸） この部分もっと知りたい、みたいなのがありましたらツイートやはてブでコメントをお願いします。 需要がありそうであれば追加で記事を書きますのでコメントお待ちしています。
質問ぽいコメントへのレス
別途記事を書くほどじゃなかったので同様の感想を持った方向けに記事内で記載しておきます。
はてブ
Googleアカウントを認証に使ってる外部サービスはどうやって移行したの？
ほとんどの外部サービスはユーザーにメールアドレス変更をして貰う形を取りました。管理者側で一括でメールアドレス変更ができるものもあったと思います。 メールアドレス変更機能を提供していない外部サービスはベンダーにDBパッチしてもらったものもあります。
何年か前にやったなー。 ITエンジニアは使えるから別にエイリアスでもって感じだったが、バックオフィス側が入社する社員にいちいち前社名とかメールのデフォルト設定とかを説明するコストに耐えられず主導した。
その未来が見えたので大変ですが本手順にしたという感じです。
Looker Studioやスプレッドシート、Gmailあたりでスタッフ個々人の作業が必要にところがあるので全社的なリテラシーが必要になりそう
それは本当にそうだと思います。ITベンチャーだからこそすんなりいけた気がします。
アカウント数が少なかったら & 調査時間がもっとあったらその形式もとれたかと思います！ なにかしら問題が起こったときに結局本記事でやったような引越し作業が発生するので、安全パイな引越し方法にしました。
*1:https://www.st.inc/news/2022-08-31-hey-to-stores
*2:もちろんこれはその時のGWSの使い方によっても変わるので、ドメインエイリアスが最適なケースもあると思います
*3:退職時に消えないようにシステム用のカウントで作るため
*4:asadminを入れるとDomain Wide Delegationになります
*5:最初はエイリアスにしようとしてましたが途中でやめました
*6:STORES 株式会社は4社がくっついて出来てる会社なので旧個社のGWSが別に残っている
*8:本記事出でてきた図は新たに作ったのではなく手順を書く中で生まれてきたものです
