【システム運用】障害で長時間労働……「請負契約」での運用業務に潜む法的リスクと落とし穴

Ask_AI

2017.01.152026.06.26

システム運用や保守の現場では、突発的なシステム障害によって夜間・休日の緊急対応が発生したり、復旧が長引いて長時間労働に陥ったりすることが珍しくありません。

こうした現場の契約形態について、「SES（準委任契約）」ではなく「請負契約」で従事する場合、法的な問題は生じるのでしょうか？

結論から言うと、「偽装請負（労働者派遣法違反）」や「労働基準法違反」といった非常に高い法的リスクが生じる可能性があります。なぜ請負での運用業務が危険なのか、そのメカニズムと実務上の注意点を徹底解説します。

🚨 リスク1：「偽装請負」の温床になりやすい（指揮命令権の壁）
🚨 リスク2：長時間労働に対する「安全配慮義務」と「残業代」のねじれ
1. ① 発注側（顧客）の「安全配慮義務違反」リスク
2. ② 受注側（所属会社）の「労働基準法違反」リスク
💡 システム運用を「請負」で行うための必須条件
📝 まとめ：運用の現場は「SES（準委任）」や「派遣」が本来の姿

🚨 リスク1：「偽装請負」の温床になりやすい（指揮命令権の壁）

請負契約の最大のルールは、「発注側（顧客）は、受注側の作業員に対して直接指示（指揮命令）をしてはならない」ということです。作業員への指示は、必ず受注側のチームリーダー（連絡責任者）を介さなければなりません。

しかし、障害対応の現場では以下のような状況が頻発します。

顧客から直接： 「今すぐこのサーバーを再起動して！」「原因究明のログを今すぐ出して！」と緊迫した指示が飛んでくる。
事態の急変： リーダーを挟んでいる余裕がなく、顧客のシステム部員と現場エンジニアが直接あうんの呼吸で動いてしまう。

このように、契約上は「請負」であるにもかかわらず、実態として顧客が直接指示を出している状態を「偽装請負」と呼び、労働者派遣法違反という明確な違法行為になります。特に障害対応という「リアルタイムの即応性」が求められる業務は、構造的に偽装請負に陥りやすいのです。

🚨 リスク2：長時間労働に対する「安全配慮義務」と「残業代」のねじれ

請負契約は、労働時間の長さではなく「成果物の納品（または業務の完了）」に対して対価が支払われる契約です。そのため、基本的には「何時間働いても定額」という固定給のような形になりがちです。

ここで以下の2つの深刻な法的問題が発生します。

① 発注側（顧客）の「安全配慮義務違反」リスク

顧客側は「請負だから、彼らが何時間残業しようが関係ない（自己責任）」と考えがちです。しかし判例上、請負であっても、顧客の施設内に常駐して密接に業務を行っている場合、顧客側にも労働者に対する「安全配慮義務」が生じるとされています。障害で連日徹夜させて労働者が体調を崩した場合、顧客側が損害賠償請求を受けるリスクがあります。

② 受注側（所属会社）の「労働基準法違反」リスク

エンジニアが所属する会社（ベンダー）は、自社の社員に対して労働基準法（36協定の遵守や残業代の支払い）を適用する義務があります。請負契約の金額が固定であるにもかかわらず、障害対応で社員が月100時間の残業をした場合、会社は莫大な残業代を自腹で支払わなければなりません。これを「請負だから残業代は出ない」などと社員に強いると、完全な労働基準法違反（賃金未払い）となります。

💡 システム運用を「請負」で行うための必須条件

もし、どうしてもシステム運用を「請負」として適法に成立させたい場合は、以下の運用が徹底されている必要があります。

業務範囲（SLA）の明確な定義： 「障害対応」をどこまでやるのか（一次切り分けまでなのか、プログラム修正までなのか）を契約書（SLA）で厳密に定義し、範囲外の突発業務は「別料金（追加見積もり）」にすること。
指揮命令の遮断： 障害時であっても、顧客からの要望は「チケットシステム」や「受注側リーダー」を必ず経由させ、現場に直接命令させない仕組みを作る。
適切な要員計画と交代制： 長時間労働を防ぐため、夜間対応後は翌日を休み（シフト制）にするなど、受注側の会社が主体となって労働時間をコントロールする。