忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
16  15  14  13  12  11  10  9  8  6  3 

 システム開発に途中での仕様変更はつきものです。経産省のモデル契約書でも、これに対処するために、変更管理の条項を手厚くしています。しかし、その内容は主に手続面に限られており、十分とは言えません。具体的に何が仕様変更に当たるのかの具体的な基準がなければ、事は解決しないのです。これについて、一般的には、「ユーザの承認を受けた設計書の記載」が基準とされているようです。つまり、記載されていることを記載されているとおりにやることが必要だが、記載されていないことはやらなくて良い、という考え方です。客観的なドキュメントを持ち出して、かつ、ユーザの承認も問題にするのですから、十分な考え方に思えます。しかし、もう少し突っ込んで考えてみる必要がありそうです。

・記載されていない場合
 まず、「Aをやる」と記載されていなことと、「Aはやらない」と記載されていることは違います。後者の場合、Aをやるのかやらないのか、あるいはA’をやるのかが検討され、やらないことに決定されたことが分かります。そして、そのことが明確にドキュメントされているのですから、その記載どおり、実装されていないことが正しいのです。しかし、何も記載がない場合、おそらく何も検討がされず、ドキュメントでも手掛かりがないのですから、ユーザとしては、AやA’を本当にやらなくて良いのか、判断する機会を与えられていないことになります。端的に言えば、検討漏れ、記載漏れという事態です。これがAをやらなくて良いことの根拠になるというのは、少し無理があります。少なくとも、上位のドキュメントにAに関することについて、抽象的な記載がある場合や、標準的なシステム設計においてAに関することについて検討課題に挙げるべきとされている場合、改めて検討の上、設計・実装をすべきです。

・記載されている場合
 次に、「Aをやる」と記載されていてAを実装したが、正しくはA’を実装すべきであった場合です。この場合、AでもA’でも、合理的設計内容として成り立つのであれば、ベンダは免責されるべきです。ベンダは、ユーザに確認してもらう以外に、自らAとA’のどちらが正しいのか、知る術がないからです。しかし、記載されていることに、それ自体として論理的誤りがある場合、他の設計部分と整合しない場合、などは、設計バグというべき事態です。設計バグを瑕疵と見れば、ユーザが承認したからといって、ベンダが直ちに免責されることがないのは当然です。裁判例でもユーザの検査漏れは瑕疵担保責任に基づく請求権を放棄したものとはみないとされていますし、殆どのモデル契約書では検収後の瑕疵担保責任追及を認めています。なお、ユーザが間違った要求を出し、それが設計書に記載された場合は、瑕疵がユーザの指図に起因すると言えるので、民法の原則から言っても、ベンダは免責されます。ただし、ベンダが専門家として気づくべきことを気づかずに、ユーザの間違いを漫然と受け入れた場合は、善管注意義務違反となる可能性があるでしょう。

拍手[1回]

PR
author : ITS 

COMMENT

ADD YOUR COMMENT

NAME
TITLE
MAIL
URL
COMMENT
PASS

TRACKBACK

TRACKBACK URL
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin