※ この記事は、2022 年 9 月 1 日に投稿された Internal Developer Advocacy: What Should You Do Next?の日本語訳です。今回、投稿者の Daniel Bryant さんに翻訳の許可をいただきました。ご快諾いただきありがとうございます。この素晴らしい記事を少しでも多くの人に届けたいと思い、 Qiita に投稿します。

開発者支援、または開発者リレーションズ（DevRel）

開発者支援、または開発者リレーションズ（DevRel）は、よく知られた需要の高い分野です。この分野では、技術やソフトウェア開発の世界の最新動向を常に把握しながら、講演、指導、助言、聞き取りなど、さまざまな役割を果たすことが求められます。
技術業界では、デベロッパーリレーションズの影響力と重要性を否定する人はいません。テクノロジーとユーザー導入のギャップを埋め、ソフトウェアエンジニアリングの実践を進め、開発者コミュニティの声を組織にフィードバックして製品やイノベーションを前進させるためには、開発者リレーションが欠かせません。
従来のデベロッパーリレーションズは、何よりもまず、インサイドアウト型のアドボカシー（擁護）です。しかし、開発者の体験に焦点を当てた開発者リレーションシップのアウトサイドイン・アプローチとして、インターナル・デベロッパー・アドボカシー（内部開発者支援）が注目されています。
外部開発者支援と内部開発者支援には重複がありますが、内部開発者支援は、内部で開発者の体験を形成し、組織での成功を支援し、組織の目標を達成するために開発者をサポートするものです。

なぜ DevRel を社内向けに行うのか？

社内の開発チームを支援することを主な目的とする社内開発者リレーションは、単なる一時的なトレンドではありません。開発者支援に長く携わってきた者として、私は社内の開発者の役割が急増しているという話を耳にし、開発者支援チームや開発者体験チームなど、こうした役割に従事する人たちに会う機会も増えています。
社内開発者支援の人気が急上昇していることは、開発者の体験を正式にサポートする必要性と、開発者が働く空間が特にクラウド・ネイティブ・テクノロジーによって複雑化していることを認識していることの両方を浮き彫りにしています。
社内開発者支援という新しい分野を簡単に分析した結果、非公式と正式な開発者支援、社内 DevRel 機能の必要性を生み出した状況、社内開発者支援を成功させる方法について、いくつかの結論が得られました。
組織の成熟度と文化は、社内開発者支援機能が開発チームの中でどのように位置づけられるか（もし位置づけられるのであれば）に影響を与えます。

非公式な内部開発者の支持、技術、ツール、そして舗装された道

中には、最初から開発者にソフトウェアライフサイクルの全責任を負わせるという考えで作られた組織もあります。デンマークに拠点を置く Lunar Bank は、そのような企業の1つです。特に、開発者のオンボーディングとセルフサービスのための「舗装された道」、つまり開発者用のプラットフォームとワークフローを作成することで、先陣を切って開発者体験に多大な投資を行ってきました。
Lunar Bank は、開発者の自由と責任のための条件、トレーニング、ツール、サポートを重視しており、これは非公式な開発者支援の一例と言えます。社内開発者プラットフォームは、開発者の体験を一元化し、開発者のオンボーディングを加速させ、生産性を向上させています。
開発者プラットフォームは、Zipcar の非公式な開発者支援と同じタイプのものです。プラットフォームチームは、開発者のペースを落とすことなく、必要なツールや依存関係を理解し、生産へのシームレスなパスを提供するために働きます。プラットフォームチームは、代理人として開発者の支持者になります。
もし組織が開発者に運用責任を求めるなら、プラットフォーム・チームはセルフサービス・ツールとオンランプを提供すべきです。
もし組織が開発者に何らかのレベルの運用責任を求めるなら、プラットフォームチームはセルフサービスツールやオンランプを提供して、開発者が仕事をするために本当に知る必要のない事柄を軽減する必要があります。このような「軽減すべき領域」の一例が、設定です。
開発者はこの点についてすべてを知る必要はなく、社内の開発者用プラットフォームが基礎となるインフラを扱うべきでしょう。プラットフォームとプラットフォームエンジニアリングは、一貫性があり、安全で、高速なソフトウェアの提供を可能にすることで、開発者の経験をサポートし、開発者を「支持」するのです。

正式な内部開発者の支持コミュニティとコミュニケーション

公式の開発者アドボカシーは、社内の開発チームに対応するために特別に設計された役割を持つ個人またはチームに頻繁に集中する一方で、コミュニティにも焦点を当てています。開発者同士を結びつけ、知識と経験を共有し、コラボレーションを促進します。
正式な開発者支援は、社内の開発チームを支援するために特別に設計された個人やチームを中心に行われることが多いのですが、コミュニティにも重点を置いています。開発者同士を結びつけ、知識や経験を共有し、コラボレーションを促進するのです。

コミュニティの価値

