システム開発は、大なり小なりトラブルがあると言われています。
弊社にもたくさんのシステム開発のトラブル案件が相談されますが、トラブルになる原因は同じものが多いです。そこでよくあるシステム開発のトラブルを紹介し、その予防策を解説します。
この記事の目次
請負契約と準委任契約の違いが分かっておらず、後からトラブルになるケースがたくさんあります。
これらの契約形態は、システム開発に関わる報酬や責任の取り扱いに大きな影響を与えるため、企業経営者にとっても知っておくべき事項です。
請負契約は、特定の成果物を納品することを前提とし、納品が完了して初めて報酬が支払われます。このため、成果物が納品されない限り、ベンダーは報酬を得ることができません。
一方、準委任契約は、作業そのものが報酬の対象となるため、納品の有無に関わらず、ベンダーは作業を進めるたびに報酬を得ることができます。
企業がシステム開発契約を結ぶ際には、これらの契約形態の違いを十分に理解し、プロジェクトに適した契約形態を選択することが重要です。特に、請負契約の場合、納品の遅延や品質に関するトラブルが発生した場合に報酬の支払いが滞る可能性があるため、ユーザ側とベンダー側の双方で納品基準を明確にしておく必要があります。
また、契約書のタイトルが「請負契約」または「準委任契約」であることは、必ずしもその内容を保証するものではありません。重要なのは、契約書の内容そのものであり、具体的な業務内容や成果物、報酬に関する記載が明確にされているかどうかなので注意をしましょう!
システム開発におけるプロジェクト管理は、ベンダーとクライアントの両者がそれぞれの役割を果たすことで成り立ちます。
ベンダー側には、プロジェクトを適切に進行させるための「プロジェクト・マネジメント義務」が課されており、クライアント側には、ベンダーが作業を進めるうえで必要な情報や協力を提供する「協力義務」が課されています。
そして裁判では、義務を果たさなかった側に、損害賠償責任などが生じるのです。
例えば、ベンダー側が進行管理を怠った結果、納期に間に合わなかった場合はベンダー側に責任が生じます。また、クライアント側がベンダーの要望に迅速に対応しなかった場合は、クライアント側に責任が生じます。
こうしたトラブルを防ぐためには、ベンダーとクライアントの間で定期的に進行状況を共有し、連絡を取り合うことが重要です。
定期的なミーティングの実施や議事録の作成、メールでのやり取りは、プロジェクトの進行状況を記録し、後にトラブルが発生した際の証拠として役立ちます。特に、納期の遅延や仕様変更が発生した場合は、その都度、議事録やメールで双方の認識を確認し、記録に残しておくことがトラブルの回避につながります。
システム開発においては、契約書を締結する前に開発作業が始まることがあります。しかし、契約書がないままプロジェクトを進めることは、非常にリスキーです。
裁判所は、契約書がない場合、契約が存在しないと認定する傾向があります。そのため、後にトラブルが発生した場合、契約が成立していたかどうかが争点となり、開発者やクライアントが法的に不利な立場に置かれることがあります。
例えば、契約書が存在しないまま開発が途中で中断された場合、ベンダーが報酬を請求できなくなる可能性があります。
このようなリスクを回避するためには、早期に契約書を締結することが重要です。少なくとも、開発対象となるシステムや報酬額については、契約書に明記する必要があります。
仮に契約が成立していないと認定された場合でも、相手方に損害賠償請求できる場合があります。それが「契約締結上の過失」と言われる場合です。これは契約に向けて交渉があり、契約締結の最終段階まで行ったのに、一方的に契約を締結しなかった場合です。
契約締結の最終段階まで行ったかの判断としては、相手方からの契約の内示書をもらう、契約書のひな形を事前に送っておくなどの事実が重要になります。契約締結に時間がかかりそうなら、このような行為をしておくのは一つの手段です。
システム開発では、納期遅延が発生することがよくあります。特に、ベンダー側のプロジェクト管理が不十分な場合や、クライアント側の頻繁な仕様変更が原因で遅延が生じることが多いです。このような場合、どちらが責任を負うべきかが問題となります。
先述したように、ベンダー側の「プロジェクトマネジメント義務」とは、システム開発の専門家として、システム会社を主導して進めていくこと、具体的にはクライアント側にも、依頼事項や確認連絡を入れるなどの動きが必要になります。
クライアントの「協力義務」には、プロジェクトを進行するうえで必要な協力をベンダー側に迅速に提供する義務があります。
そして裁判になれば、この両者のどちらに義務違反があったのかを、検証していくという作業をしていくことになります。そのとき証拠になるのは、メール、チャットでのやり取りや会議の議事録です。裁判では客観的な証拠が重要になります。
よってシステム開発では、納期や仕様変更に関する変更などの重要事項については、メール、チャット、議事録に残しておくことが重要です。例えば、仕様変更が発生した場合、その影響をどのように管理するか、納期にどのような影響が出るかを明確に議論し、議事録として残しておきましょう。
システム開発が完了した後も、保守契約はシステムの安定運用にとって欠かせない要素です。保守契約では、システムの障害対応やバグ修正、機能改善など、運用中に必要となるサポートが提供されます。しかし、保守契約においても、契約内容が曖昧であるとトラブルが発生する可能性があります。
保守契約で特に注意すべき点は、保守範囲の明確化です。保守対象となる機能やシステムの範囲、対応方法、対応時間などを明確に規定することで、後にクライアントとベンダーの間で「この作業が保守対象に含まれるか否か」といった争いが生じるのを防ぐことができます。
保守契約書に保守範囲が不明確な場合、ベンダーが対応すべき範囲を超えた要求を受けたり、クライアントが保守対象外の作業に対する追加料金を請求されたりする可能性があります。
このようなトラブルを防ぐためにも、契約書に保守範囲を具体的に明記することが必要です。また、保守の対応時間や対応方法(リモート対応やオンサイト対応など)についても詳細に記載しておくことで、緊急時の対応がスムーズに進行します。
さらに、保守契約が存在しない場合でも、議事録やメールのやり取りが保守業務に関する証拠として扱われることがあります。保守契約が曖昧な場合でも、これらのやり取りが後にトラブルの解決に役立つため、常に記録を残しておくことが推奨されます。
システム開発において、納品されたシステムが「完成」とみなされるかどうかは、ベンダーとクライアントの間で争点となりやすいです。特に、システムに不具合が多発している場合や、クライアントが完成品として認めない場合、ベンダーが報酬を受け取れない可能性があります。
システムが完成とみなされる基準は、双方の合意した仕様の水準に達しているかです。「双方の合意した仕様」がどういったものであったかは、仕様書や議事録、メールのやり取りによって確認されます。
そして納品書や検収書がある場合には、検収が完了して、システムが完成したとみなされる有力な証拠になります。重要な証拠となるため、ベンダーは検収終了時にクライアントからこれらの書類を取得することが必要です。
一方で、検収書が存在しない場合でも、クライアントがシステムを実際に使用している事実や、システムの保守契約を締結している場合などは、システムが完成したとみなされることがあります。
このような場合も、契約書や議事録などの書類が重要な証拠となるため、契約の進行中に常に記録を残しておくことが重要です。
システム開発契約は常にトラブルがつきまといます。そしてプロジェクトがトラブルに発展した際に多大な損失を被る可能性があります。
本記事で紹介した各ポイントを踏まえ、契約書の内容を十分に検討し、トラブルを未然に防ぐための対策を講じることが重要です!
LINEの友達追加で、企業に必要な契約書雛形、