【発注者必読】システム開発の契約形態 -請負と委託(準委任契約)-

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

システムを活用する側の企業の皆様は、システム開発時にどのような契約方法があるかご存知でしょうか?IT法務に詳しい人材がいないユーザー企業では、IT企業が持ってきた契約内容のまま契約してしまい、後々訴訟などのトラブルになってしまう事が少なくありません。

IT法務は契約を締結する前に必ず学んでおかなければならないものです。「契約」という性質上、難しく感じられる人が多いですが、実はそれほど難しくありません。システム開発でよく使われる契約形態はたった2種類だけです。

この記事では、IT部門にて契約を担当してきた筆者が、システムを活用する企業向けにシステム開発に関する契約内容をどこよりも分かりやすく解説します。この記事を読んで、最適な契約形態でシステム開発を行って下さい。

1.システム開発時の主な契約方法

システム開発における契約方法は主に「請負契約」と「委託契約」の2種類があります。
それぞれ単独で使うことも、「要件定義は委託契約」で、「設計以降の工程は請負契約」のように開発工程別に契約内容を分けて使うこともあります。

一般的には要件定義や基本設計までは委任契約で行い、以降の工程は請負契約で契約する多段階契約といわれる方法が多いです。
それぞれの契約にメリット・デメリットや注意点がありますので、この記事でしっかり学んで下さい。

2.請負契約

2.1.請負契約とは

請負契約とは民法第632条で以下のように定義されている契約です。

「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。」

簡単に言うと、請負契約とは「依頼した仕事が完了した場合に報酬を支払う」という契約です。
例えば、「○月○日までにXXの機能を持った販売管理システムを納品する」というシステム開発を請負契約でIT企業に発注したとします。

この場合IT企業は依頼された仕事の完成責任と瑕疵担保責任を持ちます。また、発注者はIT企業(受注者)に対して指揮命令権を持たないため開発方法に対して法的な拘束はできません。

瑕疵担保責任とは、簡単にいうと「受注者は発注者と合意した品質を担保しなければならない」という民法第634条で定められている法律で以下のように定義されています。

1.仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、相当の期間を定めて、その瑕疵の修補を請求することができる。ただし、瑕疵が重要でない場合において、その修補に過分の費用を要するときは、この限りでない。

2.注文者は、瑕疵の修補に代えて、又はその修補とともに、損害賠償の請求をすることができる。この場合においては、第533条の規定を準用する。

つまり、定められた品質で納品されなかった場合に改修を指図したり、場合によっては損害賠償を請求できるという法律です。

請負契約の特徴を整理すると以下になります。

  • IT企業(受注者)に完成責任と瑕疵担保責任がある
  • IT企業(受注者)が指揮命令権を持つ
  • 発注者は完成品の明確な定義を示す必要がある(仕様を決める責任がある)

2.2.請負契約のメリット

納期と品質が担保されるため、発注者側にとって安全な契約

請負契約では、完成責任と瑕疵担保責任をIT企業(受注者)が持つため、納期と品質が法律で担保されることから発注者側にとって安全な契約と言えます。

例えば、納品されたシステムが仕様と異なる上バグだらけで使い物にならなかったとします。
請負契約の場合、完成責任と瑕疵担保責任がIT企業(受注者)にあるため支払をする必要がありません。仕様が不明確など発注者側にも非がある場合はこの限りではありません。

ただし、完成責任と瑕疵担保責任がIT企業にあっても、遂行できるかどうかは別問題です。請負契約で発注した後にIT企業に遂行能力がなかったという事も多くあります。その場合は訴訟になりますが、工程別に多段階で契約を締結していた場合、終わっている工程については費用を払わなければならないケースもあります。

2.3.請負契約のデメリット

完成品の明確な定義を示す必要がある(仕様を決める責任がある)

請負契約の場合、その性質上開発が始まる前にその仕様など完成品の明確な定義を示す必要があります。そのため、仕様が曖昧な場合請負契約を結べません。よって要件定義を委託契約(準委任契約)でIT企業とともに行い、設計工程から請負契約で行うケースが多くあります。この事は後で詳しく解説します。

開発途中での仕様変更が難しい

あらかじめ完成品の定義を両社で合意した上で締結する契約のため、開発途中での仕様変更が難しくなります。変更ボリュームによりますが、仕様変更により開発工数が増える場合別途費用が必要になります。

実際の開発費用よりも多く費用が掛かる場合がある

請負契約の場合、「決められた納期までに依頼された仕事を定められた品質で完成すること」がIT企業(受注者)に求められますが、その開発過程は問われません。
従って下請けに出そうが海外に発注(オフショア)しようが受注者の自由です。
1,000万円で発注した仕事をIT企業(受注者)が学生インターンのプログラマーに開発させて300万円で作ったとしても1,000万円支払わなければなりません。そのため開発費用の妥当性を見分ける力が求められます。

3.委託契約

3.1.委託契約とは

委託契約には「委託契約」と「準委任契約」があり、システム開発は主に「準委任契約」で行われます。準委任契約は民法第656条で以下のように定められている契約です。

準委任(じゅんいにん)とは、法律行為ではない事実行為の事務の委託することをいう。準委任にも、委任の規定が準用される。

簡単にいうと準委任契約とは、「業務の提供に対して報酬を支払う」契約のことです。派遣に似た契約で常駐してシステム業務を行ってもらったり、開発してもらったりする場合に良く使われる契約です。別名「業務委託契約」や「システムエンジニアリング契約(SES契約)」と呼ばれています。

