設計職の求人がないなら検証・PDへ？答えは「順番」にある

30秒サマリー

• 検証人員が設計人員を追い抜いた。Wilson Research Group 2022年調査基準、2007〜2022年のプロジェクトあたり平均投入人員の増加率は検証6.2%、設計2.7%。平均人員比は1:1、プロセッサ分野では検証：設計が5:1まで開く。
• 韓国の採用市場も熱い。JobKorea集計基準、2026年第3四半期の半導体大企業採用公告は前年比102%増。ただしキャリア組が157%、新卒は55%——新卒に開かれる門は思ったより狭い。
• 迂回は恒久化する。RTLインテントを読めない検証エンジニアは「設計できないものを検証」し、RTLを読めないPDエンジニアは「読めないものを実装」する。一度付いたタイトルは次の転職でもあなたについて回る。
• 年収ファクト（韓国）。半導体エンジニアの平均base約8,296万ウォン、1〜3年目約5,854万ウォン、8年目以上約9,564万ウォン（ERI SalaryExpert、2026年）。大卒エンジニアの初任給はSKハイニックス約5,400万ウォン、DBハイテック4,800万〜5,300万ウォン水準とされる。
• 答えは順番だ。RTLを先に、次に検証、論理合成、PD、STA／サインオフの順で学べ。検証・PDで入社してもRTLから学んで前に進め。横に行かず、前に行け。

イントロ：最もよく受ける質問

読者の質問の中で、この質問が最もよく来る。

「RTL設計をやりたいのですが設計の求人枠が出ません。検証やPDで先に入って、後で設計に移ればいいでしょうか？」

正直に言おう。その迂回はほとんど恒久化する。検証で入った人は検証エンジニアのまま残り、PDで入った人はPDエンジニアのまま残る。意志が弱いからではない。構造がそうさせるのだ。

この記事はその構造をデータで示し、それでもこの道を歩く人のための答え——「順番」——を提示する。

なぜこの質問が繰り返されるのかも押さえておくべきだ。「設計の求人が見えない」という感覚は気のせいではなく構造の結果だ。RTL設計は本質的に少数精鋭の仕事だ。一人の設計者が書いたRTLを複数の検証エンジニアが検証するのが一般的なプロジェクトの姿で、Wilson調査で見た1:1〜5:1の人員比がまさにその証拠だ。国内のある進路リサーチ（2026年8月作成、実際の採用公告をクロスチェックした資料）でも、回路設計トラックのうち検証・DFTは新卒採用が「広い」に分類される一方、AI半導体ファブレスのエンジニア新卒採用は稀と整理されている。つまり、新卒が体感する「設計求人枠の失踪」は市場構造そのものだ。

本論

エピソード1. 採用市場が語るファクト：検証の求人が多いのは事実だ

まずファクトから。検証の求人が多いのは事実だ。それも圧倒的に。

Wilson Research GroupのFunctional Verification Study（2022年版）によると、2007年から2022年までIC/ASICプロジェクトあたり平均最大投入人員の年平均増加率（CAGR）は設計エンジニア2.7%、検証エンジニア6.2%だった。検証人員の増加速度は設計の2.3倍だ。今日のプロジェクトあたり平均人員比は検証：設計が約1:1で、プロセッサのような分野では5:1まで開く。（出典）

2020年版調査ではさらに直接的な数値が出る。設計エンジニアが業務時間の47%を検証関連の仕事に使う。設計をやっても検証から逃れられないということだ。逆説的に聞こえるかもしれないが、これは「検証に迂回してもいい」という根拠ではなく「設計者も検証を知るべきだ」という根拠だ。（出典）

韓国市場も熱い。JobKoreaの集計によると2026年第3四半期の半導体・ディスプレイ大企業採用公告は前年同期比102%増加した。今年第3四半期までの累計で半導体エンジニア公告は55%増えた。（出典）

