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 の話を聞いた後、私はすぐに私たちの製品技術を彼の見解とどのように結びつけるか、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