こんにちは！開発本部・バックエンドエンジニアのSongです。

2月の下旬に個人ユーザー・フォロワー統合プロジェクトをリリースできました。

このプロジェクトでは以下の機能を提供しています

• ユーザーが自身の操作でFacebookフォロワーアカウントを個人ユーザーアカウントへマイグレーションできる
• ユーザーがFacebook認証で個人ユーザーとして新規登録・ログインできる
• Facebookフォロワーユーザーは新規登録できなくなった。ただし、ログインはできる

最も重要なのはFacebookフォロワーが自身の操作でアカウントを個人ユーザーへマイグレーションできるという機能なので、今回その機能の実装についてお話します。

背景

現在、PR TIMESでは４つのユーザータイプが存在しています

• 企業ユーザー
• メディアユーザー
• 個人ユーザー
• Facebookフォロワー（以下フォロワーと呼ぶ）

各タイプのユーザーには、それぞれの特別な仕様や機能があります。しかし、フォロワーの機能はほぼ個人ユーザーと同じなので、分かれているメリットや明確な理由がありません。具体的には

• フォロワーが提供している機能は企業をフォローすること
• フォローする機能は個人ユーザーにも存在しているため、フォロワーのアカウント情報テーブルとフォローのテーブルをマイグレーションできれば良い

さらに、個人ユーザーアカウントの利便性を向上するために、SNS認証（まずはFacebook）で個人ユーザーとして新規登録・ログイン機能を追加したいのですが、Facebookでログインする機能はフォロワーのログインで利用しているため、個人ユーザーとフォロワーを統合し、個人ユーザーをFacebookでもログインできるようにすることになりました。

最初の段階で、個人ユーザーとフォロワーが統合されるということを事前にフォロワーに告知して、告知期間を経てから、自動的に個人ユーザーにマイグレーションすることにしました。ただし、事前告知期間中にユーザーが自身の操作でマイグレーションすることも可能です。

今回はユーザーが自身の操作でマイグレーションできる機能を中心に説明します。

ユーザーデータを調査した結果

マイグレーションができるように、とりあえずフォロワーと個人ユーザーのデータを調査しました。調査結果は以下のようになりました。

• フォロワーと個人ユーザーのデータが主に２つのテーブルに保存されている。これらのテーブルもユーザータイプによって別の構造や制約を持っている
  • アカウント情報
  • フォロー中の企業情報（以下フォロー情報と呼ぶ）

• 個人ユーザーのアカウント情報テーブルにはメールアドレスにUNIQUE、NOT NULL制約があり、氏名にNOT NULL制約がある（以下個人ユーザーテーブルの制約と呼ぶ）
• １つのメールアドレスは企業ユーザー、メディアユーザー、個人ユーザーという３つのユーザータイプにいずれか１つしか登録できない（以下PR TIMESのユーザー制約と呼ぶ）。つまり、企業ユーザー、メディアユーザー、個人ユーザーが同じメールアドレスで存在できない
• フォロワーのアカウント情報テーブルにはメールアドレスや氏名にNOT NULL制約がない。その上、メールアドレスが他のユーザータイプと重複可能であり、メールアドレスや氏名がないフォロワーも存在している

どんな問題が発生したのか？

調査結果に沿って、以下の問題が発生しました。

テーブルの構造や制約が違う問題

フォロワーと個人ユーザーテーブルの構築や制約が違うため、データをそのままマイグレーションすることができません。

情報が重複する・欠ける問題

メールアドレス、氏名が欠けているまたはメールアドレスが企業ユーザー、メディアユーザーと重複されるフォロワーアカウントが個人ユーザーへマイグレーションできません。個人ユーザーテーブルの制約とPR TIMESユーザーの制約に違反するためです。

問題をどのように解決したのか？

では上記の２つの問題をどのように解決したのか？

テーブルの構造や制約が違う問題

フォロワーアカウントを個人ユーザーアカウントへマイグレーションできるように、個人ユーザーのアカウント情報テーブルとフォロー情報テーブルに新しいカラムや制約の追加で解決できました。

まず、フォロワーのアカウント情報テーブルにFacebookのユーザーIDを保存しているカラムがありますが、個人ユーザの方はないため、追加する必要があります。

ALTER TABLE table_name ADD COLUMN fb_user_id VARCHAR(128);

次に、個人ユーザーのフォロー情報テーブルにはPRIMARY制約がありません。しかし、今後マイグレーションを実装するにあたり、PRIMARY制約がないと情報の重複で実装に困る可能性があります。そのため、追加する必要があります。

このテーブルには主にユーザーIDと企業IDを保存するため、２つのカラムを合わせてPRIMARY制約を追加しました。

