1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

受託アジャイルAdvent Calendar 2022

Day 2

受託アジャイルの契約形態について

Last updated at Posted at 2022-12-01

はじめに

アジャイルを始める際によく「請負」か「準委任」かどうすれば良いのか?と聞かれることがあります。
その際の考え方です。

最初に読むべき情報

まずここを読んでください。話はそれからだ!って感じ。
細かいところは読んでもらったであろうとして、個人的な解釈を以下に載せておきます。

個人的な解釈

アジャイルかどうかを論点にせず、「請け負えるかどうか」で決める

アジャイルかどうかを論点にしない
そもそも「請負」か「準委任」かについて「アジャイルかどうか」を基準にしない。
「アジャイル」が結構なバズワードになっていて、「アジャイル」が意味するところがかなりブレてます。
特に契約の場面では不明確な言葉を基準にすると痛い目を見ることになると思いますので、確実な表現で会話しましょう。

請け負えるかどうか
請け負えるってのは「事前に開発スコープが明確」「作業内容が見積もり可能であり、ブレる範囲が少ない」「ここは任せてくださいよ!問題あったら会社として責任取りますよ!と言い切れる」ケースです。

一般的に「アジャイル開発」は「スコープが不明瞭な案件」に向いていると言われており、「スコープが明確な案件」ではあまり使われません。
こういった背景があって「アジャイル開発は準委任が適している」という話になります。

偽装請負に関して

今までは偽装請負と判断される可能性が高いと判断されることが多く、受託アジャイルはなかなか進みませんでした。
そこに対して厚労省が回答したものが2021年に公開され、一定の対処方針が示されています。

基本的なポイント
pptなのでリンクがダウンロードになっちゃっうんですけど、一応上のIPAのページの中にある資料です。
講演資料:アジャイル開発の外部委託は偽装請負になるのかAgile Japan 2021 Day0講演資料(PowerPoint:160KB)

特に重要なポイントは以下です。

受託者側の開発担当者が自律的に判断して業務を行なっていると認められるケースは問題ないと厚労省が言っている 資料。

細かいポイントはざっくり以下です。詳細は資料見てね。

  • 自律的に作業できている場合は、作業内容についてすり合わせる会議体に管理者が必ずしも参加しなくても良い。(参加した方が偽装請負リスクは低い)
  • 自律的に作業できている場合は、コミュニケーションツールなどで発注側と受注側の配下メンバーが直接会話しても良い。(会話しない方が偽装請負リスクは低い)

自律的に作業できているとは?
厚労省の回答。

  • 発注者と受注者の関係性が対等であること
    • 受注者側が発注側の提案に従う必要がない関係性であること
  • ただし業務の遂行方法や労働時間に関する指示については、指揮命令があるように見えるため、偽装請負と判断される。

個人的な補足

実際にどうやっているか

  • 契約形態:受託アジャイル案件は全部準委任です。(観測範囲内に限る)
  • 偽装請負関連:
    • 会議体に関してはなるべく管理者も出るようにしている。(出れない時もある)
      • 発注側・受注側で対等な議論をした結果として、受注側としてじゃあどうしようね?って迷うケースもあって、その時に受注側の判断者がいるとスムーズなので。
    • コミュニケーションツール(チャットやJira)は発注側も受注側も関係者は全員参加して会話している。
    • 「自律的に判断」が必要ってのを随所で伝えている。(折に触れて伝えているとしか言いようがない)

瑕疵担保責任

請負から準委任にすることで瑕疵担保責任がなくなることを嫌がるお客さんを見かけたりするのですが、個人的には以下観点でメリットが上回る場合にのみアジャイルをお勧めしています。
というか、上回らないのであれば請負でウォーターフォールでやった方が良いと思う。

メリット:方向転換の高速化
私が思うに受託アジャイルで得られるメリットは「開発途中の方向転換のオーバーヘッドコストの低減」です。

請負開発の場合、頻繁な仕様変更は管理の手間が非常に大きくなりやすいです。既存の契約範囲を変更することに同義となるため、都度見積もりを行い、受注側でも発注側でも承認プロセスを回す必要があります。
頻繁な仕様変更はコストもかかりますし、期間もかかってしまうため、請負契約ではビジネスメリットが薄いです。

特に市場の変化は目まぐるしく、タイミングに乗り遅れると他社に市場を取られてしまう事になるため、このビジネスメリットは非常に大きいと思われます。

デメリット:瑕疵担保責任
請負契約が基本だった関係性から、準委任契約に変えようとする場合「瑕疵担保責任」が話題に上がるかと思います。(瑕疵担保責任=リリース後一定期間内の不具合については無償で直します責任)
色々な解決法があるかと思いますが、具体的なやり方まで言及するのはちょっと厳しいので、自社の法務と相談ください。

発注先のベンダーにもよると思いますが、ある程度の品質が期待できるのであれば、瑕疵担保責任で賄えるリスクよりも、タイミングよく市場に投入できるメリットの方が上回るとは思っています。

注意事項

  • あくまで個人の見解であって、会社を代表するものではないです。
  • 法律は素人なので、何かしらを保証するものではありません。
  • ちゃんと自社の法務に確認してね。

次回予告

社内で、あくまで1現場としてアジャイルを始めるためにどうアプローチすれば良いか、みたいな話を書きます。

おまけ

まだ買ってもないけど、こんな本が出たらしいので、こんな記事よりこういうちゃんとした法律家が書いたものを読むのが良いと思うます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?