DevRelでフォーカスすべき3つの領域とその成果の考え方

2024年8月8日(木)
中津川 篤司
今回は、DevRelでフォーカスすべき3つの領域について紹介し、その取り組みによる成果をどのように考えるべきかを解説します。

はじめに

DevRelは企業や組織によって、その考え方に若干の違いがあります。基本は「開発者との双方向コミュニケーションによる、良好な関係性の構築」にありますが、その中で何を行うかがニーズによって異なるからです。

今回は、その最も基本となる3パターンを紹介します。また、各パターンによって成果をどう捉えているかについても解説します。

なお、注意点として、今回紹介する3パターンは、それぞれ独立しているわけではありません。重複している部分もありますし、力をかけている領域が複数になっていることも少なくありません。

DevRelの3パターン

DevRelにおける戦略は、以下の3パターンに分けて考えられます。

  1. コンテンツフォーカス
  2. コミュニティフォーカス
  3. プロダクトフォーカス

それぞれフォーカスする領域によって、取り組むべき内容や成果が異なります。1つずつ見ていきましょう。

コンテンツフォーカス

この場合におけるコンテンツとは、以下のようなものを指します。

  • ブログ記事
  • ドキュメント
  • チュートリアル
  • ソーシャルポスト
  • FAQ
  • 動画配信
  • SDK・ライブラリ
  • デモアプリ
  • イベント資料
  • メールマガジン

コンテンツの多くは「発信」に主軸を置きます。ただし、単純に発信して完結するものではありません。コンテンツをフックとして、次のアクションにつなげることが大事です。

ブログ記事の例

コンテンツの多くはプル型です。コンテンツをWeb検索やソーシャルメディアを通じて見つけてもらう必要があります。多くの場合、自社や自社サービスを知ってもらうのに必要なのがコンテンツです。

期待する次のアクション

では、コンテンツを発見し、消費した後のネクストアクションは何になるでしょうか。

  • 本体サイトへの誘導
  • SDKをインストールして使ってもらう
  • コンテンツへのいいね、ブックマーク、シェア
  • アカウントのフォロー、サブスクライブ
  • メールマガジンの登録

ユーザー登録につながるのが望んだ結果と言えるでしょう。そして、サービスを使ってもらえれば最高です。そこまでいかなくともコンテンツをシェアして拡散する、フォローやサブスクライブするといったアクションを通じて次のコンテンツも届くようになれば、ロイヤリティが高まったと言えます。

成果について

コンテンツフォーカスに限りませんが、成果はユーザー登録やサービスの利用量増にあります。従って、成果は以下を測定することにあります。

  • ユーザー登録する・問い合わせする
  • 既存・新しいAPIの利用が増える

これらの数値をウォッチし、さまざまなコンテンツを流入元として、どのコンテンツが一番響いたかを測定します。

測定について

コンテンツの測定方法はいくつかありますが、よく使用されるのがフォロー数やシェア数のウォッチです。SEOが大事だとして、WebサイトのPV/UUを測定するケースもあるかも知れません。

これらの測定が無駄だとは言いませんが、そこだけにフォーカスしてしまうのは不十分です。どれだけPV/UUが増えてもユーザー登録に結びついていない、または問い合わせが来なければ意味がありません。閲覧者の画面遷移や、どこでドロップしているのかを測定して、成果に結びつけられるようにアップデートを行いましょう。

コミュニティフォーカス

コミュニティは、主に2パターンが考えられます。

  1. 外部の開発者コミュニティ
  2. 自社サービスのコミュニティ

DevRelを始めたばかりの時期に進めやすいのは、外部の開発者コミュニティへの参加です。参加方法としては、単純に一参加者としてイベントに行く、登壇者として情報発信するなどがあります。最初から運営として参画するのは難しいですが、繰り返し参加していくうちにそういった流れになるかも知れません。

コミュニティの例

外部の開発者コミュニティは、自社サービスの利用者になりえる開発者がいるコミュニティを選択します。行けば会える開発者がいるならば、そこに参加しない手はありません。普段からコミュニティに参加するのが当たり前になっている方には分からないかも知れませんが、コミュニティイベントに参加する意義を理解できない方は一定数います。DevRelに関わっている方でも、これまでにコミュニティ参加経験がない方もいるでしょう。

自社サービスのコミュニティは、サービスがある程度大きくなってから(ユーザー数が伸びてから)実施される施策です。単にユーザーが多ければ作れるものでもありません。たとえユーザーが少人数でも、熱量が高ければコミュニティになり得ます。自社サービスのコミュニティでは、運営パターンは3つに分かれると考えられます。

  1. すべて利用ユーザー
  2. すべて自社メンバー
  3. ミックス

日本で一番有名なJAWS-UGは(1)になるでしょう。そして、(2)自社メンバーで運用するパターンもよくあります。最近では(3)ミックス(自社+利用ユーザー)のパターンも見かけます。

期待する次のアクション

コミュニティに期待するのは、情報の生成と拡散です。誰かが知見を発信し、それがコミュニティ内で共有されます。さらにXなどのソーシャルメディアを通じて情報が拡散します。このコンテンツをきっかけとして、新しいユーザーの獲得や認知度の拡大につながります。

