FDE のはじめ方(無料公開)
法人向け SaaS・パッケージ事業者さま向け

FDE の本質

Palantir から学ぶ、価値で稼ぎ続けるビジネスモデル
株式会社VTL ・ 2026 年 7 月
本資料について

本資料は、法人向け SaaS・パッケージ事業者さま に向けた、FDE のはじめ方ガイドです。

生成AIが実装や作業を一気に高速化するいま、成果を左右するのは 何を・どう作るか を定める システム開発の上流設計(要求定義・アーキテクチャ) です。自社製品を持つ SaaS・パッケージ事業者にとって、この上流は 顧客の課題を解き、その解を製品に堆積させる 入口——価値で稼ぎ続けるモデル への勝負どころになりつつあります。

こうしたなか、顧客の現場に入り込み、要件から実装までを一気通貫で担う FDE(Forward Deployed Engineer) というスタイルが、世界的に注目されています。

とはいえ、「FDEをどう組成し、その核となる上流設計をどう回すのか」という体系的な方法論が無く、属人的な経験に頼らざるを得ない企業が少なくありません。貴社にも、思い当たる場面はないでしょうか。

VTL は、まさにこの上流設計のパートを、ISO/IEC/IEEE などの国際標準に基づいて体系化したメソドロジー です。ヒトとAIの協働で、システムの上流設計を「組織として再現できる仕組み」に変え、FDEの土台を支えます

本資料では、その仕組み・活用シナリオ・進め方を、順にご紹介します。まずは5分、お付き合いください。

株式会社VTL 代表取締役 片倉 健
PART 1

Palantir のビジネスモデルの本質

FDE の裏側にある、隠れた真実

Palantir の本質 ▶
常駐の意図
ビジネスモデル
設計能力
まとめ

その FDE、"常駐" が目的になっていませんか?

Palantir が売っているのは常駐ではなく、重要課題を解決するソフトウェアが生む成果です。複雑な課題を正確に解くには現場のコンテクストの正確な把握が欠かせず、顧客の中に入り込む FDE は、そのための最も筋のよいアプローチにすぎません。実際、クライアント常駐型自体は、コンサル会社が古くから実践しています。
目的 売るもの 残るもの よくある 誤解 現場に常駐すること 常駐そのものが目的化している 時間(人月) 準委任契約の単発フィー 何も残らない 人が抜ければ、能力も消える Palantir 成果を出すこと 常駐は、コンテクスト把握の手段 ソフトウェアが生む成果 解いた価値に応じたサブスクリプション 製品に堆積する 解くほど、製品が強くなる 同じ "常駐" でも、売っているものが まったく違う。
Palantir の本質 ▶
常駐の意図
ビジネスモデル
設計能力
まとめ

報酬は、可能な限り サブスクリプション

Palantir のモデルは、SaaS の上にコンサルフィーを積み上げるものではありません。価格は解いた課題の価値に応じて設定され、価値が製品に堆積するほど解約は困難になり、LTV が伸び続けます。ここが、フィー型のコンサルビジネスとは決定的に異なる点です。ただし、問題を解けなければ FDE の人件費を回収できない、というリスクを伴います。
一般的な SaaS 事業者
機能提供型
コンサル事業者
受託型
Palantir
価値連動型
売るもの
製品の機能
合意した成果物
課題解決の成果(ソフトウェア)
課金
機能・席数ベースのサブスクリプション
単発のフィー
解いた価値ベースのサブスクリプション
LTV
単価は固定的
案件ごとに途切れる
解くほど伸び、解約が困難に
リスク
作った機能を売る
受注金額の範囲でコントロール可能
解けなければ人件費を回収できない

※ Palantir にもプロフェッショナルサービスの収入はありますが、売上の1割弱で縮小傾向にあり、収益の柱はサブスクリプションです。

Palantir の本質 ▶
常駐の意図
ビジネスモデル
設計能力
まとめ

FDE に求められるのは、高度な上流の設計能力

核心は、「顧客にとって重要」「自社製品の強みで解ける」「経済的な価値を説明できる」の3つが重なる領域を見極め、そこに確実に成果が出るシステムを設計することです。領域の見極めと設計の質、そして実現スピードが、ビジネスモデルの成否を分けます。結果的に FDE が最も合理的なアプローチになります。
顧客にとって 重要な課題 自社製品の 強みで解ける 経済的な価値を 説明できる 狙う領域 最速で形にする 速やかに成果を生むためには、 報告書をまとめる ではなく プロトタイプを作って、実装する その最速のやり方が、結果として FDE
Palantir の本質 ▶
常駐の意図
ビジネスモデル
設計能力
まとめ

PART 1 のまとめ

  • FDE は手段であって、目的ではありません。本質は、顧客の重要課題をソフトウェアで解決し、その価値を サブスクリプション(価値連動型)で受け取り続ける ビジネスモデルの実現です。
  • いきなり Palantir 型を目指す必要はありません。受託型(単発フィー)とのハイブリッドでリスクを抑えながら、価値連動の比率を段階的に高める道も有効です。
  • いずれにせよ、クライアントに確実に成果をもたらす、上流の設計能力は必須となります。PART 2 では、これを組織能力として実装する方法をご紹介します。
PART 2

VTL 方式で実現する上流工程の標準化

FDE の核となる上流設計を「組織の能力」にする

VTL 方式 ▶
全体像
設計根拠
位置づけ
アプローチ
まとめ
もっと詳しく

VTL 方式の全体像:上流工程の標準化

貴社のクライアントの問題意識をうけ貴社のアーキテクトが Claude Code 等を通じて VTL に接続。知識基盤・トレーニング・サポート・品質管理 の4つを味方に、システム仕様書とプロトタイプを作成し、新しい設計を提案します。
VTL 方式の設計範囲 VTL社の提供するリソース 貴社クライアント (事業担当) ① 問題意識の共有 ⑦ 新しい設計の提案 貴社システム設計者 (アーキテクト) Claude Code 等 AI エージェント VTL の最新知識(MCP) トレーニングサイト VTL サポート 品質管理チーム ② 指示を出す ④ VTLに基づく返答 ③ VTL の最新知識を取得 VTL 方式を学ぶ(適宜) 相談する(適宜) ⑤ システム仕様書・プロトタイプを作成 ⑥ 品質保証 設計根拠 ISO/IEC/IEEE 15288 ISO/IEC/IEEE 29148 ISO/IEC/IEEE 42010 ISO/IEC/IEEE 12207 ISO/IEC 25010 特許第6934696号
VTL 方式 ▶
全体像
設計根拠
位置づけ
アプローチ
まとめ
もっと詳しく

VTL 方式のスコープと流れ

国内ではあまり知られていませんが、システム開発の上流には "世界標準の作り方" がすでに存在します。失敗の許されない防衛・宇宙開発の領域で 60年以上 磨かれてきた、システムズエンジニアリングの国際標準群です。ただ、そのままでは重厚で、一般のソフトウェア開発ではほとんど使われてきませんでした。VTL 方式は、これらの標準群を、最先端のソフトウェア開発で活用できるように、実務目線で軽量化・調整(テーラリング)した独自のメソドロジーです。
ISO/IEC/IEEE 15288 が定める開発プロセス(テクニカルプロセス) ビジネス・ ミッション分析 ステークホルダ 要求定義 システム 要求定義 アーキテクチャ 定義 設計定義 実装 統合 検証 移行・ 妥当性確認 運用・保守 ・廃棄 + プロトタイプによる 検証・妥当性確認 ◀ ここまでが上流設計 = VTL 方式の範囲 ここから先は、貴社がすでに持つ開発プロセス ▶

※ 要求の書き方は ISO/IEC/IEEE 29148、アーキテクチャの描き方は ISO/IEC/IEEE 42010、品質の決め方は ISO/IEC 25010 に基づき、最上流には当社特許(特許第6934696号・仮説生成構造)を組み込んでいます。

防衛・宇宙開発で磨かれた "正しいシステムの作り方" を、AI時代の実務へ ── それが VTL 方式です
VTL 方式 ▶
全体像
設計根拠
位置づけ
アプローチ
まとめ
もっと詳しく

