システムやソフトウェア開発の分野で主流になりつつある「アジャイル開発」。
「計画→設計→実装→テスト」という開発工程を最小限の機能単位のサイクルで繰り返す開発手法で、開発期間を短縮でき、途中の設計変更など柔軟性にも優れていると言われており、導入が進んでいる企業もあるでしょう。
ただ、「アジャイル開発」の運用にあたっては、その特性から開発チーム内の綿密な連携が不可欠となります。そのため、企業がプロジェクトを外部委託する場合、受注した企業のエンジニアに直接指揮命令を出すことを禁じた労働者派遣法（偽装請負の禁止）に触れる可能性があり、アウトソーシング活用の大きな障壁となっていました。
こうした課題を解消するために厚生労働省は、2021年9月、「偽装請負にあたらない」ための具体的な判定基準を公表しました。これにより、アジャイル開発のアウトソーシングを活用しやすくなります。
ポイントは、受注側のエンジニアが「支配や制約を受けず、自律的に判断して開発に携わっているか」にあります。
本コラムでは、偽装請負だと疑われないための対応と留意点について解説します。
人材活用に関するお役立ち情報をお送りいたします。
「アジャイル開発」と「ウォーターフォール開発」の違い
「アジャイル開発」は、事前に詳細な設計や試行を済ませてから進める「ウォーターフォール開発」よりも機能的とされ、独立行政法人の情報処理推進機構によると、すでに日本企業の約2割が「アジャイル開発」を導入しています。
「アジャイル開発」が抱えていた偽装請負リスク
自社の社員が他社の従業員からの指揮命令を受けてその他社の業務に従事する場合、国から「派遣事業許可」を得なければならないと、労働者派遣法で定められています。
「アジャイル開発」は、発注者と受注者がチームをつくり、課題や不具合、アイデアを共有、提案し合ってコミュニケーションを深めていく流れを繰り返します。他社から「アジャイル開発」を受託した場合、発注者とのやり取りが労働派遣法に抵触し、偽装請負と指摘される可能性がありました。
偽装請負と判定されると、発注者と受注者の双方に罰則があります。
「偽装請負」と疑われないためのポイントQ＆A
この問題を解消し、日本のDX推進を妨げないよう厚生労働省は2021年9月、「アジャイル開発」に絞って「偽装請負と疑われないための判断基準」を公表しました。
偽装請負か否かのポイントは、「自律的に判断して開発に携わっているか」。
アジャイル型開発の定義 ～下記３点を満たすもの～
開発要件の全体を固めることなく開発に着手し、市場の評価や環境変化を反映して開発途中でも要件の追加や変更を可能とするシステム開発の手法。
発注者側の開発責任者と発注者側及び受注者側の開発担当者が対等な関係の下でそれぞれの役割・専門性に基づき協働。
情報の共有や助言・提案等を行いながら、個々の開発担当者が開発手法や一定の期間内における開発の順序等について自律的に判断。
アジャイル型開発と契約方式
- Aはい、労働者派遣と請負等（委任、準委任を含む）の区分は、「労働者派遣事業と請負により行われる事業との区分に関する基準（告示37号）」に基づき実態に即して判断します。
基本的考え方
- A実態として、発注者と受注者の関係者が対等な関係の下で協働し、受注者側のエンジニアが自律的に判断して開発業務を行っていると認められる場合であれば、偽装請負と判断されるものではありません。
Point
- 発注者側と受注者側の開発関係者のそれぞれの役割や権限、開発チーム内における業務の進め方を予め明確にし、双方の間で合意しておくこと。
- 発注者側の開発責任者やエンジニアに対して、アジャイル型開発に関する事前研修を行い、エンジニアが自律的に開発業務を進めるものであることを共有しておくこと。
管理責任者の選任
- A両者が対等な関係の下で協働し、受注者側のエンジニアが自律的に開発業務を進めている限り、受注者側の管理責任者が会議や打ち合わせに同席していない場合があるからといって、直ちに偽装請負と判断されるものではありません。
Point
- 発注者側の開発責任者やエンジニアが、直接受注者側のエンジニアに指揮命令を行ってしまうと、たとえ受注者において管理責任者を選任していたとしても偽装請負と判断されることになります。
発注者側の開発責任者と受注者側のエンジニア間のコミュニケーション
- A開発業務の前提となるプロダクトバックログの詳細説明や、開発業務に必要な開発要件を明確にするための情報提供を行ったからといって、直ちに偽装請負と判断されるものではありません。
Point
- 受注者側のエンジニアに対する業務の遂行方法や労働時間等に関する指示などの指揮命令と認められるような場合には偽装請負と判断されることになります。
開発チーム内のコミュニケーション
- A両者間において、対等な関係の下でシステム開発に関する技術的な議論や助言・提案が行われ、受注者側のエンジニアが自律的に開発業務を進めているのであれば、偽装請負と判断されるものではありません。
Point
- 発注者側のエンジニアの助言・提案や技術的な議論における言動が、実態として、受注者側のエンジニアに対する業務の遂行方法や労働時間等に関する指示などの指揮命令と認められるような場合には、偽装請負と判断されることになります。
会議や打ち合わせ等への参加
- A全員参加している場合でも、それらの場面において、実態として、両者が対等な関係の下で情報の共有や助言・提案が行われ、受注者側のエンジニアが自律的に開発業務を進めているのであれば、偽装請負と判断されるものではありません。
Point
- 受注者側が管理責任者を選任するなどして受注者自らが指揮命令を行うなど、適正な請負と判断されるような体制を確立しておくことが必要です。
エンジニアの技術・技能の確認
- A発注者が特定の者を指名して業務に従事させたり、特定の者について就業を拒否したりする場合は、適正な請負とは認められません。
Point
- 「スキルシート」の提出を求めたとしても、それが個人を特定できず、発注者が個々の労働者を指名したり特定の者の就業を拒否したりできるものでなければ、「スキルシート」の提出を求めたからといって直ちに偽装請負と判断されるものではありません。
メルマガ登録
最新のセミナー情報、コラム・お役立ち情報などをお届けします。
関連サービス
