システム開発 受託開発【2026年版】外注前に知るべき基礎と選び方

はじめに

システム開発の受託開発とは、自社ではなく外部の開発会社に、業務システムやWebアプリの開発を依頼する方法です。社内にエンジニアがいない、既存システムとの連携が必要、短期間で業務改善を進めたい場合に選ばれます。

ただし、外注すれば自動的に成功するわけではありません。要件定義が曖昧なまま依頼すると、見積もりが膨らむ、納期が遅れる、完成後に現場で使われない、といった問題が起きます。2026年時点では、最初から大規模開発に進むのではなく、ノーコードやBubbleでプロトタイプを作り、業務に合うか検証してから本格開発へ進む方法も現実的です。

この記事では、システム開発の受託開発で失敗しないために、発注前に決めることを中心に、定義、請負・準委任との違い、開発の流れ、メリット・デメリット、費用と支払い方式、2026年1月に施行された取適法、開発会社選びまで整理します。

受託開発を検討する会社の多くは、「社内で作るべきか」「SaaSで足りるか」「外注すべきか」で迷っています。最初に決めるべきなのは開発手法ではなく、解決したい業務課題です。現場の入力作業を減らすのか、顧客対応を早くするのか、データを一元管理するのかで、選ぶべき方法は変わります。

受託開発とは？請負・準委任との違い

受託開発は、外部の開発会社にシステム開発を依頼する広い言い方です。実際の契約では、成果物の完成を重視する請負契約、作業時間や専門性の提供を重視する準委任契約などがあります。

契約形態	向いているケース	注意点
請負	要件と成果物が明確な開発	途中変更が多いと追加費用になりやすい
準委任	要件が変わりやすい改善開発	成果物ではなく稼働管理が重要
ラボ/伴走型	継続的に改善したい開発	役割分担と優先順位を決める必要がある

どの契約が良いかは、開発内容の明確さで変わります。仕様が固まっている業務システムなら請負が合う場合があります。一方で、新規事業や業務改善のように途中で検証が必要な場合は、準委任や伴走型の方が柔軟です。IPAが公開している情報システム・モデル取引・契約書（アジャイル開発版）も、要件が確定していない状態で進むアジャイル開発では準委任契約を前提にしています。

準委任には、作業した割合に応じて報酬を払う「履行割合型」と、成果の引き渡しと引き換えに報酬を払う「成果完成型」があります。2020年4月施行の改正民法で成果完成型が条文化されました（民法648条の2の解説）。準委任でも成果に対して支払う形を選べるため、契約書ではどちらの型かを明記しておきます。

発注側が混同しやすいのは、受託開発と単なる人員補充の違いです。受託開発では、成果物、要件、レビュー、検収、保守の範囲を決めます。人手だけを増やしたい場合と、業務課題を解決するシステムを作りたい場合では、依頼先も契約も変える必要があります。

受託開発の流れ

受託開発は、おおむね次の順で進みます。どの工程で発注側の判断が必要になるかを先に知っておくと、社内の担当者と時間を確保しやすくなります。

1. 要件定義：業務フロー、利用者、必須機能、既存データ、連携先を明確にする
2. 提案・見積もり：システムの概要、機能、開発範囲、費用、スケジュールを提示してもらう
3. 設計・開発：画面、データベース、権限、外部連携を設計し、実装する
4. テスト・受入：要件どおりに動くかを開発会社が検証し、発注側が受入テストで確認する
5. 納品・運用保守：本番公開、データ移行、公開後の修正・改善を行う

発注側の負担が大きいのは、最初の要件定義と4番目の受入テストです。要件定義では、現場で例外的に発生する処理まで洗い出さないと、開発の終盤で仕様変更が起きます。受入テストでは、実際に使う担当者が画面を触り、業務が止まらないかを確かめます。

受託開発のメリット・デメリット

受託開発のメリットは、社内にない技術や経験を使えることです。業務システム、予約システム、CRM、顧客ポータル、AI連携など、自社だけでは設計が難しい開発を専門家に任せられます。エンジニアを採用する場合に比べ、必要な期間だけ専門チームを使えるため、開発期間とコストを抑えやすくなります。

観点	メリット	デメリット
技術力	専門知識を活用できる	開発会社選びを誤ると品質差が出る
スピード	経験あるチームで進められる	要件確認に時間がかかる場合がある
コスト	採用せずに必要な期間だけ依頼できる	変更や追加で費用が増えることがある
運用	保守や改善も任せられる	社内にノウハウが残りにくい

