DevRelを「開発者向け製品、サービスを広めるためのマーケティング手法」として見てしまうと、そういったサービスを作っていないと使えないものだと思ってしまいます。しかし、DevRelは開発者との良好かつ継続的な繋がり（リレーション）を形成するものなので、もっと活用できる幅が大きい取り組みです。

今回はDevRelを三つの視点から見て、その価値を考えてみます。

直接収益型

自社の製品やサービスを利用してもらうことがそのまま自社利益につながるものです。例えばAWS、GCPなどのIaaS、StripeやAuth0などのSaaSベンダーなどが該当します。APIを有料提供している場合もそうです。この場合、DevRelによって開発者に採用してもらえば、それがそのまま収益増につながりますので、取り組みがコストとして算出されやすくなります。この場合、マーケティング部門下にDevRelチームがいると予算配分上、動きやすくなります。

直接収益型の場合、DevRelの価値は利用ユーザ数、問い合わせ数、APIコール数、アクティブ率、事例数などにフォーカスして見られるでしょう。利用ユーザ数を増やすのであればハンズオンが有効になり、事例を増やすのであればハッカソンなどが取り組みやすい施策になります。

いずれにしても直接収益型はDevRelを行いやすく、メリットも見出しやすい形式になるでしょう。

間接収益型

本体サービスの収益源は別にあり、その補助や知名度を増すためにAPIを提供したりするケースです。例えばレストランサービスのAPIであったり、社会的意義で提供されるAPIなどが該当します。ビジネス利用においては応相談なケースが多く、実際の事例に繋がる例は多くないです。この場合のDevRelは開発者向けの知名度向上が目的になっていることが多いので、DevRelチームは開発部門にいる方がメリットがあります。開発者からのフィードバックがスムーズに社内に浸透できたり、イベントなども開発者視点で行えるでしょう。

間接収益型の場合、収益が目的でない分、目標が定めづらいという問題があります。ユーザ数を増やしても収益になる訳ではなく、むしろサーバ負荷が増すだけでコスト増になります。APIコール数も同様です。本体サービスが開発者をターゲットとしていない場合、開発者への知名度向上が収益増に繋がらず、施策の打ちづらさはあります。

収益に関係ないのだから、と公開したAPIを放置するのは良くありません。思わぬセキュリティホールに繋がったり、古いドキュメントが放置されることで本体サービスへの信頼性も疑われてしまうでしょう。APIを公開するのであれば、自ら利用するドッグフーディングできるものに限定するのが良いでしょう（本来は逆で、自分たちが使っているものを公開すべきです）。

間接収益型で可能性があるのは、企業間連携の話が出た時です。APIがあることでサービス連携する際の開発がスムーズに行われます。APIがないと、初めて連携する企業側のニーズに合わせてAPIを開発することになります。その結果、別な企業との連携では使えないAPIになる可能性があります。また、APIが公開されていないとそもそも連携対象外になることがあります。

ブランディング型

最後はブランディング目的です。この場合、主導するのは広報や人事になります。ブランディングの場合もDevRelチームは開発チーム内にある方が良いでしょう。現場の開発を継続していることで、常に新しい話題が提供できます。好例としてはクックパッドやクラスメソッドになります（DevRelチームという形ではないと思いますが）。目的としては会社のブランディング、開発者の採用増にあるでしょう。

例えば技術ブログやカンファレンスへのブース出展などが施策として行われます。逆にユーザコミュニティなどは立ち上げづらいでしょう。自社が得意としている開発言語をテーマとしたコミュニティを形成するのも良くあるケースです。ブランディングは数値化が難しいですが、採用エントリー数であれば定量的に数えられるので取り組みやすい施策になります。

ブランディングはもちろん、直接収益型や間接収益型でも目指しているでしょう。とはいえメッセージが複数あると対象層に響きづらくなるので注意が必要です。

間接収益型の課題

問題は間接収益型におけるDevRelの取り組みと継続性でしょう。2004年くらいのWeb2.0が騒がれた時、多くの企業がAPI提供を行いましたが、その多くは情報発信のみでコンテンツが生成できないものでした。これらのAPIは今なお提供され続けていますが、殆ど放置に近い状態です。かといって、利用者が増えたところで収益につながる訳でもなく、あえてテコ入れする必要性がないでしょう。将来的にアーキテクチャが大きく変わったりすると、突然APIを閉じる可能性があります。提供側としては無料で提供しているのだから、告知期間だけ設ければ良いと考えがちですが、開発者にとっては迷惑この上ないでしょう。

かつてGoogleマップ APIは無料でしたが、現在は有料化されています。これによって開発者にすれば継続性の担保ができ、Googleとしてはコストからプロフィット部門にスイッチできたと言えます。無料枠もあるので多くの場合影響は少ないですが、有料化の動きは良いものだと考えています。特にGoogleはすぐにサービスを閉鎖する悪い癖があるので、有料化によってSLAの意味でもおいそれと終了しなくなったでしょう。

同様に間接収益型として開発者向けの機能を提供している場合には、収益化やテコ入れを考えるか、いっそのこと止めるかを検討すべきでしょう。サーバ上のコストも安いので安穏と放置した結果、セキュリティホールが見つかったり、メンテナンスもされないドキュメントを公開し続けるのは本体サービスへの不信につながる恐れがあります。

まとめ

DevRelはマーケティング施策なので、きちんと目標を決めた上で取り組むべきです。目標がないと、突然経営陣に「何のためにやっているんだっけ」と聞かれかねません。コストメリットがきちんと打ち出せ、継続的にやる価値がある活動であることを示せなければなりません。

MOONGIFTではDevRel全般に対するサポートを行っています。直接収益型はもちろん、間接収益型の改善、ブランディング型の体制作りなどDevRelに関する相談はお気軽にどうぞ！。