LIVESENSE ENGINEER BLOG

リブセンスエンジニアの活動や注目していることを発信しています

転職ドラフトの年収診断機能の仕組みと注意点

 リブセンスでデータサイエンティストをしている北原です。先日リリースされた転職ドラフトの年収診断機能について解説します。

job-draft.jp

 年収診断機能は、技術や職種の経験に応じたITエンジニアの年収目安を簡単に確認できるようにするものです。業務経験に関するいくつかの質問にチェックするだけで、転職ドラフトスカウトで指名がもらえたときの提示年収水準がわかります。しかし、利用にあたっての注意点もいくつかあります。そこで、今回は年収診断の仕組みや予測モデルに起因する注意点について解説します。注意点だけ知りたい方は、目次からまとめに移動してください。  

年収診断機能の仕組み

指名時提示年収と技術タグの関係を学習

 年収診断機能は、転職ドラフトスカウトの指名時提示年収データを利用して実現しており、ITエンジニアのITスキル項目と年収のリアルな関係が反映されるようになっています。提示年収90%ルールがあるので、指名時提示年収が内定年収より大幅に減額されることはなく、実際に内定年収と提示年収は平均的にはほぼ同じであることがわかっています。したがって、指名時提示年収を内定年収とみなすことができます。一方で、ユーザー数が同一の場合、内定年収より指名時提示年収のほうがデータ量が多くなるので質の高い年収予測がしやすくなります。

 転職ドラフトスカウトでの指名時提示年収を使っているので、比較的転職ドラフトスカウトの利用が多いユーザー層には適しているものの、それ以外のユーザーについては適切な年収が算出されない可能性があることには注意が必要です。具体的には、Webエンジニアやネイティブアプリエンジニアとしての実務経験があるユーザーには参考になるはずです。一方で、新卒1年目などほとんど実務経験がないユーザー、比較的高齢のユーザー、SESやSIerの実務経験しかないユーザーについては、指名データが少ないため適切な年収が算出されない可能性があります。ユーザー層の拡大を図っているため、将来的にはこれらのユーザーについても適切な年収水準を算出できるようになるかもしれませんが、現時点(2026年1月時点)では困難なのが実情です。「転職したらどの程度の年収になるのか」ではなく、「もしWebやネイティブアプリエンジニアをしていたら、どの程度の年収になるのか」を考えるのに参考していただければと思います。

インフレ率を考慮した現在価値を反映

 指名時提示年収データは、インフレ率を反映して現在価値に換算しています。2025年12月の日本では3%近いインフレが続いており、インフレ率3%とすると現在の年収800万円は1年前の776.7万円と同じでおよそ23万円の差があります。直近の過去データであればほとんど無視できるので問題ないものの、過去に遡るほど現在の年収との乖離が増大し、年収を低く算出する原因になるなどの悪影響を生じます。そこで、過去の提示年収を平均前月比インフレ率を使って現在価値に変換し、インフレの影響を除去しています。図で示すと以下のように変換します。

