Developer Advocate｜全方位的に技術を把握し、自社製品・サービスのファンを増やす

筆者は、直近約10年にわたって、日系企業1社、外資系企業3社で、Developer AdvocateまたはTechnology Evangelistの仕事に携わってきています。ここでは、これらの自分の経験を踏まえて、特定の企業の状況に特化するのではなく、一般的にDeveloper Advocateという仕事（役割）がなぜ必要なのか、その定義、期待される役割について書いていきたいと思います。

• keyboard_arrow_down Developer Advocateとはなにか。期待されている役割と定義
• keyboard_arrow_down Developer Advocateの具体的な仕事内容とミッション
• keyboard_arrow_down Developer Advocateとして働く理由、やりがい
• keyboard_arrow_down Developer Advocateとして働き、感じる課題感
• keyboard_arrow_down Developer Advocateに必要なスキル、マインドセット
• keyboard_arrow_down ユーザーであるエンジニアと信頼関係を築くことに興味がある人に向いている仕事である

まず、Developer AdvocateとTechnology Evangelistの役割の違いについてです。この2つの役割は、しばしば同じ意味や同じRoleとして語られることがあります。

Advocateというのは日本語に直訳すれば「代弁者」「擁護者」となるでしょうか。つまり、Developer（開発者）の声を代弁する役割となります。これは、次の章で詳しく触れますが、Developer Advocateが所属する企業の開発者向け製品・サービスに対して、それを利用するユーザー（開発者）がおり、そのユーザー（開発者）の声を代弁して会社へフィードバックする役割を担っていることを意味します。

Developer Advocateの話から離れますが、ディベートなどの場で「Deveil’s Advocate」という役割が存在するのをご存知でしょうか？ これは、議論においてわざと多数意見に対して反対意見を述べることで、その多数意見の正当性を確認したり、議論を活性化させることを目的とした役割です。悪魔の代弁者、といったところでしょうか。

このように、Advocateという言葉には「代弁者」「擁護者」という意味合いが強く反映されます。

では、Evangelistはどうでしょうか。こちらのRoleの方が耳慣れている人が多いかもしれません。こちらは、日本語に直訳すると「伝道師」となります。ですので、IT業界におけるTechnology Evangelistというのは、その企業の開発者向け製品・サービスを世に広めていくことが主たる役割になるかと思います。Technologyという冠が付いているのは、その製品やサービスを広めていくうえで、そのユーザー（開発者）と技術的な会話をしながらそのユーザー（開発者）の声を聞いていく必要があるからです。

どちらも、共通して言えるのは「開発者向けの自社製品・サービスをユーザー（ポテンシャルユーザー含む）とフェイシングしながら技術力をもって信頼関係を築く」というところになります。

ですので、解釈に多少の違いがあれどDeveloper AdvocateとTechnology Evangelistという2つのRoleは同じようなポジションとして語られることが多いというわけです。

Developer Advocateという仕事が誕生した背景

ここまでの説明で、この仕事（役割）の定義と期待値は明確になったのではないでしょうか。そして、なぜこの仕事（役割）が誕生したのかというと、それは自社製品・サービスの認知度を高めて、その製品・サービスのファンを増やしていく必要があるからです。

つまり、Developer Advocateの代弁対象者が開発者であるということは、この仕事（役割）が必要な企業というのは「開発者向けの製品・サービス」を提供しているところ、ということになります。それは例えば開発ツール、プラットフォーム、API、などです。それらを利用するユーザー、つまり開発者に信頼してもらい、より使ってもらえるようにしていく必要があるから、この仕事（役割）が誕生するわけです。

これは、総じてDeveloper Relations（DevRel）と呼ばれるマーケティングアプローチになります。世の中の開発者が求めるものを見定め、製品やサービスを開発者へ提供し、開発者の期待に応えることが企業でDeveloper Advocateという仕事（役割）を持つ理由でしょう。

前項で、Developer Advocate及びTechnology Evangelistの役割について説明しました。ここでは、もう少し具体的にこれらの役割がどのようなアクティビティを持っているかについて書いていきたいと思います。

実は、Developer AdvocateやTechnology Evangelistの役割（DevRel）が誕生した歴史を振り返ると、結構昔から存在していることが分かります。1980年代にはAppleやMicrosoftで同様の役割が存在していたことが分かる記事が存在しており、その歴史の深さを物語っています。

