【システム開発・支払い】トラブルの原因で最も多いと言われる支払いは、どのタイミングで行うのか？支払い方法や安く抑えるポイントと共に実際の裁判事例などを徹底解説！

「システム開発は契約書通りに進めていけばトラブルはおきない」

こう考えている担当者は珍しくありません。しかし、その契約書の内容は正しく把握できていますか？特に重要となるのが支払いに関する項目です。

契約書内容に同意していても、後から「こんなこと知らなかった」という事は珍しくありません。それは、多くの方が契約書の内容を流し読み程度でしか確認しておらず、形式的なサインをして開発が始まってしまうためです。

「着手金の支払いは納得していたけど50％も払うなんて聞いていない」

「システム開発が完了したのになぜか支払いがされない」

後になってこうしたトラブルに見舞われないためにも、システム開発に関する支払いについてしっかりと情報を収集しておきましょう。本記事では、支払いの方法や契約形態ごとの支払いタイミング、開発費用の内訳などを徹底的にご紹介致します。

本記事の内容を把握ししっかりと理解する事で、無駄な争いをなくしスムーズなシステム開発の依頼が行えるようになります。また、記事最後には実際の裁判事例もご紹介しておりますので、ぜひご覧ください。

支払いタイミングの基準は「検収合格日」

システム開発における支払いタイミングとは、主に「検収合格日」を基準としていることがほとんどになります。具体的には、「検収合格日から〇日以内の支払い」「検収合格をした月の翌月末」など、検収合格日に基づいて支払期日が決定される事になります。こうした取り決め自体には何ら問題はありませんが、中には検収期間が長く設定されているという事もあります。

その分支払いのタイミングも長引くという事になりますので特に注意しておきましょう。仮に、「検収期間が30日間・検収合格日翌月末の支払い」という場合で見てみましょう。

システム開発を行い納品日が4月10日だった場合、検収期間が30日間となるので、検収合格日は5月10日という事になります。支払いは合格日の翌月末となっているため、報酬支払い日は6月30日になります。

このように、納品すれば報酬の支払いが行われるという事ではなく、実際にその支払いは作業を行ってからおよそ3か月後という事になります。また、上記の説明は検収に一発合格した場合の支払い日となりますので、例えばここで何かしらの問題が発生し、修正などが発生した際にはさらに修正作業が必要となりますので、受注側は修正が完了するまで報酬の受け取りは出来ません。

こうした場合、もしも報酬の支払いが遅くなることに不都合が生じる場合、発注側と受注側で事前に打ち合わせを行い、支払いに関して細かく取り決めを行うようにしましょう。検収期間を短くする、検収合格から支払いまでの期間を短くするなど。双方でしっかりと話し合い決めることが大切です。基本的には「検収合格日から支払日が決まる」という流れになりますので、この部分の話し合いを行われなければ、納品から数か月先の支払いとなる場合もありますので、よく確認するようにして下さい。

また、仮にシステム開発の契約が下請法の適用を受けるという場合、支払いは検収合格日ではなく納品から60日以内という事になります。そのため、この支払のタイミングに関する項目は、受注側、発注側双方にとって特に重要視するポイントと言えます。相違がないように事前にしっかりと綿密な打ち合わせを行いましょう。

システム開発の「検収」とは？

システム開発の「検収」とは、納品された成果物が発注した通りのものとなっているかどうか確認する作業になります。簡単に言えば、受注側が発注側に対して「作業が完了しました。ちゃんとできていますか？」とシステムを提出し、発注側が「確かに受け取りました。」とOKを出すことです。納品されたものをチェックし、修正の必要はあるか、仕様通りに出来ているかを見て、大丈夫であれば検収合格となり、そこで初めて支払い日が決まります。

「検収」と「納品」の違いとは？

IT業界に限らず、この「検収」「納品」という言葉はビジネスの世界ではよく耳にします。同じような意味に感じている方も多くいますが、実際は大きく意味が異なる場合がありますので、注意しておきましょう。

まず納品ですが、これは発注側に実際にシステムを渡すことを指します。この場合、システム開発では基本的にありませんが、受け渡しと支払いが同時の場合は納品という言葉はあまり使いません。大型家電や家具などのように、まずはお客様から商品代金を頂き、後から配送して商品本体をお届けする、これを「納品」といいます。支払いタイミングが前後することはありますが、このように、支払いタイミングと受け渡しが異なる場合が納品です。

では、検収とは一体何なのか。システム開発に限らず、検収とは「納品されたものに問題がないかチェックを行いOKをだす」という事になります。そのため、システム開発の場合は、まず受注側が開発を行ったものを発注側に「納品」します。その納品されたものをチェックし「検収」を行います。OKが出れば、その日が「検収合格日」という事になります。

契約形態によって支払いタイミングは異なる

支払いタイミングは、契約形態により異なるという事はご存じでしょうか。システム開発の契約形態は、「請負契約」「準委任契約」の2つに分けられます。2つの契約形態は、業務に関する義務や成果物に関することなどの大きな違いがありますが、支払いに関する内容も異なっている場合がほとんどです。では、請負契約、準委任契約の支払いタイミングはいつになるのか、どのような支払いになるのかを詳しく見ていきましょう。

【請負契約】

請負契約の場合、成果物が完成していなければ受注側は報酬の受け取りは出来ません。請負契約とは、仕事を完成させるということを約束し、その対価としての報酬の支払いが生じるという契約になります。

そのため、当然成果物がなければ報酬の発生もありません。いくら長い期間開発を行っていたとしても、完成していなければ1円も報酬は受け取れません。請負契約では、先ほど本記事でご紹介したように、「検収合格日」を基準とした支払いが行われることがほとんどです。

成果物を納品し、検収を経て報酬が発生します。そのため、納品してもすぐに支払いが行われるという事ではありません。非常に極端な話にはなりますが、未完成のままで関係が破綻してしまった場合、報酬が支払われるどころか訴訟問題に発展する事もあります。後程詳しくご紹介致しますが、報酬の「前払い」などもありますので、契約書作成時や打ち合わせ時などにしっかりと報酬の支払いについて必ず協議をしておきましょう。

【準委任契約】

準委任契約では、請負契約とは違いシステム完成が目的にはなりません。システムの完成、未完成問わず、業務を行った分の時間給が報酬として支払われます。準委任契約の場合、項目ごとに依頼を行っているという事がほとんどになりますので、その手持ちの仕事が完了した時点で報酬が発生します。

この際、当初の契約時において予定していた工程が最後まで行われていたかどうかがポイントとなります。請負契約の場合では、システムが完成し納品を行い、検収合格日から報酬の支払い日が決まりますが、準委任契約の場合、多くは工程が完了した際に、当初の取り決めにより決定した日付で報酬の支払いが行われます。

契約書で「終了した1週間後」となっていれば、業務終了した日から1週間で報酬の支払いが行われ、「終了した日の月末」となっていれば、その月の末に支払いが行われるという事になります。

システム開発の内訳・相場は？

システム開発における内訳や相場は、そのプロジェクトの規模やシステムの難易度によって大きく異なります。また、契約によっては着手金や前払いなどの発生もありますので、こうした支払いについては必ず協議しておきましょう。

システム開発で多くのトラブルは支払いに関するものとなります。そのほとんどが、認識の違いや理解の不十分さが原因ですので、余計な争いを回避するためにも、システム開発の内訳や相場について、しっかりと把握しておきましょう。

着手金・前払い金について

システム開発の依頼を行う場合、着手金の支払い、もしくは費用の前払いなどを行うべきなのかという疑問を抱える方も多くいるでしょう。本記事の冒頭でご紹介したように、費用の支払いは基本的に検収合格日が基準となりますが、契約内容によっては着手金や前払いなどが発生する事があります。それぞれについて、詳しくご紹介致します。

着手金とは

IT業界に関わらず、様々な業界で聞く着手金ですが、基本的に仕事を開始するにあたり材料や資材などを購入する必要があるモノの場合、着手金の発生は当たり前にあります。代表的なのが建築業界です。建築物を建てるために、まずは資材を準備する必要がありますが、そこに宛てられるのが着手金です。