もう1つは、コミュニティメンバー内で忌憚ない意見が交わされ、口コミとなって製品の採用が増えることでしょう。情報過多になっている現在、コンテンツの発信だけでは開発者の心に刺さりません。信用する知り合いが採用している製品、大手が採用している製品には誰もが興味を持ちます。導入に不安があっても、先駆者たちからフラットに意見を聞けるのがコミュニティの魅力と言えます。

成果について

コミュニティに行ってはいけないことの1つに「コミュニティへの販売行為」があります。そういった色が見えると、あっという間にコミュニティから離散してしまうでしょう。そのため、売上げ増などを成果にしてはいけません。そこで、以下のような成果を設定することが多いです。

  1. よく使ってくれているユーザーの顕在化
  2. 良質なフィードバックの獲得

(1)はコミュニティが活性化する中でのチャンピオンプログラムの創設に役立ちます。ロイヤリティの高いユーザーを可視化することで、さらなるロイヤリティや周囲の意欲をかき立てられるでしょう。良質なフィードバックはプロダクト自体に限らず、プロダクトの含まれる市場における課題感を見つけるのに役立ちます。開発者から生の声を聞くことで、PMF(プロダクトマーケットフィット)にもつながります。

測定について

コミュニティ自体に求めるものは、ユーザー間のコミュニケーションであり、熱量の向上です。それらを確認するためには、以下のような測定を行います。

  1. コミュニティ内での対話数、対話人数
  2. コミュニティ新規参加者数・定着率
  3. イベント実施数・参加率

コミュニティは、運営を続けるうちに徐々に内輪感が出てしまい、話題が先鋭化しがちです。新しい参加者が定期的に現れるようにするには、新鮮な情報や心理的障壁の低い雰囲気作りが欠かせません。

プロダクトフォーカス

最後はプロダクトフォーカスです。製品を成長させるためにDevRelを活用するというものです。この場合、特定の施策というよりも「DevRel活動全般の目標がプロダクトに活かすために行う」という意味になります。

そうした中で、注目されるのは以下のような施策です。

  • Q&A
  • サポート
  • カスタマーサクセス
  • ドキュメント

こうした活動の多くは既存ユーザーを対象としています。まだプロダクトに触れたことがないユーザーに対してプロダクトに反映できるものとしては、コミュニティからのフィードバックが有効かも知れません。

Q&Aの例

期待する次のアクション

プロダクトフォーカスでは、プロダクトを利用する上でのペインポイント(躓きポイント)を取り除く作業が重要になります。サポートに問い合わせて1営業日待たされたとしたら、ユーザーは別なプロダクトを試そうと思ってしまうでしょう。問い合わせが全くない、すべてセルフサポートできる状態がベストではありますが、それが難しくても素早く回答し、開発者を開発にフォーカスできるようにしましょう。

プロダクトフォーカスのDevRelでは、開発者がどれだけ開発に集中できるかが鍵になります。

測定について

プロダクトフォーカスの場合、測定すべき指標は明確です。

  • チャーンレートの低下
  • サービス・API利用数
  • 問い合わせ減

チャーンレートとは、いわゆる解約率です。SaaSなどでは一定数の解約は致し方ありませんが、チャーンレートを抑えなければ、新規獲得が無駄になってしまいます。

良いプロダクトであれば、サービスの利用数は増えているでしょう。また、APIなどのコール数が増加していてもおかしくありません。こうした領域はカスタマーサクセスに期待される部分になります。

可能な限り、開発者は問い合わせをしたくないと考えているはずです。ドキュメントで理解できる、SDKで適切なエラーメッセージを出す、「こう書くのだろう」と思ったコーディングで動作するなど、デベロッパーフレンドリーな施策が大事になります。

おわりに

今回は、DevRelでフォーカスすべき3つの領域と、その成果に対する考え方について解説しました。冒頭でも述べた通り、いずれかの領域に絞る理由はありませんが、すべてを満遍なく行うには予算も人員も必要です。プロダクトや市場のステージに応じて、最適なリソース割り当てを考えるべきです。

DevRelの最終的なゴールは、常にプロダクトやAPIの利用増にあります。そのゴールに向かってコンテンツ・コミュニティ・プロダクトフォーカスにどのように取り組むのか、ぜひ検討してみてください。

オープンソース・ソフトウェアを毎日紹介するブログMOONGIFT、およびスマートフォン/タブレット開発者およびデザイナー向けメディアMobile Touch運営。B2B向けECシステム開発、ネット専業広告代理店のシステム担当を経た後、独立。多数のWebサービスの企画、開発およびコンサルティングを行う。2013年より法人化。

連載バックナンバー

システム開発技術解説
第27回

DevRelの学び方

2024/9/3
今回は、DevRelを体系的に学ぶにはどのような方法があるのか、その学び方についていかに学ぶかについて解説します。
システム開発技術解説
第26回

DevRelでフォーカスすべき3つの領域とその成果の考え方

2024/8/8
今回は、DevRelでフォーカスすべき3つの領域について紹介し、その取り組みによる成果をどのように考えるべきかを解説します。
システム開発技術解説
第25回

過去の資産(コンテンツ)が信頼性構築の足かせに?「DevRel負債」とは

2024/6/26
今回は、DevRelにおいてアウトプットさらたコンテンツに伴う「DevRel負債」の問題について、その対処法を解説します。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています