Resume（レジュメ）：リクルートの複数サービスで使える共通レジュメ
職務経歴を、人にも機械にも扱いやすいデータへどう整理し直すかに取り組んだプロジェクト。
担当領域
プロダクトデザイン
会社
Recruit
期間
2022
プロジェクト概要
チーム：プロダクトオーナー1名、プロダクトマネージャー（PdM）2名、プロダクトデザイナー2名、エンジニア10名以上
なぜこの問題が重要だったか
リクルートホールディングスは日本国内で、対象ユーザーの異なる複数の求人・転職サービスを運営している。
• リクナビ：新卒向け就職情報サイト
• リクナビNEXT：総合転職サイト
• タウンワーク：アルバイト・パート求人サイト
• リクルートエージェント：転職エージェント（人材紹介サービス）
• リクルートダイレクトスカウト：ハイクラス向けスカウト型転職サイト
• など
これらのサービスでは、ユーザーが同じ職歴をサービスごとに入力し直す必要があった。
「One ID & One resume」は、単なるアカウント統合ではない。複数のプロダクトをまたいで使え、マッチングも支えられる共通のレジュメ構造を定義する取り組みだった。
本当に変えるべきこと
システム面
• 異なるプロダクトで使える共通のレジュメ基盤をつくる
• 職務経歴をAIが安定して解釈できる構造にする
• 求職者と採用側の両方で検索とマッチングの精度を上げる
インタラクション面
• 職務経歴を「履歴書の言葉」に変換する負担を下げる
デザイン上の課題
課題 ❶：構造化入力の負担を先に下げる
何が難しかったか：
複雑で具体的な職務経歴を、数千に及ぶ職種・スキルタグにまたがるAI可読の構造へ落とし込む必要があった。
必要な情報は揃っていても、入力の負担が大きすぎた。
どう変えたか：
プロトタイプ V1（リニアQ&A）：
1画面1問の形式は整っていたが、入力に時間がかかり、内容も薄くなりがちだった。完了はできても、自分の経験の厚みがうまく入らない感覚が残った。
最終版（カテゴリ別タグUI）：
線形の質問フローから、カテゴリを手がかりに経験を選び取るUIへ切り替えた。まず「自分の経験を見つけられる」ことを優先した設計。
課題 ❷：データモデルから作り直す
何が問題だったか：
テストで見えてきたのは、検索UIより先に、職種の分類そのものがユーザーの認識とずれているということだった。ユーザーは、自分の仕事が分類のどこに当てはまるのか分からなかった。
どう変えたか：
UIだけを磨いても解決しないと判断し、PdMと一緒に職種の分類構造そのものを作り直した。
IT > エンジニア > バックエンド > サーバーサイド IT > エンジニア > システムエンジニア > Web/オープン
IT > サーバーサイドエンジニア IT > システムエンジニア > Web/オープン
階層を浅くする：
職種分類を4階層から3階層に整理し、ユーザーが自分の仕事を捉える感覚に近づけた。
検索で構造を伝える：
オートコンプリートも見直し、中分類ごとに候補を表示するようにした。検索候補の並びそのものが、分類を理解する手がかりになる。
検証：
SUSのスコアは大きく向上し、特に「理解しやすさ」が高く評価された。
課題 ❸：相反する要件を一つの基盤で受け止める
何が難しかったか：
リクルートダイレクトスカウトには深さが、タウンワークには速さが求められる。同じオンボーディングを使うと、どちらかの体験が損なわれてしまう。
一方で、プロダクトごとに完全に別の仕組みにすると、共通DBの意味が薄れてしまう。
どう変えたか：
オンボーディングを単一のフローではなく、設定で組み替えられる仕組みとして設計した。
モジュールに分ける：
収入、スキル、学歴などの入力項目をモジュールに分け、必要に応じて組み合わせられるようにした。
/registration?option_items=previous_work_histories&career_summary
URLパラメータによるカスタマイズ：
各プロダクトはWebViewに渡すパラメータで必要な入力項目を指定できるが、データは最終的に同じレジュメ構造に書き戻される。
成果
入力完了率だけでなく、入力されるデータの質そのものも向上した。
- 効率：レジュメ作成の平均時間が大幅に短縮。
- データ量：1ユーザーあたりの平均スキルタグ数が大幅に増加。
- マッチング成果：スクリーニング通過率が全体で大幅に向上。特に若年層や、これまでプロフィールが不十分だった層で大きく伸びた。
デザインの考え方
- レジュメ入力が軽くなったのは、フォームを整えたからではなく、職務経歴を「翻訳」する中間層として設計し直したからだ。
- 大きな改善は、間違った構造の上でUIを磨くことからは生まれなかった。タクソノミを直したことが効いた。
- クロスプラットフォームの一貫性は、万能な一つのフローではなく、構成可能なシステムで支えている。
- プラットフォームのデザインでは、画面よりも下にあるデータ層に入っていく必要がある。