日比谷の街角 弁護士 稲垣隆一 稲垣隆一法律事務所

稲垣隆一法律事務所 〒100-0006 東京都千代田区有楽町一丁目7番1号有楽町電気ビル南館9階956区 電話:03-6273-4351

システム開発紛争

瑕疵担保の契約条項

瑕疵担保の期間をどう定めるかは一つの問題だ。

民法637条は、請負契約の瑕疵担保の期間を1年と定めている(637条)。
この期間は除斥期間と考えられており、時効期間のように中断がないから、請求やベンダーが承認したからといって、伸びることはない。

そこで大切になるのは、この期間の始期をどう定めるかだ。


「引渡」を「納品」とする例は多い。納入した成果物が、検収に通って、納品となるから、検収を受けた時からということにする例だ。ヴァリエーションとしては、検収書の交付を受けてからというものもある。

しかし、実務では、まず、ユーザー検収拒否を想定した場合、これでいいのか?ということになる。ベンダは検収拒否に合うと、ずっと完成義務や瑕疵担保責任に付き合わされる。要員は確保しておけないから、極めて困難な状況を生じる。逆に、ユーザーは、完成義務や瑕疵担保を長期に主張できることになり、安心しがちだが、ベンダーから、契約で定めた期間は検収拒否の場合まで想定したものではないと主張されることにもなる。

逆に、検収書は出されたが、その検収書が、適切な検収を経ずに、形式的に出されたような場合、ユーザー側は、やっと完成して引渡を受けたが障害が生じて瑕疵担保を主張したが、基幹系を主張されて紛議になるケースがあり、その時は、検収書はあるが検収の実体がなかったことを主帳立証することになる。

そこで瑕疵担保責任の起算点を、「基本契約との不一致を知ったとき」とすることが考えられる。こうすると、実体のない検収を理由とするトラブルを回避することが可能になる。





システム開発契約の論点 第1回 請負契約か準委任契約か

■システム開発契約の法的性格を巡っては,請負と捉えるか,準委任と捉えるかが論じられている。
私も報告書作成のタスクフォースに加わった経済産業省の情報システムの信頼性向上のための取引慣行・契約に関する研究会「情報システム・モデル取引・契約書モデル契約プロセス」の報告書」でも,超上流から外部設計までは準委任(外部設計には請負あり),内部設計からシステムテストの前までは請負,システムテストから運用テストまでは準委任(システムテストには請負あり),運用と保守は準委任と請負を原則とするというように分けている。
この分類は,これから契約をする場合にどちらの類型を使うかを決める指標としては役立つことは間違えない。
しかし,要件定義は請負が正しいとか,すでに今目前にある契約が請負,準委任かどちらかを判断する指標になるとまではいえない。

■システム開発契約と請負か準委任かという問題のとらえ方のギャップ
システム開発契約を請負が,準委任かという問いは,担当者に基礎的な法的知識を与えるフェーズでは有効だが,実は,無理がある。
そもそも,日本の民法の請負契約と準委任契約のモデルはシステム開発契約など存在しなかった明治以前の社会のありかたいて規定されている。(本当は,さらにドイツ民法の成果を踏まえている・・・まあドイツにもシステム開発契約などなかったわけで,おなじことだが)。しかも,この二つの契約類型の差は,歴史的に形成されてきたのであって,理論的に区別されるわけではない。
請負なのか準委任なのかは,理論的に区別されるものではない。事実によって区別される。
どのような事実か。
それは,当事者が何に対して対価を支払うと考えたのかという事実だ。
仕事の結果・完成に対して払うなら請負,仕事を精一杯してもらったことに対して払うなら準委任だ。
具体的には,対価を支払う成果を,発注者が検証・評価する方法,判断の基準をどれほど具体的に決められるか,その内容を決めるにあたりベンダ側の裁量がどれほど多く認められるのかが分かれ目になると言えるだろう。





システム開発契約のコツ

契約書の解釈を巡る紛争はよくあることだ。
特にシステム開発請負契約などでは,仕事の内容を特定することが大問題。
最近こういう文案に接した。
「本契約の解釈に甲乙間の相違があるときは,甲の解釈を優先する」
感心した。
まず,この文言を考えた人の経験の豊富さ。過去によほど痛い目にあったにちがいない。
しかし経験を蓄積し,契約書に生かすという知恵は素晴らしい。皮肉ではない。心底そう思う。
ところでこの文言の効果はどうか。文字通り全てに甲の解釈を優先できるのか?
争いになったときは,おそらく,「合理的な範囲において」という限度で有効ということになるだろう。
契約の本質は合意だ。だから,こうした文言が有効な範囲は,契約の経緯,利害の公平などを考慮して,当事者の合理的な合意の内容がまず最優先されることになるだろう。その限度で,この規定は有効だろう。
とはいえ,当事者の合意の解釈をめぐる指針」という)意味では評価してよい規定だと思う。
たしかにこの文言からは,ユーザー側の強引さが伝わってくる。
しかし,契約内容は,終局的には力関係で決まるのだ。



システム開発契約紛争 瑕疵か追加か トラブル防止の秘法

システム開発契約のトラブル,瑕疵か追加かの争いをやっていて,つくずく感じる問題点。それは,ユーザーもベンダも発注内容をイメージでしか理解していないことだ。一番大事な合意の内容が,詰められていない。いくらベンダやコンサルタントがインタビューしても,当事者がレビューをしても,検収しても,回答をイメージや願いを語り合うだけでは詰められない。代金は円単位で考えていることを思い出せといいくなる。
じゃどうしたらいい?
ポイントは,文字化だ。ところがどっこい,やってみるとそれは意外に難しい。なぜか。日常生活でそれほどの粒度が要求されることはない。仮にあっても,十分にできないとしても精一杯やってもらえばそれでよいというのが日常生活だからだ。
そこで提案。文字化のプロセスを弁護士にやらせる。弁護士の能力の中核は,証拠をそろえ,その証拠にもとづいて合理的に推論すると主張が認められるということを文字で表すことだ。だから紛争に耐えられる粒度で,発注内容を文字化し,その証拠をそろえるには適任なのだ。餅は餅屋。弁護士を紛争予防に使う。これがあたりまえになれば法務コストはぐっと下げられる。

QRコード
QRコード
  • ライブドアブログ