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

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

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

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

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

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

関連記事：システム開発の検収とみなし検収条項の適用場面とは

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

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

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

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

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

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

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

関連記事：法律的観点からみた、システム開発における変更管理の行い方とは

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

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

関連記事：システム開発の見積り金額の事後増額は可能か

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

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

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

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

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

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

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

関連記事：システム開発におけるプロジェクトマネジメント義務とは

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

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

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

まとめ

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

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