システム・ソフトウェア開発でよくあるトラブルと予防策（4）完成基準や検査をあいまいにしておくと、どうなる？

前回の記事では、システム・ソフトウェア開発の委託契約において、業務範囲をきちんと決めておかない場合のトラブルや予防策について説明しました。

第4回目では、業務範囲と同じかそれ以上にトラブルになりやすい、完成基準や検査（検収）をあいまいにしているとどのようなトラブルになるのか、また、その予防策について解説していきたいと思います。

■連載記事一覧

第1回：システム・ソフトウェア開発でよくあるトラブルと予防策（1）正式契約前に作業を開始してしまった！

第2回：システム・ソフトウェア開発でよくあるトラブルと予防策（2）契約形態が作業内容に合っていない

第3回：システム・ソフトウェア開発でよくあるトラブルと予防策（3）業務範囲を決めておかないとどうなる？

なぜ、完成基準や検査があいまいになるのか？

業務委託契約が、求める仕様を満たす製品を製造、納品してもらうようなものであれば、これまでみてきたように複雑で面倒な契約をする必要はありません。たとえば洋服の製造に必要な生地をつくってもらうのであれば、サンプルを何度か確認したうえで、納品時には、基本的に納品数が一致しているかどうかの検収で済ませることがほとんどでしょう。

しかし、システム・ソフトウェア開発の委託契約では、目的としているものが目に見えないものであるため、契約がかなり複雑になります。

契約時の要件定義書や外部設計書（システム仕様書）などはあるものの、

• 何をもって完成とするのか
• 検収時にはどのような基準で検査を行うのか

…などについて、整理することは簡単なことではありません。

これらの基準は、ユーザー（委託側）とベンダー（受託側）の間で協議のうえ決定します。完成基準や検査の手順を決めておかないと、何をもって「完成した」と判断するのかもわからず、ひいては、報酬の支払いもあいまいになってしまい、次のようなトラブルにつながる可能性があります。

完成基準・検査をあいまいにしておくことで起こるトラブル

システム・ソフトウェア開発の委託契約で、完成基準や検査（検収）についてあいまいにしていたことが原因でユーザー（委託側）とベンダー（受託側）の間でトラブルが生じてしまい、裁判にまで発展している例も少なくありません。

よくあるトラブルとしては、ユーザー（委託側）が検査（検収）を完了したものの、システムを稼働させたときに、ユーザー（委託側）が求めていた機能が含まれてなかったり、重大な不具合が見つかったりした場合に、そのシステムが完成したと言えるのかどうかが争われるケースがあります。

裁判では、以下のようにケースバーケースの判断をしています。

• ベンダー（受託側）が契約で予定していた最後の工程まで作業を終えていれば、システム自体は完成している
• 重要な機能が含まれていない場合には完成していない

ただし、裁判で「システムは完成している」と判断されたとしても、検収後に納品されたシステムに不具合があるのであれば、ベンダー（受託側）の契約不適合責任（2020年4月の民法改正までは「瑕疵担保責任」）として、

• 追完請求（契約内容に合うように修理を求めること）
• 代金減額請求
• 損害賠償請求
• 契約解除

といった対応を、ユーザー（委託側）からベンダー（受託側）に求める余地があります。

トラブルを防ぐには？

システム・ソフトウェア開発の委託契約において、上記のようなトラブルを防ぐためには完成基準や検査（検収）について明確にしておかなければなりません。ユーザー（委託側）としては次のような対策を講じておく必要があります。

工程ごとに個別契約を締結する（多段階契約）

システム・ソフトウェア開発は、一般的に「要件定義作成支援業務」や「外部設計書作成（支援）業務」、「ソフトウェア開発業務」、「ソフトウェア運用準備・移行支援業務」などの業務工程に分けられ、これらの工程を順番に進めていくことになります。

契約方法としては、以下の2つがあります。

• 上記の全工程を一括して請負契約を締結する方法
• 全工程の基本ルールなどを定めた基本契約を締結したうえで、工程ごとにその業務内容に応じて準委任契約または請負契約（個別契約）を締結する方法（多段階契約）

