はじめに：システム開発のトラブル事例
現代社会では、企業や個人に限らず、コンピュータを使ったソフトウェアなくして経営活動を行うことは難しくなっています。
その一方で、システム開発に関する紛争は多発しています。
具体的に、当事務所で、ユーザー側のお客様からのご相談として多いものは、
①多額の費用を支払って開発の依頼をしたにもかかわらず、納品物の内容が納得いく物ではない
②検収をして本番稼働したものの、バグが多くてシステムが使いものにならない、等といったものが挙げられます。反対に、ベンダー側のお客様からのご相談として多いものは
③納品をしたのに依頼者が請負代金を支払ってくれない
④軽微なバグしかないのに、検収してくれない、
等といったものが挙げられます。
これらに限らず、システム開発（この頁ではシステムとソフトウェアを同義に扱っております。）においては、様々な論点が存在します。その理由は、システム開発は、その本質は請負契約であり（開発者を派遣するという準委任契約である場合もありますが、完成の有無というシステム開発の本質を争うものは、原則として請負契約となります。）、請負人、今回で言えばベンダーが目的物の完成義務を負うのですが、システムそのものは可視性がない無体物であるため、建物のような有体物の請負契約と異なり、目的物の完成というものの定義が難しいということが一番の理由に挙げられます。開発の現場では、あらかじめベンダー側で単体試験・結合試験・システム試験というものをした上で検収を行っており、この検収をもって一応完成とみるのですが、後述の通り、裁判例では、検収のみをもってシステムが完成したと判断される訳ではありません。
システム開発におけるトラブルの区分
① 開発すべき製品の仕様確定：事実認定のための証拠の確保を
①は、最終的にどのようなシステムを作るのかという、請負契約における契約内容の確定の問題です。これは、他の契約、例えば、売買契約では売る物の内容が完全に特定していることは当然ですが、システム開発では、開発すべき内容が完全には特定していないことが多いということです。例えば、レセプトコンピュータ―という風に大枠は決定したとしても、その細部については、事前に内容をある程度詰めても実際の開発過程で開発内容が変更したりすることもありますし、さらには事前に詳細に取り決めを行わずに、最終的な納品に合わせて一緒に要件定義書を作成するといった場合も実際には多くあります。これには、ユーザー側のお金や時間をできるだけ掛けたくないというニーズと、ベンダー側がお客であるユーザーのことを考慮する等、様々な要因があるのですが、本来的には要件定義から詳細に定めておくことが望ましいことは間違いありません。また、②の協力義務のところでも述べますが、ユーザーとベンダーのコミュニケーション不足から、必要な打ち合わせが行われない等した結果、納品物が最終的に予定されたものと異なるものである場合もあります。
裁判上では、この請負契約における目的物の内容自体が争いになる場合もありますので、できれば要件定義書やＲＦＰ等の詳細な証拠を作っておくべきですし、最低限のメールや議事録は残しておくべきです。具体的な定め方については、弁護士にご相談下さい。
② ベンダーとユーザーの協力義務：双方が完成に向かって協力していくことが大事
目的物の完成義務を負うのは、当然、請負人であるベンダーであり、目的物が期日迄に完成しなかった場合、原則としてベンダー側が債務不履行責任を負うことになります。
もっとも、ベンダーはシステム開発の専門家であったとしても、ユーザーが行っている業務については素人です。したがって、ユーザーは開発を依頼したシステムの内容についてベンダーに知ってもらうべく、ベンダーからの聞き取り等に協力する義務があります。また、仮に、ベンダーはユーザーから、開発の最終段階において、複数の項目の追加があって、追加の開発があると期限迄に開発が終わらないというのであれば、きちんとその旨を説明し、追加分は二次開発に回したり、保守の中でやる等の提案をすべきです。そのような説明や提案をせず、ユーザーに言われるがままに追加項目の仕事をした結果、期日迄に仕事が終わらないというのであれば、それはシステム開発の専門家であるベンダーとしての役割を果たしたとは言えないでしょう。逆に、ユーザーが自らの業務の説明を怠ったり、ベンダーの適切な説明を受け入れず、開発が結果として遅滞した場合には、その責任はユーザーにあることになります。
このように、システム開発では、当事者は相互に協力義務を負っていますので、仮に目的物が完成しなかった場合でも、当事者双方が協力義務をきちんと果たしたか否かによってその責任の有無が異なる場合があります。
③ 目的物の完成の判断：判例は本番稼働の有無によって判断するも、契約で予め対策を
実務上、最も争いがあるのは、目的物の完成の有無の判断です。開発現場では、検収をもって完成として扱う場合が多いのですが、システム開発においては、その対象物が可視性のない無対物であり、一見してきちんと開発できているかを素人であるユーザーには判断できず、また、実際にはきちんと検収試験が行われていない例も少なくないことから、本番稼働をしてからその不具合の多さ等、業務上の仕様に耐えないことが発覚する場合が数多くあります。したがって、検収をもって直ちに完成と判断することはユーザーに酷になる場合があります。逆に、ベンダー側としても、きちんと契約通りに目的物を納品したはずが、ユーザーがヒアリングに協力してくれない等、その協力義務が適切に果たされない結果、 ユーザーが納品物のイメージが違う等と言って、検収をせず、請負代金を支払ってくれない場合等、ベンダーに酷な事例も散見されます。
この点について、近時の裁判例は、形式的に検収の有無によって完成の有無を判断するのではなく、納品物が本番稼働したか否かで分けるものが多く、①納品物が本番稼働している場合には、たとえ不具合があったとしても、目的物が一応完成しているとして、後は瑕疵担保責任の問題として扱い、逆に②本番稼働していない場合には契約の目的等からその仕様が業務上の仕様に耐えうるかを実質的に判断するものが多くなっています。
もっとも、形式的に本番稼働した場合に完成と扱い、後は瑕疵担保責任しか追及できないというのは、本番稼働後に多数の不具合が発生することもある開発現場においては、酷な場面が生じることも否定できず、これらの修正には、契約書段階からその判例を修正して対応しておく必要があります。具体的内容は弁護士にご相談ください。
④ 瑕疵担保責任：通常の請負契約とは異なるため弁護士に相談を
③で見た通り、目的物の完成の判断には争いがありますが、一旦目的物が完成した後は、④瑕疵担保責任の問題になります。
そして、完成物にバグが存在する場合、それがベンダーの責任である瑕疵と判断された場合には、請負人であるベンダーはこれを無償で修補する義務を負い、その瑕疵の程度が重く、ベンダーに開発を依頼した契約の目的を達成できない場合には、ユーザーは契約を解除できます（民法635条）。
もっとも、通常の請負契約とは異なり、システム開発では、およそバグは発生しないことはあり得ません。このような特殊性から、裁判例では、納品後本番稼働した後にバグが複数発生した事例において、ベンダーが「不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右のバグの存在をもってプログラムの欠陥（瑕疵）と評価することはできない。」（東京地裁平成9年2月18日判決）と判示した判例がある等、通常の請負契約とは異なる取り扱いとなっているため、注意が必要となります。
この分野は比較的新しい分野であり、まだ実務も確定していない部分が多数ありますので、トラブルが生じたときには是非、当該分野を扱う弁護士までご相談下さい。当事務所の代表弁護士は、本分野において複数の案件を手掛け、また、執筆や講演活動を行っております。
