公開: 2026/5/26
Scalaエンジニア採用ガイド|要件定義から選考・口説き方まで
Scalaエンジニアの採用が難しい理由と要件定義・選考設計・スカウト・口説き方の実践手法を解説
TL;DR(この記事の要約)
Scalaはオブジェクト指向と関数型の両パラダイムを持つJVM言語で、金融・フィンテック・データエンジニアリング・アドテクノロジー領域を中心に採用企業が増加中
国内のScala経験者は極めて少なく、正社員採用には3〜6か月以上かかるケースが一般的。Java経験者・Haskell・F#などの関数型経験者からのコンバート採用が現実的な選択肢
年収レンジはミドルで600〜850万円、シニアで900〜1,300万円。関数型プログラミングの深い理解やAkka・Spark活用経験で上振れする
求人票にはScalaを選んだ技術的理由・Apache SparkやAkkaなど具体的なエコシステム・解決する業務課題を明示すると候補者に刺さりやすい
選考では型推論の理解・トレイト設計力・不変性の活用・モナドを使ったエラーハンドリングがScalaエンジニアの実力を見極めるポイント
Scalaエンジニアとは——なぜ今、採用ニーズが高まっているのか
「大量のデータを処理するパイプラインをApache Sparkで構築したいが、Scalaが書けるエンジニアが採れない」「Javaで書いたバックエンドを関数型スタイルに移行したいのに、Scala経験者が市場にいない」。
こうした声が、金融系スタートアップからデータプラットフォーム企業まで広がっています。Scalaは2004年にスイス連邦工科大学ローザンヌ校(EPFL)のMartin Odersky教授によって開発されたプログラミング言語で、オブジェクト指向と関数型プログラミングの両パラダイムを統合したJVM言語です。Javaとの完全な相互運用性を持ちながら、型安全性と表現力の高さを両立しています。
このページでわかること
Scalaエンジニアの定義と市場での位置づけ
採用が難しい構造的な理由と現実的な対処法
要件定義の作り方とスキルマトリクスの設計手法
候補者に響く求人票とスカウト文面の書き方
選考プロセスの設計と技術力の見極めポイント
採用競合に勝つための口説き方と条件設計
Scalaが選ばれる業界と背景
金融・フィンテックでの強さ
Scalaは型安全性と関数型の不変性が、金融システムの「バグを許さない要求」と相性が良い言語です。欧米ではJP MorganやGoldman SachsがトレーディングシステムにScalaを採用し、国内でもFinTechスタートアップや証券系企業でScalaへの移行・新規採用が進んでいます。
Apache Sparkとデータエンジニアリング
ビッグデータ処理エンジンとして広く使われるApache SparkはScalaで書かれており、高度なチューニングや独自処理の実装にScalaの知識が欠かせません。データエンジニアリングチームを持つ企業でのScala需要は、データ活用の本格化とともに伸び続けています。
アドテクノロジーとリアルタイム処理
広告配信系のリアルタイム入札(RTB)システムは高スループットと低レイテンシが求められます。AkkaのActor Modelによる並行処理、Kafka Streamsとの連携など、Scalaのエコシステムはリアルタイム処理と相性が良く、アドテク企業での採用が続いています。
Scala言語の特徴——採用担当者が理解すべき技術的ポイント
エンジニア採用を成功させるには、なぜ候補者がScalaに魅力を感じるのかを理解しておくことが重要です。ここではScala言語の特徴を、採用文脈で押さえるべきポイントに絞って解説します。
型推論による簡潔な表現力
Scalaは強力な型推論を持ちます。コンパイラが型を自動推論するため、Javaのような冗長な型宣言が不要になり、コードが簡潔になります。同時に静的型付けの恩恵(コンパイル時のバグ検出)を最大限に享受できます。
採用面接では、型推論の仕組みを理解しながらも、明示的な型注釈が必要な場面を判断できるかどうかが、Scalaエンジニアの成熟度を測る一つの指標です。
関数型プログラミングとイミュータビリティ
Scalaはイミュータビリティ(不変性) を推奨するスタイルで設計されています。val(不変変数)を優先し、副作用を持つコードを型レベルで制限するアプローチが、並行処理での安全性とテストのしやすさに直結します。
Option、Either、Tryといったモナドを使ったエラーハンドリングは、Nullポインタ例外を型レベルで防ぐ手法として、Scala特有の価値です。
豊富なエコシステム
エコシステム | 用途 | 採用シーン |
Apache Spark | ビッグデータ処理・ML | データエンジニア採用 |
Akka / Pekko | Actor Model・分散処理 | バックエンド・リアルタイム系 |
Play Framework | Webアプリケーション | Webバックエンド |
Cats / Scalaz | 関数型ライブラリ | 高度な型設計 |
ZIO | 非同期・関数型効果システム | モダンScala開発 |
sbt | ビルドツール | 全Scalaプロジェクト |
求人票で使用するエコシステムを明記すると、候補者のスキルとのマッチング精度が上がります。
JVM互換とJavaとの相互運用
ScalaはJVM上で動作し、JavaのライブラリをScalaから直接呼び出せます。既存のJavaコードベースを持つ企業がScalaを段階的に導入できる点は、移行コストの低減に直結します。Java経験者がScalaに挑戦しやすい構造でもあり、採用のコンバート戦略においても重要な特性です。
並行処理と分散システムへの適性
ScalaのActor Model実装であるAkka(現在はApache Pekkoに移行中)は、分散システムの設計に強力なツールです。非同期・イベント駆動のアーキテクチャを型安全に記述できる点が、マイクロサービスやリアルタイム処理システムの開発で重宝されています。
Scalaエンジニア採用はなぜ難しいのか——5つの構造的要因
Scalaエンジニアの採用は、GoやPythonなど人気言語と比べて難易度が高いのが現実です。その背景には構造的な要因があります。事業計画から逆算した採用計画を早い段階で立てておくことが重要です。
1. 経験者の絶対数が少ない
Scalaは国内の普及率が限定的で、JavaやTypeScriptと比べて実務経験者の母数が格段に少ない言語です。フォークウェルやFindyなどのスカウトサービスでの求人倍率も高く、スカウト返信率を高めるための工夫が不可欠です。
2. 学習難易度が高い
Scalaは「オブジェクト指向と関数型の両方を学ぶ」必要があり、Java経験者でも「Scalaらしいコードを書けるようになる」には一定の時間がかかります。型クラス・暗黙引数(implicit)・高階型などの概念は、関数型の素養がないと理解しにくく、参入障壁の高さが人材プールを絞り込んでいます。
なお、Scala 3(Dotty)では暗黙引数がgiven/usingに整理されるなど、学習体験が改善されていますが、それでも習得コストは高い水準です。
3. 優秀層が転職市場に出にくい
Scalaを主力で使う企業は国内では限られており、使いこなしているエンジニアはその職場で希少価値があります。現職のポジションを手放してまで転職する動機が低いため、潜在層へのアプローチが重要になります。
4. 「書ける」と「Scalaらしく書ける」の差が大きい
varを多用したJavaスタイルのScalaコードと、val・イミュータブルなデータ変換・モナドを活用したScalaらしいコードでは、保守性と安全性に大きな差があります。選考で「Scalaらしさ」を評価できる面接官の確保も課題です。
5. バージョン・エコシステムの変化への対応
Scala 2とScala 3では文法・概念に差異があり、AkkaからApache Pekkoへの移行など、エコシステム自体が変化しています。採用要件を「Scala 2経験が必須」に絞りすぎると母集団を著しく縮小させるため、バージョンを問わずScalaの本質的な理解を見るアプローチが有効です。
Scalaエンジニアの要件定義——スキルマトリクスの設計方法
採用要件の設計を誤ると、「理想が高すぎて誰も見つからない」か「基準が緩すぎてミスマッチが起きる」かのどちらかに陥ります。ここではScalaエンジニアの要件定義を3つのレイヤーで整理します。
スキルマトリクスの3レイヤー
レイヤー1:Scala言語のコアスキル
イミュータビリティの理解と実践(
val優先・不変データ構造の活用)パターンマッチングとケースクラス・シールドトレイトの設計
Option・Either・Tryによるエラーハンドリングトレイトとコンパニオンオブジェクトを使った設計
高階関数・カリー化・部分適用の活用
型推論の仕組みと暗黙引数(implicit / given)の理解
レイヤー2:ドメイン知識・エコシステム
ポジションによって必要なエコシステムが大きく変わります。
ポジション | 求めるエコシステム知識 |
データエンジニア | Apache Spark、Hadoop、Kafka、Parquet |
バックエンドエンジニア | Play Framework、Akka HTTP、ZIO HTTP |
分散システムエンジニア | Akka / Pekko、Akka Streams、Kafka |
関数型ドメイン設計 | Cats、Scalaz、ZIO、Shapeless |
レイヤー3:ソフトスキル
コードレビューで関数型アプローチの選択理由を説明できるコミュニケーション力
Javaとの相互運用を意識したアーキテクチャ設計の視点
Scala特有のビルドシステム(sbt)の設定・運用スキル
Java経験者のコンバート採用を前提とした要件設計
Scala経験者の母数が少ない現実を踏まえると、Java経験者をコンバート採用する前提で要件を設計するのが現実的です。
Must要件:Javaもしくは他のオブジェクト指向言語での商用開発3年以上
Want要件:Scala・Haskell・F#などの関数型言語の実務経験または個人学習実績
Nice要件:Apache Sparkやデータパイプライン構築経験
「Scala経験必須」に固執すると採用が長期化します。スキルマトリクスにコンバート枠を設けることで、採用の選択肢を広げましょう。
求人票の書き方——Scalaエンジニアが応募したくなる要素
Scalaエンジニアは技術的好奇心が強く、「なぜScalaを選んだのか」という技術的根拠と、「Scalaを深く使える環境かどうか」を重視する傾向があります。求人票の書き方の基本を押さえた上で、Scala特有の訴求ポイントを加えましょう。
必ず盛り込むべき要素
1. Scalaを選んだ技術的理由
「型安全性を担保しながら大規模データ処理を行うため」「Akkaの分散Actor Modelがリアルタイム入札のレイテンシ要件に適合するため」など、技術的根拠を具体的に書きます。「社内でScalaを使っているから」という記述は候補者の関心を引きません。
2. 使用するエコシステムの具体的な記載
こうした具体性が、候補者にとって「自分のスキルが活かせるか」の判断材料になります。
3. チームのScalaへの真剣度
コードレビューでのScalaらしい書き方へのフィードバック文化があること、Scala勉強会や社内ギルドが存在すること、技術ブログでScalaに関する記事を発信していることは、Scalaエンジニアが「ここは本気でScalaをやっている」と判断する根拠になります。
4. 技術的な挑戦の具体性
「分散トランザクションの整合性担保に関数型のアプローチを取り入れている」「型安全なDSLをShapelessで構築しているプロジェクトがある」など、Scalaの技術力を発揮できる課題の具体例が求人票に書かれていると、上位エンジニアの関心を引きやすくなります。
書いてはいけないパターン
「Scalaを使った開発経験がある方」(何をどう使っているかが伝わらない)
「関数型プログラミングに興味がある方歓迎」(やる気より実力を見てほしい層には刺さらない)
Java求人と同じフォーマットでScalaだけ差し替えた求人(技術への本気度が疑われる)
スカウト戦略——潜在層のScalaエンジニアにアプローチする方法
Scalaエンジニアの多くは顕在的な求職者ではなく、現職に満足しながらも「より面白い技術課題があれば動く」という潜在層です。パッシブ候補者へのアプローチ方法を参考に、Scala特有の戦略を組み合わせます。
効果的なスカウト媒体
Forkwell Jobs
技術スタックで候補者を絞り込めるため、Scalaで検索して実務経験者を探しやすい媒体です。GitHubポートフォリオと連携している候補者が多く、コードレビューの前段として候補者のアウトプットを事前に確認できます。Scalaの週次送付枠(20通)を有効活用するため、文面をパーソナライズして候補者のポートフォリオや登壇実績に触れることが返信率向上の鍵です。
Findy(Findy Code)
GitHubの活動量からスキル偏差値を算出するため、Scalaのコミット量・OSSコントリビューションが多いエンジニアを効率よく発見できます。
LAPRAS
ScalaのOSS活動やQiita・はてなブックマークでのアウトプットを持つエンジニアが集まっており、関数型プログラミングに深く関心を持つ候補者にリーチしやすい媒体です。
スカウト文面のポイント
スカウト採用を支援してきた経験から、Scalaエンジニアへのスカウトで返信率が高いパターンを挙げます。
返信率が高い文面の要素
候補者の具体的なアウトプットへの言及: 「あなたのXXというOSSプロジェクトのZIOを使ったエラーハンドリングの設計に興味を持ちました」
自社のScalaへの向き合い方の具体性: 「弊社ではScala 3とZIO 2を使ったマイクロサービス基盤を構築しており、チームで週次のScalaコードレビューセッションを実施しています」
技術的な挑戦の明示: 「現在、分散トランザクションの型安全なDSL設計という課題に取り組んでおり、そのアーキテクチャ設計をリードする方を探しています」
避けるべき文面パターン
「Scala経験をお持ちとのことでご連絡しました」(候補者全員に送っている印象)
「いかがでしょうか?」で終わる曖昧な締め
年収・条件を最初から押し出すアプローチ(エンジニアは技術的な文脈で判断する)
コミュニティへのアプローチ
Scala Matsuri(国内最大のScalaカンファレンス)やScala勉強会へのスポンサー参加は、Scalaコミュニティへのシグナルとして有効です。スポンサー企業には「本気でScalaをやっている」印象が生まれ、採用ブランディングにつながります。
採用支援の実務経験から言うと、コミュニティへの接点を持たずにスカウトだけで採用しようとすると返信率が下がりやすく、「この会社はScalaを使ってはいるが、コミュニティに関心がない」という印象を与えるリスクがあります。
選考プロセスの設計——Scalaエンジニアの技術力を見極める方法
Scalaエンジニアの選考設計で最も難しいのは、「Scalaを書いたことがある」と「Scalaで良い設計ができる」を区別することです。
推奨する選考フロー
ステップ | 内容 | 所要時間 |
カジュアル面談 | 技術的な関心・現在の課題感の確認 | 30〜45分 |
コーディングテスト | 実務想定の課題(Scalaで解く) | 2〜3時間(自宅課題) |
技術面接 | コードレビュー+設計議論 | 60〜90分 |
カルチャー面接 | 働き方・価値観の確認 | 45〜60分 |
オファー面談 | 条件提示・疑問解消 | 30〜45分 |
コーディングテストの設計
Scala特有の「テストしやすい課題」の例:
パターン1:データ変換課題
Either/Optionの活用、パターンマッチングの使い方、イミュータブルなデータ変換のスタイルが自然に現れる課題設計です。
パターン2:ドメインモデル設計課題
シールドトレイトとケースクラスを使ったAlgebraic Data Type(ADT)の設計力、コンパニオンオブジェクトのファクトリメソッドの使い方が評価できます。
技術面接での質問例
言語理解の確認
「
OptionとTryの使い分けの基準を教えてください」「
for内包表記がflatMapの糖衣構文であることを、モナドの観点から説明してください」「暗黙引数(
implicit/given)はどのような場面で使うべきか、乱用を防ぐための判断基準はありますか」
設計・アーキテクチャの確認
「型クラスパターンを使うべき場面と、継承を使うべき場面をどう判断しますか」
「副作用をどのように型レベルで扱いますか。ZIOやCatsを使った経験があれば教えてください」
「Scala 2からScala 3への移行で変わった主要な点と、それがコードの書き方に与える影響を教えてください」
実務経験の深掘り
「これまでのScalaプロジェクトで、型システムによって実際にバグを早期発見できた事例を教えてください」
「sbtのビルド定義の複雑化を経験したことはありますか。どう整理しましたか」
Scalaの「経験レベル」を判断するポイント
スカウト採用や選考の現場で感じる、Scalaエンジニアのレベル判断の指標を挙げます。
入門レベル: varとミュータブルなデータ構造を多用。Optionは使えるがflatMapの連鎖よりもif-elseを好む。
中級レベル: valとイミュータブルなコレクション操作を基本とする。for内包表記でモナドを自然に扱える。型推論を活かした簡潔なコードが書ける。
上級レベル: 型クラスパターン・高階型・型レベル計算を意識した設計ができる。ZIOやCatsを使った関数型効果システムで副作用を型で管理できる。アーキテクチャ全体の型設計を通じてドメインルールをコンパイル時に保証できる。
口説き方——Scalaエンジニアが転職を決める動機と交渉術
Scalaエンジニアは市場価値が高く、内定を出せても他社とのオファー競合になるケースが多い領域です。シニアエンジニアの口説き方の基本に加えて、Scala特有の動機に刺さるアプローチが求められます。
Scalaエンジニアが転職で重視するポイント
採用コンサル営業時代からエンジニアの転職相談に立ち会ってきた経験から言うと、Scala使いのエンジニアが転職を検討する際の判断基準は、以下の順序で重要になります。
技術的な深さ・課題の面白さ: 「Scalaの表現力を活かせる技術的に骨太な問題があるか」
チームのレベル: 「一緒に働くエンジニアのScalaへの理解が深いか」
学習環境: 「関数型プログラミングを深められるか、カンファレンス参加を支援しているか」
報酬: 市場相場とのギャップが大きければ動かないが、技術的魅力があれば多少の差は受け入れる傾向
口説きの鉄則
技術課題でまず引き込む
カジュアル面談では年収・条件より先に、「今こういう技術的課題があって、Scalaでこう解こうとしている」という話を先にしましょう。候補者のScalaエンジニアとしての技術的好奇心に火をつけるのが先決です。
チームのScalaへの向き合い方を見せる
面接には必ずScalaをしっかり書けるエンジニアが同席し、技術的な対話ができる場を設定します。「面接官がScalaを理解していない」という印象を与えると、候補者の意欲は大きく下がります。
コードベースのツアーを実施する
最終面接前後に、実際のScalaのコードを見てもらうセッションを設けることが有効です。「こういうアーキテクチャで設計している」「この部分の型設計について議論したい」という形で、入社後のイメージと技術的な共鳴を生み出します。
カウンターオファー対策
Scalaを使いこなすエンジニアは現職での希少価値が高く、入社直前のカウンターオファー(引き止め)が起きやすい職種です。カウンターオファー対策の詳細を参考に、以下の点を選考中から積み上げておきましょう。
現職では解決できない技術課題の明示(「現職のJava環境ではできないが、うちのScala基盤なら実現できる」)
入社後の具体的なロードマップの共有(最初の3か月で関わるプロジェクト・技術的な意思決定への関与度合い)
オファー確定後の密な連絡(入社前研修・Slack招待・チームメンバーとの事前ミートアップ)
年収・報酬設計——Scalaエンジニアの市場相場と条件設計
年収相場(2026年市場)
Scalaエンジニアは関数型・型安全設計の専門性から、同等の経験年数のJavaエンジニアより15〜25%程度高い年収レンジが相場です。
経験・スキルレベル | 年収レンジ |
Scalaコンバート・1年未満 | 500〜650万円 |
Scala実務2〜3年・中級 | 600〜850万円 |
Scala実務4年以上・上級 | 900〜1,200万円 |
Spark/Akkaスペシャリスト・アーキテクト | 1,100〜1,500万円 |
上記はあくまで参考値です。金融・フィンテック系ではさらに上振れするケースがあります。
報酬以外の条件設計
Scalaエンジニアに刺さる福利厚生・条件の例:
技術書購入補助(関数型プログラミング・型理論の書籍)
カンファレンス参加支援(Scala Matsuri、ScalaDays参加費・交通費負担)
業務時間内の勉強会・OSSコントリビューション時間の確保
Scala 3への移行プロジェクトへの関与機会
金銭的な訴求より「Scalaを深める環境があること」を前面に出した条件設計が、上位層には響きます。
FAQ(よくある質問)
Q1. Scala経験がない場合、採用をあきらめるべきですか?
あきらめる必要はありません。Java・Kotlin・Haskell・F#など、JVMや関数型の素養があるエンジニアは、Scalaの本質的な設計思想を比較的早く習得できます。「Scala経験不問、ただしJavaで3年以上の開発経験+関数型プログラミングへの関心」という要件設定でコンバート採用を前提にするのが現実的です。入社後3〜6か月の学習支援プログラムを設けると、長期定着にもつながります。
Q2. Scala 2とScala 3、どちらを要件にすべきですか?
新規プロジェクトならScala 3が推奨ですが、採用要件としては「Scalaのバージョンを問わず、言語の本質(型システム・関数型設計)を理解しているか」で判断する方が得策です。Scala 2の経験者はScala 3へのキャッチアップが比較的短期間でできます。バージョンに固執すると母集団が不必要に縮小します。
Q3. Apache Spark担当として採用したい。Scala以外の選択肢はありますか?
Apache SparkはPython(PySpark)でも利用できます。高度なチューニングや独自Sparkエクステンションの実装はScalaが有利ですが、データアナリストやデータサイエンティストがPySparkで始め、パフォーマンスが問題になったフェーズでScalaエンジニアを採用する段階的なアプローチも有効です。
Q4. Scalaエンジニアはどのスカウトサービスで探すのが効率的ですか?
Forkwell Jobs(技術スタックで検索可能)、Findy(GitHubのScalaコミット量で探せる)、LAPRASの3つを優先して使うのが現実的です。ただし、それぞれ週次の送付上限があるため、文面のパーソナライズと、候補者のアウトプット(OSS・登壇・技術ブログ)への具体的な言及を徹底することが返信率を左右します。
Q5. Scalaエンジニアの選考で、技術力の見極めに自信がない場合はどうすればよいですか?
社内にScalaの実力者がいない場合は、技術顧問やフリーランスのScalaエンジニアに面接に参加してもらう方法が有効です。技術顧問の活用方法も参考にしてください。スキルチェックシートのひな型を専門家に依頼して作成しておくと、選考の一貫性が保てます。
Q6. ZIOやCatsなどの関数型ライブラリの使用経験を必須にすべきですか?
採用難易度が大幅に上がるため、「使用経験必須」にするのは慎重に検討しましょう。「使ったことはないが、モナドとFunctorの概念を理解している」という候補者であれば、実務での習得は十分可能です。会社がZIO中心の開発をしているならZIOの理解度を確認することは合理的ですが、経験の有無より概念を理解しているか・自走で学べるかを見る方が採用の幅が広がります。
Q7. Scalaエンジニアの内定辞退を防ぐには?
内定後の密な関係構築が重要です。具体的には、内定通知から入社まで2週間以上ある場合は、チームメンバーとの非公式ランチや技術的な課題についての議論セッションを設けることが有効です。「入社したら最初に取り組む技術的なチャレンジ」を具体的に伝えておくと、候補者の期待値とモチベーションが維持されます。
Q8. 社内のJavaコードベースをScalaに移行したい場合、採用の進め方は?
まずScalaの技術的方向性を決めるテックリード・アーキテクト1名の採用を優先します。この1名がJavaからScalaへの移行方針を設計し、社内のJavaエンジニアのScala化を主導する形が現実的です。最初から複数名のScalaエンジニアを採用しようとすると、採用難易度が倍加します。
まとめ——Scalaエンジニア採用の次の一手
Scalaエンジニアの採用は、GoやPythonなど人気言語と比べて難易度が高いのは事実です。しかし「Scala経験必須」の要件に固執せず、Javaや関数型言語の素養を持つエンジニアをコンバート採用する戦略と、候補者のアウトプットに基づいたパーソナライズスカウトを組み合わせることで、採用の可能性は大きく広がります。
採用成功のポイントを整理すると:
要件の柔軟化: Scala経験必須から「Java+関数型への関心」に変更し、入社後の学習支援をセットにする
スカウトの質の向上: 候補者のOSS・登壇・ブログに具体的に触れた文面を作成する
採用ブランディング: Scala MatsurIへのスポンサー参加・テックブログでのScala記事発信
選考での技術対話: Scalaを理解する面接官の確保と、コードレビュー形式の技術面接の実施
口説きの差別化: 技術的な課題の面白さ・チームの質・学習環境を前面に出したアプローチ
まず着手できることとして、スカウトメールの書き方を見直し、Scala候補者向けのパーソナライズテンプレートを作成してみてください。
採用に困ったときは、techcellarのスカウト運用代行・採用コンサルティングサービスをお気軽にご相談ください。Forkwell・Findy・LAPRASを活用したScalaエンジニア採用の実績をもとに、貴社の採用課題を一緒に解決します。
エンジニア採用の打ち手、
エンジニアと一緒に整理しませんか?
techcellarは、採用に詳しいエンジニア自身が貴社の採用チームに伴走するサービスです。 スカウト文面の改善、技術面接の設計、ペルソナ設計、媒体選定まで、実務目線でアドバイスします。
- ✓相談は無料・所要30分
- ✓会社規模・フェーズに合わせた提案
- ✓エンジニアが直接対応
お問い合わせフォームへ遷移します
現役エンジニアでありながら、スタートアップのエンジニア採用支援を行う。採用コンサル営業として採用を売る側の経験と、エンジニアとして採用される側の経験を併せ持つ。13以上のダイレクトスカウトサービスの運用経験をもとに、AI×採用の実践ノウハウを発信。
採用のお悩み、
エンジニアに相談
しませんか?