SaaS開発の外注ガイド【2026年版】受託開発との違い、外注範囲の切り方、費用の3階建て、技術論点6つ

「SaaSを外注したいが、普通のシステム開発と何が違うのか分からない」——自社プロダクトを立ち上げようとしている方から、こうした相談をよく受けます。見積もりが会社によって3倍違う、リリース後の費用が書かれていない、マルチテナントは後からでよいと言われた。判断の軸がないまま提案書だけが増えていく、という状態です。

結論から言うと、SaaS開発の外注は受託開発の延長で考えると失敗します。受託開発は決めた仕様の成果物に対価を払い、検収して終わります。SaaSは違います。リリースした日が開発の始まりで、解約されない状態を保つために毎週のように直し続けます。終わりがないので、完成という区切りが置けません。この一点から、契約形態も費用の見方も体制も、すべてが変わります。

やるべきことは4つです。外注する範囲と自社で持つ範囲を切る。契約は請負一本ではなく準委任(ラボ型)を軸に組む。費用は初期開発費・継続開発費・インフラ運用費の3階建てで見積もる。マルチテナント、課金、認証、監査ログ、SLA、バックアップの6点は発注前に方針を決める。この4つを押さえた発注は、2年目に作り直しが発生しません。

本記事では、SaaS開発の外注が受託開発と違う6点、外注範囲の切り方と運用保守の一次受け、請負が向かない理由と準委任(ラボ型)との相性、費用の3階建ての考え方、発注前に方針を決める技術論点6つ、よくある質問の順に解説します。費用は出典ごとに幅があるため、単一の数字ではなく出典を併記した幅で示します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。SaaSの相談で最も多いのは、初期開発だけを請負で作り、改善の行き場がなくなってから来られるパターンです。この記事を読み終えるころには、自社のプロダクトをどの範囲・どの契約・いくらの月次費用で外注すればよいかが判断できるはずです。

SaaS開発の外注が受託開発と違う6点——「作って終わり」が通用しない理由

SaaS開発の外注でつまずく方の多くは、技術選定でも開発会社選びでも失敗していません。受託開発の常識をそのまま持ち込んだことが原因です。受託開発は仕様を決め、作り、検収して終わります。SaaSはリリースした日が開発の始まりで、解約されない状態を保つために直し続けます。この前提の差が、契約・費用・体制のすべてに波及します。まず6点の違いを押さえてください。

受託開発とSaaS開発の対比表(納品・顧客・収益・品質・費用・要件)

SaaSと通常のシステム開発の違いは、突き詰めると「開発の継続性」「不特定多数の顧客企業が同一システムを使うこと」「納品ではなく継続利用で収益が生まれること」の3点です。当社が現場で見ている差も、この3点を6つに分解したものです。

違いの根っこは「終わりがない」こと——完成の定義が置けない

6つの違いは、すべて1つの性質から派生しています。SaaSには完成がない、という性質です。

受託開発では「この仕様どおりに動いたら完成」と定義できます。だからこそ請負契約が成立し、固定価格が出せ、検収という手続きが機能します。SaaSでは、完成の位置に立つのは仕様ではなく顧客です。使われ方を見て機能を足し、使われない機能を削り、解約理由をつぶす。この作業に終わりがないため、「どこまで作れば完成か」を契約書に書けません。

書けないものを無理に書こうとすると、発注側と開発会社の双方が苦しみます。発注側は決めきれない要件を決めさせられ、開発会社は変更のたびに再見積もりを出す。半年後には、当初の見積もりとまったく違う金額と日程になっている。これがSaaS外注の典型的な壊れ方です。

私が見てきたSaaS外注の失敗3つ——初期開発だけ請負、マルチテナント後付け、運用の行き場なし

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきました。SaaSに限ると、相談に来られる時点で起きている問題は3つに集約されます。

1つ目は、初期開発だけを請負で作り、改善の行き場がなくなったケースです。リリースまでは順調でしたが、契約が終わると同時に開発チームも解散し、顧客からの要望に応える手段がない。次の会社を探す間にコードの理解がゼロから必要になり、3か月が空きます。最も多いパターンです。

