DevRel・技術広報に移るエンジニアの年収｜所属部門で変わる評価軸と5つの確認

エンジニアとして働くうちに、登壇や記事の発信が得意だと気づき、DevRel（デベロッパーリレーションズ）や技術広報の仕事に関心を持つ人がいます。そのとき気になるのが、エンジニアから移ったときに年収がどうなるかです。結論から言うと、DevRelや技術広報に移ったときの年収は、職種名より、どの部門に所属してどの給与テーブルが使われるか、そして成果を何で測られるかで決まります。同じDevRelという職種でも、エンジニアの組織に所属する場合と、広報やマーケティングの組織に所属する場合では、年収の水準も上がり方も違うためです。

この記事は、社内の異動や転職でDevRelや技術広報の仕事に移ることを考えているエンジニア向けに、年収を決める要素、エンジニア職と年収がずれる3つの場面、評価の指標の見方、技術力を保つ方法、移る前に確認する5項目を整理します。技術記事やOSSへの貢献がエンジニアとしての評価にどう効くかは技術記事とOSS貢献は転職で評価されるのかで扱っています。

結論：年収は「所属部門」と「成果の測り方」で決まる

DevRelや技術広報に移るときは、所属する部門と、成果を測る指標の2つを先に確認します。この2つで、移った後の年収の水準と上がり方がおおむね決まります。

理由は、多くの会社で、給与テーブルや等級制度が部門や職種の系統ごとに分かれているからです。エンジニアの組織に所属すれば、エンジニアと同じ等級制度で評価され、技術の専門性が年収の水準を支えます。広報やマーケティングの組織に所属すれば、その部門の給与テーブルが使われ、エンジニア職とは違う水準になることがあります。

具体例として、同じ経験年数のエンジニアが2人、それぞれ別の会社のDevRelに移ったとします。1人はエンジニアの組織の中に置かれたDevRelのチームに所属し、エンジニアと同じ等級で評価されます。もう1人はマーケティングの部門に所属し、マーケティング職の等級で評価されます。移った直後の年収が同じでも、数年後の昇給や昇格の上がり方は、所属する部門の制度によって変わります。

例外は、DevRelや技術広報を独立した専門職として、独自の等級制度を設けている会社です。この場合は、専門職としての評価の基準と報酬の幅を個別に確認する必要があります。

DevRelと技術広報は、目的と相手が違う

DevRelと技術広報は、どちらも社外への発信を担う仕事ですが、誰に向けて、何のために発信するかが違います。目的が違えば、評価の指標も、年収の上がり方も変わります。

この表の読み方で大切なのは、DevRelの成果が製品の事業に、技術広報の成果が採用につながるという違いです。開発者向けの製品を売る会社では、DevRelの成果が売上に近い位置にあるため、事業への貢献として評価されやすくなります。一方で技術広報は、採用の成果と結びつくため、採用の状況によって重要度が変わることがあります。

具体的には、開発者向けのAPIやツールを提供する会社のDevRelは、製品の使い方を広め、開発者の困りごとを製品の改善につなげる役割を担います。自社サービスを開発する会社の技術広報は、技術ブログやイベントを通じて、技術組織の取り組みを発信し、採用の母集団を広げる役割を担います。

注意点として、一人で両方を担う職場も少なくありません。その場合は、どちらの成果を主に評価されるのかを確認しておかないと、両方の仕事を担いながら、どちらの成果も十分に評価されない状態になることがあります。

エンジニア職と年収がずれる3つの場面

DevRelや技術広報に移ると、エンジニア職と年収がずれることがあります。ずれが起きやすいのは、所属部門の給与テーブルが違う場合、成果の指標が事業から遠い場合、技術の専門性が評価から外れる場合の3つです。

1つ目は、所属部門の給与テーブルが違う場合です。広報やマーケティングの部門の給与テーブルが、エンジニア職より低い水準に設定されている会社では、移った時点で年収が下がったり、その後の昇給の幅が小さくなったりします。移る前に、どの等級制度で評価されるかを確認してください。

2つ目は、成果の指標が事業から遠い場合です。登壇の回数や記事の閲覧数のように、事業の成果とのつながりが見えにくい指標だけで評価されると、会社の業績への貢献として認められにくく、昇格の根拠が作りにくくなります。

3つ目は、技術の専門性が評価から外れる場合です。DevRelの仕事でも、製品の技術を深く理解し、開発者の質問に答えられる技術力が求められますが、評価の項目に技術力が含まれていないと、技術の専門性が年収に反映されなくなります。等級制度の読み方は等級・グレード制度と昇格の条件で整理しています。

注意点として、この3つがそろわなければ、DevRelに移ってもエンジニア職と同じ水準を保てることがあります。ずれが起きるかどうかは、職種名ではなく会社の制度で決まるため、移る前に一つずつ確認してください。

