0から始めるエンジニア採用広報〜もしくは人に認知してもらうということ〜

こんにちは kotamat です。
ROXX（旧SCOUTER）という会社にてCTOをやっております。
僕は2年前の4月にCTOとして入社し、エンジニアリングも行いつつ、ある一つの軸に基づいたエンジニア広報を行っておりました。2年以上経過し、おかげさまで優秀なメンバーを採用することができ、一つの体系化が実績を伴った形に昇華できたため、今回記事を書くことにしました。
1万文字以上の長編となってしまいましたが、2年間やってきたすべてを記載しているので、内容としては知見に富んだ内容となっていると思います。

※記事内でSCOUTERという旧社名を使っていますが、SCOUTERと言う開発組織としてのブランディングを行ってきたためなので、あえて旧社名で記載しています。

現状のROXX開発メンバー

- 開発組織の人数は執筆時点で20名(正社員、業務委託含め)、稼働量が週3以上のメンバーは16名
- 過去3ヶ月において、入社承諾を得たのはエンジニア5名、デザイナー1名。それぞれ技術力・リファレンスチェック・選考においての評価は高く、非常にレベルが高い。(選考プロセスにおいては後日別記事にします。)
- 大規模カンファレンスへの登壇、WEB+DB PRESS(隔月6万部出版の技術雑誌)への連載、月6件程度のブログ発信、毎月ペースでの勉強会開催や登壇等会社全体で情報発信を行っている。

想定読者層

- エンジニア採用が激化している中で、技術力を妥協して採用を行おうか考えている採用担当
- 事業ドメインが複雑かつイメージが付きづらく、ビジネス面では認知形成に限界がある事業を行っている企業
- 技術組織をどのように作ればいいか悩んでいるCTO
- 優秀な人を採用しようと思っているが、なかなか実現できていない人
- 技術ブログなどをやってみたはいいものの、継続させられておらず、形骸化してしまっていることに課題を感じている人
- 技術面での口説き文句が無い組織責任者
- エンジニアに限らない採用広報に軸がなく、行き当たりばったりの施策で苦労している人

この記事の着地点

- 自分たちなりの技術広報の方向性がイメージでき、明日からアクションが取れる
- 各種技術広報の手段の活用目的を明確化でき、適切に取捨選択できるようになる

入社当時の状態

入社当時はSCOUTERという単一事業のみを行っておりました。こちらは有料職業紹介事業者の免許を保持していない個人「人材紹介を誰でもできるようにする」という事業です。事業自体の新規性は非常に高く、人材紹介業の方々やベンチャー界隈には一定の認知を形成できておりましたが、エンジニアにとってはエージェントを使わずとも自分で転職先を探すことができる状態であり、エージェント業界における課題をイメージするどころか、エージェントとコンタクトを取ったことすら無い人が多い状態で、ビジネス面での認知は非常に難しい状態でした。プロダクト自体も審査制のサービスであり、興味を持った人が気軽にプロダクトを触れる状態ですらありませんでした。
また、入社数カ月後に始まったSARDINEにおいては「エージェント向けプラットフォーム」であり、より一層エンドユーザからは遠く、こちらも月額課金ユーザでないと内部のシステムは見られず、プロダクトの良さは一切伝えられる状況ではありませんでした。

また僕自身、どこかのCTOをやっていたわけでも、有名だったわけでもなく（Twitterのフォロワーは100人以下）、前職自体もWebエンジニア認知は無かったため巨人の方にも乗れなく、有名人とのつながりも皆無の状態で、すでにある資産を用いてポジショニングを行うのは非常に難しい状態でした。

幸いにも当時から経営陣は「プロダクトで勝っていく」という思想で事業の将来を考えており、開発陣の増強自体はポジティブな考えがあったため、そういった方向に動いていくことに関しては寛容ではありました。ただ彼ら自身もどのようにすれば認知を形成できるのかはイメージできてはおらず、結果が出ていない時期は「本当にこれを継続する意味はあるの？」という状態でありました。

