FDEをどう育てるか｜エンジニアが現場力を身につける研修と評価の設計

こんにちは、株式会社TIMEWELLの濱本です。

FDE実践シリーズの最終回です。ここまでの9本で、現場の技術、一週間の回し方、市場の数字、契約の型を書いてきました。最後に、これらを身につける人をどう育てるかを書きます。

当社はエンジニアの会社で、全員が開発に飢えています。しかし、FDEとして現場に入るエンジニアに要る技術の半分は、コードを書く技術ではありません。聞く、見る、いる、構造にする、撮る、辞書を機械に渡す。この六つは、大学の課程にも、プログラミングの教材にも書かれていません。当社のエンジニアは、外部の研修を受け、現場で日々の型を繰り返して、この技術を身につけてきました。この記事では、研修で教えられること、現場でしか身につかないこと、そして評価の設計を書きます。自社のエンジニアのチームがどこまで現場力を持っているかを先に確かめたい方は、AIリテラシー診断を使ってください。

FDEに要る技術は、コードの外にある

最初に、何を育てるのかを確かめます。Palantirで8年間FDEを務めた人物は、この職種に要るものを三つ挙げています。高い耐性、他社の中に深く入り込んで顧客の信頼を得るための社会的で政治的な技術、そして速さです。加えて、顧客の言葉を速く学び、その業務がどう動いているかを掘り下げられる人ほど成果を出す、と書いています¹。同じ人物は、新人FDEに配られた本として、ユーザーインタビューの実務書と、即興演劇の理論書を挙げています。後者は、人の行動と社会的な立ち位置を機械的に分解する本で、顧客の現場で信頼を得るために要る技術の教科書として使われていた、と¹。

このリストに、コードの本はありません。エンジニアの会社が、新人エンジニアにインタビューと演劇の本を渡していたわけです。理由は、コードを書く技術は採用の段階で確かめられるが、現場で聞き、見て、信頼を得る技術は社内で育てるしかないからです。

Palantirの商用部門を率いた人物は、別の角度から同じことを書いています。模倣者は、製品の境界で役割を狭く定義することで、FDEを大きく育てる坩堝を失っている、と。顧客のミッションに深く関わる広い役割が、人を育てるのだ、と²。育成の設計は、役割の設計と切り離せません。役割が「仕様どおりに作る人」なら、育つのは仕様どおりに作る技術だけです。

シリーズで書いた六つの技術を、育成の順に並べ直します。

技術	記事	研修で教えられる部分	現場でしか身につかない部分
聞く	インタビュー	質問設計、沈黙、オウム返し、二人一組	説明と画面のずれに気づく目
見る	観察法	座る場所、五列の記録、三つの観察法	違和感の列を書く目
いる	エスノグラフィー	三層のノート、意味の辞書の書き方	その会社の当然を感じ取る力
構造にする	KJ法	四つの工程、型と枝の分け方	束に名前をつける力
撮る	ビデオ分析	同意の六項目、撮り方、AIとの分担	数字に意味をつける力
辞書を渡す	オントロジー	五つの抽出、グラフの形	同じ語の別の意味を分ける力

右の二列を分けたのは、育成の設計が違うからです。左は研修で教えられます。右は教えられません。右を育てるのは、現場での日々の型です。

研修で教えられること。型は教われば身につく

研修の話を、正直に書きます。当社のエンジニアは、現場に入る前に外部のインタビュー技法の研修を受けました。研修で学んだのは型です。誘導質問を避ける、未来の意見ではなく過去の出来事を聞く、質問の後に3秒黙る、聞く人と記録する人を分ける。研修を受けた後、質問の作り方は変わりました。

型は、教われば身につきます。だから当社は、六つの技術のうち型にあたる部分を、現場に入る前に揃えることにしています。インタビューの質問設計、観察の五列、エスノグラフィーの三層のノート、KJ法の四つの工程、撮影の同意の六項目、オントロジーの五つの抽出。これらは手順書として書ける技術で、このシリーズがその手順書に相当します。新しく入るエンジニアには、最初の週にこの手順書を読んでもらい、既存のエンジニアの現場に同行して記録する側に座ってもらう、というのが当社の設計です。

