DevRel: 開発者関係と技術布教

私がこの記事を書く動機は実はとてもシンプルです。最近、私は中国語圏の DevRel の方々、例えば Steven、dai 先生、uvd、George と交流する機会に恵まれました。また、時折前の上司とも話をする中で、中国語圏の DevRel の人材があまり多くないことに気づきました。自分が積み重ねてきた DevRel の仕事の経験や体験を基に、この機会を借りて私の見解を共有したいと思います。DevRel は複雑で若い職業であり、時には自分が正しい道を歩んでいるのか不安になることもあります。しかし、私が信じていることは一つです：DevRel はライフスタイルです。

特別感謝：Jenks @ filecoin と Rod @ Ledger、私の二人のメンター、そして前の上司にも感謝します。

PS: 言いたいことが多すぎて、書ききれませんあああああ

一些简介#

私が最初に布道に関わったのは seedao で、その時に主に講義を担当しました。その後、Rebels や小幽霊コミュニティで Web3 の知識を共有したこともありましたが、その時は DevRel というよりも講師としての役割が多かったと思います。私の専門的な背景は技術に偏っており（スーパーコンピュータを専攻し、研究テーマはブロックチェーンに関連しています）、この背景が私のアウトプットをより良くするのに役立っています。また、ファインマン学習法に基づいて、簡潔な言葉で他者に概念を明確に説明することは、自分がその概念を本当に理解しているかどうかを検証する手段です。Rebels での発表時、私は簡単な言葉で技術的な概念を明確に説明できることに気づきました。徐々に、私は web3 やブロックチェーンについてより深く学び、卒業設計の準備を進めました。

学習の過程で、私は LearnWeb3 や Alchemy Learn に触れました。Vitto（現在は Cyfrin で働いています）は私に大きな影響を与えました。彼を通じて、私は DevRel という職業を知りました。また、開発コミュニティを通じて、オープンソースや技術布教についても学びました。その後、私は BNB Chain に参加し、DevRel として働くことになりました。前の上司の Zoe と Yian に感謝します。BNB Chain では、主に Greenfield ストレージチェーンを研究しました。その後、FLock に参加しましたが、ここを選んだ理由は論理的に整合性があり、私の背景に合っていたからです。

私自身はコーディング能力が強いとは思っていません。多くの人には及ばず、せいぜい MVP を書くことができる程度で、より深い論理フレームワークにはあまり得意ではありません。しかし、私には複雑な論理を単純化する能力があります。この能力は多くの人が持っているわけではなく、私は聴衆や会話の相手の背景に応じて簡素化し、物語の語り方を変えます。例えば、非技術者に対しては、より高次の概説を追求します。一方で、web3 技術に興味がある人には、ブロックチェーンに関する知識を多く取り上げます。AI に興味がある人には、連邦学習を重点的に説明します。

私は、DevRel として、技術的な背景だけでなく、コミュニケーションと説明能力も非常に重要であると信じています。だからこそ、私は簡潔で明確な言葉で複雑な概念を他者に伝える方法を学ぶことに努めています。相手の背景やニーズに応じて私の語り方を調整し、彼らが私の説明を理解し受け入れられるようにしています。

まとめると

技術的背景
外部に対して発信する意欲
上下兼ね合いのあるコミュニケーションと説明能力
研究能力
熱意

DevRel とは何か#

DevRel の歴史と進化#

本題に入る前に、DevRel とは何か、そしてその具体的な役割について理解する必要があると思います。DevRel という言葉は 1980 年代に Apple が提唱したのが最初で、その当時はコンピュータとソフトウェアの起源に関するものでした。当時、Apple はその理念があまりにも新しく、多くの人が彼らの製品や macOS の利点を理解できないことに気づきました。そこで、技術とマーケティングの両方を理解している人がガイドや指導を行う必要がありました。macOS や Apple 製品が何であるか、そしてそれらをどのように使用するかを教えることが求められました。技術系企業が増えるにつれて、製品そのものが主要な焦点ではなく、どのように統合するかが主要な問題となりました。これにより、DevRel は一般に広まり、ますます多くの人が DevRel になりました。多くの企業が DevRel を通じて独自のエコシステムを構築し、エコシステムパートナーを通じて徐々に強化されていきました。例えば、Twilio や Spotify などです。この点については次の章で詳しく説明します。