%%{init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#ffffff', 'primaryTextColor': '#333333', 'primaryBorderColor': '#1a5a96', 'lineColor': '#546e7a' }}}%%
flowchart TD
    %% クラス定義
    classDef base fill:#1a5a96,stroke:#1a5a96,color:#ffffff,font-weight:bold
    classDef diff fill:#78909c,stroke:#546e7a,color:#ffffff,stroke-dasharray: 5 5
    classDef box fill:#ffffff,stroke:#cfd8dc,color:#263238

    %% 構造
    subgraph S1 ["2024年 提示年収 (名目価値)"]
        V1["776.7万円"]:::base
    end

    subgraph S2 ["2025年 現在の価値 (実質価値)"]
        direction TB
        P["776.7万円"]:::base
        D["23.3万円 (インフレ分)"]:::diff
        V2["800万円"]:::base
        P --- + --- D --> V2
    end

    %% 矢印(ラベルに引用符を使わない形式)
    S1 -- インフレ調整(例:3%) --> S2

    %% サブグラフのスタイル
    class S1,S2 box

プロジェクトごとに技術や職種の業務経験期間を分配

 予測モデルの主要特徴量である技術や職種の業務経験期間については、従事プロジェクトに登録されたプログラミング言語やフレームワークなどのプロジェクト期間を、カテゴリごとに登録されている各技術や職種に均一に割り当てています。また、仕様上、2年以上のプロジェクトの登録期間はどれだけ長くとも「2年以上」という登録内容となり正確な期間が不明という問題があります。そこで、2年以上のプロジェクトの登録期間は、Web・アプリ業界で数年にわたる長期プロジェクトが少ないことを考慮し一律に3年の期間として算出しています。このため、3年以上の長期プロジェクトについてはどれだけ長くとも業務経験は3年として評価されるので過小評価されやすくなっています。

 同一プロジェクトで複数技術を使っているときの問題について考えてみましょう。例として、AWSとGCPを扱うプロジェクトに2年間従事している場合を考えます。この場合、AWSとGCPを2年間使っていたと考える人も多いと思います。しかし、AWSのみあるいはGCPのみを使っていた人より業務経験の密度は下がるはずです。このとき、AWSとGCPのいずれの業務経験も2年として扱うと、AWSのみあるいはGCPのみを使っていた人より業務経験の総量が2倍になります。一般的に、このような扱いをすると、薄く広く多くの技術を扱っている人が過大評価されることになります。

 このように技術や職種を多く登録するほど高く評価されるのを防ぐため、プロジェクト期間をカテゴリごとに登録されている各技術や職種に均一に割り当てています。これにより、プロジェクトの期間と、同一カテゴリ内の技術や職種の期間の総和が等しくなるようにしています。プロジェクト内での各技術の利用頻度や各職種の業務量がわからないので、各技術や職種の業務経験が同程度であることを仮定しています。先ほどの例だと、プロジェクト期間が2年で、クラウドカテゴリのAWSとGCPの2つを使っているので、それぞれの業務経験を1年として扱っています。なお、同じプロジェクトでプログラミング言語はRubyしか使っていないならば、プログラミング言語カテゴリではRubyのみなので業務経験は2年として扱われます。図にすると以下のようになります。  

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#333333',
    'primaryBorderColor': '#1a5a96',
    'lineColor': '#546e7a',
    'secondaryColor': '#f5f5f5',
    'tertiaryColor': '#fafafa'
  }
}}%%
flowchart TD
    %% クラス定義
    classDef project fill:#1a5a96,stroke:#1a5a96,color:#ffffff,font-weight:bold
    classDef skill fill:#78909c,stroke:#546e7a,color:#ffffff
    classDef result fill:#cfd8dc,stroke:#546e7a,color:#263238,font-weight:bold
    classDef caseBox fill:#ffffff,stroke:#cfd8dc,stroke-dasharray: 5 5

    %% 構造
    P[プロジェクト期間: 2年]:::project

    P --> Case1
    P --> Case2

    subgraph Case1 [カテゴリ内スキル1つの場合]
        direction TB
        Skill1[Ruby]:::skill
        Res1[算出結果: 2.0年]:::result
        Skill1 --> Res1
    end

    subgraph Case2 [カテゴリ内スキル2つの場合]
        direction TB
        Skill2A[AWS]:::skill
        Skill2B[GCP]:::skill
        
        Calc{÷ 2}
        
        Res2A[算出結果: 1.0年]:::result
        Res2B[算出結果: 1.0年]:::result

        Skill2A & Skill2B --> Calc
        Calc --> Res2A
        Calc --> Res2B
    end

    %% サブグラフのスタイル適用
    class Case1,Case2 caseBox

これによって多くの技術や職種を登録するほど高く評価される問題は緩和されます。なお、均一割当にすることで各技術や職種が年収に与える影響が分散されるため、技術や職種が年収に与える影響の技術間の差や職種間の差は実際より小さくなっていると考えられます。

 このような特徴量の作成方法をふまえると、年収診断で技術や職種の業務経験を入力する場合も学習データ作成時と同様に計算した業務経験期間を入力したときに年収診断の精度は最大になります。しかし、これは手間がかかるので、最もよく使った技術や最も業務量の多かった職種の業務経験年数のみを入力するようにすると、大きく精度を損なわず簡単に使えます。少ししか経験のない技術や職種の業務経験年数を入力しないようにするところがポイントで、業務経験のダブルカウントなどを防ぐことで極端な診断結果を抑制できます。

提示年収予測モデル

モデル選定

 提示年収の推定モデルにはシンプルな線形回帰モデルを採用しています。シンプルなのでサービスに組み込みやすいことや、質問項目の仕様に合わせやすいこと、安定した精度が得られていたことが理由です。年収は対数正規分布にしたがいますし、高年収になるほど誤差が大きくなることが予想されます。そこで、誤差に対数正規分布を仮定したモデルや、不均一分散を仮定したモデル、ガンマ回帰などを試みました。しかし、誤差の大きさや誤差傾向に有意な改善が見られなかったので、目的変数の変換は行わず特徴量の中心化と誤差にt分布を仮定したモデルを採用しました。t分布を採用することで、外れ値の影響を受けにくくなっています。特徴量とロバスト性によって、分布の非対称性や不均一分散にある程度対応できていると考えられます。

 質問項目にプログラミング言語などの業務経験年数を使っているため、これらの回帰係数には非負制約をつけています。何も制約をつけないと、多重共線性のため、これらの回帰係数は負になることがあります。そうすると、業務経験年数が長くなるほど年収が低下するという納得し難い診断結果が生じてしまいます。業務経験年数が入力される項目に対応した回帰係数に非負制約をつけることで、このような定性的におかしな結果が生じなくなります。ただし副作用もあり、平均絶対誤差や平均二乗誤差はわずかながら増大します。

 非負制約をつける方法には制約付き最小二乗法もありますが、今回はベイズ線形回帰を使っています。非負制約をつける変数とつけない変数が混在するときの実装が簡単で、過学習の抑制もできるためです。極端に該当者が少ないスキルは質問項目に含まれていないため、階層化は行なっていません。