では、システム開発の場合はどうなのか。建築業界などとは違い、システム開発の場合は仕事を開始するにあたり準備すべき資材などはありませんので、着手金の発生はあまりありません。しかし、全くないという事ではありませんので注意してください。着手金の支払いを行う事で信用を得るという企業も少なくありません。平均的に開発にかかる費用の30％程度が相場となりますが、中にはおよそ50％ほどの着手金の支払いが必要という事もあります。

複数回依頼をしている場合は着手金がなく、初めての契約の際にのみ着手金が発生するという事もあります。また、最終の支払い時に着手金を相殺して改めて金額を出すという企業もあれば、一括で支払いを行った後着手金を返還するという方法を行っている企業もあり、それぞれの着手金に対する意識は異なります。基本は着手金はあまり発生しないという事の方が多いですが、契約段階でしっかりと打ち合わせを行い着手金についての認識を合わせるようにしましょう。

前払い金とは

前払い金は、その名の通り仕事を開始する前に支払いを行うという方法です。ですが、請負契約の場合、民法632条により、受注側が仕事の完成を約束し、発注側が完成した仕事に対して報酬を支払うという契約になります。前述した着手金などがある場合もありますが、費用を一括で前払い要求するという事は基本的にありません。約定により、開発費用に充てるために前払いを行うという事もありますが、原則としては後払いでの支払いという事を頭に入れておくようにしましょう。

フリーランスのエンジニアなどにシステム開発依頼を行った場合、条件として一括前払いを要求されるという事は少なくありません。この倍、契約形態は準委任契約となることがほとんどですので、成果物の有無問わず報酬は発生します。しかし、前払いを行うか、作業終了後に支払うかという点は、必ず契約書に明記するようにしなければいけません。比較的に規模の小さい開発の場合、前払いが用いられるという事があります。

基本的に、契約書に前払いの内容の記載がなければ、報酬の支払いは一般的な後払いとなります。双方で納得して前払いを行うという場合は、契約書にその旨をしっかりと明記し、支払時期に対しての相違がないようにしておくことが重要です。原則は後払いとなるという事をお話ししましたが、絶対に前払いが出来ないという事ではありません。傾向としてはかなり少なくなりますが、実際に前払いを要求するフリーランス、開発会社も存在しますので、後々のトラブルを回避するためにお、必ず内容を細かく契約書に盛り込み、何度も確認を行うようにしましょう。

中間金とは？

中間金は、契約の成立から完了までの中間地点で支払われる報酬の事です。前払いや着手金同様に、中間金の支払いについては契約書で必ず明記を行う必要があります。先ほどもお話ししたように、民法632条で報酬の支払いは完成した仕事に対して行われるという旨があります。そのため、契約書に記載がない場合、この民法が適用されるため中間金の支払い義務はありません。

中間金の支払いを契約書に盛り込む場合、その支払いタイミングについてもしっかりと明記するようにしましょう。設計が完了してからの支払いになるのか、製造後の支払いとなるのかなど、前もってどのタイミングでの中間金支払いが生じるのかははっきりとさせておく必要があります。契約書に記載がある以上は、中間金の支払いがないと次の工程へ進むことは出来ません。設計と製造の間に支払い義務が生じる場合、支払いが行われなければ製造過程に入りません。また、製造後の支払いとなっている場合、そこで適切な中間金の支払いがなければテストに入ることは不可能となります。

中間金だけではなく、先ほどご紹介し着手金や前払いも例外ではありません。全てにおいて、最も重要となるのは「契約書にあるかどうか」という点です。システム開発ではこの契約書が非常に強力な存在となりますので、どんな些細な事であっても、細かく明記することが重要と言えるでしょう。支払いに関するトラブルは非常に多くありますが、そのほとんどはこの契約書の作成が不十分であってり、双方の認識の違いが多くありますので、回避のためにも契約書の作成に注意して進めていきましょう。

費用は主に「人件費」

システム開発における費用は、その規模により数百万円以上かかるという事は珍しくありません。その内訳として、主となっているのは人件費です。システム開発はエンジニアが1人で行うというものではありません。SEやPG、PMなど、様々な担当者がチームを組み行っていくものです。そのため、システム開発ではこの人件費が主な費用となり、大規模なプロジェクトになればなるほど人数も多くなるため、必然的に費用も高額となっていきます。