DevRel の定義には、教えることや指導することだけでなく、開発者コミュニティとのインタラクション、関係構築、サポートの提供も含まれます。開発者コミュニティとの密接な関係を築くことで、DevRel は開発者のニーズや問題をよりよく理解し、適切な解決策を提供できます。このようなインタラクションは、開発者間の協力や知識共有を促進することもできます。したがって、DevRel は単なるマーケティング手法ではなく、開発者と共に成長するプロセスでもあります。

さらに、技術系企業が増えるにつれて、DevRel の重要性も増しています。技術製品の競争が激化する中で、優れた製品だけでは不十分であり、DevRel を通じて製品の価値や利点を伝える必要があります。開発者コミュニティとの協力を通じて、技術系企業は自社の製品をより良く宣伝し、より多くの開発者に使用され、支持されるようになります。

現在、DevRel は技術業界において非常に重要な役割を果たしています。それは単なるマーケティング手法ではなく、開発者コミュニティと密接に協力する方法でもあります。開発者コミュニティとの良好な関係を築くことで、DevRel は技術系企業が製品を宣伝し、問題を解決し、開発者間の協力や共有を促進するのを助けることができます。次の章では、DevRel の具体的な実践や事例について詳しく探求します。

この引用は非常にクラシックだと思います。確かに DevRel の日常的なノルムを説明しています（全能ではなく、具体的には dev + mkt + prod の融合です）。

リードを生成し、ドキュメントを引き継ぎ、製品管理のパートナーとなり、現地コンサルティングを行い、カンファレンスブースを整理し、予算を立て、マーケティング資料を作成し、製品開発に参加し、毎週のワークショップを作成・運営し、他の製品への統合を維持し、勤務時間の最大 80% を地域を旅行すること。
—— Alexander Reelsen

Dev Evangelist、Dev Advocate、Dev Relations#

ここで、この 3 つの職種について説明します。私の見解では、どれもほぼ同じです。ただし、機能的には会社によって異なる場合があります。

通常、このような分割ができる会社は大企業であり、小企業ではこのような分割はほとんど実現できません。私の知る限り、Polygon、Circle、BNBChain には明確な分業があります。Circle は DevRel に関して、MKT の下に 3 つの部門に分かれています（この点については後で話します）。DevRel チームの創設メンバーは Twilio の DevRel チームのメンバーです（Twilio の DevRel は業界で非常に評価されています）。Circle の Dev コミュニティの導入は Dev Advocate が担当します。Evangelist はワークショップや講演を担当します。最後に、Dev Relations はドキュメントとデモコードを担当します。これは大企業のやり方です。他の中小企業では、あまり細かく分けることはありません。

BNB Chain にいたとき、私たちにはソリューションアーキテクトと DevRel がいましたが、イベントの場所に応じて異なる人員を派遣することが多かったです。例えば、私の上司はドバイにいて、ドバイ、インド、中東地域のイベントに参加します。ソリューションアーキテクトはヨーロッパにいて、EthCC には彼が参加します。私はちょうどヨーロッパにいたので、Eth Lisbon の講演にもゲストとして参加しました。

コード、コミュニティ、コンテンツ：DevRel の三大支柱#

次の段落では、より科学的な方法で DevRel の主要な役割を説明します。私たちは 3 つの C と 5 層のピラミッドを通じて細分化できます。3 つの C は主に「コード」、「コミュニティ」、「コンテンツ」を指します。まずはこの 3 つの C について話しましょう。

コード#

コードはデモリポジトリ、ライブコーディング、そしてすべてのコード関連の内容を表します。現在、私はいくつかの良い例を見ています。例えば、lensV2やJarradsのボイラーテンプレートや動画。コードの例やライブコーディングは、開発者がさまざまなサービスを統合するのを迅速に助けることができます。これは非常に重要です。なぜなら、良いコードの例はエコシステム内の開発者が効率的に作業できるようにするからです。コードの例は通常ドキュメントと関連付けられ、ライブコーディングはコミュニティやイベントの一部です。したがって、業界の議論では、DevRel（開発者関係）はコードをあまり強調する必要がないと言われることが多いです。しかし、私はこの見解は正しくないと思います。開発者の開発パスを理解することで、私たちはより良いドキュメントを作成し、デモ / SDK を使用して開発者がエコシステムに参加するのをより良く支援できるのです。

