このところ、システム開発を受託しているIT企業の方から相談を受けることが増えています。
システム開発に関する法律トラブルでは、クライアントが望むレベルに達していないとか、システムの完成度が低いという理由で代金の支払いを拒絶されるケースが多いのが特徴です。

また、システム開発では、ローンチ後も多少のバグを修正する作業が行われるのは通常のことでもあるため、完成引渡しの境界線を定めることが難しく、そのために売掛金の回収に難を生じるトラブルに発展するケースも少なくありません。

今回は、システム開発をめぐる法律トラブルのよくあるケースをご紹介し、事前にトラブルを回避するための防止策を解説します。
システム開発を受託したのに、代金を回収できないお悩みのある方は、ぜひご一読ください。

よくあるシステム開発のトラブル事例

ご相談いただくシステム開発でのトラブルには、次のようなものが挙げられます。

➢ システム開発の案件がスタートしたものの、遅々として進捗しないことにクライアントが不満を持ち始めている。
➢ システム開発者からの「どんな機能を備えてほしいか」「どんなデザインがいいか」といったヒアリングに対し、クライアントからレスポンスがなく、納期がずれ込んでしまう。
➢ クライアント担当者に納期が遅れることを伝えたのに、それがクライアント上層部に伝わっておらず、後日になって事情を知らないクライアント社長が業を煮やし、代金を支払わない。
➢ 代金が支払われないまま、延々と修正対応をせざるを得ない状況に陥る。

システム開発は、建築に例えられることがよくあります。
実際のところ、設計して建築して完成引き渡しという一連の流れは、大変よく似ていますので、専門外の人にとってはイメージしやすい側面があります。

しかし、建築案件と大きく異なるのが、①作りながら仕様や設計を検討していくパターンがあること（アジャイル型）と、②完成引渡しの線引きが難しいことです。

建築の場合は、最初に完成した設計図があることが前提で、トラブルが起きた場合、その設計図どおりに建築したのかが問われます。
しかし、アジャイル型開発の場合、設計→開発→設計→開発、、、と双方がキャッチボールしながらゴールに向かっていくので、「そもそも契約当初に何を作ることになっていたのか」と問われても、答えにくい側面が出てきます。

また、システム開発では、一定の完成レベルに達しても、ある程度のバグが発生するのは織り込み済みで、完成後もある程度の作業が入るのは通常ともいえます。
そのため、完成後の作業が、はたして完成してないからまだ作業しているのか、完成したけれどもその後の作業をしているのかが、クライアントに専門知識がなければ分かりにくい側面があります。

システム開発者としては、受託した開発案件に責任をもって取り組み、やり遂げたいという矜持（きょうじ）があるため、早々に手を引くことは難しいものです。
ところがそれが仇（あだ）だとなって、いつの間にか赤字になっても開発から離れられなくなってしまい、同時に多くの難案件を抱え込んでしまうシステム開発会社が数多く出てきてしまう問題が起きています。

さらに悔やまれるケースとして、クライアント担当者の合意のもと開発を進めてきたにもかかわらず、その現場の状況がクライアント上層部に伝わっておらず、いざ完成引渡しとなった時に、「思っていたのと違う」「完成が遅すぎる」などとクレームを言われ、一方的にシステム開発者が非を問われ、しまいには代金を払ってもらえない事態に陥ることが多いのも特徴です。

システム開発に関するトラブルを回避するための対策

上記のようなシステム開発に関するトラブルは、事前に対策をとっておくことで、かなりの部分で回避することができます。

❖対策1.クライアント担当者と話した内容や確認を取った内容を記録しておく❖

トラブルが発生して、クライアントの社長など上層部が出てきた場合、クライアント側の現場担当者は当時の状況を知っていたとしても、黙っていたり、事実を捻じ曲げて伝えたりすることは少なくありません。
ですので、担当者との合意事項は記録に残しておくようにしましょう。

通常作業の一環として記録を残しているつもりであっても、後日に確認してみると、肝心な内容が抜けていたり、意図的に記録されていないケースもあります。
ですので、何のために記録を残すのかを意識して、トラブルが発生した際に有効な証拠となるようにということも意識して記録を残すようにしましょう。

