レガシー刷新エンジニアの採用は「経験者の直接採用」だけでは成立しません。モダン技術者と業務知識保有者を組み合わせるハイブリッド体制の設計と、AI活用を前提とした採用要件への書き換えが最短ルートです。

このページでわかること

• 2025年の崖の本質と、刷新プロジェクトに必要な人材の全体像

• COBOLや基幹系の経験者を採るのではなく「組み合わせ」で解く考え方

• リホスト・リライト・リビルドの方針別に必要な人材像が変わる理由

• 採用要件の作り方と、市場で取りに行ける現実的な候補者像

• スカウト文面・求人票・面接設計の実践ノウハウ

• 内製・外部委託・育成のハイブリッド戦略と費用感の目安

TL;DR（この記事の要約）

• 2025年の崖を超えるための刷新人材は完全な「即戦力経験者」を狙うと採れない。新旧技術の橋渡しができるチームを設計するのが現実解

• COBOL・メインフレーム経験者は減少が続く構造のため、業務知識保有者×モダン開発者×ベンダー人材の3層構成が定石

• リホスト・リライト・リビルドのどれを選ぶかで必要人材は大きく変わる。方針未決のまま採用要件を作ると確実にミスマッチになる

• 採用市場では**「レガシーシステム刷新経験」を持つPM・アーキテクトが最も希少**。年収レンジは1000万〜1500万円帯で動いている

• AI活用（生成AIによるコード解析・移行支援）を前提に求める人材像を再定義することで、母集団を一気に広げられる

1. 2025年の崖と、刷新プロジェクト人材の現在地

2025年の崖は「過ぎ去った」のではなく「進行中」

経済産業省が2018年の「DXレポート」で警告した2025年の崖は、年間最大12兆円の経済損失を懸念する内容でした。21年以上稼働するレガシー基幹システムが大企業の約6割を占めるという推計が出され、その後も多くの企業が刷新に着手しています。

出典: 経済産業省「DXレポート」

しかし2026年の現時点で見ると、崖の問題は「克服された」のではなく、刷新プロジェクトが本格化したことで人材ニーズが顕在化した段階に入っています。レガシーマイグレーション・モダナイゼーション市場は2023年度の約3480億円から2025年度には約5118億円まで拡大しており、刷新案件が爆発的に増えています。

出典: @IT「COBOL人材がいない、基幹システムのレガシー継承に向けた模索」

つまり「2025年の崖を越える」とは、いま現在進行中の刷新プロジェクトを完遂できる人材を、どう確保するかという問題です。

採用市場で起きている3つの構造変化

筆者がスカウト運用や採用設計を支援してきた中で、レガシー刷新案件の人材ニーズには次の3つの構造変化が起きています。

1. COBOL・メインフレーム経験者の絶対数が減り続けている

COBOL技術者は2025年以降、毎年約3000人規模で減少すると予測されています。職務経歴書で「COBOL実務経験あり」と書ける人材は50代以上が中心で、20代〜30代前半でCOBOLを書いてきた人材はほぼ採用市場に出てきません。

2. モダン開発者は刷新案件を敬遠しがち

React/TypeScript・Go・Pythonなどモダンな技術スタックで仕事をしてきたエンジニアは、「レガシー刷新」という案件名を聞いた瞬間にスカウト返信を渋ります。「旧システムの調査ばかりで、自分の技術スタックが伸びない」という不安が大きいためです。

3. PM・アーキテクト層の枯渇が深刻

エンジニア個人よりも、刷新プロジェクト全体を設計できるPM・エンタープライズアーキテクトが圧倒的に足りていません。複数のSIerでメインフレームと現代クラウドの両方を経験したシニア層は、市場でほぼ取り合いになっています。

「経験者ピンポイント採用」が最も失敗する

採用担当者・経営者の方から多い相談が「COBOL経験者が欲しい」「メインフレーム移行経験者をピンポイントで採りたい」というものです。気持ちは分かりますが、この方針で母集団が確保できる確率は極めて低いと考えてください。

採用支援の実務で見てきた範囲では、レガシー刷新案件で成果を出している企業は、ほぼ例外なく人材像を「単体スキル」ではなく「チーム構成」として定義しています。次のセクションで、その考え方を詳しく見ていきます。

2. 刷新プロジェクトに必要な「3層人材構成」

