「DevRel」ってなんだろう

はじめに

皆さん、はじめまして。MOONGIFTの中津川と申します。本連載では、最近よく聞かれるようになった「DevRel」(デブレルと読みます)について、開発者の目線で事例を含めながら紹介していきます。多数のテックカンパニーがDevRelを取り入れてサービス提供を行っている現在、多くの開発者たちがその一端に触れた経験があるはずです。今はまだDevRelの意味を知らなくとも、読み進めていくうちに「ああ、あれがDevRelだったのか」と思ってもらえるでしょう。

DevRelは「Developer Relations」の略語で、簡単に言えば「自社や自社製品と外部の開発者との良好な関係性」を形成するためのマーケティング活動になります。そんなDevRelはビッグテック(GAFAM)はもちろんのこと、小さなスタートアップ企業でも実践されています。例えばブログ記事の執筆、コミュニティ活動、ハッカソンへの協賛、年次の開発者カンファレンスを催すといった具合です。

Facebookの開発者カンファレンスf8の様子

年次の開発者カンファレンスとしては、有名なところでAppleの「WWDC」、Googleの「Google I/O」、Facebookの「f8」、AWSの「AWS Dev Day」などがよく知られています。そうした開発者向けのカンファレンスでは多くの開発者が集って新しいサービスに関する発表を聞いたり、その場にいるエンジニアに質問したりして自社サービスを宣伝しています。これは大規模なカンファレンスの例ですが、小さなブログ記事やソーシャルメディアでの発信もDevRelの大事な施策です。

なぜDevRelを行うのか

では、そもそもなぜ企業はDevRelを行っているのでしょうか。その理由は簡単で、企業が自分たちのサービスや製品を開発者に使って欲しいからです。特にAppleでいうiOS、GoogleでいうAndroidなどのプラットフォームにおいては、自社開発するOSやアプリだけでは魅力はほとんどありません。その上で動くアプリが魅力を作ってくれるのです。

スマートフォンを電話としてだけ使っている人はごくごくわずかでしょう。多くの人がYouTubeやLINEなどのアプリ、さらに数多あるゲームアプリを利用しているはずです。これらはプラットフォーマーであるAppleやGoogleが開発しているものはごく僅かで、大多数がサードパーティーの開発者の手によるものです。AppleやGoogleは自社プラットフォームの魅力を宣伝することで、開発者を引きつけているのです。そして開発者がプラットフォーム上で動くアプリを開発することで、プラットフォームの魅力が増大します。

プラットフォームを魅力的にするのはサードパーティーの開発するソフトウェア

プラットフォーマーに限らず、API提供企業においてもDevRelは重要です。APIの多くはシステム内部に組み込まれます。そして一旦組み込んでしまえば、正しく動き続ける限り早々に乗り換えることはありません。従って、開発者に魅力を伝えて組み込んでもらえれば、システムを使い続けてもらえるのです。大抵のAPIは排他的であり、類似した機能を提供するAPIを複数使うことはあまりないでしょう。同じクレジットカード決済APIを複数選定する理由があるとすれば、メインで障害が発生したときの控えとしてくらいですが、そうした予備を用意するケースは多くありません。その意味において、選ばれることの重要性はお分かりいただけるかと思います。

DevRelを活用して成長したサービスの例

DevRelがサービスを飛躍的に成長させた例として、Twitterがよく知られています。Twitterはサービスリリース当初からAPIを公開していました。今でこそOAuthによる安全なAPI提供となっていますが、リリース当初はBASIC認証だけで使える状態でした。セキュリティ上の課題はありましたが、その緩さから数多くのTwitterクライアントや関連サービスが生み出されていったのです。Webブラウザ版のTwitterはほとんど使われず、多くのユーザーがサードパーティー製のTwitterクライアントを利用していました。その中からリツイートの文化が生まれたり、数多くのサービスがTwitter連携機能を開発していったのは記憶に新しいでしょう。

さらに、同じソーシャルサービスを例にすると、Facebookの躍進を支えたのも開発者の力だったと言えます。FacebookアプリはFacebookの中で動作するWebアプリケーションで、農場系ゲームや診断アプリなど様々なものを誕生させました。JavaScriptだけで使える認証機能や、今はGraphQLと呼ばれるFQL(Facebook Query Language)もFacebookアプリ開発では欠かせない存在でした。それまでMySpaceというソーシャルサービスに押されていたFacebookは、このFacebookアプリによって一気に世界的なSNSに成長したと言っても過言ではありません。

