スタートアップの開発外注ガイド【2026年版】シード/シリーズA別の体制5つ、MVPの削り方、費用の上限設計

「開発会社の見積もりが、調達額の3分の1だった」——シード調達を終えたばかりの創業者から、こうした相談をよく受けます。自社で採用するには時間がない。外注すれば早いと聞くが、失敗談も同じくらい耳に入る。安いところに頼めば作り直しになりそうで、高いところは払えない。最初の1本をどこに、いくらで、どういう形で頼むかは、次のラウンドまでの時間を左右する判断です。

結論から言うと、スタートアップの開発外注は「外注か内製か」の二択ではありません。資金調達のフェーズごとに、どこまでを外に出し、何を自社に残すかを決める問題です。シードは検証したい仮説を1つに絞ってMVPを最短で出すこと、シリーズAはスケールと採用に耐える品質と引き継ぎ性を確保すること。そして全フェーズを通じて、ソースコードの権利・リポジトリ・設計判断の記録の3点だけは、必ず自社に残してください。

この3点さえ残っていれば、外注を続けることも、内製に戻すことも、別の会社に移すことも、後から自社の都合で選べます。逆に、ここを預けたまま進むと、改修のたびに同じ相手に見積もりを取るしかなくなり、価格交渉の主導権まで失います。外注で本当に怖いのは費用ではなく、この主導権の喪失です。

本記事では、シード/シリーズAで取れる開発体制5つとフェーズ別の向き不向き、外注でMVPを作るときの削り方と落とし穴、知的財産と技術的負債への備え、バーンレートから逆算する開発費の上限設計、よくある質問の順に解説します。体制の比較とフェーズ別の推奨は、そのまま社内説明の資料に使える表にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。スタートアップの失敗相談に共通するのは、「一式作ってください」と頼んで機能が膨らんだ案件と、安さで選んでコードを誰も把握できなくなった案件の2つです。この記事を読み終えるころには、自社のフェーズでどこまで外に出すか、いくらを上限にするかが判断できるはずです。

シード/シリーズAで取れる開発体制は5つ——CTO採用、業務委託、受託外注、ラボ型、ハイブリッド

スタートアップが最初のプロダクトを作るとき、選べる体制は大きく5つです。正社員として採用する、個人に業務委託する、開発会社に一括で外注する、専属チームを月額で確保する、そしてこれらを組み合わせる。どれが優れているという話ではなく、自社が今いる資金調達フェーズで何を証明しなければならないかによって、正解が入れ替わります。まずは5つを同じ物差しで並べて比べてください。

体制5つの比較表(立ち上がり・固定費・スケール余力・撤退コスト・社内への蓄積)

比較の軸は5つです。開始までの時間(立ち上がり)、毎月出ていく金額の性質(固定費)、人を増やせる余地(スケール余力)、やめるときの負担(撤退コスト)、そして技術の知見が社内に残るか(蓄積)。この5軸で見ると、体制ごとの性格がはっきりします。

同じMVPでも、開発会社にチームごと発注する場合と、フリーランスに単職種で発注する場合とでは、総額の桁が変わります。この差は「安いか高いか」ではなく、要件定義・PM・デザイン・QA・インフラ設計といった職能が含まれているかどうかの差です。金額だけを横に並べて比べるのは失敗のもとです。

フェーズ別の向き不向き——プレシードは試用、シードは検証速度、シリーズAは引き継ぎ性

フェーズごとに、証明すべきことが違います。プレシードで必要なのは、共同創業者候補やエンジニアとの相性を確かめることです。小さな予算で、副業エンジニアや知人に1〜2か月試してもらう形が現実的で、これは外注というより人材のトライアルに近い性格を持ちます。

シードで証明すべきは、「この課題に、お金を払ってでも解決したい人がいるか」です。プロダクトの完成度ではなく、仮説が当たっているかを最短で確かめることが次の調達の材料になります。ここでは検証速度が最優先で、正社員採用を先に回すと、採用に数か月、立ち上がりにさらに数か月を使い、その間も人件費が固定で出ていきます。業務委託かラボ型で、月額の上限を決めて素早く動かすほうが合理的な場面が多くなります。

