1. FDEにとってのプログラミングとは——「一人で形にする」ための道具
FDEにとってのプログラミングは、目的ではなく道具です。顧客の課題をAIで解くために、試作を自分で組み立て、顧客環境で動かし、直しながら本番に届ける——その全工程を一人でやりきるための土台がコーディング力です。専任エンジニアのように一つの技術を深く極めるより、必要なものを素早く形にする「実装の総合力」が問われます。
言語の中心はPythonとTypeScriptです。PythonはRAGやLLMエージェントの試作、データ処理、データパイプラインの中核を担います。TypeScriptは顧客が触れるUIや、既存システムと連携するWeb側で効きます。FDEは「Pythonで頭脳を、TypeScriptで顧客の接点を」作る役回りが多く、両方を最低限使えることが案件の幅を決めます。
2. FDEの現場でどう使うか——「動くものを、速く」
FDEの価値は、顧客の目の前で素早く形にして見せられることにあります。現場で問われるのは深さより速さと確実さです。
①試作を自分で組み立てる
顧客ヒアリングの翌週にプロトタイプを見せる——この速度がFDEの信頼を作ります。PythonでLLMのAPIを叩き、顧客データを処理し、RAGやエージェントの試作を自作できることが出発点です。Sansanは公式テックブログで、顧客訪問の翌週にプロトタイプをリリースする高速サイクルを紹介しています（出典は末尾）。
②顧客環境の制約に合わせて直す
試作が動いても、顧客の環境（使えるライブラリ・セキュリティ・既存システム）に合わせた調整が必ず必要になります。エラーを読んで自力で直す、動かない原因を切り分ける——この地道な力が、PoCを本番に届けられるかを分けます。
③AIが生成したコードを見極める
いまやコードの多くはAIが生成します。FDEに問われるのは、その出力を読んで正しいか判断し、危うい箇所を直す力です。書く速度はAIが上げてくれますが、良し悪しの判断は書ける人にしかできません。
3. 今どうやって身につけるか——「作品」を通して鍛える
プログラミング力は、教材を読むより「動くものを最後まで作る」ことで身につきます。
Step 1: Pythonで一気通貫のAIアプリを作る
「文書をアップロードすると質問に答える」小さなRAGアプリを、データ処理からLLM API連携まで自分の手で一本作ります。ライブラリの使い方、エラーの直し方、APIの扱いが一通り身につきます。
Step 2: TypeScriptで顧客が触れる形にする
作った頭脳に、簡単な画面（入力欄と回答表示）をTypeScriptで付けます。人に触ってもらえる形にすると、FDEの現場に近い経験になります。
Step 3: AIを相棒に開発速度を上げる
AIにコードを書かせつつ、出力を読んで直す練習をします。「全部自分で書く」から「AIに書かせて自分が品質を担保する」へ——この働き方に慣れることが、これからのFDEの実装スタイルです。作ったアプリはポートフォリオの中核になります。学習全体は未経験からのロードマップを参照してください。
4. FDE Outlook——プログラミング力の現在地と見立て
今見えていること: FDEの求人は「実装から運用まで一気通貫」を求める記述が主流で、コーディングは前提スキルです。一方でSansanは公式に「コーディングスキルより越境する姿勢・ドメイン知識」という人材観も示しており、コードは必要条件ではあっても差別化要因ではなくなりつつあります。FDEとAIエンジニアの違いも、この「コードの外側」で差がつく点に表れます。
今後の見立て: AIがコードを書く比重は上がり続け、「速く正確に書く」こと自体の希少性は下がっていきます。すると価値の中心は、AIの出力を判断し、顧客の課題に合わせて組み合わせる力へ移ります。プログラミングは「できて当たり前の土台」になり、その上で顧客のビジネスとドメインを理解する要件の言語化やドメインキャッチアップが差を生む——これが当サイトの見立てです（求人要件の変化は求人ウォッチで観測を続けます）。全体像はFDEになるにはをご覧ください。