システム開発の報酬が未払となった場合の法律とは

システム開発の報酬が未払となった場合の法律とは

システム開発の業務を引き受けるベンダー側にとって、ある意味最大のリスクとなるのは、「納品したにもかかわらず、ユーザーが報酬を支払ってくれない」という事態ではないでしょうか。システム開発に要するコストは、その多くがプログラマをはじめとするスキルをもった人材となることから、人件費が多くかかる場合が多いものです。売上の回収が滞ることはときに死活問題ともなりかねないでしょう。本記事では、報酬の支払いにユーザーが応じないという場合を想定して、ベンダー側が検討すべき事項について、法律的な観点から解説していきます。

まず、報酬請求が可能な状態となっているかを要確認

  • ベンダーがユーザーに対して、成果物を納品しているにもかかわらず、ユーザーが納品を受け付けてくれず、そのせいで報酬の請求業務まで滞ってしまっている
  • 検収まで終わっていた認識だったにもかかわらず、ユーザーの認識との間に何らかの齟齬があり、報酬の支払いに応じようとしない

という事態は、現実的にも十分起こりうるものです。

なお、ユーザーが出来上がったシステムの仕様を点検し、納品を受け付けることは、システム開発の用語では、「検収」と呼ばれます。この、検収というものについての意義と、それの進捗が芳しくない場合に検討すべき事項については、以下の記事にて詳細に解説しています。

検収そのものについての全体的な説明は上記記事に譲りますが、法律上、ユーザーの検収が完了したといえるのか否かについては、「みなし検収条項」についての規定も踏まえて検討を行う必要があるのでした。

この点も念頭におきつつ、ユーザーが報酬の支払いを行ってくれないという事案を想定してまず第一に検討すべき点となるのは以下の点でしょう。

  1. そもそも仕事が完成しているのか、もしくはまだ未完成なのか
  2. 瑕疵担保責任(民法635条)の適用はされうるのか否か

なぜ上記二点についての確認を第一に行うべきかといえば、そもそも仕事が完成していて、かつ、瑕疵担保責任(民法635条)の適用がないことをあらかじめ確認しておかないと、かりに訴訟を起こしたとしても、結局報酬の支払いに応じてもらうことが期待できないためです。

では、具体的に、上記二点を検討するために、ベンダー側の担当者はなにを調べればよいのでしょうか。以下に、確認すべき書類にどのようなものがあるかを見ていきます。

報酬請求の可否を調べるために確認すべき書類とは

納品書
納品書がないという場合には、納品まず納品が完了しておらず、仕事が完成していないという推定を強める要素となります。

検収の結果を通知する書類
仕事が完成したものと扱ってよいか否かを判断する際に、もっとも重要な資料となります。また合わせて、もしユーザー都合で検収が先延ばしになっているような事案であれば、「みなし検収条項」の記載が契約書上どのようになっていたのかも、あわせて確認しておくとよいでしょう。

課題管理一覧表
これまでにどのような課題がみつかり、そしてどのような対処を行ってきたのかを知るための資料となります。また、納品を行った後に発覚した障害・不具合の状況と、それに対する修補状況を把握するための資料ともなります。

要件定義書・設計書および変更管理書・各種会議議事録など
ユーザーとベンダーで当初どのような認識を有していたかを明らかにすることにより、なにが障害・不具合と呼ぶべきものなのかを明らかにするための資料となるものです。

なお、開発すべきシステムの仕様の変更をどのように管理するかや、変更管理書の作成方法などについては、別記事にて詳細な解説を行っています。

解除通知書もしくは、ユーザーの意向を記す文書
検収を進めようとしないこと(あるいは報酬の支払いに応じないこと)について、ユーザーがどのような意図を持っているのかを知るための手段となります。

次に、いくらの報酬請求が可能なのかを確認

仕様変更後における請求金額の再計算方法とは?

いくらの請求が可能なのかについては、契約書に記載がなされているのが原則ではあります。しかし、事後で仕様の変更等が行われた場合には、きちんとした契約書(やそれに準ずる文書)が残っていないという場合も想定されます。仕様の変更・機能の追加等の後発的な理由に基づく見積りの再計算のやり方については、以下の記事にて詳細に解説を行っています。

見積りの再計算の方法については本記事の通りですが、特に請求金額の増額の可否を検討するという観点からいうならば、

  1. 追加開発・機能の修正に関する部分の見積書の有無とその内容
  2. 見積書に対するユーザー側の反応の内容
  3. 課題管理一覧表に記載される追加開発・機能の修正を発生させた状況と、その額に関する合意の有無

といった点を中心にみていくことになります。要は「その金額で業務を発注する」という点につき、ユーザー側との意思の合致はあったといってよいのか(つまりは契約が成立しているといってよいのか)という点を調べていくという流れになります。

最後に、実際に訴訟を行う場合の懸案事項を検討

逆に反訴請求がなされる可能性に注意

システム開発では、ユーザー・ベンダーどちらか一方が相手方に訴訟を提起すると、逆に相手方から反訴の提起がなされる場合が少なくありません。すなわち、報酬の支払いに応じないという状況につき、ユーザーの側にもなにかしらの言い分があるということです。

そもそもシステム開発は、ユーザー側も各種協力義務を負いますが、まず前提として、ベンダー側がシステム開発の専門家として広範な裁量と大きな責任を負っている点を忘れてはならないでしょう。ベンダー側がシステム開発に対して負っているプロジェクトマネジメント義務については、以下の記事でも詳細に解説しています。

つまり、一方的に報酬を支払わないユーザー側に帰責することが可能であるのかという点については、事前によく検討しておく必要があるということです。過去の裁判例を見ても、当初ベンダーから報酬請求を求めて訴訟を提起したのに、ユーザーから逆に、原状回復義務や損害賠償請求がなされたという事案が多数確認されます。

営業上本当にメリットがあるかどうかも要検討

仮にベンダーの言い分が通り、実際に報酬の請求が可能な状態であることが訴訟で認められたとしても、訴訟にまで事態が紛糾するならば、以後の取引の継続は実際問題困難となることが予想されます。加えて、訴訟のうえで自己の言い分が認められたとしても、実際に報酬が受領できるまでにかなりの時間がかかることも覚悟すべきでしょう。訴訟を行うことにかかる手間やコストも決して小さくないことも考えるならば、むしろ妥協点を見出す努力をするほうが穏当で良いということも多いでしょう。

まとめ

ユーザーが報酬支払いに応じない場合に、その問題を法的に検討しようとすると、複数種類にわたる文書の確認が必要となります。また加えて、ただ単に文書管理が徹底できていればよいというものでもなく、最終的に訴訟に踏み切った場合に組織的にどのようなリスク・デメリットを抱えることになるのかといった点についても検討を要します。

日頃の文書管理の徹底といった点については、たしかに現場レベルの業務に属する場合が通常でしょう。しかし、いざ保管された文書・資料をもとに訴訟に踏み切るとなれば、それは重大な経営判断となりうるものです。こうしたイレギュラー事態にこそ、現場側と経営側の結束力・組織力が問われるのだという点とともに、一連の流れを掴んでおくべきでしょう。

モノリス法律事務所

モノリス法律事務所は、元ITエンジニアで企業経営経験のある代表弁護士の下、約60社のIT・ベンチャー企業の顧問弁護士等を勤めております

Phone: 03-6262-3245 (平日10時-17時)
Email: kawase@monolith-law.jp

モノリス法律事務所

モノリス法律事務所

モノリス法律事務所は、IT・インターネット・ビジネスに強みを持つ、東京・大手町の法律事務所です。

シェアする