どのような企業がDevRelを行うべきなのか
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/ren_devrel_cover_main_0.png?itok=fb6LEYo4)
はじめに
今回は、どのような企業がDevRelを行うべきかについてお話しします。第1回ではビッグテックを中心に挙げていたので、DevRelはグローバルな大手企業しか対象ではないと感じてしまったかも知れません。しかし、それは間違った認識です。小さな企業でもDevRelを行うべきケースは多々あります。自分の会社やサービスがDevRelを行うべきなのか、ぜひ今回の内容を参考に検討してください。
DevRelを行った方が良いか判断するには
DevRelを行った方が良いか否か、その判断基準はとても簡単です。それは「開発者が自社や自社サービスの成長にとって、ステークホルダーかどうか」です。一般的にステークホルダーは株主や従業員、提携企業などが挙げられますが、その1つとして企業外部にいる開発者も含まれるということです。第1回でも紹介した通り、外部の開発者がプラットフォーム向けにアプリケーションを開発してくれたり、APIを使うことでビジネスが成長したりするのであれば、彼らは完璧なステークホルダーであると言えます。
開発者がステークホルダーである場合、そのパターンは大枠で以下の4つが考えられます。この4パターンについて、それぞれどういったDevRelが求められるのかを解説します。
- 開発者向けサービスを提供している場合
- 開発者向けサービスではないが、APIを提供している場合
- 開発者を雇用したい場合
- その他の目的
開発者向けサービスを提供している場合
もしあなたの会社が開発者向けにサービスを提供しているのであれば、間違いなくDevRelを実施すべきです。こうした企業の代表例としてはAppleのApp StoreやGoogleのGoogle Playはもちろんのこと、AWSやMicrosoft Azure、さらにStripe、GitHub、CircleCI、SORACOMなどが挙げられます。おそらくあなたがDevRelと聞いて思いつく企業ではないでしょうか。
21世紀に入って、単に良いものを作るだけでは売れない時代になっています。また、オンラインサービスでは模倣が簡単で、サービスが流行るとすぐに真似したサービスが作られます。そうした中で他社との差別化を図る上ではマーケティングが重要となります。サービスを知ってほしい、利用してほしい開発者に正しく情報を届けなければなりません。そのための手段がDevRelなのです。
DevRelに期待する効果
開発者向けのサービスを提供している場合、予算をかけてDevRelに取り組んだ結果としてユーザー登録者が増えたり、利用量の増加が期待できます。とはいえ、これはプロダクトのステージに応じて異なるでしょう。
・サービスが正式リリース前の段階
クローズドベータなどの状態で特定の開発者に使ってもらっている段階であれば、利用してくれた開発者の意見を取り入れて開発に活かすことが考えられます。これはマーケティングでいうところのPMF(プロダクトマーケットフィット)になります。昨今、様々な家電が作られている中で「こういうんじゃないんだよな」と感じる経験はないでしょうか。余計なボタンが追加されていたり、デファクトスタンダードなサービスとは連携していなかったりといった具合です。企業によって様々な事情はあるでしょうが、市場に求められていない製品を世に送り出しても売れないのが当然でしょう。
オンラインサービスやアプリなどの場合、ハードウェアと比べてPMFが行いやすいのが特徴です。ハードウェアの場合は一旦作ってしまうと変更が難しいですが、ソフトウェアであればコードの修正は容易です。開発者が求めていないものを自己満足で作るのではなく、なるべく早い段階で開発者の意見を取り入れていくのです。
最近ではスマートフォンのOSも早い段階でベータ版を提供し、利用者のフィードバックを得るようにしています。開発者としても自分の意見を聞いてもらえるのは嬉しい体験であり、愛着もわきやすくなります。フィードバックを開発に活かしていく、いわゆるフィードバックループという考え方は正式リリース前に限らず、繰り返し行っていくことが重要です。そうしないと、初期は良かったのに段々と開発者のニーズからずれていくといった事態になりかねません。
この段階での主なDevRelの施策とその期待
主な施策 | 期待 |
---|---|
クローズドベータ提供 | 利用者からのフィードバック |
ドキュメント整備 | リリースに向けた準備 |
・サービスリリース直後
サービスがリリースした直後の場合、最も必要なのは認知度です。リリースした直後は、誰もそのサービスを知らないからです。もちろんプレスリリースを打てば幾つかのメディアに取り上げてもらえるでしょうが、それはあくまでも一時的なものです。認知度を確実に高めていくためには、開発者の間で何度も名前が出てくる状態にしなければなりません。
人は短期間に何度も情報に触れることで好感を持つようになるそうです。これは心理学的にザイオンス効果と呼ばれます。例えば、勉強会で聞いたサービス名がその翌日にはTwitterで別な文脈で話題になっており、さらに会社のチャットでもそのサービス名が出てくるといった具合です。何度もその名前を見るので、このサービスは要注目なのかも知れないと感じるのです。あなたにもそんな経験はないでしょうか。さらに最近では人の影響力も関係するので、あなたの信頼する人が発信していたりすると、その影響がより顕著になります。
そのような状態になるよう環境を整えていくのがDevRelの役割です。その手段としてはブログの執筆やイベントでの登壇、さらにメディアへの寄稿などもあります。公式サイトが情報を発信していくことは重要ですが、特に外部の開発者(第三者)による発信が特に重要です。開発者は他の開発者による忌憚ない意見を信用するので、そういったブログやソーシャルでの発言を増やしていく必要があるのです。
この段階での主なDevRelの施策とその期待
主な施策 | 期待 |
---|---|
ブログ執筆 | 拡散と検索流入 |
ソーシャルメディア運営 | コミュニケーションと拡散 |
Q&A立ち上げ | 開発者サポート |
イベントの実施 | コミュニケーションと拡散 |
・サービスリリース後
サービスをリリースしてしばらくすれば、ユーザー登録してくれる人たちがある程度増えていることでしょう。その段階ではユーザー獲得継続はもちろんですが、さらに活性化を考えていく段階になります。多くのユーザーは登録したものの利用していなかったり、放置しているものです。サービスは日々更新されており、新しい機能が追加されているにも関わらず、ユーザーに届いていない可能性があります。そこで不活性なユーザーを呼び起こすのです。
多くの場合、ユーザーへのコンタクトはメール経由になります。そのため、ユーザー登録の時点でメールでのお知らせについて許諾(オプトイン)を取っておく必要があります。後から許可をもらうのは難しい(不活性なユーザーならサイトすら訪れないでしょう)ので、忘れないようにしましょう。メールを強制的に送りつけてキャンセルする仕組みだけ用意する(オプトアウトにする)こともできますが、開発者には特に好まれないので気をつけてください。ただでさえ不活性なのに、さらに嫌われてしまうでしょう。
こういった呼び起こしをするためには、意外と定期的なコミュニケーションが重要です。営業的・宣伝的なものではない技術的なメーリングリストを定期的に配信するようにしたり、ブログの購読者を獲得する、ソーシャルメディアのフォロワーを増やすなど、あらかじめ基礎を作っておく必要があります。
この段階での主なDevRelの施策とその期待(リリース直後の施策を含む)
主な施策 | 期待 |
---|---|
ニュースレター | 最新情報の提供 |
ハンズオンの実施 | ユーザー登録増・活性化 |
Q&Aのサポート | 開発者サポート・活性化 |
ハッカソン | ユーザー登録増・活性化・フィードバック |
コミュニティの立ち上げ | 活性化・フィードバック |