上記が開発者・システムエンジニア・プログラマーの主な単価の相場となります。もちろんこれ以上の価格、これよりも低くなるという事は十分あり得ます。また、費用の内訳には設備費も忘れてはいけません。1つはシステム開発をするための設備費用、もう1つがシステムを動かすための費用となります。

開発するためのパソコンがない場合はリースをしなければいけません。さらに、開発するためのスペースがなければオフィスを借りるという事も必要でしょう。また、自前でサーバを用意するならその費用も掛かります。人件費のみではなく、こうした設備費にもしっかりと目を向けておきましょう。

「人月単価が高い」=「質が高い」は間違い

先ほどの相場一覧のように、レベルや業種により一般的な単価は異なります。数十万円以上の差がありますが、スキルの高さと単価の高さが必ずしも比例するという事ではありません。システム開発を依頼する際は、大手の開発会社を中心として子会社や委託会社などに依頼するケースが多くあります。このような場合、自社の利益幅を確保するためにあらかじめ高めの人月単価を設定しているという事は珍しくありません。

そのため、費用が高いからシステムは質のいいものが出来るという考えは間違いと言えます。また、大手だから安心、名前の知られている企業であれば心配ないと安易に発注先を決めてしまうと、同じクオリティなのに費用のみが高額になってしまうという事もあるでしょう。

また、企業規模が大きければ大きいほどに間接費が高くなります。そのため、システム開発費用をなるべく抑えて発注をしたいという場合には、大手の開発会社ではなく、あえて中小規模の開発会社へ依頼を行うというのも1つの手法と言えます。

システム開発・主となる支払い方法

システム開発における費用の支払い方法は、一括払い、分割払い、マイルストーン払いが主となります。一括払いについては特に説明する必要はないでしょう。簡単にまとめると、システムの開発が行われ検収に合格した後に費用を一括で支払うという方法となります。では、分割払いやマイルストーン払いとは具体的にどのような支払い方法となるのかについて、詳しくご紹介致します。

マイルストーン払い

そもそもマイルストーンとは、プロジェクト完遂に重要となる中間地点の事を指します。1つのプロジェクトのマイルストーンは1つだけという訳ではありません。例えば、企画書の決定までがマイルストーン、要件定義まで行けばそれが次のマイルストーンなど、プロジェクトを進めるにあたり重要となる要所をマイルストーンとして設定する必要があります。スケジュール設定と混同されがちですが、マイルストーンはスケジュールの中における工程ごとの区切りと考えておきましょう。

マイルストーン払いとは、要はこの重要工程ごとに設定されたマイルストーンごとの分割払いという事になります。プロジェクトを作業工程ごとに設定し、その工程が完了する事で報酬の支払いが発生します。支払いが完了したらその次のマイルストーンまでの作業を行い、完了後また支払いが発生する。この流れがマイルストーン払いの形となります。要約すると、マイルストーン払いは工程ごとにそれぞれの予算を立て、検収が済んだ時点でその工程分の支払いを行うということです。

分割払い

システム開発における分割払いとは、着手金・中間費・後払いの3段階で行われるという事が多くあります。分割払いは、上記でご紹介したマイルストーン張りと混同されがちの支払い方法です。マイルストーン払いも分割払いも簡単に言えば同じような支払い方法と言えますが、設定された工程ごとの支払いとなるか、工程は関係なく、開発全体的な分割となるかという点が大きな違いとなります。

先に説明したように、工程ごとに設定されたマイルストーンそれぞれに支払いが生じます。しかし、分割払いは工程は関係なく、先ほどお話ししたような着手金、中間金、完成後の支払いと、大きく区切られた支払い方法になります。契約によっては分割回数を更に多くしているという事もありますので、一概にこの流れが正しいという事は言えませんが、マイルストーンのように工程ごとの支払いとは異なるという事は頭に入れておきましょう。

安く抑えるためのポイント

「システム開発の費用はなるべく安く抑えたい。でも質は下げたくない。」