次の図は、2019年に行われた「DevRel/Japan Confernece 2019」にて筆者が基調講演を担当した際に使用したセッションスライドから抜粋しています。グローバルで開催されているDevRel関連カンファレンスの状況もタイムラインに記載しています。一部、独自調査による内容ですが、大筋のDevRelの歴史は把握できるのではないでしょうか。

Developer Advocateが担うアクティビティというのは、マーケティングに非常に似ています。それもそのはずで、Developer AdocateやTechnology Evangelistが行うアプローチであるDevRelは「開発者と自社製品/サービスを結びつけるマーケティング活動」である、と言われているのです。

参考：株式会社MOONGIFT「DevRelとは？」

日本では、MOONGIFTという会社が古くからDevRelに対してのさまざまな仕事や活動を行っています。DevRelについてもっと詳しく知りたい方は、上記参考サイトを訪ねてみるとよいでしょう。

さて、これらの仕事がマーケティングの考え方を伴っていると分かってくると、実施にやらなくてはならないアクティビティというのが見えてきます。マーケティングを知っている方であればおなじみのマーケティングファネルを説明します。

これは、パーチェスファネル（購入ファネル）とインフルエンスファネル（影響ファネル）の、大きく2つに分けられます。パーチェスファネルでは、「認知」「興味・関心」「比較・検討」「行動」の順にファネルが狭まっていきます。またインフルエンスファネルでは「継続」「紹介」「発信」の順でファネルが広がっていきます。

実際のDeveloper Advocateに当てはめると、対象の製品・サービスをまだ知らないマーケットに対して認知度を向上させ、興味を持たせてユーザーになってもらう。そして、継続利用してもらい、他の人にも使って欲しいと思ってもらい、ユーザー自らその製品やサービスを発信してくれるようになる。ここまでの流れを作っていくのがDeveloper Advocate（及びDevRel関連職）になります。

上記の図は、Developer Advocateとしてパーチェスファネルとインフルエンスファネルを網羅するために、実際に行われることの多いアクティビティになります。必ずしもこれらすべてを実施するとは限らないですし、逆にこれ以上のことを行うケースもありますが、ひとつの参考にはなると思います。

大きくカテゴライズすると、Advocacy、Community、Documents、Program Managementの4つに分けられるのではないでしょうか。これらのアクティビティを、すべてDeveloper AdvocateやTechnology Evangelistが担当するケースもありますし、チーム体制が分かれているところでは、Advocate、Writer、Contents Creater、Community Manager、Program Managerなどと役割分担されているケースも珍しくありません。

この分野での転職を考えている方は、Developer AdvocateというRoleだけではなく、これらのDevRelに関連する各Roleも視野にいれると選択肢が広がるのではないでしょうか。

筆者が考えるDeveloper Advocateという職業のやりがいは2つあります。

なぜ、この2つのやりがいを求めたのか、それは次のような筆者の経歴が背景としてあります。

筆者は元々、学校を卒業したあと美容師として社会人をスタートしました。ファッションやヘアスタイリング、メイクなどが好きで、且つ接客業をやりたいということで選んだ職種です。ですが、同時期にもうひとつやりたいことがありました。それはミュージシャン（音楽プレイヤー）です。この2つの職業に共通するのは、自分のアイデアを使って、所属する団体（お店、バンド、事務所、など）の認知度を高めファンを増やし、オーディエンスを幸せにすることだと思っています。美容師は就職してから1年で退職し、そこからミュージシャンとして生きる選択をしました。

その後、音楽業界を4年ほど経験し、IT業界への転職を決意します。音楽の活動を行う中で、Webサイト作成に関わるようになり、Webデザイナーになりたくなったからです。ここの流れは、自分の仕事におけるクリエイティブな場を、美容から音楽へ、そして音楽からWebサイトへと、自分の中では自然なものでした。

IT業界へ入ってからは、主にWeb系のエンジニアとして経験を積んできました。ソフトウェア制作会社でのProgramer、フリーランスSE、パッケージベンダーのProduct Engineer、そして知人と二人でAccurate Systemsというシステム開発会社を起業するに至ります。ここまでは、純粋にエンジニアとして経験を積んでいます（一部経営をやっていますが）。

