システム開発委託契約
情報システムの活用は、企業活動のスピードや業務効率に直結する重要な要素です。現在では多くの企業がさまざまな場面で多種多様なシステムを導入しており、その規模や開発費用も年々拡大しています。場合によっては、システム開発の成否が企業の将来を大きく左右することもあります。
しかしながら、こうした重要性にもかかわらず、システム開発の現場では依然として多くのトラブルが発生しています。トラブルを未然に防止するためのガイドライン等も整備されていますが、それでもなお、トラブルを十分に回避できているとは言い難いのが実情です。
システム開発委託契約とは、企業（ユーザ）がベンダに対し、業務用システムやアプリケーションの開発を依頼する契約です。法的性質については、通常、請負契約か、それとも準委任契約に当たるのかという点を中心に論じられることが多いといえます。
契約類型により報酬請求権や責任範囲が異なるため、業務内容、仕様、納期、検収方法、知的財産権の帰属、損害賠償の範囲などを具体的かつ明確に定めることが重要です。
Webシステム（SaaSなど）を開発対象とする場合には、プログラミングの問題だけではなくクラウドサービスの提供のあり方を踏まえた総合的な開発契約を考える必要があります。
ウォーターフォール方式
ウォーターフォール方式では、ユーザがシステムに求める要求事項を開発プロジェクトの初期段階で全て洗い出して整理し、開発対象とするものを要件として固定します。その上で、設計、開発（プログラミング）、テストというそれぞれの工程を段階的に進め、プロダクトを完成させることになります。
ウォーターフォール方式は、計画的に開発を実行できるというメリットがあります。
初期段階で開発対象となる要求事項を固定し、その後は変更せず、また、一旦終了した工程には戻らないことを前提としていますが、実際には、「要件定義の漏れ」や「ユーザの要望」により、事後的な要求事項の追加・変更が発生することも多いのが実情です。
この方式は大規模なシステム開発向きの方式といわれていますが、小規模～中規模の開発に適用することも可能であり、実務上も従来から多用されている方式であって、現在でも、最もポピュラーな開発方式といえます。
ユーザの要求事項が当初から明確であり、事後的に変化しにくいものであればウォーターフォール方式が向いているといえるでしょう。
アジャイル方式
アジャイル方式は、ユーザのニーズが変化することを前提とし、その変化を的確に反映したプロダクトを開発することを目的とします。
アジャイル方式においては、開発対象のシステムを機能単位に分けることによって、短いサイクルで設計、開発、テストを繰り返し、スパイラル型に開発を進めていくことになります。
アジャイル方式はウォーターフォール方式と異なり、各工程が不可逆的ではなく、また、開発当初に最終成果物の仕様を決定することもありません。
一般的には、アジャイル方式は小規模～中規模開発向きといわれています。
- 機能ごとに独立した構成要素を組み合わせて構成されるもの
- UIにユーザの要望やフィードバックを取り入れる必要があるもの
- ビジネス環境やニーズの変化に応じた対応が求められるもの
システム開発契約の法的性質
システム開発委託契約の法的性質については、通常、請負契約か、それとも準委任契約に当たるのかという点から論じられることが多いといえます。
これは、ユーザを委託者とし、ベンダを受託者とするシステム開発委託契約において、その契約の趣旨が、システムを完成させることであれば請負契約、開発作業を遂行することであれば準委任契約、という議論ですが、請負と準委任のいずれが有利であるということは、一概にはいえません。
なお、システム開発に特有の多くの特徴から「いずれかの典型契約に当てはめようとすることには問題がある」としている立場もあるようです。
請負契約のケース
原則として、ベンダには報酬請求権が発生しません。
※出来高がある場合には、出来高割合に応じた報酬は請求できます。
準委任契約のケース
作業を遂行していればベンダに報酬請求権が認められます。
システムが未完成であった場合において、「契約の性質」が契約書上不明確だった場合、基本的な見方をすれば、未完成であれば対価の支払いを免れる請負契約の方がユーザに有利となり、未完成であっても作業分の対価を請求できる準委任契約の方がベンダに有利、という比較ができます。
しかし、実際には、請負契約において未完成であっても出来高分の報酬請求権が認められる場合もあり、必ずしも「契約の性質」の違いで効果が区別されるというわけでもありません。
システム開発契約の類型
一括契約と多段階契約のメリット・デメリット
システム開発委託契約においては、全体として一本の契約を締結するという契約方法【一括契約】以外に、工程ごとに複数の契約を段階的に締結していくという契約方法【多段階契約】をとる場合もあります。
大規模なシステム開発の場合には、多段階契約が締結されることが多く、規模の小さめの開発は一括契約とする傾向があります。
| 一括契約 | 多段階契約 | |||
|---|---|---|---|---|
| メリット | デメリット | メリット | デメリット | |
| ベンダ | ①プロジェクト全体を一括受注できる。 ②途中工程で遅延等の問題が生じても、最終納期までに完成させれば債務不履行を免れられる。 | ①契約時点で全体費用を定める必要があり、実作業と費用の乖離が大きくなるおそれがある。 ②最終成果物が未完成の場合、報酬がもらえない可能性がある。 | ①契約ごとの費用見積りの正確性が高い。 ②プロジェクトの途中で離脱できる。 | ①次の工程の契約締結は保証されていない。 ②契約の締結手続が煩雑となる。 |
| ユーザ | ①開発開始時点から、最終成果物の完成が約束されている。 ②最終成果物が完成しなければ、原則、報酬の支払義務は無い。 | ①契約時点で全体費用を定める必要があり、実作業と費用の乖離が大きくなるおそれがある。 ②プロジェクトの進捗を管理しにくい。 | ①ベンダメリットと同様に、契約ごとの費用見積りの正確性が高い。 ②途中の工程からベンダを変更することが可能。 | ①開発当初には最終成果物の完成が約束されない。 ②最終成果物が完成しない場合でも、完了した工程に係る契約については対価の支払義務を負う。 |
多段階契約
多段階契約においては、当初に基本契約が締結され、その後、工程ごとに個別契約が締結されることになります。基本契約では、各工程に関する個別契約に共通する事項を定め、各工程における期間や業務内容、報酬などは個別契約で定めることが一般的です。
各工程における個別契約ごとに「契約の法的性質」を異なるものとすることも可能です。
一括契約
多段階契約においては、当初の段階で費用が確定しないため、ユーザにとってはシステム開発を行う大きな障害となることが多く、また、個別契約ごとに契約交渉が行われることになりますので、開発期間がその分長期化するというリスクもあります。
そのため、小規模なシステム開発においては、これらの多段階契約の問題点を避けるために、一括契約が締結されることが多いです。この場合の問題点は、これから開発するシステムの内容が十分に確定していないことが多いという点です。
請負契約の原則どおり、最終成果物の完成時のみに報酬を受領できることにした場合、トラブル発生時の代金回収リスクが生じるため、ベンダとしては、民法の原則を修正することが考えられます。
行政書士システム開発委託契約書やＳＥＳ契約書の作成は、著作権相談員であり契約書専門の当事務所にぜひご相談・ご依頼ください。