シリーズAでは求めるものが変わります。ユーザー増に耐える設計、機能拡張のしやすさ、そして自社のエンジニア採用とかみ合う体制です。この時期から正社員採用が本格化するため、入社した社員が既存コードを読んで拡張に加われるかどうかが効いてきます。FIXITも、シリーズA前後の委託先選びの軸は「内製チームと並走できるか」「採用が進んだ段階で内製へ滑らかに引き継げるか」だと整理しています。外注を続けるにせよ内製比率を上げるにせよ、いつでも移れる状態を保ったまま進められる相手を選ぶことになります。

外注に出せないもの——「何を作るか」の判断役は社内に残す

5つのどの体制を選んでも、外に出せないものが1つあります。「誰のために、どんな課題を解決するために、最低限どの機能が必要か」という判断です。ここが決まっていない状態で発注するのは、開発の依頼ではなくコンサルティングの依頼です。実際、インテグラビットも「プロダクト戦略は外注先が代わりに考えてくれない」と明言しています。

この判断役は、エンジニアである必要はありません。必要なのは、当社が標準にしている週1回の定例の場で成果物を見て、次の優先順位を決められることです。「持ち帰って確認します」が続くと開発の手が止まり、短納期・低コストという当初の利点がそのまま消えます。社内に置けない場合は、伴走するPMやテックリードを別途契約するか、PM込みの体制を選んでください。当社がパターンA(日本人PM/ブリッジSE+エンジニア)を推奨しているのは、要件の細部の言語化・指示・進捗管理までを日本側が巻き取り、発注側の仕事を優先順位の判断に絞るためです。

私が「まず採用を」と勧める案件——外注が向かない3つの条件

2018年からホーチミンで約100社の相談に乗ってきましたが、外注をお勧めしない案件もあります。1つ目は、プロダクトそのものが技術的な差別化の中心で、アルゴリズムやデータ構造の設計が事業の競争力になっている場合です。この中核だけは社内に置くべきで、外部に出すと事業の生命線を預けることになります。

2つ目は、週1回の判断の場すら社内に作れない場合です。判断役が不在のまま稼働だけが進むと、3か月後に「想定と違うものができた」という結末になります。3つ目は、1〜2か月で完全に作り切って終わり、その後の改修予定がない案件です。これは請負で成果物と費用を区切るほうが素直で、継続前提の体制を組む意味がありません。当社でも、この3つに当てはまる相談には率直にその旨をお伝えしています。体制が決まったら、次は「何を作るか」を削る作業に入ります。

外注でMVPを作る——仮説を1つに絞る、機能を削る、作らない判断

体制が決まったら、次は範囲を決める作業です。スタートアップの外注で費用が膨らむ原因のほとんどは、単価ではなく範囲にあります。MVPを「小さめの製品」だと思って発注すると、機能は必ず増えます。ここでは、仮説の絞り込み方、機能を削る基準、そして「作らない」という判断の使い方を順に整理します。

検証したい仮説を1つに絞る——MVPは製品の縮小版ではなく実験

MVPは、製品を小さくしたものではありません。ある仮説が正しいかどうかを確かめるための実験です。だから最初に決めるべきは機能ではなく、「次の3か月で、何が分かれば前に進めるのか」という問いです。問いが1つに定まれば、残す機能は自然に決まります。

よくあるのは、「ユーザー登録、課金、管理画面、外部サービス連携をひととおり」という発注です。これをすべて初期リリースに入れると、期間も費用も倍近くに膨らみます。FIXITも、検証すべき仮説が固まらないまま「とりあえず一式作ってください」と発注するのが失敗の典型だと指摘しています。答えを決める前にテストの全問を埋めにいくようなもの、という表現はそのとおりだと感じます。

当社がお手伝いした介護記録SaaS「CareViewer」も、日本語対応のブリッジSE1名とフルスタックエンジニア2名という小さな体制から始まり、週次で優先順位を決めながら機能を足していきました。健康管理サービスのHELTEQもフルスタック4名で迅速に立ち上げています。最初から完成形を発注した案件より、小さく出して毎週決め直した案件のほうが、結果的に早く形になるというのが実情です。

機能を削る基準と「作らない判断」——手作業と既製SaaSで代替する

機能を削るときの基準は1つで十分です。「この機能がなくても、決めた仮説を検証できるか」。検証できるなら外します。判断に迷ったら、次の3つの代替手段を検討してください。

「作らない判断」は、削減ではなく順番の選択です。当たってから足すほうが、外した機能に開発費を使ってしまうより安全で、資金の効率も上がります。逆に、最初から全部入りで作ると、当たらなかった機能の分だけランウェイが短くなります。