コミュニティ#

DevRel の分野における「コミュニティ」という概念は、開発者エコシステムとイベント（オンラインとオフライン）の 2 つの主要な部分を含んでいます。

開発者エコシステム#

まず、開発者エコシステムを見てみましょう。伝統的に、開発者エコシステムの管理は通常開発運営（developer operations）の仕事であり、Docker や CI/CD などの DevOps の仕事とは異なります。BNB の例を挙げると、彼らは BNB Discord に専用の開発運営チームを設け、ノードの設定や Greenfield 開発など、開発者が直面するさまざまな問題を処理しています。一方、私たち DevRel の主な役割は通常、外部への技術的な説明です。しかし、小規模な企業では、DevRel と開発運営の役割が重なることが多く、コミュニティで発生する技術的な問題は通常 DevRel が解決します。例えば、Lens の開発者コミュニティでは、Nadar が直接問題に介入して回答し、コミュニティのインタラクションを増やしています。

イベント#

もう一つの重要な部分はイベントで、オンラインとオフラインのイベントが含まれます。オンラインイベントにはコミュニティコール、AMA、ワークショップなどがあり、DevRel のメンバーは基本的にこれらのイベントをこなすことができます。以前のデータや経験から、技術コミュニティの通話は議論を促進し、プロジェクトの活発さを示す効果的な方法です。AMA は外部主導のものもあれば、内部主導のものもあり、具体的なニーズによって異なります。例えば、私は ZetaChain や Greenfield の AMA に参加し、毎週 AI x Web3 の AMA を主催して、各プロジェクトに参加してもらっています。オンラインとオフラインのワークショップの最大の違いは、聴衆の熱意の感知です。オンラインイベントは多くの場合、複数の画面操作が関与するため、フィードバックを即座に得ることができない場合がありますが、オフラインイベントでは、参加者が直接現場でインタラクションできるため、観客の感情を感じ取りやすくなります。オンラインワークショップの利点は、社交不安を抱える人々がより簡単に参加できることです（starkastroCN、LW3、Developer Dao が主催するオンラインワークショップなど）。

オフラインイベントについては、ハッカソン、開発者会議（devcon）、ETHCC など、状況はさらに多様です。これらの会議では、DevRel がブースを担当し、参加者が技術や製品をよりよく理解できるように手助けします。ハッカソンでは、DevRel の役割が特に重要です。なぜなら、私たちが外部にどのように見せるかを最もよく理解しており、参加者が問題を解決するのを最も助けることができるからです。これらの会議では、常に常駐の DevRel に出会うことができます。例えば、Nadar（Avara、Lens/AAVE）、Simon（Edge&Node、The Graph）、Kevin（Polygon）、Mirko/Francescco（Consensys&MetaMask）などです。DevRel は密接な小さなサークルを形成しています。さらに、オフラインのトークやワークショップ、HackerHouse のシェア会やさまざまなイベントでの講演も通常 DevRel が担当します。技術の外部への伝達は私たちの重要な任務の一つです。

コンテンツ#

DevRel において、コンテンツ制作は不可欠な要素であり、主に 2 つの大きなカテゴリに分かれます：テキストと動画です。

テキストコンテンツ#

