検証エンジニアから設計への転身ガイド：6ヶ月プランとポートフォリオ戦略

30秒サマリー

• DV（設計検証）はフロントエンドで採用が最も多い職種だ。入り口は広いが、RTL設計に移るには意図的な転換が必要だ。
• そのまま移せるもの：テストベンチ思考、カバレッジメソドロジー、AMBA／AXIのようなプロトコル知識、デバッグの規律。
• 新たに学ぶべきもの：マイクロアーキテクチャ設計、タイミングクロージャのマインドセット、PPAトレードオフの感覚、合成フレンドリーなコーディング。
• 最も説得力のあるポートフォリオは「自分で設計して自分で検証した」小さなRISC-Vペリフェラル一つだ。UVMテストベンチはあなたのDVキャリアが証明する。
• 面接ではDVキャリアを回り道ではなく設計の資産としてフレームしろ。「他人のRTLバグをN年探してきたから、バグの出ないRTLを書ける」という言葉が通じる。

イントロ：なぜDVから設計へ行くのか

半導体フロントエンドの求人を見ると、一つのパターンが繰り返される。DV人材が一番多く採られる。理由も明確だ。Wilson Research Groupの調査によれば、ロジック検証の工数は大きなプロジェクトで全プロジェクト時間の最大70%を占める。チップが大きくなるほど検証に人が必要になり、だからDVは新卒とジュニアに最も広く開かれた扉だ。

ところがその扉から入った人のかなりの数が2〜3年後に同じ質問をする。「今度は設計をやってみたいが、DVキャリアは役に立つのか、それとも最初からやり直すべきか？」

答えは両方だ。DVキャリアの半分は設計にそのまま移り、残りの半分は意図的に新たに学ばなければならない。この記事はその境界線を正確に引き、6ヶ月で実行可能なプランに変える。

まず市場データを確認しよう。インド基準では、RTL設計エンジニアは新卒年収6〜8 LPAから始まり、5年以上の経験で18〜30 LPA帯に行く。DVエンジニアの給与はRTLとほぼ同じ軌跡を描き、シニアレベルではむしろ前に出ることもある。チップの複雑さが増すほど検証の専門性が最もタイトなボトルネックの一つになったからだ。米国側の2026年第3四半期の実際の求人を見ると、大手AIチップ会社のミッドレベルRTL設計ポスティングがベース138k〜197k USDに15%ボーナスを提示し、シニア級は163k〜237k USDまで開いていた。設計に移ることが報酬面でも理にかなった選択肢だということだ。ただし、その扉は実力で開く。

もう一つ。検証がプロジェクト工数の50〜70%を食うということは、すなわちヘッドカウントもその比率で回るということだ。フロントエンドチームでDVが最も多くの人員を占める構造的な理由だ。だからDVは入り口のハードルが低い代わりに、内部で設計に移ろうとする競争も激しい。「いつか設計したい」という漠然とした希望ではなく、6ヶ月の実行計画が必要な理由だ。

1. DVから設計にそのまま移せるもの

1.1 テストベンチ思考：仕様を読む目

DVエンジニアは仕様を「どう壊すか」という観点で読む。これは設計者にとって最も貴重な習慣だ。RTLを初めて書くときからコーナーケースを頭に描きながら書く人と、後でテストベンチが拾ってくれるだろうと書く人では、6ヶ月後のコード品質がまったく違う。DV出身がRTLをうまく書ける理由の1位がこれだ。

1.2 カバレッジメソドロジー：「完了」の定義

設計初心者が最も苦労することの一つが「このくらいでいいのか？」という判断だ。DVエンジニアはファンクショナルカバレッジとコードカバレッジで「done」を定義する訓練をすでに受けている。この感覚はRTL設計でマイクロアーキテクチャをブロックに分割し、各ブロックの完成基準を立てるのにそのまま使える。

1.3 プロトコル知識：AMBA／AXIを知る手

