「FDEはSIerや受託開発と何が違うのか」という疑問は、FDE（Forward Deployed Engineer、海外でこう呼ばれる型については姉妹記事「FDEとは何か」で詳しく解説しています）という言葉に触れた事業責任者の多くが最初に抱くものです。この比較自体は目新しいものではなく、日本語の解説記事も既にいくつか存在します。ただしその大半は、IT開発全般を対象にした「請負と準委任の違い」「常駐か非常駐か」といった抽象的な整理にとどまっています。実務でSIerや制作会社に発注した経験がある事業責任者にとって知りたいのは、もう一段具体的な話のはずです。自社が発注しているのは基幹システムの刷新ではなく、サイトのLP追加、CRMのワークフロー整備、コンテンツの量産、営業・マーケ業務の自動化といった、日々動き続けるマーケティング・営業の実装です。この領域に対象を絞ったとき、受託開発という仕組みはどこまで機能し、どこから苦しくなるのか。本稿ではこの一点に絞って比較します。
受託開発という仕組みがどう回っているか
SIerや制作会社に発注する受託開発は、要件を確定し、見積もりを出し、契約を結び、開発し、納品し、検収するという一連の工程を、ひとつの区切りとして扱う仕組みです。経済産業省のモデル契約書を基に、独立行政法人情報処理推進機構（IPA）が見直して公開した「情報システム・モデル取引・契約書」は、この工程を段階ごとに分け、それぞれの段階でユーザー企業とITベンダーがどのような責務を負うべきかを整理したモデル契約のひな形です（参照：IPA「情報システム・モデル取引・契約書（第二版）」(2020年)）。このモデルを解説した法律専門メディアの記事によれば、要件定義のように「工程を開始する時点で成果物が具体的に想定できない」段階と、詳細設計や製造・テストのように成果物の形が既に固まっている段階とでは、適切な契約類型が異なるとされています（参照：BUSINESS LAWYERS「システム開発契約は請負と準委任どちらを使う？」(2023年)）。契約形態や費用の建て方そのものについては別記事「FDE型支援の費用感と契約形態」で詳しく扱っているため、本稿では立ち入りません。
ここで押さえておきたいのは、この仕組みが機能する条件です。受託開発が強いのは、着手前に要件をひとつの塊として確定でき、その確定した要件が完成まで大きく動かない仕事です。基幹システムの刷新、業務フローが明確な業務システムの構築、仕様の決まった単発のコーポレートサイト制作などがこれにあたります。要件を固める作業には手間がかかりますが、いったん固めてしまえば、見積もりと契約に基づいて計画通りに進められます。発注側は仕様書と検収基準さえ用意すれば、あとは納品を待つという進め方ができます。裏を返せば、この仕組みの強さは「要件が動かない」という前提の上に成り立っています。要件が動けば、そのたびに見積もりの出し直しと契約変更の手続きが必要になり、仕組みそのものが持つ強さが弱さに転じます。
マーケ・営業領域で受託が苦しくなる理由
マーケティング・営業の実装は、この「要件が動かない」という前提が最初から成り立ちにくい領域です。理由は大きく三つあります。
一つ目は、要件が高い頻度で変わることです。広告の反応、商談での顧客の反応、競合の動き、経営会議での方針転換など、マーケ・営業の現場は外部環境の変化を絶えず受け止める立場にあります。アジャイルマーケティングに関する2026年の調査では、アジャイルな進め方を実践しているマーケターの89%が、少なくとも月次で計画を見直し調整していると回答しており、これは実践していない層の66%と比べて23ポイントの差があります（参照：AgileSherpas「The 2026 State of Agile Marketing Report」(2026年)）。同調査は、変化に対応できるチームとそうでないチームの違いは、常に四半期遅れで動いているかどうかに表れると指摘しています。半年前に確定した要件のまま開発が進む受託の進め方と、月次どころか週次で計画が動くマーケ・営業の現場感覚とは、そもそも時間軸が噛み合いません。
二つ目は、成果物が小さく、かつ数が多いことです。基幹システムの刷新であれば、要件定義から検収までを一つの大きなプロジェクトとして区切る意味があります。しかしマーケ・営業の実装は、LPを一本追加する、CRMの入力項目をひとつ整理する、ナーチャリングメールの文面を差し替える、レポートの自動集計を一つ組む、といった小さな作業の積み重ねです。この一つひとつを個別の受託案件として発注すると、案件ごとに見積もり・契約・検収という重い手続きを繰り返すことになり、作業の小ささに対して手続きのコストが不釣り合いに重くなります。
三つ目は、スピードそのものが価値になることです。マーケ・営業の実装は、正確に作ることと同じくらい、早く出すことに意味があります。キャンペーンの反応が良かった施策を翌週にはLPへ反映する、失注の傾向が見えたらすぐに営業資料を直す、といった動きは、要件を確定してから着手するという受託の進め方とは相性が悪く、確定を待っている間に機会そのものが過ぎてしまいます。
これらの構造は、たとえばシリーズA〜B規模のB2B SaaS企業が、サービスサイトのLP改善を制作会社に受託発注するような場面で表面化します。依頼した時点の要件でいったん見積もりと契約を結んでも、着手までの間に営業側から新しい訴求軸の要望が出たり、広告の反応を見て構成を変えたくなったりします。そのたびに追加見積もりと契約変更の往復が発生し、着手が遅れ、出す頃には市場の状況そのものが変わっている、ということが起こりやすくなります。受託先の対応が遅いわけではなく、要件を先に固定するという仕組みの前提と、要件が動き続けるという仕事の性質が、そもそも噛み合っていないのです。
FDE型の構造はどう違うか
FDE型の進め方は、要件を先に固定するのではなく、現場の優先順位に合わせて作り続けることを前提にしています。海外の解説記事では、FDEの1週間は月曜の顧客との発見の場から始まり、実装に手を動かす時間を挟み、本番環境での対応や不具合対応まで、同じ週の中を行き来する流れで描かれています。プロジェクトが完成した時点で関与が終わるのではなく、本番環境で動き続けるものに継続して責任を持つという性質が、従来型のプロジェクト単位の開発とは異なる点として指摘されています（参照：Exponent「What Is a Forward Deployed Engineer? Complete 2026 Guide」(2026年)）。
この進め方を支えているのが、見積もりより先に動くものを見せるという順序です。要件を書面で確定してから着手するのではなく、まず小さく作って現場に見せ、その反応をもとに次に作るものを決めるというサイクルを、週単位で回します。この週次デモという運び方については、別記事「週次スプリント・週次デモという進め方」で詳しく扱っています。
契約の形も、この進め方に合わせて設計されています。FDE型支援の多くは、成果物の完成を約束する請負ではなく、事務処理の実施そのものを目的とする準委任という契約形態を採り、月額定額という料金の建て方をしています。優先順位が週ごとに変わっても、そのたびに契約を結び直す必要がなく、変更そのものが契約の範囲内の出来事として扱えるためです。この契約形態の詳しい仕組みと費用の考え方は、前述の「FDE型支援の費用感と契約形態」にまとめています。
比較表
マーケ・営業の成果物という同じ土俵で見たとき、受託開発とFDE型支援の違いは次のように整理できます。
| 観点 | SIer・受託開発 | FDE型支援 |
|---|---|---|
| 責任の形 | 成果物の完成を約束する（請負が基本） | 現場での稼働・伴走の質に責任を持つ（準委任が基本） |
| 変更への強さ | 弱い。要件変更のたびに見積もり・契約の出し直しが必要 | 強い。優先順位の変更は契約の範囲内で吸収できる |
| スピード | 要件確定を待ってから着手する | 小さく作って見せながら、動きつつ決めていく |
| 向いている仕事 | 仕様が動かない単発の制作物・基幹システムの刷新 | 優先順位が動き続けるマーケ・営業の継続的な実装 |
どちらを選ぶべきかの判断軸
この比較から導ける判断軸は、どちらが優れているかではなく、頼みたい仕事の性質がどちらに近いかという見極めです。三つの問いに置き換えると判断しやすくなります。一つ目は、要件を今から半年後も同じ形で説明できるかどうかです。説明できるなら受託が向いており、説明できない、あるいは半年の間に確実に変わると分かっているなら準委任・FDE型が向いています。二つ目は、成果物がひとつの大きな納品物か、それとも小さな積み重ねかです。ひとつの完成物を検収して終わりにできる仕事は受託向き、日々の小さな実装が積み重なっていく仕事はFDE型向きです。三つ目は、着手の判断を誰が握るかです。仕様書という形で先に判断を固定したいなら受託、動くものを見ながら現場で判断し続けたいならFDE型が実態に合います。
具体的な判断の流れを、架空の例で示します。あるB2B SaaS企業が「コーポレートサイトのフルリニューアル」と「CRMに連動したナーチャリングコンテンツの継続制作」という二つの案件を同時に検討しているとします。前者は、会社概要・沿革・採用ページといった掲載内容がすでに固まっており、半年後に大きく変わる見込みも薄いため、一つ目の問い(要件を半年後も同じ形で説明できるか)に「できる」と答えられます。成果物もサイト一式という一つの納品物であり、二つ目の問いにも受託向きの答えが出ます。この場合は、仕様書と検収基準を固めてSIerや制作会社に請負発注するのが合理的です。一方、後者のナーチャリングコンテンツは、商談化率や開封率といった反応を見ながら毎週テーマや訴求を変える性質のもので、一つ目の問いに「半年後も同じ形とは言い切れない」と答えざるを得ません。成果物もメール一通・LP一本という小さな単位の積み重ねであり、二つ目の問いも小さな積み重ね側に倒れます。この場合は、要件を先に固定する受託よりも、優先順位を都度すり合わせながら動くものを積み上げるFDE型・準委任の方が実態に合います。同じ企業の中でも、案件の性質によって答えが変わるという点が、この三つの問いを使う実務上の利点です。三つ目の問い(着手の判断を誰が握るか)についても、リニューアル案件は事前に固めた仕様書通りに進めば十分ですが、ナーチャリングコンテンツの場合は、配信結果を見た営業側の反応を翌週の制作に反映し続ける必要があるため、現場で判断し続ける体制でなければ機能しません。一つの企業が両方の案件を抱えるとき、片方だけを受託に、もう片方だけをFDE型に振り分けるという判断は、決して矛盾ではなく、むしろ三つの問いに沿った合理的な使い分けだといえます。
外注か内製か、あるいは受託かFDE型かという二択そのものの整理については、別記事「AI実装は外注すべきか内製すべきか」でも判断軸を扱っています。実務上は、この二つを使い分けることも十分に成立します。基幹システムの刷新は仕様が固まった時点でSIerに請負で発注し、そのうえに乗るマーケティングサイトやCRM運用、コンテンツの量産、営業・マーケの自動化はFDE型で継続的に進める、という組み合わせは、それぞれの仕組みが得意とする条件に沿った選び方です。
まとめ
- 受託開発は、要件を先に確定し、見積もり・契約・納品・検収という区切りで進める仕組みで、要件が動かない仕事に強みがあります。
- マーケ・営業の実装は、要件が高頻度で変わり、成果物が小さく多く、スピードそのものが価値になるため、要件確定を前提とする受託の仕組みと噛み合いにくくなります。
- FDE型は、現場の優先順位に合わせて作り続け、週次デモで動くものを先に見せ、準委任・月額定額の契約でこの動き方を支えます。
- 判断の軸は、要件が半年後も変わらないか、成果物が一つの大きな納品物か小さな積み重ねか、着手の判断を先に固定したいか現場で決め続けたいかの三点です。
- 基幹システムは受託、マーケ・営業の継続的な実装はFDE型、という使い分けも十分に成立します。
FDEという働き方の定義や、OpenAI・Anthropicが取り入れている背景については、姉妹記事「FDEとは何か」で詳しく解説しています。弊社Respectifyでは、専属チームが準委任・月額定額の形でクライアント企業の現場に入り、要件を先に固定せず、毎週動くものを届けながらマーケティング・営業領域の実装を進めるRespectify STUDIOを提供しています。自社の場合は受託とFDE型のどちらが向いているか、具体的に相談したい方は無料相談からお気軽にお問い合わせください。
