Web3 の成功にとって開発者との関係が重要なのはなぜですか?

前回は、初期段階のスタートアップがどのように開発者コミュニティを構築し、製品と市場の適合性を追跡するかを調べました。効果的な開発者対応チームがなければ、これらの取り組みは成功する可能性が低いです。

開発者関係の専門家は情報ハブとして機能することが多く、製品、販売、マーケティングなどの他の運用チームと連携して全員に情報を提供することがよくあります。Web3 スタートアップの多くは開発者中心であるため、この役割をより深く理解する必要があります。具体的には、開発者との効果的な関係が初期段階でどのように価値を付加するのか、そしてそれが Web3 エコシステム全体の健全性にとってなぜ重要なのかについて説明します。

この記事では、次の点について説明します。

開発者関係とは何か、そしてそれはどのように進化してきたのか。
開発者との関係が資金調達サイクルを通じてスタートアップの成長をどのようにサポートできるか。
初期の Web3 スタートアップにとって、開発者との関係における重要な側面。
開発者関係職を採用する際に注意すべきこと。
開発者との関係が業界として Web3 をどのように前進させることができるか。

開発者関係とは何ですか?

開発者関係 (略して「DevRel」) は、サードパーティ開発者に特定のテクノロジエコシステム用のソフトウェアとアプリケーションの構築を奨励するという共通の最終目標を持つ一連の活動を表します。

DevRel の簡単な歴史

DevRel の役割を理解することは、DevRel が登場した背景をより深く理解するのに役立ちます。オープンソース運動が成長するにつれて、多くの人が開発者関係の傘下に入る役割を担い、擁護や教育を提供するようになりました。しかし、企業が開発者に対してより積極的に販売を開始するまで、それは明確な職業として発展しませんでした。

ソフトウェアエバンジェリストの誕生

Apple は 1980 年代に「ソフトウェアエバンジェリスト」という役職を導入し、このアプローチの先駆者となったと言われています。その仕事は、開発者に macOS およびその後の iOS 向けのアプリを開発するよう奨励することでした。

Apple は、プラットフォームの価値は、その上で実行されるアプリと同じであることを認識しています。たとえば、iPhone がこれほど成功した理由の 1 つは、消費者がさまざまな魅力的なアプリにアクセスできるようになったことです。これらのアプリの多くは元々 Apple 自身によって開発されましたが、エコシステムはサードパーティアプリが App Store アプリの 99.99 パーセントを占めるまでに成長しました。

製品主導の成長と開発者第一のアプローチの台頭

2016 年、OpenView Venture Partners の Blake Bartlett は、Optimizely や DataDog などの企業に投資した後、「プロダクト主導型」(PLG) という用語を作りました。PLG の背後にある前提は、トップダウンの販売やマーケティングに巨額の投資を必要とせずに、製品の採用が有機的に拡大できるということです。このモデルは、個人がサインアップして製品を無料で試用できるようにすることで成長を促進するために、SaaS 企業によってよく使用されます。目標は、個々のユーザーが自分の部門や専門的ネットワーク内で製品を宣伝することです。

PLG は、Stripe、Twilio、MongoDB など、開発者を直接ターゲットとする企業に特に効果的です。これらの企業は、成長を促進する手段として DevRel 戦略を使用しています。DevRel が必要なのは、開発者が最高のオンボーディングエクスペリエンスを提供するための適切に設計されたユーザーインターフェイスを持っていないためです。さらなるサポートが必要です。人々が新しい API や SDK に慣れるのに役立つシームレスなフロントエンドエクスペリエンスがありません。

そのため、DevRel は、特に開発者エクスペリエンス (DX) のあらゆる側面に焦点を当て、開発者に良い第一印象を与える上で重要な役割を果たします。

DevRel は、いくつかの機能部門の総称です

Twilio や Atlassian などの開発者中心の大企業には、完全な DevRel 部門があり、職務が開発者マーケティングやコミュニティ管理などのさまざまな DevRel 機能に分類されています。小規模なスタートアップでは、これらの職務は、肩書きに「DevRel」さえ含まれていないジェネラリストによって実行されることがよくあります。

