こんにちは、ニーリーの佐古です。
現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。
DevRelKaigi 2025に行ってきました
さて、さる10月2～4日に開催されたDevRelKaigiの3日目に参加してきました。
(一か月以上経ってしまった……)
devrelkaigi.org 日本では唯一となるDevRelをテーマにしたカンファレンスです。
DevRelとは
Developer Relationshipの略で、原則としてはある主体が提供するプロダクトを「利用する開発者」との関係を指し、この分野ではその維持改善への取り組みがテーマとなります。
プロダクトのユーザーグループ(UG)との関係維持やフィードバックの吸い上げのほか、UG自体の立ち上げも行ったりと、自社プロダクトのファンとなる開発者を増やし、「パイを広げに行く」活動を行います。
DevRelエンジニアやDeveloper Advocateなど、DevRelを専門としたエンジニアの方も存在します。
Q: ニーリーのプロダクトにUG作る/DevRel始める余地はある？
A: まだです。
後ほど改めて触れる松下さんのセッションで非常にわかりやすい話があり、DevRelを必要とするプロダクトの条件が示されていたのですが、その中に
製品がHackableであるか
という点が挙げられていました。
まだ開発者がプロダクトをハックして面白いコト・モノを提供するようなことを期待する基盤にはなっていないので、これは将来のお楽しみということになるでしょう。
なぜ参加したのか
内向きのDevRelのために
実はDevRelの逆向きのことをやりたいと考えており(成瀬さんのセッションで内向きのDevRelという表現が出てきたので以後お借りします)、
そのためにDevRelに関する知見や体験を知りたかったというのがメインの動機です。
自組織の外のコミュニティにはベストプラクティスや基盤などの「佳きもの」が多数存在するので、それらを吸収するためのUGを自組織内に作りたく、「UGの作り方」に関するイメージを膨らませる材料や、翻訳あるいはハックできるノウハウが欲しかったのです。
外向き(本来の)DevRel
内向きのDevRel
メモ なぜ佳きものを規約に実装しないのか
基本的に私が
- norms overrides rules(規範は規約に優越する)
- culture eats strategy for breakfast(文化は戦略を平らげる)
派なので、大枠や簡単に自動判定できる部分だけ規約化して、それ以外の点を規範や文化で討ち取る挟撃の形を取りたいと考えているためです。
一般的な開発者コミュニティの運営
もう一つ、単純にコミュニティ運営に関しても面白そうな話を聞けそうだったので。
セッションの学びや感想
特に社内での取り組みに絡み印象強かった点に絞って触れたいと思います。
英語トラックもあったのですが、興味のある話題が日本語トラックに集中していたので今回は見送り。
10年の共創が示す、これからの開発者と企業の関係 ～ Crossroad / 株式会社ソラコム 松下 享平さん
「人はホラーストーリーよりハッピーストーリーで動かせ」というのが最大の学びです。
内向きに読み替えると
ベストプラクティスの類を導入しようとするとき、 どうしても「こうしないと後がしんどい」という説明になりがちで、それは事実なのですが 「こうすると楽だよね」でアプローチしてご利益を示すのがベターであると。
利害を説くなら利もきちんと見せましょうということで、佳きものの、佳き導入例を示しにいこうという想いを新たにしました。
そもそもハッピーに開発することでアウトカムを増大したいゆえの取り組みなわけですし。
その他・イベントのKPIの話
UGイベント開催の目標を集客よりも継続回数に置くという話がありましたが、社内での取り組みについてもとりあえず継続&安定開催を頑張ろうと再確認しました。
信頼される仲間になっていきます。
参考・弊社内での取り組み
セレンディピティを養殖するために技術的雑談のチャネルを複数用意しています。
Developer Advocate/Community Managerになるには？スキル・ロール・キャリアをグローバルな文脈から考える / Snowflake 田中 翔さん
ロールによって求められるものは変わるが、特にDeveloper Advocate/DevRelEngになるためには技術力とアウトプット力(スピーチ/ライティング)が重要という話でした。
内向きに読み替えると
ほぼそのままのものが必要になるのだろうという認識です。
ロールを任されるようになるにはというのがセッションの主眼ではあったのですが、そのロールで振る舞ったときに相手に話を聞いてもらえるかが技術で変わる体験はしているのでその点でも納得しています。
そして現状、特にアウトプットまわりが足りていないので頑張ります、はいという気持ちになりました。 (技術が足りているわけではないです。)
「発表する登壇」から「伝わる登壇」へ ─ 思いやりの「テクニック489」とは？ / OwlPay Japan 山﨑 亘さん
これはもう一般的なテクニックの話なので読み替えも何もなくその通りでした。
もっきり割と苦手なんですよね
ちょうど最近社内向けの記事を書くときはあえて情報を落とすようなことをしています。
伝わるのもそうですが、質問の余地ができるというのも利点ですね。
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化 / 日本経済新聞社 西馬一郎さん
こちらもそのものずばりで社内の取り組みに関する内容だったので。
登壇者の枯渇やバーンアウトの悩みというのは非常に共感できる内容でした。
(個人で運営しているコミュニティが今まさにこれで存続の危機にあります。)
背中を押す/無理をしないの境目の見極めが難しいなぁという課題がありますが、さりとてやっていくしかないよねの心境です。
ただの感想ですがバックエンドのミートアップがなかったらしいのちょうぜつ寂しいですね。
学び・感想を踏まえての展望
今後の内向きのDevRelへの取り組み
基本、継続でがんばっていきましょうという点は動きません。
よそでも苦労しているのだなぁということに励まされもしました。
一方、アプローチのテクニックやお膳立て、それを行う自分の在り方についてはブラッシュアップの余地が見つけられたので大変良かったです。
説客感がまた増してきた……
DevRelKaigi 2026へ
今度は英語トラックも聞く機会があるとよいですね。 また、本筋とは少しずれるので、そのあたりがどう受け止められるかというのは置いておいて、内向きのDevRel話でスピーカー狙いたいなぁと考えています。
