システム開発プロジェクト進行中におけるトラブル1：頓挫型
システム開発委託契約のプロジェクト進行中におけるトラブルは、主に次の3つに分類できます。
はじめに、頓挫型のトラブルの概要について解説します。
頓挫型のトラブルとは
頓挫型のトラブルとは、システム開発を委託されたベンダーがシステムを納品することが困難となった場合において、責任がベンダーとユーザーのいずれにあるのかが争点となるトラブルです。
頓挫型のトラブルの例
システムを納品できなかった場合、単にベンダー側の怠慢であるなどと単純に判断できるケースは多くありません。
原因が複雑に絡み合っていることが一般的であり、責任の特定が困難となることが多いといえます。
たとえば、旧システムから新システムへの移行や求める機能の充足などについてベンダーがユーザーに見積もりを提示し、システム開発委託契約を締結した後、見積もりの前提となっていた事情（ユーザによる旧システムの使い方など）が異なっており、費用が大きく増大するといった場合があります。
また、ユーザー側の希望を踏まえパッケージソフトウェアを選定し、これによりユーザー要望がおおむね充足できると考えて見積もりを算定していたものの、その後改めて詳細な確認を進めていくとパッケージソフトウェアでは3割程度しかユーザーの要望を充足できないことがわかり、カスタマイズ費用が大きく増大することなどもあります。
このような場合、ベンダーとしては費用の増加分をユーザーに負担して欲しいと考えます。
一方、ユーザーとしては追加費用が発生した原因はベンダーの事前確認が甘かったためであると主張し、追加費用の支払いを拒絶することとなるでしょう。
解決にあたって重要なポイントとなる2つの義務
このような頓挫型の問題は、次の2点が原因となって起きることが少なくありません。
- システムの技術に関する知識や経験がベンダーに偏在していること
- ユーザーがそのシステムを使って行いたい業務に関する知識がユーザーに偏在していること
このように、ベンダーとユーザーとではそれぞれ異なる知識を有しており、ユーザーの希望に沿うシステムを開発したり正確な見積もりを出したりするためには、これらの知識を十分にすり合わせなければなりません。
このすり合わせが甘いと、先ほど紹介をしたようなトラブルへと発展する可能性があります。
そこで、このようなトラブルの責任の所在を探るにあたっては、ベンダーとユーザーが次の義務を果たしていたかどうかが1つのポイントとなります。
- ベンダーのプロジェクトマネジメント義務
- ユーザーの協力義務
ベンダーのプロジェクトマネジメント義務
ベンダーのプロジェクトマネジメント義務とは、一般的にベンダーが開発プロジェクトの全体を見て適切に遂行できるようマネジメントすべき義務を指します。
裁判において定着してきた義務であり、民法などの法律で定義されているものではありません。
なお、東京地裁平成16年3月10日判決では、「被告（ベンダー）は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務」、「原告（ユーザー）のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告（ユーザー）によって開発作業を阻害する行為がなされることのないよう原告（ユーザー）に働きかける義務」を負うものと解すべきとされています。
なお、このベンダーのプロジェクトマネジメント義務は、契約締結後のみならず契約締結前においても発生すると考えられています。
ユーザーの協力義務
開発されたシステムを実際に使用するのはユーザーであり、ベンダーはユーザーの業務内容やシステムの使い方を熟知しているわけではありません。
そのため、ベンダーがシステム開発を適切に遂行するためには、ユーザーの協力が不可欠です。
そこで、ユーザー側にはシステム開発への協力義務があると解されています。
ユーザーの協力義務について先ほど紹介した東京地裁平成16年3月10日判決では、「オーダーメイドのシステム開発契約では、受託者（ベンダー）のみではシステムを完成させることはできないのであって、委託者（ユーザー）が開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担することが必要」であるとされています。
システム開発プロジェクト進行中におけるトラブル2：ユーザー都合による終了型
システム開発プロジェクト進行中におけるトラブル類型の2つ目は、ユーザー都合による終了型です。
ユーザー都合による終了型のトラブルとは
ユーザー都合による終了型のトラブルとは、プロジェクトの途中でユーザー側に生じた事情によってシステムを開発する必要がなくなることによるトラブルです。
ユーザー都合による終了型のトラブルの例
ユーザー側の経営方針の変更などにより、システム開発が不要となることは珍しくありません。
たとえば、ユーザーが新規事業に取り組むためにシステム開発を委託しプロジェクトが進行しているものの、ユーザー側の社長が変わったことなどにより経営方針が変わり、新規事業への進出自体をやめることになった場合が挙げられます。
ユーザー都合による終了型のトラブルで争点となりやすい点
ユーザー都合による終了型のトラブルで争点となりやすいのは、プロジェクトの終了原因です。
システム開発委託契約はスケジュールどおりに進行しないことも多く、ユーザーによっては自己都合による解除ではなくベンダーの開発が遅延していることが解除原因であるなどと主張されることもあります。
また、契約解除の原因がユーザー側にあると特定できたとしても、報酬の請求額や損害賠償額について争いとなることが少なくありません。
その場合、契約書の記載事項や民法の規定に照らし個々の状況に応じて報酬請求額や損害倍書額を算定することとなります。
システム開発プロジェクト進行中におけるトラブル3：不完全履行型
システム開発プロジェクト進行中におけるトラブル類型の3つ目は、不完全履行型です。
不完全履行型のトラブルとは
不完全履行型のトラブルとは、ベンダーがユーザーに対してシステムを納品したものの、ユーザー側がそのシステムが不完全であるとして報酬の支払いを拒否することによるトラブルです。
不完全履行型のトラブルの例
不完全履行型のトラブルの例としては、ベンダーが開発したシステムを納品したもののこれについてユーザーから「イメージや仕様と異なる部分がある」などとして修正や機能追加を依頼されたり、契約が解除され支払いを拒否されたりするケースが挙げられます。
ベンダー側に責任があるケースもあれば、ユーザーが納期直前になって機能の追加を要望したことで納期までの追加が間に合わなくなった場合などユーザー側に責任があるケースも考えられます。
ケース別の法的性質
不完全履行型のトラブルは、ケースによって法的な性質が異なります。
そのため、実際にトラブルが生じた際はその状況に応じて対応を検討することとなります。
なお、ここではシステム開発委託契約が民法上の請負契約の性質を持つことを前提として解説します。
仕事が未完成である場合
請負契約は、「報酬は、仕事の目的物の引渡しと同時に、支払わなければならない」とされています（民法633条）。
そのため、仕事（システム）が未完成である場合は、原則として報酬を請求することができません。
ただし、システムが未完成である原因にユーザーの協力義務違反がある場合、ユーザーに対して損害賠償が請求できる余地があるほか、ユーザー側の責任によって履行が不能となった場合は報酬の請求ができる可能性もあります。
仕事は完成しているものの瑕疵や契約不適合がある場合
仕事（システム）は完成し納品をしたものの、納品したシステムに瑕疵や契約不適合がある場合は、その瑕疵や契約不適合の程度によって法的効果が異なります。
その瑕疵や不適合が社会通念に照らして軽微といえない場合、ユーザーは契約の解除が可能であり、ユーザーから損害賠償請求や原状回復請求がなされる可能性があります。
一方、その瑕疵や不適合が社会通念上軽微なものである場合は、ベンダーはユーザーに対して報酬を請求することが可能です。
ただし、瑕疵や不適合の度合いに応じてユーザーからベンダーに損害賠償請求をすることも可能であり、結果的にこれと相殺されることで報酬が少なくなる可能性があります。
また、ユーザーは報酬減額請求をすることが可能となります。
仕事は完成し、瑕疵も契約不適合もない場合
仕事（システム）が完成しており瑕疵や契約不適合も認められない場合は、ベンダーはユーザーに対して報酬を請求することが可能です。
また、ユーザーからベンダーに対して損害賠償請求などをすることはできません。
システム開発プロジェクト進行中におけるトラブルが生じた場合の対応
システム開発プロジェクトの進行中にトラブルが発生した場合において、ベンダー側が行うべき主な対応は次のとおりです。
- 契約書ややり取りをしたメール・文書などを取りまとめる
- システム開発に関するトラブルに強い弁護士へ相談する
契約書ややり取りをしたメール・文書などを取りまとめる
システム開発委託契約に関するトラブルが発生した場合は、契約書の内容を改めて確認するほか、ユーザーとやり取りしたメールや文書などを取りまとめます。
たとえば、ユーザーから解除を告げられた場合、ユーザー側の方針変更でシステムを開発する必要がなくなった旨を記したメールなどが残っていれば、ユーザーが後から解除原因が開発の遅延であるなどと主張された場合に有利となる可能性があるためです。
反対に、ユーザーとやり取りをしたメールは相手方の証拠として自社にとって不利に働くリスクもあるため、たとえ正式な文書ではなかったとしても、表現などには日頃から注意を払うことをおすすめします。
システム開発に関するトラブルに強い弁護士へ相談する
契約書や文書、メールなどを取りまとめたら、システム開発に関するトラブル解決実績が豊富である弁護士へご相談ください。
相手方も早期に弁護士へ相談する可能性が高く、無理に自社のみで対応しようとすると不利な結果となるリスクが高くなるためです。
システム開発プロジェクト進行中におけるトラブル予防策
システム開発プロジェクトの進行中におけるトラブルを、完全に防ぐことは困難です。
しかし、次の対策を講じることでトラブルを最小限に抑えやすくなり、たとえトラブルに発展してもスムーズに解決しやすくなります。
- 起こり得るトラブルを想定して契約書を作成する
- やり取りについて詳細な記録を残す
起こり得るトラブルを想定して契約書を作成する
トラブルをスムーズに解決するため、システム開発委託契約書は起こり得るトラブルを想定して作成するとよいでしょう。
さまざまな事態を想定し契約書に盛り込むことで、契約書に照らして解決できる可能性が高くなるためです。
やり取りについて詳細な記録を残す
契約書のみですべてのケースを想定することは容易ではありません。
そのため、システム開発委託契約について、ベンダーとユーザーとの間で行ったやり取りについては、できるだけ詳細な記録を残すようにしてください。
具体的には、双方の間で開かれる会議について議事録を残したり、ユーザーから仕様変更を指示された際に、その内容や追加費用を記した変更管理書を取り交したりします。
議事録などには会議で決まった結論のみを記載するのではなく、いざトラブルとなった際に争点となり得る事項を踏まえ、可能な限り詳細に記載することが重要です。
まとめ
システム開発プロジェクトの進行中には、さまざまなトラブルが発生する可能性があります。
システム開発委託契約は報酬額が億単位など高額となることも多く、トラブル解決には長期を要することも少なくありません。
そのため、契約書を作り込んだりやり取りの記録を残したりするなど、万が一トラブルとなった際に備えて対策を行い、トラブル発生時には早期に弁護士へ相談する体制を構築してください。