なお、MVPの費用は、他社メディアが掲げる相場レンジで測っても自社の金額には近づきません。金額を決めるのは、初回に入れるコア機能の数と、決済・管理画面・権限設計といった運用層をどこまで含めるかです。まず初回に入れる機能を絞り込んでから、体制と予算を決めると話が早くなります。

外注でMVPを作るときの落とし穴5つ(一式発注・安さ優先・スコープクリープ・月次確認・デモの目的化)

外注でのMVP開発は、失敗の型がほぼ決まっています。私が相談を受けた中で繰り返し出てくるのは、次の5つです。

1. 一式発注: 仮説が固まらないまま「必要な機能すべて」を頼む。契約書のスコープが曖昧になり、後から「入っていた・入っていない」の水掛け論になります。成果物は画面単位で定義してください
2. 安さ優先: 単価だけで選んだ結果、コードがブラックボックスになり、改修のたびに元の委託先に頼るしかなくなる。乗り換えも値段の交渉もできなくなった状態は、スタートアップにとって要注意です
3. スコープクリープ: 開発中の「ついでにこれも」が積み重なり、期間も費用も見えない形で膨らむ。追加は次のバージョンに回す規律を、発注側が主導して守る必要があります
4. 月次でしか成果物を見ない: 認識のずれが発覚したとき、1か月分の作業が手戻りになります。週次で受け取れば、ずれは最大1週間分で止まります
5. 投資家向けデモを目的にする: 見栄えの良い画面を優先すると、学びが得られないまま資金と時間を使います。デモは副産物であって目的ではありません

私が見てきた失敗相談で最も多いのは、1と2の組み合わせです。一式で安いところに頼み、3か月目にできあがったものが想定と違い、作り直しでさらに2か月を失う。どちらも、発注前に範囲と確認のリズムを決めておけば防げたものです。

週次で回すリズムと、発注側が用意する受け入れ基準

発注前に用意してほしいものは2つだけです。1つは、作る範囲を1ページに書き出した機能一覧。もう1つは、「どうなったら完成とみなすか」という受け入れ基準です。粒度は「ログインボタンを押すとメールアドレスとパスワードの入力画面が開く」程度で構いません。

運用は週次で固定します。金曜に動くものを受け取り、月曜に次週の優先順位を決める。この1週間のリズムが、外注でMVPを作るときの最大の安全装置になります。当社の案件でも、週1回の定例と日々のチャットで進め、設計の判断は日本人PMがレビューする形を標準にしています。範囲と確認の頻度を先に決める——これが、外注でMVPを成功させる唯一の準備です。

知的財産と技術的負債——コードの権利、リポジトリ、あとで内製化するための設計

外注で作ったプロダクトが自社の資産として残るかどうかは、技術力ではなく契約と記録で決まります。ソースコードの権利、リポジトリのアクセス権、そして「なぜその設計にしたか」の記録。この3つが手元にあれば、続けることも、移ることも、戻すことも選べます。ここを見落としたまま進むと、資金調達のデューデリジェンスで指摘されてから慌てることになります。

契約で押さえる5条件(著作権の譲渡・リポジトリ・設計判断の記録・ロックイン回避・契約不適合責任)

「納品されたのだから当然自社のもの」とは限りません。受託開発では成果物の著作権がどちらに帰属するかを契約で定めますが、受託側に残る形の契約書も存在します。スタートアップにとってソースコードは事業の中核資産であり、将来の資金調達やM&Aの審査でも権利の所在が問われます。契約前に、次の5つを文面で確認してください。

このうち、実務で最も効くのは2番です。開始直後から発注側のリポジトリに定期的にコードが入っていれば、万一委託先が止まっても成果物は守られます。インテグラビットも、委託先の突然の離脱への対策として同じ点を挙げています。

技術的負債は「速く作ったから」ではなく「記録を残さなかったから」溜まる

技術的負債という言葉は、速度と品質のトレードオフとして語られがちです。しかし私が見てきた案件では、負債の実体は「判断の記録がないこと」でした。なぜこのデータ構造にしたのか、なぜこのライブラリを選んだのか、なぜこの機能だけ別扱いなのか。当時は理由があったはずなのに、書かれていないために誰も触れなくなる。これが負債の正体です。

だから「MVPだから雑でよい」という割り切りは危険です。検証が当たれば、そのコードはそのまま育ちます。捨てる前提の使い捨てコードではなく、速く作れて当たったらそのまま伸ばせるコードを出せる相手を選んでおくと、検証成功後の作り直しという二重コストを避けられます。速度を買うことと、記録を捨てることは別の話です。

