【第13回今日役に立つビジネス法務】小型のシステム開発契約について

【今日役に立つビジネス法務第13回】アイミツ版六法全書

更新日:2017年11月21日 | 公開日:2017年09月08日

システム開発においては、ベンダ間の受注競争が激しいこともあり、契約書を締結することなく口頭やメール上のやりとりだけで契約を結んで開発を進めてしまい、書面の授受は注文書と請求書だけ、というようなことが往々にしてあります。

しかし、システム開発上のトラブルは後を絶ちません。
納品したにもかかわらず報酬を支払ってもらえない、契約を解除されて損害賠償を請求された、注文した機能を欠くものが納品された、納期に大幅に遅れたあげく完成物の納品を受けられなかったなどのトラブルに悩まされた経験のある方も多いのではないでしょうか。
これらのトラブルが原因で、訴訟にまで発展するケースも珍しくありません。

一方で、これらの問題は、書面で契約を締結していれば防ぐことができたり、対処できることも多いものです。
したがって、システム開発の場合にも契約書を締結しておくことは非常に重要なことなのです。

そこで今回は、システム開発契約の中でも、比較的小規模のシステムやアプリなどの開発(いわゆる小型ウォーターフォール型)に関する契約書のポイントについて説明します。

このようなシステム開発契約においては、主に以下の3つの点が重要です。

システム開発契約に置いて重要な3つのこと
  • 請負契約 or 準委任契約——システムの完成義務まで負っているのか
  • 納期の設定と遅延時の定め
  • 成果物に関する権利の帰属に注意!

1.請負契約か準委任契約—システムの完成義務まで負っているのか

キーボードとメガネ

システム開発についての契約書には、一般的には「業務委託契約書」「システム開発契約書」などと記載されています。
しかし、これらはいずれも法律上の用語ではありません。

法律的にみると、システム開発契約には、以下の2パターンがあります。

システム開発契約のパターン
  • システムの全部または一部を完成させる義務を負う請負契約
  • 完成義務を負わない準委任契約

しかし、どちらの場合も「業務委託契約書」や「システム開発契約書」などと記載されているだけで、請負契約なのか準委任契約なのかがよくわかりません。
そのため、ユーザ(注文者)が、「完成義務があるのに完成していない」と言う一方で、ベンダは「いや、単なる”人出し”だから完成義務はない」と主張するといった争いが起きてしまうのです。

では、請負契約と準委任契約の違いはなんでしょうか?
それぞれについて詳しくみていきましょう。

請負契約とは?

「請負契約」は、仕事の完成に対して報酬を支払うという契約です。
したがって、ベンダは、システムを完成させる義務を負います。

このような請負契約の場合、ベンダはシステムを完成させない限り報酬を請求することはできません。
納品したシステムの内容や機能が仕様書等に記載された内容に合致しない場合には、未完成であるとして報酬の支払いを拒否され、完成させるように修正を求められたり、納期遅れであるとして損害賠償を請求される可能性があります。

準委任契約とは?

「準委任契約」は、業務(作業)の遂行に対して報酬を支払うという契約です。

典型的なものとしては、単にエンジニアを貸してあげるだけのいわゆる“人出し”契約と呼ばれるものがあります。
また、ある程度の規模のシステム開発の場合には、最初の要件定義部分のみを準委任契約とし、開発部分を請負契約とする場合もあります。

このような準委任契約の場合、受託者は、注文者から依頼された開発に係る作業を行いさえすれば、システムの完成の有無にかかわらず、報酬を請求することができます。

請負契約か準委任契約の決め方

システム開発契約が請負契約なのか準委任契約なのかは、契約内容や契約締結の経緯、契約締結後のやり取りなど諸般の事情を考慮して判断されます。

例えば、請負契約の場合には、契約書に「納品」や「検収」といったシステムの完成を前提とする条項が設けられることです。
逆に言えば、準委任契約であるにもかかわらず、これらの条項が置かれている場合には、請負契約であると判断される可能性もあります。

請負契約・準委任契約のまとめ

このように、「業務委託契約」や「システム開発契約書」と一口に言っても、システムの完成義務まで負う請負契約と、単に開発にかかる業務を遂行すれば良く、完成義務を負わない準委任契約とがあります。

今回、自分はどちらの形態で契約するつもりなのかを、契約締結前にしっかりと確認したうえで契約書の内容をチェックしなければ、後から予期せぬ責任を追及されたり、システムの完成を求めることができなくなったりするので、注意が必要です。

次に、頻繁にトラブルとなる「納期の設定と遅延時の定め」、そして、契約時には気付かない「成果物に関する権利の帰属」について説明します。

2.納期の設定と遅延時の定め

パソコンと砂時計

なかなか避けられない納期遅延

システム開発の現場では、頻繁に納期遅延が発生し、開発プロジェクトのうち実に7割弱が納期遅延に至っていると言われるほどです。
この原因には様々なものが考えられ、一口に語ることはできませんが、契約において重要なポイントは、「納期の変更」が高確率で発生することを正面から受け入れて、納期の変更手順を予め定めておくことになります。

紛争を防止する定めとは?

まず、プロジェクトの初期段階では、発注者側から十分に聞き取りを行っていても、要件定義の細部や、仕様を決めきれない場面が多いかと思います。
これらの未確定部分は、その後に確定されていきますが、この確定段階で、作業工数がしばしば増加してしまうでしょう。
この場面で、作業工数が増加しているにもかかわらず、ユーザ(注文者)とベンダ側が特段の協議をすることなく、当初の納期が維持されてしまうと、両者の認識が乖離してしまい、後のトラブルにつながってしまいます。

