FDEは「役職名」ではなく「役割」で採る。
事業形態 × 役職 × 役割のマッチング表

01軸の設計 — なぜこの7軸で比べるのか

FDEの職域は既存ブログの工程軸（01 事業・経営戦略〜10 運用）で定義済み。このシートでは工程軸を「候補者が持っているスキル」として測れる7軸に束ね直した。カッコ内が対応する工程。以降の表2（需要側）・表4（供給側）はすべてこの7軸で統一する。

もうひとつの設計判断: 行（ペルソナ）は役職名だけで並べない。「自社プロダクト系か、受託・SI系か」の事業形態で先に割ってから役職を置き、同じ役職名でも役割が割れるもの（PM・ITコンサル）はさらに役割で分岐させる。既存の8職種比較表が「職種→職域」の一段マップだったのに対し、ここが今回の新しい点。

02需要側 — FDE 6パターンが求める軸プロファイル

ブログNo.4で定義した6パターンを、01の7軸に載せ替えたもの。型によって◎の位置が違う＝同じ「FDE募集」でも必須要件は型ごとに変えられる、がこの表の主張。企業提案では「どの型のFDEを作りたいか」をこの表で先に合意する。

FDE 6パターン × 7軸の要求プロファイル© Potentialight

FDEの型（起点）	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ
① Palantir型FDE起点=開発実装。自社プロダクト導入先に配置	△	○	○	△	◎	○	−
② AIコンサル/SI型FDE受託型。実態は「生成AIを持った上流SE」	△	○	◎	○	○	△	−
③ 社内AX型FDE顧客が社内にいる型	△	○	○	○	○	△	−
④ フォワードデプロイドPM v1起点=要件定義・基本設計から前に出るPM	△	◎	◎	◎	−	△	−
⑤ フォワードデプロイドPM v2v1＋BizDev視点。売上インパクトまで	◎	◎	○	○	−	△	−
⑥ バックワードデプロイド・コンサルタント（BDC）型ITコンサルが下流へ広がる逆方向型	◎	◎	○	○	△	−	−

03業態の傾向 — 「強みの延長線上」か「弱み補填」か

FDE求人の必須要件は企業ごとにバラバラに見えて、「業態」である程度の傾向がある。ただし傾向は1本ではなく、各業態に「自社の強みの延長線上パターン」と「弱み補填型パターン」の2本が走っている——直近の求人ヒアリング・転職支援からの気づき（執筆中ブログより）。どのペルソナを採るかの前に、企業がどちらのパターンで採るのかを決める必要がある。

どちらが正解、ではない。両パターンのメリットを前進力に変え、デメリットを把握した上で採用・組織設計をする——そのために06の突合表で「補う軸」を先に見える化しておく。

04供給側【概要編】 — 役職レベルの18ペルソナ × 7軸

18ペルソナを事業形態で4グループに分けた。右端「マッチする型」は02の①〜⑥への突合結果。★は特に狙い目のペルソナ。この表の各行を志向でさらに割ったのが次の05キャラクター図鑑。

自社プロダクト系 — 顧客折衝はほぼ経験なし。技術軸で勝負© Potentialight

出身ペルソナ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	マッチする型
ソフトウェアエンジニア（自社）アジャイル環境で開発実装。顧客折衝ほぼなし	−	−	−	△	◎	○	−	①Palantir
リードエンジニア（自社）社内エンジニアを束ねる。顧客折衝はほぼなし	−	−	△	○	◎	◎	○	①Palantir
テックリード技術選定・設計の柱。受託には稀（リードが兼務）	−	−	△	○	◎	◎	△	①Palantir
EMPeopleマネジメント中心。技術知見持ち・採用や1on1も	△	−	△	○	○	○	◎	①リード枠 ③社内AX
VPoEマクロな組織観点。個別1on1より組織設計	○	−	−	○	△	○	◎	FDE組織立上げ
CTO技術も顧客もビジネスも幅広く。全方位	◎	○	○	○	○	◎	◎	全型 FDE組織立上げ

受託・SI系 — 同じ役職名でも顧客接点がある。ここが自社系との分岐点© Potentialight

出身ペルソナ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	マッチする型
ソフトウェアエンジニア（受託）顧客MTGに同席することはある	−	−	△	△	◎	○	−	①Palantir ②SI型
リードエンジニア（受託）★実装◎のまま顧客折衝している可能性がある	−	△	○	○	◎	◎	○	①Palantir ②SI型
PL / PM（顧客折衝型）要件定義・要件調整が中心。顧客折衝はほぼ必須	△	○	◎	◎	−	△	△	④FdPM v1
PM（調整型）プロジェクトの調整・進行が中心。課題提起は薄い	−	△	○	◎	−	△	△	④FdPM v1（A軸を補強）
手を動かせるPM★技術がわかるPM。要件も実装も両輪	△	○	◎	◎	○	○	△	②SI型 ④FdPM v1
PMO複数プロジェクト統括。顧客接点は多いが技術職ではない	○	△	○	◎	−	−	△	④FdPM v1（大手案件）
プリセールス顧客折衝・要件調整は多い。技術は深くない	○	◎	○	△	−	△	−	⑤FdPM v2
エンジニア出身セールス★技術がわかり顧客の前に立てる。FDE採用の最有力	◎	◎	○	○	○	○	−	⑤FdPM v2 ⑥BDC ②SI型

コンサル系 — 同じ「ITコンサル」でも役割で3分岐© Potentialight

出身ペルソナ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	マッチする型
ITコンサル（戦略型）戦略・戦術立案が中心。実装には触れない	◎	◎	○	○	−	−	△	⑥BDC
ITコンサル（PM型）戦略に携わらず実態はほぼPM	△	○	◎	◎	−	△	△	④FdPM v1 ②SI型
ITコンサル（技術型）技術がわかるコンサル。PoC等で手も動く	○	○	◎	○	△	○	−	②SI型 ⑥BDC

社内 — 「顧客の前」を「社内の顧客の前」と読み替える© Potentialight

出身ペルソナ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	マッチする型
社内SE・情シス社内各部門のヒアリング〜要件〜実装まで職域が広い	△	○	○	○	○	△	−	③社内AX

05供給側【詳細編】 — キャラクター図鑑21体 × 7軸

04との違い: 04は「役職×事業形態」の粗い地図（企業と採用戦略を話すときの概要）。この05は04の各行を「志向」でさらに割り、1人ずつキャラクター化した詳細版（求人要件づくり・求職者面談の実務用）。列は04と同じ7軸に、ない軸の扱い（補填するか・諦めて型を変えるか）と成長パスの2列を足してある。完璧な人はいない前提で、◎が1つあればどこかの型に入口がある。

ない軸の扱いの原則（設計判断）: A課題提起・B要件定義は後天的に伸ばせる（同席→単独の場数設計）。D開発実装がゼロの人に実装を求めるのは基本「諦め」＝フォワードデプロイドPM・BDCルートへ型を変える。G マネジメントはFDE単体には不要なので補填対象にしない。

自社プロダクト系（04の6行を志向で分岐）© Potentialight

キャラ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	ない軸の扱い	マッチする型	ミキワメ推定 大分類／近い16タイプ
職人型SWESWE×技術没頭	−	−	−	△	◎	○	−	ない軸: A課題提起・B要件定義 → 志向次第。無理に補填しない	①PalantirFdPMとペア運用	アレンジ（左下） エキスパート／プラクティショナー 深化・自律。1人で掘る
社交型SWESWE×コミュ好き（顧客は同席止まり）	−	△	△	○	◎	△	−	ない軸: A課題提起・B要件定義 → 補填最優先（適性あり）	①Palantir 育成枠③社内AX	サポート（左上） モチベーター／サポーター 楽観・社交。顧客の前が苦でない
番頭型リードエンジニアリード×チームの束ね役	−	−	△	○	◎	◎	○	ない軸: A課題提起・B要件定義 → 補填。社内調整力が素地	①Palantir リード枠	アレンジ（左下） プロテクター／コントリビューター 配慮で束ねる。堅実
探求型テックリードテックリード×技術探求	−	−	△	○	◎	◎	△	ない軸: A課題提起・B要件定義 → 技術に振るなら諦めも可	①Palantir 高難度案件	コンサル（右下） アナライザー／イノベーター 慎重に深く。技術で主張
世話役型EMEM×People中心	△	−	△	○	○	○	◎	ない軸: A課題提起・B要件定義 → 補填。対人力があるので速い	③社内AX①リード枠	サポート（左上） サポーター／コラボレーター 人を支える。配慮が核
組織設計型VPoEVPoE×マクロ組織設計	○	−	−	○	△	○	◎	ない軸: A課題提起・D開発実装 → 現場でなく組織を作る側で活かす	FDE組織立上げ	コンサル（右下） ファシリテーター／ブレイン 構造で考え、責任で回す
万能型CTOCTO×全方位	◎	○	○	○	○	◎	◎	ない軸: なし （現場1人分として使うのは勿体ない）	全型適合FDE事業責任者	ドライブ（右上） アントレプレナー／イノベーター 主張・楽観・拡大。2象限混在

受託・SI系（04の8行を志向で分岐）© Potentialight

キャラ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	ない軸の扱い	マッチする型	ミキワメ推定 大分類／近い16タイプ
現場型SWE受託SWE×実装一筋	−	−	△	△	◎	○	−	ない軸: A課題提起・B要件定義 → 補填。同席経験が種	②SI型①Palantir	アレンジ（左下） プラクティショナー／エキスパート 実装一筋。深化型
同席型SWE受託SWE×顧客MTG同席が習慣	−	△	△	△	◎	○	−	ない軸: A課題提起（単独経験） → 補填。同席の場数が資産	②SI型将来①Palantir	アレンジ（左下） コラボレーター／プロテクター アレンジ寄りだが社交側
前線型リードエンジニア ★受託リード×顧客折衝あり	−	△	○	○	◎	◎	○	ない軸: F BizDev → 当面諦めてよい	①Palantir 本命②SI型	コンサル（右下） ファシリテーター／イノベーター 慎重に主張。顧客折衝あり
折衝型PL/PMSI PM×顧客折衝が中心	△	○	◎	◎	−	△	△	ない軸: D開発実装 → 諦め 技術理解は用語研修で底上げ	④FdPM v1 本命	ドライブ（右上） プロモーター／ムードメーカー 楽観・社交。前に出る
調整型PMSI PM×進行・調整が中心	−	△	○	◎	−	△	△	ない軸: A課題提起 → 補填必須 D開発実装 → 諦め	④FdPM v1 育成枠	サポート（左上） コントリビューター／サポーター 配慮で進行を支える
二刀流PM ★手を動かせるPM×両輪	△	○	◎	◎	○	○	△	ない軸: F BizDev → ⑤に行くときだけ補填	②SI型 本命④FdPM v1	コンサル（右下） イノベーター／アナライザー 主張×慎重。両輪を回す
統括型PMOPMO×複数案件の統括	○	△	○	◎	−	−	△	ない軸: D開発実装・E技術リード → 諦め A課題提起 → 補填	④FdPM v1 統括枠	コンサル（右下） ブレイン／プロテクター コンサル寄り。管理を設計
提案型プリセールスプリセールス×顧客の前が主戦場	○	◎	○	△	−	△	−	ない軸: C推進調整 → 補填（PMと二人組） D開発実装 → 諦め	⑤FdPM v2	ドライブ（右上） プロモーター／ムードメーカー 楽観・社交。提案で押す
越境型エンジニアセールス ★エンジニア出身セールス×稀少種	◎	◎	○	○	○	○	−	ない軸: Gマネジメントのみ → 補填不要	⑤FdPM v2⑥BDC②SI型	ドライブ（右上） アントレプレナー／シーカー 主張・自律・拡大。稀少種

コンサル系（04の3行＝役割分岐そのまま）© Potentialight

キャラ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	ない軸の扱い	マッチする型	ミキワメ推定 大分類／近い16タイプ
戦略型コンサルITコンサル×戦略・戦術立案	◎	◎	○	○	−	−	△	ない軸: D開発実装・E技術リード → 生成AIで「触れる」に変わった	⑥BDC 本命	ドライブ（右上） アントレプレナー／イノベーター ドライブ×コンサルの境界
実務型コンサルITコンサル×実態はほぼPM	△	○	◎	◎	−	△	△	ない軸: D開発実装 → 諦め F BizDev → 案件で補填	④FdPM v1②SI型	サポート（左上） コントリビューター／コラボレーター 配慮で回す。実態はPM
技術型コンサルITコンサル×PoCで手も動く	○	○	◎	○	△	○	−	ない軸: D開発実装の深さ → 補填。生成AIで一気に埋まる	②SI型⑥BDC	コンサル（右下） アナライザー／イノベーター 慎重に検証。PoCで主張

社内 — 「顧客の前」を「社内の顧客の前」と読み替える（04の1行を志向で4分岐）© Potentialight

キャラ	F BizDev	A 課題提起	B 要件定義	C 推進調整	D 開発実装	E 技術リード	G マネジ	ない軸の扱い	マッチする型	ミキワメ推定 大分類／近い16タイプ
橋渡し型社内SE社内SE×部門間のつなぎ役	△	○	○	○	○	△	−	ない軸: E技術リード → 諦めてよい。技術顧問と組む	③社内AX 本命	サポート（左上） コラボレーター／モチベーター 部門間の配慮役
改革型社内SE社内SE×DX推進の旗振り	○	○	○	○	△	△	−	ない軸: D開発実装（本番） → 生成AIで補填	③社内AX リード枠	ドライブ（右上） プロモーター／アントレプレナー 旗を振る。楽観・拡大
技術型社内SE社内SE×内製開発してきた	−	△	○	○	○	○	−	ない軸: A課題提起 → 補填。社内相手に場数を積める	③社内AX 技術枠②SI型	アレンジ（左下） エキスパート／プラクティショナー 内製で深化
戦略型社内SE社内SE×IT企画・DX戦略	○	○	○	○	−	△	△	ない軸: D開発実装 → 諦め。実装は技術枠と組む	③社内AX リード枠④FdPM v1	コンサル（右下） ブレイン／ファシリテーター 企画で主張。慎重

06突合 — 型別に見た「採るべきペルソナ」と「補うべき軸」

02の要求プロファイルに04・05の供給を当てたまとめ。各カードの「入社後に補う軸」が、企業に伝える育成前提＝必須要件を緩められる根拠になる。なお万能型CTOは全型に適合するため各カードには載せず、FDE事業・組織の立上げ責任者として別枠で扱う。

型別突合 — 採るべきキャラと補うべき軸© Potentialight

FDEの型	必須軸	補えばよい・諦めてよい軸	採るべきキャラ（本命 → 有力 → 育成前提）	入社後に補う軸の設計
① Palantir型FDE	D 開発実装	A課題提起・B要件定義 → 補填でよい	本命: 前線型リードエンジニア ★ 有力: 職人型SWE／番頭型リード／探求型テックリード 育成: 社交型SWE／世話役型EM（リード枠）	自社系出身はA・Bゼロ。同席→単独ヒアリングの段階設計を企業に提案
② AIコンサル/SI型FDE	B 要件定義	D開発実装の深さ → 補填でよい	本命: 二刀流PM ★／技術型コンサル 有力: 現場型・同席型SWE／実務型コンサル／越境型エンジニアセールス ★	PM系出身には生成AI実装の型を研修で。上流SE経験者はほぼ即戦力
③ 社内AX型FDE	A〜Dのバランス	E技術リード → 諦めてよい	本命: 橋渡し型社内SE 有力: 改革型・技術型・戦略型社内SE／世話役型EM 育成: 社交型SWE	E技術リードが薄い。技術顧問や技術型社内SEとの組み合わせで解決
④ フォワードデプロイドPM v1	A 課題提起B 要件定義C 推進	D開発実装 → 不要（諦め）	本命: 折衝型PL/PM／実務型コンサル 有力: 二刀流PM ★／戦略型社内SE 育成: 調整型PM／統括型PMO	調整型はA課題提起が薄い。顧客同席の場数で立ち上げる
⑤ フォワードデプロイドPM v2	A 課題提起F BizDev	技術は「わかる」で足りる	本命: 越境型エンジニアセールス ★ 有力: 提案型プリセールス	プリセールス出身はC推進が薄い。PMとの二人組で走らせる
⑥ BDC型	A 課題提起F BizDev	D開発実装 → ゼロが普通	本命: 戦略型コンサル 有力: 越境型エンジニアセールス ★／技術型コンサル	生成AIで実装ハードルが下がった今が下流へ広げどき、と口説く

07使い方 — このシートで何が変わるか

企業への提案（必須要件の広げ方）

