VTL方式 詳細資料
法人向け SaaS・パッケージ事業者さま向け

FDE を、事業の力に変える。

上流設計を標準化する VTL 方式と、その成果物
VTL ・ 2026 年 7 月
本資料について

本資料は、法人向け SaaS・パッケージ事業者さま に向けた、VTL 方式の詳細資料です。

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

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

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

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

本資料では、Palantir 型ビジネスモデルの本質、VTL 方式、成果物イメージ、導入のご案内を、順にご紹介します。

vitaly asia pte. ltd.　代表　片倉 健
CONTENTS

目次

PART 1
Palantir の本質
5常駐の意図
6ビジネスモデル
7設計能力
8PART 1 のまとめ
PART 2
VTL 方式
10全体像
11設計根拠（国際標準）
12位置づけ
PART 3
成果物イメージ
14題材について
15アプローチ（12週間）
16システムの境界
17ユースケースの洗い出し
18見える化と改善（To-Be）
19検証・全体設計へ反映
20動くプロトタイプ
21統合アーキテクチャ
22成果物一覧
PART 4
VTL導入のご案内
24導入モデル
25立ち上げの流れ
26FAQ
27ご相談
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 方式で新たに実装する（上流） ▼ すでに貴社にある組織能力 ① 固有の課題を特定する ② 解決策を検討する ③ 解決策を設計する ④ 実装する 組織能力あり ✓ 運用・保守する 組織能力あり ✓ 貴社クライアント （事業担当）
PART 3

成果物イメージ

QR決済システムを題材に、VTL 方式の実際の成果物をご覧いただきます

成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

題材について

  • これからご覧いただくのは、VTL 方式の実際の成果物サンプルです。クライアントの機密に触れないよう、架空の題材で全工程を再現しています。
  • 題材は、QR決済システムを運営する決済事業者（架空のケース）です。仕様書が古び、属人化した既存システムを想定しています。
  • シナリオは 既存システムの復元・改善。As-Is を可視化して全体像を取り戻し、To-Be を設計して、プロトタイプまで作ります。
成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

FDE は、12週間で何を作るのか

その全体像が、この工程表です。題材の QR決済システムで、この順番どおりに実行しました。次のページから、各工程の 成果物サンプル を順にご覧いただきます（行末の「成果物イメージ ↗」からもジャンプできます）。
分析・定義
ドキュメント作成
プロトタイプ
統合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
成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

システムの"境界"を描く

対象システムを中心に、誰と何がつながっているか（アクター・外部システム）を1枚で可視化します。

QR決済 システム (運営: 決済事業者) 消費者 QRコードで商品代金を支払う利用者 加盟店 QRコードで代金を受け取る店舗 金融機関 発行銀行・収納銀行・カード会社 規制当局 金融庁・PCI DSS・JPQR規格 開発委託先 システム開発ベンダー・SaaS ▼ 本ケーススタディのスコープ (消費者 ⇔ QR決済 ⇔ 加盟店)
成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

"やること"を洗い出す

利用者ごとに「システムで何をするか（ユースケース）」を、抜け漏れなく特定します。

QR決済システム (運営: 決済事業者) 消費者のUC (利用者の機能) 加盟店のUC (店舗の機能) UC1: 商品代金を 支払う UC2: 残高を チャージする UC3: 支出履歴を 確認する UC4: 利用開始・ 初期設定をする UC5: 商品代金を 受け取る UC6: 売上履歴を 確認する 消費者 加盟店
成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

各ユースケースを"見える化"する

ユースケースごとに、現状の流れ（As-Is）を写生して問題を特定し、あるべき流れ（To-Be）を定義します。