テキストコンテンツは、技術分析、ドキュメント、チュートリアル、コース、スレッドなど、さまざまな形式を含みます。私の個人的な経験を例に挙げると、私はドキュメント、チュートリアル、スレッドを書くのが好きです。通常、私たちの公式 Twitter のスレッドはテクニカルライターが担当し、私は自分が行った研究や DML 関連の内容を書くことが多いです。ここで、ドキュメントの維持に関する私の経験を共有します。多くの場合、開発者はドキュメントを書くのを好まないですが、良いドキュメントは開発者が入門するための鍵です。どのように書くか、理解しやすく、タイムリーに更新することが重要です。また、ドキュメントを書くことは単に手順を記録し、説明するだけでなく、魅力的な方法で物語を組織し、各情報点が一貫してつながるようにする必要があります。そのため、私は毎月 3〜4 日をかけて、私たちのドキュメントを改善する方法を考えています。チュートリアルについては、自分を初心者だと思い、理解の論理に従って、初心者が理解できるなら誰でも理解できるはずです。私がドキュメントを書くときは、まずテーマを考え、このチュートリアルが達成したいことを決め、次にコードを分解し、長さを決定します。最後に、書き始めます。書き終えたら、自分を初心者として位置づけ、何度もテストを行い、内容を最適化し改善します。

動画コンテンツ#

動画コンテンツの制作はもう一つの重要な分野です。業界のリーダーである Patrick Collins、Nadar、Jarrods の動画制作方法から多くを学びました。YouTube ショートの制作は通常、60 秒以内に概念やストーリーを完結に伝えることを強調します。一方、通常の動画コンテンツはより広範で、通常はデモや統合使用方法を中心に展開されます。例えば、ワークショップやパネルの録画動画は貴重な学習リソースです。私は個人的には直接コードを読むことを好みますが、異なる学習スタイルを考慮すると、動画と Git リポジトリを組み合わせる方法は非常に良い選択です。特に、受 audience が不明確な場合にはそうです。How to 系のコンテンツに関しては、動画がより適切な紹介方法です。なぜなら、視覚的な効果を通じて、私たちの製品の使用方法や注意点を直感的に示すことができるからです。

ピラミッド#

以上が私の 3C に対する理解です。記事を書く際に、さらに細分化された説明を調査しました。この説明は、DevRel の大まかな仕事のタスクを実際に示しており、他の雑務は misc に置いておきます。私が上で述べたように、DevRel は通常、テクニカル BD / プロダクトマーケティングに非常に近いですが、多くの違いがあります。DevRel の最も重要な原則は、自社製品の理解を深め、製品の技術的原理、ユーザーの論理、実行の論理を知ることです。次に、さまざまな手段を通じて、これらの情報や利点をすべての人が理解できる言葉に変換します。手段はイベント、ワークショップ、コンテンツの発信などです。しかし、重要なのは、皆が私たちが何をしているのか、なぜそれを使うのか、どうやって使うのかを理解できるようにすることです。

イベント
ワークショップ & ウェビナー
教育コンテンツ
コミュニティサポート
ドキュメント & オンボーディング

Developer first & Developer Plus#

DevRel の世界では、私たちは会社を 2 つのタイプに分けます：Developer First と Developer Plus。

Dev First は、開発者を主要なユーザーとする製品で、通常は開発者ツール、開発支援ツールが中心です。著名な例としては、Vercel、MongoDB、Twilio があります。この種の製品の目標は、より多くの開発者が SDK やサービスを使用して開発することです。彼らは開発者に優れた開発体験を提供し、アプリケーションの開発と展開をより効率的に行う手助けをしています。これらの製品は通常、豊富なドキュメント、サンプルコード、サポートを提供し、他の開発ツールやサービスとの統合を行います。開発者のニーズを満たし、彼らの成功を助けることで、Dev First の企業は強力な開発者コミュニティと忠実なユーザー群を築くことができます。
Dev Plus は、開発者を副次的な目標または付加価値として扱う製品であり、主要な焦点ではありません。これらの企業のコアビジネスは通常、企業や消費者向けの製品です。彼らは開発者ツールやサポートも提供しますが、開発者は主要なユーザー群ではありません。逆に、彼らの製品は企業や消費者のニーズを満たすことに重点を置き、ソリューションやサービスを提供します。著名な Dev Plus 企業には Apple、Google、Microsoft があり、彼らはさまざまな分野で強力な市場地位を持ち、革新的な製品や技術で多くのユーザーを惹きつけています。