SoC設計の半分はインターフェースだ。AXI4、AXI-Lite、APBのハンドシェイク、オーダリングルール、アウトスタンディングトランザクションを検証しながら体で覚えた人は、ペリフェラルを設計するときにインターフェースで迷わない。求人のRTL設計ロールが要求するスキルリストを見ればバスプロトコルは欠かせない。DVですでに備えた武器だ。

1.4 デバッグの規律：波形を読む捜査力

数百万サイクルの波形からバグを見つけた経験は、RTL設計のデバッグにそのまま転移する。違いは一つだ。DVでは他人のバグを探し、設計では自分のバグを探すということ。心理的ダメージはあるが技術は同じだ。

1.5 スクリプトと自動化：リグレッションを回していた手

DVエンジニアはリグレッションを回すためにPython、Tcl、Perl、Makefileを毎日使う。この自動化能力は設計でもそのまま通用する。RTL lint＋合成＋基本シミュレーションを一気に回すスクリプトを書いたことのある人は設計生産性が違う。求人でPython／Tclを要求する理由がここにある。DVですでに備えた武器だ。

2. DVキャリアではカバーされないもの

正直になろう。下の4つはDVだけ長くやっても身につかない。これが転換の本当のカリキュラムだ。

2.1 マイクロアーキテクチャ設計：構造を組む思考

DVは与えられた構造を「検証」する。設計は構造自体を「選択」する。同じFIFOでもデプスをいくつにするか、カットスルーにするかストア・アンド・フォワードにするか、バックプレッシャーをどこで処理するかはマイクロアーキテクチャの決定だ。これらの決定はスループット、レイテンシ、面積を同時に動かす。DVではこの決定を評価したが、直接下したことはない。パイプライン設計、アービタ設計、FSMエンコーディング選択を手でやってみなければこの筋肉はつかない。

例を見てみよう。AXIスレーブの前にスキッドバッファを置くか、フルFIFOを置くかを決める仕事だ。スキッドバッファは1〜2エントリで面積が小さいがバックプレッシャー処理が難しく、FIFOは深く取れるが面積を食う。スレーブの応答レイテンシが10サイクルでマスターがバースト16を撃つとき、どちらがデッドロックなしに耐えるか？こんな質問に「FIFO 32 deepでいけます」ではなく「アウトスタンディング4、バースト16、スレーブレイテンシ10サイクルなのでバッファは最低64エントリ、だから面積トレードオフでスキッド＋クレジット方式を使いました」と答えるのが設計者の言語だ。この言語は決定の根拠を数字で言う訓練からのみ生まれる。

2.2 タイミングクロージャのマインドセット：クロックに出会うRTL

テストベンチでは1GHzで回そうが10MHzで回そうが機能さえ合えばいい。実際のチップではあなたのRTLが合成を経てゲートになり、そのゲートたちが決められたクロック内にセットアップ／ホールドを満たさなければならない。DV出身が初めてRTLを書くときに最もよくするミスがコンビネーショナルロジックを深く積むことだ。「機能は合っているのにタイミングが出ない」という言葉を設計レビューで聞く瞬間が転換の最初の関門だ。クリティカルパスを意識しパイプラインステージを分ける習慣は意図的に訓練しなければ生まれない。

具体的に感覚を掴んでみよう。5nmで1GHzで回るブロックを設計するとしよう。クロック周期は1nsだ。ここで32ビットのリップルキャリー加算器をそのまま使えばキャリーチェーンが32段のゲートを伝わりながら1nsをゆうに超える。DVでは「加算結果が合っているね」で終わるコードが、設計ではタイミング違反レポートとして返ってくる。キャリールックアヘッドに変えるか、パイプラインステージを一つ増やしてレイテンシ1サイクルを甘受するかが設計者の判断だ。こんな判断を数十回やってみなければタイミング感覚は生まれない。PrimeTimeのようなSTAツールのレポートを読めることと、RTLを書くときからタイミングを意識することはまったく違う筋肉だ。

2.3 PPAトレードオフの感覚：コード1行の値段