業務知識・モダン技術・ベンダーマネジメントの3層で組む

レガシー刷新プロジェクトに必要な人材は、機能別に分けると次の3層で構成されます。1人ですべてを兼ねる「スーパーマン」を採るのではなく、各層を別々に確保するのが現実解です。

第1層: 業務知識保有者（既存システムを読み解く役割）

• 既存システムの仕様・業務ロジックを理解している

• COBOL・PL/I・RPGなど旧言語が読める

• 自社社員・社内エンジニア・既存ベンダーから抽出するのが基本

• 採用市場で取りに行く対象ではなく社内人材の「役割定義」が中心

第2層: モダン技術アーキテクト（新システムを設計する役割）

• AWS・Azure・GCPなどクラウドアーキテクチャに精通

• マイクロサービス・API設計・データ移行戦略を組める

• Java・Goなど新システムで採用する言語の実装力もある

• 採用市場で最も取り合いになっている層

第3層: ベンダー・パートナーマネジメント担当（外部リソースを束ねる役割）

• SIer・オフショア・フリーランスと品質・進捗を管理できる

• RFP作成・契約管理・受入テスト設計ができる

• 自社のPMO・社内SE経験者が担うことが多い

3層をすべて自社正社員で揃える必要はありません。第1層は社内、第2層は採用、第3層は委託、という割り当ても十分成立します。重要なのは「自社で持つ層」と「外部から借りる層」を明確に分けて採用要件を作ることです。

各層に必要なスキルマトリクス（例）

実際の採用要件作成で使いやすいよう、職種別のスキルマトリクスを示します。

業務知識保有者（社内発掘・育成中心）

モダン技術アーキテクト（採用中心）

ベンダーマネジメント担当（社内人材活用）

スキルマトリクスを作る際の注意点は、「あったら嬉しい」を必須に入れないことです。レガシー刷新のような特殊案件は「全部できる人」を要件に並べると、母集団がゼロになります。

3. 方針（リホスト・リライト・リビルド）で人材像は変わる

方針未決のまま採用要件を作ると確実に失敗する

レガシー刷新の方針は大きく3つに分けられます。どれを選ぶかで必要人材像が大きく変わるため、採用要件の前に方針決定を済ませるのが鉄則です。

リホスト（Re-host）: ハードウェアだけ載せ替える

メインフレームのCOBOLプログラムをそのまま、x86サーバーやクラウド上で動かす方式です。プログラム自体は基本的に変更しません。

• 必要人材: メインフレーム→クラウド移行経験者、COBOL読解者

• 期間: 6か月〜1.5年

• リスク: 低（プログラムが動かないリスクは小さい）

• 人材確保難易度: 中

リライト（Re-write）: 言語を書き換える

COBOLのプログラム構造を残しつつ、JavaやC#などのモダン言語に変換する方式です。生成AIによる自動変換ツールも実用化が進んでいます。

• 必要人材: 旧言語読解者＋モダン言語実装者の組み合わせ

• 期間: 1〜3年

• リスク: 中（変換後の業務ロジック検証が必要）

• 人材確保難易度: 中〜高

リビルド（Re-build）: 業務要件から作り直す

業務プロセスごと再設計し、現代的なシステムをゼロから構築する方式です。SaaS活用・パッケージ導入もこの方式に含まれます。

• 必要人材: 業務再設計コンサル＋クラウドアーキテクト＋PM

• 期間: 2〜5年

• リスク: 高（プロジェクトの長期化・コスト超過）

• 人材確保難易度: 高

出典: 株式会社renue「レガシーモダナイゼーションとは？」

方針別の採用優先度

採用市場の実情からすると、優先度の高い職種は方針によって次のように変わります。

リホストを選ぶ場合

最も優先すべきはメインフレーム→クラウド移行の経験者、次いで既存システムを読み解ける社内SE出身者です。新規プロダクト系のモダンエンジニアは無理に採らないのが正解。リホストでは新言語実装よりも、移行段階でのトラブル対応力が重要だからです。

リライトを選ぶ場合

業務ロジック解析者と、Java・C#などの実装エンジニアを2層で揃えます。生成AIによる変換ツールを使う前提なら、**「AIが出した変換結果をレビュー・修正できる人」**が新たな採用ターゲットになります。これは比較的若手でも対応可能で、母集団を広げやすいポジションです。

