FDE（フォワードデプロイドエンジニア）、AI駆動開発、TDD、キャリブレーション開発モデルなど、最先端のソフトウェア開発プロセスやプロジェクトマネジメントに関する知見を発信します。
最近、テック業界やAIベンダーの求人票、あるいは大手企業のDX推進会議で、にわかに目にするようになった職種「FDE（Forward Deployed Engineer）」。多くの企業が大きな期待を寄せていますが、その裏側で静かな「歪み」が生まれつつあります。なぜこれほど期待してしまうのか。その期待の正体を優しく解きほぐし、FDEの源流であるパランティアの思想に立ち返ることで、ボタンの掛け違いを解消するための冷静な処方箋を提示します。
近年、OpenAIやAnthropic、Salesforceといったグローバル企業が採用を進め、日本国内でも急速に注目が集まる「FDE（フォワードデプロイドエンジニア）」。直訳すれば「フォワードデプロイドエンジニア」となるこの職種は、単にコードを書くだけの存在ではありません。顧客の経営・業務現場へ直接入り込み、課題の発見から実装、期待値コントロールまでを一気通貫で行う「信頼の設計者」です。本稿では、世に溢れる「バズワードとしてのFDE」を批評しつつ、企業が本当に必要とすべきFDEの本質を解説します。
近年、テック企業で注目を集める「FDE（Forward Deployed Engineer）」。その役割や定義は企業ごとに多義的であり、時には「ただの客先常駐の言い換えでは？」というツッコミも入ります。しかし、現場の混沌（カオス）を切り拓くFDEの本質は、指示待ちの受動的な姿勢とは根本的に異なります。本稿では、AI駆動開発時代におけるFDEの本当の価値 and 送り出す側の「組織全体」のスタンスについて、泥臭いリアルの葛藤を交えて紐解きます。
プロジェクトマネジメントオフィス（PMO）と聞いて、皆さんはどのような存在を思い浮かべるでしょうか。進捗率の監視と問い詰めを行う「PMO 1.0」の限界を現場のリアルな目線から解剖し、前線配備型エンジニア（FDE）の精神とGoogleのAIエージェント「Antigravity」等の最新スタックを組み合わせた、次世代の「課題解決型PMO（PMO 2.0）」の姿を提唱します。さらに、その導入を阻む心理的安全性とエンタープライズセキュリティという「リアルな2つの壁」についても深く切り込みます。
生成AIの台頭は、コードの記述だけでなく、テスト生成や設計・ドキュメント作成に至るまで、SDLC（ソフトウェア開発ライフサイクル）全体のコスト構造に劇的な変化をもたらしつつあります。実装や修正のコストが大きく下がる現代、最適な開発プロセスはどうあるべきか。本稿では、従来の「手戻り防止型」のウォーターフォールや「無限反復型」のアジャイルに代わる、新たな2パス型開発プロセス「キャリブレーションモデル（CDM）」という仮説を提示。要件認識の誤差を実物で測定・補正し、確実な品質へ収束させるためのマネジメント手法の可能性について議論を深めます。
生成AIの台頭によって、要求仕様からコードを書く「実装（How）」の価値はコモディティ化しました。これからのSES（システム・エンジニアリング・サービス）の生存戦略は、単なる時間売り派遣ではなく、顧客のビジネス背景を理解しAIを操る「FDE（前方展開エンジニア）」の機能を自社に実装することにあります。従来の「仲介・派遣業」から「加工・インテグレーション業」へのトランスフォーメーション、そして海外で爆発的に普及する「Fractional×Pod」アライアンスを日本で再現する実行ロードマップを提示します。
営業力と開発力はあるのに、特定の体制や一時的な知見不足のために案件を見送っていませんか？本コラムでは、SES事業者が直面する「機会損失」の本質的な要因を解き明かし、FDE（前方展開エンジニア）をスポットで接続することでリスクなく案件を受注し、かつ社内にノウハウを蓄積して「自走化」へと導くアライアンスモデル（Delivery Scope+）について解説します。
企業の生成AI活用において、プロダクトやAPIを導入するだけでは解決できない「現場のリアルな壁」が数多く存在します。本コラムでは、LLM・AI活用における4大領域（社内ナレッジ、業務効率化、AI駆動開発、プロダクトAI化）において直面する壁と、それを突破するためにFDE（前方展開エンジニア）が主導する泥臭いアプローチ、そして戦略・SESとのポジショニングの違いを整理します。
受託開発の現場でClaude Codeを使うためのサブエージェント・スキル・運用標準の一式を、「Claude Code プロジェクトパック」としてGitHubで公開しました（MIT License）。個々の機能や導入手順はリポジトリのREADMEに譲り、本コラムでは、その設計の土台にある考え方を書きます。なぜ受託開発とAI駆動開発の組み合わせは難しいのか。その難しさを、私たちはどのような判断で仕組みに変換したのか。そして、なぜ隠さず公開することにしたのか。導入を検討する際の判断材料として使ってください。
AI駆動開発の導入が止まる場所は、ツール選定でも技術検証でもありません。情報システム部門・法務・経営管理を通す社内承認です。承認側の問いに「利用ガイドラインを整備します」と答えても、稟議は動きません。本コラムでは、生成AIガバナンスの全体像を「6層モデル」と「統制の配置図」という二枚の図に整理し、承認を左右する論点だけに絞って解説します。