Power、Performance、Area。設計のすべての決定はこの3軸の上で代価を払う。DVではPPAは他人の仕事だった。設計ではあなたが書いたalwaysブロック一つが面積レポートに数字で刻まれる。32ビット乗算器をそのまま使うか、ブースエンコーディングを悩むか、クロックゲーティングをどこにかけるかが実力の差として現れる。

2.4 合成フレンドリーなコーディング：シミュレーションと合成の間隔

シミュレーションで動くコードが合成で意図通りにゲートにならない場合がある。ラッチ推論、不完全なcase文、シミュレーション・合成ミスマッチはDVだけやってきた人が最も無防備な領域だ。lintとCDCチェックをRTL作成直後に回す習慣から身につけろ。実際の求人のrequired skillsにlinting、CDC、RDC、LECが欠かさず登場する理由だ。

2.5 仕様書作成：読むことと書くことは違う

DVエンジニアは仕様を読むのは得意だが、マイクロアーキテクチャ仕様を書いたことはほとんどない。設計者はブロックを作る前に「何を、どう作るか」を文書で定義する。レジスタマップ、インターフェースタイミング図、エラーハンドリング方針を文章で書く能力は設計レビューの出発点だ。Month 4のプロジェクトで仕様を5ページで書いてみる理由がこれだ。文章で書けない設計はコードでも書けない。

3. 6ヶ月プラン：月別実行表

前提は週8〜10時間のサイドスタディだ。現職DVエンジニア基準だ。

Month 0——現在地診断（1週）。プランに入る前に正直にチェックしろ。（1）Verilogで200行のFSMをlint-cleanに書けるか？（2）YosysやDesign Compilerで合成を回したことがあるか？（3）セットアップ／ホールド違反レポートを読んで原因を特定できるか？3つともYesならMonth 3から始めてもいい。一つでもNoならMonth 1から順番に行け。むやみに飛ばすとMonth 5で詰まる。

Month 1——RTLコーディング基礎。Verilogを「読む言語」ではなく「書く言語」として学び直す。ブロッキング vs ノンブロッキングの罠、FSMの3スタイル（Mealy／Moore、1-process／2-process／3-process）、パラメータ化モジュール作成を手に馴染ませる。毎日30分ずつ小さなモジュールを書いてlintを回すルーティンを作れ。目標：lint-cleanな500行のモジュールを自分で書くこと。

Month 2——合成とPPA。Month 1に書いたRTLを合成にかけてみる。公開ツール（OpenLane、Yosys）で十分だ。面積レポートとタイミングレポートの読み方を覚え、同じ機能を3通りに書いてPPAの違いを比べる。たとえば同じカウンタをバイナリ、ワンホット、グレイコードで書いて面積と最大周波数を比べてみる。目標：「自分のコードがゲート何個か」を言えるようになること。

Month 3——マイクロアーキテクチャ。FIFO、アービタ（ラウンドロビン／固定優先度）、クロスバー、パイプラインステージを直接設計する。各ブロックのスループット／レイテンシ／面積を計算し、トレードオフを文書化する。特にFIFOはalmost-full／almost-emptyのしきい値をどう決めたか根拠を残せ。目標：面接で「FIFOデプスはどう決めたか」に数字で答えること。

Month 4——ミニプロジェクト：UART。APBインターフェースのUARTコントローラを仕様から書く。小さなプロジェクトだがレジスタマップ、割り込み、ボーレートジェネレータ、TX／RX FIFOまで含めた「本物」のペリフェラルにする。仕様書は英語で5ページ以内に書く練習を兼ねろ。実際の現場のマイクロアーキテクチャ仕様がそのくらいの分量だ。目標：GitHubに仕様＋RTL＋文書のあるリポジトリ一つ。

