devrel-hiring

DevRel 採用

この分野の採用調査が推奨する厳密さで、採用担当者が DevRel の採用に必要とする4つの成果物を作成します。役割のスコアカードと募集要項、質問バンク付きの構造化された面接プロセス、ポートフォリオと実務サンプルの評価、そして30-60-90日の立ち上がり計画です。

CNCF CTO の Chris Aniszczyk によると、DevRel には標準的な職務記述書もキャリアラダーもありません。また、DevRel 独自の採用に関する文献では、このような規律を欠いた募集要項に見られる、名前の付いた2つの失敗パターンが記録されています。詳しくは「回答を読む」を参照してください。こうした標準がないからこそ、一般的なエンジニアリングやマーケティングの採用テンプレートを流用するのではなく、これら4つの成果物を意図的に作成します。

対象外の項目は、代わりに以下へ引き継いでください。

• DevRel のレポートラインとチームの編成方法 - samber/developer-relations-skills@devrel-team-structure で、採用する前に組織体制を決めます。
• 候補者のコーチング - samber/developer-relations-skills@devrel-career は、このスキルの対になるもので、評価を受ける人のために作られています。

ユーザーが採用ではなく求職中（「DevRel の面接に向けてどう準備すればよいですか」「この募集に応募する価値はありますか」など）の場合は、その旨を一文で伝え、devrel-career を案内してください。

面接

一度に質問は1つだけにし、可能な場合は選択式にしてください。すでに回答済みの質問は省略してください。質問8〜10では、下記の成果物を作成する前に優先順位を付け直します。何かを作成する前に、これらの質問をしてください。

メモリ：現在のタスクやプロジェクトのコンテキストに関する情報を少し保存してください。メモリをファイルに保存する場合は devrel-context.md を使い、別のメモリシステムを使用している場合はそちらを利用してください。タスクごとに情報を別々のセクションにまとめてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトコンテキストには日付を付けないでください。タスクによって面接の回答が異なる場合があります。

1. 会社の種類：（a）アーリーステージのスタートアップ、プレシード〜シリーズAで、チームはこの職種の1名のみ（b）成長企業／スケールアップ、シリーズB〜D（c）大手テクノロジー企業（d）オープンソースを第一とする企業または財団。
2. 採用する役割：（a）デベロッパーアドボケイト、アウトリーチ重視（b）デベロッパーアドボケイト、プロダクト重視（c）コミュニティマネージャー（d）デベロッパーエデュケーター（e）DX エンジニア（f）未定 - 資金提供の主な目的から推奨する。
3. この職種の予算を支える目的は何ですか：開発者による採用、営業支援、開発者支援、プロダクトへの意見提供、エコシステム／パートナーシップ、コントリビューターコミュニティ、または雇用主ブランディング？
4. Go-to-market の進め方：営業主導の B2B、プロダクト主導（PLG）の B2B、B2C／個人向け、または購入を前提としないオープンソース／財団？
5. コーディングの深さに関する要件：この職種では SDK のサンプルを作成し、API 設計をレビューする必要がありますか。それとも、軽いコーディングで公開コミュニケーションができれば十分ですか？
6. チームの段階：比較対象となる既存メンバーがいない、初めての DevRel 採用ですか。それとも、既存の優秀なメンバーを参考に人物像を定める、再現性のある採用ですか？
7. 報酬に関する方針：募集要項に給与レンジを掲載しますか。また、採用対象地域の給与透明性に関する要件を把握していますか？
8. 期限：今月中、今四半期中、または特に期限なしですか？
9. 今回限りの採用ですか。それとも、スコアカードと質問バンクを再利用する、複数名採用の最初の1名ですか？
10. 労力の上限：候補者1人あたり、面接担当者の工数は何時間までですか。また、採用担当者や訓練済みの面接パネルはいますか？

回答の読み取り方