予測精度

 予測精度は、10分割交差検証のテストデータにおける提示年収の予測と実績を使って確認しています。精度指標にはMAE(Mean Absolute Error)とRMSE(Root Mean Squared Error)を使います。予測を大きく外すケースがあるとMAEよりもRMSEのほうが相対的に大きくなるので、MAEで平均的な誤差を確認し、RMSEで大外れが多いかを確認します。誤差の算出方法には、指名ごとに計算する方法とユーザーごとに計算する方法がありますが、いずれも同じ傾向を示すのでここではユーザーごとに計算した結果を示します。

全ユーザー

 全ユーザーのMAEとRMSEは次のようになっています。平均して100万近い誤差が生じているので予測はあまり当たっていないように見えるかもしれません。しかし、参加ユーザー一覧を年代別に見てもらうとわかる通り、業務経験年数が同程度でも提示年収が数百万円異なることはよくあるので、それほど悪い精度ではありません。提示年収は、技術や職種の業務経験年数以外にも、設計能力や技術の熟達度合い、事業ドメインとのマッチ度、企業の年収水準などにも影響を受けます。年収診断機能は技術や職種の経験年数に応じた平均的な年収水準を示すものなので、このことは技術や職種の経験年数だけでは説明がつかない部分が平均100万程度あるということを示しています。年収診断機能は、業務経験年数に見合った年収水準を知るのには有用ですが、転職ドラフトスカウトに参加したときに得られる提示年収を保証するものではありません。

MAE(万円) RMSE(万円)
96 130.8

業務経験年数別

 業務経験が長くなると同じような技術や職種を経験していても実際の技術力の差は大きくなりやすいです。そのため、年収診断の予測モデルでは説明できない年収のブレも大きくなりやすいと予想されるので、業務経験年数別の予測精度も確認しましょう。

 業務経験年数別のMAEとRMSEは次の図のようになっています。予想通り、概ね業務経験が長くなるほど誤差が大きくなっていることがわかります。転職ドラフトスカウトでは、レジュメの自由記述が年収決定の重要な判断材料になります。業務経験が長くなるほどアピール材料が増え、同一の業務経験でも提示年収が大きく異なり、それにともない誤差も大きくなります。つまり、業務経験が長い方ほど、実際に転職ドラフトスカウトに参加しないと正確な市場価値を知るのは難しいと言えます。  

業務経験年数別予測誤差

 もう少し詳細に確認するため、提示年収の予測と実績の散布図を見てみましょう。誤差のグラフと同じ色で業務経験年数ごとに色分けをしており、半透明なので該当者が多いところでは色が濃くなっています。点線は予測と実績が一致したラインです。

提示年収の予測と実績の散布図

 概ね点線を中心に分布しているものの、大きく外している部分も見られます。業務経験は同一でも、業務経験年数だけではわからない特筆すべき評価ポイントがあると非常に高い年収が提示されることがあります。このような場合、予測より実績のほうが遥かに大きくなります。逆に、予測より実績が大幅に下回るケースは少ないです。この非対称性の原因としては、年収が対数正規分布にしたがっていることと、業務経験に見合わないユーザーに対しては低い年収を提示して指名するのではなく、指名を見送っている可能性があることが挙げられます。業務経験年数に見合った予測より実際の提示年収のほうが大きく上方乖離していることは、十分な業務経験と実力のあるユーザーにとっては年収が大幅に増加するチャンスがあることを意味しています。

まとめ

 年収診断を使うときの注意点をまとめると以下のようになります。

  • 比較的転職ドラフトスカウトの利用が多いユーザー層(Web・ネイティブアプリ等)以外の方が診断すると、本来の市場価値より高めの年収と診断されることがある
  • 少ししか経験していない技術や職種も入力すると高めの年収と診断されやすい
  • 算出される年収は経験した技術や職種の業務年数に応じた平均的な値であるため、業務経験年数だけではわからない高い技術力を持っている場合は低めの年収と診断されやすい

 これらをふまえると以下のように使っていただくのがよいと思います。

  • Web・ネイティブアプリの業務経験のある方は、自分の業務経験に見合った年収水準を知るのに使う
  • 非Web・ネイティブアプリの方は、Web・ネイティブアプリの業務をしていたら平均的に得られる年収水準を知るのに使う
  • 最もよく使った技術や職種の業務経験のみを入力する

 年収診断機能は業務経験に応じた平均的な年収を算出するもので目安の1つにはなりますが正確な市場価値を示すものではありません。特に実力のあるエンジニアは年収診断の結果より遥かに高い提示年収が得られる可能性が高いです。業務経験の長さだけではわからない市場価値を知りたい方は転職ドラフトスカウトに参加されることをお奨めします。