ただ、もう一行読むべきだ。同じ調査でキャリア組公告は157%増えた一方、新卒公告は55%増にとどまった。AIメモリ需要が大きくなる中、企業が「すぐ投入できる人員」に重きを置いているという解釈だ。つまり、公告数は増えたが新卒に開かれる門の幅は思ったより狭い。「検証の求人枠が多いからひとまず入ろう」という戦略が通じるには、その門が新卒にも開いていなければならない。

もうひとつ数値を見よう。Wilson 2020年調査で検証エンジニアが最も多くの時間を使う活動は、ほかならぬデバッグだった。ところがデバッグとは結局「RTLがなぜこう動作するのか」を追跡する仕事だ。RTLを読めない検証エンジニアのデバッグは波形を見てテストベンチを直すところで終わり、RTLを読むエンジニアのデバッグは根本原因まで下りる。同じ「検証3年目」タイトルでもこの二人の市場価値は違う。この差はエピソード3のレバレッジの話につながる。

正直な開示ひとつ。「RTL設計 vs 検証 vs PDの正確な公告数値」はこの記事では提示しない。韓国の採用プラットフォーム（Saramin・JobKoreaなど）は職種別集計数値を公開しておらず、テキストで検証する方法がなかったからだ。上の数値はプロジェクト人員構造（Wilson）と全体採用動向（JobKorea）という検証可能なデータに基づく。職種別公告数の比較が必要ならプラットフォーム各社に直接問い合わせるか有料レポートを見るべきだ。

検証のオファーを受けたら、受諾前にこの3つを確認してみよう。第一に、このチームにRTL designレビュー文化があるか。検証エンジニアが設計レビューに参加するチームではRTLを学ばざるを得ない。第二に、テストベンチを書く以外にアサーション基盤の検証やフォーマルを使うか。手法が多様なチームほど学ぶことが多い。第三に、社内の職種転換制度が実際に機能しているか。「後で設計に移る」という計画は、その門が実際に開く会社でのみ計画になる。

エピソード2. 迂回が恒久化するメカニズム

求人が多いからといって迂回していいという意味ではない。迂回が恒久化するには3つのメカニズムがある。

第一に、検証はRTLインテントを読む仕事だ。

UVMテストベンチを書く技術自体は学べる。問題はその次だ。RTLインテント——設計者がこのコードをなぜこう書いたのか——を読めなければ、検証エンジニアはバグを探すのではなく「動いているように見えるもの」を確認するにとどまる。カバレッジ100%を取っても仕様書を誤読したところから来たバグは掴めない。Wilson 2020年調査でASIC/ICプロジェクトの3分の2ほどが一度以上のリスピンを経験したという数値がむやみに出るのではない。検証人員は増えたが、検証の質は人員数では解決しない。

第二に、PDは「なぜ」を知らなければツールオペレーターのままだ。

CTSを回し、ルーティングをし、タイミングECOをかける仕事はできる。しかしなぜこのpipeline stageがここになければならないのか、なぜこの構造がタイミングに有利なのかを知らなければPPA（power, performance, area）トレードオフで意思決定ができない。言われるがまま回す人と構造を理解して回す人の差は3年目から残酷に開く。

具体的な場面を見よう。セットアップ違反が出た。RTLを知らないPDエンジニアはECOを10回回してタイミングを合わせる。終わり。構造を知るエンジニアはタイミングレポートのスタートポイントからRTLへ遡ってみる。どのalwaysブロックから来たのか、FSMのどのstateなのか。そして「これはバックエンドで直す問題ではなく、RTL段階でパイプラインをもう1段入れるべき問題だ」と設計チームに戻す。その一言がシニアとジュニアの差だ。検証も同じだ。仕様書には「2つのクロックドメイン間の信号伝達」とだけ書いてある。RTLを読めない検証エンジニアは機能シミュレーションで値が伝達されるのだけ見てpassを出す。シンクロナイザが抜けているのを知らない。シリコンで間欠的なfailが出る。RTLインテントを読むエンジニアはコードを見て「ここに2-flopシンクロナイザがあるべきなのにない」と掴む。

