請負契約とは？準委任・業務委託との違いとシステム開発での注意点

Webサービスやスマホアプリの開発を外部へ依頼するとき、「請負」と書かれているから完成まで任せられる、あるいは「準委任」なら成果物は受け取れない、と考えるのは早計です。契約名ではなく、どこまでを成果物として納品対象にし、どの条件で受け入れるのかによって、適した契約方式は変わります。

この記事では、請負・準委任・業務委託の違いと、開発工程ごとの選び方を整理します。読後には、完成条件を合意できる範囲を見極めるために必要な情報を整理し、請負で進める範囲、準委任で先に固める範囲、工程を分けるべき範囲を判断できるようになります。

請負・準委任・工程分割は契約名だけで選ばず、成果物、受入基準、変更、依存関係、承認体制を確認して判断します。

01Section請負契約とは｜システム開発での「完成」をどう決めるか

請負は、民法第632条で「仕事を完成すること」と、その仕事の結果に対して報酬を支払うことを内容とする契約です。民法第632条（請負）では、単に作業時間を提供するのではなく、合意した仕事を完成させることが中心に置かれています。

システム開発では、「Webサービスを開発する」といった表現だけでは完成を判断しにくい場合があります。完成の対象を、機能、品質、納品物、受入条件、対象外・前提条件まで分けておくことで、納品時に何を確認すべきかを共有しやすくなります。

完成は成果物だけでなく受入条件まで含めて決める

たとえば、外部API連携を含む会員登録機能を開発する場合、画面やAPIが存在することだけでは足りないことがあります。どの入力条件で、どの権限の利用者が、どのような結果を得られれば合格なのかまで定めて、初めて受入判断がしやすくなります。

請負に向くのは、こうした完成条件を文書化できる範囲です。たとえば、要件・画面・連携先・受入テストが固まった機能改修や、確定済みの要件に基づく設計・実装・テストは請負として切り出しやすいでしょう。一方、実現方法の調査、要件の優先順位付け、外部サービスとの調整が主な段階では、完成条件を固定する前に整理が必要です。

なお、請負であっても、契約に入っていない売上増加、利用者数、業務改善といった事業上の結果まで当然に保証するものではありません。事業目標は背景として共有しつつ、請負の完成条件では実装対象と受入条件を具体化します。

02Section請負・準委任・業務委託の違い

業務委託は実務上の総称として使われることがあり、請負か準委任かは契約内容と実際の進め方で確認します。

請負と準委任の違いは、受託者に何を中心として求めるかにあります。準委任は、法律行為ではない事務を委託する場合に委任の規定を準用する契約です。民法第643条、第644条、第656条の位置付けは、民法第643条・第644条・第656条で確認できます。

準委任は「成果不要」という意味ではない

民法第644条の善管注意義務は、専門事業者として通常期待される注意を払い、合意した業務を適切に進める義務と理解すると分かりやすいでしょう。準委任でも、調査報告書、要件定義書、設計メモなどの成果物を受け取ることはあり得ます。

ただし、請負のように完成責任をどこに置くか、成果物をどの条件で受け入れるか、報酬をどう設計するかは、契約条項と実際の進め方で確認する必要があります。「業務委託契約」という表題だけでは、請負か準委任かは判断できません。

準委任の契約構造や注意点をより詳しく確認したい場合は、準委任契約の解説も参照してください。

03Section請負・準委任・工程分割の選び方

完成条件と変更手続を定められる範囲は請負候補とし、未確定要素が大きい範囲は準委任先行または工程分割を検討します。

契約方式は、案件全体で一つに固定する必要はありません。要件整理は準委任、完成条件を合意できた機能群の実装・テストは請負、リリース後の改善は準委任というように、工程ごとに分ける方法があります。IPAの情報システム・モデル取引・契約書（第二版）も、仕様、検収、協力義務、複数契約の関係を論点として整理しています。

次の4段階で、請負、準委任先行、工程分割のどれを採るかを検討します。

4段階を通過し、完成条件と変更手続を定められる範囲は請負候補です。要件や実現方法の調査が必要なら準委任で要件整理・技術調査を先行します。確定部分と未確定部分が混在する場合は、未確定部分を準委任、確定部分を請負に分ける工程分割を検討します。

判定後は、選択理由、未解消のリスク、再判定する時点、責任者を議事録や稟議資料に残します。反復ごとの優先順位変更や継続的な改善が中心の案件も、まずは準委任を候補として、発注者が優先順位を決める体制を整えられるか確認するとよいでしょう。

04Section請負で発注する前にそろえる4つの合意

仕様書だけでなく、受入基準、変更時の承認、発注者側の提供物と判断期限までつなげて合意します。

請負で発注する場合、仕様書だけを固めても十分ではありません。仕様、受入テスト、検収、変更管理、発注者側の提供物や承認体制がつながっていなければ、完成の判断や納期管理が難しくなります。要件は関係者間で合意して文書化し、変更を管理することが重要です。詳しくはIPAの要件定義に関する解説も確認できます。

仕様の範囲と発注者の役割を明確にする