小規模でそれほど複雑でないシステム・ソフトウェア開発などであれば、一括請負契約で問題ない場合もあります。ですが一般的には、工程ごとにその作業内容や仕様をユーザー（委託側）とベンダー（受託側）が確認したうえで、個別契約を締結した方が完成基準などはより明確になると言えます。

要件定義書で必要な機能や性能を確認しておく

開発するシステムやソフトウェアに、どのような機能や性能が必要であるのかについて、ユーザー（委託側）とベンダー（受託側）で認識が違うことがあります。そのことによるトラブルを防ぐためには、上記で説明した「要件定義作成支援業務」の段階で、必要な機能や性能などをユーザー（委託側）とベンダー（受託側）が確認しておく必要があります。

そもそも「要件定義」とは、ユーザー（委託側）の求めているシステム・ソフトウェアに必要な機能や性能をまとめる作業を指します。作業自体はユーザー（委託側）が主体となって行い、ベンダー（受託側）はそのサポートをする形になります。多段階契約であることを前提とすると、「要件定義作成支援業務」として個別契約（一般的に準委任契約）を締結することになりますが、準委任契約とはいえサポートするベンダーに責任がないわけではありません。

このことを明確にするため、ベンダー（受託側）には善管注意義務（善良な管理者の注意をもって委任事務を処理する義務）があり、要件定義書の作成については専門家として調査、分析、整理、また、ユーザー（委託側）に提案、助言しなければならないことを基本契約書（※下枠「（要件定義作成支援業務の実施）」参照）に規定しておきます。

ユーザー（委託側）が、必要な機能や性能を要件定義書で明確にしておくことは当然です。しかし、ベンダー（受託側）が何もしなくていいわけではありません。目的とするシステム・ソフトウェアを稼働させるために、さらに別の機能も必要と判断すれば、ユーザー（委託側）に提案、助言しなければならないということです。

※仮に、ベンダー（受託側）が上記の提案、助言をしなかったことで、要件定義書が不完全なものになってしまった場合には、ユーザー（委託側）はベンダー（受託側）の善管注意義務違反として債務不履行責任を問うことができます。

※甲はユーザー（委託側）、乙はベンダー（受託側）を指します。

※上記は、基本契約書の「要件定義作成支援業務」に関する一部の規定ですが、詳細については、電子情報技術産業協会（JEITA）が公表している「2020年版ソフトウェア開発モデル契約及び解説」や情報処理推進機構（IPA）が公表している「情報システム・モデル取引・契約書 第二版」などでご確認ください。

検収時の検査基準を明確にしておく

何をもって検収完了とするのかについてのトラブルも多く、検収時の検査基準は明確にしておかなければなりません。

ここでも多段階契約であることを前提とすると、「ソフトウェア開発業務」として個別契約（一般的に請負契約）を締結し、その最終段階で検収を行うことになります。なお、請負契約であるため、ベンダー（受託側）は完成させる義務を負っています。そのため、何をもって検収完了＝完成とするのかユーザー（委託側）とベンダー（受託側）の認識が一致していないと、トラブルになります。

トラブルを避けるには、基本契約書にテスト項目やテストデータ、テスト方法、テスト期間などを定めた検査仕様書をユーザー（委託側）とベンダー（受託側）が協議のうえ作成することを規定しておきます。（※下枠「（検査仕様書の作成及び承認）」参照）

※甲はユーザー（委託側）、乙はベンダー（受託側）を指します。

※上記は、基本契約書の「ソフトウェア開発業務」に関する一部の規定ですが、こちらも詳細については、電子情報技術産業協会（JEITA）が公表している「2020年版ソフトウェア開発モデル契約及び解説」や情報処理推進機構（IPA）が公表している「情報システム・モデル取引・契約書 第二版」などでご確認ください。

まとめ

システム・ソフトウェア開発の委託契約で、完成基準や検査（検収）についてあいまいにしないためには、全工程を一括して契約を締結するのではなく、全工程の基本ルールなどを定めた基本契約を締結したうえで、工程ごとに個別契約を締結すべきです。

また、必要な機能や性能については要件定義書で、検収時の検査基準については検査仕様書で、ユーザー（委託側）とベンダー（受託側）の双方が共有しておくことが必要です。