IT・ベンチャーの企業法務

システム開発業務がユーザー都合で中断した場合への対処法とは

2019.07.27

2023.01.19

システム開発という業務は、通常長きにわたるプロジェクトというかたちをとる場合が多いものです。そこでもし、一度着手しかけたシステム開発に対し、ユーザー側から一方的に「そのシステムはもう不要だから作らなくて良い」などと言われてしまった場合、仕事を受けていたベンダー側からはなにができるのでしょうか。

本記事では、システム開発という契約のもつ特色を整理するとともに、その場合の対応策について解説していきます。

この記事の目次

ユーザー都合による中断について考えてみることの意義

システム開発という契約には、契約として見た場合にいくつか特色というべき点があります。ひとつは、その工期が通常長きにわたるものであり、プロジェクトをマネジメントする義務として、ベンダー側も大きな裁量とともに多大な義務を負っているという点です。ベンダー側が負っているプロジェクトマネジメント義務についての全体的な内容については、以下の記事にて詳しく解説しています。

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

また、もうひとつは、ユーザーもお客さんといえど、ベンダーの業務に協力する義務を広範に負っている点です。自社の内部で用いるシステムである以上、ベンダー側への「丸投げ」では済まされるものではありません。社内内部からも、ベンダーが専門性を発揮して業務にあたれるよう、適宜協力する義務があります。これについては、以下の記事にて詳しく解説を行っています。

システム開発の発注者であるユーザー側が負う協力義務とは

以上の内容をここで簡単にまとめると、ベンダーとユーザーの間には、システムを開発する「外部業者」と、報酬を支払う「お客さん」という対価関係もありつつ、また同時に、プロジェクトの達成という共通の目標に向かって協働すべき「仲間」とでもいうような側面もあります。こうした関係性の複雑さは、単なるオーダーメイドのスーツの仕立て屋さんなどには通常ないものであり、システム開発にまつわる契約の大きな特徴でもあります。システム開発にまつわる紛争はこうした関係の複雑さゆえに、一度もつれれば、両者の関係を法的にいかに整理すべきかという点で、なにかとややこしくこじれがちなのです。

ユーザー側が翻意して、いきなり「そのシステムは結局必要でなくなったから、もうこれ以上プロジェクトは進めなくて良い」などと言ってきた場合について、両者の権利・義務関係をどのように把握すべきかという問題について考えてみることは、ある意味、こうした複雑な契約関係を前に、法的思考を働かせるということの実例を提示するという意味合いをも持ちます。以下に、こうした場合を想定したうえで、その後に検討すべき事柄について整理していきます。

まずは解約を申し出てきた理由を整理

ベンダーからみて「ユーザーが一方的にプロジェクトを中断したいと言ってきた」という認識の事案についても、ユーザーとの間でもそうした認識が必ずしも共有できているとは限りません。一例をあげるなら、海外拠点に勤務する駐在員の人事を管理するシステムを開発するプロジェクトが立ち上がっていたところ、後に海外進出の計画そのものが取り下げられ、そうしたシステムの開発そのものが不要になったという事案を想定しましょう。たしかに、この説明だけをみれば、ユーザー側の一方的な翻意ともとれるでしょう。

しかし、もし、そうした決定に至った経緯として、ベンダー側にも、各工程の遅延などのプロジェクトマネジメントの義務違反の実態があり、開発そのものの進捗が難航していたことも、会社の方針変更の一因ともなっていたような場合であればどうでしょうか。

先述の通り、システム開発はベンダーもユーザーも多大な義務を負い合い、緊密に連携しながら進めていくものです。そうであるからには、中断したいと切り出したのがユーザーの側からであり、ベンダーがユーザーの自己都合の解約であると考えていたとしても、逆にベンダー側の帰責事由を指摘され、債務不履行に基づく解除や合意解約である旨などを主張し返されてしまう可能性があることを認識すべきなのです。

自己都合による解約であるのか、債務不履行に基づく解除であるのか、合意解約であるのかといった点の区別は、プロジェクトの進捗状況や、それまでの交渉の経緯等によって、事案ごとに個別に判断される傾向も強いものです。そのため、もしベンダーがユーザーの自己都合による解約であるという認識のもと事後処理を進めるのであれば、会議の議事録などでも、その旨明確に記録を残すようにし、後からこの点で争いとなることがないようにしておくことが重要になります。

次に報酬請求・損害賠償の根拠条文を確認

上記の点を踏まえたうえで、ユーザー側の自己都合の解約として話を進めていける場合には、次に、ベンダーからユーザーに対し、完成割合に応じた報酬の請求や、損害賠償の請求が可能か否かを検討していくことになります。