• Q1で基準とポートフォリオの比重が決まります - references/company-type-and-driver-lookup.md を読み込みます。スタートアップでは、その役割自体の存在意義を説明できるゼネラリストを採用します。大手テック企業では、エンジニアリングの等級尺度に照らして役割の基準を定めます。OSS／財団での役割では、コミュニケーションの洗練度ではなく貢献実績を審査します。
• Q2 + Q3で、求人が審査する対象が決まります - 役割ごとの要件表については、references/company-type-and-driver-lookup.md を参照してください。目標とするサブロールを明言できない候補者は、すべてに応募して何にもマッチしていないのと同じです。必要なサブロールを明言できない求人についても同様です。
• Q3 + Q4で柱の配分が決まり、ひいては役割の評価指標が決まります：営業主導型はアドボカシーと営業支援を重視し、PLGは支援とプロダクトへの意見提供を重視します。B2Cはコミュニティとリーチを重視し、OSS／財団はコミュニティとアドボカシーを重視します。
• 求人票を作成する前に、この分野で知られる2つの失敗パターンに照らして自己監査します（Joe Nash、DevRelCon 2021 - devrel-careerが候補者に外部から見分けるよう教えているのと同じ分類です）。
  • Gatekeeper - 実現不可能な人物像を描くことです。複数の技術スタックでエンジニアとしてのキャリアを積み、OSSへの貢献、テクニカルライティング、コミュニティ構築、イベント運営もこなす人を、初級者向けの給与で募集します。
  • Pit trap - 「経験不問のDevRel立ち上げ担当」としながら、実際にはリソースもキャリアラダーも明示された目標もない状態で、ドキュメント、SDK、コミュニティ、サポート、セールスエンジニアリング、トレーニングを一人に担わせることです。
  • どちらにも、共通する兆候が3つあります。中核業務から外れたスキルの重視、成果が明記されていない施策のリスト、給与と整合しない職位設定です。いずれかの兆候に当てはまる求人は、応募者を獲得できずに失敗してからではなく、公開前に書き直す必要があります。
• Q6で候補者のプロファイルが決まります。 初回採用：既存チームがなくてもその役割の存在意義を説明できる構築者です。企業で初めて採用する営業担当に似ており、専門分野の深さよりも自律性と幅広さを重視します。継続的な採用：この役割が実際に担う柱で、自社の優秀な人材をもとにプロファイルを定めます。
• Q7で、以下の品質ゲートにある報酬に関する確認が必要になります - 各地域の法的要件を決して推測せず、公開前に採用地で現在適用されている給与透明性の規則を確認してください。
• Q8で、すぐに実行できる選択肢を優先します：今月中が期限なら、新たにカスタムのワークサンプルを一から設計するより、既存の質問バンクを再利用し、選考プロセスを短縮することを優先します。
• Q9で、ワークサンプルを簡素に保つかどうかが決まります。 一度きりの場合：一度だけ、低コストで設計します。継続的に採用する場合：確定した評価基準と質問バンクを、この柱で今後採用するすべての候補者に活用できるため、まず両方をきちんと整備することを優先します。
• Q10では、選考段階の順序を入れ替えるのではなく、段階そのものを削除します。 候補者一人あたりの面接官の稼働時間が数時間しかない場合は、評価表、構造化された対話形式の面接を1回、ポートフォリオ評価に絞ります。採点なしで実施するくらいなら、ライブのワークサンプルは完全に省略します。

ワークフロー

4つの成果物を順番に作成します。それぞれを提示し、ユーザーの確認を得てから次に進みます。

1. インタビューを実施します。役割と、柱の組み合わせに関する推奨案を、ユーザーが却下できるよう短い段落で示します。
2. 成果物1 - 役割スコアカードと募集要項。 references/company-type-and-driver-lookup.md と references/scorecard-and-posting-template.md を基に作成します。
   • Q3の資金調達要因を明記した、1文のミッション
   • 重要度順に並べ、定量化した3～8個の測定可能な成果（例：「公開した摩擦ログの修正により、上位3件のオンボーディング関連サポートスレッドを25％削減する」「初年度にコミュニティから採択済みCFPを40件獲得する」）。曖昧な責務は含めません
   • Q1～Q2の役割と企業タイプに応じて重み付けした5～7個のコンピテンシー
   • 公開前に、上記のゲートキーパー／落とし穴のセルフ監査を実施します
3. 成果物2 - 面接プロセスと質問集。 references/interview-loop-and-question-bank.md を基に作成します。
   • 対象分野で実績が確認されている形式から3～5個を選びます（プレゼンテーション面接、コンテンツ課題、コーディング課題、技術的な自己評価、対話形式の面接、DevRel に関する意見を問う面接、スタートアップでの創業者／幹部との面接）。標準の面接プロセスはないため、既定で全形式を採用するのではなく、この役割に必要な柱の組み合わせを実際に評価できる形式を選びます
   • 候補者に新たな作業を依頼する前に、ポートフォリオ評価（成果物3）を早い段階で実施します
   • 参照ファイルのカテゴリ別質問集から、スコアカードの各コンピテンシーにつき2～3問を作成し、DevRel に関する意見を問う質問を少なくとも1問含めます。候補者は、暗記した答えが通用しないため、これを最も難しい面接だと報告しています。まさにその点が、職務への適性と、準備した売り込み文句とを見分けます
   • 評価の仕組みを定義します。各面接担当者は、デブリーフの前に、証拠に基づくメモを添えて独立に採点します。その後、事前に設定したスコアカードの重みに照らして機械的に集計します。これは、構造化され、独立して採点され、機械的に集計された面接は、非構造化面接や総合的なデブリーフより優れた成果を上げるという、一般的な採用選考の知見です。DevRel に特有の知見ではありませんが、分野固有の要素がないため、直接応用できます
   • 公開ポートフォリオがすでにある場合、無報酬の課題制作は決して依頼しません。代わりに、有償のライブ作業セッションを提案します
