はじめに
こんにちは！ 株式会社ハイヤールーの谷合です（@poster-keisuke）
先週HireRooのサービスサイト（LP）をリニューアルしました。
先に結果を述べますと、 LPをリリースしてから（執筆時点で約1週間ほど）Twitterやその他SNSで大々的に告知を全くしませんでしたが、PV数は右肩上がりで、お問い合わせ数も前のLPと比べると日次で+100%アップという結果になりました。（図1参照）
手前味噌ですが、前のLPと比べると格段にお客様の課題感の訴求やサービスの特徴を端的に説明するLPに生まれ変わり、結果としてコンバージョンにも現れたのかなと思います。
今まで、プレスを打ったタイミングやブログ記事を出したタイミングではLPへのランディングやお問い合わせ数に変化があったものの、それ以外の要因で上がることはほとんどありませんでした。 しかしリニューアル後はSEO経由でのオーガニックやリファラルでの流入数がかなり増えました。
今回の記事では実際にどのようなフローでLPを改善していったのかというプロセスの共有と、なぜ流入数やお問い合わせ数を改善することができたのか？という考察をこの記事にてまとめようと思います。 （※前提として事業内容や、フェーズにもよると思うのであくまでもご参考程度にお読みください。）
お伝えしたいことを書いていたらかなり長くなってしまったので、時間があるときにお読みいただくことをオススメします笑
ではさっそく。
実践したプロセス
まず、実際に私たちが実施したプロセスを大きく3つのフェーズに分けて書いていこうと思います。
課題感のアップデート
まず初めに行ったのは潜在顧客に訴求すべき課題感のアップデートです。
プレスリリース時にお問い合わせいただいた企業様を含む数十社にご協力いただき、エンジニアの採用時に抱えている課題感をヒアリングしました。
その際に気をつけたこととしては2点で
- ヒアリングを通して何を学習したいのか
- （基本的には）ヒアリングの内容は変えず同じことを聞くようにするため質問項目を精査した
これらを最初の設計で行うことで、より質の高いヒアリングを行えるようにしました。
まず1をしっかりと組み立てないと、「何を聞いたらいいか分からないからとりあえず話を聞いてみた」で終わってしまいかねません。 まずはゴールをしっかり定義します。
1が決まったら質問内容を考えますが、そのときに2を意識して行うことでヒアリング終了時に図2のようにグラフ化してターゲットの属性を判断したり傾向を掴むことが可能です。 そのためヒアリングは一貫して同じことを質問できるような状態を最初の段階で考えておくことが大切です。（もちろん途中で細かなアップデートはしていくのは良いと思います。）
余談ですが、ヒアリングの内容をGoogle Formで作っておいて内容をフォームに送っていくとスプレッドシートで展開できるので、後で分析する際に非常に楽なのでおすすめです。
前提はここまでで以下から手順の紹介です。
手順としては以下の通りです
- エンジニア採用という文脈における採用ミスマッチの妥当性の検証
- ミスマッチが起こる原因となる行動やプロセスの把握
- 訴求すべき課題感を決める
順に説明します。
エンジニア採用という文脈における採用ミスマッチの妥当性の検証
もともとHireRooというサービスは創業メンバーがエンジニアとして働いている中で感じていた技術ミスマッチによる機会損失を防ぐために、必要なコーディング試験というソリューションとして生まれました。
もちろんサービスリリース前に事前に軽い調査は行いましたが、今回改めてエンジニア採用においての課題の中で妥当性（解決するに値する問題なのか）も一緒に把握することにしました。
こちらは、βリリース時点でもかなりの数の企業様がHireRooというソリューションを気になって連絡してきてくださった（＋備考欄にミスマッチの課題感を書いてくださった方もいた）ため、再確認程度のものです。
その中の上位3つくらいをピックアップすると、
- エンジニア採用の母集団形成に関する課題感
- 採用時の技術力を把握できないことによるミスマッチ
- 社内エンジニアのスキルが把握できず正しく評価ができない
といったものでした。 採用時のミスマッチという課題は大きくは外れてないようでした。
次はこの「採用時の技術力を把握できないことによるミスマッチ」を深ぼってみました。
ミスマッチが起こる原因となる行動やプロセスの把握
上の質問と同時により深ぼった質問もさせていただきました。 もともとコーディング試験サービスというものに興味を持って連絡をくださった企業様だったので、コーディング試験の導入を検討したきっかけや動機また期待するものなどをそれぞれ伺いました。
すると、ミスマッチを引き起こす要因となりそうなプロセスが分かってきました。 * 面接が属人化しており、部署・面接官ごとに採用指標が異なるため入社する人材のスキルがバラバラ * 職務経歴書やGithubで技術を把握しようとしたが無理があることは分かっている
どちらもコーディング試験を導入することによって改善できそうだけど、「社内のリソース的に内製化はできない」 or「 試したが運用コストが大きすぎて断念した。」ということでした。
訴求すべき課題感を決める
ここまで把握できたら後はどの課題感を訴求するかを決めるだけです。 (上記に紹介した以外にもいくつか細かなものはありましたが、その中でも特に頻出だったの2つを選びました。)
今回のヒアリングの結果から「エンジニア採用のミスマッチを防ぐ」という大きなテーマは変えない一方で、より具体的なプロセスに言及し、まさに自分の会社が抱えている問題だとだと思ってもらえるようにしました。
前回のLPでは、課題感の訴求は出来ていたもののそれ以上の説明がなかったためこのサービスは自分の会社の課題を解決してくれるソリューションなのか？がぱっと見分かりづらかったと思います。
また上記2つとは課題感の粒度が違いましたが、一度社内でコーディング試験を検討した会社様はみな口を揃えて、内製化のコストが高すぎると仰っておりました。 現にエンジニア採用で成功しているメルカリさんも記事を書いているくらい、大きな悩みとして挙げられていたので、僕らの解決できるソリューションとしてLPに載せることにしました。
デザインとコーディング
もちろんこれらを形にする必要があります。 今回私たちはデザインを知り合いに依頼し、コーディングだけは自分たちで行うことにしました。 今回のように依頼を前提に進めるにあたって、いくつか気をつけるべきポイントがあったので最後にそちらを共有したいと思います。
ヒアリングの内容を包み隠さず共有する
ヒアリングの内容に限らずですが、必要だと思う情報はいつでも見れるように共有しました。 あくまでも潜在顧客層の方が見て、共感して連絡してきてくれるということがLPのゴールなので、情報設計は非常に大切です。
今回のようにデザインをする人と実際にヒアリングに参加していた人が違う場合は、いちばん大事な顧客の声を直接聞いていないため、課題感の認識に大きなズレが生じやすいです。
ありがたいことに、今回デザインをお願いした方は以前一緒に仕事をしたことがある方だったので、そのあたりのコミュニケーションは非常に楽でした。 かつデザインイメージや、課題感の共有も非常にうまく行ったと思います。（かなり曖昧にお伝えしてもニュアンスで感じ取ってくれたという話でもあります。笑）
もし知らない方であればより情報共有は綿密に行うことをオススメします。 デザイン初期の段階でかなり違うものが出来てしまう可能性があります。
必要に応じてSaaSのソリューションを利用する
これはチーム内にHTML / CSSを得意とする人がいなかったということでもあるのですが、ヒアリングの次くらいに時間がかかるプロセスは受け取ったデザインを形に起こすことでした。 完璧に再現するにはそれなりにスキルが必要です。デザインもできてHTML/CSSのコーディングができればそれは最高ですが、そうでない時もあると思います。
LPのように中のコンテンツを逐次変えていくようなものに関しては、初期コストに加え運用コストもかかります。その場合作った人以外が触れない（触れるがコストが掛かる）ことがボトルネックになりかねません。
そうならないためにも、ある程度受け取ったデザインを妥協せずに形にできるスキルがあるか？なければノーコードツール（NotionやSTUDIO）などを利用することも検討してみてもいいかもしれません。
考察
ここまでLPを制作したプロセスを細かく紹介してきましたが、最後に結局何が良かったのか？を自分なりに考察して終わろうと思います。
（まず前提として、前回のLPが初期リリースだったということもあって大きな課題感「採用時のミスマッチ」とソリューション「コーディング試験サービス」という事以外の情報を載せていなかったため、圧倒的に情報量が少なかったということを先に白状しておきます。）
言ってしまえばそのとおりですが「興味のある人がLPに訪れたときの情報設計を整えられた」に尽きるかなと思います。
前述のプロセスを通して徹底的にヒアリングを行った結果、「顧客と同じ言葉で課題を語れるようになった」ことは非常に大きいと感じており、話を聞いたときにそれがどのように起こっているかをなんとなく想像できるようになりました。
自分が対象の顧客だったとして同じ悩みを持った状態でLPに遷移したときにどう情報が組み立てられていると読み進みてもらえるかを考えて文章を組み立てました。
以下LPの情報の組み立てを概要化したものです。
- まずぱっと何のサービスなのかが分かる
- 具体的なシーンとともに課題感に共感してもらう
- 利用イメージをざっくり理解してもらう
- HireRooの提供するソリューションでそれがどう実現できるのかを把握してもらう
- 利用までのプロセス（使えるまで長いのか短いのか）と疑問になりそうなことの列挙
- お問い合わせ
このように対象顧客が必要としている情報を、処理する順番に列挙してあげたことによって納得してお問い合わせをしてきてくれている（のだと思っています）。
まとめ
長文を最後までお読みいただきありがとうございました。 今回のLPのリニューアル時に僕らがやってきたプロセスを共有し、なぜきちんと効果が出たのかということの考察をしました。
顧客の声を聞くという意味でヒアリングはとてもいい方法ですが、ヒアリングの質を高いものにするために事前準備は欠かせず、これを疎かにすると結局何がしたかったのか分からず時間を無駄にしてしまいかねません。 また言われたことだけを鵜呑みにすると自分たちが相手の意見で振り回されることにもなりますので、しっかりと目的を忘れないようにすることが大事です。
LPはリリースして終わりというようなものでもないので、今後フェーズに応じてアップデートは逐次行っていきます。またその際に有益だと思うことがあれば記事にまとめる予定です。
本文内でも言及したような課題を解くべく会社の規模問わず簡単に導入できるSaaSとして『HireRoo（ハイヤールー）』というプロダクトを3月にβリリースしました（プレスリリース）。このサービスを通して少しでも日本のエンジニア採用にコーディング試験が根付き、より明瞭なエンジニア採用が実現できると私達は信じています。
もしご興味を持たれた方や、課題感に共感された方がいれば是非お気軽に弊社LPからお問い合わせ下さい。それではまた！