しかし実際の開発では、この二つの区別は非常に曖昧で、そもそも契約書にも「この契約は請負です」などとは明言されていないケースが多いのではないでしょうか。また、現実の姿と契約の形態が、実は違うということも度々あり、請負契約なのに、ベンダが見積の根拠として工数を出したり、進捗報告をこまめにユーザに出すことは珍しくありません。また、私自身の経験でも、準委任契約で、約束した時間を働いたところで、結局、未完成だったり、不具合があれば、ユーザが検収してくれないということは度々ありました。契約の形態と作業の実態が必ずしも一致しないのがIT開発というものなのかもしれません。
曖昧な契約は紛争の元
いかに曖昧な契約であったとしても、ユーザが企図したITが予定の納期で収められ、ベンダが期待した費用を受け取ることができるなら問題は発生しません。契約の形態など、現場からすれば、どうでも良いことになってしまいます。ところが、私自身も裁判所で何度となく経験したのですが、発注したITがユーザの要件を満たさないとか、ベンダの工数が大幅に超過するなどしてプロジェクトが失敗に終わった場合には、その責任の所在を明らかにする上で、そもそもの契約が請負であったのか、準委任であったのかということがクローズアップされます。
「これは準委任で、ウチは約束した時間、働いたのだから費用を払え」とベンダが訴えるのに対して、「これは請負だ。モノが出来上がっていない以上、金なんか払わない」とユーザが応酬するのを、私自身、何度となく裁判所で見てきました。
では、そもそも、この2つの区別をどのように付けるのか、裁判所が判断した例をご紹介したいと思います。今、皆さんがベンダに頼んでいる(あるいはユーザから頼まれている) 作業は、果たして請負なのか、準委任なのか、この例は元請と下請の間の例ではありますが、ちょっと考えてみてください。
<< 請負契約か準委任契約かを裁判所が判断した例 >>
(東京地方裁判所 平成28年4月20日判決より)
あるソフトウェア開発会社(下請企業)が、元請企業から，無線LAN用のソフトウェアの開発を受託した。
元請企業は下請企業に対してソフトウェアの開発計画書を提示し、下請企業は、これに従って、基本設計を行った上で、元請企業に対して見積書を提示した。当該見積書には，すでに実施した実績工数として42.24人月、今後の工数見積もりとして80.8人月，合計で123.04人月(約9500万円)が記載されていた。両社は、その後、複数回の交渉を経て、結局、ソフトウェアの開発一式の見積合計金額を7900万円（税抜）とすることで契約を締結した。
いったん、ここで区切りましょう。この契約について、皆さんは、請負と準委任のどちらだとお考えでしょうか？元請企業から下請企業に対して開発計画書が提示されています。作業スケジュールや要員の工数を示しているわけですから準委任契約のようにも見えます。ところが、契約する対象物はソフトウェアの開発一式となっています。これだと、何人月の作業という風には受け取れないので、成果物をソフトウェアとしている請負に近い書き方にも思えます。
実際、こういう曖昧な書き方をする見積書や契約書は多いのですが、それでも、開発自体がうまく行ってしまえば問題は顕在化しません。しかしこの開発は、そうではなかったようです。先を見てみましょう。
(東京地方裁判所 平成28年4月20日判決より)
本件ソフトウェア開発は一応完了したが、開発工数は当初計画通りには進まなかった。ソフトウェアの機能試験や総合試験で発生した不具合への対応の為、下請企業の作業は当初の予定の見積を超えた。このため下請側は、これらの作業に対する報酬として追加の約6300万円を請求した。
しかし、元請企業は、この契約は請負であり不具合やテスト対応によるコストの増加分を払う理由がないとしてこれを拒否したため裁判にになった。
読者の皆さんの中には、「不具合やそれに対応する工数まで請求するのか？」と下請企業の主張に首を傾げる方もいらっしゃるかもしれませんね。しかし準委任契約を厳密に解釈すれば、このような論も成り立ちます。もちろん、下請企業が、しかるべき能力の要員に作業をさせて、きちんと仕事をしていることが前提ではありますが、そもそもソフトウェアの開発には、ある程度の不具合はつきもので、本来、元請企業は、それも見込んだ上で開発計画を立てなければならないところ、この事件の計画には、そうした余裕がなく計画を逸脱した責任は元請企業が負うべきとするのが下請側の主張のようです。
一方で、元請企業の主張は、この契約は、作り手が成果物の品質に責任を持つ請負なのだから、不具合によって工数が増加したとしても、それは下請企業が責任を持つべきとの論です。結局のところ、開発計画を元請が提示しながら、"成果物のソフトウェアの開発一式" としたこの契約がどちらであったのかということが、この裁判の行方を決めることとなったのです。
では、裁判所は、この契約について、どこに着目をしてどのような判断をしたのでしょうか。判決の続きを見てみましょう。
請負と準委任の判断基準
(東京地方裁判所 平成28年4月20日判決より)
下請企業は、本件契約は、作業量に応じた報酬を支払う準委任契約であると主張する。しかし、本件契約書や下請企業が提出した見積書には、単価や工数が記載されておらず、見積書には「無線ＬＡＮルータ開発 一式」と記載され、本件契約に係る作業期間中も、下請企業から元請企業に対し、作業時間の報告等もされていないことからすると、単に作業量によって報酬を決める準委任契約であるとは認められない。
本件契約においては、報酬の支払が、成果物の検査合格という成果物の完成後とされ、下請企業は成果物に関する瑕疵担保責任を負うこと、下請企業が本件ソフトウェア開発により作成した成果物の著作権を有し、元請企業による業務委託料の完済により、同著作権が元請企業に移転するものと定められ、まず下請企業が本件ソフトウェア開発における成果物の所有権を取得するとされていること等からすると、本件契約は、元請企業から受託された本件ソフトウェア開発における業務の完成を目的とする請負契約であったものと認めるのが相当である。
結果はご覧の通り、契約が請負であり、元請企業は下請企業に対して、不具合とそのテストに掛かった工数分の費用を払う必要はないとの判断が出ました。
ここで裁判所が判断の拠りどころとした事柄は以下の点です。
- この契約にあたって提示された見積書に単価と工数の記載がなかった。
- 報酬の支払いが成果物の検収合格後とされていた。
- 開発したソフトウェアの著作権が原始的には下請のものとされていた。
こうして並べてみると、当然と言えば当然なことが並んでいます。しかし、こうした当然な事柄について双方が十分に認識せず、成果物のお題目に「ソフトウェア開発一式」などと簡単すぎる言葉でお茶を濁し、しかも、元請やユーザが開発計画を提示してしまうのがIT開発に関わる契約の実態なのです。
この事件では、前述した３点の合わせ技で、請負と判断されましたが、他の紛争案件を見ると、これらについて明記していないものも散見され、この開発が本当にどちらなのかが、誰も分からないという例もあります。そうなると、裁判所ですら、その判断が分かれることとなりますし、それ以前に、債権債務関係のハッキリしない中での作業はもめ事の元になります。上記の点も含めて、IT開発の契約には、以下の点を明示していただきたいと思います。
- 作業の成果物は開発したソフトウェアであるのか作業の報告であるのか。(Yesなら請負、Noなら準委任)
- 成果物の瑕疵担保責任があるのか(Yesなら請負、Noなら準委任)
- 検収は成果物の検査合格後か予定された作業の終了後か(前者なら請負、後者なら準委任)
- 著作権はどちらに帰属するのか(受注者なら請負、発注者なら準委任)
- 作業進捗や工数消化の報告は契約上の行為か便宜的なものか(前者なら準委任、後者なら請負)
- 作り手の作業メンバの開示は契約上の行為か便宜的なものか(前者なら準委任、後者なら請負)
これらについて、明確にして合意しておけば、契約形態を巡って争うことはなく、双方の責任範囲も明確になることでしょう。こうしたことは、双方の法務部門任せになって、実際の作業を行っている担当者は無頓着なことが多いのですが、やはり自分の作業がどういう契約のもとで行われているかを知らないと、この事件のような紛争に巻き込まれてしまう危険も十分にあります。
なお、これらの請負と準委任の区別については、平成32年に予定される新民法の施行に従って若干の変更があります。その辺りについては、また別途お話ししたいと思います。(了)