DevRel において、Developer First と Developer Plus はどちらも重要な役割を果たしています。彼らは共に開発者エコシステムの発展と革新を推進しています。Developer First の企業は優れた開発者体験やツールを提供することで、多くの開発者を惹きつけ、開発者コミュニティの繁栄を促進しています。一方、Developer Plus の企業は企業や消費者向けの製品を通じて、技術の応用と普及を推進し、開発者により広範な市場と機会を提供しています。

Developer First でも Developer Plus でも、DevRel の目標は開発者との良好な関係を築き、彼らのニーズを理解し、サポートを提供することです。イベントに参加し、ワークショップを開催し、知識を共有することで、DevRel は開発者と深い交流と協力を行い、彼らの問題を解決し、技術レベルを向上させ、製品の革新と発展を促進します。総じて、Developer First と Developer Plus は DevRel において重要な役割を果たし、それぞれ異なる位置付けと目標を持っています。開発者に焦点を当てた製品であれ、開発者を補助的な目標とする企業であれ、彼らは開発者に豊富なリソースとサポートを提供し、開発者エコシステムの繁栄と革新を推進しています。

Mkt or Ops or Dev? 私はどこにいるべきか！#

多くの DevRel との交流やいくつかの会社の面接を経て、私は DevRel に対する会社ごとの理解と位置付けに大きな違いがあることに気づきました。これには正しいも間違っているもなく、実際の効果の考慮が重要です。一部の企業は DevRel をマーケティング部門の一部と見なしており、他の企業は技術部門に属すべきだと考えています。また、DevRel は運営役割に近いと考える企業もあります。これらの異なる視点は、DevRel の全体的な戦略や役割の位置付けを大きく決定します。

明らかに、ここで中庸の立場を取ることはできません。むしろ、DevRel の多様性は、私たちが以前に述べた「3C」原則と呼応しています。「コンテンツ（Content）」はマーケティング（Marketing）に対応し、「コミュニティ（Community）」は運営（Operations）に対応し、「コード（Code）」は開発（Development）と結びついています。各企業は自社のビジネスニーズや戦略目標に基づいて、DevRel の役割の理解と期待が異なります。

伝統と Web3#

私は伝統的な web2 の DevRel の仕事をしたことがないため、この部分は主に私がインタビューした web2 から web3 への DevRel と私が収集した資料に基づいています。

伝統的な DevRel と web3 の DevRel の間には、コアに大きな違いはありません。主な業務も似ています。しかし、web2 の DevRel はより商業的であり、web3 の DevRel はコミュニティの発展により重点を置いています。

"web2 companies are actually profitable lol so it's much easier to see exactly how devs translate into profit, which in turn makes it easier to measure and plan devrel" - cat

この引用は、私の DevRel 分野の友人である Aztec の Cat からのものです。彼女の言葉は、Web2 と Web3 の企業が DevRel の重要性に対するアプローチの違いを明らかにしています。Web2 企業では、サブスクリプションモデルや製品課金モデルを採用しているため、さまざまな開発者関係活動が収益に与える影響をより直接的に観察できます。それに対して、Web3 の DevRel の仕事では、KPI を追跡し、メトリックを設定することがより困難です。例えば、私たちはチェーン上の取引量やアプリのダウンロード数といった直感的なデータ指標に依存することがありますが、これらは特に製品がテストネットの段階にあるときには、収益に直接反映されるわけではありません。

イスタンブールで、私は多くの DevRel と Web3 の状況について深く議論する機会がありました。特に印象に残ったのは、「Web2 時代、私が担当していた開発者の数は 1 万から 10 万の間で、各人の状況を深く理解することは難しかった。しかし、Web3 時代では、開発者コミュニティの規模が小さく、メンバーはさまざまなイベントで頻繁に交流し、密接な小団体を形成している」という意見です。実際、2023 年 10 月のDeveloper Reportのデータによれば、Web3 分野の月間アクティブ開発者数は19,279人で、推定フルタイム開発者は約6,279人です。これは、Web2 に比べて Web3 の開発者コミュニティが相対的に小さいことを示していますが、これこそが独自の関係ネットワークを形成できる理由です。

