「学生時代に打ち込んだものは？」
「キーボードです。」
こんにちは。 株式会社テラーノベル CTO の typer です。
2022 年 6 月 1 日をもって、ピックアップ株式会社は株式会社テラーノベルに社名変更し、それにともなってサービス名も「テラー」から「テラーノベル（Teller Novel）」に変更しました。
アイコンも変わりました
今回はテラーノベルとしての初めての技術ブログということで、会社名とサービス名を変更する際に行ったことの中から、主にバックオフィス系の技術対応を紹介します。
- 登記、契約書テンプレート、名刺、実印、…、の作成・変更
- サービスアイコンとロゴの作成
- コーポレートサイトの記載変更
- サービスサイトの利用規約、プライバシーポリシー、特商法の記載変更
- AppStore, PlayStore のアプリ名、説明、サブスクリプションの商品名の変更
- Twitter 等ソーシャルアカウントの表示変更
- サービスで使用しているドメインの変更
- FAQ、問い合わせ用メールアドレス、メール送信元ドメインの変更
- Google Workspace で使用しているドメインの変更
- Google アカウント連携済みの外部サービスの対応
- Slack, Notion, Github 等のワークスペース名・組織名の変更
新ドメイン取得
会社名・サービス名の変更前までは下記のように picappinc.jp teller.jp ドメインを使用していました。
- コーポレートサイト https://picappinc.jp
- サービスサイト https://teller.jp
- 問い合わせ先メールアドレス
~~~@teller.jp - Google Workspace
~~~@picappinc.jp
今回は下記のように変更しました。
- コーポレートサイト https://teller.jp/corp ※2022/7 時点では未対応
- サービスサイト https://teller.jp
- 問い合わせ先メールアドレス
~~~@tellernovel.com - Google Workspace
~~~@tellernovel.com
サービスサイトの URL も tellernovel.com に統一することも検討しましたが、SEO の観点から引き続き teller.jp を使用することになり、同様の理由でコーポレートサイトもサービスサイト配下に置くことにしました。問い合わせ先メールアドレスや、認証用のメール送信元アドレスは tellernovel.com に統一することになったため、全体としては下記のような対応を行いました。
- Google Domains で
tellernovel.comを取得 - Google Workspace のプライマリドメインを変更
- 問い合わせ先メールアドレスとして
~~~@tellernovel.comGoogle アカウントを 1 つ作成し、CS ツールへ転送設定を追加 - Firebase Authentication のメール認証の送信元メールアドレスを変更
- SendGrid の送信元ドメインを追加
Google Workspace のプライマリドメイン変更
今回プライマリドメインを変更するにあたって、まずはペパボさんの記事を参考にさせていただきました。Google Workspace 等の社内アカウント管理に関する事例はあまりネット上に公開されていないので大変助かりますね。感謝！
上記の記事でも説明されている通り、Google 認証時に外部に連携されるメールアドレスはメインのメールアドレスになり、エイリアスアドレスを使うことはできないといった理由から、メインのメールアドレスの変更が必要です。そして、メインのメールアドレスに使用できるドメインは「プライマリドメイン」または「セカンダリドメイン」に登録されているドメインだけに制限されます。
Google Workspace にドメインを追加する際に、「セカンダリドメイン」「ドメインエイリアス」のいずれかの選択を求められます
ペパボさんの場合は、pepabo.com を「ドメインエイリアス」としてすでに登録済みだったため、一度解除してからあらためて「セカンダリドメイン」として登録し直す必要がありました。
そして、「セカンダリドメイン」として登録されたドメインのうちの一つを「プライマリドメイン」に指定することができます。
Google が「プライマリドメインの変更は必ずしも必要であるわけではなく、そのプロセスも複雑です。ニーズの内容によっては、別のドメインをドメインエイリアスか追加ドメインとして設定するだけで十分な場合があります。」とわざわざ忠告するように、多くのユースケースでは「セカンダリドメイン」としてドメインを追加して、「プライマリドメイン」は据え置きでユーザのメールアドレスを変更するだけで良さそうです。
弊社の場合も、「セカンダリドメイン」として tellernovel.com を追加し、ユーザのメインメールアドレスを変更するだけでおそらく問題はありませんでした。
では、今回なぜプライマリドメインまで変更したのか。
まず、今後使用しないであろうドメインが「プライマリドメイン」として残り続けるのは負の遺産なので早いタイミングで消しておきたかった、そして、ペパボさんの事例からも Google Workspace の変更による影響を事前にすべて把握することは難しいため、変更できるものは小規模な組織のうちに変更した方がトラブル対応が簡単なはず、という判断で変更しました。
とはいうものの、実際に「プライマリドメイン」を変更してもそこまで目に見える変化はなく、「ユーザを追加したときのデフォルトのドメイン」が切り替わった程度でした。メールアドレスも変わっていないので従来どおりのメールアドレスで送受信できます。むしろ作業の手間と影響が大きいのはその後の既存ユーザとグループのメールアドレスの変更でした。
弊社の場合はたかだか 20〜30 アカウントだったので手作業でメールアドレスの変更を行いましたが、100 を超えるような場合はペパボさんのようにスクリプトで対応した方が良さそうです。
Google アカウント連携済みの外部サービスの対応
これは技術的な対応というよりも社内技術サポート的な意味合いが強いです。
弊社で使用している Slack, Notion, Figma, Google Docs, GCP IAM といった Google アカウント連携しているサービスが、メールアドレス変更後にそのまま使用できるかどうかは不明でした。事前に検証することも考えましたが、人数が少ないことから個別に対応することも可能と判断してぶっつけ本番で行きました。
Google Docs, GCP IAM に関してはメインのメールアドレスを変更した時点で、該当ユーザのメールアドレスが新しいものに切り替わって認識されていたので、ファイル共有や権限管理で問題が生じることはありませんでした。
外部のサービスだと Notion が一番親切な挙動をしてくれていて、もともと xyz@picappinc.jp というメールアドレスでアカウント連携している状態で、メールアドレス変更後に xyz@tellernovel.com で Notion にログインし直したところ、サービスに登録されている既存のユーザのメールアドレスを変更した上で連携し直してくれました。おそらくメールアドレスではなく ID Token から取得できる一意なユーザ ID を使ってユーザを管理していると思われます。
Slack, Figma に関しては、新しいメールアドレスで Google ログインしたところ、別の新しいユーザとして認識されました。こちらも事前に想定された挙動でしたが、Forgot Password? から古いメールアドレスに対してパスワード再登録リンクを送ってもらう遷移を踏むことで、それぞれのサービス上でメールアドレス変更することでログインできるようになりました。
思いがけず、OAuth2.0 対応サービスがどのようにユーザを一意に管理しているか垣間見える瞬間でした。
社内ネットワーク
弊社オフィスの WiFi は Google Workspace の認証情報と連携しているため、Google Workspace のメールアドレスが変更されると社内ネットワークにつながらなくなります。
Google Workspace をお使いの方でも Secure LDAP という機能についてご存じない方もいるかもしれませんが、その名の通り Google Workspace の認証 DB に対して LDAP でアクセスできる経路を提供してくれるものです。
弊社では、ネットワーク管理担当者（私）が WiFi 認証の個別管理を嫌って Google アカウントの認証情報で WiFi にアクセスできるようにするために Secure LDAP の利用を決めました。
オフィスのネットワーク構成
さて、Google Workspace のプライマリドメイン変更前までは Radius サーバに下記の DN を指定して LDAP サーバに接続していました。
※OSS の Radius サーバである FreeRadius には標準で Secure LDAP に接続するための設定のテンプレートが同梱されています。
# Base dn for your organisation.
base_dn = 'dc=picappinc,dc=jp'
この状態で Google Workspace のプライマリドメインを変更しても（ユーザのメールアドレスはまだ ~~~@picappinc.jp のまま）、引き続き LDAP の認証は通り、WiFi に接続できる状態でした。
次に、一部のメンバーのメールアドレスを @tellernovel.com に変更すると LDAP の認証が通らなくなりましたが、その後、Radius サーバの DN 指定を下記のように変更すると、再び LDAP 認証が通るようになりました。
# Base dn for your organisation.
base_dn = 'dc=tellernovel,dc=com'
正直、ここの挙動についてはどうなるかやってみないとわからないところも多かったのですが、オフィスに来ているメンバーが少なかったこともあり、ぶっつけ本番でトラブルを見つけては潰す対応でいきました。
Slack, Notion, Github 等のワークスペース名・組織名の変更
こちらもプライマリドメインと同様で、別に変えなくてもいいけど変えておきたいよねという類のものです。この 3 つに関しては基本的に古い URL でアクセスしても新しい URL にリダイレクトしてくれるので、そこまでリスクはないはずです。
と言いつつも、Github の Organization Name 変更はこれからの予定です。
WHOIS 情報の変更
細かい対応ですが、会社情報が変わるので、picappinc.jp や teller.jp 等のドメインの WHOIS 情報を変更しました。
おわりに
今回の対応では技術的にはそこまで困難なことはありませんでした。人数が少ないからぶっつけ本番で行けるだろうという見込みで実施したものもありましたが、会社の規模が 10 倍 100 倍となるとおそらく指数関数的にトラブルが増えると思うので今回のようには行かないでしょう。（正直やりたくない……）
Discussion