システム開発を外部に依頼するとき、最初に交わすのが契約である。そして契約の形によって、開発会社が「完成させる責任を負うのか」「作業に対して対価を払うのか」が変わってくる。ここを理解しないまま進めると、「完成すると思っていた」「期日までに動くはずだった」という発注者側の期待と、「決められた作業をこなした」という開発側の認識がすれ違い、トラブルの火種になる。
本記事は、システム開発でよく使われる請負契約と準委任契約の違いを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門である。法律の専門知識がなくても、「成果物への責任」「指揮命令」「報酬」という三つの軸で見れば、どちらの契約が自社の依頼に合うのかを判断する手がかりになる。なお、契約類型の選択や条項の解釈には個別の事情が関わるため、最終的な判断は弁護士など専門家への確認を前提としていただきたい。
結論：完成責任の有無で契約の性質が変わる
システム開発の契約形態を考えるうえで、まず押さえたいのは「成果物の完成に責任を負うかどうか」である。GXOが発注者に整理をすすめるのは、次の3点である。
- 請負契約は成果物の完成に責任を負い、準委任契約は作業の遂行に対して対価を払う、という性質の違いを理解する
- 開発のどの工程に、どちらの契約が合うのかを工程ごとに考える
- 契約書のタイトルだけで判断せず、責任・報酬・指揮命令の中身を確認する
契約形態は、どちらが優れているという話ではない。依頼する工程や、求める成果の性質によって適した形が変わる。発注前に違いを理解しておくことが、後の認識ずれを防ぐ第一歩になる。
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
なぜ契約形態の違いが重要か
システム開発は、要件を固める工程から、設計、開発、テスト、運用支援まで、性質の異なる作業が連なっている。それぞれの工程で「何を成果とみなすか」が違うため、一律に同じ契約で進めると無理が生じやすい。
契約形態の理解が曖昧だと、次のような問題につながりやすい。
- 完成責任があると思っていたのに、契約上は作業遂行への対価だった
- 期日までに動くものができると期待していたが、成果物の範囲が定まっていなかった
- 追加作業の費用負担をめぐって、双方の前提が食い違う
契約形態は、開発全体の責任分担の土台になる。要件定義の進め方とあわせて理解しておきたい。要件をどう固めるかについては業務システムの要件定義テンプレートも参考になる。
特に中小企業の発注では、開発の実務を社内で経験した人がいないことも多く、「動くものができて当然」という前提で話が進みがちである。だが契約上の性質によっては、完成そのものではなく作業の遂行に対価を払う取り決めになっていることもある。この前提のずれに気づかないまま進むと、納品の段階で期待と現実のギャップが一気に表面化する。だからこそ、契約形態の性質を発注前に理解しておくことが、後の関係をこじらせないために役立つ。
請負契約と準委任契約の基本的な違い
両者は、民法上の典型契約として性質が異なるとされる。発注者が押さえておきたいのは、成果物への責任、指揮命令、報酬の三つの観点である。
横にスクロールして確認できます
| 観点 | 請負契約 | 準委任契約 |
|---|---|---|
| 成果物への責任 | 完成させる責任を負う傾向 | 作業の遂行に対して責任を負う傾向 |
| 報酬の考え方 | 完成した成果物に対して支払う | 作業や工数に対して支払う |
| 指揮命令 | 開発会社側が作業の進め方を決める | 委託の範囲内で進め方を取り決める |
| 向く工程の例 | 仕様が固まった開発・構築 | 要件定義・調査・運用支援など |
ここで注意したいのは、契約書のタイトルが「業務委託契約」などとなっていても、その中身が請負の性質なのか準委任の性質なのかは、責任や報酬の取り決めによって判断されるという点である。タイトルだけでは性質は決まらない。
発注者として押さえておきたいのは、この違いが「誰がリスクを負うか」に直結するという点である。完成責任を伴う契約では、想定どおりに動くものが仕上がるまで開発側が責任を負う傾向がある一方、その分だけ見積もりに余裕が織り込まれることもある。作業遂行に対価を払う契約では、進め方を柔軟に変えやすい反面、成果物の完成そのものは保証の対象になりにくい。どちらの性質が自社の依頼に合うのかは、求める成果が「決まったものを確実に」なのか「進めながら固めていく」なのかで見極めたい。
工程ごとに適した契約を考える
要件定義の工程
要件定義は、何を作るかをこれから固めていく工程である。成果物の輪郭が定まりきっていないため、作業の遂行に対価を払う準委任契約が選ばれることが多い。この段階で完成責任を伴う契約を結ぼうとしても、「何を完成とするか」がまだ決まっていないため、責任の対象が定めにくい。だからこそ、まず作業遂行型で要件を固め、固まった後に開発の契約を結ぶという二段構えが現実的なことがある。AIを活用した要件定義の進め方はAI駆動の要件定義ガイドでも扱っている。
開発・構築の工程
仕様が固まった後の開発・構築は、作るべき成果物が明確になっているため、完成責任を伴う請負契約が選ばれることが多い。何をもって完成とするかを契約で定めておくことが重要になる。
運用・保守の工程
リリース後の運用支援や保守は、状況に応じて作業内容が変わるため、作業遂行に対価を払う準委任契約が選ばれることがある。工程ごとに性質が違うことを前提に、契約を組み立てたい。
このように、一つの開発プロジェクトの中でも、工程によって適した契約の性質は変わりうる。すべてを一律の契約でまとめると、性質の合わない工程で無理が生じやすい。要件定義はこれから固める段階だから作業遂行型、仕様が固まった開発は完成責任を伴う型、というように、工程の性質に合わせて契約を分けて考えると、責任分担が整理しやすくなる。分け方が自社の案件に適しているかは、規模や事情によって変わるため、必要に応じて専門家にも相談しながら決めたい。
発注前に整理しておきたいこと
契約形態を選ぶ前に、発注者側で次の点を整理しておくと、開発会社との相談がスムーズになる。
横にスクロールして確認できます
| 整理する観点 | 確認したいこと |
|---|---|
| 求める成果 | 決まったものを確実に欲しいのか、進めながら固めるのか |
| 工程の範囲 | 要件定義から運用まで、どこを依頼するのか |
| 完成の定義 | 何をもって完成・完了とみなすのか |
| 報酬の根拠 | 成果に対してか、工数に対してか |
これらが整理されていれば、「この工程はこういう性質だから、こういう契約が合う」という会話が成り立つ。逆に、ここが曖昧なまま契約形態だけを先に決めると、後で工程の実態と合わなくなりやすい。
契約形態でよくある失敗
契約形態の理解が浅いと、次のような失敗が起きやすい。いずれも、発注前に性質を確認しておけば避けられる。
- タイトルだけで安心する：「業務委託」という言葉で判断し、完成責任の有無を確認しないまま進める。
- 全工程を一つの契約でまとめる：性質の異なる工程を一律の契約にし、責任分担が曖昧になる。
- 完成の定義を決めない：請負の性質でありながら、何をもって完成とするかが契約に書かれていない。
- 報酬の根拠を確認しない：成果に対してか、工数に対してかが曖昧なまま、追加費用で揉める。
契約形態は、開発が始まってから変えるのは難しい。発注前に、依頼する工程と求める成果の性質を整理しておきたい。要件定義の準備の進め方は要件定義でもめないための準備、契約書全体で確認すべき項目は契約書で確認すべき項目もあわせて参考にされたい。
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。
実務判断のポイント
この記事は、経営者、情シス、業務責任者、発注担当向けです。要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。システム開発の契約・要件定義トラブル回避｜請負契約と準委任契約の違いに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問
Q1. 請負契約と準委任契約は、どちらが発注者に有利ですか
一概にどちらが有利とは言えない。完成した成果物が確実に欲しい工程では完成責任のある契約が安心だが、これから内容を固める工程では作業遂行型のほうが現実的なこともある。依頼する工程の性質によって、適した形は変わる。
Q2. 一つの開発を、工程ごとに違う契約にしてもよいのですか
工程ごとに契約を分ける進め方は実務でも見られる。要件定義は準委任、開発は請負というように分けることで、各工程の性質に合わせやすくなる。分け方の妥当性は、案件の規模や事情によるため、専門家にも相談しながら決めるとよい。
Q3. 契約書のタイトルが「業務委託契約」なら準委任契約ですか
タイトルだけでは性質は決まらない。完成責任や報酬の取り決めなど、契約の中身によって判断される。気になる場合は、責任と報酬の条項を確認し、必要に応じて弁護士など専門家に確認することをおすすめする。
システム開発の契約形態について、発注前に整理しませんか
GXOでは、システム開発の発注にあたり、依頼する工程の性質、求める成果物、契約形態の考え方を整理し、後のトラブルを避けるための準備をご支援します。契約の専門的な判断は専門家と連携しながら進めます。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