ただし、派遣契約と異なり発注者は指揮命令権を持たないため、業務提供してもらっている人に対しての指示を直接行うことができません。指示する場合、受注者の管理責任者を通す必要があります。

また、「業務の提供に対して報酬を支払う」という契約のため、IT企業(受注者)は完成責任と瑕疵担保責任を持ちません。

例えば、あるシステムを開発を業務委託契約で常駐して作業してもらったとします。期待したシステムが契約期間内に完成しなくてもIT企業(受注者)に責任を問うことはできません。
逆に言えば、働いてもらった時間に対して費用を支払えば良いので、費用の妥当性が明快な契約とも言えます。

準委任契約の特徴を整理すると以下になります。

  • IT企業(受注者)は完成責任と瑕疵担保責任を持たない
  • 期間が決まっている
  • IT企業(受注者)が指揮命令権を持つ
  • 業務の結果は一般的に報告書で行う

3.2.準委任契約のメリット

仕様変更に柔軟に対応できる

請負契約の場合、事前に開発ボリュームを見積り、発注者と受注者の間で仕様を合意した上で開発が始まります。そのため、開発開始後に仕様を変更する場合に別途費用が発生する可能性があります。一方準委任契約の場合は「業務の提供」という契約内容のため仕様変更にも柔軟に対応できるというメリットがあります。

一般的には、請負契約でも準委任契約でも開発開始前に仕様が固まっているべきですが、なかなか仕様を決められない発注者も多くありません。納期は動かせないため曖昧な仕様のままとりあえず開発をスタートし、後になって大きな変更が必要になってしまうことも少なくありません。

請負契約ではこのようなケースは柔軟に対応できないことが多いですが、準委任契約の場合は費用に影響がないため柔軟に対応ができます。
(契約期間の延長による費用増はあります)

費用の妥当性が明快

準委任契約の場合、請負契約と異なり費用の妥当性が明快です。例えば、若手のエンジニアを1名1ヶ月フルタイムで雇いたいとします。この場合契約内容は、月140時間~170時間の稼動で月単価60万円、140時間~170時間を増減した場合1時間単位で別途精算という形が多いです。

1時間あたりの精算金額は60万÷160時間で3,750円となります。つまり働いてもらった時間だけ費用が発生する仕組みのため、費用の妥当性が明快なのです。
※若手エンジニアの価格は例です。企業により価格は異なります。

3.3.準委任契約のデメリット

IT企業(発注先)に完成責任と瑕疵担保責任がないこと

準委任契約の場合「業務の提供」に対して報酬を支払うという契約でありIT企業(発注先)に完成責任と瑕疵担保責任がありません。そのため、品質が悪かったり開発スケジュール遅延があったりしてもIT企業(発注先)に責任はありません。
品質やスケジュール遅延の責任は全て発注者にあります。よってシステム開発やプロジェクトマネジメントに詳しい人材がいない企業では準委任契約での開発は難しいといえます。

4.システム開発における多段階契約

ここまで請負契約と委託契約について詳しく解説してきました。
契約内容の概要を理解できたのではないでしょうか。システム開発の契約は、上述した「請負契約」と「準委任契約」を組合せて行うことが多くあります。この章では、工程別にどのような契約形態でシステム開発を行うのか詳しく解説します。

4.1.多段階契約とは

請負契約と委託契約(準委任契約)はそれぞれ単独で使うこともありますが、システム開発においては工程ごとに請負契約と委託契約を分けて行う方法が一般的です。
このことを、「多段階契約」といいます。

〈工程別の契約形態〉

プロジェクト工程

契約形態

システム導入企画

準委任契約

要件定義

準委任契約

基本設計

準委任契約または請負契約

詳細設計

請負契約

コーディング

請負契約

単体テスト

請負契約

結合テスト

請負契約

総合テスト

請負契約

運用テスト(受入試験)

準委任契約

開発費用が1,000万円を超えるような開発では、このように工程別に契約形態を分けて契約するケースがほとんどです。

4.2.システム導入企画~要件定義工程

システム導入企画や要件定義を通して実装すべき機能や満たすべき性能を「発注者とともに」明確にしていきます。発注者と受注者の共同作業になるため、一般的にこの工程は準委任契約で行われます。

4.3.基本設計工程

基本設計は、要件定義がしっかりできている場合は請負契約で行うケースがほとんどです。逆に、発注者側が決めきれてないなど後々開発ボリュームが変わりそうな場合基本設計を準委任契約で行うこともあります。

4.4.詳細設計工程~総合テスト工程

詳細設計~総合テストは、要件定義と基本設計で定義した仕様に基づきIT企業が作業する工程になるため、請負契約になります。

4.5.運用テスト(受入試験)工程

運用テスト(受入試験)は発注者側にて品質確認してもらう必要があるため、準委任契約でIT企業がサポートして行う形が多いです。

このようにシステム開発は工程別に契約形態を分ける多段階契約が主流です。ただし、開発が小規模であったり、開発が発生しないシステム導入の場合多段階契約にせず請負契約のみで行うことも多くあります。このケースは「一括請負」と呼ばれています。

5.まとめ

この記事ではシステムを活用する企業向けに、システム開発に関する契約内容を初心者でも理解できるようなるべく分かりやすく解説してきました。請負契約と委託契約の違いなどだいぶ理解が進んだのではないでしょうか。

IT法務は「法律」に関することなので読んでいて楽しいものではないかと思いますが、IT担当者や発注者は必ず抑えておくべき内容です。発注金額が1,000万円を超すような案件では、ITコンサルタントなどに入ってもらうことも時には必要です。契約のたびにこの記事を読み直して最適な契約形態を選択して下さい。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る