評価の指標は、事業の成果とのつながりで見る

DevRelや技術広報の評価の指標は、回数や閲覧数のような活動の量ではなく、事業の成果とどうつながっているかで見ます。事業の成果につながる指標で評価される職場ほど、昇給や昇格の根拠が作りやすくなります。

理由は、会社が昇給や昇格を決めるとき、その人の仕事が会社の業績にどう貢献したかを根拠にするからです。登壇の回数や記事の数は、仕事をした証拠にはなりますが、それが会社の業績にどうつながったかを示せないと、評価の根拠としては弱くなります。

具体的には、DevRelであれば、発信をきっかけに製品の利用を始めた開発者の数、開発者から集めた声をもとに改善された機能、製品の問い合わせの減少などが、事業の成果に近い指標になります。技術広報であれば、発信をきっかけにした採用の応募や、実際の採用につながった数が、採用の成果に近い指標になります。

注意点として、DevRelの成果は、効果が出るまでに時間がかかることが多く、短い期間の数字だけで評価されると、過小に評価されることがあります。評価の期間と、長い期間の成果をどう扱うかも、移る前に確認しておきたい点です。自己評価の書き方は人事評価の自己評価シートを昇給につなげる書き方で整理しています。

企業タイプで年収の水準が変わる

DevRelや技術広報の年収も、エンジニアと同じように、会社の種類によって水準が大きく変わります。DevRelの職種を置いているのは、開発者向けの製品を持つ会社や、採用に力を入れる会社が中心で、会社の種類によって報酬の設計が違います。

エンジニアの年収が会社の種類でどれだけ変わるかは、診断モデルの推定で見ると次のようになります。実務3〜5年、東京勤務、スキル中位の条件です。

この表はエンジニアの年収の推定で、DevRelや技術広報の年収を示したものではありません。表の読み方として、エンジニアの組織に所属してエンジニアと同じ等級で評価されるDevRelであれば、この表の水準がおおむね当てはまります。一方で、別の部門の給与テーブルが使われる場合は、この表の水準から外れることがあります。個別の会社の提示額ではなくモデルによる推定なので、実際の比較では手元の提示額を使ってください。

注意点として、DevRelの職種を専任で置けるのは、開発者向けの製品を持つ会社や、発信に人を割ける規模の会社に限られやすく、求人の数自体がエンジニア職より少なくなります。応募先の選択肢が少ない分、提示条件を比べる相手も少なくなることを前提にしてください。会社の種類による違いの背景は企業タイプ別のエンジニア年収相場で整理しています。

技術力を保つ仕組みがあるかを確かめる

DevRelや技術広報に移るときは、技術力を保つ仕組みが仕事の中にあるかを確かめます。技術力が落ちると、DevRelとしての発信の質も下がり、エンジニアに戻るときの評価も下がるためです。

理由は、DevRelの仕事が、技術を分かりやすく伝えることに時間を使う一方、実務の開発に触れる時間が減りやすいからです。発信の準備やイベントの運営に時間を取られると、新しい技術を試す時間や、製品の開発に関わる時間が少なくなります。

具体的には、次のような仕組みがあると、技術力を保ちやすくなります。サンプルのコードや検証の環境を自分で作る時間が業務として認められていること、製品の開発チームと一緒に機能の改善に関わる機会があること、開発者から集めた技術的な課題を自分で調べて解決する役割があることです。反対に、発信の回数やイベントの運営だけを求められる職場では、技術力を保つのが難しくなります。

注意点として、技術力を保つための時間は、評価の指標に入っていないと、忙しい時期に真っ先に削られます。技術の検証や開発への関与が、評価の項目として扱われているかも確認してください。

出張・イベント・休日の対応を年収と合わせて見る

DevRelや技術広報の仕事では、イベントへの登壇や出展、出張、夕方や休日の勉強会への参加が発生することがあります。これらの時間がどう扱われるかによって、時間あたりの水準が変わります。

理由は、開発者向けのイベントや勉強会の多くが、平日の夕方や休日に開かれるからです。これらに業務として参加する場合、所定の労働時間の外で働くことになり、時間外や休日の扱い、振替休日の取り方によって、実際の負担と報酬が変わります。

具体的には、休日のイベントに登壇した場合に、休日出勤の扱いになるのか、振替休日を取れるのか、出張の移動時間がどう扱われるのかを確認します。裁量労働制や管理職の扱いで働く場合は、時間外の賃金が支払われないこともあるため、年収を時間あたりで考えると差が出ることがあります。時間あたりでの比べ方は年間労働時間で年収を比べる方法で整理しています。