整理するとこうだ。RTLを知らない検証エンジニアは自分が設計できないものを検証し、RTLを読めないPDエンジニアは自分が読めないものを実装する。どちらも「動くもの」は作れる。しかし「なぜ動くのか」を知らない。そして「なぜ」を知らないエンジニアは難しい問題が来たときに答えを出せない。

第三に、タイトルの慣性。

採用市場はあなたの「最後のタイトル」であなたを呼ぶ。検証3年目が設計ポジションに応募すれば面接官はこう聞く。「なぜ検証を辞めようとするのですか？」そしてあなたはRTL設計3年目たちと競争しなければならない。彼らよりRTLを読めないのに、彼らと同じテーブルに座るのだ。1年目には可能だった転換が3年目からは急激に難しくなる理由だ。迂回は入るときは広く、出るときは狭い。

履歴書の1行目を考えてみよう。「OOO, Design Verification Engineer (2023–2026)」。採用担当者は履歴書を6秒でスキャンする。その6秒があなたの次の3年を決める。タイトルはそうやって慣性を作る。

正直な例外も言おう。迂回が通じる場合もある。検証・PDで始めて設計への転換に成功した人々の共通点は2つだった。第一に、入社1〜2年以内にRTLを独学して小さなIPを直接作ってみた。「後で」ではなく「今」やった。第二に、社内に設計チームへの移動経路が実際に開いた会社だった。つまり、迂回自体が問題なのではなく「迂回＋放置」が問題だ。入ったポジションでRTLを学ばなければ迂回は恒久化し、学べば迂回は経由になる。

エピソード3. 年収ファクト：タイトルではなくレバレッジが金を稼ぐ

「それで検証かPDか、どこが金を多く出すのですか？」この質問にもデータで答えよう。

ERI SalaryExpert（2026年）基準の韓国半導体エンジニアの平均base salaryは約8,296万ウォンだ。キャリア別では1〜3年目約5,854万ウォン、8年目以上約9,564万ウォン。（出典）大卒新卒の初任給はSKハイニックス約5,400万ウォン、DBハイテック4,800万〜5,300万ウォン水準とされる。（出典1、出典2）

そして正直な開示ふたつめ。RTL設計 vs 検証 vs PDに分かれた職種別年収バンドの公開データは見つけられなかった。ERI数値も職種ブレンド基準だ。韓国大企業の同一職級内では設計・検証・PD間の初任給の差は大きくない。同じ職級体系、同じ成果給テーブルを使うからだ。

では年収を分けるのは何か。タイトルではなくレバレッジだ。RTLを読む検証エンジニア、アーキテクチャを理解するPDエンジニア、前段のインテントを読んでサインオフを出すSTAエンジニアが高い。STA／サインオフエンジニアの値段が高い理由も同じだ。サインオフはフロー全段階のインテントを全部読まなければならない仕事なので、前段を知らなければできない仕事だ。5年後の年収の差は「どのタイトルか」ではなく「フローをどれだけ広く読むか」で開く。

グローバル市場の事例がこれを証明する。2026年3月の報道によると、NVIDIAが韓国のHBM開発エンジニアキャリア組採用に約25万8,750ドル（約3億7,300万ウォン）水準の年収を提示し、MediaTekもHBM関連エンジニア採用に約26万ドルを提示した。（出典）HBMは設計・プロセス・パッケージング経験をあまねく備えた「実戦型人材」が必要な分野だ。金が集まるところは特定のタイトルではなく「代替不可能な理解」だ。HBM経験が高い理由はHBMを知る人が少ないからではなく、その程度の複雑さを扱えるエンジニアが貴重だからだ。検証でもPDでも、その水準の理解に到達したエンジニアはタイトルと無関係に高くなる。

