Q1.DevRelで成功している企業はどこですか？何が成功の秘訣でしょうか？

A.開発者を飽きさせず、常にワクワクさせるのが重要です（中津川 篤司）

　世界的に見ればもっとも成功した企業はApple、Google、AWSそしてGitHubでしょう。成功した秘訣として、開発者に対して真摯に向き合っているということが挙げられます。それは企業としてのメッセージの中にも現れています。別な視点でMicrosoftも興味深いでしょう。かつては開発者に嫌われていた企業ながら、ここ数年でイメージががらっと変わっています。オープンソースや最新テクノロジーを惜しみなく公開する（giveする）ことで開発者との関係性を改善しています。

　日本ではSORACOMが筆頭に挙げられるでしょう。元AWSのエバンジェリストやDevRelに関わってきた方たちが多く参画しているだけあって、DevRelの進め方が上手です。サービスのメッセージ、コンテンツ、API、ユーザーグループなど随所にAWSでの経験が活かされています。AWSが今なおそうであるように、開発者を新しい世界へ導き続けています。新しい機能を次々と打ち出し、停滞を感じさせません。この力強い開発力もまた、DevRelとして大事な要素になります。新しいサービスは日々生まれており、停滞または安定、運用フェーズはネガティブな印象を持たれるでしょう。

　これらの企業に共通しているのは、有言実行という意味での「デベロッパーファースト」であること、ユーザーを飽きさせずわくわくさせ続けることです。有言実行と書いたのは、メッセージだけ「開発者にフォーカスします」と書いているところが多いからです。関わっているユーザーがまさにデベロッパーファーストであると感じてもらえる雰囲気が作り出せていなければ無意味です。

A.製品軸と課題軸という異なる類型の成功事例、そこに共通するのはユーザーファーストの姿勢です。（Journeyman）

　実際に上手くいっていると感じる先をご紹介したいと思います。これは、中の人にKPIを開示してもらった情報ではないことをおことわりしておきます。自分自身がミートアップに参加したり、SNSやブログでの発信を追いかけている中で機能していると感じるという基準に則っています。また、企業名そのものは出しません。こういう領域のサービスでこんな取り組みをしており、結果どうなっているという視点でふたつの活動をご紹介します。

　ひとつ目は製品軸のコミュニティーです。立ち上げから順調に伸び、ある領域では日本でも第一純粋想起を勝ち取る日は近いほどグロースしています。テーマは決済です。近しい決済サービスも同様にDevRelを推進しており、日本でエバンジェリズムを推進する担当がいましたが、今では開催頻度、日本全国の拡散度合い、関係人口からUGCの質・量ともに圧倒しています。

　非常に近くでその違いを見て感じる上手くいってる理由をふたつ絞ってお伝えします。

　ひとつは、DXが極めて優れているという点です。このDXはデベロッパーエクスペリエンスのDXです。Webから動作の確認ができるレベルのリファレンスが日本語で提供されています。数年前にはじめて会った時の驚きは今でも覚えています。

　もうひとつは日本法人が独立して存在し、日本独自の機能要件に真摯に向き合い素晴らしいスピードでアップデートしているという点です。どんどんよくなるサービスはワクワクします。これは無論マーケティングに止まらず、事業開発、カスタマーサクセス含め全方位の絶え間ない挑戦の結果だと感じます。

　ふたつ目は課題軸のコミュニティーです。テーマはプロジェクト管理です。ITに関わるありとあらゆる場所で、プロジェクト管理のメソッドは必要になります。プロジェクト管理のツールを提供している会社の看板はついていますが、北は北海道から南は九州まで毎月どこかでミートアップが開催され、わずか2年の間にコミュニティーは自走化し自己組織化された状態で運営されています。

　どのミートアップもUGCであるツイートまとめやブログレポートを生み出すポテンシャルを持ち、普遍的なテーマであるプロジェクト管理の知見を惜しげもなく披露する多くの登壇者に恵まれ、次々に新規参画者を獲得してサステナブルに継続しています。

　年次のカンファレンスもベンダーからユーザー主体で開催され直近では、単一の製品を冠しているにも関わらず300名以上の来場者を迎え成功裡に開催されました。

　続いて、筆者が考えるふたつの成功要因をお知らせします。

　最初にいえるのは製品軸から早い段階で課題軸にシフトしたことです。プロジェクト管理の学びに終わりはありません。サービスに依存しないテーマは枯れることはありません。プロジェクト管理の事例を知り、共に学ぶ仲間を得て、明日の課題解決に繋がる知見を持ち帰れる場です。

