위장 도급이 되지 않기 위한 준위임 계약의 올바른 업무 방식 ── 계약서의 이름이 아니라 「지휘명령」으로 정해진다

「우리는 준위임 계약이니까 위장 도급이 되지 않는다」

시스템 개발 현장에서 가끔 듣는 말이지만, 이는 오해입니다. 위장 도급 여부는 계약서 제목이 도급인지 준위임인지 업무위탁인지가 아니라, 현장의 실태, 즉 누가 엔지니어에게 지휘명령을 하는가로 판단됩니다. 준위임 계약을 맺었더라도 발주자가 수탁 측 엔지니어에게 직접 작업 방식이나 근로시간 지시를 하고 있다면, 그것은 위장 도급입니다.

이 글에서는 도급·준위임·근로자파견의 차이부터 위장 도급의 판단 기준(37호 고시), 개발 현장에서 흔히 있는 OK·NG의 경계선, 애자일 개발에서의 사고방식, 그리고 발주 측·수탁 측 각각이 갖춰야 할 실무까지를 후생노동성의 공표 자료를 바탕으로 정리합니다.

먼저 용어를 하나만 짚겠습니다. 본문에서 반복해서 나오는 37호 고시란 「근로자파견사업과 도급에 의해 이루어지는 사업의 구분에 관한 기준」(쇼와 61년 노동성 고시 제37호)의 통칭입니다. 고시 번호가 그대로 이름이 되었습니다. 위장 도급 여부를 행정이 판단할 때의 잣대가 바로 이것이고, 내용은 4장에서 자세히 봅니다.

덧붙여 이 글은 제도와 실무의 해설이며, 법적 조언이 아닙니다. 개별 계약이나 현장이 위장 도급에 해당하는지의 판단은 도도부현 노동국(수급조정사업과)이나 변호사에게 확인하시기 바랍니다.

1. 먼저 결론

기업 간에 엔지니어의 노동력·서비스를 주고받는 형태는 크게 다음 세 가지입니다. 차이의 핵심은 「발주자(취업처)가 엔지니어에게 지휘명령을 할 수 있는가」에 있습니다.

도급과 준위임은 모두 발주자와 수탁 측 근로자 사이에 지휘명령 관계를 만들지 않는 계약입니다. 지휘명령을 하는 것은 어디까지나 엔지니어의 고용주인 수탁회사입니다. 발주자가 직접 지휘명령을 하고 싶다면, 골라야 할 계약은 도급도 준위임도 아닌 근로자파견입니다.

그리고 형식상으로는 도급이나 준위임 계약을 맺으면서, 실태로서 발주자가 수탁 측 근로자에게 직접 구체적인 지휘명령을 하여 일을 시키는 상태가 이른바 위장 도급입니다. 후생노동성의 질의응답집(제3집)에서도, 준위임 계약이라도 실태로서 지휘명령 관계가 있으면 계약 형식을 불문하고 근로자파견사업에 해당하며 근로자파견법의 적용을 받는다고 명확히 말하고 있습니다.

즉 「준위임이니까 괜찮다」도 「도급이니까 괜찮다」도 없고, 괜찮은지는 계약서가 아니라 현장의 매일의 업무 방식이 정한다는 것이 이 글 전체의 결론입니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 17건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 도급·준위임·파견 ── 세 계약을 올바르게 구분한다

2.1. 도급 ── 일의 완성에 책임을 진다

도급(민법 632조)은 일의 완성을 약속하고, 그 결과에 대해 보수를 받는 계약입니다. 시스템 개발이라면 「이 요건의 시스템을 완성해 납품한다」는 형태가 전형이며, 수탁 측은 완성 의무를 지고, 납품물이 계약 내용에 맞지 않으면 계약불적합책임을 집니다.

2.2. 준위임 ── 업무 처리를 선관주의의무로 수행한다

준위임(민법 656조)은 법률행위가 아닌 사무의 처리를 위탁하는 계약입니다. 시스템 개발 맥락에서는 요건 정의 지원, 기술 조사, 설계 리뷰, 보수 운용, 개발 지원처럼 「완성」보다 「전문가로서 업무를 수행하는 것」 자체를 의뢰하는 장면에서 쓰입니다. 수탁 측은 완성 의무가 아니라, 선량한 관리자의 주의를 가지고 업무를 처리할 의무(선관주의의무, 민법 644조)를 집니다.