2つ目は、マルチテナント対応を後回しにしたケースです。最初の顧客1社向けに作り、2社目を入れる段階で「データが混ざる」と判明する。データベース設計と認証設計の根幹に関わるため、後から対応しようとすると大規模なアーキテクチャ改修になります。SaaS開発では業界共通の落とし穴です。

3つ目は、運用の一次受けが決まっていないケースです。障害の連絡先が開発会社なのか自社なのか曖昧なまま公開し、夜間の障害で誰も動かない。稼働率が落ち、解約が出る。

どれも技術の問題ではなく、発注の設計の問題です。逆に言えば、発注前に決めておけば避けられます。次章では、外注する範囲と自社で持つ範囲をどう切るかから見ていきます。

どこまで外注し、どこを自社で持つか——外注範囲の切り方と運用保守の一次受け

SaaS開発の外注で最初に決めるのは、開発会社選びではなく範囲の線引きです。外注できるのは「決めたことを作る力」であり、「何を作るかを決める権限」は事業側にしか置けません。社内にエンジニアがいない場合でも、この線は引けます。ここを曖昧にしたまま発注すると、スコープが開発会社の都合に寄り、2年目に主導権を取り戻せなくなります。

外注しやすい範囲と、自社で持つべき範囲の一覧表

当社の場合、Webサイトはヘッドレスコンテンツ管理システムで構築し、求人プラットフォームは応募者管理まで含めて実装し、AIチャットボットは大規模言語モデルを使って24時間対応できる形で納めています。いずれも実装は当社が担い、何を作るかの判断はお客様側が持つ形です。この線引きが守られている案件は、体制が変わっても事業が止まりません。

MVPは外注しやすい——ただし「MVPに何を入れるか」は自社の判断

最小限の機能でまず出すMVPは、外注と相性が良い範囲です。作るものが絞られており、期間も短く、成果が見えやすいためです。

ただし「どの機能がMVPに必須か」は事業の判断であり、開発会社に決めさせるべきではありません。要件定義を丸投げすると、スコープが開発会社の得意領域や見積もりの都合に合わせて膨らみます。「スコープを欲張りすぎて、MVPが何年も出せない」は、よくある失敗パターンです。MVPの定義は「最初の10社が契約する理由になる機能だけ」と決め、それ以外は出してから足すと割り切ってください。MVPの切り方そのものは「MVP開発」の記事で詳しく扱っています。

運用保守は「誰が一次受けするか」を先に決める——障害・問い合わせ・リリース

公開前に決めておく運用の役割は3つです。障害を最初に受ける窓口、顧客からの問い合わせを受ける窓口、リリースの可否を判断する人。この3つが決まっていないSaaSは、最初の障害で必ず混乱します。

現実的な形は、顧客問い合わせは自社が受け、技術的な障害は開発会社が一次受けし、リリース判断は自社が持つ、という分担です。このとき、開発会社側の対応時間(平日日中か、夜間休日も含むか)と連絡手段を契約に書いておきます。ベトナムとの時差は2時間なので、日本の営業時間とほぼ重なります。ただし旧正月のテト休暇(2026年は2月14日〜22日)のような長期休暇は事前に共有し、期間中の対応体制を決めておいてください。

発注前に決める順番と、外注100%でも成立させるための引き継ぎ資産

発注前に決める順番は、(1)誰のどの課題を解くか、(2)MVPに入れる機能、(3)テナント分離と課金の方針、(4)外注範囲と運用の役割分担、(5)契約形態と予算、の5段階です。3番目が2番目より後ろに来ると、技術論点が後回しになって作り直しの芽になります。

