DevRelの始め方
はじめに
最近、DevRelを始める企業やサービスが増えています。もしかしたら、あなたの会社やサービスでも「DevRelを始めたい」と思っているかもしれませんが、そこで問題になるのが「何から始めれば良いのか」です。
前回「『これをやればDevRelだ』と言えるものはない」と書いた通り、DevRelとして行うべきことは千差万別です。しかし、何かしら取っ掛かりがなければ、そもそも始めの一歩を踏み出すこともおぼつきません。
そこで今回は、「これからDevRelを行いたい」と考えている企業やサービスが、実際に何から始めれば良いかについて紹介します。
自分たちがDevRelを行うべきかを判断する
まず、「そもそも自分たちがDevRelを行うべきか」を考えましょう。ライバル企業やサービスがDevRelをやっているからと雰囲気で始めてしまうと、失敗する未来しか見えません。
DevRelを行うべき企業・サービスは「開発者がステークホルダー」であるべきです。ステークホルダーとは「利害関係者」という意味です。多くの場合、株主や経営層、従業員、子会社、下請け会社などに使われます。マーケティングの文脈で言えば「開発者が自社やサービスを成長させるのに必須の存在であるかどうか」です。
もし開発者がステークホルダーであると言えるなら、DevRelを行う価値はあるでしょう。
関係性の構築を目的とする
DevRelは「外部の開発者との良好な関係性構築」を目的としています。もし「自社や自社サービスを知ってほしい」「開発者を雇用したい」だけであれば、DevRelではありません。「知ってほしい」なら日本でいう広報活動だけなので、それは技術広報であってDevRelではありません。開発者を雇用したいという目的でDevRelを行うのは韓国では一般的なようですが、日本はもちろん、グローバルでも異なります。
そういった意味で「開発者がステークホルダー」であったとしても、アプローチにDevRelが最適かは異なります。DevRelはあくまでも「開発者との関係性構築を目的とできるか」が鍵になります。
なお、サービスのステージによっては、まず認知度向上を目指す場合もあります。「関係性構築＝コミュニティ施策」というわけではないので、施策は状況によって異なります。ここではDevRelの最終的な目的のお話しになります。
社内で共通認識を持つ
DevRelが何であるか、何を目指すのかを社内で共通認識として持ちましょう。多くの企業ではごく限られた部門や担当者でのみDevRelが行われており、その内容やDevRelの意味を知らない人が多いです。コミュニティやカンファレンスのブース出展、各地への出張など、DevRelの活動はともすると遊んでいると思われがちです。
その結果、社内で協力者に助力を仰ぐことが難しくなります。テックブログを書いてくれるメンバーが集まらなかったり、コミュニティイベントを手伝ってくれる人が見つからずに回せないといった事態に陥ります。
そのため、トップダウンでDevRelを始めるとしても、他部署を含めて「DevRelで何を行うのか」を説明する必要があります。DevRel施策の多くは担当部署だけでは完結しません。開発やマーケティング、広報や人事などさまざまな部署と連携することが多いので、しっかりと情報共有を行いましょう。
DevRelのKPIを決める
「DevRelをやるぞ!」と決めたら、次はKPIを設定しなければなりません。KPIは「測定可能なもの」であること、「定量的に評価できる」ものを設定します。「開発者と仲良くする」などの定性的な設定は禁物です。
認知度を向上させるステージの場合、WebサイトやブログのPV、ソーシャルメディアのフォロワー、イベントの実施回数や集客数などがKPIになるかもしれません。サービスの活性化や継続率向上を考えるなら、チャーンレートやサポートの品質、ユーザーベースの発信数などがトラッキングされる数値になるでしょう。
なお、このKPIについてはお金でブーストできるものを選ぶべきではありません。ユーザー登録数やWebサイトのPV、動画の閲覧数などは操作可能なものです。例えば「ユーザー登録でAmazonギフト券をプレゼント」などの施策を行えば一気に増えることでしょう。しかし、そうした方法で集めたユーザーの質はあまり良くなく、継続的な利用にもつながらないでしょう。一瞬の問題解決のために、お金の力を使うべきではありません。
施策を決める
KPIが決まれば、それを達成できる施策を決めていきます。このときに大事なのは「低予算で高いパフォーマンスが期待できるものを考える」ということです。DevRelへの期待値があまりに高いと、初年度の予算が非常に高くなることも少なくありません。そして、その予算を使い切るべく、さまざまな施策を打ちます。さまざまなカンファレンスにスポンサードし、イベント会社にお金を払って自社イベントを開催したりします。懇親会で無駄に高い食事を振る舞ってしまうかもしれません。
多くの場合、そうした施策は「下手な鉄砲数打ちゃ当たる」になりがちです。さらに費用対効果の測定が甘く、失敗する可能性が高いでしょう。その結果、DevRelの活動予算が縮小されたり、期が変わったタイミングなどで条件が厳しくなったりします。
DevRel戦略シート(日本語版)
上図の「DevRel戦略シート(日本語版)」は、筆者のサイトからダウンロードできます(ダウンロードにはメールアドレスの登録が必要となります)。
コミュニティ施策など、費用対効果の測定が難しい場合もあり、厳密な数値を追い続けるのは困難です。とは言え、何の指標もなく取り組んで良いものではありません。DevRelの意義を把握するのであれば、きちんと効果測定ができる施策を選択する方が良いでしょう。
VonageのDevRelリードであるフィル氏が提唱する「The AAARRRP Developer Relations Strategy Framework」という戦略フレームワークも参考にしてください。
最初の取り組みにお勧めな施策
最初からDevRelに大きな予算を掛けられる企業は多くありません。そのため、予算ではなく社内リソースで始められるものから取り組むのが良いでしょう。例えば、テックブログは社内の開発者だけで始められます。
担当者がいるならば、外部の開発者コミュニティに参加してみるのがお勧めです。なるべくオフラインで実施されているものに参加し、開発者とコミュニケーションを取るようにしましょう。平日夜や週末の時間を使うかも知れませんが、予算的に大きく必要となることはないはずです。
お勧めとしては、テックブログやドキュメント整備など、コンテンツ施策から始めるのが良いでしょう。コンテンツは蓄積されてこそ意味が出ますし、SEOとしての効果も期待できます。また、コミュニティ施策と比べて効果が早く出やすいのが特徴です。
なお、取るべき施策はプロダクトのライフサイクルによって異なるので、他社を真似れば良いものではない点に注意してください。
おわりに
今回はDevRelの始め方を紹介しました。DevRelという言葉が知られるようになり、徐々に取り組みを始める企業が増えています。「DevRelはこれ」というものはないので、他社を真似るのではなく、自社に最適な形で取り組む必要があります。
本記事を参考に、まずは「自社がDevRelを行うべきか」から検討を始めてみてください。
