Web3開発者マーケティングとDevRel：SDKを試しやすく、使い続けやすくする

開発者マーケティングが提供するもの

クイックテスト： チーム外の開発者にクイックスタートを実行してもらいます。時間を計ってください。15分以上かかる場合は、まずドキュメントを修正しましょう。

Web3開発者マーケティングは、技術製品がその価値を説明し、開発者に明確な次のステップを提供するのに役立ちます。DevRelはその関係を中心とした継続的な作業です。教育、サポート、フィードバック、製品を試す機会の提供です。このサービスは、SDKやプロトコルが評価できる状態にあるものの、開発者がどこから始めればよいかまだ迷っている場合に役立ちます。

私たちは、発見から製品の初めての有意義な使用までのジャーニーをマッピングすることから始めます。これにより、ギャップが明らかになります。開発者がプロジェクトを見つけてもユースケースを理解していない、ドキュメントにたどり着いてもセットアップで行き詰まる、チュートリアルを完了しても次にどうすればよいかわからない、といった状況です。計画は、コミュニティ活動自体を目的とするのではなく、各ギャップを実践的な対応に結びつけます。

この作業には以下が含まれる場合があります：

• 製品の開発者オーディエンスとユースケースの概要。
• オンボーディング、ドキュメント、SDK説明のレビュー。
• コミュニティサポート、技術教育、ハッカソンの計画。
• 質問、公開コンテンツ、フォローアップアクションを追跡するシンプルな方法。

より広範なローンチにポジショニングやチャネル連携が必要な場合は、この作業をGo-to-Market戦略と連携できます。マーケティングの優先順位をより広く診断するには、仮想通貨マーケティングコンサルティングをご覧ください。

ドキュメントはどのようにSDKの採用をサポートすべきですか？

ドキュメントがSDKの採用をサポートするのは、開発者が推測することなくユースケース、前提条件、最初のアクションを理解できる場合です。私たちは、新しいユーザーが経験するであろうパスをレビューし、次のステップを見つけやすく、従いやすくするための変更を推奨します。

キックオフ時に、MarketingExtraはチームがすでに持っている資料に対してドキュメントとオンボーディングのレビューを実施します。製品の言葉遣い、クイックスタートの指示、実際の開発者タスクの間の不一致を探します。このレビューでは、不明瞭な用語、不足しているコンテキスト、古い例、または十分なガイダンスなしに読者に判断を求めている箇所を指摘できます。技術チームが実装の詳細を確認します。私たちの役割は、学習パスを一貫性のあるものにし、コンテンツをナビゲートしやすくすることです。

有用なレビューは、「ドキュメントを改善する」という漠然とした要求ではなく、具体的なアクションを生み出します。例えば、初回使用ガイダンスと詳細なリファレンス資料を分離したり、どのSDKの質問に説明記事が必要かを特定したり、ユーザーがどこで助けを求めるべきかを明確にしたりできます。また、公開前に主題専門家によるレビューを受けながら、コンテンツと編集の順序を計画するのを支援することもできます。

現在のドキュメント、SDKの概要、ターゲットとする開発者のユースケース、チームが最もよく聞かれる質問を準備してください。優先事項が一度きりのレビューではなく継続的なサポートである場合は、この作業をローンチ後サポートと組み合わせてください。

ハッカソンはどのような場合に有効ですか？

ハッカソンは、開発者がイベント中に製品を使って意味のあるものを構築でき、チームが彼らの作業をサポートできる場合に適しています。SDK、ドキュメント、またはフォローアップのパスが参加者にとって準備できていない場合、単独の発表としてはあまり有用ではありません。

イベントや形式を選択する前に、以下の質問に答えられるか確認してください：

• 参加者は何を構築、テスト、または学習できるべきですか？
• どの製品資料が必要で、誰が技術的な質問を明確にできますか？
• 提出とレビューのプロセスは何ですか？誰がそれを説明しますか？
• 有用なプロジェクトやフィードバックは、イベント後にどのように次のステップを受け取りますか？

私たちは、開発者チャレンジの定義、サポートコンテンツの準備、コミュニケーションの調整、チームとのフォローアップ計画の整理を支援できます。計画は製品の成熟度に合わせる必要があります。初期のSDKではガイド付きオンボーディングとフィードバックが必要かもしれませんが、より確立された統合パスではより広範なプロジェクト概要をサポートできます。いずれの場合も、参加者には明確な開始点と信頼できる回答を得る方法が必要です。

イベント計画については、プロモーションを開始する前に、技術窓口、レビュー責任、参加基準について社内で合意してください。製品と開発者の目標が本当にその広範な活動をサポートする場合にのみ、イベントをトークンローンチと成長計画に結びつけてください。

6項目のDevRelチェックリスト

イベントを計画する前に、これら6項目を確認してください。これらはSDKを試しやすくします。ハッカソン、講演、投稿では、開発者が最初の試行で諦めてしまった後に修正することはできません。

1. 外部の開発者でクイックスタートを実行する。
2. 1つの動作するサンプルアプリを提供する。
3. リポジトリ、ドキュメント、チェンジログをリンクする。
4. 開発者が質問する場所を指定する。
5. 新しい質問に1日以内に回答する。
6. 明確な成果が得られるイベントを1つ計画する。