# ユースケース アクター As-Is (現状の 5W1H) As-Is の問題 To-Be (あるべき流れ)
1 商品代金を支払う 消費者 消費者が、レジ会計時に、商品代金を支払うため、スマホアプリで QRコードを表示 / 読み取り、ワンタップで承認する サーバーでのオンライン承認が必須。地下・離島・災害時・通信障害時は決済できず、現金に切り替えるか購買を諦める（機会損失・信頼性の課題） 通信不能時にも、事前承認枠（上限5万円）で端末ローカルに承認し、接続復帰後に自動同期・確定する ← 本ケースの改修（次ページから深掘り）
2 残高をチャージする 消費者 消費者が、残高不足時に、追加チャージするため、アプリから 銀行口座連携 / コンビニ現金 / クレジット連携で残高を補充する 残高不足にレジ前で気づき、その場のチャージ操作で会計が滞る 残高が閾値を下回ったら自動チャージ（上限設定つき）できるようにし、レジ前の残高不足を解消する
3 支出履歴を確認する 消費者 消費者が、取引後随時に、支出を即把握するため、アプリで即時履歴を表示、カテゴリ自動分類・期間検索・家計簿アプリ連携が可能 使いすぎに気づくのが履歴を見た後＝事後で、予算管理が消費者の自助努力に委ねられている 予算上限アラートと月次サマリの自動配信を追加する
4 利用開始・初期設定をする 加盟店 加盟店が、サービス申込時に、決済を受け付け可能にするため、Webから一括申込・本人確認書類をアップロード、即日〜数日で利用開始、店頭QRコード看板を受領する 本人確認書類の目視審査がボトルネックで、繁忙期は開通まで数日かかる 本人確認のeKYC化で即日開通率を高める
5 商品代金を受け取る 加盟店 加盟店が、会計時に、代金を受領するため、スマホ / タブレットで QRコードを表示 / 読み取り、即時に決済確認する 通信不能時は受け付け自体ができず、UC1と同じ機会損失が店舗側にも発生する オフライン取引の受領と接続復帰後の同期確認に対応する（UC1改修との対）
6 売上履歴を確認する 加盟店 加盟店が、随時 / 経理処理時に、売上を即把握するため、管理ダッシュボードで即時売上表示、店舗別 / 時間帯別分析・CSV / 会計ソフト連携が可能 オフライン取引の導入後は、同期前の取引が売上に見えず突合が狂う恐れ 未同期取引の可視化と同期状態の表示をダッシュボードに追加する

※ UC1 の問題（オンライン依存）への応答は「既存UC1の改修か、新規UCの追加か」を、復元した全体像を根拠に検討し、既存UC1の改修（v2.0）と判断——目的（商品代金を支払う）が同じなら、UC は同じ。

成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

動かして確かめ、全体設計に反映する

プロトタイプで検証（V&V）した要求を統合ADに反映し、そのまま実装に進める構造になります。

Step.1
プロトタイプで V&V 検証
UC1（オフライン対応改修）のプロトタイプで 検証（Verification）・妥当性確認（Validation）を実施し、V&Vシートに記録
→
Step.2
統合AD に反映
検証を通過した設計を、全体アーキテクチャ（統合AD）に反映
→
次フェーズ
実装フェーズへ
構造化された統合AD を起点に、DD (設計定義書) を作成し、AIと共同で実装する
# ユースケース 1. BMA 2. StRS-SyRS 3. AD プロトタイプ V&V ステータス
1商品代金を支払う (v2.0 オフライン対応改修)完了 ↗完了 ↗完了 ↗完了 ↗完了 ↗改修・完了
2残高をチャージする完了 ↗完了 ↗完了 ↗完了 ↗完了 ↗完了
3支出履歴を確認する完了 ↗完了 ↗完了 ↗完了 ↗完了 ↗完了
4利用開始・初期設定をする完了 ↗完了 ↗完了 ↗完了 ↗完了 ↗完了
5商品代金を受け取る完了 ↗完了 ↗完了 ↗完了 ↗完了 ↗完了
6売上履歴を確認する完了 ↗完了 ↗完了 ↗完了 ↗完了 ↗完了

※ 完了（下線付き）はクリックで成果物サンプル一覧を開けます。

成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

仕様書から、"動くもの"が生まれる

🚀 VTL 方式で構造化したドキュメント（BMA / StRS-SyRS / AD）を、VTLの知識基盤を読み込んだAIエージェントに渡して生成した動作プロトタイプ です。これを実際にステークホルダーにぶつけ、実装前に価値を検証することが重要です。
成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

すべてを"1枚の設計図"に統合する

全UC（UC1〜6 ・ UC1はv2.0改修反映）を1つに束ねた、システム全体のアーキテクチャ（統合AD）。
🔒
CONFIDENTIAL ・ 非開示
統合ADの 記法・構造は、当社独自の表記ノウハウ のため、
本資料では非開示としています。
成果物イメージ ▶
題材
→
アプローチ
→
成果物サンプル

FDE の活動で生まれる、成果物一式

