为了不构成伪装承揽的准委托合同正确工作方式 ── 不由合同书的名称，而由「指挥命令」决定

“我们签的是准委托合同，所以不会构成伪装承揽”

在系统开发的现场，有时会听到这样的说法，但这其实是一种误解。是否构成伪装承揽（偽装請負），判断依据并不是合同书的标题写的是承揽（請負）、准委托（準委任）还是业务委托，而是现场的实际情况，也就是究竟由谁在向工程师下达指挥命令。即使签订的是准委托合同，只要发包方直接向受托方的工程师下达作业方法或劳动时间方面的指示，那就是伪装承揽。

本文将基于厚生劳动省公开发布的资料，从承揽、准委托、劳务派遣（労働者派遣）三者的区别开始，梳理伪装承揽的判断基准（37号告示）、开发现场常见的合规与违规界线、敏捷开发中的思路，以及发包方与受托方各自应当建立的实务做法。

先说明一个会在正文中反复出现的术语。37号告示是《关于区分劳动者派遣事业与以承揽方式实施的事业的基准》（昭和61年劳动省告示第37号）的通称，该称呼直接取自告示的编号。这是行政机关判断是否构成伪装承揽时所使用的尺子，具体内容将在第4章详细说明。

另外，本文是对制度与实务的一般性解读，并非法律意见。具体的合同或现场是否构成伪装承揽，请向都道府县劳动局（需求调整事业课）或律师确认。

1．先说结论

企业之间流通工程师的劳动力、劳务的方式，大致可以分为以下3种。区别的核心在于”发包方（用工单位）能否对工程师下达指挥命令“。

承揽与准委托，都是不会在发包方与受托方劳动者之间产生指挥命令关系的合同。下达指挥命令的，始终是作为工程师雇主的受托公司。如果发包方希望直接下达指挥命令，那么应当选择的合同就既不是承揽，也不是准委托，而是劳务派遣。

而形式上签订的是承揽或准委托合同，实际上却由发包方直接对受托方劳动者下达具体指挥命令使其工作的状态，就是所谓的伪装承揽。厚生劳动省的疑义应答集（第3集）也明确指出，即使签订的是准委托合同，只要实际存在指挥命令关系，无论合同形式如何，都构成劳务派遣事业，须适用劳动者派遣法。

也就是说，”因为是准委托所以没问题”或”因为是承揽所以没问题”都不成立，是否没问题，不是由合同书决定，而是由现场每天的实际工作方式决定——这就是本文的整体结论。

2．承揽、准委托与派遣 ── 正确区分3种合同

2.1．承揽 ── 对完成工作负责

承揽（民法第632条）是约定完成工作，并就其成果收取报酬的合同。在系统开发中，典型形态是”按照该需求完成系统并交付”，受托方负有完成义务，如果交付物不符合合同内容，则须承担合同不符责任。

2.2．准委托 ── 以善良管理人的注意义务处理业务

准委托（民法第656条）是委托处理非法律行为事务的合同。在系统开发语境下，常用于需求定义支持、技术调查、设计评审、维护运维、开发支持等场景——这些场景所委托的，与其说是”完成”，不如说是”以专业人士的身份从事业务”这件事本身。受托方所负的不是完成义务，而是以善良管理人的注意处理业务的义务（善良管理人注意义务，民法第644条）。

在2020年4月施行的修订民法中，还明文规定了针对成果、而非业务执行时间支付报酬的所谓成果完成型报酬约定（民法第648条之2），准委托已不再是”只能按时间结算的合同”。

另外，IT行业常用的SES（系统工程服务）并非法律用语。它是对以劳务形式提供工程师技术能力这种交易的称呼，签约形式多采用准委托合同——两者的关系仅此而已。是否使用SES这一名称，与合法性的判断也没有关系。

2.3．劳务派遣 ── 唯一能够”合法”转移指挥命令的形态

劳务派遣，是让派遣单位所雇用的劳动者，接受用工单位的指挥命令，为用工单位工作（劳动者派遣法第2条）。如果发包方希望直接进行业务指示、劳动时间管理、任务分配，那么就只有这一种形态可选。作为交换，派遣单位需要获得厚生劳动大臣的许可，用工单位也须承担期限限制、选任用工单位责任人等诸多义务。

把这3种形态并列起来看，伪装承揽的构图就清晰了。试图不承担派遣的成本与义务，却通过承揽或准委托合同来获得派遣式的用工方式（直接指挥命令），这就是伪装承揽。

3．伪装承揽的问题所在 ── 发包方与受托方双方的风险

