システム開発を外部へ委託したいものの、受託開発の範囲や契約形態、費用の考え方が分からず、依頼先選びに迷う担当者も多いのではないでしょうか。
受託開発は、企画や要件定義、設計、実装、テスト、運用保守などの業務を外部事業者へ委託する方法です。ただし、「受託開発」という言葉自体は民法上の契約類型ではなく、工程や責任分担に応じて請負契約や準委任契約などを使い分けます。
この記事では、契約形態の違い、メリットと注意点、会社選び、見積もり、検収までの進め方を発注者の視点で解説します。契約条件は案件ごとに異なるため、最終的な契約書は法務担当者や弁護士へ確認してください。
この記事でわかること
・ 受託開発と請負・準委任・労働者派遣の違い
・ 受託開発のメリットと、発注側が担うべき責任
・ 開発会社を比較する際の評価基準と契約上の確認事項
・ 要件整理から見積もり、進捗管理、検収までの進め方
システム受託開発とは？外部委託する業務と契約の基本
システム受託開発とは、自社で必要なシステムやソフトウェアの企画、要件定義、設計、実装、テスト、移行、運用保守などを、外部の開発会社へ委託することです。委託範囲はプロジェクトによって異なり、すべての工程を一社へ依頼する場合も、工程ごとに契約を分ける場合もあります。
「受託開発」は取引の呼び方であり、それだけで請負契約に決まるわけではありません。成果物の完成を約束する請負、合意した業務を善良な管理者の注意をもって遂行する準委任など、業務の性質と責任分担に合う契約を選びます。契約名ではなく、実際の業務内容と指揮命令関係も確認することが重要です。
請負・準委任・労働者派遣の違い
受託開発で利用される主な契約形態には、請負契約と準委任契約があります。労働者派遣は、派遣先が派遣労働者へ指揮命令する点で両者と異なります。SESはIT業界で使われるサービス名・取引名称であり、法律上の契約類型ではありません。SESという名称だけで準委任と判断せず、契約内容と実態を確認してください。
契約形態は工程単位で分けることもあります。たとえば、要件が固まっていない支援業務を準委任、仕様と完成条件を合意した開発を請負とする方法があります。実際の契約設計は案件に合わせ、専門家の確認を受けましょう。
成果完成義務と業務遂行義務の違い
請負契約では、受注者が契約で定めた仕事を完成させることを約し、発注者はその仕事の結果に対して報酬を支払います。完成の定義、成果物、納期、検査方法、契約不適合への対応を具体的に定めることが重要です。
準委任契約では、受任者は合意した業務を善良な管理者の注意をもって遂行します。一般に成果の完成を当然に約束する契約ではありませんが、報酬の決め方や成果物の有無は契約内容によって異なります。契約書では業務範囲、役割、報告方法、期間、終了条件を確認します。
指揮命令関係の違いと偽装請負への注意
請負契約や準委任契約では、受託会社が自社の従業員へ業務上の指示を出し、業務を独立して進めます。発注者が受託会社の担当者へ直接、作業方法や勤務時間などを指示する実態になると、契約名にかかわらず偽装請負と判断されるおそれがあります。
要望や優先順位、成果物の条件は、合意した窓口や責任者を通じて伝えます。発注者が労働者へ直接指揮命令する必要がある場合は、許可を受けた派遣元との労働者派遣契約など、実態に合う適法な枠組みを検討してください。
費用と支払条件は契約内容で決まる
請負か準委任かだけで、固定価格・時間単価・成果報酬などの支払方法が自動的に決まるわけではありません。見積もりの前提、対象範囲、単価、工数、マイルストーン、請求時期、追加作業の扱いを契約で確認します。
要件が変わった場合は、変更内容が費用、納期、品質、体制へ与える影響を評価し、承認後に契約や計画へ反映します。口頭依頼の積み重ねを避け、変更管理の手続きを定めておくことが重要です。
システム受託開発の3つのメリット
受託開発には、必要な専門性を外部から補い、社内だけでは進めにくいプロジェクトを実行しやすくする利点があります。ただし、費用削減や品質向上が自動的に実現するわけではありません。目的、役割、受け入れ基準、意思決定方法を明確にしたうえで活用します。
1．必要な専門人材と開発体制を確保しやすい
自社で採用・育成するには時間がかかるPM、エンジニア、デザイナー、QA、セキュリティなどの専門人材を、プロジェクトの目的に合わせて確保しやすくなります。
ただし、候補者の経歴だけでなく、実際の担当者、稼働条件、交代時の引き継ぎ、再委託の有無を確認してください。必要なスキルが体制表と契約に反映されているかも重要です。
2．外部の知見や開発プロセスを活用できる
類似案件の経験がある開発会社から、要件整理、設計、品質管理、セキュリティ、運用などの知見を得られる場合があります。自社だけでは気づきにくい選択肢やリスクを比較できる点も利点です。
一方で、最新技術の採用が常に最適とは限りません。既存環境との整合性、保守性、長期サポート、担当者の確保、ライセンス、総保有コストを踏まえて技術を選びます。
3．社内リソースを重要な意思決定へ集中しやすい
設計や実装、テストなどを外部へ委託すれば、社内担当者は業務要件、優先順位、利用部門との調整、承認など、発注者にしか担えない仕事へ集中しやすくなります。
ただし、丸投げはできません。業務の目的と要件を説明し、判断、レビュー、受け入れ、運用準備へ必要な人員と時間を確保することが、プロジェクト成功の前提です。
システム受託開発の3つの注意点
受託開発では、知識が社外に偏ること、依頼先への依存、変更に伴う追加費用などが課題になりやすいです。委託前にリスクを洗い出し、契約、体制、成果物、引き継ぎ計画で対策します。
1．社内に知識が蓄積されにくい
設計判断や運用ノウハウを開発会社だけが把握していると、障害対応や改修、ベンダー変更が難しくなります。発注側にも責任者を置き、要件、設計、テスト、運用の判断記録を共有してください。
納品物として、ソースコード、設計書、テスト結果、構成情報、運用手順、アカウント一覧などを定め、更新責任と引き渡し方法を合意します。
2．特定の開発会社へ依存する可能性がある
独自仕様、未共有の設定、特定担当者への属人化が進むと、将来の保守や移行の選択肢が狭くなります。知的財産権、ソースコードへのアクセス、利用ライセンス、データの所有・返却、再委託、契約終了時の移行支援を事前に確認します。
引き継ぎ可能な文書と環境を維持し、定期的に事業継続性や代替手段を見直すことが重要です。
3．要件変更で費用や納期が変わる
開発中の要件変更は、設計、実装、テスト、データ移行、運用へ影響します。特に請負契約では、合意済みの範囲を超える変更が追加費用や納期変更につながる場合があります。
変更を禁止するのではなく、変更要求の記録、影響分析、優先順位、承認者、契約変更の方法を定めます。アジャイル型の受託開発も可能ですが、発注側の継続的な参加、優先順位管理、契約と品質基準の設計が必要です。
システム受託開発を成功させる5ステップ
受託開発は、目的と現状の整理、候補会社の比較、契約、開発中の協働、検収・運用の順に進めます。工程の全体像は「システム開発の流れ」も参考にしてください。
ステップ1：目的・対象範囲・責任分担を整理する
最初に、解決したい業務課題、利用者、期待する効果、対象業務、予算・期限の目安、既存システムとの関係を整理します。機能一覧だけでなく、セキュリティ、性能、可用性、データ移行、運用保守などの非機能要件も検討します。
プロジェクトの目的と成果指標を定める
「システムを導入する」ことを目的にせず、処理時間、入力ミス、問い合わせ件数、利用率など、導入後に確認できる成果指標を定めます。現状値、目標値、測定方法、確認時期を決めると、投資判断や優先順位付けに役立ちます。
対象範囲・発注側の作業・受け入れ条件を明確にする
今回の対象と対象外、前提条件、未決事項、発注側が提供するデータや環境、承認者、レビュー期限を明確にします。完成や検収の判断に使う受け入れ条件も、見積もり前に可能な範囲で整理してください。
すべてを確定できない場合は、不確実な項目と確定時期、変更管理の方法を明記します。
ステップ2：候補会社を比較して依頼先を選ぶ
会社選びでは、価格だけでなく、類似案件の実績、提案内容、担当体制、品質管理、セキュリティ、コミュニケーション、運用支援を比較します。詳しい評価軸は「システム開発会社の選び方」も参考にしてください。
必要に応じてRFPや要件資料を用意する
RFP（提案依頼書）は、背景、目的、対象範囲、要件、制約、提案してほしい項目、評価基準、スケジュールを候補会社へ伝える資料です。大型案件や複数社比較では有効ですが、すべての案件で必須ではありません。
要件が未整理の場合は、いきなり固定範囲の開発見積もりを求めず、構想整理や要件定義を別フェーズとして相談する方法もあります。
実績・体制・品質・セキュリティを評価する
類似業務や規模の実績、提案の前提と課題理解、担当者の経験、開発・テスト・レビュー方法、セキュリティ管理、再委託方針、障害対応、契約終了時の支援を確認します。
「最新技術を使える」「価格が安い」だけで決めず、自社の目的に合う提案か、リスクを説明しているか、長期的に保守できるかを比較してください。
ステップ3：契約範囲・見積もり・変更手続きを合意する
契約締結前に、工程ごとの契約形態、成果物、役割、スケジュール、費用、検収、変更管理を確認します。受託開発の契約は案件ごとに設計が異なるため、ひな型をそのまま使わず、法務担当者や弁護士の確認を受けてください。
契約書で確認する主な項目
主な確認項目は、業務範囲、成果物、完成・受け入れ条件、役割分担、変更管理、報告・承認、知的財産権、第三者ソフトウェアとOSS、データ・個人情報、秘密保持、セキュリティ、再委託、保証・保守、損害賠償の範囲、契約解除、終了時のデータ返却と移行支援です。
契約不適合への対応は契約内容と法令に左右され、当然に無償対応となるわけではありません。対象、期間、手続き、除外事項を確認します。
見積もりの内訳と前提条件を比較する
システム開発費用は、機能数だけでなく、要件の明確さ、非機能要件、外部連携、データ移行、セキュリティ、テスト、クラウド・ライセンス、教育、運用保守、リスクによって変わります。根拠のない人月単価や総額の相場だけで判断しないでください。
見積もりでは、対象工程、工数・単価、成果物、前提、除外事項、顧客側作業、追加費用が発生する条件を比較します。詳しくは「システム開発の見積もりと費用相場」も参考にしてください。
ステップ4：開発中の進捗・課題・変更を共同で管理する
契約後も、発注側と開発側が定期的に進捗、課題、リスク、品質、変更要求、意思決定事項を共有します。会議頻度はプロジェクトの規模や開発手法に合わせ、問題が見える指標と報告方法を定めてください。
進捗率だけでなく成果物とリスクを確認する
作業時間や進捗率だけでなく、完成した成果物、レビュー結果、テスト状況、未解決課題、変更の影響、予算消化、次の承認事項を確認します。重要な判断は議事録や課題管理票へ残し、担当者と期限を明確にします。
発注側も意思決定とレビューへ参加する
業務ルールや優先順位を最終的に決められるのは発注側です。問い合わせへの回答、データ提供、画面・業務フローのレビュー、利用部門との調整、受け入れテスト、運用準備に必要な担当者を確保します。
回答が遅れると開発が止まるため、意思決定者、回答期限、代替判断のルールを決めておくことが重要です。
ステップ5：受け入れ・移行・運用開始を確認する
リリース前に、受け入れテスト、データ移行、操作教育、運用手順、監視、バックアップ、障害時の連絡、切り戻し条件を確認します。既知の不具合や残課題は、影響、対応時期、責任者を明確にしてリリース可否を判断します。
合意した受け入れ基準に基づいて検収する
検収では、契約と受け入れ計画で合意した基準に基づき、成果物、機能、性能、セキュリティ、移行結果、文書、運用準備を確認します。すべての不具合がゼロであることを求めるのではなく、重大度と業務影響を踏まえて判断します。
検査期間、修正・再検査の手続き、みなし検収の有無、検収後の保証・保守範囲も契約と整合させてください。
システム受託開発に関するよくある質問
ここでは、依頼先の選び方、請負・準委任・SESの関係、費用の考え方について、発注担当者からよくある質問を整理します。
受託開発会社は何社くらい比較すべきですか？
比較社数に一律の正解はありません。案件の規模、緊急度、要件の明確さ、調達ルールに応じて決めます。複数社を比較する場合は、同じ前提と評価基準を共有し、価格だけでなく提案、体制、リスク、運用まで評価してください。
小規模な案件や既存取引先の継続案件では、比較にかかる負担と期待効果も考慮します。
受託開発とSESの違いは何ですか？
受託開発は外部事業者へ開発業務を委託する取引の総称です。SESはIT技術者の役務提供を表す業界用語で、法律上の契約類型ではありません。実際には請負、準委任、適法な労働者派遣などのいずれかに当たる可能性があり、名称だけでは判断できません。
発注者から個々の技術者への指揮命令の有無、成果完成義務、業務の独立性、報酬条件を契約と実態の両面で確認してください。
受託開発の費用はどのように決まりますか？
費用は、対象工程、機能・画面・帳票、外部連携、データ移行、性能・可用性・セキュリティ、テスト、クラウドやライセンス、プロジェクト管理、教育、運用保守、納期、リスクなどで決まります。
総額だけでなく、見積もりの前提、対象外、発注側の作業、変更時の計算方法、継続費用を確認してください。要件が不明確な段階では、要件整理を先に実施し、その結果を基に開発見積もりを更新する方法があります。
まとめ｜契約名ではなく役割と実態を確認して受託開発を進めよう
システム受託開発は、外部の専門性と体制を活用できる一方、契約を結べば開発会社へすべて任せられる仕組みではありません。発注側も目的、要件、優先順位、意思決定、受け入れ、運用準備を担います。
受託開発を一律に請負契約と考えず、工程と責任に応じて請負や準委任などを設計し、契約と実態を一致させることが重要です。会社選びでは、実績や価格だけでなく、体制、品質、セキュリティ、変更管理、知識移転、契約終了時の対応まで確認しましょう。
本記事は一般的な情報を提供するもので、法的助言ではありません。個別の契約は法務担当者や弁護士へ確認してください。
