- Developer Relations または Developer Advocacy
→ 主にターゲット市場が開発者である企業に存在する役割
→ 特定の製品や技術を開発者に知ってもらうために、コミュニティを作ったり、コンテンツを作ったり、製品の開発者体験を向上させたりといった活動を行う
DevRel の3つのタイプ
- Community Builder : コミュニティに重点を置く DevRel
- 開発者コミュニティを作る役割
- イベントを企画し、ライブストリーミングを行い、Slack/Discord を運営し、フィードバックをやり取りするなどの活動を通じて、開発者が何かを持ち帰れるようにする
- Developer Educator : コンテンツに重点を置く DevRel
- 記事や発表などを通じて製品を知らせる
- ブログ、動画、ワークショップ、ポッドキャスト、ツイートなど
- 短期的にはプロモーションを運営し、長期的には SEO まで考慮する
- DX Engineer : 製品に重点を置く DevRel
- 製品の開発者体験に対するオーナー（開発者が製品をどう感じるかを改善する）
- 開発者と直接対話し、その意見に基づいてドキュメントやガイドを改善する
- コード例、テンプレート、Integration のような作業も行う
DevRel として就職する
- とてもホットな分野
- 多くのスタートアップが優れた DevRel を探している
- DevRel に応募するための主なスキル
- コーディング能力 : 開発者に共感するにはコーディングができる必要がある
- コミュニティ構築能力 : コミュニティを作って運営した経験があるとよい。大学、オープンソース、またはオンラインコミュニティなど
- コンテンツ作成能力 : 発表し、YouTube 動画を撮り、ツイートし、ブログ記事を書く能力
DevRel のためのアドバイス
- How to engage developers
- Show, don’t tell. : 言葉で説明するのではなく見せること（製品をすぐに試せるようにする）
- Features not benefits : 機能を直感的に見せ、他製品と比較する
- Be genuinely helpful : 高品質な資料（API ドキュメント、よく整備されたヘルプサイト、ハウツー動画、サンプルユースケースなど）に投資すること。そして追加の支援が必要なときに簡単に連絡できるようにすること
- Be Direct : 開発者について理解し、それぞれの個人に直接書いているかのように想像すること。そうすれば、売り込み文句ではなく本当に役立つコンテンツを書ける
- Think beyond the 9-to-5. : 多くの開発者は仕事の内外でさまざまなテーマのサイドプロジェクトに取り組んでいる
- Repurpose Content : 同じコンテンツをできる限り再利用すること。ツイート → ブログ → 動画 → カンファレンス発表 といったパイプラインを構成する
- Have a "breakable toy" : 新しい技術を適用して、その変更による指標を示せる実際のアプリを持つこと。小さくても本物であるべき。シンプルな運動トラッカー、食事プランナー、ノート作成ツールなど。あなたと友人数人ほどの実際のユーザーがいるとよい
- そのほかの DevRel 関連資料
2件のコメント
私も同じ考えです。ソフトウェア開発文化が発展するにつれて、当然ながら仕事の種類も多様化し、細分化されるべきだと思います。今後は単にプロダクトを作ることだけに集中して開発職・管理職に分けるのではなく、プロダクトを発展させて広報するために必要なさまざまな役割が生まれるといいですね。DevRel/Advocate だけに分かれていたところに DX が加わる点はとても良いと思います。Chrome DevRel チームのメンバーたちが Spotify の DX に多く転職したのも、良い例になるのかもしれません。個人的にもとても関心があるのですが、ポジションがなかなか……
あの記事の主役たちはほとんどが Vercel の DevRel チームですが、長い歴史のある DevRel 組織ではなく、新興スタートアップ(?) が DevRel を定義しているのは興味深いですね。
海外ではかなりホットですが……国内では……うーん……（泣）
でも私は、ぜひ必要な役割だと思います。