或许有人会想，”只要现场运转顺利，细节不必较真”。但伪装承揽之所以受到规制，是有原因的。一旦下达指挥命令的一方（发包方）与承担雇用责任的一方（受托公司）相互分离，劳动时间管理、安全卫生、工伤责任的归属就会变得模糊，劳动者就会被置于保护的空白地带。劳动者派遣法正是通过许可制以及用工单位、派遣单位各自的义务，来管理这种分离状态的。而伪装承揽，则是在这套管理体系之外制造出同样的分离。

具体的风险如下。

行政指导与整改。伪装承揽违反劳动者派遣法，是劳动局指导与整改的对象。厚生劳动省发布了《正确开展劳务派遣与承揽的指南》，持续推进区分基准的普及。

刑事处罚的可能性。如果实际情况属于劳务派遣，那么输出劳动力的一方，就可能作为无许可经营劳务派遣事业，成为劳动者派遣法罚则的对象。此外，视具体构图不同，也可能构成《职业安定法》第44条所禁止的劳动力供给事业，此时不仅供给方，接受供给的一方（发包方）也可能成为罚则（1年以下拘禁刑或100万日元以下罚金，同法第64条）的对象。

视为已提出劳动合同要约制度。这是对发包方而言最直接的风险。正如厚生劳动省的宣传单所述，这是劳动者派遣法第40条之6所规定的制度，要点可以分解如下。

• 适用对象：违法派遣的5种类型（从事禁止业务、从无许可经营者处接受劳动力、违反事业单位层面的期限限制、违反个人层面的期限限制，以及所谓的伪装承揽等）
• 伪装承揽等特有的构成要件：以规避劳动者派遣法等适用为目的而订立合同
• 效果：在发生违法派遣的时点，视为接受劳动力的一方已向该劳动者提出了与当前相同劳动条件的劳动合同要约
• 成立条件：劳动者在1年以内做出承诺，即在其与发包方之间成立劳动合同
• 例外：接受劳动力的一方不知道属于违法派遣，且对此不知情没有过失（善意无过失）时，不适用该制度

也就是说，法律上确实可能发生”原以为是协作公司的工程师，某天却成了自己公司的员工”这种情况。而且由于承诺的宽限期长达1年，也可能出现现场体制整改完毕之后，对方才承诺该要约这种时间顺序。

对交易与信誉的影响。整改过程中必然需要重新签订合同、调整体制，项目势必陷入混乱。无论对发包方还是受托方而言，伪装承揽都不是”不被发现就赚到”的事情，而是一旦被发现，双方都会受损的结构。

4．判断基准是37号告示 ── 须同时满足两项”独立性”

那么，适当的承揽、准委托与劳务派遣，具体是以什么来区分的呢？基准就是《关于区分劳动者派遣事业与以承揽方式实施的事业的基准》（昭和61年劳动省告示第37号），即所谓的37号告示。

37号告示规定，除非受托方经营者同时满足以下全部条件，否则就应当被认定为经营劳务派遣事业的经营者。这些条件大体可以归纳为两项独立性。

第一项是劳务管理上的独立性 ── 自行直接使用自己所雇用劳动者的劳动力。

第二项是事业经营上的独立性 ── 将所承接的业务作为自己的业务，独立于对方进行处理。

在软件开发的情形下，最后一项通常是通过”依据自身所具备的专业技术、经验来处理业务”来满足的。也就是说，对开发公司而言，实务上的焦点几乎全部集中于劳务管理上的独立性，尤其是”业务指示”“劳动时间”“岗位安排”这三点分别掌握在谁手中。

此外，37号告示第3条还规定，即使形式上满足了全部要件，但如果是为规避法律而故意伪装、真实目的实为劳务派遣的，仍应认定为劳务派遣事业。也就是说，仅仅在书面上做足功夫的”对策”是行不通的。

5．开发现场常见的合规与违规界线

仅凭37号告示，现场判断仍会感到困惑，因此厚生劳动省在疑义应答集（第1集〜第3集）中公开了一系列问答。以下将其套用到系统开发现场，梳理出合规与违规的界线。

（各行的依据分别为疑义应答集第1集问1、2、5、7、9、10、11，以及第3集Q4、Q7。）

贯穿整张表的原则只有一条，“公司对公司”的往来没有问题，但”发包方对工程师个人”的指挥命令则不行。

再举出另外两点在开发现场特别关键的论点。