社内にエンジニアがいない状態で外注100%でも、次の資産を自社に残せば成立します。ソースコードのリポジトリを自社名義で持つこと、クラウドアカウントを自社名義で持つこと、設計ドキュメントとデータベース定義を成果物に含めること、リリース手順が文書化されていること。当社は日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを標準の工程にしており、AI活用開発体制でドキュメント整備の負荷も下げています。この4点を持っていれば、将来内製に切り替えることも、別の会社に引き継ぐこともできます。逆に、これらを開発会社側だけが持っている状態は、乗り換えができないという意味で失敗のもとです。

請負が向かない理由と、準委任(ラボ型)との相性——契約形態の選び方

契約形態の選択は、SaaS開発の外注で最も金額に効く判断です。同じ体制でも、請負で組むか準委任で組むかによって、2年目以降にかかる手間と費用がまったく変わります。調達部門の慣行で請負を前提にしている企業は多いのですが、SaaSの継続開発にそのまま当てはめると、変更のたびに再見積もりの往復が発生します。まず3つの契約形態を比べてください。

契約形態の比較表(請負・準委任/ラボ型・SES)とSaaSでの向き不向き

請負は「仕事の完成」に報酬を払う契約(民法第632条)なので費用が事前に確定しやすく、準委任は「事務の処理」に報酬を払う契約(民法第656条・第643条)なので開発途中の仕様変更や優先順位の変更に対応しやすい——当社が実務で使い分けている基準はこれだけです。どちらが優れているかではなく、何に払うかが違うだけです。

請負が向かない3つの理由——完成の定義、再見積もりの往復、改善速度

SaaSの継続開発に請負が向かない理由は3つあります。

1つ目は、完成の定義が置けないことです。請負契約は成果物の仕様を確定させて初めて成立します。顧客の反応で優先順位が変わるSaaSでは、確定させた瞬間に古くなります。

2つ目は、再見積もりの往復が事業の速度を殺すことです。機能追加のたびに要件を文書にし、見積もりを取り、稟議を通し、契約を巻く。1回あたり2〜4週間かかるとすれば、年に10回の改善で半年近くを事務手続きに使う計算になります。

3つ目は、改善の単位が大きくなりすぎることです。手続きの重さを嫌って「まとめて発注」に流れ、3か月分の要望を一括で作る。出してみて外れていた場合の損失が大きくなります。

一方で、初期開発の一括部分は請負が有効です。当社への相談でも多いのが、初期開発を請負で固め、リリース後の改善をラボ型に切り替える併用です。請負と準委任の法的な違いは「準委任 請負 違い」の記事で整理しています。

準委任(ラボ型)との相性と、当社の体制——1名から、日本人PMフロント

ラボ型開発は、専属チームを月額固定で確保し、優先順位を見直しながら継続的に開発する形態です。準委任契約の一形態で、SaaSの継続開発とは構造がそのまま噛み合います。毎月決まった開発力があり、何を作るかは月内に決められるためです。

当社は介護記録SaaS「CareViewer」で、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制を組み、週次の優先順位判断だけで継続開発を回しています。お客様側の負担は週1回の定例で「次に何を作るか」を決めることに集中し、要件の細部の言語化・実装・レビューは当社が巻き取る形です。従来の体制と比べてコストは半分以下になり、「想像以上にエンジニアのレベルが高い」という評価をいただいています。

体制は2パターンあり、パターンA(日本人PMまたはブリッジSE+エンジニア)を推奨しています。社内に開発の判断ができる人がいない場合、フロントに日本人PMを置かないと、判断待ちで稼働が空くためです。当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社を経由する仲介マージンが乗りません。1名から契約でき、最短2週間で開始、増員は約1週間、縮小と交代は1か月単位で調整できます。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

相談時に確認する項目——継続開発の単価、増減員、引き渡し、再委託

見積もりを受け取ったら、次の6点を全社に同じ質問として投げてください。(1)リリース後の継続開発の月額と、その体制の内訳。(2)増員と縮小のリードタイム、最低契約期間。(3)担当予定のブリッジSEやPMと契約前に面談できるか。(4)ソースコードとドキュメントの著作権の帰属、契約終了時の引き渡し範囲。(5)実装担当は社員か協力会社か、再委託は何次まで入るか。(6)障害時の対応時間と連絡手段。

