every Tech Blog

株式会社エブリーのTech Blogです。

トップ > アドベントカレンダー2024 > 小売アプリのシステム移管事例紹介

小売アプリのシステム移管事例紹介

アドベントカレンダー2024

はじめに

この記事は every Tech Blog Advent Calendar 2024 11 日目の記事です。

こんにちは。DELISH KITCHEN 開発部 RHRA グループ所属の池です。

2024年6月、エブリーは5つの小売アプリの運営について事業譲渡を受け、『 retail HUB 』へ移管しました。 移管してから半年間、引き継ぎ元の企業様からサポートをいただきながら、システムの移管と運営を行ってきました。

システムの移管は、システムを構成する各種サービス・ツールの公式の移管手順に従って基本的には行いますが、中には記述が不明瞭な場合もあり、試行錯誤が必要でした。

本記事では、事業譲渡を受けた小売アプリのシステム移管作業をまとめ、移管作業における注意点もあわせて紹介します。 同じようにシステムを引き継ぐ機会がある方々の参考になれば幸いです。

また、引き継ぎ作業の前段階で行ったシステムデューデリジェンスについても先日別の記事にて紹介しておりますので、もし興味があればご覧ください。

tech.every.tv

移管対象のシステムについて

事業譲渡を受けた小売アプリのシステムは、iOS/Androidのネイティブアプリと、入稿管理画面の Web アプリケーションサーバー、アプリ向け API サーバー、それらを構成するシステム（AWS環境、ロードバランサー、データベース、バッチサーバーなど）です。

これらは以下を利用して構築され、それぞれが移管対象となります。

  • システム
    • GitHub リポジトリ
    • AWS アカウント
    • Firebase プロジェクト
    • Google Analytic プロパティ
    • ドメイン
    • App Store Connect アプリ
    • Google Play Console アプリ
  • 外部サービスの契約
    • PUSH通知サービス
    • システム監視サービス
    • WAFサービス
    • SMSサービス
  • その他
    • ドキュメント
    • Backlog

また、移管にあたっての前提ですが、移管元の企業様はエブリーへの事業継承後も引き続き一部の開発を担う契約となっているため、システム移管後も開発が継続できる状態を保つことが前提となります。

そのため、各種移管において、ユーザーアカウントの権限設定やユーザー自体の移管も含めて検討・作業を行う必要があります。以下の内容はその前提を踏まえた作業内容および注意点としてお伝えします。

それでは、それぞれのシステムに関する移管作業まとめていきます。

GitHub リポジトリ の移管

GitHib リポジトリの移管は公式手順にて確認できますが、公式手順の他にもいくつかの考慮事項がありました。

  • エブリーのGitHubに招待する移管元開発者の権限設定
    • 移管対象のリポジトリのみを閲覧操作できるような権限設定が必要
  • 移管に伴う影響の確認

上記を踏まえて、GitHubリポジトリの移管は次の手順で行いました。

  1. 移管元企業様にGitHubリポジトリと連携している外部サービスを洗い出していただく
  2. 事前に移管元の開発者を移管先のGitHub組織に招待し、移管対象のリポジトリだけを閲覧できるように設定したTeamに所属させておく
  3. 移管元GitHubにてリポジトリの移管を行う
    • リポジトリの Settings > Transfer から移管先のGitHub組織名を入力して移管を行う
  4. 移管先GitHubにてリポジトリが移管されたことを確認する
  5. 移管されたリポジトリを対象のTeamに所属させる
  6. 1.で洗い出した外部サービスにおいて、GitHubと再接続させる

注意点

注意点は2つあります。

  1. 移管対象のリポジトリ自体に直接属しているGitHubアカウントが合わせて移管される
  2. リポジトリを参照しているサービスとの連携が切れる

1点目について、GitHub組織のシートに空きがある場合、移管元のリポジトリ自体に直接属しているGitHubアカウントも合わせて移管されてしまいます。

私たちもそのことを正しく把握できていなかったため、移管後に意図しない引き継ぎ元企業様のGitHubアカウントがエブリーのGitHub組織に属している状態になっており、費用が余分に発生していました。幸いにも権限設定を正しく管理していたため、他のリポジトリを閲覧操作できることはなかったのですが、組織自体の権限設定次第では見せてはいけないリポジトリが閲覧操作できてしまう可能性があるので、注意が必要です。

2点目について、移管を行うと、GitHubリポジトリを参照している外部サービスにおいて参照できない状態になるため、再接続するまで使えなくなります。

私たちのシステムでは AWS CodePipeline で GitHub リポジトリと接続しており、移管後に再接続が必要でした。もし他にも接続しているサービスがあれば再接続が必要になるので、移管前の準備として接続しているサービスやツールを洗い出して影響範囲を確認しておく必要があります。

AWS アカウント の移管

前提として、移管対象のAWSアカウントは 移管元企業様の AWS Organizations に各AWSアカウントが所属おり、それらをエブリーの AWS Organizations に属する形へと移管を行います。

AWS Organizations 間におけるAWSアカウントの移管はこちらの手順にて確認できます。

公式手順以外には以下のようなことが考慮事項でした。

  • AWSアカウントの所有権の譲渡
  • 移管後にAWSアカウントを利用する移管元開発者の権限設定

まず、移管の前段でAWSアカウントの所有権の譲渡を行いました。所有権の譲渡が完了してしまえば、後の作業は全て弊社内の作業にて完結するようになるので、先に移しておくと作業しやすくなります。

所有権の譲渡については、今までは譲渡同意書をAWSに提出する必要があったようですが、今年から譲渡同意書は不要になりました。 譲渡要件はこちらで確認ができます。今回の作業では以下のアカウント情報を更新することで所有権を譲渡できました。

  • アカウント設定
  • 連絡先情報
  • 支払いの詳細設定

