YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

GoogleのDeveloper Relationsチームは何をしているのか

はじめに

こんにちは、Stackdriver担当者です。

これまで「Developer Relationsは何をする組織なのですか」「Developer Advocateってどんな仕事をしているのですか」といった質問をしばしば受けてきました。都度考えながら答えていたのですが、今後のためにこの記事にまとめておこうと思います。

The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success

The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success

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では開発者イベントを開催したり、登壇したりするだけが仕事だと思われているようですが*1、それは一部でしかありません。

開発者に自社関連技術を伝える仕事としてはイベント関連を含めて多岐に渡ります。たとえば自分が担当しているDeveloper Advocateでは次のような仕事に関係しています。

  • 開発者イベントの企画、開催
  • 開発者イベントでの登壇
  • 開発者コミュニティとの連携
  • 技術資料の作成(公式ドキュメント、ブログ、動画など)
  • サンプルコード、参照実装、デモの提供
  • クライアントライブラリ、SDKAPIの提供
  • OSSの開発
  • PRやGR、ビジネス開発などに対する技術面での後方支援

また後半の「自社関連技術に対する意見や情報を受け入れる」に関しても活動も多く

  • 各種標準団体や重要なOSSに参加・連携
  • 主要ユーザー(企業等)との定期的なディスカッション、ヒアリング
  • 新規技術や機能を導入する企業への技術支援

上記で集めた意見や情報を自社製品や関連技術の改善につなげるために

  • 社内の他の技術職(ソフトウェアエンジニア、セールス系の各種エンジニアなど)との技術・情報の共有
  • プロダクトマネージャーやソフトウェアエンジニアと製品や機能に関してディスカッション、PRDやDesign Doc*2へのフィードバック
  • GDEへの情報提供含めたディスカッション

といった仕事も多く行っています。(むしろ日常業務はこれらがすごく多い)*3

これらを見ると他の組織と重複する仕事も多いですが、GoogleのDeveloper Relationsチームでは「最終的に開発者のメリットになるのか」という点が最重視されていて、営業的な数値目標で意思決定がされるわけではありません*4。個人的にはこの点において営業組織との棲み分けが強く働いていると思います。社内にいながら、ときには開発者視点でみて、外部開発者に導入を積極的には勧めない、あるいは様子を見るように伝えることもあります。また外部開発者の視点で開発チームに修正を求めるフィードバックも多々行います。

Google の Developer Relations に所属する役職

Google Careers のサイトに Developer Relations に属する役職などの説明動画があります。(動画自体は少し古いですが、内容は変わっていません)

www.google.com

Developer Relationsチームに所属する職種は細かくみるとこれよりも多いのですが、主要な職種は次のとおりです。

  • Developer Advocate
  • Developer Programs Engineer
  • Developer Program Manager
  • Technical Writer

これらの役職はおおよそ次のように分かれています。

  • Developer Advocate (DA): 対外的な仕事が多く、担当領域に関してイベントでの登壇や外部の開発者への技術支援、担当製品のフィードバック収集などをよく行う。
  • Developer Programs Engineer (DPE): SDKやサンプルコードの開発など。
  • Developer Program Manager: コミュニティ(例: GDGGCPUG)との連携やオフライン/オンラインイベントの開催などを重点的に行う。
  • Technical Writer: 公式ドキュメント(Google DevelopersGoogle Cloudの各種ドキュメント)の執筆

これらがすべてきっちりと分かれているわけではなくて、たとえば自分はクラウドチームの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の重要性が認識されることを願っています。

参照

*1:実際にイベントでそのように聞かれたことが多々あります

*2:Product Design Doc; プロダクト要求仕様書、Design Doc; 設計仕様書

*3:他にも上記以外にやってそうだけど自分がパッと思いついたのはこれくらい

*4:目標設定に関しては営業的な数値目標を持つことを禁止しているわけではなく、優先度が違うという意味です。

*5:リンク先のWebAuthNの記事もえーじさんが書いたものですね