システム開発の契約は「準委任」と「請負」のどちらを選ぶべきか？費用・責任・リスクを整理する

システム開発でよくある2つの契約の違い

システム開発を外部のベンダー（開発を請け負う会社）に依頼するとき、契約書の中に「準委任契約」や「請負契約」という言葉が出てくることがあります。担当者として、ベンダーが用意した契約書にそのままサインしたくなる場面もあるかもしれません。しかし、どちらの契約を選ぶかによって、費用の決まり方や責任の所在、トラブル時の対応範囲は大きく変わります。

この記事では、開発に詳しくない担当者の方でも理解できるように、2つの契約の仕組みを整理して解説します。難しい法律用語はできるだけ避けながら、「自社にはどちらが向いているのか」を判断できる状態を目指します。

作業を依頼する契約と成果を約束する契約の考え方

まず、2つの契約の根本的な考え方の違いを押さえておきましょう。

準委任契約は、「この作業を進めてください」と依頼する契約です。一定の専門スキルを持つ人材に業務を委託し、その活動そのものに対して報酬を支払います。たとえば、「月に160時間、設計や開発作業を進めてください」という形で依頼するイメージです。この場合、作業の結果として何かが完成することを約束するものではなく、あくまで時間と労力を投じて業務を遂行してもらうことに対して費用が発生します。

一方、請負契約は、「この成果物を完成させてください」と約束する契約です。「〇〇という機能を持ったシステムを△月△日までに納品してください」という形で依頼し、ベンダーはその成果物を完成させて納品する義務を負います。作業にかかった時間や人数ではなく、「完成品を届けること」が契約の中心になります。

この違いを一言で表すなら、準委任は「作業に対する報酬」、請負は「成果に対する報酬」と整理できます。

それぞれで発注側が負う役割の違い

2つの契約では、発注側である自社が担う役割も異なります。

準委任契約の場合、ベンダーは「業務を進めること」に責任を持ちますが、「成果物を完成させること」までは直接の法的義務を負いません。そのため、開発の方向性や優先順位を発注側が積極的に決めていく必要があります。「次に何を作るか」「この機能は本当に必要か」といった判断を随時行い、進捗を確認しながら必要に応じて軌道修正することが重要になります。

請負契約の場合は、ベンダーが「完成と納品」に責任を持つため、発注側は最初の段階で「何を作ってほしいか」をできるだけ明確にしておく必要があります。仕様（どんな機能を、どんな動きで実現するかの詳細）が曖昧なまま契約すると、後から「その機能は契約範囲に含まれていない」といった認識のズレが起きやすくなります。

どちらが楽かという話ではなく、それぞれで求められる関わり方が違うと理解しておくことが大切です。

進め方と責任の違いは費用にどう影響するか

作業時間に応じて費用が変わる場合

準委任契約では、費用が「実際にかかった時間や工数（作業量）」に応じて決まることが一般的です。たとえば、「エンジニア1人あたり月100万円で、3か月間対応してもらう」というように、月額や時間単価を設定します。開発が長引けば費用も増え、早く終われば費用を抑えられる構造です。

この仕組みは柔軟性が高い反面、「最終的にいくらかかるかを事前に確定しにくい」という性質があります。追加作業が発生しても、その作業時間が契約の枠内であれば収まる場合がありますが、枠を超えれば別途請求になることが一般的です。

金額があらかじめ決まりやすい場合

請負契約では、「このシステムを完成させるための費用は合計〇〇円」というように、最初に総額が決まることが多くなります。発注側にとっては予算管理がしやすく、「いくらかかるかわからない」という不安を持ちにくい点がメリットです。

ただし、この総額は、あくまで最初に合意した仕様の範囲に対するものです。途中で「やはりこの機能も追加したい」「この画面の動きを変えたい」といった変更が生じた場合には、追加費用や納期の延長が発生する可能性があります。

追加対応や手戻りが発生したときの費用の考え方

どちらの契約でも、手戻り（一度作ったものをやり直すこと）や追加対応は費用に影響します。ただし、その影響の出方は異なります。