2020년 4월 시행의 개정 민법에서는 업무 수행 시간이 아니라 성과에 대해 보수를 지급하는, 이른바 성과완성형 보수 규정(민법 648조의 2)도 명문화되어, 준위임은 「시간 정산만 가능한 계약」이 아니게 되었습니다.

참고로 IT 업계에서 자주 쓰는 SES(시스템 엔지니어링 서비스)는 법률상 용어가 아닙니다. 엔지니어의 기술력을 서비스로 제공하는 거래의 이름이며, 계약 형태로는 준위임이 쓰이는 경우가 많다는 관계입니다. SES라는 이름을 쓰는지 여부 역시 적법성 판단과는 무관합니다.

2.3. 근로자파견 ── 지휘명령을 「합법적으로」 넘기는 유일한 형태

근로자파견은 파견원이 고용하는 근로자를, 파견처의 지휘명령을 받아 파견처를 위해 일하게 하는 것입니다(근로자파견법 2조). 발주자 측이 업무 지시, 근로시간 관리, 태스크 배분을 직접 하고 싶다면 이 형태뿐입니다. 그 대신 파견원에는 후생노동대신의 허가가 필요하고, 파견처에도 기간 제한이나 파견처책임자 선임 등 의무가 많이 붙습니다.

이 셋을 나란히 두면 위장 도급의 구조가 분명해집니다. 파견의 일하는 방식(직접 지휘명령)을, 파견의 비용과 의무를 지지 않고, 도급·준위임 계약서로 손에 넣으려는 것이 위장 도급입니다.

3. 위장 도급의 무엇이 문제인가 ── 발주 측·수탁 측 양쪽의 리스크

「현장이 잘 돌아가면 세세한 이야기는 하지 않아도」라고 생각할 수 있습니다. 그러나 위장 도급이 규제되는 이유는 있습니다. 지휘명령을 하는 자(발주자)와 고용 책임을 지는 자(수탁회사)가 분리되면, 근로시간 관리, 안전위생, 산재 책임의 소재가 모호해져 근로자가 보호의 공백에 놓이기 때문입니다. 근로자파견법은 이 분리를 허가제와 파견처·파견원의 의무 세트로 관리합니다. 위장 도급은 그 관리 밖에서 같은 분리를 만드는 행위입니다.

구체적인 리스크는 다음과 같습니다.

행정 지도·시정. 위장 도급은 근로자파견법 위반이며, 노동국의 지도·시정 대상입니다. 후생노동성은 근로자파견·도급을 적정하게 하기 위한 가이드를 공표하고 구분 기준을 알리는 작업을 진행하고 있습니다.

형사처벌 가능성. 실태가 근로자파견이라면, 내보내는 측은 무허가 근로자파견사업으로서 근로자파견법 벌칙 대상이 될 수 있습니다. 또한 구조에 따라서는 직업안정법 44조가 금지하는 근로자공급사업에 해당하고, 이 경우 공급한 측뿐 아니라 공급을 받은 측(발주자)도 벌칙(1년 이하의 구금형 또는 100만 엔 이하의 벌금, 동법 64조) 대상이 될 수 있습니다.

근로계약청약간주제도. 발주 측에게 가장 직접적인 리스크입니다. 후생노동성 리플릿대로, 근로자파견법 40조의 6이 정하는 제도이며, 요점을 나누면 다음과 같습니다.

• 대상: 위법 파견의 5유형(금지 업무 종사, 무허가 사업주로부터의 수용, 사업소 단위 기간 제한 위반, 개인 단위 기간 제한 위반, 그리고 이른바 위장 도급 등)
• 위장 도급 등에 고유한 요건: 근로자파견법 등의 적용을 피할 목적으로 계약을 체결하고 있었을 것
• 효과: 위법 파견이 이루어진 시점에, 받아들이고 있던 측이 그 근로자에게 현재와 같은 근로조건으로 근로계약을 청약한 것으로 간주된다
• 성립까지: 근로자가 1년 이내에 승낙하면 발주자와의 사이에 근로계약이 성립한다
• 예외: 받아들인 측이 위법 파견에 해당함을 몰랐고, 몰랐음에 과실이 없었을 때(선의·무과실)는 적용되지 않는다