私の別の友人 Rod は、「Web3 の開発者は小さな家族のようで、さまざまなハッカソンイベントで頻繁に出会います。この環境は特別な人間関係を促進し、交流の機会を提供します」と言いました。Web2 に比べて、Web3 ではコミュニケーションがより親密で個性的です。参加者が少ないため、この親密感は私が Web3 を特に好きな理由です。それはまるで大家族のような感覚を与えてくれます。

心得感受#

3 月から BNB Chain で DevRel を始めてから、もう半年が経ちました。まるで 2〜3 年が経過したかのように感じます。Web3 は一日が人間の一年に相当するというのは本当です。今年は多くの場所に飛び回りました。正直なところ、10 年間イギリスにいた間、帰国以外ではほとんど外に出たことがありません。今年は 25% の時間を会議に費やし、DevRel の 25% 旅行という基準を達成したことになります。4 月の ETH Lisbon、7 月の EthCC、8 月の GHH、9 月の Token2049、11 月の Devcon。この 10 ヶ月間で本当に多くの異なる試みを行い、試行錯誤を繰り返し、まとめ、改善し、自分を進歩させてきました。今年行ったことをまとめてみます。

今年は 2 つのオフラインイベント、token2049 の What the flock、ETH London の DML night の準備に参加しました。
3 つのハッカソンの審査員を務めました。BNB Chain の Zero2Hero（協力）、HomeDao Hack、ETH London です。
4 つのハッカソンに参加しました。ETH Lisbon、ETH Paris、ETH Singapore（Card3 チームに感謝）、ETH Istanbul です。
50 以上のイベントに参加し、5 つ以上のオフラインワークショップ、10 以上のオンライン共有を行いました。
コンテンツに関しては、多くのものが現在準備中で、順次更新される予定です！

全体的な体験を通じて、DevRel は非常に複雑な職種であり、私はそれをライフスタイル（生活様式）と呼ぶことを好みます。3C の他に、DevRel の主旋律は出張です。特に大規模なハッカソンや開発に焦点を当てたカンファレンス（devcon、edcon）では、出張が続く中で、DevRel は徐々にライフスタイルになっていきます。各地で地元の開発者と接触し、痛点を理解し、解決します。今年は多くの場所に行き、面白い出来事をたくさん見ました。

研究と物語#

DevRel の基本的な責任の他に、私は自分で研究を行っています。DevRel にとって、新しいトレンドや技術を探求することは非常に重要だと思います。これは新しい物語の理解だけでなく、これらの物語を既存の技術フレームワークと組み合わせて革新的な試みを行い、新しい開発者グループを惹きつけることを含みます。

パリで bob, the solver の講演を聞いた後、私はすぐに私たちの製品技術を彼の見解とどのように結びつけるか、分類器に依存せず AI エージェントを使用する方法を考えました。
DAO と AI エージェントの結合について、William（42 Agents）と safe も現在この方向を見ています。私はこの方向性に非常に期待しています。投票の自動化が進むことで、投票の効率が向上します。
内部で始まった学術研究、ZK の結合や去中心化算力の結合について研究しています。

多くの場合、DevRel はテクニカル BD に非常に近いため、会議で話した多くのプロジェクトも私がフォローアップし、ドキュメントをレビューすることになります。日常的に、DevRel が会議に参加する際、BD が言ったことは私が言ったことです。ドキュメントのレビューは非常に挑戦的なタスクです。私はプロジェクトの内容、操作方法、使用される SDK、さらには専用の言語があるかどうかを完全に理解し、これらの情報に基づいて潜在的な協力案を考える必要があります。これは、私が自社の技術を熟知しているだけでなく、市場のトレンドを洞察し、パートナーのプロジェクトビジョンや技術実現を理解することを要求します。最近では、私たちが去中心化算力とどのように協力し、ユーザーがデータを提供するだけで算力を借りることを許可するかを検討しています。良い DevRel は、自社の製品を使用したことがあり、自社製品に非常に精通している必要があります。

ハッカソン#

私が最も好きな部分はハッカソンです。ハッカソンは素晴らしい場面で、多くのハッカーが集まり、素晴らしい交流と学習の機会を提供します。DevRel として、ハッカソンに参加することは最高の学びとインタラクションの場だと思います。ここでは、多くの DevRel がハッカーの製品構築を支援しているのを見ることができ、そのプロセスは創造と協力の雰囲気に満ちています。