以下の図は、DevRel 機能が通常どのように分割されているかを示し、その基本的な目標を比較しています。

「開発者関係の 4 つの柱」 -developerrelations.com から抜粋

認識は明らかですが、開発者中心の製品における「アクティベーション」の概念を正確に把握するのは必ずしも簡単ではありません。API ベースの製品の場合、通常、開発者がアクセストークンを作成し、最初の API 呼び出しを行うときです。SDK またはライブラリの場合、コード内で関数をインポートして使用するのはこれが初めてである可能性があります。製品によって、開発者向けのアクティベーションプロセスは異なります。

Web3 における開発者関係

Web3 における DelRel の役割と目標は、Web2 のものと非常に似ています。どちらの場合でも、DevRel プロフェッショナルは、それぞれ独自の文化を持つさまざまなオープンソースコミュニティに対応する必要があります。Web3 DevRel 実践者にとっての課題は、適切なメトリクスを追跡し、低レベルのエンジニアリングタスクを簡素化するツールが不足していることです。たとえば、Web2 フロントエンド開発者は、React や Vue.js などの成熟した専用ビルドフレームワークを備えており、完全に機能する Web アプリケーションを作成する時間が大幅に短縮されます。また、Web3 では、同等のフレームワークがまだ成熟していないため、Web3 の教育者は、新しい開発者を最新の状態に導くためにさらに多くの作業を行う必要があります。

Web3 DevRel はまだ初期段階にあります

Consensys、Alchemy、Chainlink Labs など、一部の Web3 組織には完全な DevRel 部門がありますが、これらは依然として少数派です。ほとんどの Web3 スタートアップには DevRel 担当者が 1 名しかいないか、まったく担当者がいません。代わりに、DevRel 関連の機能はさまざまなチームメンバーに分散されます。

Web3 チームには DevRel の役割を担っている人が複数いますが、それらの人は通常、Web3 で長く働いているわけではありません。過去 12 か月間で、多くの人が Google、Facebook、Amazon などの Web2 大手企業で同等の役割から異動しました。これは、Web2 DevRel コミュニティによって無視されていません。実際、DevRelCon の創設者 Matthew Revell は、2022 年 1 月に「ブロックチェーン企業で上級開発者関係担当者として働くこと」が今後 1 年も主要なテーマになるだろうと予測しました。

その結果、ほとんどの DevRel プロフェッショナルは依然として適応しており、専門コミュニティとして知識を集約するのではなく、特定のプロジェクト固有の目標をサポートする最適なシナリオのセットを構築することに重点を置いています。

DevRel はさまざまな種類の Web3 組織にとって重要です

Web3 開発者コミュニティについて議論する際、Web3 開発者コミュニティを構築する必要があるプロジェクトの種類について簡単に紹介しました。開発者コミュニティの構築は DevRel の範囲内であるため、開発者コミュニティを構築したい企業は、DevRel がどのように機能するかを理解する必要があります。

要約すると、開発者コミュニティに依存する企業は、同様のビジネス目標を持つ 3 つの大きなカテゴリに分類できます。

Web3インフラストラクチャ

このカテゴリは、特定のプロトコルに結び付けられるのではなく、Web3 エコシステム内での相互運用性を促進する幅広いツールとテクノロジーのセットをカバーします。

データオラクル
レイヤ 2 拡張ソリューション
ブロックチェーンと対話するための API
KYC管理プラットフォーム
分散ファイルシステム
ブロックチェーンアプリケーションを構築するための SDK とミドルウェア

DevRel のビジネス目標は、同社のテクノロジーを使用した統合の数を増やし、API 呼び出しやスマートコントラクトのやり取りに請求される料金によって得られる収益を増やすことです。

L1 ブロックチェーンと DeFi プロトコル

ブロックチェーンテクノロジーのメンテナンスは分散チームによって管理されることがよくありますが、開発者の教育は通常、イーサリアム財団やカルダノ財団などのオープンソース財団によって処理されます。