デメリットの多くは、発注側と開発会社の認識のズレから生まれます。代表的なリスクは次の3つです。

要件定義の曖昧さによるトラブル

受託開発で最も多い問題は、要件が曖昧なまま、または十分に共有されないまま開発が始まることです。「顧客管理ができればよい」という依頼では、誰がどの項目を入力し、誰が閲覧できるのかが決まりません。開発会社が推測で補った部分は、完成後に「思っていたものと違う」という形で表面化します。

コミュニケーション不足による認識ズレ

進捗確認やフィードバックの機会が少ないと、意図しない方向へ開発が進んでしまいます。仕様書の文章だけでは、画面の使い勝手や操作の順番までは伝わりません。定例会や画面のレビューを設けず、完成間際に初めて画面を見る進め方は、手戻りを大きくします。

納期とコストの超過

契約時に決めた納期や費用が守られないこともあります。原因の多くは、開発途中の要件変更や機能追加です。変更が起きること自体は避けられないため、変更時の承認フローと追加費用の決め方を契約前に合意しておくことが対策になります。

費用の見方と支払い方式

費用は「システム一式いくら」ではなく、見積項目に分けて確認します。固定相場だけで判断すると、必要な工程が抜けたり、逆に過剰な機能まで含まれたりします。

見積項目	確認すること
要件定義	業務ヒアリング、画面一覧、機能一覧が含まれるか
設計	DB設計、権限、画面遷移、API連携が含まれるか
開発	対象機能、開発範囲、対象端末が明確か
テスト	受入テスト、権限テスト、データ移行確認があるか
保守	障害対応、軽微修正、運用相談の範囲
追加変更	仕様変更時の単価や承認フロー

見積もりを見るときは、金額の安さだけで判断しないでください。安く見える見積もりでも、要件定義、テスト、保守、データ移行、セキュリティ対応が含まれていなければ、後から追加費用になります。

支払い方式も、契約形態と合わせて選びます。

支払い方式	内容	メリット	デメリット
固定価格	契約時に決めた金額で開発する	予算が明確で管理しやすい	要件変更に柔軟に対応しにくい
時間単価	実際の工数に応じて支払う	要件変更に対応しやすい	総額が確定せず、予算管理が難しい
成果報酬	決めた成果の引き渡しに対して支払う	成果に応じてリスクを分担できる	成果の定義が曖昧だとトラブルになる

仕様が固まっていれば固定価格、検証しながら作るなら時間単価、と考えると選びやすくなります。成果報酬を選ぶ場合は、何をもって成果とするかを検収条件として書き出してください。開発者募集、採用、外注の切り分けはシステム開発の開発者募集ガイドも参考になります。

2026年時点で発注側が押さえる取適法のルール

2026年1月1日、下請法が改正され「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」（通称：取適法）になりました。システムの受託開発は、プログラム作成を含む「情報成果物作成委託」に当たるため、発注側の会社規模によっては適用されます（公正取引委員会 取適法リーフレット）。

項目	2026年1月以降のルール
適用基準	プログラム作成の委託では、従来の資本金基準（3億円超など）に加え、従業員300人超の委託事業者も対象
発注内容の明示	給付の内容、代金の額、支払期日、支払方法を書面または電子メール等で明示する
支払期日	受領日から60日以内のできる限り短い期間で定める
支払手段	手形払いは禁止。電子記録債権等も期日までに満額を得にくいものは禁止
代金の決定	受託側から価格協議を求められたのに応じない、一方的な代金決定は禁止
変更・やり直し	受託側に責任がないのに、無償でやり直しや追加作業をさせることは禁止

適用の有無は、発注側と受託側の資本金・従業員数で決まります。自社が対象になるかは公正取引委員会の取適法関係ページで確認してください。対象外であっても、発注内容を書面で残し、変更時に協議する進め方は、受託開発のトラブルを防ぐうえで有効です。

想定ケース：ノーコード/Bubbleで小さく始める

社内申請システムを作る場合、最初から全社向けの大規模システムを作る必要はありません。まずは申請フォーム、承認一覧、通知、管理画面だけをBubbleでプロトタイプ化し、実際の部署で使ってみます。

この段階で、承認者の変更、差し戻し理由、CSV出力、既存Excelとの違い、スマホ利用の可否を確認します。現場で使えることが分かってから、権限、ログ、外部API、データ移行、本番保守へ広げると、無駄な開発を減らせます。

