なぜDevRelは採用につながらない？信頼設計の始め方 

エンジニア採用に手を尽くしても成果が出ず、DevRelという言葉に可能性を感じている方も多いのではないでしょうか。採用競争が激しさを増すなかで、技術発信やコミュニティづくりに取り組む企業は増えていると言われています。ただ、施策を始めても採用につながらず、現場だけが疲弊していくケースも少なくありません。この記事では、DevRelが採用に結びつかない原因を整理し、限られたリソースで始めるための優先順位をお伝えします。エンジニアと向き合ってきた立場から見えてきた実践の視点を凝縮しました。読み終える頃には、自社が次に踏み出す一歩が明確になっているはずです。

１、DevRelが採用に効くと言われる理由とよくある誤解

エンジニア採用の難易度は、年々高まり続けています。情報処理推進機構（IPA）の調査では、DXを担う人材の不足が近年さらに深刻化していると報告されています（＊）。様々な採用手法を試しても人材と出会えない企業が増えるなかで、注目を集めているのがDevRelという取り組みです。ただ、言葉が広まる一方で、期待と実態のあいだにずれが生じている場面も見られます。まずはDevRelの前提を整理し、よくある誤解を解いていきます。

＊ 参考：情報処理推進機構（IPA）「DX動向2024 - 深刻化するDXを推進する人材不足と課題」2024年

（１）DevRelとは何か——採用広報との違いを整理する

DevRelは「Developer Relations」の略で、企業と社外のエンジニアが良好な関係を築くための活動を指します。技術ブログの発信、勉強会やイベントの開催、コミュニティ運営などが代表的な取り組みです。

似た言葉に「技術広報」や「採用広報」があります。技術広報は自社の技術力を広く社会へ伝える情報発信が中心です。採用広報は、採用を目的にした情報発信を指します。これに対してDevRelは、発信するだけでなく、エンジニアからのフィードバックを受け取る双方向のやりとりを重視します。

つまりDevRelは「伝える」よりも「関係を築く」ことに軸足を置いた活動です。この違いを押さえておくことが、後の判断を大きく左右します。

関連記事▶︎エンジニア採用広報とは何か？役割と始め方を徹底解説

（２）「DevRelをやれば採用できる」が空回りする理由

DevRelへの関心が高まる背景には、採用への期待があります。エンジニアの転職潜在層は求人媒体を積極的に見る習慣が薄く、従来の広告やスカウトだけでは接点そのものをつくりにくいという事情があります。

エンジニアは日常的に多くの情報に触れており、宣伝色の強いメッセージには反応しにくい傾向もあります。だからこそ、発信や対話を通じた関係づくりに期待が集まっているのです。

ただ、DevRelは本来、採用だけを目的にした活動ではありません。開発者コミュニティとの信頼関係を築くことが土台にあり、採用はその結果として生まれるものです。順序を取り違えると、活動が空回りします。

例えば、採用したい気持ちが前面に出たイベントは、参加したエンジニアに「宣伝の場だ」と受け取られがちです。発信の一つひとつが求人色を帯びると、かえって距離を置かれてしまいます。採用を急ぐほど採用から遠ざかる、という逆説が起きるのです。

２、スタートアップのDevRelが採用に結びつかない3つの原因

DevRelに取り組み始めたものの、成果が見えないという声は少なくありません。とりわけ人員に限りのあるスタートアップでは、つまずき方に共通のパターンがあります。採用に結びつかない代表的な3つの原因を整理します。

関連記事▶︎スタートアップのエンジニア採用が難しい理由と突破口　

（１）施策を増やしすぎて現場が疲弊する

DevRelの施策は多岐にわたります。テックブログ、登壇、SNS発信、勉強会の主催と、挙げればきりがありません。すべてに手を出すと、担当者と現場エンジニアの負担だけが積み上がります。

例1）ブログとイベントとSNSを同時に始めたものの、更新が止まり、中途半端な状態で放置される。

例2）現場エンジニアが本業の合間に発信を任され、開発に集中できなくなる。

いずれも、意欲があるからこそ手を広げすぎてしまうパターンです。始めた施策を減らす判断は、増やす判断よりも難しいものです。

施策の数は成果に比例しません。限られた時間をどこに注ぐかを決めることが、近道になります。

（２）成果を「採用数」だけで測ってしまう

DevRelの成果を採用人数だけで測ると、活動は長続きしません。関係構築には時間がかかるため、短期の採用数では効果が見えにくいからです。

数字が出ないと、活動そのものが「意味がない」と判断されてしまいます。本来は、発信への反応、イベント参加者との継続的なつながり、社外での認知の広がりなど、途中段階の変化にも目を向ける必要があります。

例えば、勉強会に毎回顔を出してくれるエンジニアが増えることは、採用にはまだ至らずとも確かな前進です。こうした兆しを拾える指標を持つことが、活動を支えます。

（３）エンジニアを発信の「手段」にしてしまう

DevRelの担い手は、多くの場合、現場のエンジニアです。その知見や人柄が、発信の説得力を生みます。ただ、発信を「やらされる業務」として割り当てると、内容は形式的になり、読み手にも伝わってしまいます。

エンジニアは一人の専門家であり、その時間と関心は尊重される必要があります。発信を強制するのではなく、本人が語りたいテーマを起点にすることが欠かせません。

例えば、担当した技術的な課題や試行錯誤の過程は、当人が最も語りやすく、読み手の共感も得られやすいテーマです。書きたいことと伝えたいことが重なる地点を探すと、無理のない発信につながります。

３、DevRelを「エンジニアとの信頼関係の設計」として捉え直す

3つの原因に共通するのは、DevRelを採用の手段として狭く捉えている点です。視点を変え、DevRelを「エンジニアとの信頼関係を設計する取り組み」として捉え直すと、進め方が見えてきます。

関連記事▶︎エンジニア採用の成功事例に学ぶ共通点と実践法

（１）目的は採用広報ではなく継続的な関係づくり

信頼関係は、一度の接触では生まれません。発信を続け、対話を重ね、少しずつ「この会社は開発者を大切にしている」という印象が積み上がっていきます。積み重ねが、いざ採用の機会が訪れたときに効いてきます。

採用を目的の中心に置かず、関係づくりそのものを目的にすることが、結果的に採用の土台を厚くします。急がば回れ、という言葉がよく当てはまります。

例えば、自社のエンジニアが技術記事を継続的に発信していれば、転職を考えていない層にも「開発者を尊重する会社」という認識が広がります。認識が、将来の応募や紹介の入口になります。

（２）信頼が採用に変わるまでの時間軸を理解する

DevRelは、着手してすぐに採用成果が出る施策ではありません。数か月から年単位で信頼が育ち、その先で採用につながっていきます。

成果が出るまでの時間軸を経営層と共有しておかないと、途中で「成果が出ない」と打ち切られてしまいます。始める前に、短期の採用ではなく中長期の関係構築が目的であることを、社内で合意しておくことが重要です。

期待値をそろえておけば、途中段階の小さな変化も前進として評価できます。時間を味方につける前提が、DevRelを継続させる支えになります。

例えば、活動開始時に「1年目は認知の広がりと関係づくりを見る」といった目標を経営層と共有しておく方法があります。評価の物差しを先に決めることで、短期の採用数に一喜一憂せずに済みます。

４、最小工数で始めるDevRel——施策の優先順位

限られたリソースで成果を出すには、何から始め、何をやらないかを決めることが欠かせません。少人数でも回せる優先順位を示します。

（１）最初に着手すべきは「社内の発信」から

最初の一歩は、社外イベントではなく社内の発信からがおすすめです。自社の開発文化や技術的な取り組みを言葉にすることから始めます。

なかでもテックブログは、社内のエンジニアだけで始められ、記事が蓄積されるほど検索経由での認知にもつながります。外部の会場や集客が不要なため、少人数でも継続しやすい施策です。

