VPoE とは何か？役割・CTO との違い・採用のポイント
エンジニア組織が10名を超えたあたりから、「CTOだけでは組織が回らなくなってきた」という声を経営者からよく聞きます。その解決策の一つとして候補に挙がるのが、VPoE（Vice President of Engineering）というポジションです。ただ、既存の解説記事の多くは「VPoEを目指す個人」向けに書かれており、「VPoEを初めて採用する経営者・人事」が必要とする情報、つまり要件の設計方法、CTOとの責務の分け方、入社後に機能させる方法、はほとんど整理されていません。この記事では、採用側の視点から、VPoEの定義・CTOとの役割分担・採用チェックリストまでを一気に整理します。
VPoE とは何か：定義と日本での普及背景
VPoEとは「Vice President of Engineering（エンジニアリング担当VP）」の略称で、エンジニア組織の人・プロセス・文化を経営視点でマネジメントする役職です。技術的な意思決定よりも、「誰を採用し、どう育て、どう評価し、どんな開発プロセスで動かすか」に責任を持ちます。
欧米のスタートアップでは2010年代からCTO・VPoEの二頭体制が一般化しており、エンジニア組織が数十名規模になる段階で導入されるケースが多いとされています。日本では2020年代に入り、シリーズB以降のスタートアップを中心に需要が顕在化しました。採用市場での求人増加やメルカリをはじめとする大手スタートアップが同種のポジションを設けたことで、ポジション名としての認知が広がっています。
なお、組織によっては「VPoE」という肩書きを使わず、「エンジニアリング本部長」「技術人事責任者」といった日本語の役職名で同様の役割を担わせているケースも少なくありません。肩書きより「何に責任を持つか」を明確にすることが先決です。
CTO・EM との責務分担：何が違い、何を共同で担うか
「CTOは技術、VPoEは組織」という対比はよく語られますが、実務レベルで曖昧なままにしておくと、入社後に役割衝突が起きます。以下の表で、業務ごとの最終意思決定者を整理します。
| 業務領域 | CTOとVPoEが両方いる場合 | CTOがVPoEを兼任している場合 |
|---|---|---|
| 技術スタック・アーキテクチャ選定 | CTO | CTO |
| 採用要件の定義 | 共同責任（CTO＋VPoE） | CTO |
| 採用活動の推進・面接設計 | VPoE | CTOまたは委任先 |
| 評価制度・グレード設計 | VPoE | 未整備のことが多い |
| エンジニアの育成・1on1設計 | VPoE（EMを通じて） | EMに分散 |
| 開発プロセス改善（スクラム等） | VPoE | CTO・EMが兼務 |
| 技術広報・対外登壇 | CTO | CTO |
| エンジニア組織の予算管理 | VPoE（CFOと連携） | 未整備のことが多い |
| プロダクトロードマップとの調整 | 共同責任（CTO＋VPoE） | CTO |
エンジニアリングマネージャー（EM）は、VPoEの下で個々のチームや個人の成長を管理する役割です。VPoEはEMを育て、EMが現場で実行するという階層関係が典型的です。
CTOがVPoEを兼任している状態は、組織が小さいうちは成立しますが、エンジニアが15〜20名を超えると評価・採用・育成の質が落ちてくる傾向があります。「CTOが採用面接で手一杯になり、技術戦略に時間が使えない」という状態が、VPoE導入を検討するサインの一つです。
VPoE に求められる5つのコンピテンシー
既存の求人票や解説記事に並ぶ「マネジメント能力・コミュニケーション力」という記述は、採用選考では使えません。面接で実際に見極めるための行動指標レベルに落とし込んだ5つの軸を以下に整理します。
① 組織設計力
エンジニア組織の人員計画、チーム構造（機能別・プロダクト別・マトリクス）の設計、採用パイプラインの構築を主導できること。見極め設問の例：「前職でエンジニア組織をどう構造設計し、その結果どう変わったか」。
② 採用・評価制度の構築経験
ゼロベースで採用基準やグレード制度を設計した経験があること。特に「1人目VPoE」は既存制度のない環境に飛び込むため、雛形を流用するだけでなく自社に合わせて設計できる力が必要です。
③ 経営・事業との接続力
エンジニア組織の活動をビジネス指標（開発スピード、エンジニア離職率、採用充足率など）で経営陣に説明できること。エンジニアの専門言語と経営の言語を双方向に翻訳できるかどうかが見極めポイントです。
④ EM育成・コーチング
EMや将来のEMになり得る中堅エンジニアを育てる経験があること。VPoE自身がプレイヤーに戻ることなく、組織全体のマネジメントレイヤーを底上げできるかを確認します。
⑤ 技術的文脈の理解（コードは書かなくてよいが、会話できること）
現役でコードを書く必要はありませんが、エンジニアの技術的な議論を理解し、品質・負債・難易度について的確な問いを立てられることが最低限の要件です。技術リテラシーがゼロだと、エンジニアからの信頼を得るまでに時間がかかります。
1人目 VPoE 採用に特有の3つの難しさ
「VPoEが存在する会社がVPoEを採用する」ケースとは異なり、「初めてVPoEを置く」フェーズには固有の難しさがあります。Hitorimeが1人目採用の支援を通じて蓄積してきた知見から、失敗しやすいパターンを3つ挙げます。
難しさ① CTOとの役割が曖昧なまま採用してしまう
最も多い失敗パターンです。「技術系の役員が欲しい」という漠然とした動機でVPoEを採用すると、入社後にCTOとの管掌がぶつかり、どちらも動けない状態になります。採用前に「CTOは何をやめるのか」を言語化しておくことが不可欠です。
難しさ② 候補者プールが薄い
日本でVPoEの実務経験を持つ人材は、2024年時点でも母数が非常に限られています。特に「スタートアップフェーズでゼロから組織設計した経験がある」人材となると、さらに絞られます。エンジニア採用のコツとは？具体的なアクションについて解説でも触れているように、エンジニア採用は構造的に難易度が高く、VPoEはその中でも特に希少なポジションです。大手転職サービスへの一般公開求人だけでなく、リファラルやダイレクトリクルーティングを組み合わせた母集団形成が現実的です。
難しさ③ オンボーディング設計が存在しない
1人目のVPoEが入社した時点で、組織の課題は可視化されていないことが多く、何から手をつければよいかの指針も整っていません。入社後90日間のミッションを事前に合意しておかないと、「動いているように見えるが成果が見えない」という状態が続きます。
採用フェーズ別チェックリスト：採用前・選考・入社後90日
以下は、Hitorimeが1人目採用の支援で実際に用いている確認軸を、3フェーズに分けて整理したものです。「担当者が変わっても再現できる」水準で具体化しています。
フェーズ1：採用前（要件設計）
| # | チェック項目 | 補足 |
|---|---|---|
| 1 | CTOとVPoEの責務分担を書面で合意した | 「CTOが何をやめるか」まで含めて明文化する |
| 2 | 採用後1年で解決したい組織課題を3つ以内に絞った | 「あれもこれも」は失敗の入口 |
| 3 | 報酬レンジ・ストックオプション付与方針を決めた | 候補者との交渉前に経営層で合意する |
| 4 | 選考に関わる面接官と評価軸をすり合わせた | CTOが面接官に含まれる場合は特に重要 |
| 5 | 採用チャネル（リファラル・ダイレクトリクルーティング・エージェント）の優先順位を決めた | 一般公開求人だけでは母集団が作りにくい |
採用基準の決め方とは？失敗しない項目設定と運用時の注意点も参照しながら、評価軸を面接前にチーム内で統一しておくと、選考中のブレが防げます。
フェーズ2：選考中（見極め）
| # | チェック項目 | 確認の視点 |
|---|---|---|
| 1 | 過去に設計した評価制度とその成果を具体的に語れるか | 「導入した」と「機能させた」は別物 |
| 2 | エンジニア組織のスケール経験（人数・フェーズ）を確認した | 大企業での経験とスタートアップでの経験は異なる |
| 3 | 経営陣と対等に話せるか（コミュニケーションの質） | 言語化力・論点整理力・建設的な異論の出し方 |
| 4 | EM経験または育成した人材の実績を確認した | VPoEの成果は「部下の成長」に現れる |
| 5 | 技術的なトレードオフ議論についていけるか | 簡単な技術判断の背景を問う設問で確認 |
| 6 | 「まだ制度がない環境」への抵抗感を確認した | 整備された環境でしか動けない人材は機能しにくい |
フェーズ3：入社後90日（オンボーディング）
| # | チェック項目 | タイミングの目安 |
|---|---|---|
| 1 | 入社前に30・60・90日のマイルストーンを書面で合意した | オファー承諾前が理想 |
| 2 | 30日目：主要エンジニア全員との1on1を完了する | ヒアリングが組織課題の一次情報になる |
| 3 | 60日目：組織課題の初期診断レポートを経営陣に提出する | 「観察期間」ではなくアウトプットを求める |
| 4 | 90日目：採用・評価のどちらかで具体的な改善施策を実行開始する | 全課題を解決する必要はない。1つ動かすことが信頼につながる |
| 5 | 経営陣・CTOとの週次1on1を設計した | 孤立させないことがオンボーディング成功の基本条件 |
スタートアップのエンジニア採用を成功させるための方法についてはスタートアップ企業がエンジニア採用を成功させる戦略は？課題から具体的な手法まで解説にも詳しくまとめています。採用活動と並行して参照してください。
まとめ：VPoE 採用を成功させるための考え方
- VPoEは「採用すれば終わり」ではなく、役割そのものを一緒に設計するポジションです。 CTOとの責務分担を言語化しないまま採用すると、入社後に機能不全が起きます。
- 採用要件は「欲しい人物像」ではなく「解決したい課題」から逆算します。 組織課題が曖昧なままでは、候補者の評価軸も定まりません。
- 候補者プールの薄さを前提に、複数チャネルを並行稼働させることが現実的です。 リファラルやダイレクトリクルーティングを早期に立ち上げることが成功確率を高めます。
- 入社後90日のマイルストーンを採用段階で合意しておくことが、オンボーディング失敗の最大の予防策です。
- 次に取るべき一歩は、「CTOとVPoEの責務分担表を1枚作ること」です。 この作業が採用要件の言語化、面接設計、オファー設計、オンボーディング設計のすべての土台になります。
Hitorimeは、スタートアップの「1人目人材（最初の重要な採用）」と採用企業をつなぐ転職サービスです。VPoEのような、役割定義そのものが曖昧な段階からの採用に数多く伴走してきた実績があります。「要件をどう設計すればいいかわからない」「CTOとの役割分担を整理したい」という段階からご相談いただけます。詳しくはhitorime.netをご覧ください。本記事は山下雅弘監修のもと作成しています。
