少々面倒な契約の話
多くのＢ２Ｂ企業には「請負」と「派遣」の大別すると２種類の契約形態が存在します。しかしＩＴ業界ではさらに「委任」「準委任」といった契約形態も存在します。
が、厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」にいう「請負」には「委任（委託）」も含まれますので、当社の場合は、委任も準委任も、基本的に「請負」と言う区分に分類されるわけです。
実際には、民法上の契約類型には１３種ほど存在していますし、且つ"契約自由の法則"に従って強行法規などに違反していなければ、基本的にどのような契約でも自由です。契約が明確でない場合に限り、１３種の契約類型に当てはめるようになっています。
「請負」、「委任」、「準委任」と言う契約類型は、民法で定められています（632条、643条、656条）。「派遣」については派遣法で定められています。
しかし、この業界ではさらにもう１つ、
ＳＥＳ契約（システムエンジニアリングサービス契約）
という契約形態が存在しています。ＳＥＳ契約は、システムエンジニアが行うシステム開発等に関する委託契約の一種として扱われ、システムエンジニアの能力を契約の対象とするもので、いわゆるグレーゾーンに陥りやすい契約方式になります。
ある"条件"を満たすと偽装請負と判断されかねないため、非常に取り扱いが難しい契約ですが、逆にその条件を知ってしまえばたいしたことはありません（偽装請負…正確に言えば労働者派遣法違反や職業安定法違反となる請負、委任、その他の契約を指します）
ではその"条件"は？と言うと、要するに
事業の独立性
を持っているかどうか？と言う点に尽きます。
要するに、派遣のようにお客様の管理・監督下に任せて、自社の独立管理・監督を怠ると、事業の独立性が認められず、「契約形態だけ請負としておきながら、実際には派遣と同じことをしている」と言うことで、偽装請負と言う判決が下る…ということです。
よって、企業としてのプライドと進め方を以って、活動し、誘導し、お客さまにとってよりよい提案を心掛け、決してお客さまの言いなりとなって指示、命令がなければ動けないような状態になることの無いよう取り組めば、この偽装請負の懸念は払しょくされるということです。
ＳＥＳ契約は、請負範囲前の"作業ボリュームを特定する"ためには非常に有効な契約方法です。要件定義工程や提案活動中の、「仕様が明確化される前」などによく利用されます。
基本的には
時間単価×稼働時間
で精算する形態をとるので、
開発側も仕様が特定できて正確な見積りができるまでは
出来高で精算できるため赤字になりにくい（単価次第）
発注側も目的が完遂でき次第、検収できて無駄にコストを費やさない
と言った観点から、原則Win-Winとなりやすい契約形態です。
ただし、期日に対する意識が低く、ズルズル続くとお客様のコストを浪費することになるため、期限を決め、そこまでにゴールを迎えられるよう調整する、あるいはするように努力することが、エンジニアとお客様との間で共有すべき必須事項となります。
しかし、世の中では…特にエンジニアにとっては、悪魔のような契約形態とされることがあります。ＩＴ企業が、SIerがただしくＳＥＳ契約を理解していない、あるいは正しく運用していないからです。
実際、私がエンジニア時代に行われていたＳＥＳ契約のプロジェクトは、完全な偽装請負がとても多く存在しました。今だからこそよくわかります。
初めて長期出張で大阪の雑居ビルに軟禁された時、
私はまだ当時社会人２年生でした。
私の所属する会社からは私１名だけで現場に放り込まれ、
リーダーやマネージャーがいるわけでもなく、
現場の別会社のリーダーの指示・命令ですべて動かなければならない
そんな状況でした。
勤務時間は朝７時から夜２７時頃まで。
借りていたウィークリーマンションにはシャワーを浴びて着替えるだけ。
睡眠は昼ご飯と夜ご飯の休憩時に少しするだけ。
休みもほとんどなく、月に１日休めればラッキー。
リ〇インを箱買いしながら、同じ境遇の若手の人たちと一緒に「24時間はたらけねーっ」なんて言ってたものです。…そんな生活が１年半も続いていました。
これでは完全に派遣と同じ扱いです。
請負やＳＥＳ契約、委任契約などの場合、派遣社員と同じ扱いは決してできません。それをやってしまうと偽装請負確定です。
今でこそコロナ禍の影響で、自社持ち帰りで開発することも多くなっているかもしれませんが、大手SIer関連のプロジェクトに参画すると情報セキュリティやユーザーとの機密保持契約のからみで、SIerの指定する現場へ常駐しなければならないケースが多々あります。この時、リーダーやマネージャーが存在する『チーム』で常駐していたとしても、SIerの度重なる過剰な指示・命令が発生して事業の独立性が守れなくなることがとても多いんです。
その結果、ロクに管理もしないSIerに、好き勝手に指示・命令だけが行われてエンジニアたちがどんどん疲弊していくドロ沼のような契約と言われるようになっていきました。
発注元は原則として「契約にない」タスクはまず相談すべきなのですが、二次請け以降を
「ただの下請けのくせに」
「発注してやらなければ生きていけないくせに」
程度にしか考えていないから、好き勝手出来てしまうんですよね。実際には二次請け以降の企業がエンジニアを提供してくれないと仕事を完遂することもできないわけですから、お互いに共生関係でしかないはずなんですけど。
本来は、とても効果の高い有益な契約方法なので、適切に使ってほしいものですね。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。