4. 成果物3 - ポートフォリオと実務サンプルの評価。 references/portfolio-and-work-sample-scoring.md を基に作成します。
   • 6つのシグナルの分布評価基準（公開文章、公開講演、公開コード、コミュニティでの実績、教育用成果物、開発者向けの表現を用いた成果物）に照らして、候補者が公開・提供した実績を採点します。Q2の対象サブロールに応じて重み付けします。評価基準の全容と採点基準は devrel-career にあり、このスキルでは評価者の立場から適用します
   • ポートフォリオが不十分な場合や、候補者がこの分野に入ったばかりの場合は、履歴書だけで判断せず、採点対象となる有償の実務サンプルを設計します。対象サブロールに合わせて、短いライトニングトーク、ドキュメント編集演習、または「このAPIの変更を開発者に説明する」演習などを実施します
   • フォロワー数はあるが実質的な内容がない、自己宣伝しかない、公開したコードがない、支援した開発者の名前を挙げられない、といったネガティブなシグナルがあれば、欠けている点を挙げるだけでなく、明示します
5. 成果物4 - 30・60・90日の立ち上がり計画。 references/ramp-plan-template.md を基に作成します。
   • 0～30日目：新入社員が開発者の視点でプロダクトを使い、摩擦ログを公開します。これは devrel-career がポートフォリオ用の成果物として推奨するものと同じで、ここでは最初の30日間の納品物とします
   • 31～60日目：チームの既存メンバーと組み、対象の柱に関する最初の公開または社内向け成果物を公開します
   • 61～90日目：定期プログラムの一部分を自律的に担当し、役割の資金調達要因の測定対象となる指標について、文書化した計画を作成します
6. ユーザーが候補者をどこで見つけるかまだ特定していない場合は、references/sourcing-channels.md を参照して、候補者の募集経路を示します。
7. 4つすべての成果物に対して、以下の品質ゲートを実施します。合格するまで改善を繰り返します。
8. ハーネスに永続メモリがある場合は、スコアカード、確定した質問集、面接プロセスの設計、立ち上がりのマイルストーンを保存し、後に同じ役割の採用を行う際に一からやり直さず、それらを再利用できるようにします。

企業の種類と資金調達の推進要因

募集要項のテンプレートを、どの企業にもそのまま使えるものとして扱わないでください。同じ職名でも、スタートアップ、成長段階の企業、大手テクノロジーベンダー、OSSを第一とする財団では仕事内容が異なり、求められるポートフォリオの水準やコーディングの深さもそれぞれ異なります。詳しい比較表、4つの柱、そして職務の評価基準を予測する7つの資金調達の推進要因については、references/company-type-and-driver-lookup.md を参照してください。

財団やOSSに関連するアンバサダー型の職務は、無給であることが多く、コミュニケーション能力ではなく測定可能な貢献が参加条件となります。給与が支払われる募集の要件を無給プログラムにそのまま適用したり、その逆を行ったりする前に、どの種類の職務なのかを確認してください。

品質ゲート

最終成果物を提出する前に、以下のチェック項目に照らして4つの成果物を評価してください。すべての項目に合格するまで反復してください。