この6点に即答できない会社は、初期開発は作れても継続開発の体制を持っていない可能性があります。自社のプロダクトを2年後も直し続けてくれる相手かどうか、という観点で読み直してみてはいかがでしょうか。

SaaS開発の外注費用は3階建てで考える——初期開発費+継続開発費+インフラ運用費

SaaS開発の費用は「人月単価×人数×期間」に分解できます。受託開発ならこの式で総額が出ますが、SaaSでは期間が終わりません。したがって、総額ではなく3つの層に分けて考える必要があります。1階が初期開発費、2階が毎月の継続開発費、3階が毎月のインフラ運用費です。この3階建てで見積もれば、事業計画にそのまま載ります。以下の表は、金額そのものを当てにいくためのものではなく、どの層に何が積み上がるかを押さえるためのものです。金額は要件と体制で大きく変わるので、見積もりを受け取ったらこの3層に分解し、どの層の何が抜けているかを確認してください。

費用の3階建て表(フェーズ別の初期開発費・月額の継続開発費・月額のインフラ運用費)

初期開発費の内訳——基盤機能だけでまとまった費用がかかる理由

初期開発費が想定より膨らむ最大の理由は、SaaSに固有の基盤機能です。画面や業務ロジックの前に、どのSaaSでも必ず要る土台があります。

どのSaaSでも必要になる基盤機能は、認証・認可、課金とサブスクリプション管理、マルチテナント基盤、管理者画面、利用状況のダッシュボード、外部連携API、通知と監査ログの7種です。画面や業務ロジックを1つも作らない段階で、この7種だけでまとまった工数がかかります。見積書では、この7種が別項目として立っているかを確認してください。

「MVPを300万円で」という見積もりに基盤機能が含まれているかどうかは、必ず確認してください。含まれていなければ、2回目の見積もりでほぼ同額が追加されます。

継続開発費とインフラ運用費——月次の固定費として事業計画に載せる

2階と3階は、事業を続ける限り発生します。売上がゼロの月でも止まりません。したがって、家賃や人件費と同じ月次の固定費として計画に載せるのが現実的です。

継続開発費の規模は、何人分の開発力を毎月確保するかで決まります。グロースフェーズでは、毎月一定の人月を確保できる契約形態にしておくのが現実的です。当社のラボ型なら、日本人PMをフロントに置いた最小構成で月額約80万円から、エンジニア1名あたりの単価は実務3年目安で1,500USD(1USD=150円換算目安で約22.5万円)です。

年間経常収益に対して開発費をどの程度まで使ってよいか、という比率の問いもよく受けます。これは成長段階と調達状況で大きく変わるため、一律の数字は示せません。一般論としては、立ち上げ期は開発費が収益を上回るのが普通で、収益が伸びるにつれて比率が下がっていく形になります。判断材料になるのは比率そのものではなく、「毎月いくらの固定費なら何か月払い続けられるか」という現金の見通しです。

見積もりに入っていないものを洗い出す——比較できない3社の見積もりを揃える

3社の見積もりが900万円、1,800万円、「月額160万円×12か月」と並んだとき、そのままでは比較できません。次の項目が各社の見積もりに含まれているかを一覧にして、揃えてから比べてください。

企画・要件定義の工数、UI/UXデザイン、基盤機能7種(認証・課金・テナント・管理画面・ダッシュボード・外部連携・監査ログ)、テストとQA、インフラ構築、リリース後3か月の不具合対応、継続開発の月額とその体制、インフラの月額、外部サービスの利用料と決済手数料、ドキュメント一式。追加費用の源泉として特に多いのは「要件定義を省いた場合」「MVP後の継続開発費が試算に入っていない」「インフラ・運用費の見落とし」「マルチテナントの後付け」の4つです。見積もりの読み方は「見積もり内訳」の記事でも扱っています。

3階建てで並べ直すと、安く見えた見積もりが2年目に最も高くつくことがあります。総額ではなく、初期費と月額を分けて比べるのが要点です。

