はじめに
こんにちは、Stackdriver担当者です。
これまで「Developer Relationsは何をする組織なのですか」「Developer Advocateってどんな仕事をしているのですか」といった質問をしばしば受けてきました。都度考えながら答えていたのですが、今後のためにこの記事にまとめておこうと思います。
Developer Relations とは何か
XXX Relationsとは何か
自分は Developer Relations を語る前に、まず世の企業内で見られるような他の「XXX Relations」というタイトルの組織について考えていくと整理しやすいのではないかと考えています。
- PR (Public Relations; 広報): 一般大衆に向けて企業の情報を伝達し、同時に一般大衆から意見や情報を受け入れるための組織
- IR (Investers Relations): 投資家に向けて企業の経営状況や財務状況を伝達し、同時に株主を主とした投資家からの意見や情報を受け入れるための組織
- GR (Government Relations): 企業が政府や行政と関係を結び、企業が実現しようとしている目標に関係する法令や規制に関してのスムーズな意見交換を実現する組織
とこのように「XXX Relations」と呼ばれる組織は名前の通り 対象の人間や組織と関係を作り、そこで必要とされる情報を伝達し、同時に意見や情報を受け入れる 組織であるとわかります。
Developer Relations の定義
先の話を前提として、自分はDeveloper Relationsを次のように定義しています。
開発者や企業に向けて自社関連技術を伝達し、同時にそれらに対する意見や情報を受け入れるための組織
これを分解して考えていきます。まず前半の「開発者や企業に向けて自社関連技術を伝達し」の部分。これに関しては注意をしないといけないと考えています。
Developer Relations is not only about holding event and talking in events, but all activities relevant to engineers; one writes programs a lot, another writes docs, the others do others. How we work is all up to us.
— Yoshi Yamaguchi (@ymotongpoo) 2019年2月28日
このツイートでも書いていますが、よくDeveloper Relationsでは開発者イベントを開催したり、登壇したりするだけが仕事だと思われているようですが*1、それは一部でしかありません。
開発者に自社関連技術を伝える仕事としてはイベント関連を含めて多岐に渡ります。たとえば自分の職種であるDeveloper Advocateでは次のような仕事に関係しています。
- 開発者イベントの企画、開催
- 開発者イベントでの登壇
- 開発者コミュニティとの連携
- 技術資料の作成（公式ドキュメント、ブログ、動画など）
- サンプルコード、参照実装、デモの提供
- クライアントライブラリ、SDK、APIの提供
- OSSの開発
- PRやGR、ビジネス開発などに対する技術面での後方支援
また後半の「自社関連技術に対する意見や情報を受け入れる」に関しても活動も多く
上記で集めた意見や情報を自社製品や関連技術の改善につなげるために
- 社内の他の技術職（ソフトウェアエンジニア、プリ・ポストセールス系の各種エンジニア、サポート系エンジニアなど）との技術・情報の共有
- プロダクトマネージャーやソフトウェアエンジニアと製品や機能に関してディスカッション、PRDやDesign Doc*2へのフィードバック
- GDEへの情報提供含めたディスカッション
といった仕事も多く行っています。（むしろ日常業務はこれらがすごく多い）*3
これらを見ると他の組織と重複する仕事も多いですが、GoogleのDeveloper Relationsチームでは「最終的に開発者のメリットになるのか」という点が最重視されていて、営業的な数値目標で意思決定がされるわけではありません*4。個人的にはこの点において営業組織との棲み分けが強く働いていると思います。社内にいながら、ときには開発者視点でみて、外部開発者に導入を積極的には勧めない、あるいは様子を見るように伝えることもあります。また外部開発者の視点で開発チームに修正を求めるフィードバックも多々行います。
Google の Developer Relations に所属する役職
Google Careers のサイトに Developer Relations に属する役職などの説明動画があります。（動画自体は少し古いですが、内容は変わっていません）
Developer Relationsチームに所属する職種は細かくみるとこれよりも多いのですが、主要な職種は次のとおりです。
- Developer Advocate
- Developer Programs Engineer
- Developer Program Manager
- Technical Writer
これらの役職はおおよそ次のように分かれています。
- Developer Advocate (DA): 対外的な仕事が多く、担当領域に関してイベントでの登壇や外部の開発者への技術支援、担当製品のフィードバック収集などをよく行う。
- Developer Programs Engineer (DPE): SDKやサンプルコードの開発などがメインだが、対外的な登壇もあったりする。
- Developer Program Manager (PgM): コミュニティ（例: GDG、GCPUG）との連携やオフライン／オンラインイベントの開催などを重点的に行う。
- Technical Writer (TW): 公式ドキュメント（Google DevelopersやGoogle Cloudの各種ドキュメント）の執筆
（追記 2022.09.01 いまはDAとDPEの職のオーバーラップが多かったため、Developer Relations Engineerというタイトルになり、両者の垣根はなくなりました。外部的には過去の役職名のままの人もいますし、変えている人も居ます。）
これらがすべてきっちりと分かれているわけではなくて、たとえば自分はクラウドチームのDAですが、GoやOpenCensusといったOSSのコミュニティとの連携を業務の中でも重視していますし、サンプルコードやPoCコードを書くことが多々あります。
WebチームのDAのえーじさんはいまはWebAuthNの普及に務めつつ*5、長年一貫してWeb関連のコミュニティ支援を行っています。
DPEである@yuichi_araki（通称: 課長）は、メイン業務ではRoomの開発をしつつ、コミュニティでの登壇やハンズオン講師なども必要に応じて行っています。
Program Managerであるたくおさんも、コミュニティ支援やイベント企画だけでなく、デザイン系のイベントでの登壇などもよく行っています。
他にもチームメイトが各々に異なる技術領域をカバーしています。このように各職種に大きな枠はありつつも、最終的に「ユーザーである外部開発者と社内の開発チームをつなぐ橋」として成立すれば、自分が実行したほうが良いと思ったことを裁量を持ってなんでもできるというのがGoogleのDeveloper Relationsです。
おわりに
そもそもこれを書こうと思った理由は先日開催されたイベントの名前を見て面白さを感じたからです。
ここでは「SA (Solution Architect)」の人たちが集まっていたようですが、各社でSolution Architectの職務の定義は違っているはずです。X社ではプリセールスという認識で、Y社ではポストセールスとして扱われていたりするでしょう。そうした人たちが同じ職種であるということで集まって活動内容をシェアするというのは、その職種に共通する性質を知る近道なのかもしれません。
最近は日本でもDeveloper Relationsという組織を持つ企業が増えてきました。先に挙げたPR、IR、GRが会社の特性に合わせて異なった活動をしているのと同様に、各社のDevRelの活動は大まかには近しいとしても、企業によって変わってきます。しかし、その「大まかに近しい」活動の内容が「重要である」と認識されれば、個人的には自分のキャリアパスも広がるので嬉しい限りです。
日本でもDevRelConが開催されていますが、こうした活動が広がってDeveloper Relationsの重要性が認識されることを願っています。
