コラム「システム開発作業中におけるトラブル」でお伝えしたとおり、システム開発作業中にまつわるトラブルは、まず、システムが「完成」しているかどうかを検討する必要があります（争点1）。そして、システムが「完成」していると判断される場合には、上記の図にあるとおり、瑕疵があるかどうか（争点3-1）、その瑕疵が重大なものかどうか（争点3-2）が問題となります。このコラムでは、これらの争点について紹介したいと思います。

そもそも、ソフトウェアにおける「瑕疵」とは、個々の契約ごとに定められる「仕事の内容・性質」と納入されたソフトウェアとの不一致であるとされています。

しかし、一口に不一致といっても、様々なものがあるので、裁判所においては、「瑕疵」の有無の認定をケースに応じて個別具体的に判断せざるをえません。

この点について判断した裁判例としては、東京地裁平成9年2月18日判決があります。この裁判例によれば、およそバグであればすべて瑕疵にあたるのではなく、バグのなかでも「遅滞なく補修できない」か「代替措置が講じられない」ものが「瑕疵」にあたると述べられています。

また、契約書に「瑕疵」の定義が規定されていることもあり、その文言によっても「瑕疵」の範囲が左右されます。

このように、「完成」したシステムに契約の目的が達成できないほどの重大な瑕疵がある場合、ユーザーは契約を解除できるわけですが、ユーザー側がいきなり解除をできるかどうかが問題になります。

この点、民法635条には催告を要するとの規定はあませんが、債務不履行解除の規定である民法540条や同541条を類推適用して、相当の期間を定めて催告した後でなければ解除することができないとするのが公平かつ妥当です。

ただし、バグが発見さる前から、度重なる開発期間の延長等がなされていれば、事前に催告なく直ちに解除をしても不合理と認められないでしょう

そして、催告をする際には、不具合の内容・程度について具体的に特定したうえで催告をすべきです。具体的な特定を欠く催告をして解除をしても、催告によりベンダーには修補の機会が与えられていないのであるから、それに続く解除は要件を欠き、無効であると判断される可能性があります。

次に、解除の理由を特定するべきかどうかが問題となります。

この点が問題となった事案としては、東京地判16年12月22日があります。これは、解除後に主張された不具合については全く修補の機会が与えられていないから、解除後に認識した自由を解除原因として追加して主張することはできないとの主張がベンダーからなされた事案です。裁判所は、「ソフトウェア開発の請負契約においては、不具合の具体的な認識を要するとすると、専門家ではない注文者にとって酷であって相当ではない」として、「解除の意思表示には、必ずしも解除原因を示す必要はなく、複数の解除原因による解除を単一の意思表示によってすることができるのであり、解除の意思表示にあたってある理由を掲げても、とくにそれ以外の理由によっては解除しない旨を明らかにする等特段の事情がない限り、当該意思表示は解除当時存在していたすべての理由に基づき、およそ契約を一切終了させるという意思表示であると考えられる」と判示しました。つまり、特にそれ以外の理由によって解除しない旨を明らかにしない限り、後から発見されたバクを解除理由として追加することは許されるのです。

とはいえ、修補を求める不具合の内容については、催告の時点で判明しているものは可能な限り列挙しておくことで、その後に契約を解除した際、修補の機会が与えられなかったとのベンダーの主張を封じておくべきであるでしょう。

当然、バグを検知し修正する責任は原則としてベンダーにあります（東京地判平成16年12月22日判決）。そのため、バグを修正した場合でも、ベンダーは追加の報酬請求はできないものが原則であると考えられます。

もっとも、①もともとの受託範囲にバグの修正が含まれていないのが明確であること、②ユーザー側も納品後にバグが発生する可能性を認識していたこと、③バグの修補に関する費用の算定方法が明確であること等の事情があれば、バクの修補に追加報酬の請求をすることも認められる可能性があります。

いずれにしても、バグの修補に関する追加費用請求をする場合には、契約書や見積書などにあらかじめ追加費用の算定方法などを定めておくことが求められ、そのような定めがないときには、追加請求はできないといえます。