【実例&解説】システム開発に関するトラブルと対処法について

今回は、前回に引き続いて、システム開発における留意点として、請負契約・準委任契約の場合にそれぞれ注意すべき条項、及び留意するべき下請法や偽装請負の問題、そして、実際に生じたトラブル事例と行っておくべきであった対処方法や解釈の指針となった契約条項について詳しく解説します。

 

◆システム開発における契約で注意すべき条項

【請負契約の場合】

①瑕疵担保責任について

請負契約の場合には、民法上瑕疵担保責任が認められていますが、瑕疵の定義にどこまで含めるのか、故意・過失を要するのか、瑕疵担保責任の追及可能な期間をいかに設定するのかなどを明確に定める必要があります。委託者としては、民法上の瑕疵担保責任よりも範囲が狭くなることは避けるべきでしょう。

②検収について

請負契約の場合には、検収の規定が設けられていることが一般的です。しかし、この検収という手続きは、法律上規定されているものではありません。「仕事の完成」を明確化するために契約法理上多く採用されているものです。

そのため、検収の手続きは、契約書の記載のみによるため、どのような方法を経て検収完了=仕事の完成となるかについてはよく考えて規定する必要があります。具体的には、検収完了の条件をいずれの当事者が定めるのか、検収期間を何日間とするのか、検収期間中の応答がなかった場合に合格とみなすか否かなどについて、自社及び当該システム開発の実態に即した規定にするようにしましょう。

 

【準委任契約の場合】

①業務の完了についての確認条項

準委任契約の場合には、業務の終了について、確認の規定が設けられていることが一般的です。これも、請負契約における検収と同様、法律上規定されている手続きではありませんので、何をもって確認完了とするのかについて明確に定める必要があります。受託者から提示される契約書の中には、委託者の確認を要することなく、業務の完了報告書の提出のみで確認完了とする契約書もありますので、委託する業務内容から、その規定で足りるのかを十分検討するようにしましょう。

【その他留意すべき条項】

①下請法の関係

情報成果物を業として提供している事業者が、その情報成果物の作成行為の全部または一部を委託する場合、例えば、アプリケーションをユーザーに提供することを業としている事業者が、そのアプリケーションの開発を委託する場合において、資本金要件を満たした場合には、下請法が適用されます。

下請法は、親事業者である委託者に対し、4つの義務と11の禁止事項を定めています。下請法は強行法規であり、下請事業者である受託者が下請法の規定を順守していない条項が含まれる契約書の締結に同意していても、委託者の義務及び禁止事項は変わりません。

4つの義務、11の禁止事項のうちでも、システム開発に当たって特に指摘されることが多いのは、記載事項が充足されている発注書面の交付義務、支払期日を受領日から60日以内で定める義務、下請代金の支払遅延の禁止、下請代金の発注後減額の禁止、不当な給付内容の変更・やり直し要請の禁止、等です。下請法について、適用の可能性があるか否かは、公正取引委員会のパンフレットなどを参照しながら、きちんと確認して契約書にも反映させるようにしましょう。

②偽装請負について

契約書上の定めのみによって判断されるものではありませんが、システム開発契約において留意しなければならないものの一つとして、偽装請負の問題があります。システム開発においては、自社のエンジニアを委託者の事業所に常駐させる形態が見受けられますが、このような形態で委託する場合は、特に偽装請負とならないように対応することが必要不可欠です。

契約書上は、労働者派遣に該当せず、指揮命令権が受託者にあること、受託者においてエンジニアの使用者としての責任・法律上の義務をすべて履行することなどを規定することになるでしょう。また、実務上も、指揮命令を直接行わないように連絡系統を明確にする、委託会社の従業員と受託会社の社員の取り扱いを分けるために執務室を別にする、従業員用とは異なるネックストラップ付の入館証を交付し管理するなどの対応が必要です。

 

◆実際に生じたトラブル事例

ここからは、実際に生じたトラブル案件をもとに、実務上及び契約上どのような対応が必要だったのかについてみていきます。

・納期はすぐだから契約書無しで取り掛かってくれ・・・【無契約案件の事例】

B社はA社の担当者から、アプリ開発に関する業務委託の依頼を受けました。ただし、アプリのリリース日がせまっていて、短納期で仕上げてもらわないと困ること、さらに、A社の社内決裁プロセスは時間がかかること、まだ決裁も降りていないが、案件自体は上に報告しており必ず通るから安心してほしい、決裁が下りていないことからまだ契約書は締結できないが大丈夫だ、ということを繰り返し述べました。

B社は、A社担当者の話に不安を覚えましたが、短納期であることを加味した高額の見積価額を提示しこれで問題ないといわれたため、案件を受託することとして、アプリ開発に着手しました。

ところが、アプリも完成間近となったところで、担当者から決裁が下りなかった、今までの話はなかったことにしてほしいと述べられてしまいました。

一番望ましいのは、先方と契約書を締結した上で業務に着手することですが、そのように進めることができない(本件のように決裁の都合や、契約書の文言の折り合いがつかない場合もあると思います。)場合に、受託者側としてはどのような手続きを踏んでいれば、精算(出来高分の報酬請求及び中途解約による損害賠償)を請求することができるのでしょうか。