DevRel のビジネス目標は、このプロトコルを使用するプロジェクトの数を増やし、それによって取引手数料を通じて収益を増やし、その手数料をマイナーやノードオペレーターにネットワークを保護するよう奨励するために使用されることです。

取引所と市場

これらは通常、デジタル資産を売買するための集中プラットフォームです。これらは主にエンドユーザーを対象としていますが、取引体験の特定の側面を自動化したい開発者向けの API と SDK も提供しています。

DevRel のビジネス目標: 統合の数を増やし、それによってプラットフォーム上のトランザクションアクティビティを増加させ、トランザクション手数料から得られる収益を増やすことです。多くのプロトコルでは、開発者が dApp で使用できる、集約されたトランザクションデータへの無料および有料アクセスも提供します。

これらの分野で市場シェアを築きたいと考えている Web3 スタートアップ企業は、できるだけ早く DevRel に投資する必要があります。当然のことながら、シード前の段階では、スタートアップは製品を完成させることに集中しますが、資金が確保されると、DevRel が非常に重要になり、プロジェクトに対する投資家の信頼を築くのに役立ちます。

DevRel がスタートアップ資金をサポートする方法

早い段階で DevRel をマスターすることを学んだスタートアップは、スタートアップの資金調達段階をより早く通過できる可能性が高くなります。「開発者コミュニティの防御性と価値」と題したプレゼンテーションで、開発者ファーストのスタートアップに焦点を当てたベンチャーキャピタル会社Heavybitのゼネラルパートナーであるダナ・オシロ氏は、DevRelの専門家がどのように投資を奨励するのに役立つかを説明しました。 -アップ企業。彼らは、投資家が関心のある指標に貢献することでこれを実現します。

資金調達段階とDevRelの役割についての大城氏の分析は次のとおりです。

シードラウンドの資金調達

プレシードまたはローンチ段階では、DevRel 機能は通常、アドホックかつ無計画な方法で設立チームに分散されます。デモは、人前で話すのが最も得意な開発者によって実行され、共同創設者がドキュメントを作成し、別の共同創設者が開発者のマーケティングを担当する場合があります。

全体的な目標: この段階で、潜在的な投資家は、創設者が製品と市場の適合性を検証し、十分な数の早期導入者がそれを使用し続けることを確認したいと考えています。
ステージの目標と指標: 投資家は、Web サイトのトラフィック、ソーシャルメディアの活動、コミュニティの登録、デモの数、収集された開発者のフィードバックの量など、初期のユーザーの粘着性と関心を示す指標に最も関心があります。
DevRel 機能が複数のチームメンバーに分散している場合でも、スタートアップ企業にとって、中核となる機能領域での初期の DevRel の取り組みを一元的に調整し、追跡し、定量化することが重要です。これは、投資家に売り込む際の信頼性を高めるのに役立ち、資金調達の次の段階に進むのに役立ちます。

資金調達のラウンド

シード資金を賢明に展開するというプレッシャーがあるため、専任の DevRel スペシャリストが非常に重要です。投資家は資金が枯渇する前に次のマイルストーンに到達できると確信する必要があるため、スタートアップの運営にはより厳しい目が向けられています。DevRel プログラムの実装とその追跡は、創設者や主任開発者の副業ではなく、フルタイムの仕事になりました。

全体的な目標: 投資家は、貴社が開発者を獲得して維持していることを確認し、参考や事例研究として役立つ成功したプロジェクトを特定し始めたいと考えています。
段階的な目標と指標: 投資家は、次の種類の目標を達成しているかどうかを確認したいと考えています (これらは、開発者のインタラクション、顧客の紹介、コミュニティメンバーの維持などの指標を通じて追跡されます)。
製品とコミュニティの認知度を高める
初めての API またはスマートコントラクト呼び出しを行う意欲のある開発者を獲得します。
画面とチャネルの製品フィードバック。DevRel の専門家は、プロセスの標準化、投資家が見たい指標の収集、開発者のオンボーディングプロセスにおける摩擦の解決に不可欠です。