開発依頼を行う場合、誰でもこのような考えを持つでしょう。なるべく安くいいものを得たいというのは当然の事です。しかし、システム開発の費用はその多くが人件費になりますので、どうすれば安くできるのか分からないという方は多くいるでしょう。無理に人員を削減してしまえばその分質が下がってしまいますし、だからと言って人員を減らさずそのままで行えば開発費用は安くならないでしょう。しかし、費用を抑えつつ質を保つという事は不可能ではありません。そのためには何をすべきか、どこに注意すべきかなどの3つのポイントをご紹介致します。

具体的イメージを伝える

システム開発では、どのような機能が欲しいのか、どんなアウトプットが必要なのかなど、具体的なイメージがない状態で発注依頼を行ってしまう場合、完成後になってからこうすればよかった、他システムの方がいいなどといった多くの不満が生じてしまいます。また、要求内容が曖昧になってしまうと、修正や再開発、工数の追加などが多く発生しますが、その場合は多くが追加費用が発生してしまいますので、コストが大幅にプラスされてしまいますし、かなりの時間もかかってしまいます。

そのため、まずは具体的なイメージを明確にしておくようにして下さい。「顧客システムが欲しい」「受発注の管理システムを作ってほしい」などと言ったざっくりとした要望ではなく、「人的ミスが多いため、チェックの作業にかかる時間やコストを削減する事が可能な受発注管理システムを依頼したい」「Webからの受注強化するために、オンラインとオフラインでのマーケティングデータを全社通して統合できるシステム構築をしたいといったレベルまで落とし込めるのが理想的です。

使用年数の想定

初期段階でシステムの使用年数を想定するのは簡単ではないでしょう。しかし、現実問題、使用年数の短いシステムに多額の費用をかけるのは得策とは言えません。特に、規模が大きいシステム開発の場合では多くの機能などを組み込んでいるため、トラブルも多く発生してしまいますので、保守費用や運用費用に想定以上のコストが必要になってしまうという事もあります。

さらに、現状のように市場変化が激しい環境下では、長期使用を前提としていても、短期間で刷新が必要となることもあるでしょう。システムの使用年数や投資回収期間を想定すること、その際に盛り込むべき機能や要素をしっかりと絞り込む事視点を持ちながらすすめていくことが重要と言えるでしょう。

すべてのシステム化を一気に行わない

企業として抱えている課題を解決させるために、あれもこれもとシステム開発依頼を行うのはやめましょう。現状の業務フローのままでシステムによる改善が出来るのか、業務フローの見直しが必要なのかを判断してください。

例えば、今の業務フローのままで、ネックとなっている人力作業をシステム化するという場合、基本的には一部門のみの対応で済むためけっこ測定、システム化は容易に行えます。

ですが、業務フローを見直したことにより改善が可能な場合は、わざわざ高いコストをかけて開発を行う必要はないでしょう。いわゆるBPR【ビジネスプロセスリエンジニアリング】であり、企業のトップ経営陣をも巻き込み全社プロジェクトとなるケースも少なくありません。システム開発の費用を抑えるだけではなく、構築対象を明確にすることでプロジェクトそのものも成功しやすくなります。

ASPやパッケージの利用

システム開発は、一般的な業務形態を想定して作られているパッケージが存在していますが、会社や業務に合わせてオリジナルで作るフルスクラッチというものもあります。当然、全てがオリジナルになるよりも既存パッケージの方がコストは安く済むでしょう。

また、ネットを通じてパッケージに搭載されている機能を提供してくれるASＰというものもあり、こちらも費用を抑えるために活用できるでしょう。しかし、これらはコストが抑えられる反面一般的な機能しか搭載していないという点があります。

そのため、全てのシステム化の構築に適しているという事ではありません。パッケージの場合、もちろんカスタマイズを行うことも出来ます。しかしその分費用はかさんでしまいますので注意しておきましょう。細かなカスタマイズならともかく、大幅なカスタマイズはなるべく避けるようにし、パッケージそのままを活用する事がコストを抑えるポイントになります。

スムーズな支払いのカギは「契約書」

