目次
はじめに
初めまして。 2023年4月から新卒エンジニアとして子育てメディア「トモニテ」の開発チームにジョインして、バックエンドやフロントエンドの設計・開発に携わっているktanonymousです。
以前投稿したGo サーバーのメモリリークを調査・改善した話の記事や
snapshotをResult Buildersを使って宣言的に書くの記事の冒頭でも実はお伝えしていたのですが、
2023年8月1日、MAMADAYSはトモニテとして生まれ変わりました。
多様性が広く認められてきている現代において、より多くの人に求められる存在になるべく、新しいスタートをきることにしました。
子育てを通じて、人や社会が「ともに手（トモニテ）」をとる世界を目指して挑戦していきます。
機能観点で言えば、アプリのメイン機能である「育児記録」「妊娠週数管理」「食材リスト」を軸として、 家族やパートナー、家族以外の人や社会との接点を作るためのシェア機能やコミュニティ機能などの拡充をめざしていきます。
リブランディングを実施するにあたり、開発チームでも管理しているソースコードに対して様々な変更を施す必要がありました。
今回必要となった作業を大きく分けると以下のようになりました。
- インフラ周りの対応
- Google Search Consoleなど、SEO対策
- ドメインの変更に伴う差し替え
- サービス名変更に伴う差し替え
本記事では、筆者自身が主に担当していたという意味合いで、インフラ/SEO周りの対応を除いた2点について主にお話しできればと思います。
リブランディングの懸念点
本題に入る前に、リブランディングの実施に伴う懸念点について簡単に触れていきたいと思います。
今回のリブランディングの実施にあたり、サービスの名称が変更されることになります。
サービス名称の変更に伴い、以下のような懸念点がありました。
- 既存ユーザー視点で、突然名前が変わることでMAMADAYSが無くなった（「トモニテ」という知らないサービスが出てきた）と思われてしまう恐れがある
- 検索エンジンによるインデックスが初期化されることで、検索順位が低下してユーザーの流入が大幅に減少する
事前に早い段階でのお知らせが必要ですが、1. についてはユーザーへのお知らせで対応できる範囲かと思います。我々のビジョンを伝えるためのページ(トモニテについて)も併せて公開しています。
しかし、2. については避けようがありません。 Google検索の公式ページにもドメイン変更に伴う影響について下記のような記述があります1。
移転中、サイトのランキングが一時的に変動することを想定する。 サイトの大幅な変更があった場合は、Google がサイトを再クロールしてインデックスに登録し直す間にランキングが変動することがあります。
こういった背景もあり、リブランディング作業を実施するにあたり、一定の閲覧数減少は覚悟する必要がありました。
ドメイン/サービス名変更に伴う差し替えについて
ドメイン変更に伴う差し替え対応では、主にserver側の実装の中で旧ドメインを利用してパス指定している箇所について、リブランディング後のドメインを指定したURLに差し替えました。
mamadays.tv -> tomonite.com
また、サービス名称変更に伴う差し替え対応では、ユーザーの目に触れる部分やwebページのメタデータに含まれるサービス名称をリブランディング後のサービス名称に差し替えました。
MAMADAYS/mamadays/ママデイズ -> トモニテ
どちらもソースコード内にある文字列を変更後の名称に置換するだけの作業ということには変わりありませんが、これが思ったよりも曲者でした。
今回の作業では差し替えをせずに後で対応する箇所などが一部にあったことをふまえて、以下のようなことを考えながら作業を進めていました。
ユーザーの目に見える形で出す必要性があるためコード上で定数として管理するには不都合なものもあり、ドメインやサービス名称をベタ書きしてしまっている箇所が相当数あるのが実情です。 そのため、ドメイン・サービス名称を差し替える際、しらみ潰しに探し回って1つ1つ差し替えていくというのは非常に面倒な作業になりますし、予期せぬミスの温床にもなってしまいます。
そこで、極力ミスを減らしたいという思いで「mamadays.tv/MAMADAYS/mamadays/ママデイズ」（1回の作業の変更量を抑えるために英大・小文字を敢えて区別しています）のキーワードを それぞれソース内で検索し、「tomonite.com/トモニテ」に一括置換する方法を採用しました。 これにより、差し替え忘れや差し替えに伴うミスを防ぐことができました。
一方で、この方法では、異なる文脈の中で該当するキーワードを利用しているような、差し替え対象外のものも置換されてしまいます。
こちらに関しては、git add -p (addコマンドのインタラクティブモードの一種、詳細はこちら)で
変更差分の観点から差し替え対象に該当するかどうかを確認して対象を選別する方法を採用しました。
これにより、差し替え対象外のものを1つ1つ探し回って置換を取り消していくのではなく、自動で表示される差分だけを見ながら差し替え対象の仕分けを効率よく行うことができたと思います。
以上の作業を通して、1. に関する対策を取りつつも作業量を抑えることができました。
また、2. については、差し替え作業を一定の基準で分割することで個々のPRが大きくなりすぎないように気をつけていました。
今回の作業では、サーバー側の対応とフロント側の対応で分割、さらに、ドメイン変更対応と名称変更対応で分割するような形としました
（実際にはもう少し細かくしている部分もあります）。
リリース作業について
先述のような方針で進めることを想定していたため、実際のリリース作業時には複数のPRを立て続けに開発/本番環境へマージする必要がありました （1つのPRにまとめてからマージしてしまうとPRが肥大化してサービスへの影響度が大きくなり過ぎてしまうと考え、選択肢から除外していました）。
何かしら問題が発生した時の手戻りのコストを抑えるための対応ではありますが、必然的に全てをリリースするまでの手順は増えてしまいます。 そのため、各PRの重要度や依存関係、リリースによるサービスへの影響度の大きさを考慮しながらリリース順を決定する必要がありました。
そんなこんなで、最終的なリリース作業の手順は以下のようになりました。
- infra周りの対応（本記事の対象外）
- フロント側、サービス名称差し替え
- サーバー側、URL差し替え
- サイトマップの構築・配置・送信(ここではecscheduleを利用)
- フロント側、URL差し替え
- サーバー側、サービス名称差し替え
実際のリリース作業時には、関係者への作業進捗の報告やこまめな動作確認を挟みつつ作業を進め、 最終的には大きな問題を起こすことなくリブランディング作業を終えることができました。
余談ですが、トモニテではドメイン移行直後のwebのユーザー流入が（予想通り）落ち込んだものの、
徐々にトラフィックが回復して約2ヶ月で移行前の数値を超えていました。
また、はじめにも軽く触れましたが、SNS等でユーザーから好意的な声が上がっているなど、
プロジェクト成功と言える結果になったと思います。
まとめ
本記事では、MAMADAYSがトモニテに生まれ変わる裏側のお話をサーバー・フロントエンドの視点からお伝えしてきました。 ここでお伝えした主な作業自体はソースコード内の文字列を置換するだけという単純なものでしたが、「たかが置換、されど置換」という感じで 思いのほか癖のある作業だったなぁと感じています。
サービスのドメイン・名称を変更するというのはなかなか出会う機会のない作業だと思いますが、偶然にも入社して間もないタイミングで このような大きな施策に携わることができたのはとても良い経験になりました。
この記事を読んでいる方が同じような状況になることがあるかどうかはわかりませんが、プロダクトの根幹を変更する作業の大変さの片鱗は感じとっていただけたのではないかと思います。
また、もし同じような状況になった際には、本記事が少しでも参考になれば幸いです。
最後になりますが、子育てを通じて、人や社会がともに手をとる世界を目指して新しいスタートを切ったトモニテにこれからもご注目ください。
最後までお読みいただきありがとうございました。