シリーズA資金調達後

この時点では、この人は圧倒されてしまうため、DevRel の採用だけでは十分ではない可能性があります。企業は、DevRel 部門を、開発者コミュニティマネージャー、開発者マーケティングリードなどの独立した役割、またはアジアおよび英語圏市場の開発者アドボケートなどの地域ごとに分割し始める必要があります。

全体的な目標: 防御力。投資家は、貴社が開発者を獲得して維持し、参考や事例として役立つ十分な成功した開発者を抱えていることを望んでいます。
段階的な目標と指標: 投資家は、何千万もの資金調達ラウンドを求めるとき、スタートアップの勢いを洞察できるより詳細なデータを見たいと考えています。これにより、以下のことが可能になります。
引き続き認知度を高め、製品のフィードバックに基づいて行動します。
テクノロジーに忠実な開発者を維持してください。
開発者自身がテクノロジーを推奨および宣伝するよう奨励します。
重要な指標は、Github フォーク、統合、統合の数、およびエコシステム内のサードパーティアプリケーションやパートナーの数になります。
スタートアップ企業は、さまざまな機能分野に焦点を当て、エコシステムの成長や製品エンゲージメントなどの各コアカテゴリの指標を提供できる専門家で構成される DevRel チームを構築する必要があります。

もちろん、各段階で収益を追跡することも重要ですが、これは DevRel の主な責任ではありません。ただし、DevRel 実践者にとっては、自分たちの取り組みとスタートアップの財務健全性との直接的な関係を理解することが重要です。一部の取り組みは収益につながりにくく、特に初期段階では成果を上げるまでに長い時間がかかるため、これは難しい場合があります。

初期段階のスタートアップは DevRel のどの側面に焦点を当てる必要がありますか?

開発者ファーストのスタートアップの多くは、開発者の支援とコミュニティを第一に重視しています。これは、マーケティング機能やコミュニケーション機能が無視されているという意味ではなく、むしろ、これらの機能は以前と同様にチーム全体に分散されています。一方で、イネーブルメント機能とコミュニティ機能は、個々の専門家がフルタイムで責任を負うことになります。

下の画像は、エンパワーメントとコミュニティに重点を置いたスタートアップの DevRel プロファイルを示しています。

初期の Web3 スタートアップの DevRel 重点分野

なぜ視認性を重視しないのでしょうか？

まず、これは特定の段階のスナップショットであり、永続的な状態ではないことに留意してください。スタートアップがチームを構築するにつれて、ディストリビューションは可視性に戻ります。しかし、初期段階では、スタートアップはユーザーを維持するよりも、早期に認知度を高めるほうが得意であることがよくあります。

創設者は資金を集めるためにネットワーク効果を構築するという強いプレッシャーにさらされているため、これは特に Web3 プロジェクトに当てはまります。重要なのは、製品全体のビジョンとロードマップについて人々を興奮させることです。

しかし、開発者の時間と注意を争うプロジェクトが無数にあります。説得力のあるビジョンだけでは十分ではありません。開発者のエクスペリエンスが低く、コミュニティの反応が鈍いと、すぐに好意が失われ、開発者は摩擦の少ないプロジェクトに移行することになります。開発者を維持する能力なしに認知度を高めるのは無駄です。

開発者のエンパワーメントを促進する戦略

一般的なイネーブルメント戦略の多くは、多くの開発者中心の企業にとって馴染みのあるものです。しかし、多くのスタートアップは依然としてそれらを無視しているか、不十分な運営を行っています。これらの戦略には次のものが含まれます。

高品質の技術文書、チュートリアル、入門ガイドを作成する
製品指向のウェビナー、ライブコーディングセッション、ビデオウォークスルーを実施する
製品アーキテクチャのすべての層の問題を捉える有益なエラーメッセージを設計する