具体的には、以下のことに意識して記録を残しておくとよいです。
➢ 何を依頼されたのか
デザインの確認や機能のチェックなど、依頼されたことが明確であることが必要です。
➢ 期限はいつまでなのか
必ず期限を決め、しかもその期限が現実的かどうか確認しておきます。
➢ 繰り返しお願いする
案件に関するヒアリングへのレスポンスを複数回催促したとしても、それが記録に残っていないと、後日会社間での話し合いになった際に不利になってしまいます。
「こちらは何度も催促していた」という記録を残しておくようにしましょう。

❖対策2.前金もしくは段階的な代金支払いの契約を結ぶようにする❖

受託者としての立場上、なかなか切り出しづらいことですが、システム開発は長期化するケースも多いので、すべてを事後的な出来高払いにするのはリスクが大きいです。

それでも、契約締結段階で、予算や開発期間で区切っての前金システムを提案したり、実装フェーズを何段階かに設定して、その段階別に開発費を支払ってもらうよう取り決めておくこともは、トラブルを回避する有効な対策です。

❖対策3.システム完成の定義を明確にしておく❖

予め作成し提出しておく仕様書に、実装する機能一覧を明記し、システム完成の定義を明確化しておくことは有効です。
先ほどの述べたアジャイル型ではどこまで盛り込めるかという課題もありますが、それでも可能な限り仕様を洗い出しておくことで、後にトラブルが起きそうになったときに優位に立つことが可能です。

論理的な開発者と情緒的な発注者

システム開発に限らず、WEBサイト制作のときにもあるのですが、受注するIT企業と発注者との間にトラブルが発生する原因として、システムそのものの欠陥というよりも、実は双方の認識の違いだったり、イメージしていたものが相違だったというケースも多いです。

というのも、クライアント側は、いわばイメージ先行で、抽象的・情緒的な世界観で案件を発注するのですが、システム開発側はそれを具体的・理論的な実装へと落とし込んでいくものとして受注するので、そこに思考のギャップや溝が生じるリスクがあるのです。

例えば、システムの機能について具体的なイメージを持てる発注者は実際には多くなく、おおむね「使いやすくて素敵なシステムが作りたい」といったようなイメージから入るのが通常です。
そうすると、新システムに夢を見かねないクライアントに対し、システム開発側は限りある予算内で具体的な機能に落とし込むため、何かを捨てさせる作業も必要となってきます。いわば“夢から醒めてもらう”という説得も必要となるのです。

それがなされないまま、あるいはできないまま案件を進めてしまうと、なかなかクライアントの承認が取れず、工期も延び延びになってしまい、そうしたコミュニケーション不足がそのままトラブルへと発展するのです。

先日、こんなエピソードがありました。

システム開発で揉めに揉めて訴訟に発展したケースでしたが、現実の開発状況を検証しようということで、法廷で画面を共有しながらシステムを操作し、互いに意見を主張する機会がありました。

このとき、クライアントが「こうしてほしかったんですよ。それなのに…」というと、システム開発者が「え、そうだったんですか？ それなら、こうすればできますよ」と答えました。
同じようなやり取りが何度も続きましたが、そのたびにクライアントの疑問が解消し、双方の溝が埋まっていき、やがて法廷がそのまま会議のようになってしまい、結局そのままシステム開発が再開したのでした。

このように、多くの場合はコミュニケーションが不足していて、クライアントの望むものとシステム開発者が実現可能なこととのすり合わせができていなかっただけ、というケースも多いのです。

システム開発費が回収できない状況に陥らないために

今回は、システム開発における法律トラブルを主な類型ごとに整理し、また、クライアントの情緒的な希望を具現化するという観点からお話しました。

私が顧問をさせていただいている企業には、トラブルになる前のタイミングでご相談いただくようにしています。
今のうちからどんな情報を取っておけばよいかというアドバイスや、クライアント担当者のタイプに応じて、どのような関わり方をすればよいかといった交渉学の見地からもアドバイスいたします。
プロジェクト担当者の方に直接アドバイスもいたしますので、現場の方の不安もなくせる役割を担えたらと思っています。

受託案件を複数抱えていて、売掛け金回収の不安を抱えていらっしゃる企業の方は、ぜひご相談ください。
業務委託契約書に見直しや、前金のルール設定などから関わらせていただきます。

《契約書作成・リーガルチェックサービスのご案内》