エピソード4. 順番が答えだ：フロントトゥバック・ルール

ここまでが診断だ。次は処方だ。答えは単純だ。順番に学べ。RTLを先に。

チップが作られる順番に学ぶこと——フロントトゥバック——が最も速い道だ。各段階で手にすべきものは次の通りだ。

1. RTL Design —— Verilog/SystemVerilog、FSM、パイプライン構造、CDC基礎。「合成可能なRTL」を直接書いてみること。これがなければ後のすべての段階がブラックボックスになる。
2. Verification —— UVMテストベンチ構造、SVA（アサーション）、ファンクショナルカバレッジクロージャ、フォーマルの概念。RTLを書いたら「自分が書いたものをどう証明するか」を学ぶ。
3. Synthesis —— 制約（SDC基礎）、リント、ネットリストがRTLとどう違うか。
4. Physical Design —— フロアプラン、パワープラン、CTS、ルーティング、フィジカル検証（DRC/LVS）の概念。
5. STA / Signoff —— タイミング制約作成、タイミング例外、タイミングクロージャ、サインオフ基準。

すでに検証・PDで入社した人のための現実的なプランもある。業務外1日1時間、6ヶ月でいい。UARTやSPIのような小さなIPをVerilogで直接書き、論理合成を回し、STAまで回してみるのだ。「読む」ではなく「作る」からだ。直接作ってみた人だけがインテントを読める。

業務時間の中でも学べる。検証エンジニアなら、バグが出たときにテストベンチから見ず、波形とRTLから見よう。「なぜこの信号がこう出るのか」をRTLで追跡する習慣がそのままRTLリーディング訓練だ。PDエンジニアなら、タイミングレポートのスタートポイント／エンドポイントを見てネットリストではなくRTLへ遡れ。3ヶ月もすれば「タイミングがなぜ壊れるのか」が見え始める。

6ヶ月プランを具体的に組むとこうだ。1〜2ヶ月目：Verilog基礎と小さなモジュール（UART TX）直接作成。3〜4ヶ月目：SPI slaveのようなslightly bigger IPとテストベンチを直接作成して機能検証まで。5〜6ヶ月目：論理合成を回してSTAレポート読みに挑戦。この順番がまさに上の図の1→2→3→5だ。PD（4段階）は概念学習で並行すればいい。

そしてこのすべての過程をGitHubに上げよう。RTLコード、直接書いたテストベンチ、合成レポート、STAレポート。「検証2年目だけどRTLも読んで書けます」を証明する方法はポートフォリオだけだ。面接官は言葉を信じず成果物を見る。履歴書のタイトルが検証でも、GitHubの1ページ目がRTLなら話が変わる。

核心を一行にまとめると：横に行かず前に行け。検証からPDへ、PDからDFTへ横に移り歩くのは移動ではなく漂流だ。RTLを起点にフローに沿って前に進むことだけがキャリアになる。

edu.vlsi.kr連携ロードマップ

この記事の「順番に学べ」という主張はVLSI EduのRTL2GDSロードマップと同じ方向を見る。当該ページは「学んだ技術が届く次の舞台」というキャリアホライズンセクションで設計・検証・EDA・ファウンドリ・装置企業のグローバルキャリア地図を示す（Samsung、SK hynix、NVIDIA、Qualcomm、AMD、Arm、Intel、Broadcom、Marvell、Micron、TSMC、Cadence、Synopsys、ASML）。——このページは直接開いて確認した。

正直な開示みっつめ。ロードマップ・チュートリアル詳細ページはテキストfetchで開けず（JavaScriptレンダリングサイト）、URLを検証できなかった。以下はこの記事の順番と直接つながるテーマで、VLSI Eduにこういうページがあれば（またはできれば）そのまま辿ればいいものだ。

