--- title: "DevRelからみたCommunity / Community Marketing" date: 2023-12-20 categories: - "ざっき" - "雑記" url: "https://hidetaka.dev/ja/blog/983" --- 記事は「[コミュニティマーケティング Advent Calendar 2023](https://adventar.org/calendars/9413)」20日目の記事です。 5日目の記事で、[DevRelとコミュニティマーケティングに関する記事](https://taiponrock.medium.com/devrel%E3%81%A8%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0-bd6df6045c08)がありましたので、StripeでDeveloper Advocateとして2年と少し活動して感じたことをまとめてみました。 ## DevRelはコミュニティで発信と情報収集をする DevRelという職種を聞くと、「イベントで登壇したり、ブログやワークショップなどのコンテンツを出す仕事」というイメージがあるかもしれません。実際[自分も2年で200記事をQiitaに投稿](https://qiita.com/hideokamoto)し、加えてワークショップ資料や登壇資料をZenn / ドクセルなどに公開しています。 ただ、コンテンツを発信することだけに取り組み続けるのは、実はかなり骨が折れます。普段、「紹介したい機能や製品から、ユースケースを考えて、デモを作り、コンテンツにする」というステップを踏んでコンテンツを作ります。このフローを繰り返すと、1年から1年半程度で「ユースケースのネタ切れ」が発生します。また、知らないことは書けないので、自分の経験だけを元にコンテンツを作り続けると、どうしても内容に偏りがおきます。実際、200記事を公開しているとはいえ、よくよく記事を見ると、Stripe ConnectやRadar / Sigmaといった、前職で触る経験が多くなかったプロダクトに関する記事は極端に少ない状況が起きています。 このような問題を解決する方法の１つとして、コミュニティへの参加があります。 人前で事例・経験として紹介してくれるということは、結果がどうであれ「人に話したい経験を積むことができたこと」を意味します。そのような貴重な話を聞くために、JP\_Stripesをはじめとする様々なコミュニティに参加しています。 そしてそこで聞いた話を元に、「この機能開発で困ったということは、こういう記事があればよかったのかもしれない」「あの人の使い方なら、たぶんこの機能は欲しいはずだ」などの仮説を立てて、コンテンツを作ります。例えば以下の3記事は、JP\_Stripesやサイボウズデイズのセッション・立ち話などで話題になった機能をメモして、後日記事化したものです。 - [Stripe Checkoutで商品の発送を伴う決済ページ・フローを構築する方法とカスタマイズ](https://qiita.com/hideokamoto/items/f10d6ebb4ff53502687a) - [kintoneプラグインにて、kintoneアプリにStripeの決済フォームを表示する方法 with kintone-ui-component](https://qiita.com/hideokamoto/items/4cd25a95719feab21d8e) - [Stripeのカスタマーポータルを利用した、請求マイページやプラン変更・解約画面のローコード開発入門](https://qiita.com/hideokamoto/items/747e568b209d03767079) この手のコンテンツは、「広く発信する」というよりは「オープンな形で、登壇やフィードバックをくれた人に返事をする」イメージに近いかもしれません。広く届けることのできるコンテンツも重要ですが、「コミュニティとの関わり合いを持ちたいと考えていることの意思表示」や、「製品に関するフィードバックや体験をオープンにしてくれたお礼」といった意味でも、来年以降もこういった記事の発信は続けたいと思います。 ## ユーザーがオープンにした情報を、社内に持って帰る [この記事を書くきっかけとなった記事](https://taiponrock.medium.com/devrel%E3%81%A8%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0-bd6df6045c08)からの引用ですが、DevRelのアプローチには「製品開発への貢献」もあります。コミュニティに参加することでこのステップにも良い影響を与えることができます。 ![](https://wp-kyoto.cdn.rabify.me/wp-content/uploads/2023/12/fda724a6883a4ad93985bb913c3b6529-20231220142132.png?&d=1140) [https://taiponrock.medium.com/devrel%E3%81%A8%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0-bd6df6045c08](https://taiponrock.medium.com/devrel%E3%81%A8%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0-bd6df6045c08) そしてこのステップは今年になって面白みを強く感じるようになった部分でもありました。なぜならユーザーからのフィードバック・要望と向き合うことで、ユースケースだけでなくより製品に関する理解を深めることができるからです。 例えば[この記事](https://qiita.com/hideokamoto/items/1e056c6ec88dd9eccd1b)は、「サブスクリプションを申し込みする前に、その申し込み内容だと初月の請求がいくらになるかを概算する方法」を紹介しています。これはイベントで知り合った方にユーザーインタビューを依頼し、その中で頂いた機能リクエストから生まれたコンテンツです。当初は新しい機能・APIについての相談だったのですが、ユースケースや困っている点について聞き取りを進めた結果、「実はその要件でも使うことができるAPIがあること」が発覚し、それを公開コンテンツとして整理したものがこの記事です。このケースでは「プラン変更時に使えるAPIはあった記憶がある。だからもしかすると使えないか？」というステップが間にあり、ヒアリング側の製品知識と、フィードバックを提供してくれた方が要望の背景を詳細に伝えてくれたことの両方が大きな要素だったと思います。 もちろん機能として存在しないため、持ち帰って製品チームにフィードバックすることもあります。その場合でも、コミュニティイベントやアドベントカレンダーでオープンになっている情報を参照したり、そこのつながりからインタビューをセッティングしたりすることで、要望のユースケースや必要な要件を詳細に伝えることができます。詳細度の高いフィードバックを提供することで、「製品の設計思想上難しいが、代替手段ならある」とか「アイディアは興味深いので、今後のマイルストーンとして検討したい」などの反応をもらいやすくなりました。 ## フィードバックやアンサー記事から、次回の登壇につなげたい DevRelとして、1年目は情報発信、そして2年目は情報収集に力を入れてきました。来年は「出した情報」と「集めた情報」が相乗効果を産めるようにしたいと思います。 - イベントの発表や公開した記事から「やってみた、試してみた」人を増やす - 試してみた人が、その経験をイベントで話したり、記事にする - その中で「ここが難しい、わからなかった、うまくいかなかった」ポイントがあれば、個別にコミュニケーションを試みる - 製品チームへのフィードバックや、ワークアラウンドを調べ、アンサー記事または個別に案内を行う - 問題の解決につながれば、また次回その経験について話してもらう みたいなイメージでしょうか。 また、今年下半期からYouTubeへのアーカイブ化も始めているので、これも継続していきたいなと思っています。 「こんな事例がコミュニティにありますよ」と社内に広めることで、DevRelだけでなく様々な立場のStripe社員がコミュニティと関わりを持つようになる部分まで目指すことができれば、なによりです。