例えば、日々の開発で得た知見や、採用した技術の選定理由を記事にするだけでも、自社の姿勢が社外に伝わります。まず社内にある素材を発信に変えることが、無理のない出発点になります。

（２）次に広げる「社外との接点」の選び方

社内の発信が回り始めたら、社外との接点を少しずつ広げます。勉強会やコミュニティは数多くありますが、すべてに参加する必要はありません。

選ぶ基準は、自社の技術領域と重なるかどうかです。自社と近い技術を扱う場に絞ることで、出会うエンジニアとの関係も深まりやすくなります。

例えば、自社が使う言語やフレームワークのコミュニティに、まず登壇ではなく参加者として加わってみる方法があります。宣伝を持ち込まず、一人の技術者として交わることが、信頼の入口になります。

（３）「やらないこと」を決めるリソース配分の判断

優先順位づけで最も重要なのは、やらないことを決める判断です。すべての施策を追うと、どれも中途半端になります。

自社のフェーズで効果の薄い施策は、思い切って手放す判断が必要です。大規模なカンファレンスの主催や動画配信などは、体制が整ってから検討すれば十分です。

例えば、担当者が一人しかいない段階では、発信の場をテックブログとひとつのコミュニティに絞る、といった割り切りが有効です。やることを減らすほど、一つひとつの質が上がります。

５、正社員以外のエンジニアとの関係もDevRelの射程に入れる

DevRelというと正社員採用の文脈で語られがちですが、関係を築く相手は正社員志望のエンジニアだけではありません。視野を広げると、採用の可能性も広がります。

（１）フリーランス・業務委託との接点が母集団を広げる

技術コミュニティには、フリーランスや副業として活動するエンジニアも数多く参加しています。正社員の求人には反応しない層も、対等な関係であれば接点を持てます。

DevRelを通じて築いた信頼は、こうした層との協働の入口になります。正社員志望に限定しないことで、出会えるエンジニアの母集団は大きく広がります。

例えば、勉強会で知り合ったフリーランスのエンジニアに、まず業務委託で開発を依頼するという関係の始め方があります。求人という入口だけに頼らない選択肢です。

関連記事▶︎フリーランスエンジニア採用を戦略的に使う方法と進め方

関連記事▶︎副業エンジニアを業務委託で採用する方法と契約の注意点

（２）関係構築から始まる採用という選択肢

業務委託で協働したエンジニアとは、実際に一緒に働くなかで相互理解が深まります。関係が育てば、正社員として迎える道も自然に開けてきます。

いきなり選考で見極めるのではなく、協働を通じて互いを知ったうえで採用に進む。この流れは、ミスマッチを抑えるうえでも理にかなっています。DevRelで築いた信頼が、こうした採用の土台になります。

書類や面接だけでは分かりにくい仕事の進め方や価値観も、一緒に働けば自然と見えてきます。エンジニアの側も、社内の雰囲気を確かめたうえで意思決定できるため、双方にとって納得感のある採用になります。

エンジニアと企業が直接つながり、関係を育てながら採用へ進める仕組みとして、re:shineのようなトランジション採用の仕組みを整えたサービスを活用する方法もあります。関係構築を起点にした採用は、DevRelの考え方と自然に重なります。

関連記事▶︎正社員採用に行き詰まった企業こそ試したいトランジション採用とは？

６、まとめ：急がば回れ、DevRelは信頼から始まる

DevRelは、採用のための発信術ではなく、エンジニアとの信頼関係を設計する取り組みです。採用を急ぐほど遠ざかり、関係を丁寧に育てるほど採用の土台が厚くなります。根底にあるのは、エンジニアを一人の専門家として尊重する姿勢です。まずは社内の発信から始め、やらないことを決めながら、無理のない範囲で接点を広げてみてください。正社員という枠にとらわれず、フリーランスや業務委託も含めて関係を築くことで、出会いの可能性は大きく広がります。今日の小さな一歩が、半年後、一年後の採用につながっていくはずです。