システム開発契約における請負契約と準委任契約の適切な選択

SI企業に身を置いて仕事をしていると、毎日のようにシステム開発契約をレビューし、システム開発がらみのトラブルに対して法的な見解を伝えて交渉のアドバイスする場面に直面します。

身も蓋もない話ですが、システム開発契約書がトラブルの解決に役立ったとか、契約書に適切な加筆修正を加えたことでリスクヘッジにつながった、という実感がほとんどありません。

とはいうものの、高確率でトラブルに発展するやってはならないことは、いくつかあります。ここではその一つを紹介して、無用なトラブルを回避してもらいたいと思います。

【ダメ】開発契約の内容と開発の実態が異なっている

いかに契約書の体裁を整えて取引を開始したとしても、契約内容と開発の実態が合っていなければトラブルを解決するには何の役にも立ちません。システム開発業界では、このような契約の内容と開発の実態が異なるというケースが頻発します。

契約の内容と開発の実態が異なるケースでは、契約書や契約書の背景にある民法に従って解決しようにも、契約に基づく主張や実態に基づく主張が錯綜し、混乱を招くことがあります。将来、紛争が起こったときに解決指針を示すための契約書が全く役に立たないのです。

ところで、弁護士としての経験値として、企業間で取り交わした契約書に書かれていないことを根拠に主張を通すには相応に高いハードルがあります。

たとえば、契約書には準委任契約と明記されているが、実態は請負契約であるから、開発に失敗してシステムが完成しなかった以上、ユーザは報酬を支払わなくてよい、というような主張です。そもそもこういった主張を許してしまう時点で契約書が紛争解決の役に立っていないことを物語っています。

残念なことに、開発着手前の契約レビュー段階で、法務部門が開発契約と実態のズレに気づくことは困難です。しかも、一旦、契約書を取り交わしたら、法務部門はトラブルが起きるまでほとんど関与する機会がありません。

言い換えると、個々のシステム開発案件に対して、精通した法務担当者を配置して定例会などに参加させておくことで、法務の観点からのトラブル防止には寄与するのかもしれません。

それでは、企業法務の担当者や営業担当が開発契約の内容と開発の実態を一致させるようにするには、どうすればよいのでしょうか？

まずは請負と準委任の違いを押さえる

法務担当者は、委託する業務の完成に重きを置く契約が請負で、業務の遂行を目的とし、業務が完了することまで約束しない契約が準委任である、とお答えになるのかもしれません。

専門的な用語を使えば、「仕事の完成」を目的とする契約が請負で、「役務の提供」を目的とする契約が準委任契約です。

さらに整理すると、請負は、前払いを約束しない限り、仕事の完成に対して報酬が支払われる契約で、準委任は、同じく前払いを約束しない限り、役務の提供に対して報酬が支払われる契約が準委任契約です。

このことは、仕事が完成しない限り報酬を支払わなくてよい請負契約と、役務を提供に応じて報酬を支払わなければならない準委任契約という整理に繋がります。

ユーザとベンダの立場の違いについて押さえる

ユーザがベンダにシステム開発を委託したものの、開発は失敗してシステムは完成しませんでした。このようなケースでは、先ほど整理した契約の考え方が、双方の立場によってより鮮明に現れることになります。

すなわち、システムが完成しなかった以上は報酬を支払いたくないユーザと、システムを完成させるまでにエンジニアを稼働させて人的コストを負担してきた以上は報酬を支払ってもらいたいベンダの立場です。

システム開発契約の締結にあたって、契約形態を請負にするか、準委任にするかは非常に対立するポイントです。

ここで注意が必要なのは、ユーザは安易に準委任契約を選択してはなりません。きちんと契約のなかで完成させるべきものを特定するよう心がけましょう。他方で、ベンダは、ユーザが請負契約を選択しているからといって、準委任契約のように完成させるべきものをあいまいにしないように心がけましょう。

ユーザとベンダはそれぞれ立場が異なるので、契約に関する個々の論点で対立するのはむしろ当然です。契約形態をどうするか、ベンダが完成させるべきものはなにか、それぞれが責任を負うべき開発における役割はなにか、これらを相手に遠慮してあいまいなままに取引を開始するのは非常に危険といえるでしょう。

双方の対立を避けてあいまいなままで開発案件を進めてしまうと、この微妙なすれ違いがあとあとトラブルにつながり、報酬を支払う支払わないといった話に発展します。このすれ違いが契約の内容と開発実態が異なってしまうことにつながります。

開発工程と契約に対する解釈の違い

システム開発契約に関する書籍では、ウォーターフォール型の開発を前提にした解説を多く見かけますが、どの書籍でも開発工程ごとに契約を取り交わす多段階契約が推奨されているところです。

確かに、開発工程ごとに契約書を取り交わすという対応はトラブル防止の観点からも適切です（開発規模が小さい案件では事務管理が大変というデメリットがある）。

開発工程には、請負契約がなじむ工程、準委任契約がなじむ工程があります。たとえば、要件定義の工程では、請負契約にするか、準委任契約にするか、どちらの判断もありうるところです。

というのは、要件定義書の完成に着目して請負契約とするのか、それとも要件定義がユーザ側の利害関係者の要望を取りまとめてシステムとして何を作るかを構想する段階なのでベンダの一存で契約期間内の完成を約束ができないことを理由に準委任契約とするか、契約形態は、当事者の交渉次第というところがあります。

このような要件定義の工程に関する開発契約で、契約書上は準委任となっているにもかかわらず、契約期間内に要件定義書が完成しなかったから報酬は支払わない、というベンダの主張は筋悪と言えるでしょう。

このほかに、製造工程（設計書にしたがってプログラムを作成する工程）に関する契約は請負と考えることが自然でしょう。この工程のみを契約対象とした取引で、準委任契約という契約書はおそらく実態に即していません。実務上、プログラムの作成は、基本的にベンダのみが行う工程ですから、プログラムの完成責任を負っていると考えられます。

製造工程の契約で、契約形態が準委任となっていた場合において、期間までに製造を終えなかった場合には、契約の実質は請負であると主張して引き続き製造の完成を求めるか、準委任契約と構成してこれまでの業務遂行の過程に善管注意義務違反があると主張し、引き続き履行を求めることができると考えられます。

どちらで構成しても結論は同じかもしれませんが、後者の構成は、善管注意義務違反があるかどうかという評価が入り込む余地があります。

紛争が長期化することをさけるためにも、ベンダに期日までの完成責任をきちんと負わせておき、またそのことをベンダにきちんと意識させてトラブルを防止しておきたいところです。