2022.5.6

契約書は後回し?そんな時でも気をつけたいシステム開発契約時の注意点(弁護士:朝妻 太郎)

この記事を執筆した弁護士
弁護士 朝妻 太郎

朝妻 太郎
(あさづま たろう)

一新総合法律事務所
理事/新潟事務所長/弁護士

出身地:新潟県新潟市
出身大学:東北大学法学部

関東弁護士会連合会弁護士偏在問題対策委員会委員長(令和4年度)、新潟県弁護士会副会長(令和5年度)などを歴任。主な取扱分野は企業法務全般(労務・労働事件(企業側)、契約書関連、クレーム対応、債権回収、問題社員対応など)のほか、離婚、不動産、金銭問題など幅広い分野に精通しています。
数多くの企業でハラスメント研修、また、税理士や社会保険労務士、行政書士などの士業に関わる講演の講師を務めた実績があります。
著書に『保証の実務【新版】』共著(新潟県弁護士会)、『労働災害の法務実務』共著(ぎょうせい)があります。

はじめに

日常生活や、社会経済活動のIT利用度が飛躍的に向上し、システム開発事業者が急増する一方、地方の中小企業であってもシステム開発を事業者に委託する場面も出てきています。

もっとも、システム開発にあたっては、業務効率化など実現したい目標を早期に成し遂げたいユーザ側の思惑と、納期の厳守を意識するベンダ側の思惑により、契約内容の十分な検討がなされないまま、両者の作業が進行することが少なくありません。

また、いざ契約書面を作成するとしても、成果物の特定が難しい点、その他の事項も明記しづらいという特徴あります。

紙面の関係でその一部しか記載できませんが、システム開発に関する契約時に注意すべき点をいくつか挙げたいと思います。

なお、モデル契約書としてIPA(独立行政法人情報処理推進機構)が公表した「情報システム・モデル取引・契約書」があります。

詳細な解説に加え、民法改正に対応した改訂もなされており大変参考になります。

<参考:IPA「「情報システム・モデル取引・契約書」第二版を公開」 https://www.ipa.go.jp/ikc/reports/20201222.html>

契約形態・契約書の構造

システム開発契約は、民法上の「請負」若しくは「準委任」になろうかと思いますが、仕事の完成義務の有無(請負ではベンダは仕事(受託業務)の完成の義務を負うのに対し、準委任ではベンダは善良な管理者の注意をもって委任事務を処理する義務を負うが仕事の完成についての義務は負わない)、契約不適合責任の有無(請負では、仕事を完成し成果物を引き渡す義務を負うので、引き渡された成果物が契約の内容に適合しない場合、契約不適合責任(無過失責任)を負うが、準委任の場合には負わない(ただし、故意過失に基づく責任は負う))といった違いがあります。

開発のフェーズごとで請負と準委任いずれが相当か変わってくる面がありますが、提示された契約がどちらの契約形態か確認をする必要があります。

また、システム開発契約では「基本契約書」と「個別契約書」の2種類を作成することがあります。

一般的に基本契約書は作業範囲や責任分担、開発成果物の権利の帰属、検査方法など基本的な事項を記載する契約書です。

これに対して、個別契約書は各業務内容の取引条件を定めた契約書です(例えば、保守/運用フェーズにおけるユーザからベンダへの個々の委託業務の内容・取引条件は個別契約において取り決めることなどが考えられます)。

もっとも、常に基本契約書・個別契約書が作成されるわけではなく、一つの契約書で完結させるケースも多くあります。 その場合には、右図表の工程のうちのどの範囲を含んでいるのか、各工程ごとで仕様変更等が生じた場合にどうなるか、事前に確認することが望ましいといえます。

内容の特定

成果物の特定について、当該システム名のみが記載され、具体的な成果物の内容が定められないケースが多くあります。

また、成果物を作成する前提として、ユーザによる機能要件(ユーザの要求を満たすために、ソフトウェアが実現しなければならない機能に係る要件。システム機能及びデータにより定義される。)、非機能要件(機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要件、技術要件、移行要件、運用要件、操作性及び付帯作業等からなり、それぞれに対する目標値及び具体的事項により定義される。)を明確に確定させることが必要です。

システム開発に限らず、無形物の製作やサービス提供を内容として契約関係に入る際には、ユーザ側の要求事項が明確になっていないために紛争化することが少なくありません。

ユーザの立場から、打ち合わせ時に口頭で伝えたとの主張反論はよくされますが、紛争が裁判所の場に持ち込まれた際には、その主張のとおりに認定されることは多くはありません。

ユーザ側が自己防衛として機能要件等を明確にさせることが肝要です。

完全な特定は不可能なケースも存在しますが、契約書別紙として仕様書を添付し成果物及び作業内容を特定するなどの工夫が考えられます。

契約締結前の合意事項に関する取り決め

契約が締結される前に開発作業に着手する例が少なくないわけですが、契約締結前段階の作業工程での合意事項が本契約に反映されているか否かが問題となるケースも考えられます。

事前の取り決め事項が十分に反映されているか確認すると共に、完全合意条項(本契約前 の口約束等が効果を持たないことを明示する条項)が盛り込まれていないか等の確認が必要です。

納品後に生じた事由に対する対応

納品後の保守点検について、基本契約とは別に個別契約を締結しておくことが適切ですが、そうでない場合でも、どの期間、どの程度の対応がなされるのか(有償か無償かを含む)については最低限取り決めておくことが必要でしょう。

ユーザ側は、システムに不具合が生じた場合、ベンダ側が開発したものであるから無制限に対応されると期待するかもしれませんが、明確な規定が存在しない場合には、そこまでの対応がなされることは稀と考えた方がよいでしょう。


<初出:顧問先向け情報紙「コモンズ通心」2022年3月5日号(vol.266)>

※掲載時の法令に基づいており、現在の法律やその後の裁判例などで解釈が異なる可能性があります。

/