즉 「협력회사 엔지니어라고 생각했던 사람이, 어느 날 자사 직원이 되는」 일이 법률상 일어날 수 있습니다. 게다가 승낙까지 유예가 1년이므로, 현장 체제를 시정한 뒤에 청약을 승낙받는 순서도 있을 수 있습니다.

거래와 신용에 미치는 영향. 시정 과정에서 계약 재편이나 체제 변경이 필요해지고, 프로젝트는 분명히 혼란합니다. 발주 측·수탁 측 누구에게든 위장 도급은 「들키지 않으면 이득」이 아니라, 발각된 시점에 양쪽이 아픈 구조입니다.

4. 판단 기준은 37호 고시 ── 두 「독립성」을 모두 충족한다

그렇다면 적정한 도급·준위임과 근로자파견은 구체적으로 무엇으로 구분되는가. 기준은 「근로자파견사업과 도급에 의해 이루어지는 사업의 구분에 관한 기준」(쇼와 61년 노동성 고시 제37호), 이른바 37호 고시입니다.

37호 고시는 수탁 측 사업주가 다음을 모두 충족하는 경우를 제외하고, 근로자파견사업을 하는 사업주라고 정하고 있습니다. 크게는 두 독립성입니다.

첫째는 노무관리상의 독립성 ── 자기가 고용하는 근로자의 노동력을 스스로 직접 이용하고 있을 것.

둘째는 사업경영상의 독립성 ── 맡은 업무를 자기의 업무로서 상대방으로부터 독립하여 처리하고 있을 것.

소프트웨어 개발의 경우, 마지막 항목은 「자기가 가진 전문 기술·경험에 기초하여 업무를 처리할 것」으로 충족하는 것이 보통입니다. 즉 개발 회사에게 실무상 초점은 거의 노무관리상의 독립성, 그중에서도 「업무 지시」「근로시간」「배치」를 누가 쥐고 있는가에 모입니다.

나아가 37호 고시 3조는, 형식상 모든 요건을 충족하더라도 법 위반을 피하려고 고의로 위장한 것이고 진짜 목적이 근로자파견이면 근로자파견사업에 해당한다고 합니다. 서면만 갖추는 「대책」은 통하지 않는 구조입니다.

5. 개발 현장에서 흔히 있는 OK·NG의 경계선

37호 고시만으로는 현장 판단이 헷갈리기 때문에, 후생노동성은 질의응답집(제1집〜제3집)으로 Q&A를 공표하고 있습니다. 거기에서 시스템 개발 현장에 맞춘 경계선을 정리합니다.

(각 행의 근거는 질의응답집 제1집의 문1·2·5·7·9·10·11, 그리고 제3집의 Q4·Q7입니다.)

표를 관통하는 원칙은 하나입니다. 「회사 대 회사」의 주고받기는 괜찮지만, 「발주자 대 엔지니어 개인」의 지휘명령은 안 된다는 것입니다.

개발 현장에서 특히 효력이 큰 논점을 두 가지 더 듭니다.

지시는 문서나 도구를 거쳐도 지시입니다. 질의응답집 제1집 문7은, 발주자가 작업의 내용·순서·방법을 문서로 상세히 제시하고 그대로 작업시키는 경우에도 위장 도급으로 판단된다고 합니다. 구두로 말하지 않고 티켓이나 채팅에 쓰면 된다는 이야기가 아닙니다. 누가 썼는지와, 그것이 지휘명령으로 기능하는지를 봅니다.

「인원×단가」만의 계약은 위험합니다. 제1집 문8은, 제품이나 작업의 완성이 아니라 투입한 노동력(인원)으로 수발주하고 노동력 단가로 정산하는 경우는 단순한 노동력 제공이며 위장 도급으로 판단된다고 합니다. 준위임에서 시간이나 공수에 기초하여 정산하는 것 자체는 부정되지 않지만, 계약서에 업무 내용이 없고 「엔지니어 ○명, 단가 ○엔」만 적힌 계약은 노동력 제공으로 평가되기 쉬운 형태입니다. 어떤 업무를 위탁하는지를 계약으로 특정할 수 있는 것이 전제입니다.

5.1. 선을 넘어가는 현장 ── 설명을 위한 가상 시나리오

이하는 실재 사안이 아니라, 여기까지 든 기준을 조합해 만든 설명용 시나리오입니다. 다만 나오는 요소는 모두 위 표의 NG 쪽이나, 이어서 나올 실무 항목에 대응합니다.

