システム開発の検収とみなし検収条項の適用場面とは

システム開発の場面で法的問題が生じやすいのが「検収」の局面です。

「検収」とは受注者が成果物を納品した際に、発注者側に生じる検査・点検義務を指します。仮に、納品後にいつまでたっても発注者が「検収」を行わなければ、受注者であるベンダーは法的に不安定な地位に置かれることになります。

そうした問題を解決するために契約書には「みなし検収」の条項が盛り込まれていることが多くあります。

この記事ではどのような場合に「みなし検収」が適用されるのか、実際の判例をもとに解説していきましょう。

システム開発における検収とはなにか

そもそもシステム開発プロジェクトにおける「検収」とは、受注者であるベンダーが納品してきた成果物（ここではITシステムのことを指す）に対し、発注者であるユーザーが、発注した目的に適う仕様となっているか等を検査・点検していくことを言います。

開発者側の目線でいうならば、「本当に仕上がったかどうかを確認する」という意味で、テスト工程と位置付けることもできるでしょう。

ITシステムを開発するという仕事は、業務の性質上、受注者たるベンダー側の裁量も大きなものとなりやすいため、実際に制作してきたプロダクトとユーザーが求めてきたものとの間でズレが生じるといったことが起こり得るものです。

ごく一般的な話としていうなら、検収の合格は、ユーザーが求めていたもの（ないしはシステムを開発してほしいと依頼をした目的）に合致する成果物が実際に納品されていることを、ユーザー自らが確認したということを意味するものだといえます。

実際の契約のやり方としても、現実にはその後にシステムに瑕疵があることが発覚するような事案は想定しうるにしろ、検収の合格を報酬の支払い条件として課しているものは多く見受けられます。

みなし検収条項に注意

検収のフェーズで一度トラブルが発生するとユーザー・ベンダーともに厄介な局面に立たされてしまいます。

たとえば、ベンダーが成果物を作り上げ、すでに成果物を提示しているにもかかわらず、ユーザー側の担当者の事情で、検収に応じない場合はどうなるのでしょうか。

こうした場合を想定して、システム開発の契約書にはよく「みなし検収条項」と呼ばれるものが盛り込まれていることがあります。

みなし検収条項とはなにか

(本件ソフトウェアの検収)第 28 条
納入物のうち本件ソフトウェアについては、甲は、個別契約に定める期間(以 下、「検査期間」という。)内に前条の検査仕様書に基づき検査し、システム仕様書と本 件ソフトウェアが合致するか否かを点検しなければならない。

2. 甲は、本件ソフトウェアが前項の検査に適合する場合、検査合格書に記名押印の上、 乙に交付するものとする。また、甲は、本件ソフトウェアが前項の検査に合格しない場合、乙に対し不合格となった具体的な理由を明示した書面を速やかに交付し、修正又は追完を求めるものとし、不合格理由が認められるときには、乙は、協議の上定めた期限内に無償で修正して甲に納入し、甲は必要となる範囲で、前項所定の検査を再度行うものとする。

3. 検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。

4. 本条所定の検査合格をもって、本件ソフトウェアの検収完了とる。

https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf

なお、法律的には、第3項の「みなされる」という言い回しがひとつ注目すべきポイントです。法律用語としてみた場合に、「みなす」と「推定する」では、実はまったく異なる意味を持つことになります。

みなす・・・
→実際〇〇でなかったとしても、法律上は〇〇である場合と同様と扱われる

(例)試験中にスマートフォンを操作していた場合、カンニングと「みなす」
→実際にスマートフォンを操作して行っていたことがカンニングであろうとなかろうと、カンニングである場合と同様の措置が下されること。

推定する・・・
→〇〇という事実を否定するような証拠などが特にない限りは、〇〇を事実として扱う。

(例)試験中にスマートフォンを見ていた場合、カンニングと「推定する」
→原則カンニングがあったものと判断されるが、カンニング以外の用途であった旨をあえて反証することができるのであれば、その判断は後からでも覆しうるものであるということ。(もっとも、試験会場でこんなアナウンスを聞くことは通常ないでしょう。)