スタートアップは一歩下がって、エンドツーエンドの開発者エクスペリエンスの全体的なビューを構築することを忘れているため、これらの戦略はうまく実行されないことがよくあります。この戦略は、開発者エクスペリエンスデザインと呼ばれることもあります。

開発者エクスペリエンスデザインの重要性

以下の画像は、開発者エクスペリエンスを考慮した設計方法の例です。これは、トランザクションおよびマーケティング電子メール自動化プラットフォームである SendGrid 用に作成されました。

この例は、プロダクトデザイナーの Todd Moy が発行した「Understanding a Path」というタイトルのケーススタディから引用したものです。これは、コンテンツや製品タッチポイントを含む開発プロセスのあらゆる側面をカバーしているため、説得力のある例です。モイは、彼が「デューイ」と呼ぶ開発者ペルソナの歩みを調査し、彼の動機、問題点、ポジティブな瞬間を文書化しようとしました。

この種のジャーニーは製品チームによって作成されることがよくありますが、製品がユーザーインターフェイスを中心にしていない場合、作成はより困難になります。DevRel に大きく依存している開発者第一の企業は、これらのマップの構築と正確な開発者のペルソナの具体化を支援しています。Web3 スタートアップの初期段階にはプロダクトマネージャーがほとんどいないため、Web3 DevRel エキスパートはさらに重要です。彼らは実際にユーザー調査と製品改善の責任者になります。

Web3 スタートアップはどのようにして適切な DevRel 人材を雇用するのでしょうか?

Web3 では、DevRel の専門知識をめぐる競争が熾烈です。TrueUp の 2022 年クリプト求人レポートによると、Web3 では他のテクノロジー業界と比較して、コミュニティおよび開発者関係の役割が 4 倍必要とされています。これは、スタートアップ企業が採用要件を柔軟に調整する必要があることを意味します。

不要不急の要求に対して譲歩する

DevRel のポジションをめぐる競争が激しいことを考えると、スタートアップ企業は Web3 の経験や所在地などの要件に柔軟に対応する必要があります。

対象: ほとんどの Web3 組織がすでに高度に細分化されていることを考慮すると、ほとんどのスタートアップ企業がこの点で譲歩するのは簡単です。ただし、一部の管轄区域やタイムゾーンでは候補者の採用には官僚的なハードルがある可能性があることに留意してください。効果的な調整のためには、十分な重複が必要です。。
これまでの Web3 での職務経験: Web3 の職務記述の多くは、これまでの Web3 での職務経験を強調していますが、候補者が以前の Web2 技術経験がある限り、技術経験は現場で学ぶことができます。さらに、候補者が Web3 の役割に興味がある場合、スマートコントラクト、NFT、分散化などの基本的な Web3 の概念にすでに精通している可能性があります。
多くのスタートアップは、上記の点で譲歩した後でも、DevRel の人材を見つけるのに依然として苦労しています。この場合、スタートアップは、他の関連分野への横断を希望する候補者を見つけることで、ネットワークをさらに拡大することができます。

一貫したスキルを持つ候補者を見つける

以前に DevRel の職に就いた人を雇用することが必ずしも重要であるわけではありません。この職業は非常に若いため、多くの人が隣接する分野から渡ってきます。たとえば、スタートアップは、Discord で技術的な質問に答えられる万能のテクニカルライター、技術的な知識がありドキュメントの書き方を知っているコミュニティマネージャー、または DevRel に参入したいと考えていて技術的なコミュニケーションスキルを持つ開発者を雇用することを検討するかもしれません。。

ほとんどのスタートアップでは、DevRel の初期採用者は通常、オールラウンダーです。機能的なカテゴリー (マーケティング、権利擁護、コミュニティ) において同様に優れている企業はほとんどないことを忘れないでください。したがって、重要なのは、候補者の長所があなたの長所とどのように重なるかを調べることです。

共感が最優先です