システム開発では支払いに関して実に様々なことが決められます。タイミングや金額はもちろんですが、他経費についての事やもしも損害賠償が発生した時のことなど、詳しく記載しておかなければいけません。いらぬ争いを避け、スムーズな支払いが行えるようにするためには契約書がカギとなります。具体的に、支払いや金額についてどのような記載が重要なのか、どんな内容となるのかについてご紹介致します。

検収条件

検収条件とは、本記事同等でお伝えした検収合格にとって欠かせない条件となります。システム開発では、完成したシステムを納品し、一定期間検収を行うのが一般的となっています。この研修にごうっくする事で作業は全て完了という形になるため、この合格に関する項目はあらかじめ双方で細かく取り決めておくようにしましょう。検収条件では、検収期間だけではなく、合格条件の記載も重要です。

検収期間

その名の通り検収が行われる期間です。システムの規模や複雑さにより期間は大きく異なります。一般的にはおよそ1～2週間程度が検収期間として多く設定されていますが、中には1か月を超える期間で契約書に記載されているという事もあります。双方で検収期間の長さについて、意見の食い違いや認識のずれがないようにしておきましょう。もしも1か月や2か月など長い検収期間を設定する場合、なぜここまでの長さになるのかを明確に説明する必要があります。

合格条件

こちらもそのままの意味で、合格するための条件を指します。システム開発では、発注者側が合格かどうかを判断しますが、個々が契約書上で曖昧になっており、極端に言ってしまえば発注者側の都合で不合格に出来るような都合のいい記載がある場合があります。中でも、「発注側が満足できる質でなければ不合格になる」といった内容がよく見られますが、こういった曖昧で都合のいい内容では会社の信頼度は下がり、その後の関係性に大きく影響を及ぼします。

また、受注側も、合格するかどうかわからないシステムに労力を注ぐようなことはしたくないというのが本音でしょう。合格条件に関しては、客観的検証が行えるようなものを定め、受注側、発注側どちらにとっても不都合のないようにしなければいけません。合格条件は支払いの時期に直接関係する重要な項目となりますので、曖昧な表現をしないようにし、双方の認識の違いの内容に細かく打ち合わせを行うようにしましょう。

支払いのタイミングと方法

システムを依頼する際に発生する報酬はどのような方法で支払いが行われるのか、そのタイミングはいつになるのかなどを細かく記載を行います。可能であれば、日付を記載することが望ましいでしょう。

• 開発スタート日
• 納品期限
• 検収期間
• 合否決定日
• 支払い日

上記のように、それぞれの日付を明記しておくようにすると、後々のいらぬトラブルを避けることが出来ます。また、支払い方法も重要ポイントとなります。当然ですが、支払い方法が明記されていない契約書と言うのはあり得ません。本記事でご紹介したように、請負契約であれば原則として後払いが一般的です。ですが、だからといって契約書に書かなくてもいいという事では決してありません。

むしろ一般的な後払いであるからこそ、その旨をしっかりと明記し、他の支払い補法ではないという事を強調することが重要です。前払い、中間金、マイルストーン払いなどに関しても、それぞれ細かくタイミングを明記するようにしなければいけません。システム開発の支払いは、実に多くのトラブルの元凶となっています。

その他の経費

システム開発にかかる費用は、作業に関わるもののみではありません。打ち合わせやミーティングのための交通費、縁プであれば宿泊費なども発生します。こうした費用についての記載もしっかりと行うようにしましょう。基本的には報酬とは別の請求をするのが一般的ではありますが、契約内容などによってはその他の費用などについても報酬にすべて含まれるという事もあります。

また、全てにおいての支払いを負担するのか、負担金額の上限を決めるのかなどについてもしっかりと双方で取り決めておきましょう。開発費用だけではなく、こうした費用に関してもトラブルの原因となることがあります。金銭面の契約内容はっと得小さく細かなものでも放置することなく適切な内容を明記するようにして下さい。

損害賠償