こうした場合に参照すべき条文は、契約型によって異なります。システム開発に関する契約は、大きく言って、請負契約と準委任契約に区別できるからです。

システム開発での請負契約と準委任契約の区別と違い

そして、準委任契約と請負契約の場合で、民法は、下記のような定めを置いています。

a.)準委任契約の場合
報酬請求：民法６４８条３項
委任が受任者の責めに帰することができない事由によって履行の中途で終了したときは、受任者は、既にした履行の割合に応じて報酬を請求することができる。
損害賠償請求：民法６５１条
１.委任は、各当事者がいつでもその解除をすることができる。
２.当事者の一方が相手方に不利な時期に委任の解除をしたときは、その当事者の一方は、相手方の損害を賠償しなければならない。ただし、やむを得ない事由があったときは、この限りでない。
b.)請負契約の場合
損害賠償請求：民法６４１条
請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる。

なお、民法６４１条に基づく損害賠償の範囲は、すでに支出した費用だけでなく、「契約を解除されていなければ得られた利益」も広範に含まれると考えられています。これは、注文者からみて不要となったにもかかわらず仕事の完成を法が強要するのは無意味なことであるため、そうした場合にはむしろ、同じだけの対価を支払うことを通じて受注者側の利益を保障するほうが合理的であるという考えを反映したものであるからです。

もっとも民法６４１条に基づく損害賠償に関しては、ベンダーとユーザー間での個別の契約において、損害賠償の対象外とされているような場合も少なくありません。そのような場合には、個別で交わされた当事者間の約束（＝契約）のほうが優越することとなり、こうした民法上の規定は及んでこなくなることが考えられるので、注意が必要です。

さらに出来高と損害の立証を進める

ユーザー側からの自己都合による解約の場合には、契約として多く見られるのは、出来高（すなわち完了部分）の委託料の請求と、損害賠償の請求ができると規定されているものです。そのため通常は、ベンダー側からは、損害賠償請求を行うために、出来高や損害についての立証を行うことが必要となってきます。

もっとも、こうした出来高つまりは完成割合の立証というのは、実際に行うとなると非常に骨の折れる作業となることも予想されるものです。なぜなら、どの作業項目がどの程度完了していたかなどについて、特に下請け業者が複数ある場合には、進捗確認のためのヒアリングなどを、いざ実際に行うとなれば相当な量となることが考えられるからです。さらには、そのヒアリング結果を裏付ける資料の作成や、ヒアリングの内容そのものの文書化といったことまで全て行うとなれば、手間は膨大なものになるでしょう。そうまでしても結局立証が不十分と言われてしまうリスクがあることになれば、立証の準備に割いた手間は徒労ともなりかねないなど、難点も多くみられます。

こうした点を踏まえた対策としては、事前の契約段階ではじめから、途中で解約する場合には解約時点までの日数で日割り計算とする旨を明記しておくなど、計算をシンプルに行えるようにするなどの工夫を行っておくといった対策も考えられます。また、出来高に対する請求が、立証に手間がかかることから考えると、出来高そのものに対する請求を断念し、「すでに出来た部分の開発に要した費用」に対して請求を行うといったやり方を検討していく方法も考えられます。社内での開発費用であれば、「工数×単価」という単純な計算式で簡単に割り出せる場合も少なくないからです。利益率が低いプロジェクトであれば特に、出来高ではなく費用ベースでの請求を優先することによって、債権回収のやりやすさを重視しながら損失補填を行うことが期待できるので、より現実的な救済措置となる場合が少なくないでしょう。　

逆にユーザー側から検討すべきことはなにか

ちなみに、自己都合での解約を切り出すユーザー側にも、事前に検討しておくべき点はあります。それは、ベンダーとの間で、支払うべき損害賠償額がだいたいいくらくらいになりそうかなど、概算金額を確認しておくということです。ここで「概算」といっているのは、おおよその目安をつけておくことでその後の交渉の流れに目処をつけておくためです（解約の意思表示そのものが遅れては本末転倒なので、正確な金額でなくても十分でしょう）。

確認した概算金額が不当に高いと判断できる場合には理由説明を求めるべきですが、支払い金額を抑えるために無茶な交渉を行おうとしたりすると、無意味な訴訟などが起きて事態がさらに紛糾する危険もあります。二者間のみでの交渉が難航しそうであれば、弁護士に相談することも一案となるでしょう。

なお、本記事では、システム開発に関する契約が成立していることを前提に解説を行ってきましたが、現実のシステム開発の場面では、「そもそも契約が有効に成立しているのか」が争いになるケースも少なくありません。これに関しては下記記事にて詳細に解説しています。