上流設計では、この成果物一式が生まれます。すべて 人とAIが参照できる HTML/MD形式のファイル。納品資産としてクライアントに渡すか、常に最新に維持される "生きた設計基盤" として貴社が提供し続けるかは、貴社の収益モデルに合わせて設計できます。
① 上流分析
📍
コンテクスト分析

システムの境界と、登場アクター・関係性を可視化

P16 スライド →
② 上流分析
👥
ユースケース分析

利用者ごとのユースケースを特定・構造化

P17 スライド →
③ To-Be設計
✨
To-Be像の作成

あるべき流れ（To-Be像）と改修を設計

P18 スライド →
④ 仕様書
📄
仕様書 一式

BMA / StRS-SyRS / AD の構造化仕様書

ドキュメント一覧 ↗
⑤ 検証
🚀
動くプロトタイプ

仕様書から生成した、実機で触れるプロトタイプ

プロトタイプ一覧 ↗
PART 4

VTL導入のご案内

導入モデル・立ち上げの流れ・よくあるご質問

VTL導入のご案内 ▶
導入モデル
→
立ち上げの流れ
→
FAQ
→
ご相談

貴社の FDE チームの立ち上げを、VTLが支援します。

VTL は、FDE モデルの立ち上げを目指す事業者さま を支援します。費用は 月額30万円から。提供内容・条件の詳細は、初回の面談でご説明します。
① 費用
💳
月額30万円から

上流を担える人材を1人採用するより、はるかに小さく始められます

月額サブスクリプション
② ご提供
🔑
VTLのリソース一式

知識基盤・トレーニング・サポート・品質管理への アクセス権

内容の詳細は面談で
★ まずはここから
③ 進め方
💬
初回面談

FDEの要否から、率直にお話しします。
売り込みの場ではありません

50分・オンライン・無料
初回面談を申し込む →
VTL導入のご案内 ▶
導入モデル
→
立ち上げの流れ
→
FAQ
→
ご相談

ご相談から、事業立ち上げまで

初回ミーティングでは、FDEの要否・目的・拡大の時間軸や規模といった根本から、率直にすり合わせます。その上で、まずは小さく1案件(1ユースケース)から共同で走らせ、成果を見ながら本格化します。
STEP 1
💬
ご相談
FDEの要否・目的・
拡大イメージをすり合わせ
初回50分〜
→
STEP 2
📝
座組みの合意
役割・契約・
報酬を設計
NDA・契約
→
STEP 3
🚀
パイロット案件
まず1UCで
共同実践
小さく1案件
→
STEP 4
📊
本格展開
成果を見て
事業として拡大
継続・拡大
VTL導入のご案内 ▶
導入モデル
→
立ち上げの流れ
→
FAQ
→
ご相談

よくあるご質問

ご検討にあたり、よくいただくご質問です。こちらに記載のない疑問点につきましては、初回の面談でお気軽にお尋ねください。
Q. 貴社と競合しませんか？

VTL は方法論の研究事業者であり、コンサルティング事業は基本的に行いません（研究目的を除く）。したがって、貴社と競合することはありません。

Q. どんな人材・体制が必要ですか？

目安として、中堅クラスの人材 2〜3名から始められます。その上で、私たちは 成果を出せる本気の体制 を重視します。片手間ではなく、事業として本腰を入れて取り組める企業さまをご支援します。

Q. 費用はどのくらいですか？

月額30万円からです。提供内容や契約条件の詳細は、初回の面談でご説明します。

Q. クライアントの秘密情報の取り扱いは？

貴社およびクライアントの秘密情報は、契約によりしっかり保護します。品質管理・レビューの過程で当社が触れる情報も同様です。

Q. VTLは、同じ領域で競合にも提供するのですか？

むやみに競合他社へ提供することはありません。領域での優先的な取り扱いは、状況に応じて個別にご相談します。

初回面談を申し込む →
VTL導入のご案内 ▶
導入モデル
→
立ち上げの流れ
→
FAQ
→
ご相談

まずは一度、ディスカッションをしませんか？

FDE モデルの立ち上げにご関心があれば、下記フォームからお申し込みください。初回はオープンなディスカッションの場（50分・オンライン・無料）です。売り込みの場ではありません。

▼ 以下のフォームから、そのままご相談ください

フリーメールはご利用いただけません。法人メールアドレスをご入力ください。
※ お問い合わせへの対応は、日本における代理店が行う場合があります。
※ ご登録情報は VTL のプライバシーポリシー に基づき適切に管理します
01 / 01