はじめに
IT業務を外部に委託する際、「SES」「準委任契約」「請負契約」という言葉を耳にします。この3つの違いを正確に理解していないまま契約を進めると、「思っていたのと違う」という事態につながります。発注側として最低限理解しておくべき契約形態の違いを整理します。
3つの契約形態の違い
請負契約
決められた成果物を完成させることを約束する契約です。ベンダーは、契約で定めた成果物（システムや機能）を完成させる義務（完成義務）を負い、発注側は完成した成果物に対して対価を支払います。検収基準を曖昧にすると起きることで触れた検収の概念は、主にこの請負契約において重要になります。
準委任契約
成果物の完成を約束するのではなく、一定の業務を遂行することを約束する契約です。ベンダーは「善良な管理者の注意義務（善管注意義務）」をもって業務にあたる義務を負いますが、成果物の完成そのものを保証するわけではありません。要件定義支援やPMO支援など、成果物を明確に定義しにくい業務でよく用いられます。
委任契約との違い
「委任」という言葉だけを聞くと準委任契約と同じものに思えますが、民法上は区別されています。委任契約は、契約締結の代理など「法律行為」を他人に委託する契約です。これに対して準委任契約は、システム開発やコンサルティング業務のように「法律行為に該当しない事実行為」を委託する契約を指します。IT業務の大半は法律行為ではないため、契約書上も「準委任契約」という名称が使われます。発注側としては、委任契約と準委任契約の条文上の扱いはほぼ同じ（準委任には委任の規定が準用される）と理解しておけば実務上十分ですが、契約書の名称として「準委任」が正しい、という点は押さえておくとよいでしょう。
SES（システムエンジニアリングサービス）
エンジニアの労働力そのものを提供する契約形態で、法的には準委任契約の一種として扱われることが一般的です。発注側が、ベンダーに所属するエンジニアに対して直接具体的な指揮命令を行うことは、偽装請負（労働者派遣法に抵触するリスクのある状態）にあたる可能性があるため、注意が必要です。
発注側にとって何が重要なのか
この3つの違いを理解しておくべき最大の理由は、「成果物の完成責任が、発注側とベンダーのどちらにあるのか」が契約形態によって根本的に異なるためです。
請負契約であれば、成果物が完成しなければベンダーの責任（契約不履行）となり、発注側は代金の支払いを拒否できます。一方、準委任契約やSESでは、ベンダーは業務を適切に遂行していれば契約上の義務を果たしたことになり、仮に期待した成果が得られなかったとしても、それだけでは契約違反とは言えません。
この違いを理解せずに契約を結んでしまうと、「成果が出なかったのだから責任を取ってほしい」という発注側の主張が、契約上は通らない、という事態に陥ることがあります。
どの契約形態を選ぶべきか
委託する業務の性質によって、適した契約形態は変わります。要件や仕様が明確に定義でき、完成の基準を具体的に決められる開発業務は請負契約が向いています。一方、要件定義支援やコンサルティング、PMO支援のように、業務の進め方自体を発注側と一緒に模索していくような性質の業務は、準委任契約が実態に合っていることが多いです。
契約形態を決める際は、「この業務の成果物・完了基準を具体的に定義できるかどうか」を基準に考えると、判断しやすくなります。
まとめ
請負契約は成果物の完成責任をベンダーが負う契約、準委任契約・SESは業務遂行そのものを約束する契約です。この違いを理解していないと、成果が出なかった際の責任の所在をめぐって認識のズレが生じます。委託する業務の性質を踏まえて、適切な契約形態を選ぶことが重要です。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント