FDEに必要なのは「フルスタックエンジニア」なのか?
FDE(Forward Deployed Engineer)の採用について相談を受けるとき、最初に出てくる人物像はたいてい「技術力が高くて、コミュニケーションも得意な人」です。間違ってはいないのですが、この定義で採用すると、たぶん外します。
それは「優秀なエンジニア」の定義であって、FDEの定義ではないからです。私たちが見ているのは、技術力の高さそのものではありません。顧客の業務のなかから、まだ誰も言葉にしていない課題を掘り当てて、それを解ける形に分解できるか。この一点です。
この記事では、私たちが実際の支援で「これが効いた」と確認できた資質を、採用基準として整理します。
FDE Leadは、実際に何を決めている人なのか?
基準の話に入る前に、役割を明確にしておきます。私たちのFDEにおいて、FDE Leadは仮説オーナーです。具体的には、次の判断を同時に持ちます。
- 何が本当の課題か 現場観察から、事業を止めているボトルネックを特定する
- 何を作れば何が証明できるか 検証設計をビジネス側と同じ粒度で持つ
- 何を作らないか これが最も重要。作れるものは無限にあり、時間は有限
- いつ捨てるか 外れた仮説を引きずらず、翌日には方向を変える
PMが要求を翻訳してエンジニアに渡す構造では、この4つは別々の人間に分散します。FDEはこれを一人が持ちます。だから求められる資質が、通常のエンジニア採用とずれます。
LICがFDE採用で見る3つの基準とは?
基準1:暗黙知を構造に分解できるか(言語化能力)
これを筆頭に置いているのは、実際の支援で最も効いた能力だからです。
株式会社Realize様の支援で私たちがやったことの核心は、AIの実装ではありませんでした。ベテランの仕入れ判断を44項目に分解して言語化したことです。価格推移データの読み方、ジャンク品の見極め、値引き交渉の勘所——代表の頭の中にあって口頭でしか伝わっていなかった判断を、誰が見ても分かる基準として書き出す。
この作業は、技術力では代替できません。現場の人と同じ密度で業務を理解し、「なぜそう判断したのか」を何度も問い直し、暗黙のまま処理されている条件分岐を掘り起こす。地道で、対話的で、粘り強さを要する仕事です。
そして、ここが分解できて初めて、AIに何をさせるかが決まります。順序が逆になると——つまり先にAIありきで入ると——「ベテランの判断をAIに真似させる」という筋の悪い設計になり、精度も上がらず現場も調整できないものが出来上がります。
面談では、本人が過去に扱った複雑な業務について「それをまだ知らない人に引き継ぐとしたら、何をどう説明しますか」と聞きます。構造化して話せるかどうかは、ここで大体分かります。
基準2:課題を「聞く」のではなく「見つける」姿勢があるか
顧客が言った課題をそのまま要件にする人は、FDEには向きません。
Megumi Company Group様のご相談は「営業の生産性を上げたい」でした。この抽象度からは何も作れません。商談の現場に入って観察して初めて、時間を食っていたのが商談前のターゲット選定と顧客リサーチであり、売上機会が失われていたのが商談後の追客タイミングだと特定できました。
Realize様も同じです。当初ご相談いただいた課題は「二重入力の手間」でしたが、事業成長を止めていたのは仕入れ判断の属人化のほうでした。この課題が最初のご相談に含まれていなかったのは、隠されていたからではなく、「そういうものだ」と受け入れられていて解ける問題として認識されていなかったからです。
顧客が言語化できている課題は、たいてい既に手が打たれています。手つかずで残っているのは、言葉になっていない課題のほうです。依頼を疑うのではなく、依頼の背後を見に行く。この姿勢があるかどうかを見ます。
基準3:早く出して、早く捨てられるか
FDEは当日から数日で動くものを出します。当然、完成度は低い。ここで手が止まる人がいます。「もう少し整えてから見せたい」という感覚は、エンジニアとして健全な職業意識でもあるので、否定はしません。ただ、FDEの現場では機能しません。
粗くても動くものを前にしたときに初めて、現場から「これは違う」「ここまで来たら使える」という反応が出ます。この反応が、次の実装を決める最も濃い情報です。完成度を上げてから見せると、その情報が手に入るのが1週間遅れます。
同じくらい重要なのが、捨てられることです。自分が作ったものへの執着が強いと、外れた仮説を引きずります。FDEにとって、書いたコードは資産ではなく検証の手段です。3日で書いたものを翌日捨てられるかどうかを見ます。
従来型エンジニア採用と、FDE採用は何が違うのか?
| 評価軸 | 従来型のエンジニア採用 | LICのFDE採用 |
|---|---|---|
| 技術力の見方 | 特定技術の深さ・アルゴリズム力 | 動くものを最短で出せる総合力。深さより到達速度 |
| 課題設定 | 与えられた要件を正確に実装できるか | 要件がない状態から課題を掘り当てられるか |
| 対人能力 | チーム内の円滑なコミュニケーション | 顧客の業務に踏み込んで暗黙知を引き出せるか |
| 成果物への姿勢 | 品質・保守性の高いコードを書く | 捨てる前提で書ける。執着しない |
| 評価基準 | 仕様への適合、開発生産性 | 顧客のKPIが動いたかどうか |
| 失敗の扱い | 避けるべきもの | 早く到達すべきもの。外れた仮説は成果 |
FDEに向かないのはどんな人か?
能力の話ではなく、相性の話として書きます。
- 仕様が固まってから力を発揮するタイプ これは弱点ではなく特性です。要件が確定した大規模開発では、こうした人が品質を支えます。ただ、輪郭のぼやけた課題に向き合い続けるFDEの現場では、消耗が大きくなります
- 技術的な美しさを最優先するタイプ FDEのコードは、検証が終われば書き直されるか捨てられます。設計の美しさを追求できないことにストレスを感じるなら、別の場所のほうが力を発揮できます
- 顧客の業務に興味が持てないタイプ 中古カメラの相場、営業の追客タイミング——FDEの仕事の大半は、顧客の商売を理解することです。ここに面白さを見出せないと続きません
FDEは採用するしかないのか、育てられるのか?
育てられます。ただし、順序があります。
私たちの実感では、3つの基準のうち「早く出して早く捨てる」は最も習得しやすく、「暗黙知を構造に分解する」が最も時間がかかります。前者は現場のリズムに数ヶ月身を置けば身につきます。後者は、顧客の業務に何度も踏み込み、外し、問い直す経験の総量がものを言います。
逆に言えば、採用時点で完成している必要があるのは「課題を見つけに行く姿勢」だけです。姿勢は教えにくく、技能は教えられる。ここが採用と育成の分岐点だと考えています。
ひとつ補足すると、この3基準は「AI時代だから必要になった」ものではありません。AIが変えたのは実装の速度であって、課題を見つける仕事の難しさはむしろ相対的に重くなりました。作るコストが下がるほど、何を作るかを外したときの損失が目立つようになるからです。
作れるものが増えた時代に希少なのは、作れる人ではない。作るべきものを、現場から掘り当てられる人である。
FDEという働き方については「FDEとは何か——LICが「前線配置」に賭ける理由」で、組織への導入手順は「FDEを自社に入れる——最初の90日の設計」で解説しています。LICで働くことにご関心のある方は採用情報もご覧ください。
← News・調査レポート一覧へ戻る