最近であればGitHubが人気を集めたのも、DevRelによるところが大きかったと言えます。彼らは学生向けのプランを提供したり、数多くのハッカソンやカンファレンスにスポンサードしています。GitHubの有名なキャラクターであるMonalisaの多種多様なステッカーは、何かのカンファレンスや技術系勉強会に参加したことがある人はもらった経験があるのではないでしょうか。MonalisaがGitHub成功のカギだったという訳ではありませんが、Monalisaに似た動物などのキャラクターを作成する風潮がテックカンパニー界隈でしばらく続きました。

日本企業も欧米に比べると数は少ないですが、DevRelに取り組んでいる企業はあります。例えばSORACOMは元々AWSでエバンジェリストをされていた玉川社長とあって、効果的にDevRelに取り組んでいる企業です。その成長速度はすさまじく、あっと言う間に200億円企業としてKDDIに買収されました。さくらインターネットはDevRelに関係する専門チームがあり、全社員の約1%がチームに在籍しています。kintoneは外部エバンジェリスト制度があり、コミュニティ活動も活発です。クラスメソッドのDevelopersIOは、企業としての発信文化を強固に形成し、事業活動上も大きな役割を担っています。Forkwellは元々イベント活動をサポートしてきましたが、コロナ禍になってからは自社主催イベントを強化しています。そして昨年末にはDevRelチームを専門的に立ち上げるに至っています。

このように、日本企業でもDevRelを行うところが増えています。それは海外のDevRelを真似るだけでなく、日本独自の方法も少なくありません。

DevRelとPRは何が違うのか

さて、話をDevRelに戻しますが、DevRelを理解してもらうためにPublic Relations(PR)について触れておきます。日本ではPRというとプレスリリースのことだと思われがちですが、世界的にはPRというとPublic Relationsを意味します。そして、このPRとは日本語で広報になるのですが、日本で広報というと情報発信を行うイメージが強いでしょう。しかし、本来のPublic Relationsの意味合いでは広報はもちろんですが、傾聴(耳を傾ける)という意味もあります。つまり、発信とともにユーザーボイスを聞くのも大事な機能なのです。

Public Relationsの分かりやすい例として、あなたの近所に大きなモール建設計画が持ち上がったことをイメージしてください。利点はありますが、問題点も多数あるでしょう。モールに向かう車で付近の道路が大渋滞したり、近くの森を切り開くため環境悪化が問題になるかも知れません。治安が悪くなる懸念もありますし、何より昔ながらの商店街にとっては大打撃でしょう。そうした問題によって、住民を中心に建設反対運動が起こることもしばしばあります。その際に企業側の窓口となるのが広報担当者です。広報担当者は多数のステークホルダー(利害関係者)と対話し、落とし所を見つけるのが役割です。

近所にモールができる際に懸念される問題

落とし所とは、例えば駐車場の位置を工夫して幹線道路に渋滞ができないようにしたり、モールの近くに交番を誘致する、モール内に地元商店街の商品を扱うスペースを作るなどといった具合です。家族向けに公園を新設するのも良いかもしれません。そうした住民や商店が納得できる条件を提示したり、要望を企業に持ち帰って検討するのが広報の役割です。企業は自分勝手に物ごとを進められる訳ではなく、社会の一員として受け入れてもらえるように環境を整える必要があるのです。

開発者の社会に受け入れられる必要がある

そして、このPRの開発者版がDevRel(Developer Relations)です。クラウドサービスをはじめ、開発者向けにサービスを提供する企業は開発者の社会に受け入れてもらわなければいけません。個人の開発者もちろん、企業やコミュニティにも信頼されなければ使ってもらえません。そのため、単に自分たちが良いと思うものを作るのではなく、開発者からフィードバックをもらったり、世の中のトレンドを受けとめて製品開発に活かしています。これもDevRelの大きな役割の1つです。

DevRelが注目される理由