その後、中途で入社した三井情報というシステムインテグレーターでは、SI案件のArchitectとしてキャリアを積み、在籍時の後半5年はR&DのEngineerとして働きました。ここがDeveloper Advocateとして働く転機になります。会社から、システムインテグレーターというある種ジェネラルな業務内容の企業において、社内外へ技術力を発信し認知度を高めるというタスクフォースの最初のメンバーへアサインされました。

この時点では、EvangelistとかAdvocateという言葉も知らず、Developer Relations（DevRel）も知らなかったのですが、このタスクフォースにおいて自分が何をすべきかを検討し調査していくと、すぐにDevRelの存在にたどり着きました。この仕事はまさに、自分の求めているものでした。そして、同社において初のTechnology Evangelistとして活動を開始したのです。

このタスクフォースは2年間限定のものでしたので、タスクフォース終了と同時に筆者の仕事も別のRoleに変わろうとしていました。ですが、このRoleでの仕事をもっとやりたい、この道のエキスパートになりたいと考え、当時ちょうどGlobalでDeveloper Advocate Teamを立ち上げ始めていたIBMにJoinすることを決めました。

IBMではGlobalでOne TeamのDeveloper Advocate Teamに所属し、Tokyo City Teamの立ち上げに従事しました。スターティングメンバーは3名でした。

ここでのDeveloper Advocateとしての仕事は非常に組織化されていて、やることも明確で、必要なバックオフィス系のオペレーションもすべて体系化されていました。チームの目的はIBM Cloudのユーザー（Developer）を増やしてファンを作り、コミュニティを活性化させ、Developer EcoSystemを醸成することです。

これが「働く理由、やりがい」の1つ目ですね。自分が若手のエンジニアだった頃、当時の技術コミュニティ（オンラインフォーラムやメーリングリスト）にとても助けられました。自分がシニアエンジニアになった今、今度は自分がそのような場を作り上げていきたいと強く思います。

IBMのDeveloper Advocate Teamの解散により、筆者はOutSysmtesというポルトガル発のローコード開発プラットフォームのDevRel TeamへJoinすることになります。ここには1年くらいしかいませんでしたが、活動内容は大体IBMと同じです。ただし、Japanのローカルにチームが存在せず、Global Teamの中に日本担当が筆者しかいない、という状態でした。この体制は、現在所属しているDatadogのAdvocacy Teamでも同様です。外資系ではこのようなチーム体制はめずらしくなく、筆者の場合はOutSystemsでもDatadogでもAPACの他の地域も担当する形になりました。各国によって開発者文化も商文化も異なります。それを理解し、現地のメンバーとコミュニケーションを取りながらDeveloper Advocacyを実現させていく難しさと戦っています。

これが「働く理由、やりがい」の2つ目です。筆者がJTCではなく外資系日本法人でDeveloper Advocateをやっているのは、この体験が自分の働く楽しさになっているからです。

Developer AdvocateやTechnology EvangelistというRoleは、マーケティングの知識を持ちつつも、常に尖ったエンジニアである必要があります。IT業界での技術の進歩は非常に早いものです。少しでも気を抜いているとあっという間においてかれてしまいます。

筆者が現職でカバーしている技術範囲は、主にクラウドにおけるObservability（可観測性）になります。簡単に説明すると、クラウド上のコンピューターシステムを監視して、なにか問題があれば直ぐに気付けるようにし、問題の原因を短期間で特定できるようにし、どのような対処が有効なのかをサジェストできる、そんな仕組みです。つまり、全方位的に技術を把握していないと、Observability領域ではなかなか技術を語ることができないわけです。

自分が理解していない技術の話をしたところで、その話を聞いている技術者の方々は直ぐに気づきます。あ、この人はこの技術のこと分かってないんだな、と。前述の通り、Developer AdvocateやTechnology Evangelistは、技術力を武器にベンダーと開発者の間に信頼関係を築く仕事です。技術力を見透かされてしまった時点で、その人に開発者は付いてきませんよね。

このような難しさのあるRoleなわけですが、筆者が感じる一番の課題は、Developer AdvocateやTechnology Evangelistは実際の開発プロジェクトにアサインされるRoleではない、ということです。つまり、「生きた技術やユースケース」を体験できない、ということです。

技術ドキュメントを読み込み、これまでの技術者としての経験を元に、技術デモやプレゼン資料を作成しても、基本的には「正常系」のシナリオであり、それはやはり「サンプル」でしかないのです。プロジェクトの現場で起こる、予測のつかないアクシデント、冷や汗をかくようなトラブル、夜中にバッチ処理が止まってその場の瞬間的な判断での対応、など、リアルな「例外」を語るのが難しいと感じます。