準委任契約では、手戻りや方向転換も「作業の一部」として時間に含まれるため、費用への影響はある程度そのまま反映されます。ただし、大きな方向転換が何度も起きると、その分だけ工数が膨らみ、結果として費用も大きくなります。請負契約では、当初の仕様から外れる変更は「追加費用」として別途見積もりになるケースがほとんどです。発注側が「この程度ならすぐ対応してもらえるだろう」と考えていても、ベンダー側では追加作業として扱われることがあります。

こうした認識のズレはトラブルの原因になりやすいため、変更が生じた場合の費用の扱いを契約前に明確にしておくことが重要です。

案件の性質によって向いている契約は変わる

要件が固まっていない案件で選ばれやすい形

「どんな機能が必要かはおおよそ見えているが、細かい仕様はまだ決まっていない」という状況では、準委任契約が選ばれることが多くあります。要件（開発に求める条件や機能）を整理しながら、並行して開発を進めるスタイルが取りやすいためです。

アジャイル開発（短いサイクルで開発と確認を繰り返す手法）を採用する案件では特にこの形が使われやすく、「まず動くものを作り、フィードバックを反映しながら育てていく」という進め方と相性が良い契約です。

仕様が明確な案件で選ばれやすい形

「既存の紙の帳票をそのままデジタル化したい」「現在の業務フローをそのまま置き換えたい」など、作るべきものが比較的明確な案件では、請負契約が向いています。仕様を詳細に定義したうえで「これを作ってください」と依頼し、完成品を受け取る流れを取りやすいためです。

特に、納期が厳しい案件や、複数の外部サービスと連携させる必要がある案件など、「何を、いつまでに、どの状態で納品するか」を明確に決める必要があるプロジェクトでは、請負契約のわかりやすさが活きます。

途中変更が多いときに注意したいポイント

実際の開発では、「最初の想定と実態がずれてくる」ことは珍しくありません。準委任契約では変更への対応は柔軟ですが、際限なく変更を続けると費用が膨らみやすくなります。請負契約では変更のたびに追加見積もりが必要になり、スケジュールも崩れやすくなります。

どちらの契約形態であっても、「変更が起きたときにどう扱うか」というルールを契約時にあらかじめ決めておくことが、トラブル防止の観点から非常に重要です。

見積もりと支払い方法の違いを理解する

時間や工数をもとに見積もる方法

準委任契約の見積もりは、「誰が、何時間、いくらの単価で働くか」という工数ベースで算出されます。たとえば、「シニアエンジニア1名（月単価80万円）とジュニアエンジニア1名（月単価50万円）で4か月」という形であれば、合計費用は（80万円＋50万円）×4か月＝520万円という計算になります。

この見積もりは想定工数に基づくため、実際に作業を進める中で増減することがあります。見積もり段階で「上限金額はいくらか」「工数が増えた場合はどのように通知されるか」を確認しておくと安心です。

総額を決めて進める方法

請負契約の見積もりは、完成させる成果物全体に対する総額として提示されることが一般的です。「この仕様のシステムを作るなら合計350万円」という形で、内訳として設計、開発、テスト、導入などの工程が含まれます。

総額が固定されやすいため予算を立てやすい反面、ベンダー側も見込まれるリスクを金額に含めて見積もることがあります。そのため、単純に「請負の方が安い」とは言い切れません。案件の性質や要件の確定度によって、どちらが結果的に費用を抑えやすいかは変わります。

予算超過を防ぐために見ておきたい点

どちらの契約形態でも、予算超過リスクを抑えるために確認しておきたいポイントがあります。準委任契約では、月ごとの稼働上限と、超過した場合の単価設定を必ず確認してください。あわせて、工程ごとに費用を見直す仕組みがあるかどうかも重要です。

請負契約では、仕様変更が発生した場合の追加費用の算出基準と、変更を依頼する際の手続きを明確にしておく必要があります。口頭で依頼した変更が後から費用請求の対象になることもあるため、変更内容はできるだけメールなどで記録に残す運用が有効です。

契約前に確認しておきたい重要項目

どこまでを納品物とするか