クラウドネイティブコミュニティは活発で活気に満ちていますが、同時に複雑でもあります。クラウドネイティブテクノロジーを理解し、前進させるためのコミュニティを構築するには理想的な場です。コミュニティとその参加者は、ベストプラクティス、ツール、プロセスに関するコンセンサスを生み出し、学習と共有の機会を作り、専門家と実務家のネットワーク構築を支援することで、価値を提供します。
コミュニティは、アウトリーチベースで、多くの場合、外部に向けた取り組みです。しかし、コミュニティの指針、ベストプラクティス、知恵が開発者の組織に導入され採用されることで、コミュニティのプラクティスや標準が社内に浸透するため、開発者の内部擁護のための重要なフォーラムでもあるのです。
また、コミュニティは、より正式な「実践コミュニティ」の源でもあります。これは、非公式なグループにおいてソフトウェアエンジニアリングの技術を継続的に向上させることを目的としたグループです。これらのコミュニティは、専門知識を提供し、コミュニティ内での知識の喪失を防ぐだけでなく、開発者が学んだことを社内のチームに持ち帰り、機能横断的な関係を促進し、サイロをなくすことで、知識の共有をコミュニティの外にまで広げています。

双方向コミュニケーションの威力

教育やトレーニングは、オンボーディングと継続的な開発者体験の形成に不可欠ですが、開発作業の「方法」を促進するための入り口でもあります。優れた開発者文化を創造するには、コミュニケーションに依存します。コミュニケーションは、優れたストーリーテリングと、さまざまな取り組みの背後にある「なぜ」を説明することに依存します。
Veterans United Home Loans 社の Alan Barr 氏は、この言葉を最もよく使用しています。「コミュニケーションは、本当に重要な活動です。コミュニケーションは、本当に活用度の高い活動です」。
双方向のコミュニケーションには、聞くことも必要です。開発者のためのプラットフォームやツールを構築することはできますが、まず、ツールを構築する前に、開発者の声に耳を傾け、彼らのニーズを理解する必要があります。そして、ツールを開発した後は、開発者とコミュニケーションをとることが同様に重要です。
社内の開発者支援者や社内の開発者体験チームは、内向きのコミュニケーション活動を迅速に行い、社内のフィードバックループを高速化すると同時に、開発者の生活を楽にするための道を切り開くのに貢献します。
また、開発者の労力と認知的負荷を軽減し、全体的な開発者エクスペリエンス（開発者コントロールプレーンなど、それをサポートするツール）を、挑戦ではなく、喜びに変えることができます。社内の開発者支援により、開発者エクスペリエンスの向上までの時間が短縮されます。

内部開発者支援の事例

組織は、非公式または公式に、開発チームに内部開発者の支持を加えることで価値を得ることができます。それは、開発者の声を高めることです。クラウドの著名人である Kelsey Hightower 氏が最近の DockerCon で説明したように、「10倍の開発者が欲しいわけではない...欲しいのは、他の10人の開発者の生産性を高めることができる人」なのである。
開発者の声を高めることの核心は、"他の開発者のリソースとなる開発者を支持する "という考えです。社内で、すべてのピースがどのように組み合わされているかを理解し、他の開発者のために熱心に主張し、中心的な概念を把握する手助けをしてくれる開発者を見極めましょう。社内の開発者の支援者に投資することは、大きな利益をもたらします。

"他の開発者のリソースとなる開発者の支持者"

組織によって、この社内開発者の支持者に投資する方法は非常に異なっています。Snyk 社のエンジニアリングディレクターである Crystal Hirschorn 氏は、ある開発者が非公式の社内開発者支援者になった例について説明しました。
この開発者はインフラストラクチャのバックグラウンドを持っていたため、Snyk のプレイブックに従って、必要なものを開発したのですが、それは存在しなかったのです。彼は、開発者の自由を推進する模範となり、さらに一歩踏み込んで仕事をしました。彼は、毎月のR&Dディスカッションでチームを擁護し、インフラストラクチャとチームの相互作用なしに必要なものを得るためのセルフサービスアプローチを説明しました。
また、別の組織である cinch 社は、会社の拡大に伴い、「開発者コーチング」アプローチをスケールアップする方法を見つける必要がありました。そのアプローチは、知識を体系化し共有する（そしてワークフローを自動化する）一方で、開発者だけでなく、インフラ、CI/CD、観測可能性、モニタリングなどの全体像に焦点を当てた社内開発者支援者を各チームに加えるというものでした。このアプローチにより、チームはソフトウェアをより速く、より良く構築できるようになり、多くのコーチや社内開発者の支持者を持つという考え方が導入されました。

結論：内部開発者支援による投資対効果

内部開発者支援は、開発者リレーションというよく知られた外向きの規律を、開発者の経験を形成し、開発者の成功を支援し、組織の目標達成に貢献するために内向きにするものです。
開発者が開発者向けプラットフォームを採用し、より多くのコラボレーション、コミュニケーション、コミュニティを活用することで、より速く、安全にソフトウェアを出荷できるようになれば、社内開発者支援活動の価値は明らかになります。社内の開発者支援は、効率的かつ効果的な開発者体験を利用して、ビジネスに焦点を当てた賭けを安全に配置する能力を組織に与えるツールの一つです。

Daniel について

Daniel は、Ambassador Labs (旧 Datawire) の DevRel 担当ディレクターです。Daniel は Java チャンピオンであり、TechBeacon DevOps 100 インフルエンサーです。彼は、いくつかのオープンソースプロジェクトに貢献しています。
https://thenewstack.io/author/daniel-bryant/
https://thenewstack.io/internal-developer-advocacy-what-should-you-do-next/