　もうひとつは、ベンダーサイドのコミュニティーマネージャや経営層含め、その自走化を全面的にバックアップしてくれているという点です。製品・サービスそのものである製品軸ではないため、毎回手に余るほどの直接的なフィードバックがある訳ではありません。一方でその製品・サービスが扱うべきイシューに関わるひとつとして同じものがないストーリーを生で聞ける場になっています。

　製品軸と課題軸、関心軸の違いはあっても機能する根本はユーザーと真剣に向き合った結果、あるべき姿になったと感じます。自社の形を作って行きましょう。

A.企業マーケティングの枠を超え、コミュニティーが自走しているのが成功の証（長内 毅志）

　DevRelが成功しているかどうかは、各企業のKPIによって異なるため、一概には言いづらいものがあります。外から見ていると「あの企業はDevRelに成功している」ように見えていても、社内のKPI設定が非常に高く、その企業のDevRel担当者は評価されていないケースもあり、驚くことがあります。ここでは「外部から見て、成功しているように見える企業」という尺度で記述したいと思います。

　その企業のDevRelが成功しているかどうかは、企業のマーケティング活動の枠を超え、その企業・サービスのユーザーコミュニティーが自らの意思で自走し、参加者を増やし、周囲に影響を与えているかどうか、という評価でよいと思います。外部からの判断という条件では、定量的な評価は難しく定性的な評価となります。

　その上で、DevRelに成功しているのは次のような企業ではないでしょうか。

　・AWS（Amazon）

　・Microsoft

　・Google

　・IBM

　・サイボウズ

　AWSはDevRelの成功例として、もっとも有名な事例のひとつといえるでしょう。JAWS-UGという名称で各地にユーザーグループが立ち上がり、自主的に勉強会を開催。技術分野ごとに分科会というグループを作り、アメーバのように自己増殖しています。Microsoftも、DevRelに成功している企業のひとつです。「MVP」という独自の顕彰制度を作り、ユーザーの自発的な活動を裏から支えています。Microsoftはドキュメントに対する修正・校正をプルリクエストで受け付けていますが、ユーザーが自発的に修正作業を行い、品質の高いドキュメント作成に自ら貢献しています。同様の仕組みはIBMにもあり、「IBM Champion」という名称でユーザーたちの自発的な活動を促しています。

　ちょっと毛色が違うのはGoogleです。Google自体のサービスに対するDevRelの枠を超えて「HTML5」「PWA」など、次世代のウェブ技術・ネット技術のコンセプトを提示し、そのユーザーグループ活動を裏から支えています。広い視点で見ると、Googleが提唱する次代の技術の啓蒙に成功しています。

　海外の巨大企業ばかりになってしまったので、日本企業としては「サイボウズ」を挙げたいと思います。サイボウズは「kintone」というサービスにコミットする技術者を集めてカンファレンスを行ったり、自社ユーザーを巻き込んだ定期的なイベント・情報発信を下支えしています。DevRelに成功している企業のひとつといえるでしょう。

Q2.DevRelについて教えてくれる人がいません。まず何からはじめればいいですか？

A.最初は興味を持っている人と共同作業で始めましょう（長内 毅志）

　もしあなたが担当しているサービス・製品が魅力的で、すでにユーザーが存在する場合、きっとあなたのサービス・製品についてもっと知りたい、というユーザーさんや開発者の方がいらっしゃると思います。最初は大規模な形ではなく、お茶会や飲み会など、ごく小さなコミュニケーションから始めてみませんか。

　最初から予算をつけて、大規模なイベントを行って…と考えると、意外に行動に移しづらいものです。どんなに大規模なコミュニティーも、最初はごく少数のメンバーから始まることがほとんどです。コミュニティーと呼べるものが存在しないのに、あなたが担当しているサービス・製品についてブログを書いたり、Twitterに投稿している人がいるとしたら、まずは声をかけてみるとよいでしょう。共通の話題を持つ者同士、きっと話題に困ることはないでしょう。

　ユーザーの皆さんは、サービス・製品に対する好意的な声とともに、「こんな情報がほしい」「こんなイベントがあればよいのに」など、なんらかの要望を持っているかもしれません。そんな要望の声こそ、DevRelとしてあなたが対応していく仕事となっていくはずです。そして、そんな活動に同意し、支援してくれるユーザーの皆さんもきっと少しずつ現れてくることでしょう。一個人が持つ情報や知恵には限りがあります。大勢の声を集めることで、より具体的で、みんなが喜べるDevRelのアクティビティを形作ることができます。

