ますます多くの開発者サービス会社が巨額の投資を行い、自社の製品、サービス、APIなどを中心に自社のDevRelチームを構築しています。
しかし、会社によってDevRelに対する理解は異なります：一部の企業は専任の「技術推戴エンジニア（Developer Advocate）」を雇用し、一部の企業は「技術布教師（Developer Evangelists）」を雇用し、一部の企業はDevRelは「開発者向けマーケティング活動」だと考え、またある人はDevRelを製品のフィードバックの取得、製品の成功の推進の鍵と見なしています。どのような職位役割、活動形式があなたの会社に最も適しているかをどのように判断すればよいのでしょうか？異なる職位の呼称には一体どのような違いがあるのでしょうか？
「開発者関係」は会社にとって一体何を意味するのでしょうか？それは会社の目標が何にあるかに依存します。状況を説明するために、GoogleとTwilioのDevRel部門の使命を引用しましょう。ただし、短いフレーズがDevRelチームが実際に行っているすべてのことを必ずしも網羅しているわけではないことに注意してください。
開発者関係の役割は、開発者と会社のプラットフォーム製品、エンジニアリング、デザインとの双方向コミュニケーションを通じて、活力のある第三者開発者エコシステムを創造することです。
Twilio
私たちの仕事は、開発者を激励し、次の世代の驚くべきアプリケーションを構築するのを助けることです。これは、彼らが何を達成しようとしているかを理解し、ツールを指し示しトレーニングを行い、彼らが成功するのを助けることを意味します。
Google は「the interface between」という表現を使用しました。DevRelが期待するのは製品意思決定者と開発者（即ち製品の使用者）の間の双方向コミュニケーション橋梁の構築であることを示しています。Twilioの姿勢はDevRelがより単方向の「教育の役割」に近く、開発者がTwilio製品を使用するのを手伝うことを示しています。
Michael Mahemoff は最近 Developer Relations: A Five-Level Maturity Model を書きました。この記事の中で、彼は会社のDevRel部門の発展の異なる段階を説明しました。DevRel部門がない状態から、戦略の価値を完全に定量化できる段階まで。
「どのように自社のDevRel戦略を制定するか」という状況において、私はMichaelの定義に少し調整を加える必要があります：
- なし（None）、会社内に開発者をサポートしたり開発者フィードバックを収集するメカニズムがない；
- 非公式（Informal）、会社の他の部門がDevRelの一部の役割を果たす、PRは会社のブランド向上を担当、BDは開発者をサポートする任務の一部を担当、製品の専任開発者も一部のコミュニティ講演を担当；
- パートナーシップ（Partnerships）、貴重なパートナーとの関係、通常は比較的隠れている（通常はリソースが豊富な大企業で、新しい製品特性を構築する十分な能力を持つ）；
- 布教（Evangelism）、会議、パートナー、オンラインメディアを通じて大規模に会社の製品を向上・サポート；
- 技術推戴（Advocacy）、双方向の関係、製品の開発への参加を奨励するだけでなく、外部開発者が自社製品を使用することを奨励し、バグフィードバックや新機能リクエストを収集する。同時に、開発者の使用体験を向上させるサポートツールを開発；
以上の分析から、要約すると：Twilioは「技術布教師」の方法でDevRelを運営し、Googleは「技術推戴エンジニア」の方法です。
Michael は指摘しました：DevRelの正しい運営方法は会社のDevRelプロジェクトの目標に依存します。例えば、ある会社がブランドの知名度の向上、または少量の活動への参加によるコスト削減だけを期待している場合、その会社は「技術布教」の方法でDevRelを運営すべきです。第三者開発者から製品の使用フィードバックの収集を優先する場合、「技術推戴」の方式が最も良い効果かもしれません。
要するに、DevRelへの投資は会社の各ビジネスに促進作用があります。したがって、あなたの戦略の目標が何であるかが特に重要です。Dave McClure の AARRR モデルは DevRel 戦略の指導の基石として使用できます。
しかし、私は2つの修正を提案します：
DevRel は開発者たちが製品への認知度を高められるため、従来のマーケティング習慣に基づいて、AARRR の略語の前に別の「A」を追加します；
DevRel チームの日常活動には開発者たちの製品のフィードバックが含まれる可能性があるため、それを示すために AARRR の略語の後に「P」を追加します；
こうして新しいモデル：AAARRRP モデルが生成されます。これらを単に DevRel 指標として使用するのではなく、DevRel プロジェクトの潜在的目標として考えるべきです（「これらの指標をどのように測定するか」も考慮する必要があります：
- 認知度（Awareness）製品プラットフォームの認知度
- 獲得（Acquisition）登録量、ダウンロード量、インストール量
- 活性化（Activation）プラットフォーム使用の活動度
- 定着（Retention）プラットフォームの継続使用、新機能の使用
- 収益（Revenue）プラットフォームへの支払い
- 自主伝播（Referral）プラットフォームを他の人に伝える
- 製品（Product）製品の構築とフィードバックの収集に関連
DevRel の日常運営には様々な活動形式があります。各タイプの活動には1つまたは複数の DevRel 指標に対応し、1つまたは複数の AAARRRP 目標を実現できます。例えば：
| 活動 | 目標 |
|---|---|
| ドキュメント作成（リファレンスケース、スタートアップガイドなど） | 獲得、活性化、製品 |
| ライブラリ開発 | 活性化、製品 |
| クイックスタートアプリ | 活性化、製品 |
| ブログ記事（チュートリアル、テクニック、思想リーダーシップなど） | 認知度、獲得、活性化、定着 |
| ウェビナー | 認知度、獲得、活性化、定着 |
| イベントスポンサー（Meetupスポンサー、大会展示ブースなど） | 認知度、獲得 |
| 講演（Meetup、大会、コミュニティなど） | 認知度、獲得 |
| 製品サポート（Zendesk、StackOverflow、他のフォーラムなど） | 活性化、定着、製品 |
| プレセールス技術議論（電話、メール、サポートなど） | 獲得、活性化 |
| 専用フォーラム（Google Groups、Discourseなど） | 活性化、定着 |
| Alpha/Betaプログラム | 定着、製品 |
| オフィスアワー | 活性化、定着 |
| 開発者フィードバックの収集 | 定着、製品 |
| 会社の採用活動を助ける | 認知度 |
これらの行動の結果が開発者に積極的な意義を持ち、会社の評判が向上することを保証します。このようにして「自主伝播」の可能性が高まります。しかし、開発者と会社間のこのような関係構築には時間がかかります。
収益：明らかに上記の行動から省略されています。収益は開発者が製品を使用する程度に依存します。したがって、製品の価格構造に大きく依存します。したがって、収益を上記のリストに単純に追加することはできませんが、収益を一時的に考慮しないことで、より多くのROIをもたらす可能性の高い活動と目標開発者に集中できます。
個人的には職位タイトルで人を定義することに賛成ではありませんが、職位タイトルは会社または他の開発者がDevRelチームでの彼の役割位置を反映しています。
したがって、一般的な職位タイトルに基づいて、異なる役割がどのような活動に参加するかを見てみましょう？
技術推戴エンジニア（Developer Advocates）：DevRelの仕事の一部として上述の責任の大部分を担当、特に製品または定着に関連する責任；
技術布教師（Developer Evangelists）：おそらくユーザー獲得関連の活動により集中している、例えば：ドキュメント作成、ブログ公開、イベントスポンサー、講演。「認知度」と獲得に関連する活動をより多く参照。
まとめ
DevRel をどのように定義するか？そしてどの方式があなたの会社に最も適しているか？以下が私の提案です：
- AAARRRP モデルに基づいて DevRel チームに期待する目標を制定する；
- これらの目標に最もマッチする活動形式を選択する；
- これらの活動形式に基づいて、技術推戴エンジニア（Developer Advocates）または技術布教師（Developer Evangelists）を募集するかを決定できる；
私自身を助けるための別の方法として、あるいは少なくとも職位タイトルに関するこのような持続的な議論に対して、私は DevRelOMeter プロジェクトを作成しました——あなたが期待する DevRel チームが展開する活動タイプに基づいて、技術布教か技術推戴かを提案します。
DevRelOMeter
あなたは開発者布教という事業に参加しているか、または参加を検討していますか？
https://leggetter.github.io/devrelometer/
著者：Phil Leggetter
原文：Defining Developer Relations
翻訳：Jack Jin
転載をご希望の場合は、出典を明記してください：デベロッパーリレーションズ »