繰り返しになりますが、Developer AdvocateもTechnology Evangelistも開発者の信頼を得る必要があります。そのために、リアルな開発者体験を自分自身も持つ必要があるというところが、筆者がこれらの職種に対して感じる課題感です。

Developer AdvocateやTechnology Evangelistといった職種に必要なスキル、及びマインドセットとして、筆者は次の5つを挙げたいと思います。

このRoleをやっていて、良く聞かれる質問の中のひとつに、

Developer Advocateは （だいたいにおいてはDevRelは？と言われますが）  技術職ですか？営業職ですか？マーケ職ですか？

みたいなものがあります。これは確かに、AdvocateやEvangelistの活動を外から見ていると、このように聞きたくなる気持ちも分からなくもありません。

情報を発信している部分だけを見れば広報に近く見えるでしょうし、技術デモやワークショップ講師を見ればエンジニアに見えるでしょうし、製品を紹介しているトークを聞けばプリセールスに近いのかなと感じることもあるでしょう。

そうなんです、Developer Advocateという職種はいくつかのRoleの要素を複合的に有する非常にユニークなポジションと言えるのです。では、そのあたりを踏まえて、必要な5つのスキル・マインドセットを説明します。

Developer Advocateに必要なスキル1：技術力

まずは技術力です。Developer AdvocateやTechnology Evangelistは、対象となる技術や製品・サービスにおいて、実際のエンジニアに知ってもらい、使ってもらい、好きになってもらう必要があります。そのためには、ターゲットオーディエンスであるエンジニアが抱く疑問点や課題、問題に対して技術的アプローチで会話することが求められます。サンプルプログラミングやテスト環境構築が求められることもあるでしょう。同じ技術レベルで会話が成り立たなければ、そのエンジニアからは信頼されなくなってしまいますよね。
Developer Advocateが行うDevRelは、ベンダーと開発者・技術者の間に信頼関係を築くことだったはずです。そのためにも、Developer Advocateにとって技術力は絶対に必要なのです。

Developer Advocateに必要なスキル2：マーケティングの知識

次に、マーケティングの知識です。Developer Advocateが行うDevRelというアプローチでは、マーケティングのプロセスやフレームワークを理解することが求められます。このマーケティング知識そのものは、フェイシングするエンジニアに対して必要というよりは、自分自身の活動を意味あるものにプランニングするために必要、といったほうが正しいかもしれません。

わかりやすいところでいうと、カテゴライズやターゲティングは、Developer Advocateが活動する際に最初に意識するところだと思います。極端な例で言えば、モバイルアプリ開発向けAPIのアドボカシーを、物理ネットワークエンジニアに対してアプローチすることはない、みたいなことです。

それから、AIDMA（アイドマ：消費者が購買決定に至るまでのプロセスを表したモデル）やAISAS（アイサス：消費者が商品を認知してから購買に至るプロセス）といった購買行動モデルや（DevRelではコンテンツマーケティングにおける購買行動モデルであるDECAXが近いか？）、それらを元にしたマーケティングファネルの各フェーズの理解が、Developer AdvocateやTechnology Evangelistの活動には必要になってくるのも、この職種でマーケティング知識が必要であることを示しているのではないでしょうか。

マーケティングでおなじみの3C分析ですが、DevRelではCode、Contents、Communityといった「DevRelの3C」という考え方も出てきています。

Developer Advocateに必要なスキル3：プレゼンテーション能力

次に、プレゼンテーション能力です。Developer Advocateのメインの活動の中に、カンファレンスやセミナーなどでの登壇というものがあります。

元々のメインミッションとして、自社の製品やサービスの機能や特徴、使い方を「分かりやすく伝える」というものがあります。そのため、単純な話術だけではなく、プレゼンテーションの時間を踏まえた章立て、ストーリー作成、トークスクリプト作成、などが必要となってきます。

また、Developer Advocateは通常、自社製品のみにフォーカスした製品紹介に近いプレゼンテーションは行わないものです。もっとオーディエンスに対して技術的にフェアな内容で話すことが求められるからです。製品押しのプレゼンテーションでしたら、セールスエンジニアに任せれば良いよね、という話になってきますので。