なぜ、ここ数年DevRelが注目されているのでしょうか。まず「広告の費用対効果が悪い」点が挙げられます。こと開発者に対する広告(AdWordsやバナー広告など)はクリック率が非常に悪いです。なぜ広告が効果的ではないのかと言うと、開発者は普段の仕事やプライベートにおいてインターネットの利用時間が他職種と比べて圧倒的に長いからです。その際、数多くの広告コンテンツに触れ続けている結果、広告コンテンツ(PRと書いてあったり、バナーだったり)が見えなくなるようなフィルタリングを獲得してしまうのです。

そこでDevRelでは、自社サービスを知ってもらうためにブログを書いたり、ソーシャルメディアでの発信、勉強会の開催など日々のアクティビティを通じた宣伝活動を行っています。さらに使い方に困っているユーザーがいればサポートしたり、ドキュメントを整備するなど利用する際に困らないように開発環境を整えます。使ってみたけれど何かエラーが出て動かない、ユーザー登録が手間、クレジットカード登録が必須など開発者が苦痛に感じるポイントを極力なくしていくことで、自社サービスを使い続けてもらえるように促すのです。

次に「サービスの乱立化」が挙げられます。何か新しいサービスが流行ると、それを模倣するようなサービスが雨後の竹の子のように次々に登場します。クラウドサービスが整っている現代では、開発力さえあれば似たようなサービスを作るのはさほど難しくありません。すでに先駆者たるサービスがあれば、それを真似て管理画面を作ったり、APIを用意できます。

技術的に大きな差がない中で他社との差別化を図る上で重要なのがDevRelです。UIやAPIは模倣するのが容易ですが、コミュニティやQ&Aなどを通じて培った開発者とのつながりは一朝一夕に真似できるものではありません。そうした開発者との感情的なつながりがサービスの差別化につながるケースは少なくありません。

サービス選定する際に、人は完璧に理性的であるとは言い切れません。意外と感情的(エモーショナル)な決断を下すことはよくあります。例えば身近な人が教えてくれたり、すでに過去に導入した経験がある、ブランドへの安心感などが選定理由になるケースは多いです。毎回理性的に、機能差を吟味して判断することはあまりないでしょう。そうした「選んでもらえる理由」を作るのもDevRelの重要な仕事なのです。

開発者に必要なもの

2006年頃に発売された書籍に「ドリルを売るには穴を売れ」があります。これはワカサギ釣りを想像してもらうと分かりやすいのですが、釣りをしたい人に氷に穴を空けるドリルを売るのは筋が悪く、ドリルを使って氷に空けた穴を売るべきだという考えです。顧客はドリルが欲しいのではなく釣りをしたいのだから、穴を掘ってそれを売れば良いのです。確かに一般消費者を対象にするならその通りですが、開発者に対する考え方としては異なります。

開発者に売るならば、もっと格好良く穴が掘れるドリルです。シャープで綺麗な穴が掘れたり、またはもっと高速に穴が掘れるドリルです。APIが用意されていて、外部からコントロールできるドリルも良さそうです。開発者はそのドリルを使って素晴らしい穴を掘り、顧客に提供できるのです。つまり開発者が必要とするのは、もっと彼らの仕事をスマートにしてくれる道具であったり、何度も繰り返し行ってきてうんざりしている作業を省略化してくれるサービスになるでしょう。

一般的なマーケティングと開発者向けマーケティングの違い

そのため、ある程度の先進性があったり、使っていて周囲からすごいと思われるようなサービスが好まれます。有名なサービスを真似たようなものは好まれません。ただ安価なだけのサービスも好かれないでしょう。開発者に選ばれるサービスには、心に刺さるメッセージやデザイン、機能など、統合的な価値が必要となります。それもまた「選んでもらえる理由」の1つなのです。

おわりに

今回は「そもそもDevRelとは何か」について概要を紹介しました。次回以降は、より各論を深掘りして解説していきます。最近ではDevRelに関係する求人も増えており、それらは開発者としてのバックグラウンドを必要としています。ぜひDevRelに興味を持っていただき、そうしたキャリアパスがあることを知って欲しいです。

筆者はこのDevRelを広める活動を2015年から行っていますが、年々求められる役割の広がりや提供する企業の拡大を感じています。DevRelを知って、ぜひ皆さんの会社でも実践してみてください。