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（前方展開エンジニア）をスポットで接続することでリスクなく案件を受注し、かつ社内にノウハウを蓄積して「自走化」へと導くアライアンスモデルについて解説します。
企業の生成AI活用において、プロダクトやAPIを導入するだけでは解決できない「現場のリアルな壁」が数多く存在します。本コラムでは、LLM・AI活用における4大領域（社内ナレッジ、業務効率化、AI駆動開発、プロダクトAI化）において直面する壁と、それを突破するためにFDE（前方展開エンジニア）が主導する泥臭いアプローチ、そして戦略・SESとのポジショニングの違いを整理します。
受託開発の現場でClaude Codeを使うためのサブエージェント・スキル・運用標準の一式を、「Claude Code プロジェクトパック」としてGitHubで公開しました（MIT License）。個々の機能や導入手順はリポジトリのREADMEに譲り、本コラムでは、その設計の土台にある考え方を書きます。なぜ受託開発とAI駆動開発の組み合わせは難しいのか。その難しさを、私たちはどのような判断で仕組みに変換したのか。そして、なぜ隠さず公開することにしたのか。導入を検討する際の判断材料として使ってください。
AI駆動開発の導入が止まる場所は、ツール選定でも技術検証でもありません。情報システム部門・法務・経営管理を通す社内承認です。承認側の問いに「利用ガイドラインを整備します」と答えても、稟議は動きません。本コラムでは、生成AIガバナンスの全体像を「6層モデル」と「統制の配置図」という二枚の図に整理し、承認を左右する論点だけに絞って解説します。
AI駆動開発の事例はプロダクト開発やアジャイルの文脈で語られるものが多く、工程を承認で固定していくウォーターフォールにはそのまま当てはまりません。各工程の成果物は短時間で出るようになりましたが、その成果物を次工程の前提として固定する承認の責任は、AIに移せないためです。本コラムでは、要件定義から設計・実装・テストまでを通して、どの工程で誰が何に責任を持つのか、その責任を成立させるためにAIの生成をどう統制するのか、そして承認者が判断できるレビュー文書をどう作るのかを扱います。
2026年7月、AI駆動開発は複数のAIを組んで同時に走らせる段階に入りました。この組み方が**グラフエンジニアリング**です。 ループまでの自動実行は、いわば1体のAIを安全に走らせる工夫でした。速くするには複数を同時に走らせるしかありませんが、そうすると「どれが終わったら次を動かすか」を人が捌き続けることになります。夜中は手が止まり、出来上がった成果物がどの判断を経てきたのかも、後から追えなくなる。ここが限界でした。 グラフは、この捌きを図面に写したものです。 - **ノード（点）** ― 仕事のひとつひとつ。設計・実装・レビュー・テスト - **エッジ（線）** ― どれが終わったら、次に何が動くか。レビューNGで戻る経路も線の一本 - **人のゲート** ― ここからが日本の受託開発に合わせた調整です。工程の承認と検収を線の外に置き、ここを通らずに仕事は始まらず、終わらない 図面の通りにしか動かないので、何本を同時に走らせても実行順は崩れず、人がいない時間も止まりません。そして「この仕様は誰がOKしたのか」に、後から答えられます。上のGIFは、この考え方を工程の承認と検収のあいだに収めた、受託開発向けの実行図です。フェーズごとに、同じ図が前へ進みます。 詳しくは以下記事で。
受託開発・SESの現場でAI駆動開発の話をすると、返ってくる反応はほぼ2通りです。「やらないとまずいのは分かっているが、何から手をつければいいか分からない」。もうひとつは「現場のエンジニアが個別にツールを使い始めていて、会社として統制できていない」。どちらも足りていないのはツールの知識ではなく、着手の順番です。本コラムでは、社内承認から始めて、案件1本での実測、開発標準への組み込み、そして見積り・契約への反映まで、ベンダーが進む道を4つの段階に分けて示します。各段階の詳細を扱った個別のコラムへの入口も兼ねています。
「AIで開発が速くなるなら、外注費も下がるはずだ」——そう考えるのは自然です。しかし実際には、AIを導入したというベンダーに発注していても、見積りも毎月の支払いも変わらない。原因の多くは、生成AIの使い方がコードを書く時間を削るだけの域にとどまり、費用が動くほど総工数が減っていないことです。本コラムでは、外注費を「量×単価」「作業の対価＋判断と責任の対価」に分解するところから始めて、費用を実際に下げる3つの経路——要員枠の縮小、工程を分離した発注、内製化——と、そのすべての前提になる自社での実測、発注側が骨格を用意するRFPの作り方、人月単価の先にある「責任の値段」までを扱います。
経営層は生成AIの活用を号令し、ライセンスは全社に配布済み。それでも開発のリードタイムと品質は変わっていない——いま、事業会社の開発組織からSIerまで、規模を問わず同じ相談が寄せられています。原因はツールでも現場の意欲でもありません。「ツールの導入」と「開発プロセスへの定着」が別の仕事であり、後者を担う人が組織のどこにもいないことです。本コラムでは、定着までの道のりを5段の階段に整理し、社内推進が止まる構造的な理由を解説したうえで、段の先へ登る道のりを「定着までの12週間」として、モデルケースの時系列でお見せします。
仕様駆動開発（Spec-Driven Development）、テスト駆動開発（TDD）、評価駆動開発（Eval-Driven Development）。AI駆動開発の広がりとともに「◯◯駆動」を名乗る方法論が同時に語られるようになり、どれを採るべきかという議論が続いています。本コラムの立場は単純です。AIがある今、どれが正解かという問いには意味がなく、組み方次第でどれも重要です。「駆動」とは、何を動かない正本として先に固定するかの選択であり、三つの手法は択一の関係にありません。適した固定点は対象の性質ごとに違い、一つのシステムの中に三つが同居し、組み合わせは工程の一直線ではなくグラフの形になります。そしてAIは、このグラフの繋がり——正本と正本の突き合わせ——を即座に、何本でも同時に取れるようにしました。仕様はテストから、テストは評価から、評価は仕様から検証され、三つの「駆動」は両面から、多角的に精緻になっていきます。それをどう組むかが、設計者に残る仕事です。