システム開発を外部に依頼するとき、最初に交わすのが契約である。そして契約の形によって、開発会社が「完成させる責任を負うのか」「作業に対して対価を払うのか」が変わってくる。ここを理解しないまま進めると、「完成すると思っていた」「期日までに動くはずだった」という発注者側の期待と、「決められた作業をこなした」という開発側の認識がすれ違い、トラブルの火種になる。

本記事は、システム開発でよく使われる請負契約と準委任契約の違いを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門である。法律の専門知識がなくても、「成果物への責任」「指揮命令」「報酬」という三つの軸で見れば、どちらの契約が自社の依頼に合うのかを判断する手がかりになる。なお、契約類型の選択や条項の解釈には個別の事情が関わるため、最終的な判断は弁護士など専門家への確認を前提としていただきたい。

結論：完成責任の有無で契約の性質が変わる

システム開発の契約形態を考えるうえで、まず押さえたいのは「成果物の完成に責任を負うかどうか」である。GXOが発注者に整理をすすめるのは、次の3点である。

  • 請負契約は成果物の完成に責任を負い、準委任契約は作業の遂行に対して対価を払う、という性質の違いを理解する
  • 開発のどの工程に、どちらの契約が合うのかを工程ごとに考える
  • 契約書のタイトルだけで判断せず、責任・報酬・指揮命令の中身を確認する

契約形態は、どちらが優れているという話ではない。依頼する工程や、求める成果の性質によって適した形が変わる。発注前に違いを理解しておくことが、後の認識ずれを防ぐ第一歩になる。

なぜ契約形態の違いが重要か

システム開発は、要件を固める工程から、設計、開発、テスト、運用支援まで、性質の異なる作業が連なっている。それぞれの工程で「何を成果とみなすか」が違うため、一律に同じ契約で進めると無理が生じやすい。

契約形態の理解が曖昧だと、次のような問題につながりやすい。

  • 完成責任があると思っていたのに、契約上は作業遂行への対価だった
  • 期日までに動くものができると期待していたが、成果物の範囲が定まっていなかった
  • 追加作業の費用負担をめぐって、双方の前提が食い違う

契約形態は、開発全体の責任分担の土台になる。要件定義の進め方とあわせて理解しておきたい。要件をどう固めるかについては業務システムの要件定義テンプレートも参考になる。

特に中小企業の発注では、開発の実務を社内で経験した人がいないことも多く、「動くものができて当然」という前提で話が進みがちである。だが契約上の性質によっては、完成そのものではなく作業の遂行に対価を払う取り決めになっていることもある。この前提のずれに気づかないまま進むと、納品の段階で期待と現実のギャップが一気に表面化する。だからこそ、契約形態の性質を発注前に理解しておくことが、後の関係をこじらせないために役立つ。

請負契約と準委任契約の基本的な違い

両者は、民法上の典型契約として性質が異なるとされる。発注者が押さえておきたいのは、成果物への責任、指揮命令、報酬の三つの観点である。

観点請負契約準委任契約
成果物への責任完成させる責任を負う傾向作業の遂行に対して責任を負う傾向
報酬の考え方完成した成果物に対して支払う作業や工数に対して支払う
指揮命令開発会社側が作業の進め方を決める委託の範囲内で進め方を取り決める
向く工程の例仕様が固まった開発・構築要件定義・調査・運用支援など

ここで注意したいのは、契約書のタイトルが「業務委託契約」などとなっていても、その中身が請負の性質なのか準委任の性質なのかは、責任や報酬の取り決めによって判断されるという点である。タイトルだけでは性質は決まらない。

発注者として押さえておきたいのは、この違いが「誰がリスクを負うか」に直結するという点である。完成責任を伴う契約では、想定どおりに動くものが仕上がるまで開発側が責任を負う傾向がある一方、その分だけ見積もりに余裕が織り込まれることもある。作業遂行に対価を払う契約では、進め方を柔軟に変えやすい反面、成果物の完成そのものは保証の対象になりにくい。どちらの性質が自社の依頼に合うのかは、求める成果が「決まったものを確実に」なのか「進めながら固めていく」なのかで見極めたい。

工程ごとに適した契約を考える

要件定義の工程

