「検収」と「本稼働」の微妙な関係
通常のシステム開発委託契約は、ベンダが総合テストを終えると一旦「納品」し、これをユーザが運用テストや受入テストなどの形で「検査」をし、それに合格すると「検収」となり、その後「本稼働」を迎えるというものです。今回考えてみたいのは、この「検収」と「本稼働」の関係です。
二つの品質確認 – 検収と稼働判定
上に見たように、検収後に本稼働を迎えるというのは、ユーザが品質の確認をしたうえで了解し、支払義務を負う反面でシステムに対する権利を得てから利用を開始するというのですから、極めて自然に思えます。経産省の「モデル取引・契約書」をはじめ、殆どのサンプル契約書ではそうなっているようです。
しかし、見方を変えると、検収と本稼働の関係は常にそうではないのではないか、というのが今回の話です。（実はここが重要なところでもあるのですが）検収は大雑把に言って請負契約における完成（債務の履行）を確認する行為ですから、これによってベンダは瑕疵担保責任の除く免責を得、ユーザは支払義務を負います。逆に言えば、そのような効果を付与しても良い場合にユーザは検収を出すということになります。他方、本稼働は、権利とか義務とかを特段考えることなく、ユーザが自らの業務にシステムを利用できるレベルの品質確認ができれば足りるものです。このレベルの品質確認は、厳密に言えば、「検収」（あるいはその前提の検査）ではなく「稼働判定」でしょう。
実務における検収と本稼動
なぜこのようなことを考えるのかと言うと、（契約書での想定にかかわらず）現実のシステム開発、それも一応成功したと言えるシステム開発でも、その多くが、本稼働後に検収を迎えているという事実があるからです。本稼働前のドタバタは別にしても、稼働直前の時期に悠長にドキュメントの最終チェックなどやっていられませんし、受入テスト段階で出た不具合の対応を本稼働までに終えるのも、多くの場合スケジュール的に無理があります。しかし、検収するとなれば、建前上はこれらをクリアしておかなければならないはずです。
確かに、代金を支払わない可能性を残しながら、先走ってシステムを使ってしまうのは変であるとは言えます。しかし、検収の有無にかかわらずシステムが客観的に完成レベルに達していれば支払義務は発生するわけですし、結局のところ代金の支払義務が発生しなくても、先走ったシステム利用の分を利得として代金と別に精算することも観念的には考えられるところです。
また、システムに対する権利について言えば、ユーザが著作権の譲渡を受ける場合でも、その移転時期は検収時ではなく代金の支払時とされることが多く、これは検収が本稼働前だとしても、ほぼ確実に本稼働後のタイミングとなります。契約書上、このタイムラグ分の利用権がケアされていることは稀ですが、ここに黙示の利用権設定を認めるなら、検収が本稼働後にずれ込んだ場合でも同様のはずです。
仮結論 – 開発完了への二つの流れ
結論として、「納品→検収→支払」という権利義務に関わる流れと、「納品→稼働判定→本稼働」という稼働に関わる流れがあるような気がします。気はしますが、実務でここまで踏み込んだことはありません。本稼働近くになれば非現実的に見える建前も、契約締結時に否定してしまって良いものか、若干の躊躇があるというのが本音だからです。
検収前、つまり完全な確認をする前に本稼働してしまった場合に、実は本稼働に耐えない不具合が発見されたとすると、その責任を完成義務を負うベンダが負担するのか、稼働判定でOKを出したユーザが負うのかという問題も生じそうです。