設計書の記載による仕様変更の判断基準
システム開発に途中での仕様変更はつきものです。経産省のモデル契約書でも、これに対処するために、変更管理の条項を手厚くしています。しかし、その内容は主に手続面に限られており、十分とは言えません。具体的に何が仕様変更に当たるのかの具体的な基準がなければ、事は解決しないのです。
これについて、一般的には、「ユーザの承認を受けた設計書の記載」が基準とされているようです。つまり、記載されていることを記載されているとおりにやることが必要だが、記載されていないことはやらなくて良い、という考え方です。客観的なドキュメントを持ち出して、かつ、ユーザの承認も取り込んでいるのですから、十分な考え方に思えます。しかし、もう少し突っ込んで考えてみる必要がありそうです。
設計書に記載されていない場合
まず、「Ａをやる」と記載されていなことと、「Ａはやらない」と記載されていることは違います。後者の場合、Ａをやるのかやらないのか、あるいはＡ’をやるのかが検討され、やらないことに決定されたことが分かります。そして、そのことが明確にドキュメントされているのですから、その記載どおり、実装されていないことが正しいのです。
しかし、何も記載がない場合、おそらく何も検討がされず、ドキュメントでも手掛かりがないのですから、ユーザとしては、ＡやＡ’を本当にやらなくて良いのか、判断する機会を与えられていない可能性があります。端的に言えば、検討漏れ、記載漏れという事態です。これがＡをやらなくて良いことの根拠になるというのは、少し無理があります。少なくとも、上位のドキュメントにＡに関することについて、抽象的な記載がある場合や、標準的なシステム設計においてＡに関することについて検討課題に挙げるべきとされている場合、改めて検討の上、設計・実装をすべきです。
設計書に記載されている場合
次に、「Ａをやる」と記載されていてＡを実装したが、正しくはＡ’を実装すべきことが後から判明した場合です。この場合、ＡでもＡ’でも、合理的設計内容として成り立つのであれば、ベンダは免責されるべきです。ベンダは、ユーザに確認してもらう以外に、自らＡとＡ’のどちらが正しいのか、知る術がないからです。
しかし、記載されていることに、それ自体として論理的誤りがある場合、他の設計部分と整合しない場合、などは、設計バグというべき事態です。設計バグを瑕疵と見れば、ユーザが承認したからといって、ベンダが直ちに免責されることにならないのは当然です。裁判例でもユーザの検査漏れは瑕疵担保責任に基づく請求権を放棄したものとはみないとされていますし、殆どのモデル契約書では検収後の瑕疵担保責任追及を認めています。
なお、ユーザが間違った要求を出し、それが設計書に記載された場合は、瑕疵がユーザの指図に起因すると言えるので、民法の原則から言っても、ベンダは免責されます。ただし、ベンダが専門家として気づくべきことを気づかずに、ユーザの間違いを漫然と受け入れた場合は、善管注意義務違反となる可能性があるでしょう。