リビルドを選ぶ場合

業務プロセス再設計ができるコンサル系人材、クラウドアーキテクト、PMの3職種が要となります。社内SE出身者は業務知識の橋渡し役として残し、技術設計は新規採用＋外部委託で組むのが定石です。

方針が決まっていない段階で求人を出すと、「全部できる人」を要件にしてしまい、結果として誰も応募してこない求人になります。経営層を巻き込んで方針を確定してから、求人票の作成に進む順番を守ってください。

4. 採用要件の作り方——「採れる要件」へのリフレーミング

よくある「採れない要件」のパターン

採用担当者・経営者の方から見せていただく求人票で、典型的な「採れない要件」は次の通りです。

• COBOL実務経験10年以上 + クラウドアーキテクチャ設計経験 + 業務知識

• 大規模基幹システム移行PM経験 + 英語ビジネスレベル + 30代まで

• メインフレーム保守経験 + Kubernetes・Terraform実装スキル

これらの要件は、市場に存在する人材像と乖離しています。3つすべてを満たす人は数えるほどしかおらず、その層は既に大手SIerや事業会社のCTO候補として確保されています。

「採れる要件」へのリフレーミング3ステップ

ステップ1: 必須要件を「絶対に外せない1つ」に絞る

3層人材構成のうち、いま採用枠で本当に取りたい層を1つに絞ります。例えば「モダン技術アーキテクト」を取るなら、業務知識は社内人材で補完する前提で、AWS設計力だけを必須要件にする。

ステップ2: 経験年数ではなく「成果物・思考プロセス」で書く

「COBOL実務10年」ではなく「業務ロジックが書かれた仕様書を読んで、データフロー図を起こせる」と書く。「何ができれば良いか」を成果ベースで定義することで、職務経歴書の表面的なキーワードに引きずられない採用ができます。

ステップ3: 育成余地を要件に組み込む

「クラウド経験は入社後3か月で習得することを期待」のような書き方で、入社時点での要件を緩和します。レガシー刷新案件は数年スパンのため、入社時に全スキルを持っている必要はありません。

スカウト・人材紹介で実際に届く候補者像

採用要件を緩和することで、実際にアプローチ可能な候補者像は次のように広がります。

• 大手SIerでメインフレーム保守を担当してきた30代後半〜40代の中堅エンジニア

• 事業会社の社内SEで、自社の基幹システム刷新を経験した30〜40代

• フリーランスでレガシー移行PMOを請けてきた、正社員復帰を検討中の40代

• 外資系コンサルから事業会社への転職を希望する、テックリード候補

特に**「フリーランス→正社員復帰」希望者は隠れた優良層**です。レガシー刷新案件をフリーランスで複数経験しており、業務知識と技術力の両方を持っているケースが多いです。ただし年収レンジは1000万〜1500万円帯になるため、報酬テーブルの調整は必要です。

社内に経験豊富なエンジニアがいない場合は、エンジニア採用支援のプロに採用要件の設計から相談するのも選択肢です。techcellarのスカウト運用代行サービスでは、要件定義段階からエンジニア視点で支援しています。

5. 求人票・スカウト文面の設計

求人票で必ず触れるべき4要素

レガシー刷新案件の求人票で、応募率を高めるために必ず触れるべき要素は4つです。

1. プロジェクトのゴールと社会的意義

「老朽化システムの保守を引き継ぐ」ではなく、「3000人の業務を変える基幹システム刷新を主導」のように、変革のインパクトを言語化します。エンジニアは「自分の仕事が何を変えるか」に強く反応します。

2. 採用後に使える技術スタックの明示

旧システムの保守だけでなく、新システム側でAWS・Java・Kubernetesなど何を使うのかを具体的に書きます。モダンな技術に触れられることが分かるだけで、応募率は明確に上がります。

3. AI活用の方針

生成AIによるコード解析・移行支援を採用しているか、Copilotなどの開発支援ツールを導入しているかを書きます。AI活用前提の現場かどうかは、若手〜中堅エンジニアにとって大きな判断材料です。

4. プロジェクト期間と、その後のキャリアパス

「3年プロジェクト後は社内DXの中核を担う」など、刷新プロジェクト終了後のキャリアパスを示します。これがないと「終わったら居場所がなくなる」と懸念されます。

スカウト文面の3パターン