Month 5——RISC-Vペリフェラル。Month 4のUARTをRISC-Vコアに付け、自分のUVMテストベンチで直接検証する。これがこのプランの核心だ。DVキャリアがポートフォリオで証明される瞬間だ。カバレッジ95%以上、見つけた自作バグのリストを文書化する。ここで見つけたバグのうち一つは必ずタイミングや合成関連のイシューにしろ。そうすれば「設計者的デバッグ」をした証拠になる。

Month 6——面接準備。設計中心の面接質問100問を抜き出して答えを書く。マイクロアーキテクチャ決定の根拠、PPAトレードオフの事例、タイミングクロージャの経験をSTAR形式で整理する。知人の設計エンジニアに模擬面接を一度は受けろ。DVの同僚ではなく設計者に受けなければ本物の質問が出ない。目標：「DVをやっていた人がなぜ設計を？」という質問に90秒ストーリーで答えること。

4. ポートフォリオプロジェクト：設計して、検証して、証明しろ

採用担当者がDV出身応募者のポートフォリオで見るのは一つだ。「この人がRTLを書けるか」。そしてDV出身には二つ目の質問が付いてくる。「検証はちゃんとできるか」。一つのプロジェクトで二つの質問に答える構造が最善だ。

推奨プロジェクト：APB UARTペリフェラル＋自作UVMテストベンチ

構成は単純に見えるが評価ポイントが正確に合っている。

• 設計側：レジスタマップ設計、TX／RX FSM、ボーレートジェネレータ、割り込みロジック、APBスレーブインターフェース。面接官はマイクロアーキテクチャ決定の根拠を聞いてくる。なぜFIFOデプスを16にしたのか数字で答える準備をしろ。
• 検証側：あなたがすでに得意な領域。UVM driver／monitor／scoreboard、ファンクショナルカバレッジ、アサーション。カバレッジレポートを添付しろ。他人のRTLではなく自分のRTLで見つけたバグ3つを文書化すれば、このリポジトリは平凡なチュートリアル成果物とは次元が違う。
• PPA側：合成を回した面積／タイミングレポート添付。「自分の設計の値段」を知る応募者は稀だ。

リポジトリ構造はこう持っていけ：docs/（仕様、マイクロアーキテクチャ決定記録）、rtl/、tb/（UVM）、synth/（レポート）。READMEの1行目にこのプロジェクトが証明すること3行を書け。採用担当者は30秒で判断する。

転換失敗パターン3つ

このプランを辿って失敗する場合も決まっている。あらかじめ知っておけ。

失敗1. チュートリアル地獄。講義だけ見てコードを書かない場合。DVエンジニアは学習能力が高く講義を早く消化するが、手で書かなければMonth 6に行っても「知っていること」と「できること」が分離される。毎週コミットがなければ失敗だ。

失敗2. 合成を回さない場合。シミュレーションだけで回して「できた」と思う場合。設計とDVの違いはまさにここだ。合成を回していないRTLポートフォリオは面接官に「まだDVマインド」と読まれる。Month 2を飛ばすな。

失敗3. 早すぎる応募。Month 3が終わって焦って応募する場合。設計面接はマイクロアーキテクチャの質問で分かれる。ポートフォリオなしに「一生懸命勉強中です」では通らない。最低Month 5のリポジトリがなければ応募資格がない。

面接官がリポジトリで確認するチェックリスト：

1. 仕様があるか？（READMEではなく別文書として）
2. マイクロアーキテクチャ決定の根拠が数字で書かれているか？
3. テストベンチがUVMか、適当に書いたdirected testか？
4. カバレッジの数字があるか？
5. 合成レポートがあるか？
6. Gitコミット履歴が「一気に上げた」ではなく漸進的か？

6番が意外に重要だ。一晩で完成したリポジトリと5週間かけてコミットされたリポジトリは違いがわかる。Month 4〜5の間コツコツとコミットしろ。

5. 面接のフレーミング：DVは回り道ではなく資産だ

面接官の頭の中の質問は決まっている。「DVをやっていた人が設計できるのか？」この質問に防御的に答えれば負ける。攻撃的にフレームしろ。

正直なチェック：転換すべきでない場合

フレーミングの話に移る前に一つ押さえよう。全員が設計に移るべきではない。メソドロジー自体が面白く、カバレッジクロージャの追跡の快感、UVMアーキテクチャを設計する仕事が楽しい人ならDVに残るのが正しい。シニアDVの需給はタイトで報酬もいい。「設計の方がかっこよさそうだから」移るのは最悪の動機だ。本物の動機は一つだ。「自分で構造を組んでみたい」。この一文に胸が躍らなければ、DVリーダーやアーキテクトトラックの方が幸せな道だ。

核心メッセージ：「私はN年間他人のRTLバグを探してきました。だからバグの出ないRTLの書き方を知っています。」

この一文が通じるのは具体的だからだ。続けて証拠を付けろ。

• 「私が検証しながら見た最悪のRTLパターン3つがあります。1つ目は…、だから私のコードでは…」
• 「カバレッジクロージャをやってきたので、設計するときから検証フレンドリーな構造を書きます。たとえば…」
• 「AXIオーダリングバグを捕まえた経験があるので、私がマスターを設計するときはアウトスタンディングトランザクション管理をこうします。」

絶対にするな：

• DVをけなすな。「検証は面白くなくて」は最悪の答えだ。検証の価値を知る設計者になるという姿勢が正解だ。
• 「RTLも書けます」レベルの主張だけするな。ポートフォリオリポジトリのリンクで証明しろ。
• タイミング、PPAの質問を回避するな。知らなければ「まだ勉強中で、こうアプローチしています」と正直に言え。設計面接官は見栄を最も早く見抜く。

よく出る設計面接の質問（DV出身が特に準備すべき）：

1. ブロッキング vs ノンブロッキング、いつ何を使うか——そして合成結果の違いは？
2. FIFOデプス計算：write 100MHz、read 50MHz、burst 64のときminimum depthは？
3. CDC：2段フリップフロップシンクロナイザのMTBF概念と限界、いつハンドシェイクが必要か？
4. AXI4でアウトオブオーダー完了が可能な条件は？
5. あなたが設計したブロックのクリティカルパスはどこで、どう直したか？

2番はDV出身が意外に間違える問題だ。計算自体は簡単だ。writeがreadより2倍速いのでburst 64が入ってくる間にreadは32個しか抜けない。だからminimum depthは64 - 32 = 32。だが面接官が聞きたいのは数字の次だ。「だから私はマージンを取って48か64にして、almost-fullのしきい値はこう置きました」が出てこそ設計者の答えだ。

3番も同じだ。2段フリップフロップシンクロナイザが「だいたいいける」というのはDVも知っている。設計者はMTBFがクロック周波数とフリップフロップのレゾリューション時間に指数関数的に依存すること、だから高速ドメインではハンドシェイクやFIFOシンクロナイザに移らなければならないことを言う。「いつ2段で十分でいつそうでないか」の境界が実力だ。

5番が本物の質問だ。ポートフォリオプロジェクトでタイミング問題を経験していなければ、この質問に答えられない。だからMonth 2の合成実習が必須だ。

年収交渉のヒント：DV年次を設計年次に1対1で認めさせるのは難しい。現実的には「関連経歴」として50〜70%程度見てくれる場合が多い。交渉のてこはポートフォリオだ。「3年DV＋検証済みRTLポートフォリオ」は「0年設計新卒」と違う値札をもらう。最初の設計ポジションで年収がDV時代より少し下がっても、2年後の設計シニアトラックの上昇幅を見て判断しろ。上の市場データが示す通りシニア設計の天井は確かだ。

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

この記事の各段階はedu.vlsi.krのロードマップにそのままつながる。順番に踏めばいい。

• RTL設計ロードマップ——Month 1〜3のカリキュラム。Verilog基礎からマイクロアーキテクチャまでの段階別学習経路。
• 検証ロードマップ——あなたがすでに持つ武器。UVM、カバレッジ、フォーマルまで。設計に移る前に現在地を点検する用途で。
• RTL2GDS全体フローロードマップ——RTLがチップになるまでの全体像。「全体的に全部やってみなければならない」という哲学の地図。
• RTL設計年収データ——ロール別報酬データ。転換の経済的根拠を数字で確認。