1. スコアカードには3～8個の成果があり、すべて定量化され、優先順位が付けられ、Q3で挙げた資金調達の推進要因が明記されています。
2. 募集要項は、ゲートキーパー／落とし穴の自己監査に合格しています。中核業務以外のスキルを重視しておらず、成果を伴わない戦術の羅列がなく、職位レベルが提示された報酬と整合しています。
3. 面接の各質問が、スコアカードに記載された能力項目に対応しています。また、同じ職務の候補者全員に同じ質問セットが適用されます。
4. 面接プロセスには、対象となる柱を実際に評価できる形式が少なくとも1つ含まれています（アウトリーチが中心の職務ではプレゼンテーション面接、DX／プロダクト重視の職務ではコーディング課題）。職務に関係なく使い回した一般的な構成は避けてください。
5. 公開ポートフォリオの証拠がすでにある場合、いずれの段階でも無報酬の課題を求めません。
6. 面接官は、振り返りの前に、それぞれ独立して根拠を記した評価を提出します。最終評価の組み合わせは、事前に設定した重みに基づいて機械的に行います。
7. ポートフォリオの評価は、6つのシグナルを用いた評価基準に照らして採点され、対象となるサブ職種に応じた重み付けがなされ、該当する場合はマイナスのシグナルが明示されています。
8. 実務に即した課題を設計した場合は、固定の評価基準で採点し、報酬を支払います。無料の試用業務として扱わないでください。
9. 募集要項には、Q7の管轄区域に関する回答と整合する実際の報酬方針（公開された報酬範囲、または非公開とする理由の明記）が記載されています。金額も理由の説明もなく「競争力のある報酬」とだけ記載するのは避けてください。
10. 育成計画には、30日目の課題として摩擦ログの提出、60日目のマイルストーンとして成果物のリリース、90日目のマイルストーンとして自律的なオーナーシップの確立が含まれています。
11. このスキルの成果物における「良い状態」の説明はすべて、明示された情報源までたどれるか、このスキル独自の作業上の仮定であることが明記されています。この分野には、キャリアラダーを定める単一の権威ある組織がないため、出典を示さない主張は、実際以上に確立された見解として受け取られるおそれがあります。

よくある失敗パターン

意図的に順位は付けていません。各行は、必須の対処が1つある不備です。

失敗	対処
ゲートキーパーのような募集	中核から外れた要件のリストを、その柱の構成が実際に必要とする範囲まで絞り、実際の要件に照らしてレベルを再評価します
落とし穴のような募集	リソース、キャリアラダー、12か月後の目標を明記するか、それらが整うまで採用を延期します
汎用的なエンジニアリングまたはマーケティングの職務記述書テンプレートを流用する	資金提供の要因と柱の構成をもとに作り直します。DevRelの成果やコンピテンシーは、どちらのテンプレートにも当てはまりません
成果物ではなく履歴書で評価する	会話形式の面接に進む前に、6つのシグナルに基づくポートフォリオ評価を実施します
無報酬の課題選考	報酬付きの実務セッションを提案するか、すでに公開されているポートフォリオを評価します
グループでの振り返り後に、全体を主観的な1つのスコアで評価する	議論の前に、各自が根拠を記録して独立に採点し、その後、機械的に集計します
すべてのDevRelサブロールに同じ選考プロセスを適用する	対象のサブロールで実際に評価する要件に応じて、形式と質問を選びます
「競争力のある報酬」とだけ記載し、金額の範囲も理由も示さない	金額の範囲を公開するか、非公開とする理由を明記し、該当する管轄区域の最新要件を確認します
成果物のマイルストーンがない立ち上がり計画	30日目は公開済みの課題ログ、60日目は公開済みの柱に関する成果物、90日目は自律的なオーナーシップを基準にします
役職名は会社の種類を超えて共通だと見なす	過去の募集内容を再利用する前に、Q1の会社タイプ別の行に照らしてスコアカード全体を再調整します

参考資料

• 会社タイプの比較表、4つの柱、7つの資金提供要因については、references/company-type-and-driver-lookup.mdを参照してください。
• スコアカードの構成と募集例については、references/scorecard-and-posting-template.mdを参照してください。
• 形式の表、役割ごとの選考設計、カテゴリ別の質問集については、references/interview-loop-and-question-bank.mdを参照してください。
• 6つのシグナルに基づく評価の適用方法と報酬付きワークサンプルの設計については、references/portfolio-and-work-sample-scoring.mdを参照してください。
• 30-60-90の完全なテンプレートについては、references/ramp-plan-template.mdを参照してください。
• DevRel候補者が実際に見つかる場所については、references/sourcing-channels.mdを参照してください。
• 候補者側の情報（ポートフォリオの構築、面接対策、オファーの評価）については、samber/developer-relations-skills@devrel-careerを参照してください。このスキルは候補者をコーチングしません。
• この役割が採用される組織設計とレポートラインについては、samber/developer-relations-skills@devrel-team-structureを参照してください。これはこのスキルによって決めるのではなく、事前に決定します。
• 採用後もスコアカードの成果指標との整合性を保つべき測定フレームワークについては、samber/developer-relations-skills@devrel-metricsを参照してください。
• 候補者が承諾前に確認する雇用主ブランドの情報発信面については、samber/developer-relations-skills@tech-employer-brandingを参照してください。