レガシー刷新案件向けスカウトでは、候補者層によって訴求軸を変えます。筆者がスカウト運用代行で実際に使い分けている3パターンは次の通りです。

パターンA: 大手SIer出身の中堅向け

「メインフレーム移行を複数経験されていますが、上流から関わりたいフェーズではありませんか。当社では3000人規模の基幹システム刷新の意思決定権をお任せします」

→ 上流志向への移行・裁量権を訴求。受託の限界感に共鳴する候補者に届きます。

パターンB: モダン開発者向け

「フロントエンドのご経験を、当社の基幹システム刷新後の新規プロダクト開発で活かしませんか。レガシー刷新と並行して、新規SaaS開発も始まります」

→ 刷新だけが仕事ではないことを明示。モダン領域でのキャリアが続くことを保証。

パターンC: フリーランス→正社員復帰検討者向け

「フリーランスとして複数の刷新案件を経験されていますが、長期で1社の変革にコミットしたいフェーズではありませんか。年収レンジ1200〜1500万円で、3年の業務委託契約からの正社員転換も可能です」

→ 安定志向への戻り・長期コミットへの希求に応える。報酬と契約形態の選択肢を提示。

スカウト文面の設計では、**「相手の人生フェーズを理解しているメッセージ」**が返信率を大きく左右します。テンプレートをそのまま流用するのではなく、職務経歴の文面から相手の状態を読み取ることが鍵です。

6. 選考プロセスと見極めポイント

推奨選考フロー

レガシー刷新案件の選考は、技術力単体ではなく業務理解力・ステークホルダー調整力・新旧技術の橋渡し能力を見極める必要があります。推奨選考フローは次の通りです。

第1段階: カジュアル面談（30〜45分）

• プロジェクト全体像と候補者のキャリア志向のすり合わせ

• 旧技術領域でやり切りたいのか、モダン領域へ移りたいのかを確認

• 採用後のキャリアパスを率直に提示

第2段階: 技術面接（60〜90分）

• 過去の刷新プロジェクトの経験を構造的にヒアリング

• 業務ロジックを読み解いた具体的なエピソードを聞く

• 想定するアーキテクチャ設計の素案を口頭で議論

第3段階: 現場メンバーとのパネル面談（60分）

• 既存システムを担当している社内SEとの相性を確認

• 「業務知識保有者」と「モダン技術者」が協働できるかを見る

• 技術的な議論よりも、コミュニケーションスタイルの相性を重視

第4段階: 役員面談・オファー面談（60分）

• 経営層から刷新プロジェクトの本気度を伝える

• 候補者の長期キャリアと会社のロードマップをすり合わせ

• 報酬・契約形態の最終確認

技術面接で聞くべき5つの質問

レガシー刷新の経験者かどうかを見極めるためのコア質問は5つです。これらに対する回答の「具体性」が、実務経験の深さを測る指標になります。

質問1: 過去最も難航したレガシー刷新プロジェクトを教えてください

→ プロジェクト規模・期間・自分の役割・失敗ポイントを具体的に語れるか

質問2: 旧システムの仕様書がない状況で、業務ロジックをどう抽出しましたか

→ ソースコード解析・現場ヒアリング・データ分析の組み合わせを語れるか

質問3: 移行段階でデータ整合性が崩れた経験はありますか

→ 並行稼働期間の設計・差分検証ツールの使い方を具体的に語れるか

質問4: 既存ベンダーと衝突した経験と、どう乗り越えたかを教えてください

→ 政治的な配慮・契約条件の交渉・代替案の提示を語れるか

質問5: AI活用（コード解析・自動変換）を使った経験はありますか

→ ツール名・出力の検証方法・失敗パターンを具体的に語れるか

質問5でAI活用経験を必ず聞くのが、2026年現時点での重要ポイントです。生成AIによる移行支援は急速に実用化が進んでおり、AI活用経験の有無で生産性が2倍以上変わります。

カルチャーフィット評価のポイント

刷新プロジェクトは社内政治・既存ベンダーとの関係性・経営層への説明責任が複雑に絡みます。次の3観点をパネル面談で確認してください。

• 既存システム担当者へのリスペクトがあるか: 「古いコードを書いた人を見下す」タイプは現場が崩壊します

• 長期コミットへの覚悟があるか: 3〜5年スパンの仕事に耐えられるか