　そして、DevRelの理念や活動に賛同してくれる人を少しずつ増やしていきましょう。あなたが所属する会社・組織・部署に、あなたが考えていること、成し遂げたいことを伝えて、味方になってくれる人を見つけましょう。内部、そして外部に賛同者をひろげて、人と人とのネットワークをつなげていき、共同作業でDevRelを始めていく。最初は小さな共同作業でも、集まる人が増えるごとに、より活発な、規模の大きな活動になっていくことでしょう。

A.まずはコミュニティーに参加してみましょう（萩野 たいじ）

　DevRel、つまりDeveloper Relationsは、自社サービスや製品を提供している会社にとって今でこそ重要なキーワードとして認識されつつありますが、少し前まではあまり馴染みのない言葉でした。もちろん、同等の活動はこれまでもされてきましたが、それをDevRelと呼ぶことはあまりなかったように思います。

　世界規模で、DevRelのカンファレンスや勉強会、ワークショップなどが開催されています。海外の一部の国ではだいぶ浸透してきたこのDevRelという言葉も、日本ではまだまだ知られていないことも多いでしょう。

　そんな市場なわけですから、周りにDevRelを知っている人、教えてくれる人、気軽に聞ける人がいないのも無理はありません。

　東京エリアににりますが、DevRel Meetup in Tokyoというコミュニティーがあります。本書で回答しているメンバーも同コミュニティーのメンバーです。月に一度はMeetupという形でコミュニティーイベント（勉強会）を開催しています。このようなコミュニティーは初心者へ親切なところが多いと思うので、ぜひ怖がらずに飛び込んでみてはいかがでしょうか？

　多くのコミュニティーグループは、FacebookグループやSlackチャネルなど、オンラインでもコミュニケーションが取れるようにツールを使って場を作っているはずです。いきなりオンサイト参加はちょっと……、という方はぜひこのようなオンラインコミュニティーの場も活用してみてはいかがでしょうか？

　DevRel活動は、テクニカル（テクノロジー）エバンジェリストやデベロッパーアドボケイトが担うことが多いと思います。会社によってはセールスエンジニアやソリューションアーキテクトといった人たちが担当することもあるでしょう。

　このようなロール（Role：役割）の人たちは、得てして孤独になることが多いです。そこそこの大企業なら職場内に同じロールの人が居るケースはありえますが、そうでない場合はひとりだけ、なんてこともよくあります。そうなると、相談相手が自然と外部になります。コミュニティーへの積極的な参加は、今後自分自身がエバンジェリストやアドボケイトとしてDevRelを行っていく上での大事な仲間を作る場所にもなり得るのです。

A.入り口をしっかりと作り、外部の勉強会に参加しましょう（中津川 篤司）

　DevRelの基礎知識はあるという前提で書きます。計画を立てるべきという当たり前なことも省いたとして、施策として行いやすいのはオンラインコンテンツの整備と外部で行われている勉強会への参加ではないでしょうか。オンラインコンテンツはブログやWebサイト、ドキュメントが該当します。Webサイトに訪問した開発者があなたのサービスを見て、試したいと思う仕組みを整えておかないといけません。また、試す上で必要なドキュメントやチュートリアルも最低限必要です。これがないと、いくら広報して流入を増やしても無駄になってしまいます。むしろサービスを見て失望する分、マイナスであるともいえます。

　流入した開発者をしっかりとキャッチできる体制ができあがったら、日夜行われている勉強会へ参加してみましょう。そこに集まっている開発者はあなたが狙っている人たちに他なりません。とはいえ、そこで営業するのはもってのほかです。彼らと話をし、どんな課題感があるか、どんな解決策を選んでいるのか聞いてみましょう。そして自分たちのサービスがよいと感じてもらえる人たちがいれば、あとで案内して試してもらうのもよいでしょう。繰り返し勉強会に参加している内に、登壇を依頼されることもあるかも知れません。それは自分たちの知見を共有し、さらに大きなフィードバックをもらうチャンスです。

　結論としては、まず開発者が登録し、使ってもらうまでの流れをきちんと作りましょう。勉強会への参加はそれと平行して行えるでしょう。入り口が雑な作りになっていると、呼び込んだ開発者はザルに水を流すごとく、どんどん流れてしまうでしょう。

Q3.ライバル会社のDevRelチームと仲よくするなんてあり得ませんか？

A.所属組織の方針に反しなければ、交流するメリットは大きいのでは（長内 毅志）

