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 が 3 つの部門に分かれており、MKT の下にあります（この後に話します）。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 リポジトリを組み合わせる方法は特に受け手が不明な場合に良い選択です。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 は 1 日が人間の 1 年に相当するというのは本当です。今年は多くの場所に飛び回りました。正直なところ、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 の講演を聞いた後、私はすぐに私たちの製品技術を彼の見解とどのように結びつけるか、classifier に依存せずに ai agent を使用する方法を考えました。
DAO と ai agent の組み合わせについて、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