「何が納品されるのか」を明確にしておくことは、どの契約でも基本です。プログラム本体だけでなく、設計書、操作マニュアル、テスト結果報告書なども納品物に含まれるか確認してください。特に準委任契約では「作業を行うこと」が中心になるため、成果物の定義が曖昧になりやすい傾向があります。

この契約で最終的に何を受け取れるのかを書き出して確認するだけでも、後々の認識違いを大きく減らせます。

検収の条件と完了の判断基準

「検収」とは、納品された成果物が契約どおりに完成しているかを確認し、承認する作業のことです。どのような条件を満たせば検収完了とするのか、たとえば「指定したテスト項目をすべて通過すること」といった基準を事前に決めておく必要があります。

特に請負契約では、検収が完了した時点でベンダーの完成義務が果たされたと判断されます。検収基準が曖昧なまま進めると、「もう完成していると考えるベンダー」と「まだ修正してほしい点がある発注側」の間で認識のズレが起きることがあります。

不具合が見つかった場合の対応範囲

運用開始後に不具合（バグ）が見つかることは珍しくありません。請負契約では、納品後に見つかった不具合について、ベンダーが一定期間内に無償で修正する責任を負うのが一般的です。対応期間は契約によって異なりますが、納品後3か月から1年程度とされることが多くなっています。

準委任契約では、ベンダーは成果物の完成を保証していないため、同じ考え方は原則として当てはまりません。不具合修正も「追加の作業」として工数に含まれる形になります。いずれの場合も、どこまでが無償対応の範囲に入るのかを契約前に確認しておくことが重要です。

作ったシステムや資料の権利の扱い

開発したプログラムのソースコードや設計書などには権利が発生します。費用を支払って作ってもらったのだから自社のものになると考えがちですが、契約で権利の移転を明記していない場合、権利がベンダー側に残ることがあります。

将来的にベンダーを変更したい場合や、自社で修正を加えたい場合、別のサービスと連携したい場合には、ソースコードや設計書の扱いが大きな影響を持ちます。成果物の権利が誰に帰属するのか、ソースコードは納品されるのかを、契約書で必ず確認してください。

ケース別に見る選び方のポイント

新しい業務を整理しながら開発したい場合

「業務フローがまだ固まっていない」「必要な機能を探りながら進めたい」という場合は、準委任契約で柔軟に進める方が現実的です。完成像が見えていない段階で請負契約を結ぶと、後から想定とのズレが生じやすく、追加費用や工期延長が繰り返されるリスクがあります。

このような場合は、まず準委任契約で要件整理の工程を1〜2か月ほど進め、その後に請負契約で本開発を依頼するという進め方も有効です。

既存業務をそのままシステム化したい場合

「現在の業務手順はほぼ決まっており、それをデジタルに置き換えたい」という場合は、請負契約が向いています。業務フローが明確であれば仕様を固めやすく、請負契約のメリットである費用の見通しや完成責任の明確さを活かせます。

ただし、「ほぼ決まっている」と思っていた業務でも、実際に設計書に落とし込むと未確定な部分が見えてくることがあります。設計工程で丁寧に仕様を確定させる時間を確保することが、後半のトラブルを防ぐポイントです。

小さく始めて段階的に広げたい場合

「まずは最小限の機能だけ作り、使いながら段階的に広げたい」という場合は、フェーズを分けて契約する方法が有効です。第1フェーズは準委任で要件整理と基本機能の開発を行い、第2フェーズ以降は請負で追加機能を開発する進め方であれば、柔軟性とコスト管理を両立しやすくなります。

小さく始めることで、実際に使ってみてわかる課題を次のフェーズに反映できるため、最終的に使われないシステムを作ってしまうリスクも下げられます。

迷ったときに発注側が押さえるべき判断基準

自社で決められていることと未確定なことを分ける

どちらの契約が向いているかを判断するうえで、最初に行いたいのは「自社の要件がどこまで固まっているか」を整理することです。機能の一覧を書けるか、業務フローを図で説明できるか、利用する画面のイメージがあるか、といった観点で確認すると整理しやすくなります。

要件の7割以上が固まっているなら請負契約も検討しやすくなります。半分以下しか固まっていないなら、まずは準委任契約で要件整理から始める方が現実的です。

