コラム

　現在、様々な分野でIT化が目まぐるしく進む中で、新しいシステムの導入が盛んに行われている一方、そのシステム開発過程や運用過程における紛争は後を絶たない。システムの開発や運用時に発生する紛争は、複雑で難解である上、訴額や損害賠償額も高額になり、訴訟の結果によっては、企業が極めて大きな金銭的負担を強いられる可能性もある。

　システム開発の紛争類型は、(1)契約・交渉段階で発生する紛争、(2)システムの開発途中で発生する紛争、(3)システムの運用段階で発生する紛争、(4)知的財産に関する紛争に大別でき、類似した事案が繰り返し発生している。現在、当職はシステム開発訴訟を数件担当しているが、そのいずれもベンダが情報システムを納品することができず、途中で頓挫してしまった類型（上記(2)の類型）である。以下では、(2)の類型に焦点をあて、システム開発訴訟が起こった場合に備え、開発を進める上で留意すべき点を述べることとする。

　システム開発は、基本的に、要件定義工程、デザイン工程、コーディング過程、システム構築工程を経て、最終的にユーザーに納品されることなり、各工程には、数社のベンダが関与することが多い（例えば、要件定義工程はＡ社が、デザイン工程はＢ社が担当する、といった具合である。）。

　システムの開発途中で発生する紛争（上記(2)の類型）は、①「ベンダが情報システムを納品できずに途中で頓挫してしまう類型」と②「ユーザーが自己都合でシステムを中止する類型」とに分類することが可能である。もっとも、この①と②の類型を明確に線引きすることは困難なことが多い。例えば、ユーザー側の意向で解除がなされたとしても、その前段階で、システム開発の進捗が大幅に遅れていることも多く、この遅延を理由にユーザーが開発を取りやめたといったようなケースがそれに該当する。このケースの場合、ユーザー側の意向で解除されたという事実に着目すると端的に②の類型に該当するようにも思われるが、ベンダがテスト用のシステム（いわゆるベータ版）の納品すらできていないような場合は、ベンダの技術力不足による債務不履行が生じていると評価でき①に該当することもある。システム開発を依頼する側の立場（ユーザー側の立場）からすれば、裁判所に②と判断されてしまうと、必然的に民法641条（任意解除）に基づき損害賠償の負担を負う（なお、損害賠償額の上限は、実務上請負代金総額とされている。）ことになるため、①に該当するのか②に該当するのかという問題は極めて重要な問題である。この問題をクリアにするためには、様々な過程で発生する納期（システム開発の中でシステム開発の実装状況に合わせて、何度か納期が定められることが多い。）、納品物の内容を当事者間で明確にしておくこと（最終的に、システムは様々な機能を備えることになることから、いつまでにどのような機能を実装したシステムを納品する、といったかなり具体的なところまで認識を共有しておくことが求められる。）、ベンダによる作業の進捗が遅れている場合は、どの作業工程に遅れが生じているのかを明確に指摘し、その内容を記録として残しておくことが重要である。

　以上のとおり、システム開発訴訟では、当時の担当者のやり取りや合意内容が非常に重要になり結論に影響を及ぼすにも関わらず、現実には、議事録が作成されていない、作成されていたとしても相手方の帰責事由や義務が記録されていない、ベンダとユーザーの共通認識の形成に役立っていないということも多く、議事録を作成することによるメリットが十分に発揮されていないケースが見受けられる。現在、システム開発では、Teamsやチャットワークを利用して１つのアカウントを作成し、当該アカウントに各ベンダが参加することも多く、やり取りがデータとして残っていることもある。しかし、当該アカウントにユーザーが参加していなかったり、開発終了後にアカウントが相手方によって勝手に削除されてしまったりといった落とし穴があり、訴訟になった段階で、必要な証拠を十分に手に入れることができないといった事態も発生している。さらに、Teamsやチャットワークの場合は、日常会話のような感覚でタイムリーにやり取りがなされていることが多く、相手方の帰責事由や義務等を意識してやり取りが行われないことの方が多い。Teamsやチャットワークを利用して開発を進める場合においても、会議ごとなど一定のタイミングで、上記で指摘した事項を記録した議事録を必ず作成し、ユーザーを含めた関係者間で共有した上で、共通認識を図ることは、訴訟を進める上で極めて有益である