発注前に方針を決める技術論点6つ——テナント分離、課金、認証、監査ログ、SLA、バックアップ

技術の詳細を発注側がすべて理解する必要はありません。ただし、後から変えると高くつく論点については、発注前に方針だけ決めておく必要があります。ここで挙げる6つは、いずれもデータベース設計と認証設計の根幹に関わるか、契約で約束する内容に関わるものです。提案を受けるときに、この6点への回答を求めてください。

技術論点6つのチェック表(論点・判断のタイミング・後回しにした場合のコスト)

6つのうち、後回しの代償が最も大きいのは1番のテナント分離です。順番に見ていきます。

テナント分離の3方式——共有スキーマ、個別スキーマ、個別DBの費用差

マルチテナントとは、複数の顧客企業が同じシステムを使いながら、データは互いに見えないようにする仕組みです。実現方式は大きく3つあり、初期コストと運用の手間が変わります。

初期コストは、共有データベース・共有スキーマ方式がもっとも低く、共有データベース・個別スキーマ方式、顧客ごとに個別データベースを持つ方式の順に上がります。分離を強くするほど初期コストも運用コストも上がる、という関係です。共有スキーマは安価でスケールしやすい一方、テナントを識別する条件を1か所でも書き忘れると他社のデータが見える事故につながります。個別データベースは分離が強く、大企業や医療・金融の顧客に説明しやすい反面、データベースの数だけ運用と移行の手間が増えます。

判断の基準は、狙う顧客層です。中小企業向けに数百社を載せるなら共有スキーマ、大企業や規制業種を狙うなら個別スキーマ以上、と考えるのが一般的です。重要なのは、どの方式を選ぶかより「MVPの段階から方式を決めて作る」ことです。後から変えるのは、データベース設計と認証設計を同時に入れ替える作業になるため要注意です。

課金基盤は作らずに借りる——Stripe等の外部サービスを使うのが一般的

課金は自作したくなる領域ですが、避けたほうが無難です。カード決済、与信、失敗時のリトライ、日割り計算、プラン変更、返金、請求書の発行、税率の扱いまで、要件が想像より広いためです。加えて、これらは一度作って終わりではなく、決済ネットワークや税制の変更に追随し続ける必要があります。

一般的なのは、Stripeのような決済・サブスクリプション管理のサービスを使い、自社側はプランの定義と利用状況の集計に集中する形です。当社でも、決済アプリの開発でStripeを組み込み、二要素認証、ウォレット機能、PDFの帳票出力までを新規開発し、リリース後は週次の保守運用に移行した実績があります。外部サービスを使う場合は、決済手数料が売上に比例して発生するため、3階のインフラ運用費の見積もりに手数料も入れておいてください。

認証・権限・監査ログ・SLA・バックアップ——当社の実績から

残りの4点は、発注時点で「いつやるか」を決めておけば十分です。

認証と権限は、役割ベースの権限設計だけは最初から入れます。企業向けのシングルサインオンやSAML対応は、大企業の顧客から要求が出た時点でよいのですが、「後から足せる作りにしておく」ことを設計要件として伝えてください。多要素認証は、当社の決済アプリのように金銭や個人情報を扱うなら初期から入れます。

監査ログは、記録していなければ過去に遡れないという性質上、最初から取る以外の選択肢がありません。誰が・いつ・どのテナントの・どのデータに・何をしたかを記録し、保存期間を決めておきます。

SLAは、顧客に約束する稼働率と、開発会社と結ぶ対応時間の2段構えです。発注前に決めるのは、稼働率の保証値、重大障害の応答時間、復旧目標時間、免責範囲の4点です。自社が約束できる水準は、開発会社とどこまでの対応時間で合意できるかで決まります。約束が先走ると、守れない契約を売ることになります。

