この記事は、2021 年 4 月 21 日に dev.to へ投稿された「The Subtle Art of Being A Developer Advocate」の日本語訳です。
今回投稿者の Wassim Chegham（@manekinekko）さんに翻訳の許可をいただきました。ご快諾いただきありがとうございます。
この素晴らしい記事を少しでも多くの人に届けたいと思い、 Qiita に投稿します。
デベロッパーアドボケイトになるための秘訣（The Subtle Art of Being A Developer Advocate）
数年前、私は「デベロッパーアドボケイトとは一体何か？(What the heck is a developer advocate?)」という記事を執筆しました。その記事では、テック業界の人々にこの役割がどのようなものかを理解してもらおうとしました。しかし、いまだに Twitter でこの役割についてのたくさんの質問をいただきます。
本記事では、私が Microsoft のシニアデベロッパーアドボケイトとして日々行っているタスクや活動、そして 2015 年からデベロッパーアドボカシーを行っている者として、具体例を挙げてデベロッパーアドボケイトの役割を解明していきます。
免責事項
本記事で述べられている見解は私個人のものであり、私の所属する企業や同僚を代表するものではありません。
まずは、デベロッパーアドボケイトとテクノロジーエバンジェリストの違いに注目しましょう。
デベロッパーアドボケイトとテクノロジーエバンジェリスト
デベロッパーアドボカシーとテクノロジーエバンジェリズムには、ある種の混乱があります。両方の用語の定義について見ていきましょう。
Wikipedia によると、「テックエバンジェリスト」という用語は Apple によって、Macintosh 用のアプリを作成するよう開発者を説得するための取り組みの一環として提唱されました。「persuade」という動詞は、とても重要です。なぜなら、エバンジェリストが必ずしも開発者のニーズや意見を気にすることなく、とあるテクノロジーを採用することを意味するからです。
これはアドボカシーとは正反対です！
「アドボカシー」とは、中世ラテン語の「advocare」に由来する古い概念で、「声を添える」という意味です。「advocate」という用語は、古いフランス語で「avocat」で、「弁護士」という意味です。ですのでアドボケイトとは文字通り、「事件や原因を訴える」人や「何かを変えたり改善する必要性を主張する」人を意味します。
テック業界に当てはめるとこれら 2 つの用語はとても似ているように見えるかもしれませんが、実際は微妙な違いがあります。テックエバンジェリストは一方通行（外向き）で、デベロッパーアドボケイトは双方向（外向きと内向き）とされています。つまりテックエバンジェリストは、ある技術が必要なものであると開発者を説得することに関心を持つのが普通です。デベロッパーアドボケイトは、開発者のニーズに耳を傾け、最も適切な支援をすることに関心があります。またデベロッパーアドボケイトは、開発者のフィードバックを収集したり、社内で開発者の支援も行います。
ですので、この 2 つの職種を賢く使い分けることが必要です。
しかし、理論的な定義だけではなく、実際には職種によって例外があることを強調させてください。私の友人の中には職種はテックエバンジェリストですが、仕事はデベロッパーアドボケイトのような人もいます（その逆もあります）。本当に重要なのは職種ではなく、開発者が成功するために何をするかです。
デベロッパーアドボケイトとマーケター
デベロッパーアドボケイトを定義するよう頼まれると、人によって様々な答えが返ってきて混乱します。それはよくあることです。ではその理由を考えたことがありますか？主な理由はほとんどの企業が、営業からコミュニケーション、最もよくあるのはマーケティングまで様々なタスクをするためにデベロッパーアドボケイトを採用する傾向にあるからです。なぜマーケティングなのでしょうか？企業は利益の 5~12%をマーケティングに費やしていて、より多くの開発者にアプローチする必要がある場合、通常マーケティング（またはビジネス部署）に報告し、マーケティングと営業の KPI（重要業績評価指標）に従って動くデベロッパーアドボケイト（またはこの職種の他の種類）として誰かを採用するでしょう。最も重要なのは、この状況において、この役割はプロダクトのエンジニアリングチームの外部で主導されるため、問題になる可能性があるということです（これについては後述します）。
ただ誤解しないでください。企業がマーケティングと営業を使って開発者にアプローチすることは、決して悪くはありません。ですがデベロッパーアドボカシーという職種でこれを行うことは、誰にもメリットがありません。いずれにせよ、全ての開発者がマーケティング（または営業）に長けているわけではないため、これは悪い方向へ進み、最終的に良くない結果となります。開発者は優れた創造力や独創力を持っていますが、ビジネスマーケティングのスキルが欠けている人もいます。なぜ成功している多くのスタートアップは少なくとも 2 人以上で起業するのでしょうか？もし私がマーケティングや営業に長けていたら、私は自分のオープンソースプロジェクトを改善するためにもっと良い仕事をしていたでしょう。しかし、xlayers.devのことを聞いたことはあるでしょうか？
開発者にアプローチするときマーケティングチームは開発者へのメッセージを調整するために、デベロッパーアドボケイトと強力した方が良いでしょう。なぜでしょうか。その理由はデベロッパーアドボケイトが他の何よりもまず開発者自身であり、他の開発者と同じ言語を使って会話するからです。
企業はアドボカシーの背後にある真の意味を無視し、自分たちのビジネスを元に各々の定義をしていることも少なくありません。そのためデベロッパーアドボケイトのほとんどが自分の役割やどうあるべきかを理解できていません。本記事が何かお役に立てば幸いです！
デベロッパーアドボケイトと DevRel
DevRel とは簡単にいうと、デベロッパーアドボケイトやコミュニティマネージャー、開発者コミュニティを作り育てる責任を負うチームの総称です。Microsoft のような大企業の中には、ドキュメントやイベント、ソーシャルメディアに対して責任を負っているチームも含みます。
つまりデベロッパーアドボカシーのチームは、DevRel のごく一部です。
Microsoft における私の役割は何か？
デベロッパーアドボケイトとして、私たちが何をするか、何をすべきかについては意見が合わないかもしれませんが、ある共通の定義には賛同します。
「私たちの役割は、社内のエンジニアリングチームと開発者コミュニティの橋渡しをすることです。また社内で開発者の支援も行います。」
Microsoft で私がどんな仕事をしているかを説明する前に、少し背景を説明させてください。
私は JavaScript のスキルと JavaScript の開発者コミュニティとの関係性の深さを理由に採用されました。現在の私の仕事は、JavaScript アドボカシーチームとして働くことです。私のチームは Microsoft の Azure エンジニアリング部署の一部である DevRel 組織に所属しています。
私の日々の仕事は、Microsoft 社内の JavaScript 開発者を支援し、プロダクトチームのミーティングや社内調査で彼らの声を代弁することです。対外的には、JavaScript 開発者のフィードバックを集め、自分達のプロダクトやサービスの改善を支援しています。基本的に私は JavaScript 開発者が Microsoft のクラウドやサービス、オープンソースの開発者ツールを使って成功することを支援しています。
Microsoft が自社プロダクトのレベルを上げ、そのために開発者やオープンソースに投資していることはご存知かもしれません。ですので私たちの DevRel チームのミッションは、より多くのことを達成できるように開発者を支援することです。 私たちの大きいデベロッパーアドボカシーチーム（DevOps チームも支援しているため、クラウド開発者アドボカシーとも呼んでいます）は、Rust、Java、Python などの異なる開発者コミュニティだけでなく、学生、大学、スタートアップなどにも焦点を当てた複数の子チームで構成されています。
クラウド開発者アドボカシーチームのミッションは、信頼性、コミュニティ、技術的な関わりを通じて、開発者の心を掴むことです。
デベロッパーアドボケイトとしての私の１日は？
以下で公開するタスクは、「私」が定期的に行っている活動です。私のチームメンバーは「全く」同じ活動をするかもしれないし、しないかもしれません。
コンテンツの作成
私は世界的にエンジニアが使っている様々な形式で、技術ドキュメントやコンテンツの作成に参加しています。その活動は既存のドキュメントを更新するような簡単なものや、私と私のチームが Microsoft のドキュメントチームと共同で作成した「Azure Static Web Apps documentation 」のような完全なドキュメントの作成があります。
他には、開発者向けのワークショップやコーディングチャレンジの開催、私が普段 Twitter で投稿しているような気軽に楽しめるコンテンツの作成があります。
こちらが最近作成したコンテンツです。
あとこちらも。
講演
多くのデベロッパーアドボケイトが悪名高い活動として挙げているのは、おそらく公のイベントです。国際的なカンファレンスやイベントで技術講演や基調講演をすることも、私の仕事の 1 つです。基本的に開発者がいるところに行きます。それにはライブストリーミングやポッドキャスト、似たようなメディアも含んでいます。
オープンなツールの作成
会社での仕事に加えて、私はオープンソースコミュニティーのアクティブなメンバーの一員でもあります。私が会社で行っている仕事のほとんどはオープンでも行っています。つまり私の仕事は、開発者が自分のプロダクトやアプリケーションに Azure を使用し統合するためのツールを使って成功するのを手伝うことでもあります。最近作ったツールには、 https://www.hexa.run/ や Nest.JS libraries for Azure CosmosDB 、Azure Storage があります。wassim.dev でオープンソースの作品を確認できます。
プロダクトへのフィードバック
開発者が使用するプロダクトやサービスを継続的に改善することは私たちのチームの重要なミッションの 1 つです。私は開発者やエンジニアとソーシャルメディアやオンライン、オフラインのイベントを通じて交流することに多くの時間を費やしています。開発者から質問されたり、問題を上げてもらったり、機能のリクエストといった多くの要求を受けています。私がプロダクトに詳しい場合は、まず最初に彼らを手助けします。大きな問題や人気のある機能のリクエストの場合はコミュニティーから集めたフィードバックをもとに体験を向上させるため、社内のダッシュボードにワークアイテムを作りプロダクトチームと密接に協力します。
ここがまさにデベロッパーアドボケイトとして JavaScript 開発者を支援し社内で彼らの声を代弁できる場所です。最近の例として私は 1 年半、 Azure Static Web Apps というプロダクトへ貢献し、サービスの一部を設計するエンジニアリングチームの手助け、重要なフィードバック、早期にアクセス機能を試し、開発者用の CLI ツールを実装しました。
プロダクトのリリース
多くの人が無視しているかもしれないデベロッパーアドボケイトのもう 1 つの観点としては、社内社外問わず、プロダクトを作りリリースすることにも貢献している人がいるということです。 私は半年間、開発者がローカルで実行しデバッグできるように、公式の Azure Static Web Apps の開発を作成、リードしリリースしてきました。
理由は、プロダクトやサービスがどのように設計、実装されているか、そしてその長所と短所を理解する事は不可欠だからです。それは開発者をより支援するために必要な知識です。
カスタマー・ゼロであること
私は Azure のプロダクトやサービスを改善し、会社を横断して新しい機能を試すためにエンジニアリングチームと一緒に働き、JavaScript 開発者の期待についてのフィードバックを提供することに多くの時間を費やしてきました。 過去 2 年間取り組んできたプロダクトは、Azure Functions、Azure Storage、Azure Cosmos DB、Azure IoT、Azure Static Web Apps、GitHub Codespaces、そして npm です。「カスタマー・ゼロ」として振る舞うことは、リリースされる前にプロダクトへ多大な影響を与えるとても良い方法です。その一例として Azure Static Web Apps があります。私と私のチームはこのサービスを使う Web 開発者のコミュニティにベストな開発者体験を提供するため、エンジニアリングチームと密接に協力しています。
常に学び続ける
JavaScript は多くの分野で広く使われているので、私が注目している技術スタックには、Node.js、TypeScript、Serverless、IoT アーキテクチャ、データベース、そしてホスティングも含まれています。正直なところ、Rust というプログラミング言語にも魅力を感じているので近い将来学び始めるつもりです！ 幸運なことに Rust の開発者アドボカシーチームにいる私の同僚が、初学者のために Rust についての無料の5時間分のガイドを作っています。私にとってそれは良いスタートになりそうです。
公式ドキュメントの作成と改善
デベロッパーアドボケイトとして、私は多くのマイクロソフトクラウドサービスについての包括的な技術ガイドを作ることに時間を費やしてきました。私と私のチームが 4 ヶ月取り組んだ最近のガイドの 1 つが、the Node.js Learn Path です。 私たちの公式ドキュメントの良いところはオープンで誰でもそれを改善できるところです。この活動にいつでも参加し、http://docs.microsoft.com のドキュメントを改善、更新するためにプルリクエストを送ることもできます。
他の人の成長を助ける
私の仕事のもう 1 つの側面は、仕事内容には含まれていないですが、私にとってとても重要なことです。それは私の周りの人々が成長し、成功するのを支援することです。マイノリティ出身でテック業界で成功した者として、私は純粋にダイバーシティーやインクルージョンに興味を持っています。 そのためプロフェッショナルや個人として、人の成長を助けることは私の一部です。
私は Microsoft 社内で、公式のメンターシッププログラムでメンターをしています。対外的にはプログラミングを始めたばかりの人たちやキャリアを変更したい人、オープンソースに貢献したい人たちのメンターをしています。全ては公開できませんが、基本的にプログラミングや技術、キャリアにおける成長の支援とアドバイスを行なっています。
ビジネスと OKR
まずはっきりさせますとすべての会社の目的は、ビジネスをすることです。あなたの会社は単純にオープンソースで働いたり、イベントに出たりするためにお金を払っているわけではありません。それはあなたに投資をして、ROI（投資収益率）を期待しているのです。しかし、コミュニティや関係構築の ROI を簡単に測ったり定量化するのが容易ではないことをみんな知っています。
私たちは継続的にチームの OKR（Objectives と Key Results）戦略を見直し、会社の幅広い戦略に沿って計画を立て、チームの全員が開発者と本物の方法で繋がり、有意義な会話をして彼らの問題の解決を支援し、彼らの支援者となる自由を与えています。
まとめ
エンジニアの主な責任はプロダクトを保持、設計、実装、リリースすることです。そしてやりたい人は、開発者コミュニティにその体験を共有できます。 デベロッパーアドボケイトの責任はプロダクトに対してフルタイムで関わることではありません。ですがエンジニアリングチームが開発者のニーズに寄り添って全員にとってベストな体験を実現できるように支援することを除いては、エンジニアと違いはありません。
デベロッパーアドボケイトはオープンな場で学ぶことが大好きなエンジニアです。
これは私のストーリーです。もし読んだことに賛成であれば、私たちのチームは採用中ですので、https://aka.ms/awesomejobs を確認してください。
おまけ：デベロッパーアドボケイトの氷山
もしデベロッパーアドボケイトに興味があれば、Twitter で @manekinekko にお気軽にご連絡ください。また wassim.dev もフォローできます。hashnode でブログを書いているので、そちらもフォローしてください。
本記事で使用しているアセットは、Adobe Standard License です。