要件定義は、何を作るかをこれから固めていく工程である。成果物の輪郭が定まりきっていないため、作業の遂行に対価を払う準委任契約が選ばれることが多い。この段階で完成責任を伴う契約を結ぼうとしても、「何を完成とするか」がまだ決まっていないため、責任の対象が定めにくい。だからこそ、まず作業遂行型で要件を固め、固まった後に開発の契約を結ぶという二段構えが現実的なことがある。AIを活用した要件定義の進め方はAI駆動の要件定義ガイドでも扱っている。

開発・構築の工程

仕様が固まった後の開発・構築は、作るべき成果物が明確になっているため、完成責任を伴う請負契約が選ばれることが多い。何をもって完成とするかを契約で定めておくことが重要になる。

運用・保守の工程

リリース後の運用支援や保守は、状況に応じて作業内容が変わるため、作業遂行に対価を払う準委任契約が選ばれることがある。工程ごとに性質が違うことを前提に、契約を組み立てたい。

このように、一つの開発プロジェクトの中でも、工程によって適した契約の性質は変わりうる。すべてを一律の契約でまとめると、性質の合わない工程で無理が生じやすい。要件定義はこれから固める段階だから作業遂行型、仕様が固まった開発は完成責任を伴う型、というように、工程の性質に合わせて契約を分けて考えると、責任分担が整理しやすくなる。分け方が自社の案件に適しているかは、規模や事情によって変わるため、必要に応じて専門家にも相談しながら決めたい。

発注前に整理しておきたいこと

契約形態を選ぶ前に、発注者側で次の点を整理しておくと、開発会社との相談がスムーズになる。

整理する観点確認したいこと
求める成果決まったものを確実に欲しいのか、進めながら固めるのか
工程の範囲要件定義から運用まで、どこを依頼するのか
完成の定義何をもって完成・完了とみなすのか
報酬の根拠成果に対してか、工数に対してか

これらが整理されていれば、「この工程はこういう性質だから、こういう契約が合う」という会話が成り立つ。逆に、ここが曖昧なまま契約形態だけを先に決めると、後で工程の実態と合わなくなりやすい。

契約形態でよくある失敗

契約形態の理解が浅いと、次のような失敗が起きやすい。いずれも、発注前に性質を確認しておけば避けられる。

  • タイトルだけで安心する：「業務委託」という言葉で判断し、完成責任の有無を確認しないまま進める。
  • 全工程を一つの契約でまとめる：性質の異なる工程を一律の契約にし、責任分担が曖昧になる。
  • 完成の定義を決めない：請負の性質でありながら、何をもって完成とするかが契約に書かれていない。
  • 報酬の根拠を確認しない：成果に対してか、工数に対してかが曖昧なまま、追加費用で揉める。

契約形態は、開発が始まってから変えるのは難しい。発注前に、依頼する工程と求める成果の性質を整理しておきたい。要件定義の準備の進め方は要件定義でもめないための準備、契約書全体で確認すべき項目は契約書で確認すべき項目もあわせて参考にされたい。

よくある質問

Q1. 請負契約と準委任契約は、どちらが発注者に有利ですか

一概にどちらが有利とは言えない。完成した成果物が確実に欲しい工程では完成責任のある契約が安心だが、これから内容を固める工程では作業遂行型のほうが現実的なこともある。依頼する工程の性質によって、適した形は変わる。

Q2. 一つの開発を、工程ごとに違う契約にしてもよいのですか

工程ごとに契約を分ける進め方は実務でも見られる。要件定義は準委任、開発は請負というように分けることで、各工程の性質に合わせやすくなる。分け方の妥当性は、案件の規模や事情によるため、専門家にも相談しながら決めるとよい。

Q3. 契約書のタイトルが「業務委託契約」なら準委任契約ですか

タイトルだけでは性質は決まらない。完成責任や報酬の取り決めなど、契約の中身によって判断される。気になる場合は、責任と報酬の条項を確認し、必要に応じて弁護士など専門家に確認することをおすすめする。

システム開発の契約形態について、発注前に整理しませんか

GXOでは、システム開発の発注にあたり、依頼する工程の性質、求める成果物、契約形態の考え方を整理し、後のトラブルを避けるための準備をご支援します。契約の専門的な判断は専門家と連携しながら進めます。

システム開発の発注相談をする

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。