제조업 A사가 업무 시스템 개수를 B사에 준위임으로 위탁했습니다. B사 엔지니어 1명이 A사에 상주합니다. 계약서에는 「업무 시스템 개수 지원 일식」만 적혀 있고, 청구는 「1명×월액 단가」. B사의 관리책임자는 그 상주 엔지니어 본인이 겸합니다. 여기까지는 많은 현장에 있을 법한 출발점입니다.

• 4월: A사 담당자가 조회에서 엔지니어에게 「오늘은 이 화면을 먼저 해 주세요」라고 작업 순서를 직접 지시하기 시작합니다. 급한 안건이라 B사에 전해 회신을 받을 시간이 아깝기 때문입니다.
• 6월: 월말 마감이 가깝다는 이유로, A사 담당자가 「이번 주는 초과근무로 부탁합니다」라고 본인에게 직접 전합니다.
• 9월: A사 다른 부서에서 「이참에 Excel 매크로도 고쳐 달라」는 의뢰가 본인에게 도착합니다. 계약서에 업무 내용이 특정되어 있지 않아, 현장에는 거절할 근거가 없습니다.
• 12월: 엔지니어가 컨디션을 해치고, 근로시간을 관리하던 사람이 누구였는지가 문제가 됩니다.

이 시점에서 4장의 노무관리상 독립성 가운데 「업무 수행의 관리」와 「근로시간의 관리」는 성립하지 않습니다. 더해 계약에 업무 내용이 없고 인원×단가로 정산하는 것(제1집 문8), 1인 상주로 관리책임자를 본인이 겸하는 것(제1집 문4)이 겹칩니다. 시정 국면에서는 계약 재작성, 체제 재구축, 상주의 일시 철수 같은 대응이 필요해지고, 프로젝트는 멈춥니다.

참고로 근로계약청약간주제도까지 갈지는, 여기에 더해 「근로자파견법 등의 적용을 피할 목적」이 있었는지의 판단이 들어갑니다. 다만 그 앞단의 행정 지도나 계약 재편은 목적 유무와 관계없이 일어날 수 있습니다.

두려운 것은, 이 네 단계의 어느 것도 당사자에게는 「약간의 융통」에 불과하다는 점입니다. 누군가 악의로 위장한 것이 아니라, 바쁜 현장에서 최단 경로를 계속 고른 결과로 계약의 선과 지시의 선이 어긋납니다. 그래서 다음 장에서 말하는 「의뢰 경로를 처음에 정해 전원에게 공유한다」가 가장 효과적인 대책이 됩니다.

6. 준위임으로 올바르게 일하기 위한 실무 ── 체제·창구·보고

경계선이 보였으니, 그것을 매일 운용에 녹여 넣기 위한 실무를 정리합니다. 포인트는 지휘명령 경로를 계약과 체제로 고정하는 것입니다.

flowchart TB
    subgraph OK["적정한 준위임"]
        direction TB
        A1["발주자"] -->|"의뢰·요구·성과물에 대한 주문"| B1["수탁회사"]
        B1 --> C1["관리책임자"]
        C1 -->|"지휘명령"| D1["엔지니어"]
    end

    subgraph NG["위장 도급"]
        direction TB
        A2["발주자"] -->|"계약"| B2["수탁회사"]
        A2 -->|"직접 지시<br/>태스크 할당<br/>작업 절차 지시<br/>초과근무나 휴일출근 지시"| D2["엔지니어"]
    end

「적정한 준위임」 쪽은 발주자의 의뢰가 일단 수탁회사에서 받아들여지고, 관리책임자를 거쳐 엔지니어에게 도달합니다. 발주자의 의뢰가 수탁회사·관리책임자를 경유하고, 지휘명령 계통이 하나로 모여 있는 점이 중요합니다. 「위장 도급」 쪽은 계약의 선은 회사 사이에 있는데, 실제 지시는 발주자에서 엔지니어로 직접 날아갑니다. 계약의 선과 지시의 선이 어긋나 있다는 것, 이것이 위장 도급의 그림입니다.

6.1. 수탁 측이 갖출 것

