Resume - クロスプラットフォームのレジュメ/CVサービス
職務経歴を、人にも機械にも扱いやすいデータへどう整理し直すかを扱ったプロジェクト。
Contribution
プロダクトデザイン
Company
Recruit
Year
2022
プロジェクト概要
チーム：プロダクトオーナー1名、プロダクトマネージャー（PdM）2名、プロダクトデザイナー2名、エンジニア10名以上
なぜこの問題が重要だったか
リクルートホールディングスは、日本で多様な市場を抱える複数の求職サービスを運営しています。
• リクナビ：新卒向け求職サイト
• リクナビNEXT：総合型の求職サイト
• タウンワーク：アルバイト・派遣など非正規求人向けサイト
• リクルートエージェント：人材紹介・エージェントサービス
• リクルートダイレクトスカウト：ハイクラス向けスカウト型転職サイト
• など
こうしたサービス群では、同じ職歴をサービスごとに入力し直す必要があった。
「One ID & One resume」はアカウント統合の話ではない。複数プロダクトをまたいで流通し、マッチングも支えられる共通のレジュメ構造を定義することだった。
本当に変えるべきこと
システムのレベルでは
• 異なるプロダクトで使える共通のレジュメ基盤をつくる
• 職務経歴をAIが安定して解釈できる構造にする
• 求職者と採用側の両方で検索とマッチングの精度を上げる
インタラクションのレベルでは
• 職務経歴を“履歴書の言葉”に変換する負担を下げる
Design Challenges
チャレンジ ❶：構造化入力の負担を先に下げる
何が難しかったか：
複雑で具体的な職務経歴を、1,200超の職種と15,000以上のスキルタグにまたがるAI可読の構造へ落とし込む必要があった。
必要な情報は揃っていても、入力の負担が大きすぎた。
どう変えたか：
プロトタイプ V1（リニアQ&A）：
1画面1問の形式は整っていたが、入力は長く、薄くなりがちだった。完了はできても、自分の経験の厚みがうまく入らない感覚が残った。
最終版（カテゴリ化タグUI）：
線形の質問フローから、カテゴリを手がかりに経験を選び取るUIへ切り替えた。まず“自分の経験を見つけられる”ことを優先した設計。
チャレンジ ❷：データモデルから作り直す
何が壊れていたか：
テストで見えてきたのは、検索UIより先に職種モデルそのものがズレているということだった。ユーザーは、自分の仕事をこの分類のどこに置けばいいのか分からなかった。
どう変えたか：
UIだけを磨いても解けないと判断し、PdMと一緒に職種構造そのものを作り直した。
IT > エンジニア > バックエンド > サーバーサイド IT > エンジニア > システムエンジニア > Web/オープン
IT > サーバーサイドエンジニア IT > システムエンジニア > Web/オープン
階層を浅くする：
職種タクソノミは4階層から3階層へ整理し直し、実際の理解のしかたに近づけた。
検索が構造を説明する：
オートコンプリートも整理し直し、中位カテゴリごとに候補が見えるようにした。検索結果の並び自体が分類の手がかりになるようにしている。
検証：
SUSは73.8から83.0へ改善し、「理解しやすさ」は91.4まで伸びた。
チャレンジ ❸：衝突する要件を一つの基盤で受ける
何が難しかったか：
リクルートダイレクトスカウトには深さが必要で、タウンワークには速さが必要だった。同じオンボーディングを当てると、どちらかを傷つける。
一方で、プロダクトごとに完全に別物にしてしまうと、共通DBの意味が薄れる。
どう変えたか：
オンボーディングを単一フローではなく、構成可能なシステムとして設計した。
モジュールに分ける：
収入、スキル、学歴などの入力要素をモジュールとして切り分け、必要に応じて組み合わせられるようにした。
/registration?option_items=previous_work_histories&career_summary
URLパラメータによるカスタマイズ：
各プロダクトはWebViewに渡すパラメータで必要な入力を指定できるが、最終的には同じレジュメ構造へ書き戻される。
最後に変わったこと
入力完了率だけでなく、入力されるデータの質そのものも改善した。
- 効率：レジュメ作成の平均時間が50％超短縮（957秒→450秒）。
- データの豊かさ：ユーザーあたりのスキルタグ入力数の平均が4から10に増加。
- マッチング成果：スクリーニング通過率が全体で117％に、若年層や以前は未充足だったプロフィール層では157％まで伸長。
一番伝えたいこと
- レジュメ入力が軽くなったのは、フォームを整えたからではなく、職務経歴を翻訳する層として設計し直したからだ。
- 大きな改善は、間違った構造の上でUIを磨くことからは生まれなかった。タクソノミを直したことが効いた。
- クロスプラットフォームの一貫性は、万能な一つのフローではなく、構成可能なシステムで支えている。
- プラットフォームのデザインでは、画面よりも下にあるデータ層に入っていく必要がある。