いま、FDE(Forward Deployed Engineer)という職種がにわかに盛り上がっている。
PalantirやOpenAI、Anthropicが採用を拡大し、VCのa16zは「いまテック業界で最もホットな職種」と呼び、日本でもLayerXやログラスなどのSaaS企業を中心に採用が立ち上がってきた。
一方で、この説明を聞いた多くの日本のエンジニアがこう思ったはずである。
「それ、客先常駐のSESと何が違うの?」
この記事を読み終わる頃には、この問いに一言で答えられるようになっているはずである。しかもその答えは、FDEの解説記事によくある「上流から関われる」「自社プロダクトがある」といった差分の列挙ではない。なぜその差が生まれるのかという構造のほうである。
種明かしを先に言ってしまうと、こうだ。
SESとFDEの違いは、ドラクエとモンハンの違いである。
まずドラクエのシステムをおさらいする。
ドラクエでは、戦闘に勝つと経験値が入り、勇者がレベルアップする。強くなるのは人である。装備ももちろんあるが、成長の主体はあくまでキャラクター自身のレベルであり、旅を重ねるほど勇者個人が強くなっていく。
これを仕事に置き換えると、従来の受託開発・SES・コンサルティングの構造とぴったり重なる。
プロジェクト(戦闘)をこなすと、経験値はエンジニアやコンサルタント個人に蓄積される。修羅場をくぐったシニアは強い。単価も上がる。これ自体は美しい成長モデルである。
ただしこのモデルには、構造的な特徴が3つある。
念のため言うと、これは誰かの怠慢の話ではない。ゲームの仕様の話である。
ドラクエ型組織では、プロジェクトの成果が「人」という揮発性の高いストレージにしか書き込まれない。 会社に残るのは請求書と、少し強くなった個人だけである。
一方のモンハン。
モンハンをやったことがある人なら知っていると思うが、モンハンにはハンターのレベルという概念が(実質的に)存在しない。何百回クエストをこなしても、ハンター自身のステータスは上がらない。
では何が強くなるのか。
武器と防具である。
クエストでモンスターを討伐すると、素材が手に入る。素材を工房に持ち込むと、武器が生産・強化される。強くなった武器でより高難度のクエストに挑み、またレア素材を持ち帰る。このループが、モンハンというゲームの進行構造のすべてである。
もちろん、プレイヤー自身も上手くなる。立ち回り、回避のタイミング、モンスターの行動の読み。いわゆるプレイヤースキルは確実に上達する。ただしそれらは定量化されるものではなく暗黙的な腕前としてのみ存在しており、ゲームの設計として、成長の主体はプレイヤーではなく装備側に置かれている。ここが決定的にポイントである。
成長が装備に書き込まれていると、何が起きるか。
お気づきだろうか。ドラクエ型の3つの構造的特徴が、すべて反転している。
そしてこの反転を生んでいるのは、ハンターの能力でも意識の高さでもない。
「経験値をどのオブジェクトに書き込むか」という、たった一つの設計の違いである。 人に書き込めばドラクエになり、資産に書き込めばモンハンになる。
ここで「じゃあ武器屋を作ればいいのか」という話になるのだが、これがそう単純ではない。
なぜなら、ドラクエにも武器屋はあるからだ。
ドラクエの武器屋は、街に行けば「はがねのつるぎ」を売ってくれる。しかしあの武器屋は、どの街の誰に売っても同じ「はがねのつるぎ」を売るカタログ販売業である。プレイヤーが竜王を倒そうが、その戦闘データが武器屋の品揃えに反映されることは永遠にない。
これは市販のパッケージソフトウェアやBIツールの構造である。世界中のどの企業が使っても同じ製品。個社の現場で起きたことは、製品には還流せず、機能要望として気の遠くなるような列に並ぶだけでしかない。
対してモンハンの武器屋(加工屋)は、まったく違う商売をしている。
素材の持ち込みがないと、商品が存在しないのである。
レアな武器は、レアなモンスターの素材からしか作れない。そしてレア素材は、討伐の現場でしか採れない。ハンターが最前線から持ち帰った素材が工房に還流し、武器体系全体が深化していく。
同じ「武器屋」という名前でも、ビジネスモデルがまるで違う。
武器屋の強さは、鍛冶の腕前ではなく、素材還流ループの回転数で決まる。
ここまで来ると、FDEの構造が一気に見通せる。
FDEの原型を作ったPalantirのモデルはこうだ。エンジニアが顧客の現場(最前線)に入り込み、その企業固有の泥臭い課題を解く。ここまでは客先常駐と同じに見える。しかし決定的に違うのは、現場で得た知見・データ構造・エッジケースが、Foundryという自社プラットフォームに還流し続けることである。
つまりFDEとは、単に前線に配備されたエンジニアではない。
討伐と採取を兼ねたハンターであり、その所属先は工房(プラットフォーム)である。
対応表を書くとこうなる。
1社目で苦労して解いた問題は、2社目では武器として最初から装備されている。だからFDEは常駐しているのに労働集約ではない。日経クロステックはこれを「SESは労働集約型、FDEは少数精鋭の知識集約型」と表現したが、知識集約になるのは、還流ループが回っているからである。
SESとFDEの違いは、常駐するかどうかでも、上流かどうかでもない。
帰る場所に工房があるかどうか、である。
ここで誤解のないように言っておくと、これは人を軽視する話ではまったくない。むしろ逆である。
ゲームのモンハンでは、討伐すれば剥ぎ取りで鱗が手に入る。何が素材かはゲームが教えてくれるし、剥ぎ取りボタンを押せば自動的にポーチに入る。
しかし現実の狩場に、「素材です」と書かれたものは落ちていない。
目の前で解いた個別課題のうち、どこまでがこの顧客固有の事情で、どこからが他の狩場でも通用する構造なのか。何を抽象化して工房に持ち帰り、何を現場の暗黙知(プレイヤースキル)として自分の身体に残すのか。——この仕分けは、WHYとWHATから考える設計行為そのものであり、極めて高度な知的作業である。
だからFDEには精鋭が求められる。コンサルの脳とエンジニアの手を兼ねる人材が要るとされるのは、討伐が難しいからだけではない。
何が素材かを見極める目のほうが、討伐の腕より希少だからである。
モンハン型は、人を不要にする話ではない。人の希少な能力の使いどころを、「討伐力」から「採取眼」へシフトさせる話なのだ。
ただし、ここには落とし穴がある。
FDEがバズるにつれ、「うちもFDEやってます」という企業が増えていく(すでに増えている)。この現象に対してa16zは早くも警告を出している。要旨はこうだ——埋め込みエンジニアの部分だけを模倣してプラットフォームの背骨がない場合、残るのは保守もアップグレードも不可能な無数の個別実装の山であり、それは「Palantir for X」ではなく「見た目のいいAccenture for X」である、と。
モンハンの語彙で言えば、これは武器屋なきハンター派遣である。
ハンターを名乗って狩場に行き、討伐はする。しかし素材を持ち帰る工房がない。持ち帰ったところで鍛造する仕組みがない。それは装備の更新されないハンター、つまり実態としてドラクエの傭兵であり、名前を変えたSESに過ぎない。
FDEというラベルは職種名でしかない。本体は、その後ろに工房があるかどうか、そして素材還流ループが実際に回っているかのほうである。
エンジニアを前線に出すことは今日から真似できる。しかし還流ループの構築には設計と年月がかかる。だからこそ、そこが堀になる。
偉そうに書いてきたが、これは私自身が業務でずっと格闘しているテーマでもある。
私は経営管理領域のソフトウェア企業で、可視化まわりの基盤を内製・展開することに取り組んでいる。この業界には、コンサルタントが顧客ごとにパワーポイントやBIツールで複雑な絵や表現を毎回ゼロから手作業で組み上げクライアントの意思決定を支援する、という伝統的な労働集約の世界が今も広く残っている。まさにドラクエ型の狩りである。優秀な職人ほど強くなるが、その技は個人に宿り、案件が終われば成果物は再利用されない。
そこで、現場で要望された複雑な表現を宣言的に描ける社内ライブラリを作り、案件で生まれた要望を吸い上げてはライブラリ側に実装して還流させる、ということを試みて続けてきた。要するに武器屋をやっている。現場から素材(描画要望)が持ち込まれ、武器(表現の実装)が鍛造され、次の案件では最初から装備されている——このループが回り始めたときの手応えは、モンハンで武器ツリーが伸びていくときの快感に近い。
そして痛感しているのは、武器屋の最大の課題は技術ではなく、狩場との導線だということである。
良い武器を作っても、ハンターが素材を持ち込む習慣と、武器を装備して出撃する習慣の両方が組織に根付かないと、ループは回らない。ドラクエ型で強くなってきた歴戦の勇者ほど、自分の剣(手作業の技)で狩り続けようとする。これは怠慢ではなく、勇者として最適化されてきた人の合理的な行動である。
だから変えるべきは人ではない。素材を持ち込むと得をする構造のほうである。
まとめる。
生成AIによって、コードを書くこと自体はどんどん安くなっていく。そうなったとき企業に残る差は、「どれだけ強い勇者を抱えているか」ではなく、「現場の学びがどれだけの速度で武器に変わる工房を持っているか」になっていくのではないかと思っている。
最後に、ひとつ問いを置いて終わる。
あなたのチームの直近のプロジェクト、素材は持ち帰っただろうか。
それとも、経験値は誰かのレベルアップ画面の中に消えただろうか。
夫婦共働きでフルリモート化するので対応策を考える
2021年9月20日(月) 15時56分23秒 | 1179 view術後16日:座り仕事
2020年10月21日(水) 12時17分22秒 | 102 viewactions-js/push@masterでのデフォルトブランチがmasterからmainに変わっていてCIが動かなくなっていた
2021年8月30日(月) 8時49分10秒 | 78 view「三人のレンガ職人」の寓話はアップデートできると思う
2026年5月14日(木) 6時40分18秒 | 43 view目次をデフォルトで開いたり、開いたり閉じたりを検出したい
2020年10月30日(金) 9時52分28秒 | 40 view