Hajime

Posted on Sep 19

「可・不可・要相談」の3値を媒体ごとに持つと、検索はどう変わるか

#database #webdev #japan

人と案件をつなぐサービスを作るとき、プロフィールは「できること」の集合として設計されがちです。スキルタグを持たせて、部分一致で引く。実装としては素直ですが、できないことが表現できないという弱点があります。

キャスティングのサイトを読んでいて、ここを正面から持っているデータ設計を見かけたので、構造として何が起きるのかを書きます(掲載内容の確認は2026年9月時点)。

→ 対応可否を媒体ごとに登録できる NEXT CAST

持っているのは (媒体 × 3値) と NG 事項

登録するタレントは、SNS や媒体ごとに「対応可 / 不可 / 要相談」を登録し、加えて NG 事項を明記します。

素朴に書くと、プロフィールはこうなります。

Talent
  id
  category            # 芸人 / インフルエンサー / アーティスト / その他
  intro               # 紹介文(必須)
  availability[]      # (media, status, condition)  status ∈ {ok, ng, negotiable}
  ng_notes[]          # 受けない案件の種類

availability を 2値(できる / できない)ではなく 3値にしているのが肝です。

2値にすると「要相談」が消える

3値を2値に落とすと、negotiable はどちらかに寄せることになります。

ok に寄せる → 検索結果に出るが、打診すると断られる。偽陽性が増える
ng に寄せる → 条件次第では受けられた案件が、そもそも表示されない。偽陰性が増える

現実の運用では、後者のほうが見えにくく、損も大きくなります。出てこなかった候補は、誰にも気づかれないからです。

3値のまま持てば、検索側で「可のみ」と「可+要相談」を出し分けられます。UI としては、絞り込みの既定値をどちらにするかという問題に変わります。

条件は構造化しないほうが通ることもある

condition と ng_notes は自由記述です。ここを無理に enum へ落とさないのは、実務上は妥当だと思います。

受けない案件の理由は、業種、商材、表現、時期、共演者と、軸がばらばらです。列挙しようとすると、どの軸でも取りこぼす。検索の絞り込みには媒体 × 3値を使い、細部は人が読む。役割を分けた形です。

依頼側にも必須項目がある

このサービスで面白かったのは、依頼する企業側にもプロフィールの公開が必須な点でした。

会社名・キャスティングの希望・企業ロゴの登録が、タレント検索と依頼の必須条件とされています。タレント側も、紹介文の登録が公募案件の検索・応募の必須条件です。

つまり検索できる状態になるまでに、両側でバリデーションが1回ずつ入ります。「空のプロフィールで一覧だけ眺める」ができないので、検索に出てくるレコードの質が上がります。

公開前に人の確認が入る

タレントの掲載も、企業の公募案件も、公開前に運営が内容を審査します。差し戻しの場合は理由がマイページに表示され、修正して再申請できるとありました。

状態としては draft → in_review → published、差し戻しで rejected(reason) を経て draft に戻る形です。理由を保持して画面に出す前提なので、rejected は状態フラグではなくメッセージ付きのレコードになります。

掲載基準も、値として効いてくる

掲載基準には、18歳以上、本人が運用する公開アカウントで活動実態が確認できること、フォロワーの購入・水増しが疑われる場合は掲載を見送ること、といった条件が並びます。

SNS を主な媒体とする人は合計フォロワー1,000人以上が目安、ただし目安未満でも活動実績・専門性・独自性を含めて総合判断、とも書かれています。

しきい値を公開しつつ、しきい値だけで機械的に切らない。審査を人が持っている設計とセットで読むと筋が通っています。

契約の形は1つに絞られている

扱うのは業務委託の案件のみで、雇用契約の募集は掲載できません。企業とタレントが直接契約を結ぶ場の提供であり、雇用のあっせんは行わないと明記されています。

扱う契約が1種類だと、通知も、案件の状態遷移も、分岐が減ります。何でも載る場にしないことが、そのまま実装の単純さになっています。

まとめ

できないことを持てる構造(3値 + NG)は、検索の精度に直結する
2値へ落とすと偽陰性が増え、しかもそれは観測しづらい
絞り込みは構造化データ、細部は自由記述、と役割を分ける
両側に必須項目を置くと、検索対象のレコードが痩せない

本ページはプロモーションが含まれています

DEV Community