候補者の職業的背景に関係なく、DevRel に不可欠なスキルは、他者に共感する能力です。これには、自分自身の内部の偏見と想定されている知識を認識する必要があります。また、対象読者の動機や知識のギャップも理解する必要があります。さまざまなタイプの開発者に共感できるこの能力により、スタートアップ企業はターゲット開発者のニーズに合わせてコミュニケーションや製品戦略を調整することができます。

共感能力の評価に関する注意事項

共感力は技術的適性よりも評価が難しいため、就職面接で見落とされることがあります。企業は候補者のソーシャルスキルをテストするために一般的な質問をしますが、DevRel の使命は、特に開発者の共感を呼ぶことです。

1 つのアプローチは、Web3 の技術コンセプトをさまざまな聴衆に「5 レベル」で説明する方法を受験者に尋ねることです。たとえば、「なぜ Web3 なのか」というタイトルの記事の中で、Chainlink 開発者アンバサダーのパトリック・コリンズ氏は、「信頼を最小限に抑えたプロトコル」の概念を、小指の罵り言葉に似た「破ることのできない約束」という観点から説明しました。彼は、一般の聴衆が信頼の最小化の概念にまだ慣れていないことを理解しており、それを誰もが理解できる概念に分解します。複雑で馴染みのないトピックをより単純でより馴染みのある概念に分解するこの能力は、DevRel プロフェッショナルにとって不可欠なスキルです。

もう 1 つのコツは、ロールプレイングを行うことです。開発者が技術的な課題の解決に取り組み、コミュニティで質問するというシナリオを候補者に与えることができます。候補者は DevRel Advocate の役割を果たし、開発者が最終的に達成したいことを候補者がどれだけ早く見つけられるかを確認します。繰り返しになりますが、重要なのは、特定の技術的問題の細部を超えて、それが発生するより広範な状況を理解することです。

Web3 にさらに多くの DevRel が必要な理由

共感的な DevRel チームがガイドとして機能し、初心者が複雑なテクノロジーエコシステムをナビゲートできるよう支援します。この分野に不慣れな多くの開発者にとって、Web3 は、凝集して相互に接続された業界というよりは、競合するギルドでいっぱいの都市国家のパッチワークのように感じられます。相互運用性が優先されるようになってこの状況は変わりましたが、共通の言語や用語を見つけるのは難しいことがよくあります。同じことが、文字通りの意味ではスマートコントラクト言語の普及にも当てはまり、概念的な意味では競合するコンセンサスメカニズム、プロトコル、ブリッジ、レイヤーなどにも当てはまります。その結果、DevRel のスペシャリストが翻訳者として機能し、外国の技術概念をより馴染みのある用語に翻訳します。これは、エンジニアリングの実践が大きく異なる Web2 から開発者を呼び込むために不可欠です。

DevRel という職業には大きな独自性もあります。それは、二重の忠誠心を持っているということです。一方で、DevRel 実践者は、自分たちが代表するプロジェクトの成功を確実にすることが直接の責任です。一方で、彼らの忠誠心は、業界内のより広範な開発者コミュニティに対してのものです。彼らは、開発者が直接の顧客であるかどうかに関係なく、開発者が成功するのを見たいと考えています。だからこそ、彼らはより一般的な教育コンテンツを公開し、Stack Overflow のような広範な開発者フォーラムで質問に答えようとしているのです。これは、彼らが代表する企業のブランド評判を高めるという相互効果がありますが、これが彼らの中心的な動機ではありません。

最も重要なことは、Web3 インフラストラクチャの新興企業が成功するために DevRel にますます依存するようになるということです。分散型インフラストラクチャソリューションの必要性が高まっていることを起業家が認識しているため、Web3 インフラストラクチャ領域は増加傾向にあります。つまり、競争が激化しているということだ。同様のプロジェクトを手掛けるスタートアップ企業は、競合他社との差別化を図り、開発者間の市場シェアを拡大するために、DevRel の専門家をますます必要とするようになります。このレースで最終的に誰が勝つかに関係なく、より多くの Web3 スタートアップが DevRel を成功の不可欠な部分として採用する場合にのみ、Web3 スペース全体が恩恵を受けることができます。