通过文书或工具下达的指示，同样属于指示。疑义应答集第1集问7指出，即使发包方是通过文书详细列出作业的内容、顺序、方法，并要求按此作业，同样会被判断为伪装承揽。这并不是说”不用口头说，写在工单或聊天工具里就没问题”。审查的重点在于是谁写的、以及它是否实际上发挥了指挥命令的作用。

只按”人数×单价”计算的合同很危险。第1集问8指出，如果不是以产品或作业的完成来接单、发单，而是以投入的劳动力（人数）来接单、发单，并按劳动力的单价结算，这就属于单纯的劳动力提供，会被判断为伪装承揽。准委托合同本身按时间或工时来结算并不会因此被否定，但如果合同书中没有写明业务内容，只写着”工程师○名，单价○日元”这种合同，就很容易被评价为劳动力的提供。前提在于，合同能够明确委托的究竟是什么业务。

5.1．逐渐越界的现场 ── 用于说明的虚构情景

以下并非真实案例，而是把前文所列的基准组合起来、用于说明的虚构情景。不过，其中出现的每一个要素，都对应上表违规一侧的内容，或后文提到的实务事项。

制造业的A公司，将业务系统的改造以准委托方式委托给B公司。B公司的1名工程师常驻在A公司。合同书中只写着”业务系统改造支持 一式”，费用按”1人×月度单价”结算。B公司的管理责任人由这名常驻工程师本人兼任。到这里为止，还是许多现场都可能出现的起点。

• 4月：A公司的负责人开始在晨会上直接向工程师指示作业顺序，”今天请先做这个画面”。原因是项目紧急，等联系B公司再等回复太浪费时间。
• 6月：因为临近月底结算，A公司的负责人直接对本人说”这周请加班”。
• 9月：A公司的其他部门向本人发来”顺便也把Excel宏改一下”的请求。由于合同书未明确业务内容，现场没有拒绝的依据。
• 12月：工程师身体出现问题，究竟是谁在管理其劳动时间，成了问题。

到这一步，第4章所述劳务管理上的独立性中，”业务执行管理”与”劳动时间管理”两项均已不成立。此外，合同未明确业务内容、按人数×单价结算（第1集问8），以及1人常驻且由本人兼任管理责任人（第1集问4）这两个因素也叠加在了一起。在整改阶段，需要重新签订合同、重建体制、暂时撤回常驻人员等应对措施，项目将陷入停滞。

另外，是否会进一步发展到视为已提出劳动合同要约制度，还需要另外判断是否存在”以规避劳动者派遣法等适用为目的”这一要素。不过，在此之前的行政指导与合同重签，无论是否存在该目的，都有可能发生。

令人担忧的是，这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，明确了这一思路同样适用于敏捷型开发以外的系统开发。

要点如下。

• 密切协作、信息共享、技术性的建议与提案都没有问题。如果发包方与受托方的开发相关人员作为一个团队随时共享信息，在对等的关系下协作，且受托方的开发人员被认定为是在自主判断的基础上推进开发，那么就不构成伪装承揽（Q2、Q5）。
• 产品负责人（Product Owner）对待办列表的说明同样没有问题。发包方的开发负责人直接向受托方的开发人员详细说明产品待办列表（Product Backlog）的内容、提供开发所需的信息，这件事本身并不成问题（Q4）。
• 界线依然在于指挥命令。如果这种说明或讨论，实际上变成了关于业务执行方法或劳动时间的指示，那就构成伪装承揽（Q4、Q5）。当进度出现延误、需要就工作分配、顺序、缓急进行调整指示时，这项工作本应由受托方的管理责任人来完成；如果由发包方直接进行，即便已经选任了管理责任人，仍会被判断为伪装承揽（Q3）。
• 事先的机制设计很重要。建议事先明确并就双方的角色与权限、团队内部的业务推进方式达成一致，并通过相关人员的培训等，共享”敏捷开发是由开发人员自主推进的”这一认识（Q2）。

也就是说，并非因为采用敏捷开发就更容易构成伪装承揽，而是当打着自主团队的名义，实际上却由发包方在调动成员时，才会构成伪装承揽。只要能够将Scrum中的”自我组织化团队”落实到实际运作中，采用准委托合同的敏捷开发就是制度上原本设想的工作方式。

8．承揽、准委托、派遣，应当如何选择

最后梳理一下，究竟应该选择哪种合同才合适。

需要注意的是，不要出于”想下达指挥命令，却又想规避成本与义务”的心态而选择准委托。这不是合同选择，而是伪装承揽的入口。如果作为发包方确实有直接管控的需求，正确的顺序应当是改用派遣合同，或者研究能否通过受托方的体制（经由管理责任人运作）来满足这一需求。