機能一覧に加え、対象外、外部連携、データ移行、非機能要件、納品文書、発注者が提供するデータ・アカウント・素材・業務ルールを整理します。発注者の承認が遅れれば、受託者が作業を進められない場合もあるため、承認者と判断期限も決めておく必要があります。

受入テストと検収を実行できる形にする

「問題なく動く」といった抽象的な基準ではなく、業務シナリオ、連携、権限、例外処理、納品物について何を確認するかを決めます。テスト項目、環境・データ、期待結果、実施者、証跡、合否判定を一組で定めると、受入判断を行いやすくなります。

納品、検収通知、支払いの順序や期限は契約ごとに異なるため、個別の契約条件で確認してください。

変更は影響評価と承認を先に行う

変更要求は、契約・仕様・受入基準との関係を確認したうえで、既存仕様を満たすための修正、仕様追加・変更、発注者側の前提変更、原因未確定に仮分類します。その後、費用、納期、品質、セキュリティ、外部連携への影響を確認し、承認後に仕様・見積・スケジュールを更新します。

原則として、口頭やチャットだけの依頼で着手しない運用が重要です。緊急対応が必要な場合も、例外承認者、対象範囲、費用負担、事後に文書化する期限を記録しておきます。

05Section費用・納期は固定条件の成立要件と見積比較で判断する

請負の費用と納期は、対象範囲、要件確度、外部連携、非機能要件、テスト、データ移行、発注者側の準備、保守範囲、変更条件によって変わります。固定価格・固定納期は、仕様、受入基準、前提条件が合意済みの範囲に適用しやすい考え方です。

主要な要件や依存条件が未確定な段階で、案件全体を固定条件の請負にまとめると、追加費用や納期再協議の論点が生じやすくなります。要件整理を先行し、節目で範囲を確定して再見積りする進め方も検討対象です。ITユーザとベンダのための定量的見積りの勧めでは、多段階契約・再見積りや、価格だけで比較しない考え方が示されています。

Webサービス・スマホアプリ開発では、対象規模、含有工程、除外費用、調査時点、標本・調査方法がそろった比較可能な原典がなければ、相場数値だけで自社案件の費用や期間を判断するのは困難です。金額比較の前に、見積条件をそろえることを優先します。

見積金額に差がある場合は、最安値かどうかではなく、範囲、品質、発注者作業、リスク分担の差によるものではないかを確認します。主要な未確定事項が残るなら、準委任先行、工程分割、再見積りの条件も決裁事項に含めます。

06Sectionシステム開発の契約不適合｜不具合を見つけたときの初動

システムに不具合や仕様との差異が見つかったときは、まず契約内容に適合しているかを確認します。エラーが発生したことだけで直ちに結論を出すのではなく、契約書、仕様書、受入基準、見積条件、承認済みの変更記録と照合することが出発点です。

請負の目的物に契約不適合がある場合には、民法上、追完請求・報酬減額請求・損害賠償請求・契約解除が問題となり得ます（請負は有償契約のため、売買の契約不適合責任の規定（第562条〜第564条）が第559条を介して準用されると整理されています）。ただし、第636条は、注文者が提供した材料の性質や注文者の与えた指図によって生じた不適合については、請負人がその材料や指図が不適当であると知りながら告げなかった場合を除き、注文者は追完請求・報酬減額請求・損害賠償請求・契約解除ができないとする、請負人の担保責任を制限する規定です。また第637条には、目的物の種類・品質に関する不適合について、注文者が不適合を知った時から原則1年以内に通知しないと、これらの請求ができなくなる定めがあります。条文は民法第559条、第562条〜第564条、第636条、第637条で確認できます。

一般的な制度上の選択肢としては、追完、代金減額、損害賠償、解除が整理されています。法務省の民法（債権関係）の改正に関する説明資料も参照できます。ただし、契約不適合に当たるか、どの対応を求められるか、責任範囲や条項がどのように扱われるかは、契約条項、仕様、受入基準、通知時期、検収・変更記録、事実関係によって異なります。

07Section契約締結前の最終確認とエスカレーション条件

契約締結前は、契約書だけでなく、個別契約、仕様書、要件定義書、見積書、変更要求票、議事録、テスト記録を一つのセットとして確認します。文書間で内容が異なる場合に備え、優先順位、版数、承認者、更新方法を明確にします。

とくに、仕様書の最新版が見積条件や受入基準に反映されているか、変更内容がスケジュールと報酬条件に反映されているかを確認してください。契約方式を選んだ理由、残るリスク、再判定の時点、責任者も、関係者が追える形で残します。

契約書全体のレビュー観点を確認したい場合は、契約書の確認ポイントも参照してください。

請負契約で重要なのは、契約名ではなく、完成を約束する範囲を具体化することです。成果物、受入基準、対象外、前提条件、変更手続、検収体制をそろえられる範囲は請負として検討し、未確定部分は準委任先行や工程分割で整理すると、発注後の認識差を抑えやすくなります。

開発パートナーを比較する

要件、完成条件、受入基準、変更時の扱いを整理したうえで、開発パートナーの体制や提案内容を比較したい場合に活用できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発のパートナーを探す