判断の記録は、重い設計書である必要はありません。プルリクエストの説明欄に「何を、なぜ、どの案を捨てて」を数行書く運用でも、半年後の自分と、入社したばかりのエンジニアには十分に効きます。

あとで内製化するための設計とドキュメント——当社の品質3点とプルリクエスト運用

当社が標準にしている品質の担保は3点です。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェック。このうち内製化に直結するのが2番目で、すべての変更がプルリクエストとして残るため、誰がいつ何をなぜ変えたかが履歴として蓄積します。発注側のエンジニアがレビュアーとして入れば、外部チームの作業はそのまま社内への技術移転になります。

実務の例では、決済アプリの案件(外部決済サービス連携、二要素認証、ウォレット、帳票のPDF出力)を新規開発から引き継ぎ、リリース後は週次の保守へ移行しました。求人プラットフォーム(応募者管理)も、機能追加と運用を並走させています。いずれも、リポジトリと記録が発注側にある前提で進めているため、体制を増減しても事業側の主導権は動きません。

内製化への移行チェックリストと、移す順番

内製化は一度に全部を移すものではありません。移す順番は、(1)リポジトリと権限、(2)リリース手順と監視、(3)中核ドメインのコード、(4)周辺機能、の順が安全です。移行を判断する目安は次の4つです。社内にレビューできるエンジニアが2名以上いるか。環境構築が手順書だけで再現できるか。直近3か月の変更がすべてプルリクエストとして追えるか。外部チームが抜けても1か月は運用が止まらないか。

このうち1つでも欠けていれば、内製化ではなく並走の期間を先に置いてください。外注か内製かを一度に切り替えるのではなく、判断を社内に、実装を段階的に——この順番を守れているでしょうか。次章では、この体制をいくらで、どういう払い方で維持するかを見ていきます。

バーンレートと開発費のバランス——月額で上限を決める外注の設計

スタートアップの開発費は、金額の大きさより「読めるかどうか」が効きます。総額いくらの一括見積もりは経営計画に載せにくく、追加が出るたびにランウェイの前提が崩れます。月額いくら×何か月という形にできれば、バーンレートの表にそのまま1行として載り、いつ止めるかも自分で決められます。ここでは上限の決め方と、当社の構成を具体的な数字で示します。

調達額・ランウェイから開発費の上限を決める(MVPの市場相場と見比べる)

順番は、機能から積み上げるのではなく、上限から逆算します。手元資金を月々の支出(バーンレート)で割った残り月数がランウェイです。次のラウンドまでに必要な期間を確保したうえで、開発に回せる総額を決め、それを月数で割って月額の上限を出す。この上限を最初に伝えたほうが、開発会社も現実的な体制を提案できます。

上限が必要な体制の月額に届かない場合の選択肢は3つです。範囲をさらに削る、期間を延ばして月額を下げる、単価構造の異なる体制に変える。3つ目がオフショアやラボ型の出番で、同じ人月でも単価が下がる分、同じ予算で人月か期間を増やせます。

総額一括と月額上限の違い——月額で上限を決められる体制との相性

請負の総額一括は、要件が固まっている場合には最も安全な形です。成果物と費用が確定し、完成責任も相手にあります。ただしシード期は仕様が動きます。動く前提の案件で総額を先に固めると、変更のたびに追加見積もりが出て、結局は上限が読めなくなります。

一方、準委任で専属チームを月額固定にするラボ型は、人数と期間を決めた時点で上限が確定します。増員・減員で波を吸収でき、撤退も予告期間の範囲で選べます。ベトナムオフショアではこの形が主流で、オフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)では契約形態の45%をラボ型が占めています。シード期の「上限は決めたいが中身は動かしたい」という要求と構造が合うのは、この形です。

現実的には、初期のMVPを範囲を区切った請負で出し、リリース後の改善を準委任に切り替える組み合わせが、スタートアップの実態と合いやすいという整理が一般的です。契約形態の違いは「準委任 請負 違い」の記事でも詳しく扱っています。

当社の最小構成と単価——日本人PM+2〜3人月で月額約80万円〜、1名から最短2週間