• 계약서·주문서에서 업무 내용을 특정한다. 「시스템 개발 지원 일식」이 아니라 대상 시스템, 업무 범위, 체제, 기간, 보고 방법까지 적습니다. 성과완성형으로 할지 이행비율형(시간·공수 베이스)으로 할지도 여기서 정합니다.
• 관리책임자(현장책임자)를 두고 권한을 준다. 발주자와의 창구, 엔지니어에 대한 지시, 진척과 품질 관리를 수탁 측에서 맡는 사람입니다. 질의응답집 제1집 문4대로, 관리책임자가 작업을 겸하는 것 자체는 문제가 없지만, 실태로서 관리가 되어 있지 않으면 의미가 없고, 상주 멤버가 1명이고 그 사람이 관리책임자를 겸하는 형태는 발주자의 주문이 그대로 개인에 대한 지휘명령이 되므로 위장 도급으로 판단됩니다. 1인 상주 안건에서는 사내 매니저가 관리책임자로 기능하는 설계(의뢰 창구를 수탁회사 측으로 일원화한다, 정기 보고·리뷰를 사내에서 한다)가 필요합니다.
• 근태는 자사에서 관리한다. 시업·종업, 휴가, 초과근무 판단은 고용주인 수탁회사가 합니다. 발주자 건물의 출입 관리를 따르는 것이나, 발주자가 안전 확인을 위해 재석을 파악하는 것은 「단순한 파악」의 범위이지만, 초과근무를 해 달라·내일은 일찍 와 달라는 이야기는 반드시 자사를 거쳐 받습니다.
• 업무 보고를 남긴다. 무엇을 의뢰받아 무엇을 하고 어떻게 완료했는지를 월차나 주차 보고서·완료 보고로 남깁니다. 이는 위장 도급 대책인 동시에, 선관주의의무를 다한 기록입니다.

6.2. 발주 측이 갖출 것

• 의뢰는 창구(관리책임자)로. 새로운 작업 의뢰, 우선순위 변경, 재작업 요구는 엔지니어 개인이 아니라 수탁회사 창구에 냅니다. 성과물에 대한 주문·클레임을 회사 앞으로 하는 것은 질의응답집 제1집 문2대로 정당한 발주 행위입니다.
• 개인을 지명하지 않는다. 「A씨를 넣어 달라」「B씨는 빼 달라」는 수탁 측 배치 결정에 대한 개입이며, 적정한 도급·준위임으로 인정되지 않습니다(제3집 Q7). 기술력 확인은 개인을 특정하지 않는 스킬시트 등으로 합니다.
• 회의의 위치를 정해 둔다. 정례 회의는 요건·사양 전달, 진척 공유, 과제 협의의 장으로 두고, 개인에 대한 태스크 할당의 장으로 만들지 않는 것입니다. 회의나 채팅에 양쪽 전원이 참여하는 것 자체는 문제가 없습니다(제3집 Q6). 그러나 거기서 발주자에서 엔지니어로의 직접 지시가 흐르기 시작하면 위장 도급이 됩니다.
• 「파악」과 「관리」를 구분한다. 진척이나 품질을 파악하고, 계약대로가 아니면 회사 앞으로 시정을 요구하는 것은 발주자의 당연한 권리입니다. 반면 그 수단으로 엔지니어의 시간 사용이나 작업 절차에 손을 대기 시작했다면, 그것은 관리＝지휘명령입니다.

6.3. 현장 멤버에게 공유해 둘 것

위장 도급은 계약 담당자가 아니라 현장의 선의에서 시작되는 일이 많습니다. 발주자 측 담당자가 「이것도 잠깐 부탁」이라고 옆자리 엔지니어에게 부탁하고, 엔지니어도 악의 없이 받는다 ── 이런 부탁은 잡담의 연장처럼 보여도 「업무와 관계없는 일상 대화」가 아니라 업무 의뢰이며, 원래는 창구를 통해야 할 주고받기입니다. 쌓이면 발주자로부터의 지휘명령 실태 그 자체가 됩니다. 발주 측·수탁 측 양쪽 현장 멤버에게 의뢰 경로(누구에게 부탁할지, 누구에게서 받을지)를 처음에 공유해 두는 것이, 결국 가장 효과적입니다.

7. 애자일 개발과 위장 도급 ── 「대등한 협업」이면 문제없다

