1人で何でも作れるFDEほど真っ先に代替される
文章目录
FDE（Forward Deployed Engineer）という言葉を、見ない日がなくなりました。
エンジニアが顧客の現場に入り込み、要件定義から実装までを一人で回す。AIでコーディングのハードルが下がった今、これこそがエンジニアの次のキャリアだ。そんな論調が広がっています。
エンジニアが顧客の業務に踏み込むこと。それ自体は正しいと思います。僕もずっと必要だと言ってきました。
しかし、忘れてはならない重要な事実があります。
FDEを「1人で要件定義から実装までできる人」と捉えた瞬間に、このモデルの価値の源泉が抜け落ちてしまうのです。FDEの価値は、実装力ではありません。顧客業界への深いインサイトです。そしてそれは、一人の優秀な個人からではなく、チームと循環から生まれます。
今回はこの話をしたいと思います。
FDEとは何か？
先日、こんなポストをしました。
FDEの原型であるパランティアでは、顧客の現場に入るのは一人ではありません。
Echoと呼ばれるDeployment Strategistが、顧客の業務と課題を理解する。Delta、つまりFDSE（Forward Deployed Software Engineer）が、自社プロダクトを元に現場で実装する。そして現場で見つかった機能不足や要望を、Product / Core Engineering（社内ではDevと呼ばれるプロダクト開発側）へ還流させる。
パランティア自身のブログでも、Deltaが現場で見つけた不足をコア製品にコードで直接貢献したり、大きな要望をプロダクトのロードマップに組み込んだりする流れが紹介されています。還流を受けた本体は、プロダクトを改善・拡張します。強くなったプロダクトを持って、また次の現場に入る。だからこそ次の開発がさらに速くなる。
FDEモデルとはポジションではなく構造だ
FDEとは、現場に出ていくエンジニア個人の肩書きではありません。
現場と本体をつなぐ、循環構造の名前です。
FDEの価値は「顧客業界へのインサイト」
では、なぜわざわざ役割を分け、循環させるのか。
この循環が生み出しているものが、顧客業界への深いインサイトだからです。
顧客の要望を聞くことではありません。顧客の業務と業界の構造を、ときに顧客以上に理解すること。そして、顧客自身すら見えていない価値に気づくことです。
Echoがインサイトを掘り当て、Deltaが現場で検証し、Coreが次の顧客でも使える資産に変える。3つの役割は、すべてインサイトのためにあります。
インサイトがあると、もうひとつ大事なことができるようになります。
Noと言えることです。
背後にプロダクトという軸があり、業界の構造が見えているから、「それは作りません」「それは既存のプロダクトの延長で解決できます」と言える。軸を持たない現場担当者は、目の前の要望に応える以外の選択肢を持てません。
経営学に「両利きの経営」という考え方があります。チャールズ・A・オライリーとマイケル・L・タッシュマンが提唱したもので、日本では入山章栄さん監訳の『両利きの経営』で広く知られております。今ある知を深め続ける「深化」と、自分の領域から離れた知を探しにいく「探索」。この2つを同時に回せる組織が強い、という主張です。
FDEモデルは、この両利きを組織構造として実装したものだと僕は見ています。現場に出るEchoとDeltaが探索を担い、Coreが深化を担う。そして循環が両者をつなぐ。
「ひとりFDE」の落とし穴
ここで、冒頭の「1人で何でも作れる人」「1人で要件定義から実装までできる人」に戻ります。
僕はこれを「ひとりFDE」と呼んでいます。
ひとりFDEは、AIのおかげで驚くほど速く動けます。要望を聞いた翌日にはプロトタイプが出てくる。顧客は喜びます。
しかし、少し立ち止まって考えてみてください。
顧客が「欲しい」と言ったものは、本当に顧客の問題を解くのか。その案件で得た知見は、次の顧客で使える形で残っているのか。要望に「作らない」と言える根拠を、自分は持っているのか。その仕事は、従来の受託開発と何が違うのか。
どれも、すぐには答えられないはずです。
ひとりFDEとの違い
両利きの経営の言葉で言えば、ひとりFDEは探索しかしていません。現場には出ている。けれど、得た知見を磨き込んで資産にする深化がない。案件が終われば、知見はその人の頭の中に残るだけです。
それは、高速な御用聞きです。
そして、速さはもう差別化になりません。僕たちの会社では、約10人月の受託案件を2週間で終わらせたことがあります。AIを使えば、実装のスピードはここまで来る。誰もがこの速さを手に入れつつある今、速く作れること自体に価値はなくなっていきます。
以前、CTO・社内SEが事業部門の「社内SIer」になってしまう問題を書きました。ひとりFDEは、その社外版です。
インサイトはフレームワークから生まれる
では、インサイトはどうすれば手に入るのか。
「顧客業界への深い理解」「顧客すら見えていない価値」「経営層にNoと言う」。こう並べると、気づく方も多いと思います。これは従来型のコンサルタントが、まさに得意としてきた仕事です。
僕自身、SIerを経てコンサルティングファームにいました。コンサルティングファームは、金融や製造といったインダストリーで組織が切られていることも多い。業界知識が武器になるのは事実です。
しかし、本当の武器は業界知識ではありません。
フレームワークです。
BCG日本代表を務めた御立尚資さんの『戦略「脳」を鍛える』という本があります。この本はまず、既存の戦略論、つまり定石を学ぶだけでは勝てる戦略は作れないと指摘します。定石を踏まえたうえで新しい戦い方を生み出す頭の使い方が必要で、BCGではそれを「インサイト」と呼ぶ、と。
面白いのは、そのインサイトを天才のひらめきとして扱っていない点です。仮説を次々に立てる「スピード」と、定石を応用する独自のものの見方である「レンズ」に分解し、パターン認識のような鍛え方まで示しています。インサイトには、鍛えられる型があるのです。
フレームワークがあるから、初めて触れる業界でも構造を素早く掴める。構造が掴めるから、顧客が当たり前だと思っている前提を疑える。前提を疑えるから、顧客すら見えていない価値に気づける。
コンサルタントが短期間で業界に入り込み、経営層にNoと言えるのは、この型を持っているからです。
FDEで問われているのも、同じです。実装力ではなく、インサイトを毎回、再現性をもって出せるかどうか。
エンジニアが持つべき3つの基盤
ここまで読むと、「結局コンサルの仕事か」と思うかもしれません。
そうではありません。エンジニアには、コンサルタントにはない武器があります。インサイトを、そのまま動くものにできることです。
そのために、エンジニアは次の3つの基盤を持つべきだと僕は考えています。
持つべき3つの基盤
1つ目は、思考フレームワークです。
今年7月のAI駆動開発Conference Summerで、僕は「コードを1行も書かないCTOのAI駆動開発」という話をしました。AIで実装が自動化された後、エンジニアに残る仕事は「仕組みづくり」と「思考」の2つになる、という内容です。
その思考も、仕組みにできます。イシューをどう定義するか。どの情報源を見るか。誰からどうフィードバックを受けるか。自分のバイアスをどう外すか。これを型として持っておくと、正しい選択肢にたどり着く確率が上がります。
2つ目は、知の集合体、つまりデータです。
業界の構造、業務の知識、過去の案件で何をなぜ判断したか、顧客との対話の記録。これを一人の頭の中ではなく、AIが参照できる形で蓄積していく。
ドメイン知識は、一人の頭に完全に揃うことはありません。僕自身、クライアントとの対話の中で、自分の視座の低さに気づかされたことが何度もあります。だからこそ、個人の経験を集合知に変える仕組みが要る。これがFDEモデルでいう「還流」の正体です。
自分にはこうしたものがないという方も安心してください。その知の集合体を持つ企業に所属するという選択肢を探すこともできます。
3つ目は、プログラム基盤です。
コードセット（プロダクトなど含む）、スキル化した手順、並列で動くエージェント、機械的に判定できる完了条件。現場で得たインサイトを、すぐに動くものへ変える実装の型です。
コンサルタントはインサイトを資料にします。エンジニアは、インサイトをプロダクトにできる。3つ目の基盤こそが、エンジニアの最大のアドバンテージです。
この3つは、最初から揃っていなくて構いません。上述したように所属する組織の力で補うという方法も非常に有効だと考えています。
結論：FDEは人ではなく、循環である
最後に、一つだけ耳の痛いことを書きます。
「自分は現場に出て、顧客と直接話し、一人で作れる。だからFDEだ」と思っているなら、あなたの仕事は、案件が変わるたびにゼロからやり直しになっているはずです。
前の現場で掴んだ業界の構造も、判断の理由も、書いたコードも、次の現場では使われない。そして実装の速さは、AIで誰もが手に入れつつある。そうなると残るのは、「速く作れる人」という、いつでも代わりがいるポジションです。
ただ、悲観する必要はありません。現場に入り込み、顧客と話し、作り切れる力そのものは本物です。足りないのは、その経験を次に持ち越す仕組みだけです。
案件を重ねるごとにインサイトの精度が上がり、次の現場ではもっと深いところから始められるようにする。それが、チームと循環の中で価値を出せるエンジニアに求められるものです。
FDEは人ではなく、循環である。
目指すべきは、FDEという肩書きではありません。現場で得たものを次に持ち越し、循環させられるエンジニアになることです。
イベントと書籍出版のお知らせ
FDEになるべきかを語るイベント
このテーマで、イベントを開催します。FDEという言葉の流行の先で、エンジニアと組織が本当に向き合うべきことを、現場の話を交えて掘り下げます。
参加リンク：https://simplexinc.connpass.com/event/408605/
『AI×アーキテクト』が10/27に出版されます
また、僕も執筆に参加した書籍『AI×アーキテクト』の予約受付が始まっています。今回触れた「仕組みづくり」と「思考」を、AIシステムを作る側の視点から体系的にまとめました。
沿着这个主题继续读
从一篇文章，找到相关的教程、经验和阅读路径。
