まず、本件システムのプログラム開発に関する契約において、下請け企業が、その完成義務を負っていなかったのかどうかについて、検討する。
(中略)
そこで、証拠を見ると、下請け企業が(中略)契約において、本件プログラムの完成義務を負っていないことを認めることのできる証拠を見い出すことはできないのである。(確かに元請企業はいったん、支払いを行ってはいる)。しかし、この支払の性格は、約定によるものと見ることもできるが、(中略)主前渡金と見ることも十分可能であって、この支払のあったことのみで(下請け企業の)主張事実を認めることはできない。
裁判所は、本プロジェクトが派遣である証拠はないという消極的な理由で、下請け企業の主張を退けた。その上で、判決は以下のように続く。
書証を見ても、成立に争いのない(中略)工程表は、下請け企業が、(中略)プログラムを完成する義務を負っていることを前提として、その完成までのスケジュールを記載した趣旨のものであることが認められるのであるから、これによれば、逆に、下請け企業が契約上プログラムの完成義務を負っていたと認めることができるのである。
工程表、つまりスケジュールを能動的に作成したのが下請け企業なのだから、これは請負契約だというのが、裁判所の判断だった。
工程表は、下請け企業が自ら「この開発には、これくらいの日数を要する」と判断して書いたものである。
スケジュールを書くということは、要員の配置や作業項目の細分化、その順序やリスクも自ら検討した結果であり、また、作業をスケジュール通りに進める責任も負うことになる。つまり、プロジェクトの管理を、自ら責任を持って行うということだ。
裁判所はこの点を重く見て、本契約は請負であると判断した。請負か準委任、派遣かの判断材料は、成果物、納期の有無や要員の工数管理の他にも、プロジェクト管理責任を負うのが実質的にどちらなのかがあるということだ。
しかし、だ。本判決を他の派遣や準委任契約のプロジェクトに当てはめると、ベンダーはユーザー企業や元請会社に、不用意にスケジュールを書いて提出できないということになる。
派遣や準委任で仕事をしていても、プロジェクトの全体か一部のスケジュールを自ら作ることは、しばしばあることだ。ユーザー企業はシステム開発に精通しているわけではないので、例え準委任契約であっても、納期以外のマイルストーンやそこに至る作業をベンダーが判断して書かないと、実現性のないスケジュールに困窮することになってしまう。
私もかつて、自分たちがやる作業については、自分たちでスケジュールを書き、それが順守できるように日々の作業管理を行っていた。実際、そうしなければプロジェクトは回らないからだ。
そう考えると、果たして本判決が示す請負と派遣の切り分けポイントは、本当に現実的で妥当なものなのだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.