この記事は、2022 年 9 月 24 日に DX Tips: The DevTools Magazine へ投稿された「DevRel as a Service Unbundling The Full Stack DevRel, and building Infrastructure for scaling Developer Relations beyond "the DevRel team"」の日本語訳です。
今回投稿者の swyx（@swyx）さんに翻訳の許可をいただきました。ご快諾いただきありがとうございます。
この素晴らしい記事を少しでも多くの人に届けたいと思い、 Qiita に投稿します。
DevRel as a Service - フルスタックな DevRel を切り離し、「DevRel チーム」を超えて DevRel をスケールするためのインフラを構築する -
DevRel についてのお気に入りのジョークの 1 つに、DevRel の第一戒があります。それは DevRel の仕事に就いたらすぐに、振り返って「DevRel への入り方」という自己満足なブログやポッドキャスト、 Twitter Space を作成しなければならないというものです。もちろん誰しも DevRel にはなりたいですよね？2030 年までにはエンジニアはいなくなり、技術者は 19 ドルの電子書籍や 10 ドルの Substack1、4.99 ドルのスーパーフォロー2をお互いにする DevRel だけとなり、万国で基本的な DevRel が普及しているでしょう。
DevRel には限界がある
もっと真剣な話をすると、私は以前のマネージャーのあるエピソードで DevRel には限界があることに気づきました。その人は「ねえ、あなたは既に会社の 10%だ！今持っているものでもっとやれ！」と言われ、これ以上人数を増やせませんでした。
これはとても良い指摘です。エンジニアリングマネージャー1 人に対してエンジニアが 5~8 人、並列でプロダクトマネジメント、プロダクトマーケティング、プロダクトデザイン（さらに凝ったことをするのであれば、プロダクトアナリティクス）を様々な割合で配置するという、今では一般的になっている知恵と同じような、DevRel チームの最適なサイズの割合がおそらく存在します。
CommonRoomの DevRel の報酬に関するレポートは、DevRel チームのサイズに関して驚くほど広範囲に分散してることを指摘しています。
しかし私の以前のマネージャーの指摘はもっともで、ある地点で、DevRel は成長を止める必要があります。
補足：実際、将来利益率を向上させたければ、社内のエンジニアと顧客の数に比例してスケールしたDevRelの数が欲しくなるでしょう。
これとは対照的に、DevRel の限界生産性はチームが成長するにつれて劇的に減少するという経験則があります。1 人目はたくさんのことをします。10 人目は 9 人目が行ったこととほぼ同じことをする傾向にあります。50 人目はその一年何をしていたかほぼわからなくなります。つまり、DevRel の平均的な生産性（しかしその測定については、別の機会に取り上げます。）はチームが大きくなるほど低下する傾向にあり、まさに生産性を上げる必要があるときに（人数を直線的にスケールするために）低下します。
では、どのようにDevRelをスケールするのでしょうか？
注：この質問は本記事に収まりきらないほど長い回答になる修辞的な質問です。他のより多くの次元については、シングルトン・プログラムから言語/地域/垂直分割プログラムへの移行に関するInfraEngでの私の議論を確認してください。
オーナーシップとイネーブルメント
私が好んで持ち出す一例として、GitHub や Snowflake、Stripe は最初の数年、DevRel を雇用していなかったというものがあります。彼らはうまくやれていましたね。もちろん、Twilio やPlaidのように創設者が良い DevRel やエヴァンジャリズムのプログラムを確立したことが成功に繋がったという例もあります。しかしそうではないところでは、基本的に DevRel はみんなの仕事でした。Stripe は、パトリックとジョンが見込み客のオフィスに出向いて統合作業を行い、全ての反対意見を排除してフィードバックを得るという、Collison Installationで有名でした。TPW やクリス・ワンストラスが初期の GitHub を盛り上げるために、多くの Ruby ミートアップで講演をするなどといった具合です。
DevRel をスケールするためには、DevRel はオーナーシップの役割（責任はここにあり、DevRel に関することは全て私たちが行う）からイネーブルメントの役割（私たちは他のみんなが DevRel に関することをできるようにする！）へ変わるべきです。この二律背反について去年から書き始めています。
これは人事のような他の「イネーブルメント」の役割を考えるまでは、責任範囲を縮小しているように見えます。人事部は個々のチームの採用を実際に行なっているわけではないことを考慮しましょう。その代わりにほとんどの企業では個々のラインマネージャーが採用責任者となり、基本的に最終決定権を握っています。人事部は採用を自ら行う代わりに、採用を行うマネージャーが彼らの仕事の一部として採用業務を行えるように、ATS ソフトウェアの購入、福利厚生の決定、候補者の発掘、入社手続きなど、可能な限りのインフラを構築しています。
つまり DevRel をスケールするために、私たちは「DevRel インフラ」について明らかにし、「サービス」として社内の他のメンバーや潜在的にはコミュニティの支持者に提供する必要があります。
フルスタックな DevRel を切り離す
古典的な「私のだけ」の 1 人目の DevRel の雇用（私たちの以前の考えはこちら）は、「フルスタック」になりがちです。彼らは、執筆、講演、ワークショップ、コーディング、インタビュー、編集、企画など全てのことをやります。これは 8 人以上までのチームでこのような設定になる傾向があります。各 DevRel はほぼ自律的な一匹狼となり、特定のユーザーペルソナやコミュニティと親和性が高く、社内のコンテンツチャンネルや成果物に強いという傾向があります。しかし通常は、プロジェクトをアイディア出しから制作、出版、シンジケーションまで最初から最後まで一貫して行います。優秀な DevRel であれば、YouTube 動画の編集から社内会議の運営、フェローキッズのためのジョークに溢れたソーシャルメディアミームの作成まで、あらゆるスキルを多様に使いこなすことが期待されています。
しかしもちろん、メディアや専門教育機関はこのように運営されていません。企業が本当に、社内でメディア企業を構築していると認識することで、専門的な役割が生まれ始めます。
これについて考えるための最も簡単な方法は、私が過去に経験した銀行のトレーディングのフロアでの分業に例えることです。フロントオフィス、ミドルオフィス、バックオフィスなど（私の本の読者には馴染み深いでしょう）。
- フロントオフィス：トレードについて考えることやお金を稼ぐことに責任を持つ
- ミドルオフィス：リスク評価やコンプライアンスの保証に責任を持つ
- バックオフィス：経理などその他の事務作業に責任を持つ
フロントオフィスは華やかで給料も高く、後ろに行くほど地位が下がるというのが、通常の力学です。しかし物事がうまくいかないとき、つまり過ちを犯したり、制限を破ったときには力が反転し、バックオフィスやミドルオフィスはフロントオフィスに過ちの責任を負わせることができます。
この 3 階層のアーキテクチャを DevRel の責任に当てはめることができます。
- フロントオフィス：コンテンツのアイディアを作成し、会社の公の顔になるデベロッパーアドボケイト
- ミドルオフィス：声のトーンのチェック、動画編集、パートナーシップ/用語/ビジネス戦略に関する懸念の解決、コンテンツの混合やカレンダー、レイアウトの決定、ブランド資産を提供する編集者
- バックオフィス：スケジュールの発表、動画の文字起こし、インタビューの日程調整、契約者の支払いなどを支援するオペレーションのスペシャリスト
選択したメディアやユースケースによって細かい部分は異なるでしょうが、このように DevRel の「フルスタック」を分割すると、「フロントオフィス」は「デベロッパーアドボケイト」という職種の人以外にも拡大できることがわかります。もしあなたがDevRelインフラを構築すれば、「DevRel as a Service」を社内の他の社員や、コミュニティの熱心なボランディアにも簡単に提供できます。
DevRel インフラの要素
これは不完全な一覧ですが、ここには私が過去にメンテナンスしてきた DevRel インフラの項目がいくつかあります。
-
発表スライド例のディレクトリ
- いつ、何のために発表されたかを示すメタデータ付き
- 社員同士の「持ち寄り」だけではなく、ユーザーが「上司を説得」したり、ミートアップで自社についてのプレゼンテーションをするときに利用できる
- 目的は、他の人が簡単に自分をよく見せることができるようにすること
-
フォーカスすべき一覧：外部との接点を持つことができる機会の再利用可能な一覧
- 今後登壇したいカンファレンスの一覧：エンジニアの登壇を支援するオフィスアワーや登壇準備の提供と一緒に
- 業界のニュースレターやポッドキャストの出演一覧
- 購読者、読者、聴衆となり、ホストとの関係だけではなく、視聴者に何が有効かを感じ取ること
- 少なくとも年に 1 回取り上げてもらうことを目標に、何かいいことがあったら声をかけてみましょう
- この一覧を公開することで確信が持てれば、とてもうまくいく
- 以下と重複している部分が多いが、人や長期間の関係性よりもチャンネルや特定のコンテンツのアウトプットに焦点を当てたもの
-
業界のインフルエンサーの一覧とその企業との関係性
- 誰も認めたがらないが、どの業界にもインフルエンサーが存在し、彼らとの関係性を慎重かつ積極的に管理すべき
- 人々の話題のモニタリングだけではなく、主要プロダクトの発表やイベントの招待などの活動にも役に立つ
- このドキュメントはとても機密性が高く、省略や委託の罪は高く就くため、DevRel や会社のリーダー以外には全てを広めるべきではない
-
Slackの#ecosystem-news チャンネル
- これは私が勤めていた直近 3 社では典型になってきている。DevRel はプロダクトやエンジニアリング/デザインがトンネル状のビジョンを持っているかもしれない業界の他の部分で起こっていることに驚くほどよく同調する。DevRel はたとえ競合他社に反応することで会社のロードマップが決定されるべきではないとしても、市場からのニュースやフィードバックを裏道としてとても有益な機能を果たしている。
-
動画やスライドのテンプレートやアセット、編集
- 上記で言及したように、Figma で１日中遊んでいる人ではなくても、会社のブランドと一貫性があり、高品質に見えるリッチなメディアのコンテンツを他の社員が簡単に作成できるよう、このプロセスを把握しドキュメント化すること
この「インフラ」の一覧に他に何を加えるのが適切でしょうか？
翻訳後記
iOS エンジニアとして活動している kamimi（@kamimi_01）と言います。☺️
会社のテックブログ運営に関わっている関係で DevRel に興味を持ち、DevRel Meetup in Tokyoで始まった記事の翻訳活動に参加しています。
本記事は私にとって 2 つ目の翻訳記事でした。（前回翻訳した記事は「【日本語訳】デベロッパーアドボケイトになるための秘訣（The Subtle Art of Being A Developer Advocate）」）前回の記事では DevRel やデベロッパーアドボケイトとの役割について内容だったのですが、今回はその役割をどのように企業でスケールしていくかという内容で DevRel as a Service という記事タイトルもとても面白いと思い、翻訳してみました。
この翻訳記事が DevRel、デベロッパーアドボケイトに興味がある方々の参考になれば幸いです。🥑