システム開発で訴訟のリスクも！？回避するためにできること

トラブルの大きな原因となる項目のひとつが、金銭面でのリスクです。依頼していた当初の予算を大幅に超える金額を請求される可能性があります。

システム開発の分野では、製造における部品代のように、前もって設定された金額の幅がはっきりしないのが実情です。そのため、プロジェクト開始後に仕様の変更や機能の追加の依頼をすると、想定していた予算を超えてしまうことがあります。これに加えて、開発を始めてから予定通りに進まず期間が延びたりすると、開発側での工数が増えてしまうため、コストがかさみます。

金銭面でのリスクが原因で裁判となった事例として、開発会社側（原告）がユーザー側（被告）へ請負代金の約5570万円を請求したケースがあります。ユーザーは当初、別の開発会社に「現行のオフコンから新機能を追加したパソコンへ書籍在庫管理システムの導入をしたい」と依頼したものの、思うように開発が進まず本件の開発会社へ発注を依頼します。
その後、ユーザーは検収段階で現行オフコンに実装されていた個別出版社プログラムがないことに気付き、その機能の追加を要求しました。それを受けて開発会社側は追加開発を行い、請負代金を加算して請求しました。しかし、ユーザーは本機能が開発業務範囲に含まれるとし、追加費用を拒んだため、提訴することとなったのです。

これらは、あらかじめ追加費用に関する契約を交わしていれば、トラブルに発展することはありません。しかし、契約を交わすことなく仕様変更や追加の依頼をしてしまうと、プロジェクト終了後には「予算をとうに超える金額が請求されていた」といったことが起こりえます。

このように、追加費用の認識が異なることで訴訟に発展することも少なくありません。アウトソーシングでシステム開発を行う際は、追加費用に関する契約もしっかりと確認することが大切です。

システム開発において、コミュニケーション不足は深刻な問題です。開発側との認識に相違があると、プロジェクトの失敗につながってしまいます。

コミュニケーション不足が原因で裁判となった事例として、開発会社側（原告）がユーザー側（被告）に売買代金の約763万円を請求し、認められたケースがあります。ユーザーが開発会社に教材販売システム一式を発注したところ、開発会社側は必要な打合せを後伸ばしにしていました。一方で、ユーザー側もデータ登録作業を怠ったことから、システムの完成が納期に間に合わないというトラブルが発生したようです。それを理由としてユーザー側が契約解除の要求と代金の支払いを拒み、開発会社が提訴することとなりました。

システム開発においては、開発会社とユーザーの双方が協力し、緊密なコミュニケーションを行うことが重要です。打合せや担当作業を怠るとうまく連携が取れず、納期に間に合わなかったり、当初の契約時に想定していた仕様を満たしていなかったりということが起こりえます。さらに、システムの仕様に誤った認識があったり、相手が言った言葉を違う意味で理解してしまったりすると、すれ違いが起きてしまいます。

しかし、システムの仕様や機能の認識に齟齬があることは、システムが形になるまで気づきにくいものです。

そうなると、仕様の変更や機能の追加を依頼することになります。少しの変更や追加であればトラブルに発展する可能性は低いです。しかし、プロジェクト後半に大規模な変更があると、大幅なコストが発生してしまい、開発側とのトラブルにつながることがあります。最悪の場合、プロジェクトが破綻してしまうことも考えられます。

最初の段階で、システムの意味を間違って伝えていたり、相手の言葉を違う意味で捉えたりすると、そこから方向性が大きくそれてしまうおそれもあるため、十分な注意が必要です。
発注側と開発側で認識の相違が起きないよう、打ち合わせなどの際は綿密なコミュニケーションを行ってください。

開発の計画を行っている段階では、技術的に問題がないと思われていたシステムでも、実際にプロジェクトが始まると導入が難しいことが判明するケースもあります。

ITの技術進歩のスピードはめざましく、プログラミングの構成も複雑化の一途をたどっています。各システムが正確に作動し、相互の動作を妨げることはないかどうかは、開発後でないと判明しない場合も多いです。技術面でのリスクを完全に回避するのは難しいです。

技術的な要因でトラブルとなった裁判として、ユーザー側が開発会社側に9億以上の損害賠償を請求した事例があります。具体的には以下のような内容でした。

ユーザー（原告）が基幹系システムの再構築を開発会社（被告）に依頼したところ、実際にユーザー側でシステムの作業確認ができる直前の総合テストの段階でシステムにいくつかの不具合が発覚しました。もともと稼働予定だった日程までに何度も延期することとなったようです。更に、調達したハードウェアの処理能力が不足しており、システムの実用がうまくいかないことが判明したことから、ユーザー側で契約目的に反すると判断し提訴しました。

サーバーやネットワークなどのインフラ整備のことを「サーバ・サイジング」といいます。本件については、ユーザー側と開発会社側におけるサーバ・サイジングの責任の所在を明確に定めていなかったことも、要因のひとつとしてあげられます。

このような技術的なリスクについては開発会社側に責任を問うケースが多いようですが、無理な追加開発の要求をしていたときや、要件定義書作成などの協力が不十分だった場合には一部責任を問われることがあるため、注意が必要です。

費用面のリスクをできる限り抑えるには、依頼したい内容について明確にすることが重要です。

システム開発の費用は、開発が必要な要件や工数、担当者の数、開発のための期間といったあらゆる項目から算出されます。請求金額の妥当性を高めるためには、現状何が不便なのか、何がしたいのかといった意思を明確にする必要があります。

要望が不明確だった場合、予想外のトラブルが発生して、その対応に時間や予算がかかってしまったり、進捗に遅れが生じたりする可能性もあります。
予想外のトラブルを起こさないためにも、事前に必要な機能や業務上の改善点などを洗い出しておくことが大切です。

前述したように、認識のずれによるトラブルを防ぐには、打ち合わせの段階から認識をすり合わせ、行き違いが起こらないようにしておくことが大切です。システム開発の目的、要件、進捗など、各段階でもし認識のずれが起こっても、早い段階で判明すれば、大きな問題に発展するリスクを減らせます。

また、認識のすり合わせで有効とされる手段は、ルールや役割分担などを表に明記し、「見える化」しておくことです。責任の範囲や意思決定を行う人間が誰なのかを双方で把握しておくことで、認識のずれを防ぐ効果があります。

技術面でのリスクを可能な限り回避するには、システム開発の入念な検証が求められます。

発注側でもITに知見のある担当者を配置しておくと、バグや問題点を早急に見つけやすくなります。基本的には開発側が要件に対して、技術的に導入、実現が可能かどうかの検証を行いますが、発注者側でも適宜検証を行うことで、さらにリスクを回避できる可能性が高められます。

問題が発生したときは、それを解決するにはどう取り組めば良いのかといった擦り合わせを行うことが重要です。
自社にITに詳しい人材がいれば良いですが、いない場合は外部の専門家に相談するのも選択肢のひとつです。