Notion + Wraptas + Tally で作るカジュアル面談募集ページ
こんにちは、すべての経済活動をデジタル化したい LayerX HR の宮本です。
本日はリリース時にとてもとても大きな反響をいただきました LayerX のカジュアル面談募集ページ「OpenDoor」の裏側(作り方)についてお話したいと思います。
この記事では以下のことがわかりますので、少し長いですがぜひ最後までご覧ください。
OpenDoor を作るに至った課題背景
Notion でカジュアル面談ページを作るにあたって検討したこと
具体的な実装方法
OpenDoor を作ってみての反響
0. 従来のカジュアル面談サービスの課題
近年の採用シーンにおけるカジュアル面談の重要性については、もはや疑う余地はないかと思います。LayerX でもかねてより積極的にカジュアル面談を行なって参りました。
そしていま在籍してる社員のうち決して少なくない割合で、いわゆるカジュアル面談サービスでの接点から入社に至っています。
一方で、その利用においてはいくつかの課題があると考えていました。
ちなみに LayerX では Notion をベースに Wraptas というツールにて自社の採用ページを公開しています。
先のカジュアル面談サービスの課題と、Notion の柔軟性・Wraptas による拡張性をふまえ「あれ?なんだかカジュアル面談ページは内製化できる気がするぞ…?」となったのが OpenDoor 作成のきっかけでした。
カジュアル面談ページの内製化にあたり、前述の課題を解決するためのユーザーストーリーとして以下の3つの観点で整理しました。
1. 閲覧者が面談に簡単に応募ができる
お客様の体験を何よりも大切にするカルチャーの LayerX において、最もこだわったのがこのポイントでした。
残念ながら2023年5月現在で Notion にはフォーム機能はありません。
なんとしても、採用ページ(Notionのページ)から他ドメインに遷移することなく、募集ページ内から直接応募をしてもらえる仕様にしたかったのです。
さまざまなパターンを試しましたが、UI/UXの観点から、最終的に以下の2つの仕様に定めました。
1-1. フォームの埋め込み方法について
Notion ページにフォームを埋め込む場合、フォームサービスの外部公開用 URL を Notion に Embed するやり方が最も簡単ではあります。
ただ、特にスマホにおいてスクロール可能な範囲が限定されることにより、UXが悪く見送りました。
調査の結果、Wraptas には Notion のコードブロックを HTML として挿入できる機能があり、これを使うことでフォームの課題は解決しました。
1-2. フォームの設計について
フォームの入力項目の増加は応募体験として極めて悪いため、1つの共通フォームで自動的に「誰の、どの面談への応募かが自動的にわかる」という仕様にしたかったです。
これを実現するために、フォームの URL に対してクエリパラメータ等でなんらかの情報を事前に付与しておくことで、フォーム送信時のデータに連携できるサービスを検討しました。
具体的には、Googleフォーム、HubSpot、Tally の3つのサービスで検討しました。
最終的に、全ての仕様を満たせるかつ、埋め込んだデザインが Notion に馴染み、コストもかからないということで、Tally というフォームサービスを選択しました。
以上のようにカジュアル面談の募集ページを Notion を使って作るには、Wraptas と Tally を組み合わせれば、比較的すぐにできてしまいます。
ですが、表向きのページが簡単にできても、実際の募集ページが充実しないことには意味がありません。
次項では通常業務に追われる社員の方に、いかに募集ページを簡単に作ってもらえるかの工夫をしたお話をします。
2. 社員が簡単に面談を作ることができる
カジュアル面談ページを内製化するにあたり、面談ページを作成する社員もこのサービスの「お客様である」と考えていました。
そのため、出来る限り簡単に募集ページを作ることができる仕様を考えました。
そもそも募集ページ作成は以下の3つから成り立ちます。
2-1. 募集要項の記入
これはシンプルに Notion のテンプレート機能を使うだけなので詳細は割愛します。
2-2. OGPの作成
カジュアル面談の募集において主にSNSからの流入がメインであることを想定して、OGP のデザインは非常に重要だと考えました。
LayerX が誇るコーポレートコミュニケーションデザイナーの @chibakun に多大なるご協力をいただき、このような OGP が完成しました。
デザインにあたり大切にしたポイントは以下の3つです。
また作成方法においては、以下の note で紹介されている、Zoom の背景画像を Slack から動的に生成する仕組みを一部アップデート(後で詳しく解説します)することにしました。
2-3. 面談情報付きのフォームURLの発行
Tally というフォームサービスの埋め込みURLは、通常以下のようなものです。
ここに対して、事前に面談タイトル( = title)と、面談者( = member)という項目を非表示で設定した上で、以下のような URL にて埋め込むと、付与したクエリパラメータの情報がフォーム送信時にも連携される仕組みになっています。
この URL で埋め込んだフォームを送信すると、面談タイトル項目には「カジュアル面談がしたいです!」、面談者項目には「junya.miyamoto」が自動的に入ってきます。
とはいえ、フォームのクエリパラメータの設定を手動でするのは大変なため、前述の OGP の自動生成に合わせて、フォームの URL も自動的に作ることができる仕組みを考えました。
2-4. zapierで一連の流れを自動化する
Slack のワークフローに対して、面談タイトル、面談担当者、募集職種を入力すると、自動的に OGP とフォームの URL が返信される仕組みを作りました。
zapier のレシピはこんな感じです(長い…)
以下ざっくり解説します。
(さらに詳しく知りたい場合は直接お問い合わせください😎)
2-4-1. Slackのワークフローのテキストをスプレッドシートへ記入する
まず、Slack のワークフローより送信された各項目について、zapier の Formatter を用いて適切に加工した上で、スプレッドシートへ転記します。
2-4-2. スプレッドシートから、ランダムで表示する背景画像の Figma ID を取得する
OGP の作成は大きく以下の流れになっています。
(再掲ですが API template について詳しくはこちらをご覧ください。)
この記事で紹介されていることと異なる点としては Figma の API によって背景画像を毎回変えている点です。
API template はこのような編集画面になっており、画像の URL やテキストを渡すと、自動的に画像やテキスト内容が置き換わるサービスです。
この背景画像のURLを、事前に Figma で用意した画像に対して Figma の API 経由で取得する、という処理をしています。
ちなみにFigma の API の利用についてはこの記事が詳しいです。
スプレッドシート側では、1~20までの数字と Figma の API を叩く上で必要な各画像の ID を保持し、Slack のワークフローが送信される度にランダムに画像の ID を返す、という仕組みにしています。
2-4-3. Figma の API から背景画像 URL を取得する
zapier の Webhooks という機能でも API を呼び出すことはできるのですが、レスポンスの配列を一部操作する必要があったため、Python を動かしています。
import requests
token = "{YOUR_TOKEN}"
id = input_data['id']
api_url = "https://api.figma.com/v1/images/{hoge}?ids=" + str(id)
headers = {
"X-FIGMA-TOKEN": token
}
response = requests.get(api_url, headers=headers)
result = response.json()
output = {"url" : result["images"][str(id)]}
2-4-4. 面談タイトルが長い場合に、テキストを切り詰める
あまりにも面談タイトルが長い場合、OGP 内に収まりきらなかったり、レイアウトが崩れる場合があるため、全角38文字以上は「…」となるような処理を噛ませました。
スプレッドシート上でできなくもないですが、半角の考慮がされないため、ここでも Python を動かしています。
import unicodedata
length = 0 # 文字列の長さを初期化する
truncated = "" # 切り詰めた文字列を初期化する
text = input_data['raw_title']
for char in text:
# 文字の幅を取得する
char_width = unicodedata.east_asian_width(char)
# 全角文字の場合は、長さに2を加算する
if char_width in ("F", "W", "A"):
length += 2
else:
length += 1
# 文字列が39文字を超えた場合、処理を終了する
if length > 74:
truncated += "…"
break
else:
truncated += char
output = [{'title': truncated}]
2-4-5. API template から画像を取得する
zapier 上では、背景画像の URL と、面談タイトル、募集職種を入れるだけです。
2-4-6. 生成された OGP を Slack で返信する
上記処理で API template から吐き出された OGP の画像 URL を Slack で返信します。
2-4-7. 生成されたフォームの URL を Slack で返信する
クエリパラメータに Slack のワークフローで取得した情報を付与します。
上記により、Slack のワークフローを動かすだけで、自動的に OGP とフォームの URL を取得することができます。
これらのおかげで、1つの面談の作成から公開まで、おおよそ10〜15分程度で完了しています。
この簡単さも相まって、現在 LayerX OpenDoor には100件以上のカジュアル面談が公開されています。
3. 採用チームと社員が簡単に応募者を管理できる
せっかく Notion から簡単にカジュアル面談ページを作れるようになったんです。応募者の管理ももちろん Notion でやりたいですよね?
安心してください、Tally は zapier と連携しています。
せっかくここまで全てがこれだけ簡単にできるんです。まさか応募通知がメールなんてことはないですよね?
安心してください、応募者に Slack で通知できます。
ということでこちらが zapier のレシピです。
3-1. Tally 経由で送信されたフォーム内容を Notion の DB に格納する
全ての応募が Notion の DB でステータスとともに管理することができます。これは現状外部のカジュアル面談サービスでは難しいので、とても嬉しいです。
3-2. 応募者に Slack で通知する
前項で説明した 2-3. 面談情報付きのフォーム URL の発行 により、面談者の情報が Tally から送られてきますので、その情報をもとに Slack からメンションを飛ばして通知しています。
Slack と Notion で応募管理ができるって、最高ですよね。
4. で、実際この施策どうなんですか?
結論を申し上げますと、、、
とても効いています。
細かい数字は別の機会で公開したいなと考えておりますが、公開後100件以上のご応募をいただきました。
そして実際にカジュアル面談から選考に進んでいただくケースも多数出ており、さらには入社の決定も出ています。
またご応募いただく方の特徴として、どのような目的でどのような内容を話したいか、を明確にフォームにご記載いただくケースが多く、LayerX にご興味を持っていただいた次のステップとしての選択肢になっていると感じています。
ただ、そういった効果以上に個人的に嬉しいのが、「社員のみんなが新しい施策に楽しみながら協力してくれて、募集をドンドンと立ち上げ、実際に応募がきていること」です。
事業はもちろん、採用という領域においても、0 から 1 を生み出せるダイナミクスと面白さがあるのが、LayerX の良さだと心から思います!
まずは小さく失敗して改善しよう、という前提で始めた施策ではありましたが、今後も継続的に続けていく予定です。
長くなってしまいましたが、少しでも参考になっていれば幸いです。
直近では Gaudiy さんが参考にしていただいており、大変光栄に思っております。
(純粋にめっちゃ嬉しいです!ありがとうございます!)
また、個人的には LayerX の行動指針の1つである、 Bet Technology をHR 組織こそ体現していきたいと強く考えております。
現在取り組んでいる内容などはあらためて note や Twitter で発信していく予定です💡
(個人的にこれまでさまざまな SaaS の API を触り自動化や可視化をしてきたので、定期的にアウトプットしていきます。)
また、僕と一緒にエンジニア採用していただける方も探しています。何卒!
この note に関することや、その他 LayerX の HR などなんでもお話できればと思いますので、僕の OpenDoor もお待ちしています🙌