型の研修には、外部のものも使えます。a16zは2026年夏に、FDEと応用AIの実務者を対象にした8週間のフェローシップを開いています。企業の実環境でフロンティアのAIシステムを出荷しながら、経験者と一緒に学ぶ形式です³。日本でも、FDEを育てる講座や、社内FDEを育成するプログラムが2026年に複数出てきました。型を学ぶ入口は、増えています。

ただし、型だけでは現場に立てません。研修を終えたエンジニアが最初の現場で必ず経験するのは、型どおりに聞いたのに、担当者の答えと画面が違う、という場面です。ここで「あれ」と思えるかどうかが、次の段階です。

現場でしか身につかないこと。ずれに気づく目

現場でしか身につかない技術を、当社は「ずれに気づく目」と呼んでいます。「いつも承認は課長がします」と言われた直後に、画面の承認欄に係長の名前があるのを見て、「あれ」と思い、「係長が承認することもあるんですか」と聞き返せる力です。

この目は、研修では育ちませんでした。育てたのは、四つの日々の型です。

一つ目は、二人一組です。新しいエンジニアは、最初は記録する側に座ります。聞く側は先輩です。記録する側は、発言を逐語で書き、担当者が画面を指した、付箋を見た、隣に確認した、という動作も書きます。この記録を毎日書いていると、発言と動作のずれが、記録の上に見えてきます。聞く側に回るのは、記録の上でずれを見つけられるようになってからです。

二つ目は、違和感の列です。観察の五列のうち、五列目には「聞いた話と見たものの差」を書きます。この列を空欄にせず、毎日必ず一つは書く、と決めています。最初の週は、たいてい書けません。何がずれなのか分からないからです。二週目に一つ書けるようになり、四週目には、この列がいちばん長くなるのが、当社が見てきた経過です。前回の記事で、研修では身につかなかった、と書いた力は、この列を毎日書くことで育ちました。

三つ目は、金曜の束です。KJ法の記事で書いた、週の断片をカードにして束を作り、名前をつける作業です。新しいエンジニアは、最初はカードを作る側で、名前をつけるのは先輩です。束に名前をつけられるようになるには、その束が現場で何を語っているかを知っている必要があります。名前をつけられるようになったとき、そのエンジニアは現場を「見た」ことになります。

四つ目は、辞書の版です。オントロジーの記事で書いた、名詞と動詞の辞書を毎週更新し、版を振る作業です。「承認する」の定義が、先週から今週でどう変わったかを説明できるかどうか。辞書の差分を担当者に説明できるようになったとき、そのエンジニアは、現場の言葉を自分の言葉として持ったことになります。

この四つに共通するのは、野中郁次郎らが共同化と呼んだもの、つまり同じ場にいて同じ経験をすることで暗黙知を移す過程です⁴。ずれに気づく目は、先輩から新人へ、講義ではなく同席で移ります。だから当社は、新しいエンジニアを最初の現場に一人では送りません。

評価の設計。稼働率ではなく、型の還流数と工数の減少

育成と評価は、一体です。評価の指標が人月の稼働率なら、育つのは長く現場にいる技術です。評価が行数なら、育つのは多く書く技術です。FDEを育てるには、評価をFDEの型に合わせなければなりません。

当社が見ている指標は四つです。その案件から製品の標準機能になった型の数。第1週から第8週で、現場工数が減ったか。担当者が辞書を自分で更新できるようになったか。次の顧客で、前の顧客から返った型が再利用されたか。契約の記事で書いた三つの比率に、担当者の自走を足したものです。

この四つは、受託開発の評価と逆向きです。受託では、稼働率が高いほど、長くいるほど、評価が上がります。FDEでは、早く出て、型を多く返し、次の顧客で速く動けるほど、評価が上がります。評価を逆向きにしないと、育成も逆向きになります。a16zが本物の型を見分けるテストに挙げた、成熟した顧客で工数が減っているか⁵は、会社の評価であると同時に、一人のFDEの評価でもあります。

もう一つ、評価に入れているものがあります。断った要望の数と、その根拠です。枝の要望に根拠を示して「No」と言えたか。これは数が多ければよいわけではありませんが、ゼロなら、そのエンジニアは全部作っているか、全部受け入れているかのどちらかです。Palantirの商用部門を率いた人物が、FDEを顧客の要望を製品の現状に縮める係の逆だと書いたのは²、ミッションには「Yes」、製品の原則に反する枝には「No」、という両方の判断ができることを求めたのだと私は読んでいます。