　DevRelやデベロッパーアドボケイトは、開発者とコミュニケーションを取るために、人前に出ることが多い職種です。所属する企業・組織によっては、他社のDevRelや開発者とのコミュニケーションに対してルールを設けている会社も存在します。所属する企業・組織が他社のDevRelとの交流・情報交換を禁止している場合、基本的にはそのルールに従うべきでしょう。一方で、特別な制限がない場合は、交流するメリットは大きいのではないでしょうか。

　一般的に、企業規模が大きければ大きいほど、その企業に所属するスタッフの発言は注意が必要です。悪意のある第三者やメディアが、揚げ足を取って企業に対する批判・攻撃に利用されるケースがあるからです。そのようなリスクを避けるため、大手企業ではSNSによる発信や他者との情報交換に制限をかけることがあります。ある企業は、SNSによる情報発信や人前で自社名を明かす場合、情報発信のための試験を受け合格する必要があり、試験に合格しない限り情報発信を禁じているそうです。このように、自分が所属する企業が公の場での情報発信や交流に対してルールを設けている場合、基本的にそのルールに従うべきでしょう。

　一方で、特に制限やルールがない場合、他社のDevRelとの交流は得るものが多いでしょう。デメリットよりもメリットの方が多いのではないでしょうか。公の場で情報発信を行う立場の人間は、相応のルール・マナーを弁えていることでしょう。そんなDevRel担当者の情報発信や、人前での振る舞い方、開発者との交流方法は、何よりDevRelという仕事の生きた教材であり、参考にするべき対象です。他社のDevRel担当者との交流によって、新たな発見や情報を得ることはきっと多いでしょう。もちろん、交流にあたってはギブアンドテイクの精神で、与えてもらうだけでなく、積極的に自分からも情報発信をしてみましょう。互いに情報交換を行い、勉強し合うことで、自分自身に対するプラスのフィードバックが多くなっていくことでしょう。

A.むしろ積極的に関係を構築されることをお勧めします（萩野 たいじ）

　この質問はよく聞かれます。もちろん、人によって考え方も異なると思うので、私の見解が必ずしも正しいとも限らないですし、シチュエーションによっては当てはまらないかもしれません。それを踏まえてお答えします。

　基本的にエバンジェリストやアドボケイトという人は孤独な場合が多いです。それは仲のよい同僚が社内に居ないという意味では無く、エバンジェリズムやアドボカシーについてその意味をちゃんと理解し共感してくれる人が社内になかなか居ないという意味です。多くのケースでは、社内で新たにDevRelチームを立ち上げ、これから施策を打っていく、という感じかと思います。それは、別の質問で回答していますがエバンジェリストやアドボケイトの役割というのは短命だからです。社内の理解を得て、社員全員がDevRelに対しての理解が深まった頃、きっとその会社はすでにDevRelチームが不要になっているかもしれません。

　そうなると、DevRelを推進する人（きっとエバンジェリストやアドボケイトと名の付く人）は、なにか困ったことや相談したいことがあった時に一緒に共感して考えてくれる仲間は社外にいることが多くなるかもしれません。

　また、A社とB社が技術領域で競合だったとしても、双方のエバンジェリスト達が一緒にイベントを実施することも少なくありません。これは、自分たちがコンペであるということはいったん置いておいて、広い意味でのお互いの技術領域の市場を広めたい、といった場合に起こりうるでしょう。IoTやブロックチェーン、PaaSのCloudなんかは分かりやすい例だと思います。

　と、いうことで他社のDevRelチームと仲よくすることは悪いことではありません。情報統制を意識した上で適切に関係を構築されるとよいでしょう。

A.仲よくしないなんてあり得ないと思います（山崎 亘）

　ライバル会社ならば同様な製品なので同様の悩みを抱えていることが多く、定例ミーティングまでをする必要はないとしても、たまにコミュニケーションをとって解決方法を共有したりできるなど、お互いよい刺激になるはずです。大前提に「重要な機密情報を共有しない」ということがありますが、これは何もライバル会社でなくても当たり前の話ですね。

　逆につまらないことでライバル会社の悪口を言ったり、毛嫌いしたりする態度はユーザーにも見えてしまい、DevRelとしては上手いやり方ではないでしょう。DevRel担当的にはあくまでもニュートラルな（少なくともそう見えるような）態度で顧客視点の姿勢を貫くのがいいです。ライバル会社の製品のよいところは敬意を表して素直に認め、その上で自社製品のよいところを説明する。ライバル会社のDevRelチームと仲よくするというのは、そういう姿勢の一貫だと思います。

