FDE（フォワードデプロイドエンジニア）、AI駆動開発、TDD、キャリブレーション開発モデルなど、最先端のソフトウェア開発プロセスやプロジェクトマネジメントに関する知見を発信します。
最近、テック業界やAIベンダーの求人票、あるいは大手企業のDX推進会議で、にわかに目にするようになった職種「FDE（Forward Deployed Engineer）」。多くの企業が大きな期待を寄せていますが、その裏側で静かな「歪み」が生まれつつあります。なぜこれほど期待してしまうのか。その期待の正体を優しく解きほぐし、FDEの源流であるパランティアの思想に立ち返ることで、ボタンの掛け違いを解消するための冷静な処方箋を提示します。
コードを書くこと自体は、一瞬で終わりました。時間と費用を使ったのは、その外側です。
PMO支援を外部に頼む、という判断は珍しいものではなくなりました。人材紹介にもコンサルティング会社にもPMO支援のメニューが並び、大規模プロジェクトの多くに外部のPMOが入っています。その一方で、PMOが入っているのに結合テストで重大な欠陥が一斉に発覚するプロジェクトも、なくなっていません。本コラムの主張は二段です。前半では、この現象の構造を書きます。進捗報告とは成果物を人が要約したものであり、要約の過程で悪い情報は薄まるため、報告の確認だけを業務範囲とするPMOは、問題を検知できる時期が構造的に遅れます。よく参照される支援型・コントロール型・指揮型というPMOの分類は権限の強さの分類であって、この検知能力の軸——成果物を読むかどうか——が抜けています。後半では、AI駆動開発がこの限界を致命的にすることを書きます。生成が速くなった結果、書いた量や動く画面を根拠とする進捗率・消化率は、残作業の近似として機能しなくなりました。報告を確認するPMOは、読む材料そのものを失います。では成果物を読むPMOは何を読み、何を統制するのか。その各論までを、発注側がPMO支援を選ぶときの判断材料になる形で書きます。
生成AIを開発に入れて、コードを書く速度は確かに上がりました。それなのにプロジェクト全体のリードタイムがあまり縮まらない——同じ感覚を持っている方は多いはずです。実装だけが速くなった結果、レビュー、プルリクエストの処理、ドキュメントの合意という人間側の工程が、全体の速度を決める制約になりました。この問題への現在の主流の答えがスペック駆動開発(仕様駆動開発)ですが、実際に回すと壁に当たります。仕様は書き切れないのです。書き切ろうとすれば、ボトルネックは実装から仕様合意の工程へ移るだけで、全体は速くなりません。本コラムで書くのは、問いを立て直した先の進め方です。仕様を書き切ることをあきらめ、AIが空白を埋めるときの判断基準だけを渡す。CLAUDE.mdのようなAIが常時読むファイルを、指示書ではなく「憲法」として書く。そして人間が書けなかった仕様のほうは、書くコストがほぼゼロになったAIに受入テストケースとして書かせ、人間はその一覧を確定する仕事だけを持つ。Anthropic自身がClaudeの学習に使っているConstitutional AI——細かい規則を網羅せず、原則を与えて個別の判断はモデルに演繹させる——の発想を、開発プロセスの運用に転用した形です。条文の書き方、AIに出させる解釈一覧の様式、テストケース一覧をどの粒度で人が見るかまで、実際に運用している形で書きます。
2026年7月、AI駆動開発は複数のAIを組んで同時に走らせる段階に入りました。この組み方がグラフエンジニアリングです。
「プロジェクト失敗の原因は要件定義だった」——この総括を、プロジェクトの振り返りで、業界誌の調査で、SNSの議論で、100回は見聞きしてきました。そして多くの場合、こう続きます。「顧客の理解が進まなかった」「要件を出し切ってもらえなかった」。本コラムは、この診断の裏に隠れている基準を疑います。「正しくやれば、完璧な要件定義が書けたはずだ」という基準です。完璧な要件定義とは曖昧さを認めない要件定義のことですが、曖昧さがなくなるまで決め切られた文書は、もう要件定義ではなく設計です。ありえない完成形を基準に置いたまま、その差分を、答えを持っていない——持っている必要もない——顧客やオーナーからヒアリングで聞き出そうとしてきたことが、同じ失敗を三十年再生産してきました。AIが実装と突き合わせを安くした今、曖昧さは潰し切るものではなく、認めて抱えたまま、具体物の上で解いていくものに変わります。
AI駆動開発の議論は、コーディングの速さとレビューの負荷に集中しがちです。その一方でテストの中身、つまり外部結合テストをどう組むのか、性能をどう測るのか、運用と監視をどう確かめるのか、画面とバッチをどう検証するのかは、従来の工程表に沿ったまま残されています。本コラムで扱うのは、その工程表そのものを置き換える構成です。開発者一人ひとりがAWS上に使い捨てのフルスタック環境をVPC(隔離されたプライベートネットワーク)ごと持ち、AIエージェントがその中でIT(結合テスト)・ST(総合テスト)・外部結合・性能・運用・異常系の検証を常時実行し続ける。テストは決まった期間に実施する工程ではなくなり、テスト計画書は合格基準の定義だけを残して不要になる。この構成を、海外で定着しつつあるEphemeral Environment(エフェメラル環境)の考え方をテスト全体に広げたものとして、Ephemeral Testing(エフェメラルテスティング)と呼ぶことにします。構成部品はすべて実在の技術です。サービス仮想化、合成データによる増幅、カオスエンジニアリング、時刻の加速。単体ではどこかの先進企業がすでに本番で使っていますが、組み合わせて「テスト工程」の代わりに据えた現場はまだほとんどありません。理論上は組めるのに、誰も手を出していない。その領域まで含めて書きます。
経営層は生成AIの活用を号令し、ライセンスは全社に配布済み。それでも開発のリードタイムと品質は変わっていない——いま、事業会社の開発組織からSIerまで、規模を問わず同じ相談が寄せられています。原因はツールでも現場の意欲でもありません。「ツールの導入」と「開発プロセスへの定着」が別の仕事であり、後者を担う人が組織のどこにもいないことです。本コラムでは、定着までの道のりを5段の階段に整理し、社内推進が止まる構造的な理由を解説したうえで、段の先へ登る道のりを「定着までの12週間」として、モデルケースの時系列でお見せします。
仕様駆動開発（Spec-Driven Development）、テスト駆動開発（TDD）、評価駆動開発（Eval-Driven Development）。AI駆動開発の広がりとともに「◯◯駆動」を名乗る方法論が同時に語られるようになり、どれを採るべきかという議論が続いています。本コラムの立場は単純です。AIがある今、どれが正解かという問いには意味がなく、組み方次第でどれも重要です。「駆動」とは、何を動かない正本として先に固定するかの選択であり、三つの手法は択一の関係にありません。適した固定点は対象の性質ごとに違い、一つのシステムの中に三つが同居し、組み合わせは工程の一直線ではなくグラフの形になります。そしてAIは、このグラフの繋がり——正本と正本の突き合わせ——を即座に、何本でも同時に取れるようにしました。仕様はテストから、テストは評価から、評価は仕様から検証され、三つの「駆動」は両面から、多角的に精緻になっていきます。それをどう組むかが、設計者に残る仕事です。
受託開発・SESの現場でAI駆動開発の話をすると、返ってくる反応はほぼ2通りです。「やらないとまずいのは分かっているが、何から手をつければいいか分からない」。もうひとつは「現場のエンジニアが個別にツールを使い始めていて、会社として統制できていない」。どちらも足りていないのはツールの知識ではなく、着手の順番です。本コラムでは、社内承認から始めて、案件1本での実測、開発標準への組み込み、そして見積り・契約への反映まで、ベンダーが進む道を4つの段階に分けて示します。各段階の詳細を扱った個別のコラムへの入口も兼ねています。
「AIで開発が速くなるなら、外注費も下がるはずだ」——そう考えるのは自然です。しかし実際には、AIを導入したというベンダーに発注していても、見積りも毎月の支払いも変わらない。原因の多くは、生成AIの使い方がコードを書く時間を削るだけの域にとどまり、費用が動くほど総工数が減っていないことです。本コラムでは、外注費を「量×単価」「作業の対価＋判断と責任の対価」に分解するところから始めて、費用を実際に下げる3つの経路——要員枠の縮小、工程を分離した発注、内製化——と、そのすべての前提になる自社での実測、発注側が骨格を用意するRFPの作り方、人月単価の先にある「責任の値段」までを扱います。
AI駆動開発の事例はプロダクト開発やアジャイルの文脈で語られるものが多く、工程を承認で固定していくウォーターフォールにはそのまま当てはまりません。各工程の成果物は短時間で出るようになりましたが、その成果物を次工程の前提として固定する承認の責任は、AIに移せないためです。本コラムでは、要件定義から設計・実装・テストまでを通して、どの工程で誰が何に責任を持つのか、その責任を成立させるためにAIの生成をどう統制するのか、そして承認者が判断できるレビュー文書をどう作るのかを扱います。
AI駆動開発の導入が止まる場所は、ツール選定でも技術検証でもありません。情報システム部門・法務・経営管理を通す社内承認です。承認側の問いに「利用ガイドラインを整備します」と答えても、稟議は動きません。本コラムでは、生成AIガバナンスの全体像を「6層モデル」と「統制の配置図」という二枚の図に整理し、承認を左右する論点だけに絞って解説します。
受託開発の現場でClaude Codeを使うためのサブエージェント・スキル・運用標準の一式を、「Claude Code プロジェクトパック」としてGitHubで公開しました（MIT License）。個々の機能や導入手順はリポジトリのREADMEに譲り、本コラムでは、その設計の土台にある考え方を書きます。なぜ受託開発とAI駆動開発の組み合わせは難しいのか。その難しさを、私たちはどのような判断で仕組みに変換したのか。そして、なぜ隠さず公開することにしたのか。導入を検討する際の判断材料として使ってください。
企業の生成AI活用において、プロダクトやAPIを導入するだけでは解決できない「現場のリアルな壁」が数多く存在します。本コラムでは、LLM・AI活用における4大領域（社内ナレッジ、業務効率化、AI駆動開発、プロダクトAI化）において直面する壁と、それを突破するためにFDE（前方展開エンジニア）が主導する泥臭いアプローチ、そして戦略・SESとのポジショニングの違いを整理します。
営業力と開発力はあるのに、特定の体制や一時的な知見不足のために案件を見送っていませんか？本コラムでは、SES事業者が直面する「機会損失」の本質的な要因を解き明かし、FDE（前方展開エンジニア）をスポットで接続することでリスクなく案件を受注し、かつ社内にノウハウを蓄積して「自走化」へと導くアライアンスモデルについて解説します。
生成AIの台頭によって、要求仕様からコードを書く「実装（How）」の価値はコモディティ化しました。これからのSES（システム・エンジニアリング・サービス）の生存戦略は、単なる時間売り派遣ではなく、顧客のビジネス背景を理解しAIを操る「FDE（前方展開エンジニア）」の機能を自社に実装することにあります。従来の「仲介・派遣業」から「加工・インテグレーション業」へのトランスフォーメーション、そして海外で爆発的に普及する「Fractional×Pod」アライアンスを日本で再現する実行ロードマップを提示します。
生成AIの台頭は、コードの記述だけでなく、テスト生成や設計・ドキュメント作成に至るまで、SDLC（ソフトウェア開発ライフサイクル）全体のコスト構造に劇的な変化をもたらしつつあります。実装や修正のコストが大きく下がる現代、最適な開発プロセスはどうあるべきか。本稿では、従来の「手戻り防止型」のウォーターフォールや「無限反復型」のアジャイルに代わる、新たな2パス型開発プロセス「キャリブレーションモデル（CDM）」という仮説を提示。要件認識の誤差を実物で測定・補正し、確実な品質へ収束させるためのマネジメント手法の可能性について議論を深めます。
近年、テック企業で注目を集める「FDE（Forward Deployed Engineer）」。その役割や定義は企業ごとに多義的であり、時には「ただの客先常駐の言い換えでは？」というツッコミも入ります。しかし、現場の混沌（カオス）を切り拓くFDEの本質は、指示待ちの受動的な姿勢とは根本的に異なります。本稿では、AI駆動開発時代におけるFDEの本当の価値 and 送り出す側の「組織全体」のスタンスについて、泥臭いリアルの葛藤を交えて紐解きます。
近年、OpenAIやAnthropic、Salesforceといったグローバル企業が採用を進め、日本国内でも急速に注目が集まる「FDE（フォワードデプロイドエンジニア）」。直訳すれば「フォワードデプロイドエンジニア」となるこの職種は、単にコードを書くだけの存在ではありません。顧客の経営・業務現場へ直接入り込み、課題の発見から実装、期待値コントロールまでを一気通貫で行う「信頼の設計者」です。本稿では、世に溢れる「バズワードとしてのFDE」を批評しつつ、企業が本当に必要とすべきFDEの本質を解説します。