DevRel

一言でいうと

社外の開発者との関係づくりを担当する職種で、自社の技術を伝え、実際に使ってもらい、その反応を製品側へ戻します。

この職種の出自と登場時期

背景にあるのは、開発者が技術を選ぶようになったことです。API・SDK・クラウドサービスが増え、購買の決定権が経営から現場の開発者へ移った領域では、営業ではなく技術者どうしの信頼が採用の決め手になります。この関係を作る職務として DevRel が形になりました。

コミュニティとして輪郭ができたのは2015年前後です。DevRelCon を運営する Hoopy は2015年から活動しており、実務者が手法と評価の考え方を共有する場ができました。DeveloperRelations.com のような実務コミュニティもこの時期に整備されています。

国内では2017年前後から、API を外部提供する企業とクラウドベンダーを中心に置かれるようになりました。日本語では「デベロッパーアドボケイト」「技術広報」と呼ばれる場合もあり、担当範囲は会社ごとに異なります。

ミッション

責任範囲は、開発者から自社の技術が信頼され、選ばれる状態をつくることです。イベントの登壇回数や記事の本数ではなく、開発者が実際に使い始め、使い続けているかで評価されます。

同時に、この職種は一方向の発信ではありません。コミュニティで聞いた不満と要望を製品側へ戻す経路を保つことが、長期の信頼につながります。

主な業務範囲

• 技術的な発信。ブログ記事、サンプルコード、チュートリアルを作成して公開する
• イベントとコミュニティの運営。登壇、勉強会、ハッカソンを企画して実施する
• 開発者の支援。フォーラムや SNS での質問に答え、詰まりどころを解消する
• 製品へのフィードバック。現場で得た要望を整理し、優先度をつけて製品チームへ渡す
• 効果の測定。導入数、ドキュメントの閲覧、コミュニティの活性度を追う

求められる能力

前提になるのは、自社の技術を自分で使って動かせることです。サンプルコードを書き、質問に技術的に答える必要があり、実装の経験がないと信頼を得られません。

日常の仕事は、書く力と話す力に支えられます。加えて、売り込みにならない距離感を保つ姿勢が問われます。開発者コミュニティは営業色の強い発信に敏感で、信頼を失うと回復に時間がかかります。

この職種に就く人のキャリア経路

多いのは開発エンジニアからの移行です。技術記事や登壇を続けていた人が、その活動を職務として担う流れが一般的です。技術広報やマーケティングから、技術を学んで移る例もあります。

DevRel 組織の責任者に進む道と、プロダクト側へ移る道があります。後者ではプロダクトマーケティングや Technical Product Manager が移り先です。

隣接職種との違い

採用担当の見極めポイント

• 求人票では、目的を明記してください。製品の利用者を増やすのか、採用ブランディングかで、必要な経験と評価指標が異なります
• 職務経歴書を見るときは、発信の実績と、それが利用につながったかを確認してください。登壇回数だけでは成果を判断できません
• 評価指標を募集前に決めてください。数字にしにくい職務のため、基準がないまま採ると評価で揉めます

求人・市場の傾向

国内の母集団は薄く、この呼称で経歴を書いている候補者は限られます。職種カテゴリを持たない媒体も多く、検索の件数は母集団の厚みを表しません。技術記事・登壇資料・OSS への貢献から候補者を探す進め方が中心で、媒体での検索は補助的な位置づけになります。

対象となる製品、開発者コミュニティの現状、活動の裁量。とくに裁量の範囲は、この職種の候補者が最初に見る箇所です。

関連キーワード

デベロッパーアドボケイト / 技術広報 / コミュニティ / 技術記事 / 登壇 / OSS / ドキュメント