エンジニア採用でスカウトより先にやるべきこと

「エンジニアみんなでスカウトメール打ちましょう」をやって、成果ゼロだった経験がある。なぜ失敗したのか、構造的に整理する。

スカウトを打っても返信が来ない理由

候補者の行動を考えると明確になる。

1. スカウトが届く
2. 「どんな会社だろう」と調べる
3. テックブログもない、エンジニアの発信もない、中が見えない
4. 「よく分からないから返信しない」

スカウトの数を増やしても、着地先（＝この会社で働くイメージ）が空っぽなら意味がない。 水をいくら流しても、受け皿がなければ溜まらない。

エンジニアに頼む仕事が間違っている

エンジニアにスカウトを打たせるのは、シェフに客引きをさせているようなもの。

やらせたこと	エンジニアの本来の強み
スカウトメールを書く（営業行為）	自分の仕事について語る（自然な行為）
見知らぬ人に声をかける	技術選定の理由、苦労、学びを共有する
返信率という数字を背負う	「うちはこうやってる」を言葉にする

エンジニアに協力を求めるなら「スカウト打って」ではなく 「最近やった仕事で面白かったこと 30 分話して」 のほうが成果に繋がるし、本人の負荷も低い。

順番が逆

× スカウト打つ → 返信来ない → 成果ゼロ → もうやりたくない

○ 現場の学びを言語化（受け皿を作る）
  → 候補者が「この会社面白そう」と思える状態にする
  → その上でスカウトを打つ
  → 返信率が上がる

採用発信の失敗パターン

よくある失敗は 3 つ。

• 当番制の義務化 — 書き手は最低限で済ませ、品質が落ちる
• 指示と丸投げ — テーマも目的も示さず、書ける人だけが書く属人化
• 短期成果の期待 — 数本の記事で応募改善を求めるのは非現実的。発信は信頼醸成の中期活動

VPoE が発信に熱がない場合

記事の理想論は「VPoE が翻訳者になれ」だが、現実にはドキュメント作成に関心が薄い VPoE もいる。

その場合は VPoE 自身が書く必要はない。仕組みに予算と権限を付ける だけでいい。

VPoE の状態	打ち手
発信の価値は理解しているが自分では書きたくない	翻訳者を別に立て（EM・DevRel・外部ライター）、VPoE は承認・支援に回る
採用には関心があるが発信との接続が見えていない	採用 KPI の悪化原因として発信不足を数字で示す
採用自体に熱がない	経営が VPoE の評価に採用成果を組み込む（組織設計の問題）

発信が機能する組織の条件

• 大型リリース直後、障害対応後、アーキテクチャ決定後など 「熱がある瞬間」を逃さず言語化する習慣 がある
• 技術知識ではなく「なぜその技術を選んだか、何を重視し、どう乗り越えたか」という 文脈 を伝えている
• 発信への反応が見える化されている（社内共有、採用効果のフィードバック）

まとめ

採用は条件競争ではなく不安解消。候補者は「入社後を想像できる会社」を選ぶ。発信はその想像材料を作る行為であり、スカウトより先に整えるべきインフラ。

エンジニアに求めるのは「書くこと」ではなく「語ること」。語った内容を記事に変換する仕組みを作るのが、VPoE の仕事。

参考

• エンジニアが発信しない会社の採用が負け続ける理由 — VPoEが見落としている「感情」と「構造」の本質