私がハッカソンに参加したり審査員を務めたりする理由はシンプルです。全体のプロセスを深く理解することで、他の参加者をより効果的に指導し、サポートできるからです。DevRel のハッカソンにおける主要な KPI はプロジェクト数です —— 私たちはできるだけ多くのプロジェクトが私たちの技術を使用することを望んでいます。これにより、後のデータ分析に十分なサンプルを提供できます。例えば、ETH London では、私は主に 2 つのことを行いました。1 つはチュートリアルを簡素化することです。私たちのバウンティはアプリケーションの革新に焦点を当てているため、参加者が私たちのコードを統合するのにあまり時間をかけないようにしたいと思いました。私はインターフェースコードと返されるデータを直接示し、統合プロセスをより直感的で簡単にしました。もう 1 つは、毎日 1 時から 2 時の間に会場を巡回し、開発者の進捗状況を把握し、私たちのバウンティタスクを宣伝することです。私は、午前 1 時から 3 時の間が参加者が比較的空いている時間帯であることに気づきました。なぜなら、皆が高強度の作業の後に休憩時間を持つからです。これは彼らと交流するのに最適な時期です。

私の経験と実践に基づいて、最終的な反響は非常にポジティブでした。合計 12 のプロジェクトが私たちのモデル API に接続され、私たちの期待を大きく上回りました。ハッカソンで参加者を惹きつけることは、ある意味で地推活動に似ています。特にこのような高密度の開発者集結の場では、審査員の立場を利用して開発者と深く交流し、私たちのバウンティタスクや製品を宣伝し、彼らの問題を解決する手助けをすることが、さらなる深い関係を築くのに役立ちます。この時の一つの賛辞は、「ありがとう Tim、確かに私たちの戦いの間に唯一一緒に起きていた人で、サポートに感謝します」というものでした。これは私が努力した甲斐があったと感じさせてくれました。

イベント、ワークショップ、AMA#

まずは会議について。今年、私はさまざまなイベントや会議に参加し、時折自分が BD のように感じることがあります。今年の経験から、実際に開発者を惹きつけることができるイベントはあまり多くないことがわかりました。開発者はハッカソンの前後で探し回る必要があります。したがって、ターゲットを絞ったプロモーションや特定の小規模グループへの参加が重要になってきます。この点に関して、ElectricCapital の Developer Report は私にとって非常に役立ちました。これは DevRel 分野の聖書のようなもので、開発者エコシステムに関する深い分析を提供してくれます。このレポートを通じて、現在の開発者コミュニティの状況を明確に理解できます。当然、オープンソースの視点から見ると、プロジェクト自体がオープンソースでなければ、これらの分析は意味を失います。

全体的に、イベント、ワークショップ、AMA の組織と参加は非常に挑戦的な仕事です。私は常に効果的なコミュニケーションを考え、参加者が私たちの作業内容を迅速に理解できるようにする必要があります。AMA では、ゲストの発言を迅速に記録することが不可欠であり、各ラウンドの回答では、観客の記憶を高めるためにエコーを行います。ワークショップの準備は教師の授業準備に似ており、どのように教え、説明するかを深く考える必要があります。開発者のニーズはさまざまであるため、優れた開発者コミュニティを構築するための一つの答えは存在しません。絶え間ない試行、接触、議論を促すことで、徐々にコミュニティを築くことができます。コミュニティを迅速に構築するための近道はなく、すべてには時間と継続的な努力が必要です。しかし、確かなことは、継続的にイベントやワークショップを開催することで、私たちの努力を示し、開発者の参加を効果的に惹きつけることができるということです。

まとめ#

最後に言いたいのは、DevRel は本当に複雑で、痛みと喜びが共存しています。開発者がますます増えることを願っていますし、私たちがより多くの開発者を引き込むことができることを願っています。ここでは主にプロジェクト側の視点から、私が見たことや行ったことを基に話しています。実際には純粋な開発者コミュニティのアプローチもありますが、私はその点についてはあまり詳しくありません。

timtimtim