はじめに
こんにちは、クオリティ部の三上と申します。
あなたは最後にいつ、求人を検索しましたか？
その時、思い通りの結果は表示されたでしょうか。
「なんか違うな」と感じたことはありませんでしたか？
そんな「なんか違う」を見つけて、改善していく。それが私の仕事、Search Quality（SQ）です。
しかし、この職種には1つ大きな矛盾があります。
検索を改善するのが仕事なのに、私たちはコードを書きません。
検索エンジンを開発するわけでも、UIを設計するわけでもないのです。
今回は、そんな技術の隣にいるけれど、開発者ではない職種としてのSQのご紹介と、そこに込めている我々の誇りや葛藤について書いていきます。
SQは何をしているのか
SQは、最良の検索体験を重視し、検索品質を保つための評価・改善・提案を行います。
我々が担っているのは、具体的には以下のような業務になります。
- 検索品質指標と定性的観点に基づいたA/Bテストの評価分析
- 検索ランキングやUI等のさまざまな改善施策がどのような影響をもたらすかを、定量と定性の両面から検証。検索品質指標からの定量的な分析と、実際に返ってくる検索結果を評価スケールに従って1件1件人の目で評価する定性評価の二軸で確認。
- 検索辞書の作成・運用
- 求人側の表現とユーザーの検索語句のズレを埋めるための辞書整備。同音異義語や同義語等、意味が近いものを適切にマッチさせることで、検索結果の網羅性と適合性を高める。
- 検索品質向上にまつわるオペレーション業務
- 機能の精度評価、大規模な競合調査、データクレンジングなど、泥臭く見えるが重要な日々の地道な調査やメンテナンスもSQの範疇となる。
開発職でも企画職でもないこの立場だからこそ、「検索体験」そのものに専念できる──それがこの仕事の価値だと感じています。
何をもってして“よい検索”と言えるのか？
SQという職種で仕事に携わっていると、たびたび「よい検索とはなにか？」という問いに向き合います。
検索エンジンの世界では、nDCG（Normalized Discounted Cumulative Gain）やMRR（Mean Reciprocal Rank）のようなランキング評価指標や、A/Bテストの勝敗で「良し悪し」を判断するのが一般的です。それらは当然、大事な判断材料です。
ただ、我々はそうした指標に加えて、検索が「ユーザーにとって良かったかどうか」という、やや抽象的で主観的な問いにも常に向き合っています。
なぜなら、「よい検索」とは単なる数値の良し悪しではなく、「体験として意味のある結果（求めていた仕事）が返ってきたかどうか」に根ざしているからです。
SQは、以下に挙げる「RCFPTSD」の軸を総合的に見ながら、「よい検索」を定義しようと試みています。
Relevancy ― 関連性
まず、検索体験の根幹となるのが関連性です。
ユーザーが「事務 週3」と検索したときに、上位に表示されるのは「週3日勤務の事務職の求人」であるべきですし、この際に「アルバイト」とは打っていないのに、雇用形態がアルバイトの求人を勝手に増やすような過剰な推測も避けるべきでしょう。
その人が思ってもいなかったような出会いが演出されるのもスタンバイというサービスで提供できる1つの価値と考えますが、検索エンジンが求職者の意図を過剰に推測して拡張してしまうと、「入力したキーワードと無関係なものが出ている」という違和感につながりかねません。
だからこそ、入力されたクエリに忠実であることを重視しています。
Comprehensiveness ― 網羅性
一方で、「忠実である」ことだけを優先しすぎると、ヒット件数が極端に少なくなることがあります。ここで登場するのが網羅性という視点です。
たとえば「リモートワーク」と検索された場合、「完全在宅」や「テレワーク」などの表現ゆれに対応できていないと、求職者は求める求人に出会えず終わってしまいます。
広くあまねく求人票がindexされたうえで、取りこぼされることなく表示されるのがベストです。
Freshness ― 更新性
求人情報は更新性が命です。すでに募集が終了している求人や、情報が古いまま残っている求人が出てくると、それだけで求職者のがっかり度合いは高まります。
定期的なデータ更新、期限切れの判定、求人情報の提供元との同期精度──こうした地道な積み上げで更新性を担保することも非常に大事な要素です。
Presentation ― 閲覧性
検索品質は結果の並び順だけではなく、結果の見え方にも影響されます。
その求人がどんな業務内容で、どのエリアで、給与はいくらなのか。それらが視認性の高い形で整然と並んでいるか。
SQはUI・UXの専門家ではありませんが、検索結果に並ぶ情報が構造的に表示されていることや、応募判断に必要な情報だけが適切に露出されていることも重視しています。
それにより、ユーザーが求人を“読む”のではなく、“一目で把握できる”状態に近づけていきます。
Trust ― 信頼性
求人検索には信頼性も欠かせません。
怪しい副業勧誘、架空の求人、誘導目的の空求人──残念ながら、世の中にはそうした“信頼を裏切るコンテンツ”が存在しており、それらが混ざり得てしまうことがあります。
検索とは「真実に近づくための手段」でもあるべきで、職務上関われる領域としては限られていますが、SQとしても安心して使える検索体験の維持に努めています。
Speed ― 表示速度
検索体験における体感品質の中で、意外に見落とされがちなのが速度です。
検索ボタンを押したあと、コンマ数秒で画面が切り替わるし、求人詳細ページをクリックした瞬間に表示される──こうした速度の積み重ねが、ユーザーのストレスを最小化します。
逆に、レスポンスが遅いだけで、検索体験全体が「もっさりしている」「使いづらい」と評価されてしまうのです。
SQは体感上の待ち時間を最小限にすることも、検索品質の一環として捉えています。
Diversity ― 多様性
その職種で検索しているわけではないのに、検索結果の上位に同じような職種の求人が並びすぎていないか？
特定のブランドやエリアだけが強調されていないか？
SQは、関連する選択肢を過不足なく届けるだけでなく、ユーザーの視野を狭めないことも重要だと考えています。
そのために、職種・雇用形態・勤務地等の多様性にも目を配っています。
“体験”としての検索品質を、どう捉えるか
ここまで紹介してきた各要素は、いずれも直接的な数値で表しにくく、それゆえに議論が難しい側面もあります。 ましてや、SQはスタンバイのプロダクト体験全体を代表する立場でもありません。
ですが、検索という機能において、「ユーザーが仕事に出会うまでの橋渡し」を担っているという自覚があります。
その橋が、崩れていないか？
狭すぎて通れない人がいないか？
誰かにとって怖い道になっていないか？
こうした問いを、自分たちなりの“ものさし”で考え続ける──それが、私たちSQの役割なのだと思っています。
SQという職種は珍しい？
さて、ここからはSQという職種について書いていきます。
検索サービスの品質管理というと、GoogleやLINEヤフーのような大規模プラットフォームにしか存在しない印象を持つかもしれません。
実際、検索体験の質にフォーカスした専任職は、全世界を見渡してもありふれたものではないようです。しかもそれらの多くは、検索そのものが事業のコアであり、かつリソースに余裕のある超大企業です。
そんな中で、スタンバイのような比較的小規模な事業会社が、検索品質だけに特化した専任職を設けているのは、ある意味ユニークです。
開発を担わず、直接プロダクト機能を生み出すわけでもない職種に対して、リソースを割くことは、短期的な視点では非合理に見えるでしょう。
仮に置くとしても少なくとも今のフェーズではない。
普通ならば、1つでも機能を開発するために、エンジニアの数を増やす経営判断をするはずです。
しかしスタンバイはあえて、この職種を配置しています。
それは、「求人検索体験の質」こそが、サービスの生命線であるという強い哲学があるからと私は思っています。
「検索結果が正確である」
「意図に沿ったものが返ってくる」
──これは、どれだけ華やかなUIや機能があっても欠けてはならない土台です。
そしてその土台を、数字の外側にある“肌感覚の違和感”まで含めて丁寧に保つために、SQというロールが存在しています。
ロールモデルの不在とキャリアの見えなさ
SQの意外な悩みとしては、明確なロールモデルがほとんどいないことも挙げられます。
先述したように、SQは世の中にありふれた職種ではありません。
近しいものを挙げるとするなら世間一般的にはデータサイエンティストやリサーチャーですが、それとてSQの経験をそっくりそのまま外に持っていくのも難しいのです。だからこそ……
- 何をもって「優秀」とされるのか？
- どんなスキルを深めていけばいいのか？
- どんなキャリアパスがありうるのか？
これらが曖昧で、自分で自分の仕事の価値を定義しなければならない瞬間が多くあります。
SQはまだ“未定義の職種”なのです。
これは孤独でもありますが、同時に「自分で形を作れる」という自由でもあります。
「好き勝手に言っているだけ」に見えてしまうときもある
一方で、開発をしない立場として、エンジニアやプランナーと接する中で感じる“距離”はたしかにあります。
たとえば、検索体験を改善するためのを提案しても、
「実装コスト重くない？」
「全体の優先度的に今ではないんじゃない？」
「それって本当に意味あるの？」
という反応が返ってくることがあります。
もちろん議論は健全なことです。
しかし、自分たちが創り出していない分、発言が軽く受け取られてしまう感覚を時として抱くこともあります。
「現場の苦労もわからず好き勝手に言っているだけ」
「自分で実装しないのに、このタイミングでそれを言うのか」
──そう思われるリスクを常に感じながら、それでも提案を続ける場面もあります。
この立場には、信頼されなければならないけれど、信頼を築くための「見える成果」が得にくいという矛盾が常につきまといます。
それでも、言わなきゃいけないことがある
開発をしていなくても、数値に表れなくても、「これが気になる」「これはユーザー体験として違う気がする」という直感を大事にしたい。
そしてそれを仮説に変え、検証できる形に持ち込み、誰かと協働して実際の改善に結びつけていく──そのプロセスこそが、SQという職種の本質なのだと考えます。
時には耳の痛いことを言わなければならない。ときには嫌われ役になることもある。
でも、それがユーザー体験のためになるのであれば、我々は甘んじてその役割を引き受けたいと思っています。
おわりに
SQという職種は、技術と非技術の“あいだ”に立っています。 エンジニアのようにコードを書かず、PdMのようにロードマップを握るわけでもない。
だからこそ、見えるものがあります。
だからこそ、言えることがあります。
この未定義な職種で、日々悩みながら働いている人間がここにいます。
もし、あなたのチームにも「コードを書かないけれど、体験の質を守ってくれている人」がいるなら、その人の存在に少しだけ思いを巡らせてもらえたら嬉しいです。
そして、もしこの記事を読んで「こういう立場で検索体験に向き合ってみたい」と感じていただけたなら──
スタンバイでは、SQという少し変わった職種に挑戦してみたい仲間を募集しています。
未定義だからこそ、まだまだ形にできることがたくさんあります。ぜひ一緒に、検索という体験を育てていきましょう。
↓SQが気になった方はこちらかどうぞ
サーチクオリティ/Search Quality(SQ)
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com