• 経営層への説明力があるか: 技術用語を経営判断材料に翻訳できるか

7. 内製・委託・育成のハイブリッド戦略

「全部内製」「全部委託」のどちらも失敗する

レガシー刷新で最も多い失敗パターンが、極端な内製化または極端な委託化です。

• 全部内製: 採用に2〜3年かかり、プロジェクト開始が遅れる

• 全部委託: ベンダーロックインで保守費用が膨張、ナレッジが社内に残らない

成功している企業は、ほぼ例外なく**3層人材構成に対応した「役割別の調達方針」**を持っています。

推奨ハイブリッド構成（中堅規模・3年プロジェクトの場合）

費用感はあくまで目安です。実際にはプロジェクト規模・難易度・地域により大きく変動しますが、全体予算のうち人件費・委託費が占める比率の感覚値として参考にしてください。

社内育成の戦略

レガシー刷新を契機に、社内エンジニアの育成プログラムを並行して走らせる企業が増えています。トヨタシステムズが2025年10月に設立した「レガシーコードラボ」は、次世代人材が生成AIツールを活用して基幹システム開発に取り組む取り組みとして注目されています。

出典: @IT「COBOL人材がいない、基幹システムのレガシー継承に向けた模索」

社内育成では、次の3つの軸で設計するのが効果的です。

• 新卒〜若手をレガシー＋モダンの両刀使いに育成: 生成AIの活用前提なら、若手でも刷新案件の戦力になります

• 既存社内SEのリスキリング: 業務知識を持つ既存社員にクラウド研修を提供

• ベンダー出身者の正社員転換: 既存ベンダーの優秀メンバーを引き抜き、社内知見として残す

非IT企業でのDX人材確保について体系的に学びたい方は非IT企業がエンジニア採用を成功させるDX人材獲得の実践ガイドも参考にしてください。

8. 失敗パターンと回避策

採用支援の現場で見てきた、レガシー刷新人材採用の典型的な失敗パターンを5つ紹介します。

失敗1: 「全部できるスーパーマン」を要件にする

業務知識・モダン技術・PM力をすべて要件に書き、結果として誰も応募してこない求人になるパターンです。

回避策: 3層人材構成を採用要件の前に整理し、1求人=1層に絞ること。

失敗2: 経験者の年収を市場相場以下で設定する

レガシー刷新経験を持つPM・アーキテクト層は年収1200〜1500万円帯で動いています。既存社員との公平性を理由に800〜900万円で求人を出すと、書類応募はゼロに近くなります。

回避策: 刷新プロジェクト限定の特別報酬テーブルを設定する。プロジェクト終了後の処遇も事前に設計しておくこと。

失敗3: モダン開発者にレガシー保守を任せる前提で採用する

「最新技術が学べる」と訴求しておいて、入社後はレガシーシステムのバグ対応ばかりさせるパターンです。当然早期離職に直結します。

回避策: 求人票・面接段階で「最初の半年は何をするか」を率直に伝える。期待値ギャップを生まない設計が定着率を決めます。

失敗4: 既存ベンダーとの関係を無視した採用

新規採用したアーキテクトが、長年保守を担当してきたベンダーと衝突し、プロジェクトが空中分解するパターンです。

回避策: 採用面接時に「既存ベンダーとの協働経験」を必ず確認する。既存ベンダーの担当者を社内化することも選択肢の1つです。

失敗5: 採用だけで解決しようとして時間切れになる

数十名規模の刷新プロジェクトを「全員採用で揃える」前提で動くと、人材確保に2〜3年かかり、刷新自体の着手が遅れます。

回避策: 採用・委託・育成のハイブリッド戦略を最初から設計し、各層の調達タイムラインを並行で動かす。

9. プロジェクト期間別の採用ロードマップ

レガシー刷新プロジェクトの期間別に、採用の進め方を整理します。

フェーズ1: プロジェクト立ち上げ前（3〜6か月）

• 経営層との方針合意（リホスト・リライト・リビルドの選択）

• 既存システム調査チームの編成（社内人材＋一部外部委託）

• PM候補1名の採用着手

フェーズ2: プロジェクト初期（6〜12か月）

• アーキテクト2〜3名の採用

• 業務知識保有者の社内発掘・契約条件の整理

• 大手SIerとの基本契約・PMO体制の構築

フェーズ3: 実装期（1〜3年）

