問い：「開発者コミュニティを構築する仕事は必ず開発者がやるべきですか？」
このような質問は、私は何度も聞いてきました。この質問はすべてのコミュニティグループに現れ、この質問をするのは通常、テクノロジー業界で成功したいが、自分には技術的背景がない人たちです。彼らは自分がテクノロジー業界で生き残れるかどうか確信がありません。
私は1行もコードを書いたことがありませんが、Estimote のコミュニティエバンジェリストになることに成功しました。私たちはモバイル開発者に焦点を当てたスタートアップ企業です。この道を歩んで多くの経験を学び、コミュニティ運営を職業とするすべての人にとって、これらの経験は非常に実用的です。私たちは製品を中心に、より多くの開発者を集め、これらの経験を使用できるだけでなく、一緒に議論、推広し、絶えずより多くの貢献をして、経験をより豊かにすることができます。製品志向のコミュニティは蜂の巣のように、すべての人が共通の目標のために自分の力を貢献しています。ほとんどの場合、私たちの仕事の重点は実際には技術自体ではありません。
私も技術専門出身ではない唯一の例ではなく、SendGrid や Twilio のように開発者コミュニティを構築することで有名な企業でも、コミュニティチームには非開発者出身のメンバーがいます（やあ Tim、やあ Lisa！）。
もう一度この問題を議論しましょう：開発者コミュニティを構築するには、自分が開発者出身でなければならないのでしょうか？
いいえ、でも開発者のように考えることを学ぶ必要があります
コードで考えることができなくても、開発者のように考えることを学ぶべきです。
どんな職業に従事する人も、自分の習慣、用語、世界を見る特別な方法があります。あなたの任務は、開発者が家にいると感じられる場所を作ることです。もちろん、すべての開発者には独自の特性がありますが、開発者に会えば会うほど、彼らの共通点がより多く見つかります。彼らは常に同じことを話しています。例えば、pull request、forked repos、API tokens などです。そうです、これらのことを学ぶ必要があります。言い訳をして逃げないでください。
多くの開発者は効率に非常に執着しています。彼らの頭の中はシステム、パターンの識別、様々な問題の詳細な分析でいっぱいです。
このような記述は少し抽象的すぎますか？その通りです。一定の数量レベル内では、この記述は正確です。しかし、誰かが数文で開発者（またはデザイナー/ジャーナリスト/建設労働者）の考え方を説明できると言ったら、絶対に信じないでください。
開発者の思考パターンを学ぶには、近道はありません。唯一の方法は、開発者と対話することです。
社内の技術チームと一緒に食事し、彼らの会議に参加し、Slack/HipChat チャンネルの新しい動向をフォローし、ユーザーフィードバックを担当する人と議論してください。社外でも学習の機会を求めることができます。例えば、あなたの都市で開催される技術会議に参加し、Stack Overflow であなたのコミュニティに関連するトピックタグをフォローしてください。
一部のトピックは完全に理解できないかもしれません。例えば、「あなたが作成した最も複雑な C 言語コードは何ですか？」など。実際、この質問をあまり深く理解する必要はありません。読む時、他の人が議論する詳細を見て、そこから楽しみを見つけるだけでいいのです。これらの做法は、あなたをより良いコミュニティ運営者および技術エバンジェリストにします。
いいえ、でも製品を理解する必要があります
すべてのコミュニティの核心は人です。しかし、開発者コミュニティの核心は人以外に製品もあります。開発者コミュニティは特別なツールや目的によって開発者を引き付けます。これらのツールを使用する専門家になれなくても、それらを説明する専門家になるべきです。
成功事例を読んで、ベストプラクティスと開発者がどのような状況であなたのツールを使用するかを理解できます。もしあなたの会社がまだこれらの内容を公開していない場合、カスタマーサクセスチーム/ビジネス開発チーム/他のコミュニティ運営者と共有してもらうことができます。また、製品の変遷過程を理解する必要があります。古い投稿を確認し、製品の更新ログを読んでください。
製品とユーザーを理解すれば、関連するケーススタディを提示し、一般的な質問に答え、人々が自分でコンテンツを書いてコミュニティに貢献することを奨励できます。他の人に貢献させることは最も重要な点です。コミュニティメンバーがあなたが彼らを気にかけていると感じると、彼らはあなたのツールのためにガイドを書き、あなたの製品のためにミートアップを企画します。もしあなたの製品がオープンソース製品であれば、彼らはバグの修正を手伝くさえし、彼らはあなたの製品の信者になります。
自分が会社の SDK と API を十分に理解しているかどうかを確認する良い方法の1つは、誰かが製品機能をデプロイする際に問題に遭遇した時、製品説明書のどのページに答えがあるかを伝えられるかどうかです。これは、自分で製品を使用できなくても、製品に精通し、問題の根源がどこにあるかを知っていることを意味します。明らかに、これができれば、運で問題を解決していないことを十分に証明できます。ソフトウェアは常に変化しており、特に誰もがアジャイルと毎日の更新を強調するこの時代です。つまり、以前学んだこともすぐに時代遅れになるため、継続的に学習する必要があります。
Estimote 内部では、2週間に1回の「stack review」活動を設立しました。短い会議を開き、全員が最新の製品リリースを学習したことを確認します。この会議は最大20分しかかかりませんが、全員の足並みをそろえることができます。
ソフトウェア製品の変化速度が速いため、理解できないことや覚えていないことがある時、落ち込まないでください。会社内では、開発者でさえ製品のすべての詳細を完全に理解できず、製品が自分で開発したものであっても、恥じることはありません。ソフトウェア製品はあまりにも複雑で、一人が巨大なコードベースを頭で覚えることは不可能です。問題に遭遇した時、誰に相談すべきかを知っていればいいのです。
もしあなたの会社が Confluence や Asana のようなコラボレーションツールを使用している場合、製品のために技術的詳細説明と FAQ を含むドキュメントを維持するべきです。
会社がコラボレーションツールを使用していない場合、Google Doc を使用できます。注意すべきは、必ず専任者が更新を担当することです。期限切れのドキュメントはドキュメントがないより悪いです。
いいえ、でもチームには開発者が必要です
開発者向けの分野では、どのコミュニティチームにも開発者が1人必要です。当初、私たちのチームにはフルタイムの開発者がいませんでした。このようなモデルはしばらく維持され、世界中の活動で一定の露出を維持し、コンテンツを絶えず改善し、高品質のカスタマーサービスを提供しました。
しかし、すぐにボトルネックに遭遇しました。ハッカソン活動をサポートする能力には限界がありました。技術的なコンテンツを作成する時も力不足を感じました。困難なサポートリクエストは数日間遅れ、チームは shipping 問題を優先し、その後 troubleshooting になり、この部分のサポートリクエストは全リクエストの10%を占めていました。
コードを書ける技術エバンジェリストを見つけた後、チーム全体がより効率的になりました：カスタマーサポート、コンテンツ、活動、フィードバック収集、開発者関係など、私たちはコミュニティの目により積極的で、アクセスしやすくなりました。
チームに専門能力を持つメンバーを配置することで、チームの効率を幾何級数的に向上させることができます。あなたの開発者コミュニティチームを「悪くない」から「すごい」に変えたい場合、チームに開発者出身の技術エバンジェリストを配置する必要があります。
Estimote Community チーム（左から）、Wojtek、Witek（チームリーダー）、Ula（コミュニティマネージャー）、Piotr（技術エバンジェリスト）
いいえ、でも自分でプログラミングを学ぶのも悪くない
皆さんは私が大言壮語を言っていると思うかもしれません。結局、私はコードを書いたことがないと認めました。どう言えばいいでしょうか？私たちはよく他人にアドバイスをしますが、自分ではめったにそうしません。だから、皆さんに学ぶよう勧め、私の轍を踏まないでください。
おそらく、学習しても優れた開発者にはなれないでしょう。しかし、優れた開発者になる必要はありません。
自分で製品を開発する必要もありません。あなたがプログラミングを学ぶのは、開発者コミュニティを構築し、より良く開発者のように考えるためです。最も基本的なプログラミング知識でも、コミュニティとあなたの製品の意図を理解するのに大いに役立ちます。開発者コミュニティに参加するには、これは最も基本的な知識です。
プログラミング以外にも、他のことを学ぶことができます。開発者向けの製品のユーザーは、コードを書く以外にも多くのことをします。もし私と同じように、Xcode と Android Studio の世界に好感を持てない場合、他の分野で学ぶことができます。製品管理の本を読み、UI デザインのコースを受け、UX を学び、この世界には学ぶべきものが無限にあります。Coursera、Udemy、iTunes U、大量のブログがあなたに様々な知恵を提供し、これらはすべてあなたが夢見る学習資料で、それらをうまく使うことを学ぶ必要があります。
最も重要なのは：分野内の知識を学ぶことです。視野を広げ、コミュニティ構築の知識だけに限定せず、他の知識を学ぶことで、開発者コミュニティをより簡単に構築できます。関連分野で知識の蓄積を拡大し、それはあなたがコミュニティメンバーとよりスムーズに対話できるようにします。
例外はありますか？
確かに、当初はかなり豊富な開発者経験があるに違いないと思った開発者コミュニティチームがあります。例えば、Docker や MongoDB のような会社です。彼らの製品は非常に技術的で、彼らに言及すると必ず技術コードを思い浮かべます。Estimote に言及するとマイクロロケーション、Twilio に言及するとテキストメッセージ、Oculus に言及するとビデオゲームを思い浮かべるのと同じです。
しかし、「コミュニティマネジメント」職位の要件を研究した後、これらの職位は応募者に技術的背景を要求していないことがわかりました。おそらくこれは驚くべきことではありません。開発者コミュニティを構築したい場合、ただやればいいのです。Linus Torvalds になる必要はなく、成功できます。
著者：Wojtek Borowicz (Wojtek is the community evangelist at Estimote in Krakow, Poland.)
原文：How to Become An Awesome Developer Evangelist When You’re Not a Developer
転載元：DevRel 開発者関係－非開発者が優れた技術エバンジェリストになる方法
翻訳者：魯行雲
転載をご希望の場合は、出典を明記してください：デベロッパーリレーションズ »