まず、本件ではA社とB社との間で契約書が締結されておらず、アプリ開発の契約が成立しているかが問題となります。民法上、契約書の締結は必ずしも契約成立の条件ではなく、口頭の合意であっても成立していることになりますが、裁判の場になると、書面が無いと合意の成否についての立証が難しくなります。先方の担当者から契約書の締結が難しいといわれた場合でも、「内示書」等の形式で会社からの依頼であることを証明する一筆をもらうようにしましょう。また、内示書等にはキャンセルする場合の精算条項も併せて記載しておくことで、当該書面に基づく精算を要求することが容易になります。

 

・ベンダーはプロなんだから・・・【お任せ案件の事例】

 案件がどうしても欲しかったシステム開発ベンダーであるB社の営業担当者は、ソフトウェア開発のプロである弊社が中心になってシステム開発を行います、何も心配せずにお任せください!と提案書や打合せで述べるなど、A社(委託者)に対して積極的に営業を行いました。その甲斐もあってB社はA社から案件を受注することができ、システム開発を進めていくことになりました。

その後、システム開発は順調に進んでいたように見えましたが、打合せの節々でB社の担当者からA社の担当者に対して、プロなんだからお任せするよ!というような発言が見受けられました。

A社は、B社担当者やB社全体の任せてしまえばいいものが出来上がるという雰囲気に若干の不安を覚えながらも、要件定義フェーズ、設計フェーズと業務を進め、フェーズごとに報酬を受領してきました。

ところが、設計フェーズが終了する頃になって、B社担当者から思っていたものと違う、使えないものを進めて作成したのはA社なのだから、要件定義からすべてやり直してほしい、やり直しが難しいのであれば、今まで支払った報酬を返還してほしいとの申し入れがなされてしまいました。

このような場合、受託者側はどのような契約を結んでいれば、報酬の返還及びやり直しを拒否することができるのでしょうか。まず、法的な構成としては、一括請負形式ではなく準委任形式で、かつフェーズごと(もしくはより短期間)の契約を締結していることが望ましいでしょう。

更に、契約形態にかかわらず、要件定義書の確定・設計書の確定に関する手続きを契約書上で定め、それを実行していることが重要になります。確定の手続きとしては、責任者の選任方法、責任者が行う確定の方法(双方の捺印を要するのか、送付後一定期間をもってみなし承認とするのか等)を規定することとなります。そして、実務上も契約書に記載された手続きを経ていれば、委託者は各フェーズの業務の終了を委託者側において確定しており、受託者は適切に業務を遂行したと評価される可能性が高く、報酬の返還及びやり直しの拒否が認められやすいと考えられます。

また、実務上の対応という観点からは、営業担当者が案件獲得のために行ったセールストークが過剰なものとなっており、委託者に過度な期待を持たせる結果となった点、及び、受託者の業務遂行担当者が先方の期待が過度なものであることを認識しながらも、要件定義や(外部)設計の確定者が委託者であることを明確に示さなかった点にも是正の余地があったといえるでしょう。

 

・こんなに工数がかかるとは思わなかった・・・【追加工数拒否案件の事例】

システム開発の受託に当たり、システム開発ベンダーB社は、委託者であるA社に対して、受託前段階で簡易なヒアリングを行い、ヒアリングをもとにした範囲のシステム開発見積書を作成し、これに基づいてA社B社間で契約が締結されました。

しかし、開発が進むにつれて、当初ヒアリングを行った時点で見積もっていた以上に、追加で開発をする機能が増え、工数が膨らむ結果となりました。

B社は、当該追加でかかった工数分の見積りを作成し、追加で支払って欲しい旨A社に申し入れましたが、A社にこれを拒否されてしまいました。

 

受託者から委託者に対する追加報酬の請求は認められるのでしょうか。

この点、追加開発を行わなければならなくなった原因は以下のパターンが考えられます。

①A社の要望により、スコープ外の追加機能を新規に開発対象とした場合

②A社の要望により、スコープ内の機能の仕様を変更したことにより工数が増加した場合

③当初想定していたスコープの範囲内であったが、B社の能力不足等により追加工数が必要となった場合

上記の原因のうち、③については、受託者に帰責性のある事由ですので、基本的に追加報酬の請求はできないと考えるべきです。ただし、当初の契約書の内容として時間単価に基づいて報酬額を決定する旨を定めている場合などには、かかった工数を全て請求することができる可能性もあります。

①及び②の場合には、基本的にはA社の要望による追加・変更であり、報酬の追加請求が可能と考えられます。しかし、当初の契約書に、業務範囲・スコープの内外をわかるように記載していなかった場合には、当初契約書の範囲内だと主張され、追加報酬を請求することができなくなってしまうおそれがあります。

当初の契約書の中に、システム図、提案書、開発対象となる要件が列挙された要件定義書を明示するなどして開発範囲を明確にするようにしましょう。間違っても、「●●システム開発一式」のような漠然とした記載の身にするのは避けましょう。

 

◆安易なシステム開発の受発注はトラブルリスクを多く孕む

上記でみたように、システム開発契約においては、しっかりと契約書を交わすことのみならず、契約書の審査検討をすることが非常に重要となります。

AI-CONは契約書をアップするだけで内容をチェックしてもらえるだけでなく、修正を求める場合には修正方法も画面上で教えてもらえるツールです。オプションで相手方との交渉のときに使えるコメントも利用できるようになったので、ぜひ一度お試しください。

 

この記事が気に入ったらいいね!をお願いします