(2)設計業務と請負契約の問題点

 一般に〝物〟をつくる請負契約においては、発注者が仕様を示し、それに基づき受注者はその物を完成させることに専念する。すなわち請負といわれるものの典型例である。もち論、数ある取引のなかには、「こういう働きをするものを作ってください」といった機能だけを指示して、その仕様の決定をもすべて請け負わせることもあろうが、むしろ例外といえる。

 建築においては、注文者と工事請負人との間に設計者が入っている。工事請負人は設計者の作成した設計図に基づき工事だけに専念する。工事の施工段階に入ったときは、設計者は監理技師として工事用の詳細図を作成し、かつ設計書どおりの工事が行われているかどうかを監理する。

 この監理技師は注文書の代理人とされているので、建築工事においては注文者がすべての仕様を決定し工事請負人はそのとおりに工事だけをすればよいのである(ただし、近時において工事業者が設計・施工を一括して受注するケースが顕著になっているのも事実である)。

 この場合、設計については請負というよりも、むしろ委任のほうがなじみやすい性質をもっているといえる。なぜならば設計という業務は、工事業者が設計図をみて施工するように、具体的にどのようなものをつくるのか明確になっていないからだ。具体的にどのようなものをつくるのかが明らかになっていない以上、仕事の完成ということに対する判断が主観的になってしまう。

 このことは、コンピュータのシステム開発にあたってもいえる。システム開発委託契約の問題点として、契約締結時点においては、具体的にどのようなものをつくるか-最終的な詳細な仕様が決められないということがあげられる。契約締結時点においては、発注者より発注仕様が提供されるどころか、システム開発の必要性の判断というようなことから業務が始まることもある。

 また、どのようなものをつくるかということを決定すること自体が業務内容になることも多い。とりわけ最近のシステムインテグレーションサービス契約などはこの傾向が強い。

 このようなことからケースによっては、請負のように完成を約したとしても、契約締結時点においては、何が完成なのかが定まっていないわけである。そこで、このようなシステム開発契約においては、請負型の契約より委任型の契約のほうが、実情に合致すると考えられる。

 先にシステム開発契約は委任型にすべきであると述べたが、プログラムの作成だけを取り上げるならば委任型よりはむしろ請負型のほうが適しているといえる。しかし、システム設計という仕事は、どのようなものを開発したらよいのかを具体的に明らかにする仕事である。

 これを請負型にすると、なにが「完成」なのかが明らかになっていないにもかかわらず、仕事の「完成」を約するという問題が生じてくる。その結果として極論すれば、完成とは何かということについて、ユーザーの主観にゆだねられ、ユーザーの意図した結果が出るまで手直しが繰り返されるということも考えられる。

 請負型にするか、委任型にするかは営業政策上の問題を無視するわけにはいかないが、一つの方法として、上流工程を委任型とし、仕様が確定した以後を請負型の契約にするようなことも考えられる。

 

 

目次