「발주자와 수탁자가 밀접하게 대화하면 위장 도급이 된다면, 애자일 개발은 불가능한 것 아닌가?」라는 의문에, 후생노동성은 질의응답집 제3집(2021년 공표)에서 정면으로 답하고 있습니다. 2026년 5월에는 Q8이 추가되어, 이 사고방식이 애자일형 개발 이외의 시스템 개발에도 해당한다는 점이 명시되었습니다.

요점은 다음과 같습니다.

• 밀접한 연계·정보 공유·기술적 조언·제안은 OK. 발주자 측과 수탁 측 개발 관계자가 하나의 팀으로서 수시로 정보를 공유하고, 대등한 관계 아래에서 협업하며, 수탁 측 개발 담당자가 자율적으로 판단해 개발을 진행하고 있다고 인정되면 위장 도급이 아닙니다(Q2·Q5).
• 프로덕트 오너에 의한 백로그 설명도 OK. 발주자 측 개발 책임자가 수탁 측 개발 담당자에게 직접 프로덕트 백로그 내용을 자세히 설명하고, 개발에 필요한 정보를 제공하는 것 자체는 문제가 없습니다(Q4).
• 경계는 역시 지휘명령. 그 설명이나 논의가 실태로서 업무 수행 방법이나 근로시간에 관한 지시가 되어 있다면 위장 도급입니다(Q4·Q5). 진척 지연 때 일의 할당·순서·완급 조정을 지시할 필요가 생기면, 그것은 수탁 측 관리책임자가 해야 할 일이며, 발주자 측이 직접 하면 관리책임자를 선임하고 있어도 위장 도급으로 판단됩니다(Q3).
• 사전 설계가 중요하다. 양쪽의 역할·권한, 팀 안에서의 업무 진행 방식을 미리 명확히 해 합의해 둘 것, 애자일 개발은 개발 담당자가 자율적으로 진행하는 것이라는 인식을 관계자 연수 등으로 공유해 둘 것이 권장됩니다(Q2).

즉 애자일이라서 위장 도급이 되기 쉬운 것이 아니라, 자율적 팀이라는 명분으로 실제로는 발주자가 멤버를 움직이고 있을 때 위장 도급이 됩니다. 스크럼의 「자기 조직화된 팀」을 실태로서 운용하고 있다면, 준위임의 애자일 개발은 제도상으로도 상정된 업무 방식입니다.

8. 도급·준위임·파견, 무엇을 골라야 하는가

마지막으로, 애초에 어떤 계약을 고르는 것이 적절한지를 정리합니다.

중요한 것은 「지휘명령을 하고 싶은데 비용이나 의무를 피하고 싶어서 준위임으로 한다」는 고르기를 하지 않는 것입니다. 그것은 계약 선택이 아니라 위장 도급의 입구입니다. 발주자로서 직접 컨트롤하고 싶은 사정이 정말 있다면, 파견 계약으로 바꾸거나, 수탁 측 체제(관리책임자 경유 운용)로 충족할 수 없는지를 검토하는 것이 올바른 순서입니다.

정리

• 위장 도급 여부는 계약서 이름이 아니라, 발주자가 수탁 측 근로자에게 직접 지휘명령을 하고 있는가라는 실태로 판단됩니다. 준위임 계약에서도 위장 도급이 될 수 있습니다
• 도급·준위임은 발주자와 엔지니어 사이에 지휘명령 관계를 만들지 않는 계약이며, 직접 지휘명령을 할 수 있는 것은 근로자파견뿐입니다
• 판단 기준은 37호 고시입니다. 업무 수행·근로시간·배치 관리를 수탁 측이 스스로 할 것(노무관리상의 독립성)과, 자금·책임·전문 기술에 의한 독립 처리(사업경영상의 독립성)를 모두 충족해야 합니다
• 일상 대화, 사양 설명, 회사 앞 주문, 대등한 기술적 논의는 문제가 없습니다. 개인에 대한 태스크 할당, 작업 절차의 직접 지시, 초과근무의 직접 지시, 멤버 지명·교체 요구는 위장 도급의 신호입니다
• 상주나 혼재 자체는 위장 도급이 아닙니다. 1인 상주＋관리책임자 겸임처럼, 주문이 개인에 대한 지휘명령으로 직결되는 체제가 위험합니다
• 애자일 개발은 대등한 협업과 수탁 측 멤버의 자율적 판단이 실태로서 성립하고 있으면 위장 도급이 아닙니다. 이 사고방식은 애자일 이외의 개발에도 해당합니다
• 위장 도급의 리스크는 행정 지도나 형사처벌에 그치지 않고, 근로계약청약간주제도에 의해 발주자가 엔지니어에게 근로계약을 청약한 것으로 간주될 가능성이 있습니다
• 망설이면 도도부현 노동국에 상담할 수 있습니다. 근로계약청약간주제도 해당 여부에 대해서는 노동국이 조언을 하는 체계(근로자파견법 40조의 8)도 있습니다