　ライバル会社のやり方を見て、相手が自社よりも上手くやっていることがあれば、自社内で共有し、追いつき追い越せというモチベーションをライバル心を活用して高めていくのもよいでしょう。最終的にはアウトプットを最大限にすることもできるはずです。

　また、自社製品のカテゴリーの市場がまだ小さい場合、小さなパイを取り合うのではなくマーケットを拡げてより大きな需要を喚起するために、競合他社と協力して技術セミナーを開催するということもできます。このあたりは製品戦略とも絡んでくるので、製品マーケティング担当などと話し合いながら決めていくとよいです。

　実際に私も先日、競合となるだろうなと思われる製品の担当者をイベントで見かけたので紹介してもらいました。「協力してマーケットを拡げていきましょう」と握手を交わしました。同士のようで嬉しかったです。

Q4.日本のDevRelと海外のDevRelって違いはあるんでしょうか？

A.個々の施策に大きな違いはありません。今後は分かりませんが……（中津川 篤司）

　日本と欧米（シリコンバレーなど）での違いについていえば、個々の施策については大きな違いはないといえます。土地が広いので小さな勉強会は多くないですが、ハッカソンに参加したり、オンラインコミュニティーは盛んです。イベントを行う場合は、その開始時間やスタイルに各国の特性が出たりします。たとえばアメリカの場合は18時くらいから行われることが多いようです。シンガポールでも同様です。シンガポールは最初に懇親会があり、食事が出ます。その食事に引きつけられて参加者がある程度集まった段階でセッションがスタートします。インドは平日夜よりも土曜日の午前中が盛んだと説明を受けました。土地の治安などによっても変わるでしょう。

　日本のDevRelでは国内の限られた開発者に対してアプローチするため、狭く深くなります。自ずと開発者との繋がりは強固なものになりがちです。海外の場合、英語圏という意味では全世界中がターゲットになるので、広く浅い施策を選ぶようになります。全世界でイベントを行う場合でも、経済圏の大きな国の首都のみが選ばれるでしょう。日本のように地方都市では行われません。ただし、リーチできる数は圧倒的に英語圏の方が多くなります。

　国内市場がある程度大きい現在においては特に問題にはならないでしょう。日本企業が日本人開発者をターゲットにDevRelを行えば一定規模の経済圏を作れます。英語圏の情報をローカライズして書籍にしても一定の冊数販売されます。しかし今後経済状況が悪化するようなことがあると、日本企業においても最初から海外をターゲットにしてDevRelを行わないといけなくなるでしょう。

A.ユーザーとなる開発者との距離じゃないですか（山崎 亘）

　以前、シリコンバレーに本社があるITの会社に所属していました。年に一度全世界のDevRel、デベロッパーマーケティングの担当が集まって各自の活動の発表をしたり、ディスカッションしたりしました。しっかりとしたデータ（ファクト）に基づいた結論ではないのですが、この会議に何回か出席したり他国の担当と話したりした感想からいうと、やはりユーザーとなる開発者との距離ではないでしょうか。そして、それによって生じるのが、オンラインとオフラインの比率だと思いました。

　まず比較元となる日本から定義してみます。やはり、活動の対象となる開発者が圧倒的に東京に集中しています。ミートアップやイベントなどのリアル イベント、オフライン イベントは東京をカバーすれば、かなりの割合で対応可能です。オフラインの活動を中心に据えて、オンラインでの活動を展開するのが効果的です。

　さて、海外で、たとえば北アメリカの場合、大都市が複数あり時差もあるため、オンラインがベースになっています。セミナーもウェビナー（Webセミナー）で開催します。オンラインの活動を中心に、たまに、大きなカンファレンスに集まってくるように仕立てています。この場合には全米から集まるというよりも、全世界から集まる感じです。

　日本以外のアジアの場合、言葉の壁があるせいか、オンラインで展開というよりは、中小都市でコミュニティー活動を展開しているようでした。日本は近いのですが、やはり言葉の壁のせいでお互い行き来して効率化するのは、なかなかできません。

　ヨーロッパもアジアと雰囲気は近い気もしますが、こちらはもう少し言葉の壁が低く、英語でオンライン展開できているようでした。

　グローバル チームの一員だと、ベストプラクティスの共有やコンテンツ リソースの共有ができるし、同じ製品で同様な悩みを抱える人たちとコミュニケーションが取れるのは嬉しいものです。日本企業に転職して同様な体験はできなくなったと思いましたが、年に一度のDevRelCon Tokyoに参加すると「DevRel」という同じ境遇の世界の人と交流ができました。他国のDevRelと関わりたい人には、このカンファレンスはお勧めです。