久しぶりの更新は，システム開発契約における「瑕疵」について。
訴訟になるかならないかは別として，情報システムの検収後に，あるいは検収時に，ユーザ（発注者）からベンダ（受託者）に対し，「バグじゃないか。すぐに直してくれ」と要求したところ，「これは仕様です。直すとしたら仕様変更です。」などと言われて揉めるケースは少なくない。
契約書には，「瑕疵が発見された場合，ユーザはベンダに対して当該瑕疵の修正を請求できる。」などと書かれていることが多い。ただ，この瑕疵とは何かがしばしば争いになる。
一般的な定義によれば「瑕疵とは本来あるべき機能・品質・性能・状態が備わっていないこと」とされるが，これもなかなか難しい。ただ，注意すべきは，ベンダが提供する契約書には
瑕疵（仕様書との不一致をいう。以下同じ。）が発見された場合・・
などと，瑕疵を極めてせまく限定する場合のほか，
ベンダの責めに帰すべき事由によって生じた瑕疵が発見された場合・・
のように，本来は無過失責任であるはずの瑕疵担保責任にベンダの帰責性を要求するケースも多い。例えば，ＯＳその他のミドルウェアの動作，相性によって生じた不具合などについては，「ベンダの責めに帰すべき」場合でないから「瑕疵にあたらない」という主張も出てきうる。
前者のように瑕疵を仕様書との不一致に限定した場合には，ユーザから後に不具合の主張をするのは難しくなる。私が開発側，ユーザ側あるいは弁護士として過去に経験した例でわかりやすいものとして，
(1)マスタを削除する際にdeleteするのではなく，削除フラグを立てるという論理削除方式としていたところ，一覧検索の際に，「削除フラグ=off」という条件が仕様書になかったため，削除したはずのマスタが検索，表示された
(2)上記(1)に関し，いったん削除フラグを立てたマスタについて復活させたいと思ったが，ユーザの操作によって復活させられなかった
(3)上記(1)に関し，逆に削除したものは「削除済みマスタ」として閲覧したいと思ったが，一切これを表示させる方法がなかった
(4)マスタ更新の排他制御が不十分で，特定のマスタを更新しようとすると，そのマスタ全体の更新ができなかった
(5)ログインユーザのパスワード変更機能がなかった
(6)迅速なレスポンスが求められる画面において，平均で10秒以上のレスポンスタイムが生じた
(7)一定期間経過後にログやトランザクションをパージする機能がなかった
などがあった。いずれも，ユーザからの指摘に対し，「仕様書にないから」という反論が出たものだ。
こういうとき，せめて，
瑕疵（仕様書との不一致，論理的誤りまたは通常有すべき機能，品質，性能を欠いている状態をいう。以下同じ。）が発見された場合・・
というように，瑕疵に幅のある記載をしておきたいところだ。
とはいえ，仮にこのような定めをしていたとしても，なお(2)(3)(6)については，「通常有すべき」ものかどうかは争いが残る。ユーザからすると直して当然だ，と思えることを第三者である裁判所に納得させるのは容易ではない。
いずれにせよ，「瑕疵担保責任」が定めてあるから安心，というわけではなく，どこから先が「瑕疵」になるのかはできる限り明確にしたい。
これに加え，瑕疵担保保証の期間についても留意が必要だ。通常は，検収合格から6か月などとされているが，検収受領後に，ユーザテストなどを行う場合，そこで手こずると，本番稼働前に瑕疵担保保証期間が切れてしまう。また，会計システムなどで年次決算処理など1年に1度しか動かない機能については，初めて動作するタイミングで，すでに期間が終了していることもありうる。
ユーザテストなどにベンダがコミットするのであれば，瑕疵担保保証期間を，検収合格を始期として，本番稼働開始から○か月後を終期とする方法も考えられるだろう。
「瑕疵」については，いろいろと紛争もあり，裁判例などにも言及したかったところだが，とりあえずこれにて。