수탁 개발·기술 지원의 진행 방식을 검토 중인 분께

외부 엔지니어에게 개발을 의뢰하고 싶거나, 지금의 상주·지원 형태가 이대로 좋은지 신경 쓰이는 경우, 먼저 정리해야 할 것은 「무엇을 의뢰하고 싶은가(완성물인가, 업무인가, 노동력인가)」와 「누가 지휘명령을 하는가」 두 가지입니다. 여기가 정해지면 도급·준위임·파견 중 무엇으로 짤지, 체제와 창구를 어떻게 설계할지는 자연히 정해집니다.

합동회사 코무라소프트는 Windows 애플리케이션을 중심으로 한 수탁 개발과 기술 지원을 도급·준위임 어느 형태로든 받고 있습니다. 업무 범위와 성과물을 명확히 한 계약, 창구와 보고를 통한 진행을 기본으로 하며, 「어떤 구분으로 의뢰하면 좋을지 모르겠다」는 단계부터의 상담도 가능합니다.

준위임은 올바르게 운용하면, 요건이 다 굳지 않은 개발이나 지속적인 개선에 매우 적합한 계약 형태입니다. 계약의 형태와 현장의 업무 방식을 일치시켜, 발주 측·수탁 측 양쪽이 안심하고 협업할 수 있는 체제를 만드는 것부터 시작해 보시기 바랍니다.

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

SES와 준위임 계약은 같은 것인가요?

SES(시스템 엔지니어링 서비스)는 법률상 용어가 아니라, 엔지니어의 기술력을 서비스로 제공하는 거래를 가리키는 업계 실무 용어입니다. 계약 형태로는 준위임 계약이 쓰이는 경우가 많지만, SES라고 부르는지 준위임이라고 부르는지는 적법성 판단과 무관합니다. 판단되는 것은 발주자가 수탁 측 엔지니어에게 직접 지휘명령을 하지 않는지라는 실태입니다.

준위임 계약으로 발주자 사무실에 상주해 일하는 것은 문제인가요?

상주 자체는 문제가 아닙니다. 후생노동성의 질의응답집에서도, 발주자의 근로자와 수탁 측 근로자가 같은 장소에서 섞여 일한다는 것만으로 위장 도급으로 판단되는 것은 아니라고 합니다. 문제가 되는 것은 장소가 아니라 지휘명령입니다. 상주하더라도 업무 지시·근로시간 관리·배치 결정을 수탁 측 회사가 스스로 하고 있으면 적정하고, 반대로 원격이더라도 발주자가 직접 지휘명령을 하면 위장 도급이 될 수 있습니다.

발주자가 수탁 측 엔지니어에게 직접 질문이나 의뢰를 해도 되나요?

일상 대화, 사양이나 요건 설명, 정보 제공, 대등한 입장에서의 기술적 논의·조언·제안은 그것만으로 위장 도급이 되지 않습니다. 반면 작업 방식이나 순서 지시, 개인에 대한 태스크 할당, 초과근무·휴일출근 지시를 발주자가 수탁 측 엔지니어에게 직접 하면 지휘명령으로 보아 위장 도급으로 판단됩니다. 새로운 의뢰나 작업 지시는 수탁 측 관리책임자(창구)를 통하는 운용이 원칙입니다.

위장 도급으로 판단되면 어떻게 되나요?

근로자파견법 위반으로 노동국의 지도·시정 대상이 되며, 무허가 근로자파견이나 근로자공급에 해당하면 형사처벌 대상이 될 수도 있습니다. 나아가 근로계약청약간주제도에 따라, 파견법 등의 적용을 피할 목적으로 위장 도급을 하고 있던 경우 발주자가 그 엔지니어에게 근로계약을 청약한 것으로 간주되며, 엔지니어가 1년 이내에 승낙하면 발주자와의 근로계약이 성립합니다. 발주 측·수탁 측 모두에게 중대한 리스크입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.