VTL 方式の位置づけ:上流の ①②③ を、貴社に実装する

貴社のクライアントは、次のユースケースを果たすために 貴社 を使います。④実装と運用・保守は、すでに貴社の組織能力。VTL 方式が新たに実装するのは、これまで属人的だった 上流の①②③ です。
貴社(法人向け SaaS・パッケージ事業者) ▼ VTL 方式で新たに実装する(上流) ▼ すでに貴社にある組織能力 ① 固有の課題を特定する ② 解決策を検討する ③ 解決策を設計する ④ 実装する 組織能力あり ✓ 運用・保守する 組織能力あり ✓ 貴社クライアント (事業担当)
VTL 方式 ▶
全体像
設計根拠
位置づけ
アプローチ
まとめ
もっと詳しく

FDE の標準アプローチ(12週間)

貴社のアーキテクトがクライアントの現場に入り込み(FDE)、As-Is の可視化 → To-Be 設計 を約3ヶ月・12週間で完了する標準アプローチです。密着支援で認識のズレを防ぎ、品質を高めます。
分析・定義
ドキュメント作成
プロトタイプ
統合AD
◆ マイルストーン
工程
W1
W2
W3
W4
W5
W6
W7
W8
W9
W10
W11
W12
設計対象のシステムの 境界線 を明らかにする成果物イメージ ↗
境界・Context分析
システム利用者の ユースケース を特定する成果物イメージ ↗
UC特定
各ユースケースの 現状の流れを可視化 し、問題を特定する成果物イメージ ↗
As-Is 復元・可視化
各ユースケースの あるべき流れ を定義する成果物イメージ ↗
To-Be 定義
◆ W8 | To-Be像 確定
ユースケースごとに、BMA から AD の仕様書 を作成する成果物イメージ ↗
BMA → StRS/SyRS → AD
⑤仕様書 ⇄ ⑥プロトタイプ を行ったり来たり(反復)し、W12で同時Fix
作成した仕様書から プロトタイプ を作成し、To-Be像を具体化する成果物イメージ ↗
プロトタイプ作成 → V&V
◆ W12 | 仕様書・プロトを同時Fix・開発チームへ引き渡し
統合アーキテクチャ として To-Be 全体像をまとめる成果物イメージ ↗
統合AD
VTL 方式 ▶
全体像
設計根拠
位置づけ
アプローチ
まとめ
もっと詳しく

本資料のまとめ

  • FDE は手段であって、目的ではありません。本質は、顧客の課題を解き、解を自社製品に堆積させ、価値に応じた利用料を受け取り続ける ビジネスモデルへの転換です。
  • 多くの会社に欠けているのは、属人化した 上流工程(課題の特定・解決策の検討・設計)の標準化です。VTL 方式は、国際標準を実務目線でテーラリングしたメソドロジーで、この上流工程を貴社の組織能力として実装します。
  • 実装と運用保守の能力をすでに持つ貴社に、この上流工程が加われば、"堆積する価値" のループが、貴社の製品と顧客基盤の上で回りはじめます。
VTL 方式 ▶
全体像
設計根拠
位置づけ
アプローチ
まとめ
もっと詳しく

もっと詳しく知りたい方へ

本資料でご紹介したのは、考え方の全体像です。詳細版では、VTL 方式の 成果物サンプル と、VTL との具体的なパートナーシップの実現方法(立ち上げまでの流れ・FAQ) をご覧いただけます(無料)。

▼ 以下のフォームから、そのままご請求ください(無料)

フリーメールはご利用いただけません。法人メールアドレスをご入力ください。
※ ご登録情報は VTL のプライバシーポリシー に基づき適切に管理します

📩 パートナーシップのご案内をお送りします

下記フォームをご送信いただくと、ご登録メールアドレス宛に
パートナーシップのご案内(Web版)のURL をお送りいたします。

フリーメールはご利用いただけません。法人メールアドレスをご入力ください。
※ ご登録情報は VTL のプライバシーポリシー に基づき適切に管理します
01 / 01