所有権をエブリーに移した上で、権限設定の考慮事項を踏まえて AWS Organizations 間におけるAWSアカウント移管の作業を以下の手順で行いました。

  1. 移管元の開発者を移管対象のAWSアカウントごとにIAMユーザーとして作成（管理上の都合で各AWSアカウントごとにそれぞれIAMユーザーとして作成）
    • 最小限の権限となるようにポリシー設定を行う
  2. 移管先の AWS Organizations にてAWSアカウントの招待を行う
    • 招待の画面にて、移管対象のAWSアカウントIDを入力することで招待を行える
  3. 招待したAWSアカウントに設定されているメールアドレスに招待メールが届き、招待を承認する
  4. 移管したAWSアカウントにSSOログインできるように設定を行う

以上でAWSアカウントの移管は完了です。

注意点

AWSアカウントの移管にあたっては、大きく注意すべきポイントはありませんでしたが、強いてあるとすれば、移管したタイミングで請求書が分かれるということです。 移管した月は請求書が2つに分かれるので、そのことを把握していないと片方の請求書を見落としてしまう可能性があるので、ご注意ください。

また、今回は各AWSアカウントごとにIAMユーザーを作成する形をとりましたが、移管元企業様が引き続き開発を行える状態をどのように維持するかについて、事前に十分に協議して擦り合わせておくことが大切です。

Firebase プロジェクト の移管

Firebase プロジェクトはGoogle Cloud プロジェクトと連携しているので、該当のGoogle Cloud プロジェクトの移管を行うことでFirebase プロジェクトを移管できます。

移管の前提として、今回移管したプロジェクトは組織に属していない「組織なし」のプロジェクトを、エブリー組織に属するよう形への移管となります。

組織なしのプロジェクトの移管はこちらの手順にて確認できます。 GitHubやAWSの移管と近しいですが、手順書以外の考慮事項は以下でした。

  • プロジェクトに設定されているIAMの整理
  • 作業者アカウントの権限準備

上記を踏まえて次の手順を移管作業を行いました。

  1. プロジェクトに設定されているIAMの整理
    • プロジェクトに設定されているIAMは移管時に移管先の組織に属するように設定されてしまうため、事前に全てのIAMを確認して整理します。
  2. 作業者のアカウント権限を準備
    • 移行作業を実施する Google Cloud アカウントは以下のような状態にする必要があります。
      • 移管対象プロジェクトのオーナー
      • 移管先の組織の管理者
  3. 移管の実施
    • Google Cloud コンソールからコマンド実行するためのターミナルを開き、移管コマンドを実行します。
// 移行コマンド
gcloud beta projects move <移管対象のPROJECT_ID> --organization <移管先のORGANIZATION_ID>

// プロジェクトが属しているORGANIZATION_IDを取得するコマンド。移管確認用。
gcloud projects describe <移管対象のPROJECT_ID> --format=json | jq -r ".parent"

注意点

注意点はGitHubリポジトリの移管と同様で、アカウントも一緒に移管されることです。想定しないアカウントが移管先の組織に属する形になることを防ぐため、移管前にIAMの整理を行うことが大切です。

Google Analytics プロパティ の移管

Google Analytics プロパティの移行手順は公式の[GA4] プロパティを移行する手順にて行いました。

手順の流れは Firebase プロジェクトの移管と同様で、以下のような流れでした。

  1. プロパティに属しているアカウントの整理
  2. 作業者のアカウント権限を準備
    • 移行作業を実施する Googleアカウントを以下のように権限設定する必要があります
      • 移管対象プロパティの管理者
      • 移行先のGAアカウントに対する管理者もしくは編集者
  3. 移管の実施
    • Google Analytics コンソール画面から公式の手順に沿って移管を実行することができます

注意点

まず、移管にあたって一つ理解が必要なのは、Google Analytics は GAアカウントに複数のGAプロパティが属する構造となっており、GAアカウントとGAプロパティはそれぞれで権限設定が行えるという点です。 GAアカウントとGAプロパティの言葉の違いを理解した上で、適切にそれぞれのユーザー権限設定を行うこと大事です。

また、注意点ではないですが、移管作業では以下の点について問題ないかどうかをドキュメントから正確に読み解くことが難しかったので、記録として残しておきます。

  • 過去のデータが引き継がれるか
  • 移管の実施はデータ収集に影響がないか

これらは問題ありませんでした。過去のデータは引き継がれ、データ収集も影響がないことを確認しました。

ドメインの移管

移管対象のドメインはDoレジで管理されており、エブリーで主に利用しているお名前.comへと移管しました。移管手順は他者からお名前.comへのドメイン移管に沿って比較的楽に実施することができます。

作業自体に関しては注意点は特にありませんが、作業に費用が発生するため、注意が必要です。

App Store Connect アプリ の移管

App Store Connect アプリについては移管はこれから実施を予定しており、現在計画立てを行っている段階です。 計画立ての途中ではありますが、現時点で以下のような影響がわかっています。

  • 移管実施に伴うユーザー影響
    • キーチェーンにデータ保存している場合に参照できなくなる
    • Sign in with Apple でログインできなくなる

譲渡における影響はアプリの譲渡の概要にて確認できます。

Google Play Console アプリ の移管

Google Play Console アプリについてもこれから移管する予定となっているので、本記事では割愛いたします。 移管作業が完了したらまた具体的な話をお伝えできればと思います。

まとめ

本記事では、システム移管の作業内容と、作業から得られた注意点を紹介しました。

移管するシステムの状態によって具体の作業内容は少しずつ異なってくると思うので、その点を踏まえてご参考にしていただければ幸いです。

最後までお読みいただき、ありがとうございました。