受託開発の育成との違い

育成の観点で、受託開発との違いを並べます。

観点	受託開発の育成	FDEの育成
育てる技術	言語、フレームワーク、設計	上に加えて、聞く、見る、いる、構造にする、撮る、辞書を渡す
教材	技術書、資格	手順書と、インタビューと観察の実務書
現場での役割	仕様どおりに作る	要件を掘り、作り、反応を取り、製品に返す
育つ場所	開発室	顧客の現場（同席）
評価	稼働率、納期、品質	型の還流数、工数の減少、担当者の自走、再利用率
育成の出口	プロジェクトリーダー	製品を育てる人

いちばん大きな違いは、育つ場所です。受託開発のエンジニアは、開発室で育ちます。顧客の現場は、要件を受け取りに行く場所です。FDEは、顧客の現場で育ちます。開発室は、金曜に戻る場所です。この違いは、育成の費用の違いでもあります。現場で育てるには、先輩の同席が要り、二人分の時間が要ります。当社がそれでも同席で育てるのは、一人で送ったエンジニアが会議室に閉じ込められて帰ってくる場面を、避けたいからです。

もう一つの違いは、出口です。受託開発の育成の出口は、プロジェクトを率いる人です。FDEの育成の出口は、製品を育てる人です。現場で見つけた型を製品に返す判断を、自分でできる人。当社は小さな会社なので、現場のエンジニアと製品のエンジニアが同じ人ですが、この二つを同じ人がやることが、育成の出口そのものです。

当社の実践と限界

正直に書きます。この育成には時間がかかります。型の研修は数日で終わりますが、ずれに気づく目が育つには、同席の現場が二つか三つ、期間にして半年ほど要ると見ています。その間、先輩の時間が二人分かかります。小さな会社にとって、これは軽くありません。

限界も書きます。育たない場合があります。聞くことより書くことが好きで、現場に座ることに耐性がないエンジニアもいます。当社は、それを欠点だとは思っていません。製品を書く側に、そういうエンジニアが要るからです。FDEに向く人と、製品に向く人がいて、両方が要る。全員をFDEにしようとすると、両方を失います。

そして、研修の限界です。当社のエンジニアが受けた外部研修は、インタビューの型を教えてくれました。しかし、観察、エスノグラフィー、KJ法、ビデオ、オントロジーの型は、社内の手順書で補うしかありませんでした。このシリーズを書いた理由の一つは、その手順書を外に出すことです。自社でFDEを育てたい会社が、このシリーズを手順書の代わりに使えるなら、書いた甲斐があります。

まとめ

FDEに要る技術の半分は、コードの外にあります。聞く、見る、いる、構造にする、撮る、辞書を機械に渡す。この六つのうち、型は研修で教えられ、ずれに気づく目は現場でしか育ちません。当社は、型を現場に入る前に揃え、目を二人一組、違和感の列、金曜の束、辞書の版という四つの日々の型で育てています。評価は稼働率ではなく、型の還流数、工数の減少、担当者の自走、再利用率で行い、断った要望の根拠も見ます。

受託開発の育成との違いは、育つ場所が開発室ではなく顧客の現場であること、出口がプロジェクトリーダーではなく製品を育てる人であることです。

このシリーズは、当社がFDEを育てるために書いた手順書を、外に出したものです。自社のエンジニアのチームにこの育成を入れたい方、あるいは自社の現場に育ったFDEを迎えたい方は、WARPのプログラムをご覧いただくか、個別相談でお話ししましょう。シリーズの全体は、FDEとは何かから辿れます。

Footnotes

1. Reflections on Palantir（Nabeel S. Qureshi、2024年10月15日）。FDEに要る三つの資質、顧客の語彙を速く学ぶ人が成果を出すという指摘、新人に配られた本の記述は同稿による（筆者の要約） ↩ ↩²

2. Sorry, that isn't an FDE（Ted Mabrey、2024年9月21日）。役割を狭く定義する模倣者が育成の坩堝を失っているという指摘、顧客の要望を縮める係の逆という記述は同稿による（筆者訳） ↩ ↩²

3. FDE Fellowship（a16z Build、Summer 2026）。8週間のコホート、実環境での出荷、経験者との学びは同ページによる（筆者の要約） ↩

4. Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press ↩

5. The Palantirization of everything（Marc Andrusko、a16z、2026年1月16日） ↩