システム開発は全て滞りなく完了するものばかりではありません。多少のトラブルや修正などは多くあるでしょう。しかし、中には損害賠償の請求などという大きなトラブルになる事もあります。損害賠償請求は、発注側が受注側に請求を出すという事がほとんどと思われがちですが、発注側が請求されるというケースも珍しくはありません。そのため、「損害賠償に関する項目は双方どちらにとっても重要と言えるでしょう。

損害賠償請求トラブルが契約書内容で解決できない場合、訴訟まで発展してしまうという事もあります。契約書に記載する損害賠償に関する項目としては、責任の所在やその範囲、期間、金額の制限などが主となります。特に金額の制限などについては、無制限に賠償請求をされてしまうというリスクを回避する事になりますので、しっかりと明記しておきましょう。

システム開発の支払い・トラブル事例

「システム開発は支払いに関するトラブルが多い」

「支払いトラブルによって裁判になったこともたくさんある」

こうしたざっくりとした情報は多くありますが、実際どのようなトラブルがあったのか、どんな裁判になりどのような判決が出たのかなどと言う詳しい内容までは知らないという方は少なくありません。そこで、ここでは実際にあったシステム開発の支払いトラブルについてご紹介致します。

ケース1：完成後の不具合により支払い拒否となり損害賠償請求

石材の加工や販売を事業としている発注側が、システム開発会社に販売管理システムの開発を一括請負契約で依頼しました。開発が完了し納品されたシステムを稼働させたところ、不具合の発生があり処理速度の遅く使用が出来ないという連絡をしましたが、開発会社側は不具合に関して一切認めず、補修作業行わなかったために発注側企業は開発費用の支払いを拒否しました。

開発会社は、加勢したシステムを納品したにもかかわらず支払いがないという事で裁判を起こし、発注会社を訴えました。発受注側の請求内容は損害賠償1億1千万円の請求でした。その際、発注会社は反訴し、システムの不具合を原因とした契約解除、前払い金1,000万円の返還と損害賠償1億3選万円の請求を求めました。

裁判所は、システムの完成はしているが補修が一切なく、重大な不具合であるために契約解除の原因として妥当と判断。開発会社側の請求を棄却し、発注会社側の請求の一部を容認しました。その結果、システム開発会社は前払い金1,000万円の返還、500万円の損害賠償を支払うように命じられました。

ケース2：納期遅れと追加請求トラブル

発注企業は大手旅行代理店で、宿泊予約などが出来るHRシステムの再構築を依頼しました。しかし、スケジュールが大幅に遅延してしまい、プロジェクトや人員体制の見直しを行ったものの当初の予算より大幅にコストが掛かってしまうという事態に陥り巻いた。さらに、開発会社から実に1年以上もの稼働時期の延伸を提案されたために、発注側は契約解除を行いました。

その後、プロジェクト失敗の責任、開発費用の支払いに関する話し合いを長く続けましたが結局解決させることは出来ず、最終的に裁判に判決が委ねられました。裁判では、遅延の原因がどちら側にあるのかが争点となり、およそ3年余りの長い裁判の結果、双方請求内容を放棄し裁判費用の負担をそれぞれが行うという形で和解しました。今回のケースでは、裁判が長くなりすぎたためにこれ以上話し合いを行っても時間とお金がただ消えていくだけだという判断の元、双方で和解という道を選んだとされています。

まとめ

システム開発は特に重要なのが報酬支払です。トラブルとなる大きな要因の1つでもありますし、発注側も受注側も余計なコストはかけず、負担を最小限に抑えて仕事を行いたいという気持ちは同じでしょう。そのため、契約書には支払いのタイミング、方法やその他の細かな内容まで全て詳細に記す必要があります。

裁判ともなれば裁判費用や損害賠償など、さらに大きな金額が失われてしまうでしょう。こうしたリスクを回避するためには、支払い内容について契約書にしっかりと明記し、お互いの認識のずれをなくすことが重要です。

• 契約形態による報酬支払いの違い
• 支払い方法によるタイミングの違い
• トラブルが起きた際の損害賠償の金額条件

こうした上記の内容は特に大切な項目と言えます。スムーズな開発を行い、事業を円滑に進めていくためにも、開発前にしっかりと確認を行い、未然に防げるトラブルに関しては徹底した準備を行っておくようにしましょう。