注意点として、個人の活動としての発信と、業務としての発信の区別があいまいになりやすい点にも注意が必要です。業務時間外に個人として書いた記事が、会社の成果として扱われるのか、個人の活動として扱われるのかは、事前に確認しておくと、評価と時間の両方で行き違いを防げます。

DevRelからのキャリアの広がり方

DevRelや技術広報の経験は、その後のキャリアで何につながるかを考えておくと、移る判断と年収の見通しを立てやすくなります。

理由は、DevRelの経験が、技術の理解、社外への説明、開発者の声を製品に反映する力という、複数の職種で評価されるスキルの組み合わせになっているからです。この組み合わせをどう使うかによって、次のキャリアの選択肢が変わります。

具体的には、DevRelの経験は、プロダクトマネージャー、開発者向けの製品の企画、技術組織のマネジメント、エンジニアへの復帰など、いくつかの方向につながります。開発者の声を製品の改善につなげた経験は、プロダクトマネージャーとしての評価の土台になります。プロダクトマネージャーとの年収の比べ方はプロダクトマネージャーとエンジニアの年収比較で扱っています。

注意点として、DevRelの経験を次のキャリアで評価してもらうには、発信の回数ではなく、発信を通じて何を変えたかを説明できる必要があります。どの声を集めて、どの改善につなげたかを記録しておくと、次のキャリアで経験を説明しやすくなります。

転職と社内異動で、年収の決まり方が違う

DevRelや技術広報に移る方法には、社内の異動と転職の2つがあり、年収の決まり方が違います。

社内の異動では、多くの場合、今の等級と基本給を保ったまま職種が変わります。所属する部門が変わって別の給与テーブルに移る場合でも、移った時点で年収が大きく下がらないよう調整されることが一般的です。ただし、その後の昇給や昇格は、移った先の部門の制度で決まるため、数年後の年収の上がり方が変わることがあります。社内異動の考え方は社内公募・社内異動で年収を上げられる条件で整理しています。

転職では、DevRelとしての経験がどう評価されるかによって、提示される年収が決まります。エンジニアとしての経験が長くても、DevRelとしての経験が浅いと、DevRelの職種としては経験の浅い人として評価されることがあります。転職全体の傾向として、転職で年収が増えた人の割合は 60.4%、増えた人の平均増加額は 73.1万円 でした。ただしこれは職種を変えない転職も含めた全体の傾向で、職種を変える転職では、前職の経験がどう評価されるかで結果が大きく変わります。

注意点として、社内で発信の経験を積んでから転職すると、DevRelとしての実績を具体的に説明できるため、評価されやすくなります。いきなり転職するより、今の職場で発信や開発者との接点の仕事を小さく試してから移るほうが、年収の面でも安全です。

移る前に確認する5項目

DevRelや技術広報に移ることを考えているときは、次の5項目を確認します。

1. 所属する部門と、適用される等級制度・給与テーブル
2. 成果を測る指標と、その指標が事業の成果とどうつながっているか
3. 技術の検証や製品の開発に関わる時間が、業務として認められているか
4. 休日のイベントや出張の扱い（休日出勤、振替休日、移動時間）
5. DevRelからほかの職種へ移った人の実績と、そのときの年収の扱い

いずれも社内の異動であれば上司や人事に、転職であれば面接やオファー面談で聞ける項目です。特に1番目と2番目は、移った後の年収の水準と上がり方を決める要素なので、口頭の説明だけでなく、等級制度や評価制度の資料で確認してください。オファー面談で確認すべき条件全体はオファー面談で確認すべき条件にまとめています。

よくある誤解

「DevRelは発信が仕事なので、登壇や記事が多いほど評価される」という見方は、評価の指標が事業の成果とつながっていないと成り立ちません。活動の量だけでは、昇給や昇格の根拠になりにくいことがあります。

「DevRelに移ると技術力が落ちる」という見方も一面的です。技術の検証や製品の改善に関わる仕組みがあれば、技術力を保ちながら、説明する力を伸ばせます。技術力が落ちるかどうかは、職場の仕組みで決まります。

「DevRelはエンジニアより年収が低い」という理解も、所属部門と給与テーブルを見ないと成り立ちません。エンジニアと同じ等級制度で評価される職場では、大きな差が出ないこともあります。

まとめ

• DevRelや技術広報の年収は、職種名より、所属部門と使われる給与テーブルで決まる
• DevRelは製品の事業に、技術広報は採用に、成果がつながりやすい
• 評価の指標は、活動の量ではなく事業の成果とのつながりで見る
• 技術の検証や開発への関与が業務として認められているかで、技術力の保ちやすさが変わる
• 移る前に、所属部門、評価の指標、技術の時間、休日の扱い、その後の実績の5項目を確認する