情報システムの活用は、企業活動のスピードや業務効率に直結する重要な要素です。現在では多くの企業がさまざまな場面で多種多様なシステムを導入しており、その規模や開発費用も年々拡大しています。場合によっては、システム開発の成否が企業の将来を大きく左右することもあります。
しかしながら、こうした重要性にもかかわらず、システム開発の現場では依然として多くのトラブルが発生しています。トラブルを未然に防止するためのガイドライン等も整備されていますが、それでもなお、トラブルを十分に回避できているとは言い難いのが実情です。
システム開発委託契約とは
システム開発委託契約とは、企業（ユーザ）がベンダに対し、業務用システムやアプリケーションの開発を依頼する契約です。法的性質については、通常、請負契約か、それとも準委任契約に当たるのかという点を中心に論じられることが多いといえます。
契約類型により報酬請求権や責任範囲が異なるため、業務内容、仕様、納期、検収方法、知的財産権の帰属、損害賠償の範囲などを具体的かつ明確に定めることが重要です。
Webシステムを開発対象とする場合には、プログラミングの問題だけではなくクラウドサービスの提供のあり方を踏まえた総合的な開発契約を考える必要があります。
システム開発契約の法的性質
システム開発委託契約の法的性質については、通常、請負契約か、それとも準委任契約に当たるのかという点から論じられることが多いといえます。
これは、ユーザを委託者とし、ベンダを受託者とするシステム開発委託契約において、その契約の趣旨が、システムを完成させることであれば請負契約、開発作業を遂行することであれば準委任契約、という議論ですが、請負と準委任のいずれが有利であるということは、一概にはいえません。
システムが未完成であった場合において、「契約の性質」が契約書上不明確だった場合、基本的な見方をすれば、未完成であれば対価の支払いを免れる請負契約の方がユーザに有利となり、未完成であっても作業分の対価を請求できる準委任契約の方がベンダに有利、という比較ができます。
しかし、実際には、請負契約において未完成であっても出来高分の報酬請求権が認められる場合もあり、必ずしも「契約の性質」の違いで効果が区別されるというわけでもありません。
請負契約とするか準委任契約にするかというようにどちらかを選択するのではなく、具体的な開発工程の内容に応じた規律を開発過程ごとに設けることが重要です。
多段階契約
多段階契約においては、当初に基本契約が締結され、その後、工程ごとに個別契約が締結されることになります。基本契約では、各工程に関する個別契約に共通する事項を定め、各工程における期間や業務内容、報酬などは個別契約で定めることが一般的です。
ウォーターフォール方式の場合、段階的に工程が進んでいく方式であるため、多段階契約になじみやすいといえます。この方式は大規模なシステム開発向きの方式といわれていますが、小規模～中規模の開発に適用することも可能です。
一括契約
多段階契約においては、当初の段階で費用が確定しないため、ユーザにとってはシステム開発を行う大きな障害となることが多く、また、個別契約ごとに契約交渉が行われることになりますので、開発期間がその分長期化するというリスクもあります。
そのため、小規模なシステム開発においては、これらの多段階契約の問題点を避けるために、一括契約が締結されることが多いです。この場合の問題点は、これから開発するシステムの内容が十分に確定していないことが多いという点です。
プロジェクトマネジメント義務
①ベンダに契約書及びシステム提案書において提示した開発手順、開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処する義務
②開発の局面に応じて、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等について、ユーザに対して説明をする義務
ユーザの協力義務
①システムの開発過程において資料等の提供その他システム開発のために必要な協力をベンダから求められた場合、これに応じて必要な協力を行うべき義務
②契約外の追加要望を大量に出すなどしてベンダの開発行為を妨害してはならない義務
仕事の完成
システム開発委託契約においては、請負契約の性質を有する場合が多いですが、ベンダが報酬を請求するためには、原則としてシステムの「完成」が求められます。
システム開発委託契約で特に重要となるのがベンダの報酬請求の点であり、報酬請求の可否を巡って完成か未完成かがよく争われます。
請負契約の完成の基準としては、「予定された最後の工程まで終了」したかという外形基準の観点で判断されることが多いです。
システム開発においては、ベンダからの納品物を、ユーザが、システム仕様書などに合致していることを確認する「検収」が行われますが、通常は最後の工程に「検収」が予定されているため、検収に合格するということは、最後の工程まで完了したということと同義です。
よって、検収が完了したということは、法的には「仕事の完成」を意味すると考えられます。
契約不適合責任
システム開発委託契約において、請負契約の性質を有する場合は、民法上の請負に関する契約不適合が適用されます。
この責任は任意規定ですので、契約によって別の規定を設けることも可能です。なお、契約上規定されない場合は民法の規定が適用されることになります。
仕様変更・機能追加
システム開発においては、工程途上における仕様変更や機能追加がトラブルの原因となることが多いです。
ユーザの仕様変更の要求に対してベンダが対応する義務を負うか否かについては、ユーザの要求が当初合意した仕様の範囲内かどうかによって決まります。ですから、当初の仕様の範囲が不明確だとトラブルになる可能性が高まることになります。
トラブル回避のためにも、契約においてできる限り「確定した仕様」を記載しておくようにしましょう。
知的財産権の帰属
システムに関する知的財産権として重要となるのがプログラムの著作権です。著作権者は、著作物を独占的に利用することができるため、ユーザとベンダのいずれに著作権が帰属することとするかが重要となります。
まとめ
システム開発契約では、仕様や仕様変更・機能追加をめぐってのトラブルが多く見られますが、ベンダとユーザのコミュニケーションが円滑であり、また、ベンダのシステム構築能力に問題がなければトラブルを防ぐことができます。
契約書の条項は、コミュニケーションの支柱であるので、現場は常に契約書の条項に従ったプロセスを確認できるようにしておく必要があります。
契約の実態に即した契約書にしてトラブルを予防しましょう！