ノーコード/Bubbleは、受託開発の代替というより、発注前の確認や段階開発に向いています。動くものを見ながら要件を固められるため、要件定義の曖昧さによるトラブルも減らせます。システム開発を外注するときは、最初に小さく動かしてから本格開発へ進むことが失敗回避につながります。進め方は「動くもの」から始める要件定義でも解説しています。

受託開発を成功させるポイント

受託開発を成功させるには、開発会社任せにせず、発注側も判断を担うことが欠かせません。次の4つを押さえると、ここまでに挙げたリスクを小さくできます。

要件定義を明確にする

要件定義は、プロジェクト全体の土台です。機能の一覧だけでなく、使う技術、納期、予算、対象外にする機能まで合意します。「誰が使うか」「どの画面が必要か」「どのデータを移行するか」「既存システムと何を連携するか」「公開後に誰が修正するか」を書き出してから相談すると、見積もりの精度が上がります。

定期的な進捗確認とフィードバック

定例会で進捗を確認し、画面ができた段階で発注側が触ってフィードバックします。問題を早く見つけられるほど、修正の範囲は小さく済みます。課題の管理表を共有し、誰がいつまでに判断するかを残しておくと、判断待ちで開発が止まることを防げます。

契約書でリスクを管理する

契約書には、納期、費用、要件変更の手続き、検収条件、保守・サポートの範囲を盛り込みます。請負か準委任か、準委任なら履行割合型か成果完成型かも明記します。保守の範囲を事前に決めておくと、公開後の障害対応や軽微な修正で揉めずに済みます。

信頼できる受託開発パートナーを選ぶ

開発会社を選ぶときは、価格だけで比較しないでください。重要なのは、業務理解、要件定義、設計、実装、テスト、保守まで一貫して見られるかです。

確認項目	見るポイント
実績	同じ業務領域や近い課題の開発経験があるか
要件定義	機能だけでなく業務フローまで聞いてくれるか
技術選定	フルスクラッチ、SaaS、ノーコードを比較できるか
進行管理	定例、レビュー、課題管理の方法が明確か
保守	公開後の修正、障害、改善相談の範囲が明確か
セキュリティ	権限、個人情報、ログ、バックアップを説明できるか

相談時には、過去の制作実績だけでなく、要件が固まっていない段階でどう進めるかを確認してください。Bubble開発会社の選び方は、bubble 開発会社【2026年版】選び方・費用・発注前チェックでも解説しています。

まとめ

システム開発の受託開発は、社内に足りない技術や開発リソースを外部の専門家で補う方法です。請負、準委任、伴走型などの契約形態があり、要件がどこまで固まっているかによって適した進め方が変わります。準委任にも履行割合型と成果完成型があるため、契約書で型を明記してください。

成功のポイントは、要件定義を明確にし、定期的に進捗を確認し、契約書で変更と保守の範囲を決め、信頼できるパートナーを選ぶことです。費用は固定相場だけで見るのではなく、要件定義、設計、開発、テスト、保守、追加変更の項目に分け、固定価格・時間単価・成果報酬のどれで支払うかも合わせて決めます。

2026年1月からは取適法が施行され、発注内容の明示、60日以内の支払期日、手形払いの禁止、一方的な代金決定の禁止といったルールが、プログラム作成の委託にも関わります。自社が対象になるかを確認したうえで、発注書と変更時の協議を整えておきましょう。

2026年時点では、最初から大規模開発に進まず、ノーコードやBubbleでプロトタイプを作ってから本格開発する選択肢もあります。ノーコード総合研究所では、受託開発の要件整理、Bubbleによる業務システム開発、外注範囲の切り分け、公開後の改善まで支援しています。

「システム開発を外注すべきか迷っている」「見積もりの妥当性を判断したい」「まず小さく動くものを作って現場で試したい」という場合は、現在の業務フローと課題を整理するところから始めることをおすすめします。最初の相談では、完成形よりも「何を検証したいか」を共有すると、過剰な開発を避けやすくなります。

ノーコード総合研究所

bubble 開発会社【2026年版】選び方・費用・発注前チェック | ノーコード総合研究所 bubble 開発会社の選び方を2026年版で解説。Bubble受託開発の流れ、費用が変わる要因、公式料金プランの確認点、実績・保守・セキュリティの見極め方、発注前チェックリス...