アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(後編)。Agile Japan 2021

2021年11月16日

アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。

すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか? という疑義が以前から呈されていました。

この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」として公表されています。

オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応答集の策定にも関わった、弁護士でIPA専門委員でもある梅本大祐氏によるセッション「アジャイル開発の外部委託は偽装請負になるのか ~長年の疑問に答える厚労省Q&A集の紹介~」が行われ、疑義応答集に関する詳しい解説が行われました。

日本の企業におけるアジャイル開発の実現は、ほとんどの場合において外部ベンダとの協力なしには考えられないでしょう。その意味で、アジャイル開発に関わる多くの人にとって、重要な解説だったといえます。

この記事ではその内容をダイジェストで紹介します。

(本記事は前後編に分かれています。いまお読みの記事は後編です。前編はこちら

スキルシート提出の要求は大丈夫か?

Q7は少し毛色の違う内容で、スキルシートに関するものです。

アジャイル開発の場合、わりと少人数でチームを組むこともあって、メンバーのスキルが非常に重要だと思うのですが、発注者が特定のメンバーを指名してしまうと、人員配置にかかわったとして偽装請負になるおそれがあります。

個人氏名はしないが、発注者から受注者に、開発担当者の技術のレベルや経験年数などを記載したスキルシートの提出を求めたいが、これは問題あるか、というのがこの問いです。

fig

答えとしては、発注者が、受注者が雇用する技術者のシステム開発に関する技術のレベルと、当該技術・技能に関わる経験年数等を記載したいわゆる「スキルシート」の提出を求めたとしても、それが個人を特定できるものではなく、発注者がそれによって個々の労働者を指名したり特定の者の就業を拒否したりできるものでなければ、偽装請負にはならないとしています。

逆に言えば個人名が書いてあったり個人を特定できるものになっていると、偽装請負になるリスクがあるということになります。

アジャイル開発でも偽装請負になる例はある

以上がこの今回の疑義応答集の大体の内容になります。これで過剰に心配する必要がなくなった、ということは言えると思います。

ただ、アジャイル開発なら偽装請負にならない、というわけではありません。偽装請負になりうる例をいくつかピックアップしました。

fig

それではどうすれば偽装請負のリスクを下げられるか。疑義応答集を踏まえると以下が考えられます。

fig

1つは、発注者からの業務の割り振りとか進め方、稼働時間などの要望は、管理責任者を置いて、偽装請負の指揮命令に当たるようなリスクのあることは管理責任者経由で受けて検討するようにし、直接指揮命令に及ぶようなことが個別のメンバーに対して起こらないようにしておくことです。

そのために、そういう事項を協議する会議は管理責任者が出席するようにアレンジしておく、ということが考えられます。

もう1つは、受注者側の開発担当者が自律的に判断して開発業務を行える状況にあることを、客観的に説明できるようにしておくことです。

先ほどから何度も自律的、自律的と出てくるのですが、実際、偽装請負があるかどうかについて労働局が来て調査をした際に、ちゃんと開発担当者が自律的に判断して開発業務を超える状況にありますよと客観的に説明できるようにしておくべきです。

具体的には、契約書とかその他の合意文書において発注者と受注者の関係者の役割分担とか権限、開発の進め方をなるべく詳細かつ具体的に書いておくことが考えられます。

また、アジャイル開発に関する研修などをして、アジャイル開発はそもそも開発担当者が自律的に開発を進めるものというアジャイル開発の特徴を、発注者と受注者の関係者がちゃんと理解し、認識を合わせておくことが重要になります。

この辺りは疑義応答集のQ2に示唆がありました。

fig

アジャイル開発で偽装請負とみなされないために

さて、アジャイル開発で偽装請負と見なされないための対応なのですが、IPAで出しているモデル契約と関連資料が活用できると思います。

fig

これはIPAモデル契約の条項の一部ですが、この3条というところでは、別紙で定めた業務をそれぞれ同項記載の役割分担に従って行う、とあります。この別紙に役割分担を詳しく書いて明確にしておくことが有効です。

また、「実施責任者」、これはつまり管理責任者ですが、それを置いて、指示や要請、依頼などの連絡はその人を通じて行うということも規定しています。

fig

モデル契約の付属のドキュメントとして、「アジャイル開発の進め方の指針」というのがありますが、そうした文書を通じて進め方を確認し、発注者・受注者間で認識を共通化しておく、というのも一つのリスクヘッジのやり方になります。

fig

さらに、契約前チェックリストというのも用意しているので、これもお互いの理解を共有するために使えると思います。

fig

これらを活用することで、アジャイル開発における偽装請負リスクを低減できることになります。

私からの説明は以上です。ご静聴どうもありがとうございました。

参考資料

厚労省の疑義応答集とIPAのモデル契約へのリンク

あわせて読みたい

DevOps アジャイル開発 IPA




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本