■ 1. FDEと受託開発の違い
- 違いの核心:
- 作業内容は外注の受託開発部隊と似ている
- 違いは何に対して責任と報酬が紐づくかにある（Gartnerの整理）
- 成功の定義:
- 受託開発は契約どおりの納品を成功とする
- FDEは事業成果と本番環境の安定稼働を成功とする
- 報酬の測り方:
- 受託開発は工数やマイルストーンで測る
- FDEは実現した価値で測る
- 開発の進め方:
- 受託開発は要件定義、開発依頼、納品の順に進める
- FDEは現場に入り込み、リアルタイムで作って直す
- アクセス権限:
- 受託開発は顧客環境の一部のみに触れ、ベンダー製品は基本的にブラックボックス
- FDEは顧客環境とベンダー自身のコードベースの両方にフルスタックでアクセスする
- 主な対象:
- 受託開発は要件が固まった個別開発を対象とする
- FDEは製品知識と現場への密着が必要な、手探りの課題を対象とする
■ 2. ベンダー製品の中身に触れる点
- 受託開発の通常の形:
- 顧客の要望に合わせ、製品の外側で作り込む
- FDEの形:
- 製品の開発元の人間が現場に常駐し、必要なら製品側のコードも直す
- 現場で見つけた課題を製品のコア機能に反映することが理論上可能
- Gartnerの予測:
- 2028年にかけて、繰り返しのニーズをコア製品の機能に転換できる案件は20％未満
- 本来の姿を実現できている案件が少ないことを意味する
- 元の概念:
- 顧客の現場に自社エンジニアを送り込むPalantirのやり方が広めたとされる
- この点は記事ではなく一般知識に基づく
■ 3. FDEウォッシング
- 実務上の実態:
- 多くのベンダーがFDEを実装支援やAIコンサルの言い換えとして使っている
- 成果責任も価値連動の報酬もなく工数で請求するなら、普通のプロフェッショナルサービスにすぎない
- 定義上は違っても名前だけ変えた受託開発が多く、契約条件を見ないと区別がつかない
- 見分けるチェックポイント:
- 報酬が工数やマイルストーンか、成果連動か
- ベンダーのコードベースに触れる体制があるか
- 知識移転と終了計画が契約に入っているか
- 入っていなければ依存し続けるリスクが高い
■ 4. アジャイル開発との関係
- 進め方の重なり:
- 現場に入り込み作って直すを繰り返す進め方は、アジャイル（XP、内製チーム、顧客常駐型開発）がずっと行ってきたこと
- 顧客と同じ場所で働き、短いサイクルで作って検証する
- 要件を最初に固めず、現場のフィードバックで形を変えていく
- 開発依頼のチケットを経由せず、その場で反復する
- Gartner自身も、共通パターンはエンタープライズソフトウェアでおなじみのもので、新しいのは期待の過熱だけだとする
- 手法と提供モデルの違い:
- アジャイルはどう作るかの開発手法で、責任の所在や報酬の決まり方を規定しない
- FDEは提供モデルであり、新しさは契約、責任、権限の構造にある
- アジャイル受託でも工数ベースの準委任契約（SESやラボ型）は普通にあり、ただのプロフェッショナルサービスにあたる
- 製品コードへの関与:
- FDEは製品の作り手が現場に来るため、現場の課題を製品側に還元できる
- 普通のアジャイル受託は自社製品を持たない開発会社が行うため、この構造がない
- 成果への責任:
- アジャイルチームはスプリントごとに動くものを出す責任を持つ
- 事業成果や本番稼働の安定性まで契約上負うとは限らない
- FDEの構成要素:
- アジャイル的な進め方、製品開発元の人間の参加、成果連動の責任構造の組み合わせ
- 最初の要素は新しくなく、後ろの2つが定義上の違い
- 後ろの2つがなければ、アジャイル受託にFDEのラベルを貼っただけになる
■ 5. 社外の人間が負う成果責任
- 責任の意味:
- 法的な賠償責任ではなく、報酬や評価が成果と連動する設計を指す
- 記事には具体的な契約形態までは書かれていない
- 想定される連動の仕方:
- 固定費を抑え、成果が出たら上乗せまたは分配する成果報酬型の料金
- 本番稼働後の運用品質をSLAや保証で縛る
- 製品のサブスクリプション更新と結びつける
- サブスクリプションとの連動:
- 受託開発との一番の構造的な違い
- 受託は納品で売上が確定するが、製品ベンダーは顧客が使い続けて初めて利益が出る
- 契約解除より前に、継続利用されないという形で痛みが来る
- 成果責任の限界:
- 事業成果は顧客側の組織、データ、市場にも左右され、ベンダーに全責任を負わせるのは難しい
- 成果報酬にするとベンダーは案件を選別する
- 成果の定義と帰属をめぐって揉めやすい
- 最悪の帰結は契約終了か報酬減額であり、構造はアジャイル開発と同じ
- アジャイルとの比較:
- アジャイル開発でも成果連動の契約は設計できる
- 一般的なアジャイル受託は準委任（工数ベース）で、成果リスクは顧客が持つ
- FDEの理想はそのリスクの一部をベンダーが引き受ける契約だが、成立するのは契約をそう作ったからである
- 成果連動の契約条項がなければ、FDEを名乗っても従来の受託と区別がつかない
■ 6. コンサルとの関係
- 成果へのコミット部分:
- 取り出せば実態はコンサル、あるいはアウトカム型のマネージドサービスに近い
- Gartnerも、スコープが明確なら従来型サービスやパートナー支援の方が費用対効果が高い場合があるとする
- コンサルとの違い:
- コンサルの成果物は通常提言や設計で、本番に載せるところまでは担わない
- FDEは本番環境で動くものを作り、安定稼働させるところまで入る
- FDEは製品のコードベースと、それを書き換える権限を持つ
- FDEの本質:
- 成果にコミットするコンサル的な契約と、製品開発元のエンジニアリング能力の合成
- どちらか片方だけなら既存の枠に収まる
- 合成が成立するのは製品ベンダーだけ
- 自社製品を持たない開発会社やコンサル会社が名乗れば、ただのコンサル兼開発になる
- 実態としての捉え方:
- 新しい職種や手法の誕生ではない
- 製品ベンダーが導入支援を成果連動のサービスとして売る形が、AI分野で目立ってきたもの
■ 7. FDEの難しさ
- 個人にかかる負荷:
- 経営課題を成果指標に落とすコンサル力と、本番で動くものを作る開発力は鍛え方も評価軸も違い、両方が高水準の人は希少
- 現場で信頼を得る対人スキルと、製品コードを直す権限に見合う設計判断も要る
- 成果に連動する立場のため、失敗時の精神的プレッシャーが受託より重くなりがち
- 組織としての難しさ:
- 人材が希少で同時に抱えられる案件数が限られ、スケールしない
- これが割高な料金の背景になる
- 現場の課題を製品に還元するには、FDEと製品開発チームの間の回路が必要
- 回路が機能しなければ、FDEはただの高単価な個別対応要員になる
- 評価制度の難しさ:
- 工数で測れない
- 成果は顧客要因に左右される
- 製品への貢献は間接的
- 帰結:
- 質を保てるベンダーは多くないというGartnerの見方は自然
- 名乗るのは簡単でも実質を伴わせるのは難しく、FDEウォッシングが起きやすい構造
- 顧客側の確認事項:
- FDEが付くこと自体を価値と見ない
- 実際に両方の能力を持っているか、ベンダー内に製品へ還元する回路があるかを確認する
■ 8. 混成チーム化と残る違い
- 現実の姿:
- 多くの案件で実態はコンサルと開発者の混成チームになり、外からは受託と変わらない
- チームの形以外に残る3つの違い:
- 誰が送り込むか（製品の開発元か第三者か）
- 製品コードに触れ、現場の課題を製品側に直せるか
- 売上が納品で確定するか、継続利用や成果に連動するか
- 3つが揃わなければ受託と何が違うのかという話に戻る
- 新しい言葉が出てきた理由:
- AIエージェントは業務への組み込み、データ、運用ルールとの擦り合わせが成否を決める
- 標準的な導入手順がまだ固まっていない
- そのため製品を一番知る人間が現場に入るやり方に価値が出る
- 手法の発明というより、製品が未成熟な時期にベンダーが導入支援を抱え込まざるを得ない状況の表れという面もある
- 顧客にとっての実用的な見方:
- FDEかどうかより、3点が契約と体制に入っているかを見るほうが早い
- 入っていなければ単価が高いだけの受託の可能性がある
- それはGartnerが予測する高コストなFDE依存に陥る典型パターン
- Gartnerの記事は新概念の解説というより、既存の受託の言い換えへの注意喚起として読むほうが実態に近い
■ 9. ラベルと誠実さ
- パッケージと呼ぶ利点:
- 実態が混成チームなら、コンサルと開発のパッケージと呼ぶほうが顧客は何を買うか理解しやすい
- 期待値もずれない
- ラベルが曖昧な場合の問題:
- 顧客はFDEという言葉から成果責任や製品への還元を期待しがちだが、契約に入っていないずれが起きる
- ベンダーは戦略的に聞こえることで単価を上げられる
- 中身が伴わなければ、顧客の不信と高コストなのに自立できない状態だけが残る
- ベンダー側の言い分:
- パッケージと呼ぶと受託の価格競争や工数比較に巻き込まれる
- 成果連動や製品還元を本気で行うベンダーにとって、FDEは既存の受託と差別化する看板
- 名前を変えることが、評価制度、採用、製品チームとの連携を設計し直す動機になる
- ただしこれは実質が伴う場合に限り、ラベルだけ使うなら不誠実と言われても仕方がない
- 誠実さの基準:
- ラベルではなく契約書に何が書いてあるか
- 成果責任、報酬の連動、IPと知識移転、終了計画が明記されていれば、名前が何であれ誠実
- これらがなければFDEでもパッケージでも同じで、後者のほうが正直
- Gartnerが初日から終了戦略、IP、知識移転のガイドラインを求めるのはこのため