人材業界やHRTechのエンジニアの年収は、「HR」という領域の名前では決まりません。採用市場の景気で売上が動く事業か、月額課金で積み上がる事業かで、給与の原資の安定性が変わるからです。そのうえで、業務知識が設計の判断に結びついている人ほど、等級の説明がしやすくなります。
業界による差の全体像は企業タイプ別の年収相場で確認できます。この記事では人材領域に固有の事情に絞って説明します。
HRTechの年収を示す公的統計はない
結論として、HRTechや人材業界のエンジニアだけを集計した公的統計はありません。比較に使えるのは業種全体の平均です。ただし人材サービス業と情報通信業は別の業種に分類されるので、どちらの業種の統計で見るかで出発点が変わります。
| 項目 | 平均給与 |
|---|---|
| 情報通信業 | 682万円 |
| サービス業 | 402万円 |
| 全業種 | 487万円 |
この表を業界の優劣として読むことはできません。国税庁の統計は業種ごとに全職種を集計しているので、サービス業にはエンジニアではない職種が多く含まれます。人材系のSaaSを提供する会社は情報通信業に分類される場合もあり、職業紹介が主力の会社はサービス業側に入ることがあります。
使い方としては、同じエンジニアでも、会社全体の給与水準が違う環境に置かれる可能性があると理解することです。全社の賃金テーブルが営業や事務を前提に作られている会社では、エンジニアだけ別のレンジが用意されているかどうかが重要になります。この点は面接で確認すべき項目です。
平均値の読み方についてはエンジニアの平均年収をあわせて見てください。
収益の形で分けると原資の違いが分かる
人材領域の事業は、大きく3つに分けて考えると見通しがよくなります。人材紹介と求人メディア、派遣や請負の人材サービス、採用管理や労務のSaaSです。売上がどう発生するかが、昇給の原資と景気の影響を決めるためです。
| 事業の形 | 売上の発生 | 景気の影響 | エンジニアに求められやすい役割 |
|---|---|---|---|
| 人材紹介・求人メディア | 成約や掲載ごと | 受けやすい | マッチングや集客の改善、社内の業務システム |
| 派遣・請負 | 稼働ごと | 中程度 | 勤怠や請求などの業務システム |
| 採用管理・労務のSaaS | 月額課金 | 比較的安定 | プロダクト開発、連携、法改正の対応 |
これは一般的な構造で、会社によって複数の事業を併せ持つことも多くあります。
具体例として、人材紹介を主力にしている会社の採用が急減した場合を考えます。売上は成約に連動するので、すぐに減少します。すると翌年の昇給の原資や開発の予算に影響します。一方、月額課金のSaaSは売上が急には減りません。ただし新規の契約が減れば成長率は落ち、資金調達をしている会社なら評価や採用の方針が変わります。どちらも無関係ではありません。
求人の市場そのものの数字として、情報処理・通信技術者の有効求人倍率は1.33倍、新規求人数は前年同月比で-3.4%でした。これはハローワーク経由の数字で人材業界の売上を示すものではありませんが、採用の市場が動いていることを知る手がかりになります。
企業タイプでみた推定レンジ
当サイトの診断モデルで、実務3〜5年・東京・スキル中位の条件を企業タイプ別に見ると次のようになります。
| 企業タイプ | 推定レンジ | レンジの図 |
|---|---|---|
| メガベンチャー・外資 | 604〜709万円 | |
| 上場・大手 | 531〜624万円 | |
| 中小の受託・SIer | 459〜539万円 | |
| スタートアップ | 483〜567万円 | |
| SES | 411〜482万円 |
モデルに業界の係数はないので、上場した人材大手は「上場・大手」、資金調達段階のHRTechは「スタートアップ」の行を目安にします。同じHRTechでも、どの行に当たるかでレンジは大きく変わります。領域が同じなら水準も近いと考えるのは誤りです。
同じく、自社プロダクトの開発を担う会社と、社内の業務システムを担当する部門でも違いがあります。人材大手の社内システムを担当する場合は、社内SEの処遇に近いことがあります(社内SEの年収)。プロダクト開発の場合はSaaSのエンジニアとして比較するほうが適切です。
スタートアップの場合は、現金の年収に加えてストックオプションの有無を確認します。ただし現金と同列には扱えないので、まず現金だけで生活が成り立つかを確かめます(ストックオプションの評価)。
業務知識が評価される5つの場面
人材領域で業務知識が年収に効くのは、知っていることそのものではなく、知っていることで設計の失敗を防げる場面です。特に次の5つの場面で差が出ます。
1つ目は給与計算と勤怠です。締め日、割増の計算、休暇の付与など、ルールの組み合わせが多く、仕様の誤りが利用者の給与に直結します。業務を理解している人は、例外のパターンを先に洗い出せるので、後から作り直す量が減ります。
2つ目は法改正への対応です。労働や社会保険の法令は定期的に変わり、施行日に合わせて製品を変える必要があります。特定の日付で計算が切り替わる設計や、過去の計算の再現性を保つ設計が求められます。法改正のたびに大きな改修が発生しない仕組みを作れる人は、代替が利きにくくなります。
3つ目は採用のプロセスです。応募から内定までの状態の遷移、選考の権限、通知の出し分けなど、業務を理解していないと画面と実務が噛み合いません。導入先の企業ごとに異なる運用をどこまで設定で吸収するかは、典型的な設計の判断です。
4つ目は個人情報の扱いです。履歴書、評価、給与、健康に関わる情報を扱うため、権限の制御と監査ログの設計が重要になります。単に暗号化するのではなく、誰がどの情報を見られるかを組織の変更に追従させる必要があります。
5つ目は既存システムや外部サービスとの連携です。給与システム、会計システム、行政の手続きと連携する場合、相手の仕様変更や失敗の扱いが品質を左右します。再実行で二重に処理しない設計など、信頼性の判断が評価されます。
業務知識の評価については、物流・小売業界のエンジニアの年収と業務知識でも別の業界の例を扱っています。業界が変わっても、知識を判断に変換できるかどうかが共通の基準です。
業務知識を年収につなげる書き方
業務知識を評価に結びつけるには、知識の量ではなく、設計の差として説明する必要があります。「労務の知識があります」では、等級の根拠になりません。その知識がなければ起きていた問題を、どう防いだかを書きます。
具体例を比べます。「勤怠管理システムの開発」と書くと担当の範囲しか分かりません。「月の途中で労働条件が変わる従業員の計算を再現できるよう、条件を履歴として持つ設計に変更し、遡及の修正に対応した」と書くと、業務の理解が設計にどう効いたかが伝わります。後者のほうが面接でも深く話せます。
書き方の詳細は職務経歴書の書き分けにまとめています。
なお、業務知識は業界を変えると価値が下がることがあります。給与計算の細かな知識は他の業界では使えません。ただし、複雑な業務ルールをモデル化する力、法令変更に耐える設計、監査可能な権限管理は、金融や医療の領域でも評価されます。移るときは、業界に閉じた知識ではなくこの抽象度で語れるようにしてください(業種をまたぐ転職で年収がどう動くか)。
カスタマイズの多さが仕事の質を変える
HRTechの求人を見るときは、製品の性質も確認します。導入先ごとのカスタマイズが多い製品か、設定の範囲で標準化されている製品かで、エンジニアの仕事は大きく変わります。カスタマイズが多いと個別対応の比率が高くなり、受託開発に近い働き方になることがあります。
年収との関係では、標準化が進んだ製品のほうが、利益率が高くなりやすいとされる点が重要です。個別対応に人手がかかると原価が上がり、昇給の原資を圧迫します。もちろん、大手向けの高単価な製品では個別対応が多くても利益が出る場合があるので、一律には言えません。
面接では、「直近の開発のうち、特定の顧客向けの対応はどのくらいの比率ですか」と聞きます。導入や運用に関わる仕事の相場は業務SaaSの導入・運用エンジニアの年収で扱っています。
例外として、カスタマイズの多い環境で要件の整理を担当すると、顧客の業務に踏み込む経験が積めます。これを評価の材料にして、プロダクトマネージャーや導入コンサルタントへ広げる道もあります。
人材大手の社内開発とSaaS企業の違い
同じ人材領域の中で転職を考えるなら、人材大手の社内開発とSaaS企業の違いを把握します。賃金テーブルの作り方が異なることが多いからです。
人材大手では全社の人事制度の中でエンジニアの処遇が決まることが多く、賞与の比率や福利厚生は手厚い一方、エンジニア専用の高いレンジがない場合があります。ただし近年はエンジニア専用の職種やレンジを設ける会社もあります。SaaS企業ではエンジニアを中心に制度が作られていることが多い反面、賞与が少なく年俸に寄せている会社もあります。
比較の基本は、額面の年収を基本給、賞与、手当、株式に分けることです(オファー面談で見る年収の内訳)。賞与の比率が高い会社は、業績で変動する点を見積もりに入れてください(賞与比率が高い会社と低い会社)。
注意点として、自社の製品の顧客である人事部門の感覚が、社内の評価制度に反映されるとは限りません。HRTechの会社だから評価制度が優れているとは言えないので、制度は個別に確かめます。
面接とオファーで確認すること
人材領域の求人では、次の項目を確認します。
- 主な収益の形(成約、掲載、月額課金)と、景気で売上が動いた実績
- 配属先がプロダクト開発か社内システムか
- エンジニア専用の等級やレンジがあるか
- 特定の顧客向けの開発の比率
- 法改正の対応を計画に入れる仕組みと、繁忙期の時期
- 個人情報の権限管理や監査の責任を担う担当者
法改正の時期は繁忙期になりやすい領域です。残業の実態も合わせて確認し、提示年収を実質時給でも評価してください(みなし残業と実質時給の見方)。
個人情報の領域は責任が重くなるぶん、評価の材料にもなります。セキュリティの担当者がいて役割分担ができている環境かどうかで、働き方と得られる経験が変わります。
向いている人と、そうでない人
人材領域は、複雑な業務ルールを整理して正しく動かすことに価値を感じる人に向いています。派手な技術の挑戦より、間違いが許されない処理を丁寧に作る仕事が中心になる場面が多いためです。
一方で、新しい技術を試すことが主な関心なら、物足りなく感じる場合があります。また、利用者の業務を理解する時間が長いので、業務の話を面倒に感じる人には負担になります。これは優劣ではなく適性の問題です。
年収の観点では、業務に閉じた知識で評価を得ると、社外に持ち出しにくくなります。社内の評価が高くても、外の市場で同じ評価を受けられるとは限りません。定期的に職務経歴書を更新し、一般的な技術の言葉で説明できるかを確かめてください。
この記事の数字が当てはまらないケース
業種の平均給与は全職種の平均で、エンジニアだけを取り出したものではありません。人材領域の会社が情報通信業とサービス業のどちらに分類されるかも、会社によって異なります。
有効求人倍率はハローワーク経由の求人の集計で、転職市場全体の実態とは異なる場合があります。診断モデルのレンジはエンジニア全体の推定で、HRTechの係数を持っていません。いずれも個別の提示額の妥当性を判定できる根拠ではありません。
最終チェック
- 応募先の主な収益の形を確認した
- 配属先がプロダクト開発か社内システムかを確認した
- エンジニア専用のレンジや等級の有無を確認した
- 業務知識を、防いだ問題の形で説明できる
- 特定顧客向けの開発の比率を確認した
- 業界に閉じない言葉で自分の経験を書けるようにした
人材領域で年収を動かすのは、領域の名前ではなく、事業の収益の形と、業務知識を設計の判断に変える力です。この2つを確かめてから、提示額を比べてください。