この記事は、2022年8月10日にanother random community newsletter :)へ投稿された「How Can DevRel Enable Engineering?」の日本語訳です。
今回投稿者のAditya Oberai（@adityaoberai1）さんに許可をいただきましたので、Qiita に投稿します。
DevRelはどのようにエンジニアリングを実現するのか？
私がDevRelの専門家として11ヶ月間活動する中で、１つのよくある誤解に気づきました。
それは、DevRelチームとEngineeringチームは協力していないと信じている人が非常に多いということです。
私の仕事の性質上、定期的にEngineeringチームと協力していることもあり、その誤解についてはフラストレーションを感じていました。
しかし時が経つにつれて、この誤解は多くの人が目にしているDevRelの氷山の一角に、コラボレーションの部分があまり見えていないために生じているのだと気づきました。
そこで、DevRelチームが製品の背後にあるエンジニアリング作業にどのように貢献しているかを私の経験をもとに共有します。
DevRelとEngineeringはオーバーラップできるのか？🤔
前回は、「DevRelというキャリアを選ぶべきか否か」というテーマで、DevRel領域ではどのようなスキルや経験が従事者に求められているのかについても取り上げました。
DevRelの3つのCのうち、コードとコンテンツ（特にテクニカルライティング）は、エンジニアリングと直接的に関連するスキルです。
結局のところ、EngineeringチームとDevRelチームの両チームは、製品の成功を保証するために存在します。
エンジニアは製品を作り、DevRel従事者は製品の利用をユーザーに促し、彼らとの関係性を構築することを可能にします。
もしこの2つのチームが一緒に機能しなければ、開発者コミュニティがアクセスできない製品や、開発するのに適していない製品を作ることになります（例外はありますが、あまり多くはありません）。
製品を成功させるためには、DevRelチームとEngineeringチームが相互依存関係を持って機能し、協力し合うことが必要です。
どんな場面でDevRelはエンジニアリングワークを支援するのか? 🤝
DevRelとEngineeringの責務が重なる部分はいくつかあります。
- ソフトウェア開発
The “Developer” in “Developer Relations“ is not for naught!
(“Developer Relations“の“Developer”は無意味ではない！)
DevRelチームは専任のソフトウェアエンジニアではないかもしれませんが、コードを書かないということではありません。DevRelチームは、製品のエコシステムを拡張するために新しい統合機能をビルドしているのをよく見かけます。私は、Appwriteのコア製品の一部であるAuth0 OAuth2 adapterと Vonage phone authentication adapterの統合部分を作成しました。
DevRelチームはまた、それらのプロダクトを使い始める際の摩擦を減らすために、より新しいサンプルアプリケーションを積極的にビルドしています。
また、ワークフローを改善し、生産性を高めるために、組織内のツールの開発およびアップグレードを支援することもあります。
- ドキュメンテーションの作成
If the product’s not easy to understand, it’s not easy to use!
(製品が理解しにくければ、使いやすいとは言えない！)
ドキュメントを読むことは、開発者が製品やサービスを自分のソリューションに統合する方法を学ぶための最良の方法の一つです。もしドキュメントが不完全であったり不明瞭であったりすると、開発者の摩擦を増大させるだけで、その製品を使うことから完全に遠ざかってしまうかもしれません。
AppwriteがJava、Kotlin、.NET、C++用の新しいCloud Functions runtimesをリリースしたとき、私はFunctionsガイドにそれらのサンプルを追加し、人々が同じものを作り始めるのを簡単にできるようにしました。
DevRelの責任の大部分は、技術的なコンテンツです。これは、ドキュメント作成にも当てはまります。なぜなら、DevRelの従事者は、コミュニティと向き合っているため、彼らのペインポイントをよりよく理解できることが多いからです。
- ソフトウェアテストとフィードバック
If we can’t eat our own dog food, how can we ship it out?
(ユーザーに提供するサービスを提供者が使ってなければ、どうやって出荷すると言うんだい？)
DevRelに所属する上で欠かせないのは、私たちが支持する製品を身近に知ることです。DevRelチームは、しばしばサンプルアプリケーションやソリューションの構築に取り組み、製品の開発者エクスペリエンスに関する利用者の観点に近づきます。
以前のAppwriteのバージョンリリース時、私はAppwrite CLIのQAを手伝いました。そこで最終的に一般に公開される前に問題を発見し、修正することができました。
このような理由から、DevRelチームはしばしば製品のユーザー0として、誰よりも早く製品を使って構築する実地経験を得ることができます。
これにより、ユーザーの視点を体験できるだけでなく、リリース前にバグや問題を発見し、そのフィードバックをEngineeringチームと事前に共有することができるのです。
- テクニカルサポート
If you’re facing trouble building, we’re here to help you out!
(トラブルに直面したときは、私たちが支援するよ！)
DevRel従事者は、コミュニティの最前線で活躍することが多くなっています。DevRel従事者は、優れたコミュニケーターであるだけでなく、必要な時にコミュニティのメンバーを助けられるよう、ある程度の技術的な能力を持っていなければならないので、これは大変な責任なのです。私は、TwitterやRedditなどの各種ソーシャルメディアや、自社のDiscordサーバーで、Appwrite関連の問い合わせを積極的に解決するお手伝いをしています。新しい技術を取り入れようとする人にとって、入りやすい入り口やサポート体制は大きな違いですが、DevRelの実務担当者はそれを実現しています。
最後に🤝
開発者にフォーカスした製品の開発と成長には、DevRelチームとエンジニアリングチームが不可欠です。開発者フレンドリーであることと、開発者のニーズに応えることは、補完的ではありますが、別々の責任です。両チームが協力し合えば、この2つの責任を簡単に達成できるエコシステムを作ることができるのです
個人的には、DevRelのプロフェッショナルとして約1年を過ごし、この仕事と、この仕事によって同僚や仲間、そしてそれ以上の人たちに与える影響を心から愛するようになりました。近い将来、皆さんの周りでも、DevRelの役割によって開発者の卵たちに魔法をかけることができるようになればと願っています。
翻訳後記
今回翻訳を担当した中西(@nana_nigiiro)と申します。
DevRelに関わってまだ一年も経っていませんが、こういった価値ある記事の翻訳のお手伝いができたことを嬉しく思います。
今後DevRelの活動が日本でもより広がっていくことを願っています。
最後に翻訳を快く快諾してくださった投稿者のAditya Oberaiさん、その仲介をしてくださったMOONGIFTの中津川さん(@goofmint)、読んでくださった皆さん本当にありがとうございました。