費用の見えやすさと変更への強さを比べる

この表はあくまで一般的な傾向です。実際の契約内容はベンダーによって異なるため、契約書の中身を確認し、不明な点は遠慮なく質問することが大切です。

ベンダーに事前確認したい質問一覧

契約締結前には、ベンダーにいくつかの重要な点を確認しておくと安心です。

まず確認したいのは、「この契約は準委任と請負のどちらなのか、またその理由は何か」という点です。ここを聞くことで、ベンダーがどのような前提で契約形態を提案しているのかが見えてきます。

次に、費用が変動する可能性があるか、変動する場合はどのタイミングで、どのように通知されるのかを確認しておきましょう。あわせて、仕様変更が起きた場合に費用と工期がどう変わるのかも確認しておくと安心です。

納品物の範囲も重要です。ソースコード、設計書、マニュアルなど、何を受け取れるのかを書面で共有してもらうと、後の認識違いを防ぎやすくなります。

さらに、検収の判断基準、納品後の不具合対応の範囲と期間、権利の帰属先についても確認しておく必要があります。これらに明確に答えられるベンダーは、プロジェクト管理に慣れている可能性が高く、信頼できるパートナーとして期待しやすいでしょう。回答が曖昧な場合は、契約前に書面での確認を求めることをお勧めします。

よくある質問

Q1. 準委任と請負、どちらが費用を抑えられますか？

一概にどちらが安いとは言えません。要件が明確であれば請負の方が無駄な費用が発生しにくいことがあります。一方で、要件が曖昧なまま請負で進めると、変更のたびに追加費用が膨らむことがあります。自社の状況に合った契約形態を選ぶことが、結果的に費用を抑える近道です。

Q2. 小規模な開発でも契約の種類は重要ですか？

はい、規模に関係なく重要です。小規模であっても、「何を作るのか」「費用はいくらか」「完成の基準は何か」が不明確なまま進めると、後から認識のズレが起きやすくなります。金額が小さい案件ほど、シンプルで明確な契約内容にしておくことがトラブル防止につながります。

Q3. ベンダーから『準委任にしましょう』と言われましたが、問題ありませんか？

ベンダーがどちらを提案するかには理由があることが多くあります。「要件がまだ不明確なので、まずは準委任で進めましょう」という提案であれば合理的です。一方で、仕様がある程度明確なのに準委任を強く勧める場合は、完成責任を負う範囲を狭くしたい意図がないかという視点で確認することも必要です。理由を聞いたうえで、自社の状況に合っているかを判断してください。

Q4. 途中で契約の種類を変えることはできますか？

はい、可能です。実際に、「要件整理の段階は準委任、本開発は請負」という形でフェーズごとに切り替えるプロジェクトは珍しくありません。切り替えのタイミングと、その時点で何を確定させるのかを事前に合意しておくことが重要です。

Q5. 契約書を自分でチェックする自信がありません。どうすれば良いですか？

契約書の内容に不安がある場合は、法務に詳しい担当者や顧問弁護士に確認を依頼することをお勧めします。また、独立行政法人情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書」も参考になります。発注側にとって確認すべき観点が整理されており、無料で入手できます。

まとめと次のステップ

準委任契約と請負契約には、それぞれ向いている場面があります。要件が固まっていないなら準委任、完成物が明確なら請負、という基本的な考え方を持ちながら、費用の変動リスク、変更への対応、完成責任の有無といった観点で、自社のプロジェクトに合った形を選ぶことが重要です。

大切なのは、どちらが正解かを先に決めることではなく、「自社が今どの段階にいるのか」を正直に把握することです。契約前に疑問点をしっかり確認し、認識のズレをなくしておくことが、プロジェクトを円滑に進める最も確実な方法です。

自社に向いている契約形態の判断に迷う場合や、見積もりのどこを確認すべきか整理したい場合は、早い段階で相談先を持っておくと安心です。開発に詳しくない担当者の方でも進めやすいように、現状整理から支援できる体制を整えておくことが、失敗を防ぐ実務的な一歩になります。