システム開発訴訟等のITトラブル、コーディングもできる弁護士に。準委任契約かという問題は、契約当事者間で定められていない事項があったとき、はじめて問題になるにすぎないといっても過言ではない。どの契約類型に該当するのかという点は、先に決めるものではなく、行う業務内容や役割分担によって自然と決まるべきものである。開発モデルによって、契約類型や契約において合意すべき事項は異なるのが通常である。同じ開発モデルであったとしても、ケースごとによって、契約類型や契約において合意すべき事項が異なる可能性がある。請負契約や委任契約も含め、いわゆる典型契約という13種類の契約類型が定められています。ある契約について、契約当事者間で定められていない事項があったとき、その契約がいずれかの典型契約に該当する場合には、その典型契約に適用される民法等の規定が、その契約を補充する形で適用されることとなります。ある契約について、契約当事者間で別途定めのある事項については、原則として、民法等の規定ではなく、契約当事者間で別途定めた内容が適用されることとなります。ある契約をする際、どのような内容の合意があればよいのか、どのような内容の合意をしておいた方がよいのかといったことを、何もないところから考えることは非常に難しいことですし、何よりも手間がかかります。そこで、典型契約は、日常的に用いられる典型的な契約に関するモデルを提示し、その契約がいずれの典型契約に該当するかによって、契約当事者間でしなければならない合意、しておいた方がよい合意の「道しるべ」という役割も果たしています。私が学生の頃、民法学の教授が「典型契約は契約のカタログである。」といった趣旨の発言をしていましたが、典型契約が「道しるべ」の役割を持つことを指すものといえます。他方で、民法の定める典型契約は、あくまで典型的な契約を定めたにすぎません。典型契約にはどうしても該当しない、非典型契約というものも存在しています。典型契約のいずれにも該当しない、非典型契約であると言われることがあります。ソフトウェア開発委託契約は非典型契約であると言われることもあります。請負契約や準委任契約であることを必ずしも決める必要がないという意味で、ソフトウェア開発委託契約が非典型契約であるということにも、一定の合理性があるものと考えられます。ソフトウェア開発委託契約の性質さて、ソフトウェア開発委託契約の契約の性質について、そもそも非典型契約であるというべきなのかもしれませんが、契約の性質が請負契約なのか、準委任契約なのかが問題とされることがやはり多いと思われます。請負契約は「ある仕事の完成を目的とする契約」であるのに対し、(準)委任契約は「ある者の事務処理を行うことを目的とする契約」です。要件定義段階における契約は、要件定義自体は通常ユーザが行うべき事項ですから、ベンダはその支援をするにすぎず、「ユーザの要件定義作成の支援という事務処理をベンダが行うことを目的とする契約」として、準委任契約になじむものと考えられます。他方、開発段階における契約は、(あるべき理想としては)仕様書が完成しており、ベンダがこれに基づいてソフトウェア開発を行うわけですから、完成させるべき仕事の内容も明らかですので、「ベンダによるソフトウェアの完成を目的とする契約」として、請負契約になじむものと考えられます。ところで、データ移行段階における契約は、当該プロジェクトにおいて、専らベンダが新システムにデータ移行を行う場合には、「ベンダによる新システムへのデータ移行の完成(完了)を目的とする契約」として、請負契約になじむと考えられます。他方で、データ移行段階における契約でも、当該プロジェクトにおいて、ユーザが主体的に新システムへのデータ移行を行い、ベンダが結果の確認等の支援を行うにすぎない場合には、「ユーザの新システムへのデータ移行の支援という事務処理をベンダが行うことを目的とする契約」として、準委任契約になじむと考えられます。このように、たとえ同じ段階における契約であっても、請負契約なのか、それとも準委任契約なのかは、行われる業務内容や、ベンダとユーザとの間の当該業務における役割によって自然と決定されるものです。業務内容やその役割分担によって契約類型が決められるべきで、契約類型によって業務内容や役割分担が決められるべきではありません。先に述べたとおり、典型契約における規定は、すでに締結された契約に関しては、契約当事者間で別途定められなかった事項を補充して適用する機能を有するにすぎません。契約当事者間で別途定めた事項があれば、原則としてそちらが適用されることとなります。その事項によっては、開発段階における契約であっても、準委任契約のような契約となることは当然あり得ますし、そもそも請負契約でも準委任契約でもない契約とすることもできるのです。以上は、ウォーターフォールモデルでの多段階契約を前提としていましたが、同モデルにおいても、多段階契約を採用するのではなく、一括契約を採用することもあり得るところです。アジャイル開発やプロトタイプ開発などを行うこともあり得るでしょう。詳細は別記事としますが、開発モデルによって、システム開発委託契約の性質が異なる可能性があります。これも詳細は別記事としますが、開発モデルによって、契約の際に注意しなければならない点も自ずと異なります。上述したように、契約類型は、業務内容やその役割分担によって決められるべきです。ウォーターフォールを採用する場合と、アジャイルを採用する場合とでは、契約類型はもちろんのこと、契約において合意すべき事項も、当然どちらを採用するかによって異なるはずです。同じモデルによる開発に関する契約であっても、ケースバイケースで契約類型や契約において合意すべき事項が異なる可能性は十分にあります。FAX:03-3580-7115。