总结

• 是否构成伪装承揽，判断依据不是合同书上写的名称，而是发包方是否对受托方的劳动者直接下达了指挥命令这一实际情况。即使签订的是准委托合同，也可能构成伪装承揽
• 承揽与准委托，都是不会在发包方与工程师之间产生指挥命令关系的合同，唯有劳务派遣才能直接下达指挥命令
• 判断基准是37号告示。需要同时满足：业务执行、劳动时间、岗位安排的管理由受托方自行进行（劳务管理上的独立性），以及依靠资金、责任、专业技术独立处理业务（事业经营上的独立性）
• 日常闲聊、说明规格、向公司提出要求、对等的技术性讨论都没有问题。向个人分配任务、直接指示作业步骤、直接指示加班、指名或要求更换特定成员，都是伪装承揽的信号
• 常驻与座位混杂本身并不构成伪装承揽。危险的是像”1人常驻＋本人兼任管理责任人”这样、导致委托直接等同于对个人下达指挥命令的体制
• 只要对等协作以及受托方成员的自主判断在实际中成立，敏捷开发就不构成伪装承揽。这一思路同样适用于敏捷以外的开发
• 伪装承揽的风险不仅限于行政指导与刑事处罚，根据视为已提出劳动合同要约制度，发包方还可能被视为已向工程师提出了劳动合同要约
• 如果拿不准，可以向都道府县劳动局咨询。关于是否符合视为已提出劳动合同要约制度的情形，劳动局也设有提供建议的机制（劳动者派遣法第40条之8）

致正在考虑受托开发与技术支持推进方式的您

如果您希望委托外部工程师进行开发，或者对现有的常驻、支持形态是否合适感到担心，首先应当梳理清楚两点：”想要委托的是什么（完成品、业务，还是劳动力）”以及”由谁来下达指挥命令”。只要这两点确定下来，究竟该以承揽、准委托还是派遣哪种形式来组建，体制与窗口该如何设计，就自然而然能够确定。

合同会社小村软件（合同会社小村ソフト）以Windows应用程序为中心，承接受托开发与技术支持，无论是承揽还是准委托的形式，我们都可以承接。我们以明确业务范围与成果物的合同、通过窗口与汇报推进项目为基本原则，即便您尚处于”不知道该如何划分委托内容”的阶段，也欢迎咨询。

准委托合同只要运用得当，非常适合需求尚未完全确定的开发，以及持续性的改进工作。请从让合同形式与现场工作方式保持一致做起，构建一个发包方与受托方双方都能安心协作的体制。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

SES与准委托合同是同一回事吗？

SES（系统工程服务）并非法律用语，而是业内对以劳务形式提供工程师技术能力这种交易的实务惯用称呼。签约形式多采用准委托合同，但称之为SES还是准委托，与合法性的判断无关。真正被判断的，是发包方是否直接对受托方的工程师下达了指挥命令这一实际情况。

在准委托合同下常驻发包方的办公室工作，是否有问题？

常驻本身并不构成问题。厚生劳动省的疑义应答集中也指出，仅凭发包方的劳动者与受托方的劳动者在同一场所混杂工作这一点，并不能就此判断为伪装承揽。真正成为问题的不是场所，而是指挥命令。即使常驻，只要业务指示、劳动时间管理、岗位安排的决定都由受托方公司自行进行，就是合规的；反过来，即使是远程工作，只要发包方直接下达指挥命令，同样可能构成伪装承揽。

发包方能否直接向受托方的工程师提问或提出请求？

日常性的交谈、对规格或需求的说明、提供信息，以及在对等立场上进行技术性的讨论、建议、提案，仅凭这些并不会构成伪装承揽。但如果发包方直接向受托方的工程师下达作业方法或顺序的指示、向个人分配任务、指示加班或休息日出勤，就会被视为指挥命令，判断为伪装承揽。新的委托或作业指示，原则上应当经由受托方的管理责任人（窗口）来进行。

一旦被判断为伪装承揽，会产生什么后果？

会作为违反劳动者派遣法的行为，成为劳动局指导与整改的对象；如果构成无许可的劳务派遣或劳动力供给，还可能成为刑事处罚的对象。此外，根据视为已提出劳动合同要约制度，如果是以规避劳动者派遣法等适用为目的实施了伪装承揽，就会被视为发包方已向该工程师提出了劳动合同要约，只要工程师在1年以内做出承诺，发包方与该工程师之间的劳动合同即告成立。这对发包方与受托方双方而言，都是重大风险。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。