こんにちは！YOUTRUSTの春日（YOUTRUST / X）です。
今回は、長年のサービス運用上の悩みのタネであったユーザーの所属データにおける「二重管理問題」を解決し、よりシンプルで直感的なユーザー体験を実現したプロジェクトについてお話しします。
背景：なぜデータ構造の見直しが必要だったのか
YOUTRUSTでは、ユーザーの所属・経歴情報を主に3つのテーブルで管理していました：
- 所属テーブル: 現在の所属企業名・所属学校名などを保持
- 職歴テーブル: ユーザーの職歴を記録
- 学歴テーブル: ユーザーの学歴を記録
これらのテーブルはそれぞれ独立して存在しており、所属と職歴・学歴が相互に紐づかない構造になっていました。 このようなデータ構造でサービス運用を行っていく中で、以下のような問題が顕在化していました。
① 二重登録の手間と表記揺れ
たとえば、あるユーザーが「株式会社YOUTRUST」に勤務している場合：
- 所属テーブルに「株式会社YOUTRUST」
- 職歴テーブルにも「株式会社YOUTRUST」
というように、同じ情報を別々のフォームに登録する必要がありました。
加えて、職歴側で「YOUTRUST」（株式会社表記なし）のような表記揺れが発生することもあり、統一的な表示や管理が困難になっていました。
② 拡張性の限界
従来の「所属テーブル」は、ユーザーの“現在の所属”という単一の文字列情報（会社名や学校名）を保持するだけの構造でした。
このため、以下のようなニーズに対して柔軟に対応するのが困難でした：
- 「株式会社YOUTRUST Webエンジニア」のように、所属企業と職種を組み合わせて表示したい
- 将来的に「肩書き」「役職」など、所属に紐づく追加情報を表現したい
これらを満たすために職種情報を所属テーブル側に持たせてしまうと、今度は職歴テーブルと整合性が取れず、逆に職歴テーブルに職種を持たせると、プロフィール上の“現在の所属 + 職種”表示が困難になるなど、表現と構造のねじれが発生していました。
③ 所属種別を区別できない
旧構造では、「所属テーブル」に企業名と学校名の両方を同列に保持しているため、 その所属が「勤務先」なのか「在学中の学校」なのかを明確に区別することができませんでした。
実際に発生していた問題例：
- 「◯◯大学」という所属が登録されていた場合、そのユーザーが学生として在学しているのか、職員・研究者として勤務しているのか、データ上で区別できない
- 企業名と学校名が混在しているため、「現在の勤務先」「現在の在学先」といった立場別の絞り込み・検索・表示が不可能
解決策：経歴情報の集約と責務の明確化
こうした課題を解消するため、以下のような構造を導入しました：
- ユーザーが自身の職歴・学歴から現在のポジションとして明示的に選択できるテーブルを新設
- データの実体は職歴・学歴テーブル側にあり、現在のポジションはそれらを参照するだけの中間構造
移行アプローチ
YOUTRUSTでは「所属テーブル」に関連・依存する処理がとても多く（grepして軽く影響反映を確認しただけで何千箇所も・・・）、そのため、一度に全てを新テーブルに置き換えることは現実的ではなく、既存機能を壊さず安全に移行を進めるための戦略設計が必要でした。 そこで、以下のような段階的アプローチを採用しました。
① メンテナンスによる書き込み先の切り替え
移行に際して最大の課題は、新旧両方のテーブルに書き込みが行われる状態をどう避けるかという点でした。
旧テーブル（所属）を参照している既存機能が多数ある一方で、新テーブル（現在のポジション）に切り替えていくには、しばらくのあいだ両者が共存する状態を許容する必要がありました。
しかし、新旧どちらにも同時にユーザー編集が加わる状況では、整合性の破綻や意図しないデータ競合が発生するリスクが極めて高くなります。
そのため、共存を開始する前に、あらかじめ旧テーブルへの直接的な書き込みを完全に停止する必要がありました。
こうした背景から、計画的な深夜メンテナンスを実施し、このタイミングで以下の切り替えを行いました：
- 旧所属テーブルのデータをもとに、新しい「現在のポジション」テーブルへデータを移行
- ユーザーの編集操作は、すべて新しい「現在のポジション」テーブルに対してのみ行われるよう制御
- 旧所属テーブルは、以降は読み取り専用の状態とし、既存機能の参照元としては維持
これにより、「新旧両方に書き込まれる状態」を回避しつつ、安全な共存フェーズをスタートさせることができました。
② 共存期間中の同期戦略
メンテナンスを経て書き込み先を切り替えた後も、既存の多くの機能が旧所属テーブルを参照していたため、旧構造を壊さず挙動を維持するための“共存期間”を設けました。
編集操作は新テーブルのみに限定
ユーザーのプロフィール編集画面では、新テーブルのみが編集対象となります。新テーブルの編集内容を旧テーブルに即時同期
編集のたびに、旧所属テーブルへ同等のデータを即時反映する同期処理を構築し、既存機能への影響を最小限に抑えました。
このようにして、既存コードへの修正を最小限に抑えながら移行を進行できました。
おわりに
今回の「現在のポジション」構造への移行は、一見地味に見える変更かもしれませんが、YOUTRUSTのプロフィール機能全体に関わる大規模な再設計でした。
やってみて強く実感したのは、ゼロから作る新機能よりも、すでに動いている仕組みを壊さずに作り替えることの方が、何倍も難しいということです。
それでも、構造を整理し、表現力と拡張性を持たせることができた今回の取り組みは、ユーザー体験だけでなく、プロダクトとしての持続性にも大きな意味があったと感じています。
YOUTRUSTでは、一緒にプロダクトをより良くしていく仲間を募集しています。
今回のような設計・改善に興味のある方は、ぜひカジュアル面談からどうぞ！