ALTER TABLE table_name ADD CONSTRAINT table_name_pkey PRIMARY KEY (user_id, company_id);

さらに、フォロー情報テーブルのレコード数が増えてもパフォーマンスの問題が出ないように、これまでなかったcompany_idのINDEXも追加しました。

CREATE INDEX table_name_company_id_idx ON table_name (company_id);

情報が重複する・欠ける問題

調査結果によって、フォロワーを４つのパターンに分けました。

パターン①：メールアドレスが個人ユーザーと重複しているフォロワー

フォロワーアカウントのメールアドレスに該当する個人ユーザーアカウントが既に存在するため、ユーザーがそのままアカウントマイグレーションを実行できます。

その上、マイグレーションする際に個人ユーザーの情報が優先されるため、氏名が欠ける問題も解決できます。

パターン②：メールアドレスまたは氏名がないフォロワー

フォロワーアカウントのメールアドレスまたは氏名がないため、個人ユーザーテーブルの制約に違反してしまいます。

アカウントマイグレーションできるように、ユーザーが情報を追加する必要があります。

パターン③：メールアドレスが企業ユーザーまたはメディアユーザーと重複しているフォロワー

メールアドレスが企業ユーザーまたはメディアユーザーと重複しているため、PR TIMESユーザーの制約に違反してしまいます。

アカウントマイグレーションできるように、ユーザーが別のメールを追加する必要があります。もちろん、もし氏名がないなら追加する必要があります。

パターン④：メールアドレスや氏名があり、メールアドレスが他のユーザータイプと重複していないフォロワー

情報があり、個人ユーザーテーブルの制約とPR TIMESのユーザー制約に違反していないため、ユーザーがそのままアカウントマイグレーションを実行できます。

アカウントマイグレーションの処理

ではマイグレーションを実行する時にどのように処理すれば良いでしょうか？

今回はフォロワーのアカウント情報テーブルとフォロー情報テーブルをマイグレーションする必要があります。上記の4つのパターンがあるので、アカウント移行とアカウント統合という２つの処理に分けました。

アカウント移行

フォロワーアカウントの情報を個人ユーザーアカウントに移行するという処理です。

技術的には個人ユーザーのテーブルに新しいデータをINSERTする処理です。該当の個人ユーザーが存在していないためです。もちろん情報が欠ける場合、移行できるようにユーザーが情報を追加する必要があります。

アカウント移行の対象はユーザーパターン②、③、④です。

アカウント統合

フォロワーアカウントの情報を個人ユーザーアカウントに統合するという処理です。

技術的には、個人ユーザーのテーブルをフォロワーの情報でUPDATEすることです。同じメールアドレスでフォロワーと個人ユーザーに登録したため、統合先が既に存在しています。ですから、INSERTの代わりに、UPDATEで処理します。

ただし、フォロー情報はUPDATEではなくUPSERTで処理します。なぜならフォロワーのフォロー情報を統合する際に、個人ユーザーのフォロー情報テーブルに該当するレコードが存在すればUPDATEで処理するが、存在しなければINSERTで新しいレコードを追加する必要があるからです。

アカウント統合の対象はユーザーパターン①のみです。

フォロワーの管理画面上でアカウント移行・統合を行う

今回のアカウント移行・統合の処理はユーザーの管理画面で行われます。

では、フォロワーがログインした後、そのアカウント移行と統合とどちらが実行できるか？

情報が欠けることをどうやって判定できるか？を考える必要があります。

ログイン中のフォロワーのメールアドレスと氏名を判定することに沿って、以下のように分岐処理で実装しました。

分岐処理が多いですが、以下のようにまとめられます

• ログイン中のユーザーがアカウント移行・統合の条件を満たすとしたら、管理画面上に該当のモーダルやお知らせが表示される
• ユーザーがそのモーダルやお知らせにあるリンクをクリックすると、アカウント移行・統合を確認できる。もちろん情報が欠けたら確認前に入力する必要がある
• ユーザーが確認した後、アカウント移行・統合が実行され、終了する

個人ユーザーの管理画面上でアカウント統合を行う

個人ユーザーとフォロワー両方登録している方も個人ユーザーにログインしてからアカウント統合を実行できます。

個人ユーザーのメールアドレスに該当するフォロワーが存在するかという条件を判定するだけなので、処理がとても簡単です。

最後に

今回のプロジェクトの実装で、フォロワーユーザーと個人ユーザーが自身の操作でアカウントをマイグレーションすることができました。

テーブルの調整やアカウント移行・統合の分岐処理のおかげで、告知期間を経てから、自動的にフォロワーアカウントを個人ユーザーにマイグレーションすることが安易に実装できると思います。