このような事態を避けるために、「未確定部分が確定した段階で、納期・報酬について再協議する機会を設ける」旨を予め契約書に明記しておくべきでしょう。
ただ協議するだけでいいの? と思うかも知れませんが、重要なのは、ユーザ側が開発工程を理解しておくことです。
そして、協議の結果、納期の変更が必要になる場合は、「変更確認書」などの書面によって、変更後の納期を目に見える形で明確にしておくことをおすすめします。

また、仕様の変更が行われたために納期が遅延する場合もあります。
このような場面でも、納期の変更手順を予め定めておけば、トラブルは大幅に防止できるでしょう。
具体的には、あらかじめシステムの重要部分を記載した「重要事項説明書」などを作成しておき、「この書面に記載されている部分に変更があった場合には、納期・報酬について再協議する機会を設ける」などと、一定の場面で必ず協議するように条項を盛り込んでおくと必要があります。
逆に、あまり軽微な仕様変更では、そのような協議はむしろ不要でしょうから、再協議する機会は、一定の規模の仕様変更があった場合に限定する方が望ましいでしょう。

遅延してしまった場合は?

システム開発の納期遅延には、一概にベンダ側の責任とは言えない場面もありますが、最終的に約束した納期に遅延した場合、ユーザ側としてはやはり損害を賠償してもらいたいと考えるでしょう。
しかし、ユーザ側としては、その損害額を算定することは容易ではありません。そのため、損害額で水掛け論になり、紛争が長期化してしまう場合があります。

そのため、契約書の中には「納期遅延1日あたり、報酬額の〇パーセントの損害が発生したものとして扱う」旨の定めを置くことも有用です。
このような定めは、ユーザ側の立証を容易にするだけでなく、ベンダ側から見ても、遅延によってどの程度の損害(リスク)が発生するのかの見込みが立てやすく、システム開発の不明確さ・不安定さを取り除くための一要素となり得ます。

3.成果物に関する権利の帰属

会議室

権利の所在は実は不明確

システム開発で生成される成果物には著作権が発生しますが、システム開発取引では、「ユーザが委託料を支払っているのだから、システムの著作権は当然ユーザに移転される」と考えている場合が比較的多いように思います。
特に契約書を締結することなく口頭やメール上のやりとりだけで契約を結んで開発を進めてしまうようなケースでは、このような傾向は一層顕著です。

しかし、これは決して当然のことではありません。
まず、ユーザ側から見ても、著作権を全部取得しなくとも、実はそれほど弊害のない場合も多いように思います。
そして、システム開発委託料の設定は一般的に人月単位のコストから算出する方式が採られることも多く、その委託料の中に、著作権の対価が含まれているかどうかというのは、実は非常に不明確な問題です。
したがって、契約書には、権利帰属をどちらにするのかを必ず明記しておきましょう。

権利帰属条項の意味

権利帰属に関する契約書上の条項としては、「本システムに関する著作権(著作権法第 27 条及び第28条の権利を含む。)は〇〇に帰属する。」という表記が一般的です。
ただし、この条項を正確に理解するためには、少し法律的な知識が必要となります。

そもそも著作権は、それを創り出した者が権利者になると法律で定められており、創作者であるベンダが最初の権利者です。(ベンダ=著作者)。
そのため、契約上で、「ユーザに帰属する」と定めていた場合、「帰属する」という言葉を使っていても、実質的な意味合いは「ユーザに譲渡する」となります。

また、この契約条項には、「著作権法第27条及び第28条の権利を含む。」と表記されています。わざわざ第27条と第28条だけが取り上げられている理由は、この第27条と第28条で定めている権利(翻訳権・翻案権・二次著作物に関する原著作者の権利)は、あえて契約書で明示しておかないと、権利が譲渡されないという法律上のルールがあるためです。

著作者人格権は移転しない?

また、著作権の中には、「著作者人格権」と呼ばれる権利があります。
この著作者人格権は、著作者だけが持っている権利で、譲渡したり、相続したりすることができません。
先ほどの条項例で言えば、いくら「本システムに関する著作権(著作権法第 27 条及び第28条の権利を含む。)はユーザに帰属する。」と契約書に記載していても、この著作者人格権だけはベンダ側に残ります。

そこで、契約条項の中には、著作者人格権に関する定めも置いておく必要があります。
もしユーザ側が権利を完全に自分のものにしたい場合は、「ベンダは、著作者人格権を行使しない。」著作者人格権不行使特約を契約書に盛り込んでおく必要があります。

まとめ

握手

今回は、トラブル防止するために契約書で予め定めておくことができる部分をご紹介しました。
前述の通り、システム開発の現場では完全に開発が成功する割合は約3割程度で、7割は何らかのトラブルが生じていると言われています。
それにもかかわらず、実際の開発現場では、膨大な作業に追われ、なかなかトラブル防止策が打てないという声もよく聞きます。
もちろんトラブルというのは「想定外の事態」ですから、あらかじめ定めておくことに限界はありますが、開発現場から生じる紛争の「泥沼化」を防止するため、契約でシステム開発のルールを可能な限り明確にしておくことをおすすめします。