用語の一行説明

SDK: ソフトウェア開発キット。開発者が製品で構築するために使用するツールとコード。

DevRel（平たく言えばデベロッパーリレーションズ。開発者が製品で成功するのを支援する作業）。

イベント間で開発者コミュニティを有用に保つものは何ですか？

経験則： 1つの動作するサンプルアプリは、10ページの説明に勝ります。

有用な開発者コミュニティは、人々に製品について質問し、アプローチを比較し、信頼できるガイダンスを見つける場所を提供します。ドキュメントを補完するものであるべきであり、重要なセットアップ情報が存在する唯一の場所になってはいけません。

私たちは、開発者が実際に持ち込む質問（入門、技術的概念の理解、統合のトラブルシューティング、次に何を構築するかの決定）を中心にコミュニティ体験を形成するのを支援します。つまり、チームが回答する質問の種類、技術的な返信の責任者、議論がいつドキュメントの更新につながるべきかを定義します。明確な境界も重要です。コミュニティメンバーは、どの発言が公式の製品ガイダンスであり、どこに問題を報告すべきかを知っている必要があります。

実用的な運用計画には以下が含まれる場合があります：

• コミュニティの目的、オーディエンス、参加ガイドライン。
• 技術的な質問に対する対応とエスカレーションのパス。
• 一般的な開発者のニーズに基づいた定期的なコンテンツリズム。
• 有用なフィードバックを製品チームに伝える方法。

エンジニアが技術的な正確性の責任を保持する間、私たちはコミュニティの活性化と教育プログラムを調整できます。プロジェクトに開発者サポートを超えたより広範なコミュニティ運用が必要な場合は、コミュニティ管理を検討してください。適切な選択は、チームが持続可能で、開発者の進捗を助ける計画であり、単に最も活発に見えるチャネルではありません。

DevRel契約はどのように納品されますか？

DevRel契約は、製品、既存の資料、および当面の開発者目標のレビューから始まります。そのレビューから、チームが何を納品するか、誰が技術コンテンツを承認する必要があるか、進捗状況をどのように報告するかを合意します。

典型的な流れは以下の通りです：

1. 製品概要、現在のSDK資料、最もよく聞かれる開発者の質問を共有します。
2. チームとともにオンボーディング、ドキュメント、既存のコミュニティタッチポイントをレビューします。
3. 製品の準備状況、利用可能な技術サポート、ローンチのタイミングに合った優先事項を選択します。
4. 合意されたコンテンツ、コミュニティ活動、またはハッカソンの準備を作成または調整します。
5. 完了した作業、未解決の質問、推奨されるフォローアップをチームとレビューします。

計画は、焦点を絞ったレビューまたは継続的なサポートのいずれかです。エンジニアがレビューやイベント参加に無制限の時間を割けると想定すべきではありません。スケジュール設定時に承認サイクルを考慮し、技術的な決定は製品を担当する人々に委ねます。更新では、何が完了し、何が入力を待っており、次にどのような決定が必要かが明確になるようにします。

作業が役立っているかどうかを評価するには、チームが観察できる実用的なシグナル（解決された質問、対処されたドキュメントのギャップ、完了したオンボーディングステップ、関連するSDKの会話）を追跡します。レポート形式は、それらの観察を計画に役立てるものにし、活動を採用の主張に変えないようにします。複数のローンチ優先事項にわたる作業については、計画をグロースマーケティングサポートに結びつけてください。

計画に着手する前に確認すべきことは何ですか？

健全なDevRel計画は、製品の準備状況とチームの開発者サポート能力を一致させます。着手する前に、SDKに明確なユースケースがあること、ドキュメントが現在の製品を反映していること、技術担当者が公開ガイダンスをレビューできることを確認してください。また、エンジニアリングのインプットが必要な質問を誰が処理するか、ハッカソンやコミュニティでの議論の後に何が有用なフォローアップとみなされるかについても合意してください。

イベント主催者は独自のルール、スケジュール、選考決定を設定し、開発者はイベント後に統合を続けるかどうかを自分で決定します。私たちは合意されたドキュメント、サポート、イベント作業を納品できますが、サードパーティのイベントへの参加承認や結果としてのSDK統合を約束することはできません。

3つのものを送ってください：ドキュメントのリンク、SDKリポジトリ、リーチしたい開発者グループ。これらをもとに、最初の一見から最初のコールまでの道筋をレビューし、作業開始前に費用を書面で確定します。

仕組み

1. 製品コンテキストを共有する製品概要、SDK資料、開発者オーディエンス、現在の優先事項を送ってください。チームが繰り返し聞かれる質問を含めてください。
2. 開発者ジャーニーをレビューするドキュメントとサポートタッチポイントを通じたパスを評価し、明確な次のアクションを妨げるギャップを特定します。
3. 計画と担当者に合意する製品の準備状況に合った作業を選択し、レビュー責任を設定し、どの技術的判断がチームに残るかを確認します。
4. 合意された作業を納品するドキュメント、コミュニティサポート、またはハッカソンの準備を調整し、未解決のリクエストを関連する担当者に可視化します。
5. レビューとフォローアップの計画完了した作業、未解決の質問、開発者オンボーディングのための推奨される次のアクションの簡潔な説明を受け取ります。