> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # Developer Relationsの役割 > 企業が開発者と築く関係を担う取り組みとしてDevRelを定義し、エンジニア文化を学習・共有・改善という価値観として、エンジニアコミュニティを三層構造として整理し、発信が果たす役割を解説します。 ## 概要 DevRel（Developer Relations）は、企業が開発者との関係づくりのために行う取り組みです。この取り組みが何の上に成り立つのかを理解するには、ソフトウェアエンジニアのあいだで共有された文化、すなわち学習・共有・改善という価値観と、それを外から見える形にする発信の働きを知る必要があります。 このページが対象とするのは、ソフトウェアエンジニアの文化です。まずDevRelを定義し、そのうえでエンジニア文化、エンジニアコミュニティの三層構造、発信が果たす役割を順に整理します。 ## DevRelとは何か ### 一般的な定義 DevRel（Developer Relations）とは、企業が開発者とのあいだに築く関係そのものと、その関係づくりを担う取り組みを指します。一般的なマーケティングや広報と異なるのは、相手が開発者である点です。プロダクトの利用者として、コミュニティの参加者として、あるいは将来の同僚としての開発者が相手になります。 ### 2つの方向性 | 方向性 | プロダクトの利用者 | この取り組みが目指すもの | | -------- | ----------------------------------- | ---------------------------------------- | | プロダクト型 | API・SDK・開発者向けのツール・インフラ・部品など、利用者が開発者 | 導入と継続利用。ドキュメント、サンプル、サポート、利用者の声のプロダクトへの還元 | | ブランディング型 | 利用者が開発者とは限らない | 技術組織の認知と信頼。発信、イベントの主催、社員の登壇支援 | 多くの企業は2つの方向性を同時に持ち、その比重は事業の変化とともに移ります。個々の活動がどちらに寄与するものかを明示しておくと、誤った尺度で評価されずに済みます。 ### 関わり方の例 | 関わり方 | 必要になるもの | | ------------------ | ------------------------ | | 自社イベントの主催 | 継続的な企画の体制と、参加者にとっての参加理由 | | コミュニティイベントへのスポンサード | 資金または会場。内容への条件をつけずに提供する | | 技術メディアの運営 | 書き手の継続的な供給と、編集のプロセス | | 社員の登壇支援 | 時間、レビュー、開示してよい範囲の方針 | | オープンソースへの貢献 | 一度きりの寄付ではなく、継続的なエンジニアの時間 | ### 原則 参加者が何のために来たかを基準に活動を設計します。宣伝が主目的になった内容は、届けたかった相手を失います。 言語・ツール・職種に優劣をつけません。比較は、それぞれがどんな条件で適するかを述べる形にします。 関係は繰り返しの接点によって築かれます。一度だけ全力で実施するのではなく、続けられる規模に調整します。 効果を部分的にしか帰属させられないことを受け入れます。個々の活動に直接の見返りを割り当てるのではなく、参加者数・再参加率・到達範囲を時系列で追います。 これらの原則は、実務では互いを制約します。継続性は個々の活動の規模を制限し、中立性は活動が自社の短期的な利益に直接寄与できる度合いを制限します。このトレードオフを活動ごとに判断するのではなくあらかじめ決めておくと、この取り組みの成果は長期にわたって一貫します。 ## エンジニア文化とは何か ### 価値観 エンジニア文化とは、特定の雇用主にも特定の技術分野にも依存せず、エンジニアのあいだで共有されている価値観です。企業ごとの社内ルールや制度、働き方は組織文化であり、会社によって異なります。エンジニア文化は、誰に雇われているかにかかわらず、コミュニティ・共同のプロジェクト・公開された文章のいずれにも繰り返し現れるものを指します。 観察される内容の大部分は、次の3つの価値観で説明できます。 | 価値観 | 意味 | 実践に現れる形 | | --- | ------------------------ | --------------------------------- | | 学習 | 現在の知識を暫定的なものとして扱い、更新し続ける | ソースコードや設計書を読む、未知のツールを試す、設計の理由を調べる | | 共有 | 知識をそれを持つ人の外に動かす | ドキュメント、相互レビュー、記事、登壇、オープンソース | | 改善 | 動いているシステムをまだ良くできるものとして扱う | ずれた構造の作り直し、振り返り、繰り返し作業の自動化 | ### なぜこの価値観が成り立つのか これらは、たまたま多くの人が好んでいる嗜好ではありません。エンジニアリングという仕事が持つ3つの性質が、これらを実務上の必然にしています。 **技術的な知識は変わり続けます。** 道具やフレームワークは数年単位で入れ替わり、クラウドやAIのように新しく習得が必要な領域も加わり続けます。学習は、この分野で働き続けるための条件であり、任意の美徳ではありません。 **知識は複製しても減りません。** 解決策を説明しても、説明した側からその知識が失われることはありません。共有のコストが低く双方に利益があるため、ノウハウが本質的に希少な分野よりも共有が広がりやすくなります。 **作ったものは完成しません。** 使われ続けるソフトウェアは要件・環境・負荷の変化を受け続けるため、「動いている」は完了ではなく状態を指します。改善は、その状態を維持するための活動です。 この3つが同時に現れる最も明確な例がオープンソースです。コードが公開され、誰でも読んで学ぶことができ、改善を同じコードベースへ還元できます。 ## エンジニアコミュニティの構造 ### 三層構造 エンジニアコミュニティは、主体も動機も異なる3つの層から成り立っています。これらを一体のものとして扱うことが、企業が関わり始めるときによくある失敗の原因です。 | 層 | 主体 | 主な動機 | 発信の典型的な形 | | ------ | ------------- | ------------------------- | ----------------------------------- | | 個人 | 一人のエンジニア | 自分の理解を整理し、その記録を公開の形で積み上げる | 記事、登壇、オープンソースへの貢献、質問への回答 | | コミュニティ | 有志の運営者と参加者 | 関心を共有する人が学べる場を存続させる | 勉強会、ミートアップ、テックカンファレンス、オープンソースプロジェクト | | 企業 | 事業とそこで働くエンジニア | プロダクトの導入、技術ブランディング、採用活動 | 自社主催イベント、技術メディア、スポンサード、社員の登壇支援 | ### 層どうしの関係 個人は3つの層を横断して動きます。同じ人が個人の記事を書き、ミートアップの運営を手伝い、勤務先が主催するイベントで登壇します。層をまたぐのが同一の人物であるため、ある層での扱われ方が他の層での信頼に影響します。 コミュニティは有志の労力で運営され、中立性を前提に成り立っています。運営者は基本的に利益を得ず、参加者は自分の意思で参加し、その場は「営業の場として使われていない」と信じられているあいだだけ維持されます。この信頼がコミュニティの主要な資産です。 企業は事業として関わり、その動機は正当なものであり、隠す必要はありません。重要なのは順序です。会場・資金・登壇者・公開された知見など、コミュニティが求めるものを先に差し出す企業は関わりを維持できます。先に注目を求める企業はその関わりを失いやすく、失ったものを取り戻すのは困難です。 コミュニティへの関わりは、企業が所有するチャネルではありません。場を運営し参加する人たちから与えられているものであり、その場の役に立たなくなれば取り上げられます。取り上げられうるという前提で関わり方を設計します。 ### 場の種類 コミュニティが集まる場にはいくつかの形式があります。それぞれ規模・必要な準備・向いている目的が異なります。 | 形式 | 規模と頻度 | 向いていること | | ------------- | --------------- | -------------------------------- | | 勉強会 | 小規模・継続的 | 同じ参加者と一つのテーマを時間をかけて扱う | | ミートアップ | 小〜中規模・継続的 | 関心を共有する人と出会う。セッションと同じくらい会話が重要になる | | テックカンファレンス | 大規模・多くは年次 | 技術領域全体を一度に扱い、普段の輪の外にいる人に届ける | | オンラインイベント | 規模を問わず、移動コストが低い | 場所を問わず参加してもらい、記録を残す | | オープンソースプロジェクト | 継続的・会場を持たない | 機会ではなく成果物そのものを介して協働する | ## 発信が果たす役割 ### 定義と形式 自社プロダクトにおいても、技術ブランディングにおいても、発信は重要です。発信は、エンジニアリングの知識を、それを持つ個人やチームの外に、他の人が使える形で置く行為です。いくつかの形式があり、それらは互いに代替できるものではありません。 | 形式 | 向いていること | | ---------- | ---------------------------- | | 技術記事 | 判断とその理由を分量をかけて説明し、後から読める形で残す | | イベントでの登壇 | 決まった時刻に聞き手へ届け、その場で質問に答える | | 勉強会・ミートアップ | 少人数と深い関係を築く | | オープンソース | 成果物そのものを公開する。実物が説明を兼ねる | | 公開ドキュメント | すでに具体的な疑問を持って訪れる読者に応える | ### 3つの役割 説明することで、書き手は自分の中で曖昧なままだった部分を埋めることになり、読み手は解決済みの問題を解き直さずに済みます。 公開された成果は、組織の技術的な水準を外から観察できるものにします。その水準は、他者がその組織と関わるかを判断するときに見るものです。 発信は求人票では伝わらないもの、すなわちそのチームが実際に扱っている課題と、判断の質を伝えます。 学習の循環は、まず発信した側に返ってきます。説明を書くと、書き手が言語化できない飛躍は読み手に受け入れてもらえないため、これまで検証されていなかった理解の部分が表に出ます。そこで得られるフィードバックが誤りを訂正します。これは他の方法では得にくい形のレビューです。 技術ブランディングは、単発の成果ではなく蓄積から生まれます。判断を継続して公開している組織は外部から予測可能になり、その予測可能性が技術的な協業や導入の判断を成り立たせます。 採用への影響は実在しますが、間接的なものです。受け手のために作られた内容は同じ価値観を持つ人を引き寄せ、応募者を集めるために作られた内容は宣伝として受け取られ、必要な受け手を失います。採用を直接の目的ではなく下流の効果として扱うことが、時間を使うに値する内容を保ちます。 発信の効果は時間をかけて現れ、個々の記事やイベントに帰属させることが困難です。一つひとつを短期の数値で評価するのではなく、多数の発信を含む十分な期間で活動全体を評価します。