システム開発で、請負契約を結ぶ際の注意点とは

ITシステムを開発するプロジェクトで締結される契約は主に、請負契約と準委任契約です。ユーザーにとってもベンダーにとっても、それぞれの契約型を採用することにはメリット・デメリットは様々ですが、その特徴と締結する際の注意点を把握することは重要です。本記事では、ITシステムの開発業務における請負契約について解説していきます。

システム開発と請負契約

請負契約とは

請負契約とはなにかを知る際には、まずなにより重要なのは、直接条文上から請負契約の成立要件を確認することです。

第632条

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

「仕事の完成」というのがなにより重要なキーワードです。請負契約の代表例は、工事を要する建物の建設です。たとえば、期日までに家屋やビルを建設することをもって、「仕事の完成」とし、債務は履行されたことになるということです。逆にもし工事が進まずに納期に遅れた場合は、一定の条件下で履行遅滞として債務不履行責任が課されます。しかしもし一度「仕事の完成」が認められれば、そこで債務不履行の問題はなくなり、以後は瑕疵担保責任の問題となります。こうした意味でも、「仕事の完成」という結果をきわめて重視する点こそが請負契約の特徴です。なお、何を持って「仕事の完成」が認められるのかについては、以下の記事にて詳細に説明しています。

請負契約は、建設のみならず、大きな構想と細やかな計画性を要するシステム開発プロジェクトにもよく用いられます。

請負契約と準委任契約の違いとは

また、請負契約が「仕事の”完成”」という結果重視の特色をもつ契約類型であることがわかると、同時に準委任契約の特徴もわかってきます。こちらは、「完成」という結果ではなく、プロセスの部分を重視するものです。たとえば、成果がどうあれ事務処理自体が適切に進められていたのであれば報酬の請求は可能であり（648条2項）、受任者の責めに帰すことができない事由で履行が中途で終了した場合には、その割合に応じて報酬の請求することも可能であると定められています（648条3項）。

なお、委任契約と準委任契約の比較に関しては、以下の記事にて詳細に解説しています。

システム開発で請負契約が好まれる理由

システム開発の契約では、請負はきわめて多く用いられます。請負が多く用いられる理由は、仕事を発注するユーザー側・受注するベンダー側双方にとって一定のメリットがあるためです。

まず、ユーザーにとって請負で業務を発注するメリットは、債務の履行要件が「仕事の完成」というかたちで明確化しやすい点が挙げられます。つまり、（後からバグが見つかったりなどで、瑕疵担保責任の問題が出てくることは一旦不問にしても）「完成」したといえる状態にならない限り、報酬の支払いは原則行わなくて良いという明快さがあるのです。このことは、予想以上に工数がかさんでしまったり、工期が長引いてしまったりした場合などに、支払うべき報酬が膨れ上がる危険をとりたくないユーザーにとって大きな魅力になりえます。「完成」させた成果物と等価交換にて、定額の報酬を払うという建てつけには予算管理の点からみても大きな利便性があります。

また一方で、仕事を受けるベンダー側にとっても、請負にて受注することには一定のメリットが見込める場合があります。請負契約は、うまく進めることができれば、準委任契約よりも大きな利益率が見込めるからです。

「仕事の完成」させることが債務の履行のための要件であることからすれば、仕事を受ける側からみても、「完成」させるまでのプロセスで、商品の原価（システム開発の場合は、大半は人件費）にいくらかけたのかは不問にすることができます。このように、利益率を高めたいベンダーと、予算管理を行いやすくしたいユーザーの思惑もあり、システム開発では請負契約は非常に好まれる傾向があるのです。

請負契約を締結する際の注意点

もっとも、ユーザー・ベンダー双方からみて請負契約にメリットがあるとはいえ、特にベンダーにとって、安易な請負契約の締結にはリスクも伴います。なにより「仕事の完成」が債務の履行に必要となるということは、成果物が完成することなしには原則債務不履行責任から免責されないことを意味します。ベンダー側の見積りミスなどで、赤字となってもなお納品のために工数を割かなければならないといった炎上事案がたびたび発生する理由もここにあります。

では、請負契約の締結のためには、契約書上の記載でどのようなことに注意する必要があるのでしょうか。以下にひとつひとつ見ていきましょう。

システムの要件と検収合格の条件を事前に明確にしておくこと

請負契約で重要なことは、いうまでもなく「仕事の完成」の条件を明確化しておくことです。通常、ここにいう「仕事の完成」の要件とは、要件定義フェーズによる取り決めの内容を指します。しかし実務上、開発工程が進むにつれて事後的に変更を迫られる場合もあるため、「仕事の完成」の要件も流動的になることもあります。それらも含めて、仕様の変更履歴の文書化に務めることが重要だと考えられます。以下の記事では、法律的な観点からみた、システム開発プロジェクトの変更管理の行い方を解説しています。

また、この話題に関連して、ユーザー側が行う「検収の合格」についても予め取り決めをしておくことは後のトラブル予防に効果的です。成果物を納品しようにも、ユーザー側の担当者がつかまらなかったり、いつまでも返事をもらえなかったりといった事態は当然に想定されるものです。検収の合否がいつまでも判然としない状態のまま放置されないために、検収についても一定の期日を設けることは有益です。これがいわゆる「みなし検収条項」と呼ばれるものですが、こちらについては以下の記事で解説を行なっています。

著作権の移転の有無について事前に取り決めを置くこと

また他に問題になりやすいのは、著作権の移転に関するものです。著作権は「作った人」すなわちシステム開発であればベンダー側が取得するのが原則ではありますが、移転したり譲渡したりすることも権利の性質上可能です。そのため、著作権をユーザーに譲渡するか否かも事前に取り決めをしておくと、事後にトラブルになることを防ぐことができます。著作権の帰属や移転に関しては、以下の記事で詳細に解説しています。

その他の注意事項

ほかにも、あえて準委任的な要素を含めず、請負契約として契約を締結したいのであれば、

• 報酬を工数とは無関係にしておくこと
• 契約書の表題に「請負契約」と明記しておくこと
• 瑕疵担保責任の条項を明記しておくこと
• 報酬の支払いが、結果や成果に対する等価交換になっていること

といった点を意識しておくとよいでしょう。

なお、契約書の表題に「請負契約」と書いておけば、なんでも請負契約になるというような安易な考えを持つことは禁物です。実務上、他社の契約書のテンプレートが、その記載内容が請負なのか準委任なのかという点に無頓着なまま継ぎ接ぎで使い回され続けてしまうことがあります。いざ裁判などにもつれた場合には、表題の文言などの表面的な要素以上に、契約書の記載事項の全体的な内容や、これまでの商習慣など、より実質的な事項が重要視されます。この点にも注意をしておくべきでしょう。

まとめ

以上の点に配慮すれば、請負による契約事務は適切に処理しやすくなります。なお、「委託」という言葉は、請負的な契約であれ、準委任的な契約であれ両方で用いられるものです。また、「業務委託」という用語は当事者間に準委任契約であるとの意思がある場合に用いられるのが通例です。こうした細かい用語の違いも含めて、注意を払っておくと尚よいでしょう。