DevRelエンジニアフレンドリーになるためのコミュニティ活動
※この記事は『DevRelエンジニアフレンドリーになるための3C』のCommunity運営についてフォーカスしたものになります。
私はコインチェックという会社でエンジニア採用広報をしています。
変化の激しいテクノロジー時代において市場価値があるキャリアを構築すべく、『DevRelエンジニアフレンドリーになるための3C』よりDevRelの知見をインプットしました。
開発者には顧客を喜ばせる力があり、競合他社を圧倒させビジネスを変革できる可能性を秘めており、Devrelには「開発者に寄り添って、プロダクトやサービスの魅力と開発者の強みを同時に引き出し伸ばすための能力」が必要です。
そもそもなぜ、DevRel（Developer Relations）が重要なのでしょうか。
DevRelの目的は、自社サービスを使っているデベロッパーや技術者とのエンゲージメントを高め、新たな利用者や利用検討者を増やすことです。つまり、コミュニティマーケティングを通じて、テクノロジーやサービスを拡販することが重要になります。
テクノロジーが時代の中心になった今、エコシステムに求められるテクノロジーパートナーは企業だけではなく、外部のユーザー・開発者と企業がお互いWin-Winになる形で巻き込む必要があります。彼らと共創する仕組みが構築できれば、プロセスは効率化されより早くイノベーションを実現することができるのです。
企業と開発者がお互いの価値を高めていける最良のパートナー関係の構築を目指すべく、開発者に対していかに優れた開発者体験（Developer eXperience）を提供できるか、開発者との共創を実現するための活動がDevRelです。
DevRelを成功させるためには、企業は社内外の開発者とより多くの接点を持ちエンゲージメント、すなわち"繋がりの強さ"を高めることに注力する必要があります。
具体的なアプローチを実行するためには、3Cフレームワーク「Code、Contents、Community」で開発者を巻き込み、継続設計とデリバリー検証のフローを回す必要があります。
Code（コード）
コードや技術情報を利用する相手を知る
コードや技術情報を作成する
コードや技術情報を公開する
コードや技術情報を使ってもらう
Contents（コンテンツ）
コンテンツ施策は他のものに比べて低コストではじめられる
コンテンツ施策は測定しやすい
コンテンツはテキスト、音声、動画、スライドなどさまざまな種類がある
コンテンツはマルチチャネルで発信すると効果的
Community（コミュニティ）
コミュニティが成長するための3つのファースト
コミュニティ参加者の3つのレイヤー
コミュニティの3つの成長軸
コミュニティ運営でやってはいけない10の施策
本記事では、3CのうちのCommunity（以下, コミュニティ）について解説します。
コインチェック開発組織ではコミュニティ活動へのコミットメントを推進しています。エンジニア採用広報を担当している私もコミュニティ活動の経験を蓄積し、FY24採用広報の目標「web3のゲートウェイになる」を達成したいため、コミュニティ運営のノウハウをインプットしてみました。
DevRelに求められるコミュニティタイプ
ここで解説するコミュニティとは、マーケティング手法の一つです。
「関心軸 - 地域軸」「オープン - クローズド」の4象限でタイプを整理すると分かりやすく、DevRelに求められることは「関心軸 × オープン」なコミュニティの形成です。
ITの世界でのコミュニティは基本的に「関心軸×オープン」である。
■関心軸
- ネットの普及により地域や場所といった制限を超え、興味・課題・趣味などの「同じ関心軸」で集まったコミュニティ。
- ITの世界では、関心軸で形成されるコミュニティがメインストリームである。地域軸コミュニティと比べて帰属意識が高いので熱量が高くなる傾向がある一方、簡単にコミュニティを辞めることもできる。
■オープン
- 新しい人が次々と入ってくるコミュニティ。
- クローズドなコミュニティは特定の人との関係を維持する特徴がある。
DevRelの目的は、自社サービスを使っているデベロッパーや技術者とのエンゲージメントと新たな利用者や利用検討者を増やすことです。コミュニティマーケティングを通じて、テクノロジーやサービスを拡販することが重要になります。
国内最大規模の「JAWS-UG（AWS：Amazon Web Services）」が良い例でしょう。
2010年の東京でのキックオフからはじまり、現在は日本国内の50を超える支部や海外AWSコミュニティの成立に大きいな影響を与えています。
2018年の1年間で250回以上の勉強会が開催されているようです。
コミュニティマーケティングで大事なのは「誰を」対象にするか
コミュニティを立ち上げる時にまず「誰を」対象にすべきかを考えましょう。「誰」が決まれば訴求ポイントと手法もより精度が高くなります。
訴求したいテクノロジーやサービスの特徴・ベネフィットの中から、デベロッパーが関心を持つ内容とメリットに焦点を当て、それが伝わりやすい手法をコミュニティ活動の中で行うことが効果的です。
手法
ハンズオン
アーキテクチャーレビュー
デザインパターン・バッドノウハウの共有
ハンズオンとは
ハンズオンは座学のイベントではなく、参加者が実際に手を動かして学ぶイベントです。手を動かすためにPCを用意したり、サービスアカウントが必要になることも多いので、ウェビナーと比べると敷居が高くなります。その代わり、学習意欲が強く、積極的に学ぼうとする方達が多い傾向があります。
また、「誰」は既存ユーザーだけではなく、サービスを利用検討中のユーザーもターゲットに含めてリーチしたほうが効果的です。
上図のように、既存ユーザーと導入検討中ユーザーの双方のデベロッパーに連続したフィードバックループを作ることができます。
結果、マーケティング部門にとって重要な「どの機能が評価されているか」「どの機能が求められているか」といった製品開発やマーケティングメッセージ開発に関わるフィードバックも得られるのです。
コミュニティ成長のフレームワーク「3つの原則」
コミュニティを効率的に成長させるためのフレームワークには3つの原則があります。
1.コンテキストファースト
「このコミュニティはなんのために運営しているのか」「このコミュニティに集まる人は何を期待しているのか」「このコミュニティではどんな情報を得られるのか」というコンテキスト（文脈）を明確にします。何故なら、参加者がコミュニティに求めるものがバラバラだと参加者の継続率が下がってしまい、参加者同士のネットワーキングも進まなくなります。
コミュニティに対する期待値や関心軸を、参加者がある程度共有できていることが重要なのです。
2.オフラインファースト
オフラインの場で情報交換を行い、オンラインで情報を拡散。そして拡散によって新たな人がオフラインの場に入ってくる形が、正しい成長スパイラルです。
オフラインの場はそこのテーマに興味を持った人が集まります。コンテキストが合っている人たちなので、参加者同士が仲良くなりやいのが特徴です。オンラインよりオフラインのほうが熱量も伝播しやすいのです。
3.アウトプットファースト
アウトプットとは、オフラインファーストの図で示している通り、オフラインの会合から生まれるブログや登壇スライド、SNSでの拡散を指します。
また、ベンダーからは出しきれないサービスの運用に関する情報がコミュニティユーザーからアウトプットされます。何故なら、コミュニテイから生まれるコンテンツと、ベンダーから発せられるコンテンツは大きく異なるからです。ユーザーは実際の運用に関わる情報やユースケースを圧倒的に持っており、これはベンダーでは提供できません。
ベンダーからは出しきれないサービスの運用に関する情報がコミュニティからアウトプットされることで、既存ユーザーや導入検討ユーザー双方にとって有益なコンテンツになり、コミュニティの成長に繋がります。
コミュニティ運営に必要な3つの参加者レイヤー
既存ユーザー・導入検討中ユーザーを集めて3Cを守っていても参加者のレイヤー分けとコミュニティを推進していくリーダーがいないと"実行"が伴わない停滞したコミュニティになってしまいます。そのため、コミュニティに集まる3つのレイヤー層と、コミュニティの立ち上げ必要な人のタイプを解説します。
リーダー
商品、サービスのファンであり、かつ「アウトプット」ができる人
フォロワー
リーダーのアウトプットを見て同じようにやってみたり、アウトプットしてみたりとというフォローができる人
ワナビーズ
商品やサービスに興味はあるが、インプットのみを要求して「アウトプット」もフォローもまだできていない人
人数比率は上図のようにリーダーとフォロワーが20%、ワナビーズが80%という割合です。（パレートの法則はさまざまな経験則から生まれるんですね。）
1.立ち上げ：コミュニティの立ち上げに必要なのはリーダーとフォロワー
コミュニティ立ち上げ時はリーダーを慎重に選ぶ必要があります。選ぶ方法は、初期のコミュニティをクローズドにして参加者をある程度セレクトします。
失敗例は、はじめの段階から人数を集めたくなる衝動にかられ、ワナビーズ層やワナビーズにもならない"無関係"な人たちにも声がけを行うケースです。ワナビーズ層は、コミュニティが立ち上がってくると自然に集まってくるので積極的な声がけは不要でしょう。この立ち上げ時にワナビーズが多いと、リーダーが消耗してしまいます。
反対に、リーダーに必要なのはフォロワー層です。何故なら、リーダーの考えを外に向けてアウトプットしてくれるからです。最終的にはリーダーの行動している姿を真似してくれることもあるので、コミュニティの立ち上げ時はリーダーとフォロワーを集めることになります。
2.自走化：コミュニティ立ち上げ後に自走化させる方法
コミュニティ立ち上げ後は、少しづつリーダーにmeetup等のイベント開催を任せてみましょう。DevRelを展開するベンダー側の担当者がオフラインの場に参加しなくても、勉強会やミートアップがコミュニティ側のメンバーによって自主的に開催されている状態こそ、自走化できていると言えます。
なぜ、自走化された状態が理想かというと、開催頻度がベンダーの担当者のスケジュールや人数などの制約を受けなくなるメリットがあります。また、コミュニティ運営メンバーだけで開催できる状態はコミュニティ活動が自分ゴト化=自走化している状態とも言えるのです。
いきなりベンダーが抜けてコミュニティメンバーに任せるのではなく、ベンダーはリーダーに寄り添いながら自走を促すと良いでしょう。
冒頭で紹介したAWSコミュニティ「JAWS-SU」は年間250回以上のmeet upを開催していると述べましたが、ベンダー担当が参加していないコミュニティのみで自走化できています。
3.株分け：初心者メンバーが増えてきたら株分けをする
立ち上げ時のコンテキストで始めたコミュニティも、時間が経ちワナビーズが増えてくると、参加者の期待値がさまざまに広がってきます。そうすると、すべてのメンバーの要望に応えるのが難しくなってきます。
初心者と上級者が混在している状態になってきたら、「初心者支部」「上級者支部」と株分けをしましょう。メリットは、コミュニティの成長速度が再び上がり、"実行"が伴わない停滞したコミュニティになってしまうのを阻止できることです。
コミュニティ全体のコンテキストを上級者寄りの深い議論や関心軸に合わせると、初心者が入りづらくなるので、株分けはワナビーズの割合が50%を超えたあたりで実行することをお勧めします。
コミュニティ成長を測るKPI
コミュニティマネージャーは、コミュニティの成長を把握するためのKPIを設定しましょう。コミュニティが"正しく"成長しているかを会社へ報告する義務があるためです。
新規参加者の割合
アウトプットの数
ミートアップ、勉強会の述べ人数
コミュニティに所属している人数
その他定性的なKPI
1.新規参加者の割合
コミュニティの成長度合いを測る軸として最も分かりやすい指標でしょう。勉強会やミートアップ参加者の常時40~60%くらいが「初めてきた人」であれば、そのコミュニティは成長軌道に乗っていると言えます。
2.アウトプットの数
先述した3Cフレームワークの「Contents」で解説した通り、DevRelにとって重要な役割の一つです。具体的には、ミートアップ、勉強会での登壇者数・ツイート数・ブログ数などが挙がります。
他にも、勉強会で得た情報を社内展開したり、ミートアップで登壇した人が他のカンファレンスの登壇者として発表するなどのアウトプットを測るのも良いでしょう。
3.ミートアップ、勉強会の述べ人数
コミュニティがリーチした人の数です。例えば、Connpassからのお申し込み人数などです。
述べ人数の計算式は以下です。
述べ人数 = 平均参加者数 × ミートアップ開催数
平均参加者数はSNS等でのシェア。ミートアップ開催数は先述した「自走化」と「株分け」の成長軸が大きく関わってきますね。
4.コミュニティに所属している人数
コミュニティに所属している人数です。例えば、SlackはFacebookのグループに参加している人数や、connpassやDoorkeeperの自社アカウントをフォローしている人数などを示します。
また、アクティブな参加者が全体のうちどのくらいの割合を占めているのかを把握する場合は、アウトプットの数とコミュニティ所属人数を併用することで、どの程度活発に活動できているか（アクティブ率）を把握できるでしょう。
例：アクティブ率= コミュニティ所属人数 / 述べ人数
5.その他定性的なKPI
定性的なKPIとしては、「コミュニティ参加者の熱量」や「コミュニティリーダーの質」が該当します。この定性的な部分を見るセンサーの役割はベンダー側から1人で行うことが大切です。何故なら、定量化できない指標は、人によってバラツキが生じやすいためです。なので、極力同じセンサーで計測を続けさせるため、この役割を特定の人に固定化させましょう。
コミュニティ成長のために「やってはいけない」10のこと
「これをやるとうまくいかない」10のことを紹介します。
インセンティブプログラムの導入
インフルエンサーマーケティングどの混同
集客数からのスタート
プロダクトローンチ前にスタート
既存ユーザーだけに限定したアプローチ
刈り取り型セミナーとの混同
売上に直結したKPI
セッションコンテンツとスピーカーに頼った集客
コミュニティ参加者をお客様扱いする
売上規模などの組織ヒエラルキーの適用
1.インセンティブプログラムの導入
コミュニティ活動に「金銭的な対価」を支払うインセンティブプログラムを導入するのは控えましょう。何故ならコミュニティとインセンティブプログラムの相性が悪いためです。
無償でアウトプットしてきたファンの熱を冷ましてしまう（コミュニティ活動とインセンティブの金額が釣り合わなく感じる）
ファンでもない人がインセンティブ目当てで、本心ではないアウトプットをする
2.インフルエンサーマーケティングとの混同
サービスのファンでもないインフルエンサーを起用するのは控えましょう。何故なら、認知は得られても見込み顧客の共感は得られないことになるからです。インフルエンサーを無償でコミュニティに引き入れることができたとしても、インフルエンサーは自分の「インフルエンス力」を増やすために、結果的にコミュニティの場を踏み台にしてしまうこともあるので注意すべきです。
"本当のファン"であるインフルエンサーはコミュニティの中にいます。
3.集客数からスタート
コミュニティ立ち上げ時は、新規の集客数をKPIにおいてはいけません。先述したように立ち上げ時は関心軸 × オープンなコミュニティの形成が重要だからです。
まずは、初期で「このコミュニティはなんのために運営しているのか」「このコミュニティに集まる人は何を期待しているのか」「このコミュニティではどんな情報を得られるのか」というコンテキスト（文脈）を設定しましょう。
4.プロダクトローンチ前にスタート
プロダクトローンチ前にコミュニティを立ち上げるのはNGです。PMF（スタートアップ企業がターゲット顧客を特定し、適切な製品を提供することに成功した段階）して、プロダクトへの熱心なファンがいることを確認した上でコミュニティを立ち上げるのが賢明です。
5.既存ユーザーだけに限定したアプローチ
既存ユーザーだけのアプローチではなく、見込み顧客に対してもアプローチをしてコミュニティに参加してもらいましょう。既存ユーザーが見込み顧客に対し事例やユースケースを紹介してもらうことで、コミュニティはスケールしていきます。
6.刈り取り型セミナーとの混同
BtoBマーケティングと同じ論理ですが、見込み顧客ユーザーに対してダイレクトに案件獲得を狙った刈り取り型セミナーだと、スケールするマーケティング施策にならないためNGです。重要なのはリードナーチャリングで、コミュニティ参加者から生成されるプロダクトやサービスに関する事例コンテンツを提供し見込み顧客を自分ゴト化させます。
その後、リードクオリフィケーション(見込み客の選別)を目的とした、刈り取りセミナーやキャンペーンを用意しましょう。
7.売上に直結したKPI設定
DevRelにおけるコミュニティのKPIは先述した「コミュニティ成長を測るKPI」にしましょう。売上に直結したKPIは刈り取り型セミナーやキャンペーンでカバーするもので、DevRel本来の目的とはかけ離れています。
8.セッションコンテンツとスピーカーに頼った集客
「界隈の著名人がスピーカー」「価値のあるテーマ」でも集客はできるでしょう。ここでお伝えしたいのは、ある程度人数が増えてきたコミュニティでの集客が「スピーカーとテーマに頼っているだけ」の状態だと、成長できていないということです。
スピーカーに関わらず、その場でコミュニティメンバー同士が会えることを目的とした参加者が増えている状態が健全な成長だと言えます。「学びたい」と「会いたい」がバランスよく共存するようなコミュニティ運営をしましょう。
9.コミュニティ参加者を「お客様扱い」する
参加者に対してお客様扱いをするのは控えましょう。（最初のうちは大丈夫です）何故なら、参加者にはコミュニティの場は自分の場として認識してもらい、主体的に動いてもらう必要があるためです。いつまでもお客様扱いしていては、自走が始まらないことになります。
10.売上規模などの組織ヒエラルキーの適用
組織のヒエラルキーではなく、個人の熱量を重視しましょう。コミュニティはあくまでも参加者の熱量、「個人＞ 組織」が重要です。BtoBマーケティングでは、利用金額や予算規模の数字が大きい見込み顧客ほど優先しがちです。
また、個人の熱量を無視して、会社規模などで登壇者やコミュニティリーダーを選ぶとコミュニティ発展の芽を摘んでしまうことに繋がりやすいです。
最後に
DevRelを成功させるための具体的なアプローチである3Cのうちコミュニティの立ち上げから運営方法を紹介しました。
書籍には、LINE社の事例として「2つのコミュニティ活動事例」や「DevRelと開発者の距離感を掴むコツ」といった他社事例も解説されています。また、今回解説できませんでしたが3CフレームワークのコードとコンテンツもDevRelになるための重要なファクターです。
ぜひ本を購入してみてください。
この記事が気に入ったらサポートをしてみませんか？