「FDE募集＝技術も顧客折衝も両方◎」の求人は採れない。02で作りたい型を、03で「延長線上か・弱み補填か」を先に合意し、その型の◎だけを必須に、残りは06の「補う軸」＝育成前提に落とす。同じ強みの人ばかり採ってもチームは前に進まない——◎の位置が違う人を組み合わせるポートフォリオ採用を提案する。

求職者への紹介（入口の広げ方）

04の18ペルソナすべてに、少なくとも1つのFDE型への入口がある。「FDE」という求人名で届かない層——調整型PM・PMO・プリセールス・社内SE——にも、05図鑑の自分のキャラを見せて「あなたの◎はこの型で活きる。ない軸は補填する／型を変えれば要らない」と具体で語れる。職種名を型に合わせて変える（フォワードデプロイドPM・BDC等）ことで、コンサル出身者への訴求も変わる。

ポテンシャライト 山根

08性格 × 職域 — ミキワメ4象限に職域・職種・図鑑キャラを載せる

この章の主張: これまでエンジニアの職種は「テクニカルスキル」だけで整理されてきた。しかし現場は暗黙に「この職種にはこういう性格の人が多い」と知っている（05図鑑の「職人型／社交型」がまさにそれ）。AIで職域が前に溶け出した今、その暗黙知をミキワメの4象限・16タイプという共通言語で明示的に整理する。これは正解ではなく、問題提起の叩き台。

読み方: 4象限は「主張⇔配慮」×「楽観⇔慎重」の2軸（ミキワメ公式）。性格に優劣はない。各象限に◎の工程があり、全象限が職域マップのどこかに載る。◎○△−は「その工程を主戦場にしやすいか」の初期仮説で、山根一城 × Claude が図鑑・職域マップの文脈から置いたもの。ミキワメ社の公式判定ではない。

08-1. 4象限マップ — エンジニア20職種の「リスキリング前の傾向」を置く

濃いタグ＝エンジニア20職種（その職種に多い性格の中心値）。枠線タグ＝職域マップの8職種の主戦場。同じ職種名でも人によって象限は違うので、あくまで傾向。

08-2. 工程 × 4象限 — どの性格がどの工程を主戦場にしやすいか

「全8職種の職域比較」の10工程を、4象限で採点したもの。右端の「AI置換」は2026年9月時点の現在地（山根の見立て）。左下＝アレンジ人材の◎が集まる工程ほどAI置換が進んでいる、がこの表の見どころ。

08-3. 職種 × 職域 × 性格 — 3変数を1枚に（案1・案2）

案1（職域マップに性格を塗る）: 職域比較マップの各工程セルを「その工程を主戦場にしやすい象限」の色で塗った。行を左から右へ読むと、同じ職種の中でも工程が下流に行くほど求められる性格が変わるのが見える。右端は職種ごとの性格ミックス（カバー工程の象限比率）。2色斜め分割＝2象限が同点の工程。

案2（色でなく「位置」で伝える）: 案1と同じ職域ガントだが、各工程セルに2×2のミニ象限アイコンを置き、光っているマスの位置で「右上＝ドライブ／左下＝アレンジ」を読む。色を覚えなくても、行を追えば光る位置が右上から左下へ落ちていくのが見える。

08-4. 20職種の詳細 — 近い16タイプと、足す象限（アドオン）

05図鑑に載っていない細分化職種（インフラ・SRE・データ・SI系など）を追加。「傾向」はあくまでその職種に多いと山根が見てきた性格の中心値であって、個人を決めつけるものではない。「足す象限」＝アドオンする側面。それが入るとFDE型の入口（02章）が開く。

08-5. 図鑑21体のミキワメ推定

05図鑑の各表に「ミキワメ推定」列を追加した（表の上に「ミキワメとは」の凡例あり）。図鑑の「職人型／社交型／番頭型／探求型」という志向分岐は、ほぼそのまま4象限に対応する（職人型＝アレンジ、社交型＝サポート、探求型＝コンサル、越境型＝ドライブ）。05図鑑へ

出典: ミキワメAIラボ「性格検査（16タイプ）の見方」（4大分類・16タイプ名）／ミキワメ公式メディア（4軸の名称）／情報戦略テクノロジー社との打ち合わせ（2026-09-10、性格リスキリング4ステップ・OSとアプリ・畳むPM＝アレンジ）／本シート01〜07章。