また使用している技術がLaravelとVue.jsといった、当時ではかなり前線を行っている技術スタックで開発をしており、決してエンジニアにとって開発し辛い状況ではなかったため、方法次第ではどうにかエンジニアを引きつけることはできるのではないかという期待は持っておりました。

まとめると
- プロダクトを見せることで事業の有用性を説明するのは困難
- エンジニア界隈の著名人や巨人の方に乗って広報することも困難
- 経営陣がプロダクト思考であり、人を採用する方向においてはポジティブ
- 使用している技術スタックはポジティブ
という状態でした。

広報戦略で意識したたった一つの軸

僕は前職での経験から「エンジニアは量ではなく質である」という考えがあり、特に技術面においては妥協をしない方針で採用したいという考えがありました。
ただ、そう入っても上記状況下です。エンジニア採用倍率は8倍以上、特にWeb系は一極集中型の総取り状態であり、認知が形成できていない企業では数倍数十倍どころの倍率ではないでしょう。そういった中でこちらがエンジニアを選ぶというのは非常に難しい状態であり、僕自身採用に責任を持っていながら妥協ラインを探さざるを得ない状況が長く続きました。

僕はその状況下でもぶらさず一つの軸で広報活動を行っておりました。
それは

「あるカテゴリで１位を取り、クロスメディア戦略を駆使して〇〇といえばSCOUTERだよねという認知を取る」

という軸です。僕は下記の本を参考にしました。

売れるもマーケ 当たるもマーケ―マーケティング22の法則

こちらにある「カテゴリーの戦略」「集中の法則」がまさしくこの軸に沿っているものであり、広報戦略においては非常に重要な法則であると認識しております。

カテゴリの戦略とは？

書籍には「あるカテゴリで一番手になれない場合には、一番手になれる新しいカテゴリを作れ」と記載されております。
よく聞くたとえ話に、「日本一の高い山は？と聞かれ「富士山」とは答えられるが、二番目に高い山は？三番目四番目…と聞かれるとわからない」というのがあります。認知という点において二番手以降は「その他」というカテゴリであり、認知においては失敗です。そういった場合は「その他」にならない一番を取れるカテゴリを見つけ出し、一番を取る必要があります。

集中の法則とは？

書籍には「マーケティングにおける最も強力なコンセプトは、見込み客の心の中にただ一つの言葉を植え付けることである。」とあります。
僕らが使っている技術は少なくとも特定のフレームワークで言葉を植え付けられるものではなかったわけですが、とにかく上記カテゴリにおいて「どういった言葉で認識されるか」は非常に重要視していました。

「LaravelとVue.jsを使っている会社といえばSCOUTER」を作る

Laravel、Vue.jsはそれぞれ弊社で使っている技術スタックです。それぞれのフレームワークにおいては、一定数のメンバーが参加しているコミュニティーがすでに存在しておりました。すでにコミュニティーが存在している中で、そこだけの認知を作っていくのは上記法則から非常に困難です。ただ後ほど紹介しますが、調べていく中で、LaravelとVue.jsを双方使っている会社やエンジニアが多いことに気づき、またLaravel自体がVue.jsを公式にサポートするという流れも有り、Laravel、Vue.jsを組み合わせたカテゴリにおいては、現状だれもポジションを取っていない上に市場性もあると言うところで、コレを追うべきカテゴリと定義しました。

どのように実現していくか

では具体的にどのように実現していったのか、今から自分が0からやるならどうするかという観点から実例を元に説明していきます。

順番は下記となります。それぞれにおいて適切な役割の人を記載しておりますが、特にスタートアップの場合はメンバーが揃っていないこともあるので、その場合はCTOがやっていくのがいいかなと思います。ちなみに弊社の場合はすべて僕が行ったので、一人でやるのは不可能ではないと思います。

1. 理想の組織像を定義する
2. 共通のアイデンティティーを定義する
3. ターゲットが見ているものを知る
4. 一貫した発信を定期的に行っていく
5. 面接の最初で正しく伝える