プレゼンテーションを行ったり、デモを行ったり、お客様とフェイシングしたりと、Developer AdvocateやTechnology Evangelistとセールスエンジニアはアクティビティだけ見るととても似た側面を持っています。会社によってはセールスエンジニアやソリューションアーキテクトなどのプリセールスエンジニアをエバンジェリストという立ち位置にしているところもあります。

この両者の決定的な違いは、ターゲットオーディエンスに対する期待値と会社が求めるKPI/OKRになると思います。Developer Advocateはセールスエンジニアでは無いので、自身のアクティビティが即座に実案件につながる必要が無いのです。種まきに近い活動と言えるでしょう。

Developer Advocateに必要なスキル4：他人の話を聞く姿勢

そして、他人の話を聞く姿勢です。技術者となると自分自身の培ってきたスキルに自信を持っているものです。それはエキスパートとして大切なことですが、時にそれは頭を固くする原因になってしまいます。

Developer Advocateの大事な役割のひとつとして、Developer Voiceというものがあります。これは、実際に開発者コミュニティなどを通じて拾い上げたエンジニア達の率直な意見や感想を、自社へフィードバックし自社製品・サービスの改善につなげるものになります。

時には、非常に攻撃性の高いネガティブな意見もあるでしょう。対象技術や対象製品に対する自分の価値観と、ユーザーにあたるエンジニアの価値観が異なった時、一蹴してしまうのではなく、まずは耳を傾けることが大事です。

それは、自社製品・サービスの成長、及び自分自身のAdvocateとしての成長にもつながるはずです。

Developer Advocateに必要なスキル5：対象技術を好きである気持ち

最後に、対象の技術を好きである気持ちです。これはシンプルです。自分が好きでもない技術や製品を他のエンジニアに使ってもらうなんてできないですよね。ある意味、これは前の4つの下支えになっているマインドと言っても良いかもしれません。

実際に自分も使い倒して知り尽くして、その経験や知識を元にユーザーとなり得るエンジニアや既に使っているエンジニアとコミュニケーションを構築していくのですから、やはり対象の製品や技術を好きである気持ちというのは必要不可欠だと考えます。

これまでの文中でも触れてきた通り、Developer AdvocateやTechnology Evangelistというポジションは、少々ユニークな位置付けになります。純粋なエンジニアリングでもマーケティングでもセールスでも無く、混合スキルが必要とされる仕事内容です。
そして、そんなDeveloper Advocateが行う仕事内容というのは一言でまとめるとDevRel（Developer Relations）というわけです。

DevRelは種まきです。まだ畑は耕されてすらいないかもしれません。そんな中で、乱暴に種を蒔いて短期間で芽が出てくるのを期待されても困ってしまいますね。

畑を耕し（市場開拓）、正しい場所に種を蒔き（ポテンシャルユーザーへのリーチ）、然るべきステップで育て上げて（イベント実施、コミュニティの育成）、ようやく芽が出ます（プロダクト、サービスへの興味）。そこから花を咲かせる（ユーザーになる）まで導いて、花を摘み取ってしまってはいけません。花がさらなる花を咲かせるようにし（ユーザーがインフルエンサーとなり）、増えて増えて大量になった花を枯れないようにケアをする（チャーン防止）、そんな一連の流れを「技術力をもってリード」していくのが、Developer AdvocateやTechnology Evangelistが担うDevRelという仕事なのです。

0を1にするだけでなく、その先まで見据えて自社製品・サービスのユーザーであるエンジニアと信頼関係を築いていく、そんなお仕事に少しでも興味を持ったあなたは、おそらくDeveloper Advocateに向いています。

求人情報では、大きくカテゴライズされてDevRelとして募集しているケースもありますし、Developer AdvocateやTechnology Evangelistだけでなく、Community Manager、Product Marketing Manager、Technical Writer、Technical Contents Createrなど、他のポジション名で近しい仕事を募集しているケースもあります。

これらの職種が特に多く見られる外資系企業では、募集への応募の前にカジュアル面談を行っているところも多いですし、また一番最初にリクルート担当者が応募者と企業間で期待値の差が無いかを確認する面談を行うことが一般的ですので、興味があれば臆せずに応募してみてはいかがでしょうか。

今回の記事が、Developer Advocateへの転職に興味を持つ人達の参考になれば幸いです。