• 実装エンジニアの業務委託・SES確保

• 並行して若手社員のリスキリング開始

• AI活用ツールの導入・運用ノウハウ蓄積

フェーズ4: 移行・運用移管期（最終6か月）

• 並行稼働運用チームの編成

• 旧システム停止判断のための業務確認

• 新システム運用引き継ぎ担当者の社内固定

フェーズ5: プロジェクト終了後

• アーキテクト・PMの次のDX案件への配置

• 業務委託メンバーの一部正社員転換オファー

• ナレッジドキュメントの社内資産化

採用ロードマップを引く際は、プロジェクト全体の人員ピークと、その前段階での採用着手時期を逆算することが重要です。実装期に「実装エンジニアが足りない」と気づいてから採用を始めても、間に合いません。

FAQ（よくある質問）

Q1: COBOL経験者が本当に必要ですか？

すべてのプロジェクトで必須ではありません。リホスト方式ならCOBOLプログラムを変更しないので、保守経験者で十分です。リライト方式では生成AIによる変換ツールが進化しているため、COBOL読解者と新言語実装者の2層構成で対応可能です。リビルド方式なら、業務要件さえ抽出できればCOBOL経験は不要になります。

Q2: 60代以上のベテラン採用は現実的ですか？

現実的です。FPTジャパンホールディングスは60歳以上の人材を含めたメインフレーム経験者の採用を積極的に進めており、2024年に新たに1000人以上を育成し、3500人以上の規模を目指しています。

出典: @IT「COBOL人材がいない」

60代以上の活用は、業務委託契約・週3〜4日勤務など柔軟な働き方を提示することで成立します。長期雇用ではなくプロジェクト期間限定の知見継承役として位置づけるのが定石です。

Q3: 生成AIによるコード移行はどこまで使えますか？

業務ロジックの一次変換・コード解析・ドキュメント生成は実用域に入っています。ただし生成AIの出力は100%の正確性を保証するものではないため、必ず人間によるレビューと業務テストが必要です。AI出力をレビュー・修正できるエンジニアの確保がボトルネックになります。

Q4: 採用予算が限られています。優先順位は？

3層のうち第2層（モダン技術アーキテクト）を最優先で正社員採用します。アーキテクトが決まれば、第3層（実装エンジニア）は業務委託で柔軟に調達でき、第1層（業務知識保有者）も社内で巻き込みやすくなります。アーキテクト不在で実装人員だけを増やすと、設計品質が崩れて手戻りが膨大になります。

Q5: 採用に苦戦しています。今すぐできる打ち手は？

3つの打ち手を試してみてください。1つ目は求人票の必須要件を1つに絞ること。2つ目はスカウト文面で「相手の人生フェーズ」に踏み込んだメッセージに書き換えること。3つ目はフリーランス→正社員復帰希望層に焦点を当てることです。techcellarのスカウト運用代行サービスでは、レガシー刷新案件のような難易度の高い採用も支援しています。

Q6: 既存ベンダーとの関係を維持しつつ自社採用を進めるには？

「役割分担の明示」と「ベンダー担当者のキャリアパス提示」がポイントです。新規採用したアーキテクトの役割を「全体方針決定・進捗管理」とし、ベンダーの役割を「実装・保守」と明確に切り分けます。さらに、ベンダーの優秀メンバーには自社への正社員転換オプションを提示することで、ベンダー側も協力的になります。

まとめ：レガシー刷新の採用は「組み合わせ設計」で勝つ

2025年の崖を越えるためのレガシー刷新人材採用は、経験者の単体採用ではなく、業務知識・モダン技術・ベンダーマネジメントの3層を組み合わせる設計勝負です。

採用要件を緩和し、母集団を広げ、AI活用を前提に人材像を再定義することで、これまで「採れない」と諦めていた案件にも勝ち筋が見えてきます。

リホスト・リライト・リビルドのどの方針を選ぶかで人材像は変わります。方針決定→3層構成設計→採用要件作成→スカウト・選考設計の順番を守ることが、レガシー刷新の採用成功の王道です。

刷新プロジェクトの採用要件設計から、スカウト運用、内定承諾までの実務サポートが必要な方は、techcellarのエンジニア採用支援サービスにご相談ください。エンジニア視点と採用コンサル経験の両方から、難易度の高い採用案件を支援しています。