請負・準委任などIT契約の種類とポイント

システム会社との契約には基本類型が3タイプあります。依頼する側の企業としてどのような契約形態で依頼し、どの様に対応するべきかを知っておくことが重要です。

先々IT会社と揉めた時のことや費用なども考えて、どの様な場合にも請負契約を求めることが必ずしも良いとは言えませんので、その辺りの考え方をこちらではご紹介しています。

IT会社との契約類型

システム開発・導入を日本のSI企業や、コンサルティング会社などへ依頼する場合の契約には、日本の法律上、下記のような契約の基本的な類型があります。

準委任契約

一般的には、殆どのSI会社との契約がこの契約になっているかと思います。SI会社に都合が良い(完成責任がない)契約形態ですので、何も言わなければこの契約形態でSI会社は契約書を持ってくるものと思います。

この契約の特徴は下記のような点にあります。

受託者(SI会社)には仕事の完成義務がなく,瑕疵担保責任を負わない。善良な管理者としての注意義務(善管注意義務)を満たすように一生懸命やっていればよく、極端に言えば何も成果が上がっていなくても稼働提供した時間で請求出来る。

準委任契約の場合は専門家に対する信頼をベースとしていますので,原則として再委託は委任者の承諾が必要である、と言えると思います。

「委託者が,(法律行為以外の)事務を委託する受託者たるSIベンダは,善良な管理者の注意をもって委任事務を処理する義務を負う」(民法644条)と法律上はなっていますので、この部分に抵触しない限りSI会社側には落ち度はないことになります。

 

請負契約

正に、依頼したシステムの完成に責任を追う契約形態です。IT会社には都合が悪いので、特に大手SI会社では基本的にはこの契約は受けてくれない場合が多いかと思います。

また、SI会社にとってはリスクが大きいため、請負契約を求めると、リスク分を上乗せした見積り金額を持ってくる可能性が高いと思われます。従って、請負契約をして欲しい場合はRFP(提案依頼)を複数社に出して競争入札にすると考えておいたほうが良いかと思います。

 

要件を纏めていくようなフェーズはその完成の基準があいまいで、発注側が何をやりたいのかはっきりしない場合等、いつまでも終わらない可能性が高いのも問題です。よって、完成を請け負うことを求めると、かなりのリスク分を上乗せしてくると思います。

一般的には開発するシステムの要件がはっきり見えてから、その開発をしたらどの程度の工数が掛かるかを見積もることが出来る、開発工程に用いられることが多いかと思います。

この場合も、整理された要件を元に開発・コーディング部分だけを競争入札にするほうが良いかと思います。

この契約形態の特徴は下記のようなものです。

請負人が仕事を完成させ,注文者がそれに対して報酬を支払う契約請負人たるSIベンダは,契約の本質的義務として仕事の完成義務を負う(民法632条)

目的物に瑕疵があった場合は,瑕疵担保責任を負う(同法634条)引渡し後も,瑕疵がある場合には,修補義務,損害賠償義務が生じる。

契約書に定めがない場合には,原則として請負人の裁量で再委託できる(未完成の責任は請負人が負う)

と考えられます。また、瑕疵により契約の目的を達成できないときは、発注者は契約を解除できます。(完成割合に応じた費用を支払った上で)

仕事を完成させて引き渡す(契約書においては「検収合格」を条件としているケースが多い)ことにより報酬請求権が生じます。

 

派遣契約

派遣契約とは、一般的に皆さんがイメージされる派遣社員だと思って頂ければ大丈夫かと思います。その特徴は下記のようなものです。

当然、仕事の完成義務はないが、上記にもあるような善管注意義務はあります。

派遣先の指揮命令を受けて作業をします。よって、瑕疵担保責任はない、と思って良いかと思います。(あくまで指示を受けて作業を行う)労働者派遣法がその根拠となっている。

 

請負契約を常に意識する

実態がどうであった(と客観的に見える)かが重要

契約書に「準委任契約」又は「請負契約」と明記されていれば、基本的には、その契約形態で実施されたもの、として内容を判断されます。

但し、上記はあくまで、法律上の契約分類であって、訴訟になると、必ずしも上記のどの契約形態であったかではなく、その実態がどうであったかが問われます。

実際には請負契約と準委任契約の両方の性質を合わせ持つ

と考えておいたほうが無難です。

よって、SI会社にシステム開発を依頼する立場としては、準委任契約と書いてあったとしても、「相手のSI会社がITのプロとして責任を持って進めていた」のであって自社はITに関しては素人でる、と感じられるスタンス・コミュニケーションを心がけることが重要かと思います。

具体的には、あくまで、ITのプロとして扱い、準委任と明記されていたとしても、完成責任を負っていると認識させ、プロとしての成果を求める姿勢で常に接します。

コミュニケーションでは、下記にあるような用語は請負契約(完成責任)を連想させるものだと思います。

 

請負契約と取られ易い用語

◆ 一式

一式として見積・契約書に記載する記述が多くありますが、これは時間単位ではなく一式の完成を約束した契約だと見えます。

そこの何人の人が何時間・何日稼働するのか明記が無い以上、どう見ても準委任契約の契約形態には合わない表現です。

◆ ソフトウエア作成作業請負

正に、自ら請負と言っています。

◆ 納期

納期がある=完成物をその納期までに納入することを約束したように見えます。

◆ 開発完了書

準委任契約の場合は、完成を保証しませんので、その様なものはないのだと思います。あえて言うとすれば、稼働提供をした工数の報告書でしょうか。

◆ 検収

正に請負契約を連想させる用語です。完成を約束しているからこそ、その検収があるのです。

◆ 合否判定

こちらも同様でしょうか。完成を約束していないものに対して合否もないはず。

◆ 納品(納入)・成果物

準委任契約だとすれば、完成物の納品はないでしょう。

◆ 瑕疵

瑕疵とは、完成を約束した開発物に約束した通りの要件が含まれなかったり、その他の問題があった場合に責任を負うことです。

◆ 瑕疵担保(期間)

完成語に、問題が発見された場合に、それを保証する期間ですので、そもそも、完成を保証していなければ、その保証期間もないのだと思います。

また、注意点として、派遣契約以外では、労働者に直接作業指示をすると偽装請負とみなされてしまいますので、発注者は請負先である労働者の会社(監督者)に対して指図をして、その請負先が労働者に指図することになっています。

よって、このような行為を続けていると、請負契約をしたつもりでも、実際には発注元の指揮命令系統のもとプロジェクトが進んでいた、とみなされ完成責任や瑕疵担保責任を問えない可能性すらあると思われます。

※ もちろん私は弁護士資格を持っているわけではありませんので、あくまで、これまでのシステムコンサルティング経験に基づく、経験を元に一般の会社のIT部門の方々の参考になれば、と思い私見を記載しています。

法律の専門家によれば違った見解があるのかも知れませんが、実務上、後になって気付いても遅い面がありますので、参考にして頂ければと願っております。

 

 

 

 

 

関連記事

  1. IT開発は請負にしましょう【経産省モデル契約】

  2. IT 訴訟で注意すべき点、主張すべき事

  3. SES/タイム・アンド・マテリアルは日本の契約には無い

カテゴリー

人気の記事

  1. record-windows-operation-and-automate