当社の構成を具体的に書きます。最小構成は、日本人PMがフロントに立ち、2〜3人月の開発体制で月額約80万円からです。単価は公開しており、実務3年目安のエンジニアが1,500USD(約22.5万円)、5年で2,000USD、10年目安およびブリッジSEで3,000USD(いずれも1USD=150円換算目安)。当社調べでは市場相場の約2分の1にあたります。2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社や紹介を経由する仲介マージンが乗りません。

体制の動かし方も数字で決めています。1名から契約でき、開始は最短2週間、増員は約1週間、縮小と交代(リプレイスメント)は1か月単位。流れは、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始です。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

シード期の使い方としては、まず1〜2名で3か月動かし、仮説が当たったら増員、外れたら縮小、という運用が現実に即しています。ベトナムとの時差は2時間で、日中の時間帯がほぼ重なるため、週次の判断のリズムも崩れません。まずは自社のランウェイから月額の上限を出し、その数字を持って相談に来てください。上限が先にあるほうが、体制の提案は具体的になります。

スタートアップの開発外注でよくある質問

シードからシリーズAのスタートアップから、相談の場で繰り返し聞かれる質問を5つにまとめました。社内や投資家への説明にもお使いください。

Q1. 開発外注はいくらから頼めますか?

当社の最小構成は、日本人PMフロント+2〜3人月で月額約80万円からです。1名のみの契約も可能で、その場合は職種と経験年数によって単価が変わります(実務3年目安1,500USD、5年2,000USD、ブリッジSE 3,000USD。いずれも1USD=150円換算の目安)。

Q2. CTOがいなくても外注できますか?

できますが、条件が1つあります。週1回の定例で成果物を見て、次の優先順位を決められる人を社内に置くことです。技術者である必要はありません。技術的な判断まで含めて任せたい場合は、日本人PMやブリッジSEを含む体制を選んでください。判断役を誰も置けない状態での発注は失敗のもとです。

Q3. MVPをオフショアで作れますか?

作れます。当社では健康管理サービスや介護記録SaaSの立ち上げを、フルスタック2〜4名の小さな体制から始めた実績があります。条件は、仮説を1つに絞ること、週次で確認すること、日本語で要件を詰める役割(日本人PMまたはブリッジSE)を体制に入れることの3点です。

Q4. 作ったコードの権利は自社のものになりますか?

契約次第なので、必ず契約前に文面で確認してください。当社は成果物の著作権を発注側へ譲渡し、リポジトリは開始時点から発注側の管理下に置く形を標準にしています。詳しくは「知的財産 帰属」の記事でも整理しています。

Q5. 内製化に切り替えるタイミングは?

社内にレビューできるエンジニアが2名以上いること、環境構築が手順書だけで再現できること、直近3か月の変更がプルリクエストで追えることの3つが揃った時期。

まとめ: フェーズで体制を選び、仮説1つまで削り、権利と記録は自社に残す

スタートアップの開発外注は、外注か内製かの二択ではありません。取れる体制はCTO・正社員採用、業務委託・フリーランス、受託外注(請負)、ラボ型(準委任の専属チーム)、ハイブリッドの5つで、立ち上がり・費用の性質・スケール余力・撤退コスト・社内への蓄積の5軸で性格が分かれます。プレシードは人材の試用、シードは検証速度、シリーズAは採用と内製化に耐える引き継ぎ性。フェーズで証明すべきことが変われば、選ぶべき体制も変わります。

MVPは製品の縮小版ではなく実験です。検証したい仮説を1つに絞り、手作業・既製サービス・次のリリースへの先送りで機能を削り、仮説に関係しないものは作らない。そのうえで、著作権の譲渡、開始時点からのリポジトリのアクセス権、設計判断の記録、ロックインしない構成、契約不適合責任の5条件を契約で押さえてください。技術的負債は速く作ったから溜まるのではなく、判断の記録を残さなかったから溜まります。当社は日本人PMの設計レビュー、Gitプルリクエストによるコードレビューの標準化、リリース前ダブルチェックを標準にし、リポジトリと記録が発注側に残る前提で開発を進めています。

費用は総額一括ではなく、ランウェイから逆算した月額の上限で管理してください。当社の最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名から契約でき、開始は最短2週間、増員は約1週間、縮小と交代は1か月単位です。単価は実務3年目安1,500USD(約22.5万円)、5年2,000USD、ブリッジSE 3,000USD(1USD=150円換算目安)を公開しています。MVPそのものの作り方はMVP開発とは、内製と外注の損益分岐はシステム開発は内製か外注かもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、外注すべき範囲の切り分けと概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。