つまり、「推定する」と「みなす」では、それを覆す際のハードルが段違いなのです。「検収に合格したか否かという事実とは無関係に、合格した場合と同様の扱いを受ける」という意味合いがここには含まれています。

みなし条項規定に関連する裁判例

みなし検収条項規定が、裁判で決定的な意味を持った例は過去にも存在します。たとえば以下に引用する判決文は、ユーザーが所定期間内に検収に応じることなく、事後で必要な機能が実装されていないという訴えを提起し、裁判となったものです。しかし裁判所は、みなし条項規定をもとに、すでに納品は完了されたものという判断を下しました。

本件契約においては，Ｙ会社は，本件システムの納品後，遅滞なく検査し，10日以内に検収を行って書面で通知すること，上記期日までに通知がされない場合は検収合格したものとされることが定められており，本件において検査に適合しない箇所の通知があったものとは認められないから，納品及び検収の事実を認定することができる。

東京地判平成24年2月29日判決

しかし一方で、このみなし検収規定が置かれていたとしても、これの適用を否定し、ベンダーの側の義務違反を認めた裁判例も存在します。

以下に引用する判決文の事案は、そもそも検収を行うにあたり、ベンダー側の協力が必要であったにもかかわらず、その協力をベンダーが怠っていたという点が前掲の裁判例とは異なる点です。

原告は（ベンダー），被告（ユーザー）が，成果物納入の日から10日以内に検査結果の通知を行わなかったため，本件ソフト開発契約書9条4項により，成果物を検収したものとみなされる旨主張する。しかし，このような結果が行われるためには，原告の協力が不可欠であるところ，原告は，被告に対し，このような検査のための協力を行っていないと認められるから，本件においては，被告が，成果物納入の日から10日以内に検査結果の通知を行わなかったからといって，本件ソフト開発契約書9条4項により，被告が本件ソフトを検収したものとみなされるものではない。

東京地判平成16年6月23日

みなし検収条項そのものの制度趣旨が、「早く検収に進みたいにもかかわらずユーザー側の一方的な都合によって、進むことができずに仕事が滞っている」というような不安定な立場からベンダーを早く解放し、両者の関係をフェアに保つことにあると考えられます。

したがって、そうした趣旨からはるかに逸脱して、「みなし検収条項を盾にとって、なんとか時間稼ぎをして検収そのものをズルズル先延ばしにして、そのまま不良品でもなんでも押し付けてしまおう」という話にはできないというわけです。

検収が合格したものと「みなされ」てしまえば、ユーザーはシステム開発の対価として、報酬を支払わねばなりません。こうした重大性も加味しつつ、裁判所はベンダー側の協力状況も取り込んで、公平な判断を行うことを目指したものであると考えられます。

こうした判断を支えるものとして、契約書のみならず、システム開発の進捗に伴う議事録が重要な証拠となる場合もあります。これに関しては下記記事にて詳細に解説しています。

なお、ベンダー側がシステム開発の専門家として、プロジェクトに対して包括的にどのような義務を負っているものなのかについては、以下の記事を参照ください。

検収業務が原則としてはユーザー側が行うべきものであるとしても、ベンダー側もシステム開発の専門家として、検収に対して様々な協力は行ってしかるべきであるという点は、以下の記事の内容を踏まえることで、ごく自然な話として納得がいくでしょう。

検収において瑕疵が見つかるパターン

もっとも、検収段階において、システムの不備(法律上は「瑕疵」という言葉を用いることが多い)が発覚することもありえます。この場合における法律問題としては、詳細は以下の記事を参照ください。

まとめ

システム開発における「検収」は、原則それがベンダー側の義務の履行の完遂を示すものであることから、ユーザー側にとってもベンダー側にとっても非常に重要だといえます。ここで深刻なトラブルを起こさないためにも、発注者・受注者ともに、「みなし検収条項」についてはよく理解しておくべきでしょう。

そして、検収が円滑に進まないといった事態を万一に想定して、事前の契約段階から、両者ともに検収にかかわる規定については特に、意識のすり合わせを綿密に行っておくことが大切だと考えられます。