1. RTL設計ロードマップ —— Verilog/SystemVerilog基礎 → 合成可能なRTLコーディング → AMBAプロトコル（AXI/AHB）→ 小さなIP直接設計。エピソード4の1段階。
2. 検証ロードマップ —— UVMテストベンチ構造 → SVA → ファンクショナルカバレッジクロージャ → フォーマル検証の概念。エピソード4の2段階。
3. STA／サインオフロロードマップ —— SDC作成 → タイミング例外 → タイミングクロージャ → サインオフ基準。エピソード4の5段階であり年収レバレッジが最大の区間。
4. PDロードマップ —— フロアプラン → パワープラン → CTS → ルーティング → フィジカル検証。エピソード4の4段階。

Chase's Take

私は今SynopsysでPrimeTime/PrimeShield/PrimePowerを作るStaff Product Engineerだ。STAとサインオフツールが本業なので、言ってみれば私は「バックエンドの端」に立っている人だ。

ところがその前に私はSiFive KoreaでRTL-to-GDSフルオーナーシップで働いた。Samsung 5nmから14nmまで、5回を超えるテープアウト——Rebellions ATOM、FuriosaAI WARBOY、RHEAのようなチップのphysical implementationを最初から最後まで担った。

バックエンドツールを作る私が新卒たちに「前段から学べ」と言う理由がある。STAでタイミング違反に向き合えば、結局戻るところはRTLインテントだ。SDCを書くことも、ECOを判断することも、前段を知らなければ「ツールが吐いた数字」と戦う仕事になる。数字は読めるが、数字がなぜ出たのかは知らないのだ。私がPrimeTimeを作りながら最も恐れるユーザーがまさにそのユーザーだ——ツールを信じ、RTLを疑わないユーザー。

SiFiveでRTL-to-GDSをやっていたとき、テープアウト前夜に私が最も長く見たのはPrimeTimeレポート画面ではなくRTLコードだった。タイミングを直す最も速い方法はたいていRTLにあった。この経験が今私がSTAツールを作るときの基準になる。「この機能を使うエンジニアがRTLを知らなければ、この機能は毒になる。」ツールは前段を知るエンジニアの手でのみまともな武器になる。

だから私は「全体的に全部やってみなければならない」と言う。フロー全体を手で触ったエンジニアと一区間だけ知るエンジニアは5年後にまったく違う人になる。検証・PDで始めたことを後悔するな。ただそこで止まるな。RTLから学んで前に進め。順番が答えだ。

よくある質問

Q1. 検証で始めると本当に設計に戻れませんか？

戻れないのではなく、戻るコストが毎年大きくなる。1年目は難しくない。しかし3年目になるとRTL設計キャリア組と競争しなければならず、面接では「なぜ検証を離れようとするのですか」という質問を受ける。だから「後で」ではなく「今」RTLを学ぶべきだ。

Q2. PDは設計より年収が低いですか？

韓国大企業の同一職級内では設計・検証・PD間の初任給の差は大きくない。職種別に分かれた公開年収バンドのデータもない（上エピソード3参照）。差は5年後に開くが、それはタイトルではなくフローをどれだけ広く読むか——レバレッジの差から来る。

Q3. 検証の求人が多いのに、ただ検証を目標にすればいいのでは？

検証自体は素晴らしいキャリアだ。問題は「設計をやりたいのに」検証に迂回することだ。目標が検証なら検証の頂点を狙え——フォーマル検証、UVMアーキテクチャ、検証リーダーシップ。迂回は目標ではなく妥協のときに危険になる。

Q4. 今検証／PDで働いていますがRTLはどう始めれば？

業務外1日1時間でいい。UARTやSPIのような小さなIPをVerilogで直接書き、論理合成を回し、STAまで回してみる。読むだけでなく作ってみよう。直接作ってみた人だけがインテントを読める。上のedu.vlsi.kr連携セクションのRTL設計ロードマップの順番で行けばいい。

この記事はキャリア観点の一般情報であり、投資・移民アドバイスではありません。