はじめに
今回は、システム開発に関わる方に知っておいてほしい法律知識を紹介していきたいと思います。システムエンジニアはもちろん、これからIT企業で法務業務に関わる方などに参考にして頂ければ幸いです。
採用通知をもらったら作業に着手してよいか？
採用通知は、契約の成立ではありません。そのため、作業内容や機能、金額、納期等の交渉が長引き、結局契約しないというケースもあり得ます。そういった際に、早まって作業に着手してしまうと、エンジニアの人件費が損害となります。また、相当程度開発が進んでしまうと、解除のリスクが大きくなるため、結果として当初想定していた金額よりも低い金額で契約せざるを得なくなったというケースもあるようです。
採用通知をもらったから安心と思わず、まずはしっかりと条件面をきっちりと取り決めるということを肝に銘じましょう。
準委任契約と請負契約ってなに？
「準委任契約（民法６４３条、６５６条参照）」とは、法律行為でない事務を委託するという内容の契約です。
「請負契約（民法６３２条）」とは、仕事の完成を約束して、その仕事の結果に対して報酬が支払われることを内容とする契約です。
つまり準委任契約は、エンジニアの工数に対して、業務委託料が支払われます。そして、一番重要なポイントは、仕事の完成義務がない点です。そのため、結果としてシステム開発が終わらなかったとしても、工数に応じた業務委託料の請求は当然可能です。（※１）
一方で、請負契約の場合には、仕事の完成義務を負います。そのため、契約で予定された仕事が完成できなかった場合には、業務委託料は発生しません。（※２）
システム開発の現場では、ユーザーとベンダーの立場上、早くシステムを導入したいユーザーからせかされて、契約書の内容を詰めていくことができないケースが多々あります。また知識のないユーザーの場合には、ユーザー自身が仕事の完成を具体的にイメージできていないという場合もあり、仕事が完成したとユーザーに納得してもらうのにも一つハードルがあるケースもあります。
そのため、一般的には、準委任契約のほうがベンダーに有利と言われています。
では、契約書上どのように請負契約と準委任契約区別すればよいのでしょうか。
これには、いくつかポイントがありますが、やはり大きなところとしては、業務委託料が、工数に対して支払われるのか、仕事の完成に対して支払われるのかです。
また、仕事の完成（＝成果物）が明記されているか、それに対して検収や契約不適合責任（＝瑕疵担保責任等）の規定があるかという点も判断材料の一つです（これらの規定があるからといって必ず請負契約というわけではありません。）
あとは、本当にサブ的な判断要素ですが、先方が契約書に印紙を貼ってくるかどうかです。印紙税法上、請負契約であれば、第２号文書として印紙が必要ですが、準委任契約であれば、印紙は不要です。
以上のように、契約の性質が準委任契約なのか、請負契約なのかによって、法的リスクが変わってくるので、意識するようにしましょう。
※１もちろん仕事を誠実に行っていない場合には、準委任といえども損害賠償や業務委託料の減額等色々言われます。また、仕事が完成しないうちに、開発を中止し、工数分の費用を請求というのも、会社の信用を失わせかねないので、現実にはあまりないと思います。そう考えると、僕個人の見解としては、準委任と請負でそこまで大きな違いはないと思っています。
※２改正民法６３４条では、仕事の結果のうち可分な部分の給付によって注文者が利益を受ける場合には、その部分を仕事の完成とみなして、報酬の一部を請求できることが明文化されます。
プロジェクト管理義務とは？
「プロジェクト管理義務」とは、ITシステムの専門家であるベンダーは、素人であるユーザーの目的を達成するために、自ら有する高度の専門知識と経験に基づきプロジェクトの進行をうまくコントロールしなければならないことをいいます。
ベンダー側は、このプロジェクト管理義務をきちんと全うしなければ、業務委託料の請求ができなかったり、損賠賠償請求をされたり等多大な損害を会社に生じさせてしまうリスクがあります。例えば次のような例があげられます。
ユーザーが機能の追加・変更の要望を繰り返してきて、システムの納期が大幅に遅延し、リリースの見込みも立たないケース
ユーザーはシステムの素人ですので、もちろん無茶な要望もしてきます。そういった際に、何も言わずお客様の言うとおりにし、結果として決められた納期が過ぎてしまってもプロジェクト管理義務に違反し、ベンダーの責任です。
ベンダーとしては、専門家として、「その機能追加は主要な機能に影響しますので、プロジェクトを予定通り進めることができなくなります」等、費用の増額、スケジュール変更、要望の撤回等をユーザーに対して求めなければなりません。
このようにユーザーとベンダーは、素人と専門家の関係にあります。一方で、注文者と受注者でもあり、複雑な立場でもあります。受注者としての立場を重視するあまり、専門家としての立場をないがしろにしてしまうのは、かえって、プロジェクトの失敗ひいては受注者としての立場も全うできないことになりえますので注意しましょう。
要件定義書に書かれたことだけを守ればよいか。
要件定義書は、ユーザーとベンダーで協力して作成していくものです。では、作成された要件定義書さえ守られていれば、システムは完成したといえるのでしょうか。
これは意外かもしれませんが、そうとも言い切れません。システム開発の最終目標は、要件定義書の内容の充足ではなく、契約目的の達成です。例えば、人事システムであれば、高度なセキュリティが担保されていることは、要件定義書や契約書に書かれていなくても、セキュリティ機能が実装されていなければ、人事システム自体使うことができず、契約目的は達成できません。
このように、ベンダーは、その機能をユーザーが使うためには、どのような機能が無くてはならないかを考え、ユーザーとのヒアリングを十分に行い、理解し、必要であれば要件定義書になくても機能を追加する必要があります。
最後に
システム開発というのは、ここまで読んでいただいたように、ユーザーとベンダー間の知識量の差というのが問題の種になることが多いです。そこを埋めるために専門家としてはどうすればよいのかを常に考えていく必要があると思っています。
法務の立場としては、システム開発に関わる方や営業担当等に対して、ベンダーが果たすべき義務、そして（今回は書ききれませんでしたが）ユーザーが果たす義務について、周知させ、また現場にヒアリングしつつ具体的にどういったリスク対策をしていくかを検討していきたいなと思っています。
研修資料とか作ってみようかなぁ～？いつになるかわからないけれど、完成したらブログにも公開しますね！
では、また～
コメント