バックアップと復旧は、公開前に一度必ず復旧のテストをしてください。取得しているつもりで戻せなかった、という事故は珍しくありません。当社はクラウド基盤の設計にAWS認定11冠のメンバーが関わり、日本人PMの設計レビュー、Gitのプルリクエストによるコードレビュー、リリース前のダブルチェックを標準の工程にしています。セキュリティ面の体制は「オフショア開発 セキュリティ」の記事で詳しく扱っています。技術論点を発注前に潰しておくことが、2年目の作り直しを防ぐ最も安い投資です。

SaaS開発の外注でよくある質問

SaaS開発の外注について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内の検討資料や、開発会社への確認事項としてもお使いください。

Q1. MVPはいくらから作れますか?

公開されている目安には大きな幅があります。差が出るのは、認証・課金・マルチテナントといった基盤機能を含むかどうかです。見積もりを比べる前に、基盤機能7種が含まれているかを確認してください。

Q2. マルチテナントは最初から必要ですか?

顧客企業を2社以上載せる予定があるなら、方式は最初に決めてください。実装のすべてを初期に作り込む必要はありませんが、データベース設計と認証設計をテナント前提にしておかないと、後から入れ替えることになります。方式ごとに初期の作り込み量は変わりますが、効いてくるのは初期費用の差よりも、後から方式を変えるときの作り直しの大きさです。

Q3. 課金機能は自社で作るべきですか?

一般的にはStripeのような外部サービスを使います。決済、与信、日割り、プラン変更、返金、請求書、税率の扱いまでを自作すると、実装だけでなく変更への追随が続くためです。自社で作るのは、プランの定義と利用状況の集計に絞るのが現実的です。

Q4. 社内にエンジニアがいなくても運用できますか?

できます。ただし、リポジトリとクラウドアカウントを自社名義で持つこと、設計ドキュメントを成果物に含めること、リリース判断と顧客問い合わせの窓口を自社に置くことの3点は必要です。技術的な障害の一次受けは開発会社に任せられます。当社は日本人PMをフロントに置く体制で、お客様の負担を週1回の優先順位判断に集中させています。

Q5. 途中で開発会社を変えられますか?

変えられますが、引き継ぎには時間と費用がかかります。著作権の帰属、契約終了時の引き渡し範囲、ドキュメントの納品を契約書に書いておけば、切り替えの負担は大きく下がります。逆に、これらが曖昧なまま進んだ案件の乗り換えで最も時間を要するのは、コードの理解という見えない作業。

まとめ: SaaSの外注は「終わらない開発」の設計——範囲・契約・3階建ての費用・技術論点6つ

SaaS開発の外注が受託開発と違うのは、納品・顧客・収益・品質・費用・要件の6点です。根っこにあるのは「完成の定義が置けない」という性質で、リリースした日が開発の始まりになります。この前提を共有できていない相手と組むと、初期開発だけを請負で作って改善の行き場がなくなる、マルチテナントを後付けして大規模改修になる、運用の一次受けが決まらず障害で止まる、という3つの失敗のどれかに行き着きます。

やるべきことは4つです。第1に、外注する範囲を切ること。実装・デザイン・インフラ構築は外注しやすく、プロダクトの方向性、価格設計、データモデルの骨格、リリース判断は自社で持ちます。第2に、契約形態を選ぶこと。初期開発は請負で固め、リリース後の改善は準委任(ラボ型)に切り替える併用が現実解です。第3に、費用を初期開発費・継続開発費・インフラ運用費の3階建てで見積もり、2階と3階を月次の固定費として事業計画に載せること。第4に、テナント分離、課金、認証、監査ログ、SLA、バックアップの6つについて、発注前に方針を決めることです。当社は2,000名以上のIT人財データベースから直接アサインし、日本人PMをフロントに置く最小構成で月額約80万円から、1名・最短2週間で開始できます。介護記録SaaSの継続開発やStripeを使った決済アプリの新規開発から週次保守までを、同じ体制で担っています。

外注のどこに線を引くかは「内製 外注 比較」の記事、最初に出す範囲の決め方はMVP開発とは、月額の内訳と試算はラボ型開発の費用相場もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、外注範囲の切り方と契約形態の提案、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。