Chase's Take

正直に言うと、私はDV出身ではない。SiFive KoreaでRTL-to-GDSをフルオーナーシップでやり、Samsung 5〜14nmで5回以上テープアウトした。今はSynopsysでPrimeTime、PrimeShield、PrimePowerのようなSTA／サインオフツールを作るStaff Product Engineerだ。バックエンドツールを作る人間だが、後輩たちには常に前段階から学べと言う。RTLが先、次に検証、次に合成／PD、次にSTA／サインオフ。「全体的に全部やってみなければならない」。

だからDVファーストで入門した人を見ると二つのタイプが見える。一つは検証にだけ留まる人。もう一つは検証を足がかりに前段階に戻ってRTLをちゃんと学ぶ人だ。後者が5年後にはるかに強いエンジニアになる。理由は単純だ。バグを何百も捕まえた人が書くRTLは最初から違う。検証で見た悪い設計パターンが体に染みているので、知らず知らず避ける。

ただし勘違いするな。DVキャリアが自動的に設計実力になるわけではない。私がSTAツールを作るからSTAが得意なわけではないように、検証を長くやったからRTLをうまく書けるわけではない。マイクロアーキテクチャを直接組み、合成を回して面積レポートに痛い目に遭い、タイミング違反を徹夜で捕まえてみて初めて設計者になる。この記事の6ヶ月プランはまさにその過程を圧縮したものだ。

最後に一言。DVを「設計に行く前の仮の職」扱いするな。検証はチッププロジェクト時間の半分以上を食う本物のエンジニアリングだ。その時間を過ごしたあなたはすでに設計者の半分を持っている。残りの半分を6ヶ月で埋めろ。

FAQ

Q1. DVキャリア3年ですが、設計新卒として応募すべきですか？

A. 「設計新卒」として応募するのは損だ。DVキャリアを抱えて設計ポジションに応募しろ。3年のDVは0年の設計キャリアよりましだ。ポートフォリオでRTL能力を証明し、DV経験は検証フレンドリーな設計能力として包め。年収交渉でもDV年次を完全に捨てるな。

Q2. UVMをもっと掘る方がいいのでは？DVシニアの方が年収が高いと聞きましたが。

A. その通りだ。シニアDVは需給がタイトで報酬がRTLを上回ることもある。だからこの記事は「DVを去れ」ではなく「選択肢を広げろ」だ。RTLを書けるDVエンジニアは検証リーダー、design manager、architectへの道も開ける。転換は脱出ではなく拡張だ。

Q3. FPGAでポートフォリオを作ってもいいですか？

A. いい。むしろ勧める。RTLをFPGAに載せて実際に動かした経験はシミュレーションだけより説得力が強い。ただしFPGAで動いたからといってASICタイミングが解決するわけではない。合成レポートと一緒に提出しろ。

Q4. 6ヶ月は現実的ですか？現業と並行できますか？

A. DV現職者基準で週8〜10時間なら可能だ。DVですでに知っていること（プロトコル、デバッグ、カバレッジ）を除けば新たに学ぶのはマイクロアーキテクチャ、合成／PPA、タイミング感覚の3つだ。最も時間がかかるのはMonth 5の自作検証プロジェクトだが、これはあなたの本業スキルなので他人より速い。

この記事はキャリアガイドであり、特定の会社や採用結果を保証するものではありません。年収の数値は公開資料基準であり実際の報酬と異なる場合があります。

Sources: Wilson Research Group 2022 findings via SemiWiki; 2026 Siemens/Wilson study via SemiWiki; India salary data via Futurense 2026 salary guide and entri.app; US 2026-Q3 RTL postings via hardwareifai; JobzMall; entry-point data via techgig and Futurense 2026 guide.