システム開発契約まわりの業界慣習を知る

初めてシステム開発業界の案件に携わる法務担当者向けに、この記事を書きました。思えば、私が企業内弁護士として入社した当初、この業界の慣習に驚く場面もありました。

なんとなくシステム開発における業界慣習のイメージができると幸いです。

システム開発契約における契約の構成は３つ

どの業界であっても業務委託契約書を交わす場面はあります。契約書のタイトルが業務委託契約であったり、コンサルティング契約であったりと業界によって使われている言葉はさまざまです。

システム開発の業界でも、業務委託契約はあります。システム開発をベンダーに委託するのです。ベンダーとは、エンジニアを抱えている企業で、システム開発を基幹事業にしています。受託開発という言い方をすることもあるでしょう。

システムの開発をベンダーに業務委託する契約をSES契約（システムエンジニアリング契約）という言葉で表現する時があります。SES契約は、民法上の位置付けでは準委任契約にあたると考えられています。これが契約構成の１つ目です。

次に、エンジニアを派遣先であるユーザー企業に派遣する労働者派遣契約があります（２つ目）。また、ベンダーがシステムの完成を約束する請負契約もあります（３つ目）。請負契約は、一括請負契約という呼ばれ方をすることがあります。民法上の位置付けでは、文字どおり請負契約です。

ちなみに、一括という言葉はベンダーによってもニュアンスが異なりますが、開発工程の最初から最後までを１つの契約を取り交わすという意味で、一括請負という言葉を使っているケースが多いようです。
単に請負契約を取り交わすことを一括請負と呼称しているベンダーもいます。

法律の観点から整理すると、システム開発において用いられる契約の構成は、請負契約、準委任契約、労働者派遣契約のいずれかになります。

常駐型と非常駐型の契約

私が会社に入ったとき、エンジニアの方がほとんどオフィスにいないことに驚きました。みなさん、ユーザー企業の事業所に常駐してシステム開発に従事しているのです。

請負契約や準委任契約は、発注者であるユーザーの事業所で開発を行う常駐型と、受注者であるベンダーの事業所で開発を行う非常駐型の契約に分類することができます。受託開発を業としているSI企業では、システム開発契約は常駐型がほとんどです。

なお、労働者派遣契約では、法律により就業場所を明記しなければなりませんが、派遣先であるユーザー企業の事業所を記載することが一般的です。

人月単位による代金の定め

システム開発契約における代金の算定方法は、業界の慣行により人月によって定められています。人月とは、「エンジニアが一ヶ月作業したとき」という意味で理解して差し支えありません。たとえば、１人月７５万円は、エンジニア１名が１ヶ月作業したら７５万円かかる、という意味になります。

システムを作るのは人であり、人に作業させるとコストがかかりますから、「１ヶ月間、エンジニア１名をシステム開発に従事させますから、月にXX円かかります」というのはとても使いやすい単位ですね。

人月には明確な基準がなく、企業によって微妙なニュアンスの違いがあります。たとえば、先ほどの「１ヶ月間」は実際には標準作業時間という時間単位が用いられることがあります。１ヶ月あたりエンジニアが作業を行う時間を指し、月によって日数や祝日の関係で営業日数に増減が生じるため、標準作業時間は一定範囲で定めることが一般的です。

たとえば、１ヶ月あたりの平日の日数は２０日くらいですが、１日あたり実働８時間で乗じて１６０時間です。また、月によって平日の日数が１９日や２１日ということもありますから、標準作業時間を１６０時間±２０時間といった形でバッファをもって定めておきます。ベンダーによって標準作業時間の算出方法や考え方に違いがあるようです。

そして、標準作業時間の範囲を下回ったり上回ったりした時は、１時間あたりの単価を契約で決めておき、作業時間に増減が生じたら精算します。

準委任や労働者派遣を契約構成として採用した場合にはこのような代金の定め方をしているシステム開発契約を多く見かけます。

ちなみに、準委任契約を前提に、エンジニアの作業時間に関わらず代金を固定にする契約をときどき見かけます。多くは、発注するユーザー企業の予算の都合によるものと推察されますが、代金固定の準委任契約は実態として請負契約のような運用であることが多く注意が必要です。

ベンダー側の法務担当者は、代金固定の準委任契約に出会った時は、契約のなかでベンダに求められている業務範囲をきちんと特定するよう意識してレビューした方が良いでしょう。契約基幹中の作業量や作業の基準などを契約できちんと限定しておかなければ、ユーザー企業からどこまで作業を要求されてしまうこともあるからです。

システム開発業界は受注の多重構造が常態化している

建設業界と同じくシステム開発業界は、受注関係が多重構造化しています。孫請けはもちろん、ひ孫請け、玄孫請けも珍しくありません。ユーザーの事業所には複数のベンダーが常駐して作業していることもよくあります。

ときどき困るのは、ベンダーが再委託先のエンジニアに自社の名刺を渡して活動させているときです。受注の多重構造のなかでトラブルが生じた場合、責任の所在を把握するのには困難が伴うときも少なくありません。

企業内弁護士がシステム開発業界に入って最初に思い悩むのは、いわゆる偽装請負に対してどこまで対処し、どこまで目を瞑るのかではないでしょうか。

はっきり言いますが、エンジニアの方々は、何が偽装請負と疑われてトラブルになるのか、よく理解していません。法律に詳しくないのでごく自然なことだと思います。
「私は理解している」という声も聞こえてくるかもしれませんが、それはおそらく一次請けに近い立場で仕事をしているからです。そもそも、受注構造の末端の方までいくと、エンジニア自身がどのような契約構成で開発業務に従事しているのかを把握していません（把握している方が珍しい）。

同じく企業内弁護士の方へのアドバイスですが、偽装請負の考え方や判断基準に対して自分なりの見解や対応方法を持っておくと良いでしょう。

また、法律事務所の弁護士がエンジニアから労働紛争の相談を受けたときは、受注が多重構造化していることや、エンジニア自身が契約形態を把握していないケースがよくあることを押さえておくと良いでしょう。

まとめ

とてもざっくりとした内容ですが、まとめると、

・システム開発契約における法律構成は、請負、準委任、労働者派遣契約の３つです。

・「人月」は、業界の慣行である業務委託契約の対価の算定方法であり、エンジニアが１ヶ月の標準作業時間内で作業した場合の代金を意味します。

・システム開発業界は受注が多重構造化していますので、いわゆる偽装請負としてトラブルに発展しないよう注意を払う必要があります。ときどき、受託開発業界では偽装請負が常態化しているという主張を耳にしますが、それなりに理由があると思います。