EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

その契約、請負ですか?準委任ですか?

edited by Operation Online   2018/05/31 06:00

 しかし実際の開発では、この二つの区別は非常に曖昧で、そもそも契約書にも「この契約は請負です」などとは明言されていないケースが多いのではないでしょうか。また、現実の姿と契約の形態が、実は違うということも度々あり、請負契約なのに、ベンダが見積の根拠として工数を出したり、進捗報告をこまめにユーザに出すことは珍しくありません。また、私自身の経験でも、準委任契約で、約束した時間を働いたところで、結局、未完成だったり、不具合があれば、ユーザが検収してくれないということは度々ありました。契約の形態と作業の実態が必ずしも一致しないのがIT開発というものなのかもしれません。

曖昧な契約は紛争の元

 いかに曖昧な契約であったとしても、ユーザが企図したITが予定の納期で収められ、ベンダが期待した費用を受け取ることができるなら問題は発生しません。契約の形態など、現場からすれば、どうでも良いことになってしまいます。ところが、私自身も裁判所で何度となく経験したのですが、発注したITがユーザの要件を満たさないとか、ベンダの工数が大幅に超過するなどしてプロジェクトが失敗に終わった場合には、その責任の所在を明らかにする上で、そもそもの契約が請負であったのか、準委任であったのかということがクローズアップされます。

 「これは準委任で、ウチは約束した時間、働いたのだから費用を払え」とベンダが訴えるのに対して、「これは請負だ。モノが出来上がっていない以上、金なんか払わない」とユーザが応酬するのを、私自身、何度となく裁判所で見てきました。

 では、そもそも、この2つの区別をどのように付けるのか、裁判所が判断した例をご紹介したいと思います。今、皆さんがベンダに頼んでいる(あるいはユーザから頼まれている) 作業は、果たして請負なのか、準委任なのか、この例は元請と下請の間の例ではありますが、ちょっと考えてみてください。

 << 請負契約か準委任契約かを裁判所が判断した例 >>

  (東京地方裁判所 平成28年4月20日判決より)

 あるソフトウェア開発会社(下請企業)が、元請企業から,無線LAN用のソフトウェアの開発を受託した。

 元請企業は下請企業に対してソフトウェアの開発計画書を提示し、下請企業は、これに従って、基本設計を行った上で、元請企業に対して見積書を提示した。当該見積書には,すでに実施した実績工数として42.24人月、今後の工数見積もりとして80.8人月,合計で123.04人月(約9500万円)が記載されていた。両社は、その後、複数回の交渉を経て、結局、ソフトウェアの開発一式の見積合計金額を7900万円(税抜)とすることで契約を締結した。

 いったん、ここで区切りましょう。この契約について、皆さんは、請負と準委任のどちらだとお考えでしょうか?元請企業から下請企業に対して開発計画書が提示されています。作業スケジュールや要員の工数を示しているわけですから準委任契約のようにも見えます。ところが、契約する対象物はソフトウェアの開発一式となっています。これだと、何人月の作業という風には受け取れないので、成果物をソフトウェアとしている請負に近い書き方にも思えます。

 実際、こういう曖昧な書き方をする見積書や契約書は多いのですが、それでも、開発自体がうまく行ってしまえば問題は顕在化しません。しかしこの開発は、そうではなかったようです。先を見てみましょう。

  (東京地方裁判所 平成28年4月20日判決より)

 本件ソフトウェア開発は一応完了したが、開発工数は当初計画通りには進まなかった。ソフトウェアの機能試験や総合試験で発生した不具合への対応の為、下請企業の作業は当初の予定の見積を超えた。このため下請側は、これらの作業に対する報酬として追加の約6300万円を請求した。

 しかし、元請企業は、この契約は請負であり不具合やテスト対応によるコストの増加分を払う理由がないとしてこれを拒否したため裁判にになった。

 読者の皆さんの中には、「不具合やそれに対応する工数まで請求するのか?」と下請企業の主張に首を傾げる方もいらっしゃるかもしれませんね。しかし準委任契約を厳密に解釈すれば、このような論も成り立ちます。もちろん、下請企業が、しかるべき能力の要員に作業をさせて、きちんと仕事をしていることが前提ではありますが、そもそもソフトウェアの開発には、ある程度の不具合はつきもので、本来、元請企業は、それも見込んだ上で開発計画を立てなければならないところ、この事件の計画には、そうした余裕がなく計画を逸脱した責任は元請企業が負うべきとするのが下請側の主張のようです。

 一方で、元請企業の主張は、この契約は、作り手が成果物の品質に責任を持つ請負なのだから、不具合によって工数が増加したとしても、それは下請企業が責任を持つべきとの論です。結局のところ、開発計画を元請が提示しながら、"成果物のソフトウェアの開発一式" としたこの契約がどちらであったのかということが、この裁判の行方を決めることとなったのです。

 では、裁判所は、この契約について、どこに着目をしてどのような判断をしたのでしょうか。判決の続きを見てみましょう。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心にITベンダ及びITユーザ企業に対するプロセス改善コンサルティング業務を行なう。現在は、東京地方裁判所でIT開発に係わる法的紛争の解決を支援する傍ら、それらに関する著述も行なっている。 おもな著書に、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』 日本実業出版社、『IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』。

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

All contents copyright © 2007-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5