OFFICIAL SNS
ここ最近、各社でDevRelチームを立ち上げました！という話題が聞かれるようになっています。
各企業において、DevRelの重要性を理解してもらいつつあるのが嬉しい半面、「これってDevRelだっけ？」的な意見もちらほら散見されるようになっています。
そもそもDevRelという単語が具体的な何かを指し示している訳でないので、拡大解釈しやすいという課題があります。その結果として「俺の考える最強のDevRel」が出てきたり、ともすると「こんなのDevRelじゃねえ」といった原理主義にも陥ります。
そこで、私の立場（2014年からDevRelをサービスとして提供していたり、DevRelを広めるためのコミュニティDevRel Meetup in Tokyoを主催していたり…）から、DevRelの定義を説明しておきます。
DevRelと似た言葉にPR（パブリックリレーションズ）があります。パブリックは一般市民のことで、リレーションズは関係性です。Wikipediaによると、以下のように定義されています。
個人・組織の目標を達成するためには彼らと良好な関係を築くことが不可欠である。この公衆（パブリック）に対して情報・意見を双方向に伝え受け入れながら、望ましい関係（リレーションズ）を構築し維持することがパブリック・リレーションズである
このパブリックリレーションズの開発者版が、DevRel（デベロッパーリレーションズ）と言えます。
自社外の開発者と、良好な関係性を築くのがDevRelの目的になります。この時大事なのが、上記にもある「双方向」です。つまり、自社からの発信はもちろんですが、開発者の意見を聞く姿勢も大事ということです。
だって、一方的に話すだけで話を聞いてくれない相手は、信用できないですよね？
パブリックリレーションズはなかなか日本に浸透していないのは、日本では「広報」と訳されているためです。広報と言うと、「広く知らしめる」という意味になってしまって、発信面しか見ていません。傾聴の意味が抜け落ちています。
そのため、広報部は広告などを通じていかに知ってもらうかに注力しがちです。
大事な点として、「傾聴」する機能があるかどうかがDevRelと広報（技術広報とか最近言われているようですが）の大きな違いだと思います。
ではDevRelの目的が「自社外の開発者との良好な関係性を築く」ことにあるならば、DevRelチームがすべきことは何でしょうか？
これは実に多種多様です。前述の通り「これをやればDevRel！」というものはありません。ただ、主に3つのカテゴリーに分けられるのは2016年くらいから変わっていません。
これはDevRelの3Cと呼ばれ、当時SendGrid（現Datadog）のBrandon Westさんが紹介していたものです。拙著でもあるDevRel エンジニアフレンドリーになるための3Cでも取り上げています。
コードでいえば、SDKやデモアプリ、チュートリアル、ライブラリなどが該当するでしょうか。スニペットも入りそうです。
コンテンツは幅広すぎて網羅はできませんが、ブログ記事やドキュメント、動画、音声などコード以外の成果物の多くがコンテンツです。
コミュニティは開発者コミュニティはもとより、イベント（カンファレンスやハッカソン含む）やソーシャルメディア、Q&Aでの対話なども入るでしょう。
DevRelで取り組める施策はとても多いので、「これとこれをやるべき！」みたいなことはとても言えません。自社や事業部のリソース、ステージによって最適なものを選ぶべきです。
DevRelチームで、自社内にいるエンジニアを支援して登壇をサポートしたり、ブログを書いてもらうといった取り組みを行っているケースがあります。これはDevRelでしょうか？
もちろんDevRel活動の一環でしょう（海外ではInternal DevRelとか呼ばれています）。DevRelチームに所属する人たちは、現場を離れたエンジニアも多いので、最新の現場におけるテクノロジーに対して疎くなってしまう場合があります。現場でこそ蓄積されるナレッジは実に多いです。
そうした現場で働くエンジニアが登壇したり、ブログ記事を書いてこそ、開発者に刺さるコンテンツになります。そのような登壇や記事執筆などをサポートすることで、外部の開発者との信頼関係が構築できるなら、それはもちろんDevRel活動になるでしょう。別にDevRelに直接関わる人たちが登壇したり、前面に出ていかなければならないルールはありません。
個人的に「技術広報」という単語には詳しくないのですが、幾つか紹介記事を読んでみました。
いずれの記事においても、やはり「広報 = 発信」にフォーカスしています。
DevRelでは「外部の開発者との関係性構築」を目的としているので、「情報発信」はもちろんですが、開発者との対話やフィードバック、Q&Aなどの「傾聴」が必須要素です。この「傾聴」があるかどうか、目的が発信ではなく、関係性の構築にあるかどうかが違いになるでしょう。
逆に「DevRelとはこれ！」を定義しないことによって、日本だけに限らず各国での独自の施策が生まれています。初期のDevRelはAppleのガイ・カワサキさんからはじまったと言われていますが、その活動は主にMac OS向けのソフトウェア開発者（企業含む）を増やすことにありました。そういった意味でも、DevRelはシリコンバレー発祥の文化と言えます。
そのため、アメリカ式がスタンダードで、他はまがい物！みたいな考えで臨んでいると、大きな失敗につながるでしょう。外資系企業が日本市場に進出する際には、やはり現地の開発者を理解したり、必要としているリソースの提供が求められます。日本語ドキュメントやサポートはよくある話で、アメリカ式が絶対だから英語のドキュメントだけとか言っていたら、確実に使ってもらえないはずです。
日本や中国、インドなど国によってさまざまな文化があります。フランスやオランダ、イギリスなどもそれぞれ開発者の文化が異なり、課題も異なります。それらを正しく理解し、現地の開発者ニーズに合わせたDevRelを実行しないと成功はおぼつかないでしょう。
日本独自の施策としては、たとえば「もくもく会」であったり「マンガ」「技術書典・技書博」などが挙げられます。ヒーローズリーグも長く日本で開催されていますし、アドベントカレンダーも日本が最も活発です。
もちろんインドや中国など、それぞれに独特な文化・施策があります。
もし自社の取り組みがDevRelなのかどうか迷ったら、それが「外部の開発者との関係性・信頼性構築につながっているか」どうかで判断すれば良いでしょう。良好な関係性を築くために行っている！と言えるのであれば、それはDevRel活動の一環と言えるでしょう。
逆に「発信」だけだったり、タレントプールを作るだけ、宣伝にしかつながっていないなら、それはDevRelではありません。それは別な何かなので、別なネーミングを探してください。そこでDevRel風とか言われると、「DevRelとは？🤔」に舞い戻ってしまいます。
日本独自の〜と言いつつも、やはりDevRelが進んでいるのは欧米になります。シリコンバレーではじまった取り組みですし、DevRelに関するグローバルなカンファレンスであるDevRelConはロンドン発祥です。
最近の海外トレンドとしては、コミュニティ重視が挙げられます。認知度向上ももちろん大事ですが、それ以上に開発者コミュニティとの接点を増やしたり、自社製品のコミュニティを構築するという点に注力されています。
また、コロナ禍にあってレイオフの話が話題にあがったのも大きな流れです。その中で、DevRelに求められる役割がより洗練されたようです。予算配分であったり、その中で求められる成果がより厳しくなっています。
後は、DevRelの登場人物（ロール）が増えています。シニア的な立場の人はもちろん、プログラムマネージャー、コミュニティマネージャー、コンテンツライター、DevRelエンジニア…などなどさまざまな職種が出てきています。アメリカではJD（ジョブディスクリプション）ベースの求人なので、求められるタスクによって職種に名前を付けている印象があります。
信頼性とか、関係性をどう数値化するか、それがDevRelにとっての長い長い課題と言えます。でも、これをきちんと解決しないと「DevRelを何のためにやっているんだっけ？」「DevRelやってて意味あったっけ？」という話につながりかねず、その結果として数値が取りやすい施策（主に発信）ばかりに目を向けるようになります。
この関係性をマーケティング用語で言い表すなら、ロイヤリティーになるでしょう。ロイヤリティーの測定は、以下のような項目があります。
この辺りは顧客ロイヤリティーの測定項目として、よく用いられるものになります。ただし、これらは「既存利用ユーザー」向けの測定項目です。他、開発者向けとしてはQ&Aへの質問数や閲覧数などもトラッキングすべき指標です。
DevRelの場合、まだ利用していない開発者の認知度を上げ、ユーザー登録してもらう点も大事です。この辺りの測定はWebサイトのPVやソーシャルメディアのフォロワー数、イベントへの参加者数（継続的参加回数）などを測定します。
とりとめなく書いてしまった感がありますが、大事な点は以下の2点です。
これは、自社製品が開発者向けであるかどうかは重要ではないと思います。「ソフトウェアが世界を飲み込む」とか「DX」とか「内製化」などと言われている現在、開発者に敬遠されるような企業は遠からず淘汰されるでしょう。
また、日本人の人口減少を考慮すれば、限られたパイの取り合いになるのは間違いありません。いかに自社や自社製品を知ってもらい、開発者に選んでもらうかは重要な課題になります。
そして、当たり前ですが「信頼はすぐには築けません」。一歩一歩着実に構築してこそ、揺るぎない信頼性に結びつくのです。そのためのDevRelと考えて取り組んで欲しいです。
メールにてDevRelに関するニュース、アップデートをお送りします。
Contact is below.