はじめに
先日のイベント DevRel Talks で、いろいろな DevRel の方とお話しする機会がありました。
そこで強く感じたのは、DevRel は「会社の技術を広める人」ではあるけれど、実はその会社の中だけで完結している仕事ではないという点です。多くの人が知っているように、DevRel は会社に所属して技術を外に広めたり、ユーザーや企業と話して意見を拾ったり、プロダクトの改善につなげたりする役割を持っています。
一方で、Microsoft MVP は Microsoft 社員ではなれず、社外の技術者が Microsoft の技術やコミュニティと関わるための重要な入口です。公式の MVP FAQ でも、参加条件の 1 つとして「not a Microsoft employee」と明記されています。MVP もまた、技術コミュニティと企業や製品との橋渡しに近い役割を担っています。どちらも最終的には「技術をよりよく伝える」ことに向いている一方で、成果の出し方や見え方はまったく違うのがややこしいところです。
この仕事の一番難しいところは、見える成果と見えにくい成果が両方あることです。コミュニティを育てる、信頼を作る、フィードバックを拾う、技術への理解を深める――こうした価値は、たとえば「イベント参加者数」「資料のダウンロード数」「商談件数」といった数字に簡単には置き換えられません。
それでも、経営陣が求めるものと、現場が本当に大事にしているものの間にズレがあると、ひどく不幸な状態になりやすいです。
今回のイベントをきっかけに、そのあたりをどう捉えているかを、私なりに整理したいと思います。
DevRel と MVP の共通点
まず大前提として、DevRel と Microsoft MVP は似ているようで、実は少し違います。
- DevRel は、会社や製品に所属していることが多いです。
- Microsoft MVP は、Microsoft 社員ではなく、社外の技術者が技術の普及やコミュニティとの関係構築に貢献する立場です。
ただし、どちらも「企業の技術や思想をコミュニティに伝える」「ユーザーの声を会社に戻す」「関係性を育てる」という役割を担っています。
どちらにも、技術そのものよりも「関係性」そのものが価値になるという側面があります。これはとても不安定で、数字として追いやすいものではありません。
企業側から見ると、こうした関係性はしばしば「見えにくい投資」になります。コミュニティのために時間を使っているのに、すぐには売上に繋がらない。ユーザーの声を拾って改善しようとしているのに、改善の結果がいつ頃出るのか不明瞭。話が長くなるほど、「何の成果を、どこで、誰が評価しているのか」 が曖昧になってしまいます。
この曖昧さが、役割そのものの損失に繋がることもあります。
数字で追うと壊れやすいもの
コミュニティ活動は、基本的に長期的で、信頼を作り、関係を維持し、継続的なやり取りを支えるものです。
ですから成果を数字で追うと、意外と危険なことがあります。
たとえば、イベントの参加者数を増やすことそのものが目的化してしまうと、次のような歪みが起こります。
- 近場の人だけを集めて、深い議論が生まれない
- 企業の宣伝色が強くなって、コミュニティの空気が変わる
- 「来てもらえた人を数で誤魔化す」だけのイベントが増える
- 参加者同士の関係性よりも、参加人数を重視する風土が生まれる
こういうのは、コミュニティが本来持っている個体差や変化を捨ててしまうことになります。人と人が信頼し合う土壌を作る活動なのに、数だけで評価すると、関係そのものが壊れてしまうのです。
本当に大事なのは、「その活動でコミュニティがどう変わったか」ではないでしょうか。
- その製品がもっと知れたか
- その技術に触れた人が、もっと深く愛着を持てたか
- その場で議論が生まれたか
- その後、他の人と接点が持てたか
- 何かが改善のきっかけになったか
こうしたものは、数値化しにくい分、むしろ価値の中心になるべきです。
しかし、現実には数字にしやすい成果ばかりが重要視されがちです。すると、本来あるべき関係性が、数字のために犠牲になることが起きます。
それが、私が今回一番感じたことです。
価値の判断軸はどこに置くのか
この話をさらに深く考えると、「何を価値とみなすか」をどこに置くかがすべてだと思います。
コミュニティ活動には、いったいどんな価値があるのでしょうか。
- 製品を知ってもらうことが最優先なのか
- もっと深くファンになってもらうことが重視なのか
- 影響力のある人を育てることが重要なのか
- フィードバックを集めることが最も価値なのか
これらは、どれも一理あります。
ただし、どれが正解かは目的次第です。
| 視点 | 目指す価値 | 近くにある指標 |
|---|---|---|
| 🧭 認知拡大 | 製品を知ってもらう | 参加者数、露出、流入数 |
| 💖 ファン育成 | 技術や体験に愛着を持つ | 継続率、再参加率、発信量 |
| 🌐 インフルエンサー育成 | 伝播の担い手を増やす | 発信数、拡散率、再利用率 |
| 🧪 フィードバック収集 | 使っている人の声を拾う | 相談数、改善件数、アンケート結果 |
この表から分かるのは、目標が違えば指標が違うべきだということです。
しかし、実際には「イベントは参加者数で評価しよう」と決めてしまうと、コミュニティの本質がぶれてしまいます。もし本当にコミュニティを育てたいなら、関係性の重みと、継続的な信頼の積み上げを指標として扱う必要があります。
これは、DevRel や MVP のような役割にとって非常に重要です。
経営陣の期待と現場の思いがずれるとき
今回のイベントで感じたのは、経営陣が求めることと、DevRel として活動する人の思いが、必ずしも一致していないということです。
経営陣には、当然、数字や見える成果が必要です。投資対効果、売上、育成の効率、顧客との接点量など。そうした「見える成果」を求めるのは自然なことです。
一方で、実際にコミュニティと接している人たちは、関係性や信頼、文化の育成、長期的な価値が大事だと考えていることが多いです。
ここでズレが生じると、不幸が起きます。
- その人の真の価値が評価されない
- 価値の出し方が不自然になり、コミュニティが離れていく
- 「数が多いが、関係が薄い」状態が続く
- それでも継続するために、やっていることが不自然に変わる
これは DevRel だけでなく、MVP やコミュニティの運営にも当てはまります。
関係性を維持しながら仕事を続ける人は、数字が見えにくい性質を持っているので、数字が価値のすべてだと考えると、彼らの活動は閉じてしまいます。
つまり、組織として「何が価値なのか」を明文化しない限り、DevRel や MVP の仕事は、どこかで燃え尽きてしまうのです。
ここが本当に難しい
ここまで書くと、たぶん「じゃあ、何をもって成功とするのか」という問いが残ります。
答えは簡単ではありません。
でも、少なくとも私は、成果を数字だけで測ることは、関係性を育てる仕事に対しては妥当ではないと考えています。
むしろ成果とは、次のようなことの積み重ねではないでしょうか。
- 人がその技術に触れた
- 話す人が増えた
- 似た悩みを抱える人が出会えた
- その技術が、ただの製品ではなく、価値あるものとして受けとめられた
- 自分たちの声が、製品やコミュニティに戻っていった
これは、すぐに数字に置き換えられない代わりに、長く残る価値です。
たしかに、その価値は見えにくいです。
でもその見えにくさこそが、DevRel と「関係を作る人」の性質なのだと思います。
何を続けるべきか
今回のイベントで最も印象に残ったのは、「何を続けるか」よりも「何を価値として扱うか」 が本質だという感覚でした。
技術コミュニティを育てるのか。製品のファンを増やすのか。インフルエンサーを生むのか。フィードバックを集めるのか。観測するのか。啓蒙するのか。
どれを選ぶかで、活動の意味が変わります。
そして、持続するためには、選んだ価値に対して、その価値を支える評価軸と関係性 が揃っている必要があります。
こう言うと、少し抽象的に聞こえるかもしれません。
ただ、今回のようなイベントに参加して、現場の方々の話を聞くと、確かにその感覚は強くなります。
コミュニティの活動は、短期的な成果だけで語れない。
人と人の関係を育てる仕事には、数値に変換しづらい時間と信頼が必要です。
そのため、やりたいことと評価軸が一致していないと、いつしか活動が変な方向に流れてしまいます。
おわりに
DevRel と Microsoft MVP の役割は、単なる広報やイベント運営ではありません。
それは、人と技術と会社の間にある距離を縮める仕事です。しかもその距離は、目視できる数字では測れないほど、人間関係と信頼に依存しています。
だからこそ、成果を数字だけで見ようとすると、関係性そのものが壊れる危険があります。
今回の話を踏まえると、私が大事だと感じているのは、次の問いです。
その活動で、どんな価値を生んでいるのか。
その価値は、どこで評価されるべきなのか。
そのために、どんな関係性を守る必要があるのか。
DevRel や MVP の仕事は、たしかに目に見えにくいです。
でも、その見えにくさのなかにこそ、彼らの仕事の本質があるのだと思います。
継続して価値を出すには、まず自分たちが何を大事にしているのかを、ちゃんと伝えることが必要です。
その姿勢があるとき、コミュニティも、企業も、そして自分自身も、少しずつ健全に育っていくのではないでしょうか。