読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

アジャイル開発モデルは準委任契約を結べば良いという誤解

Agile Project Management

最初に注意書きを。本エントリは法務面で専門家ではない私が個人として意見見解を述べているものであり内容を保証するものではない(他のエントリもそうなのだけれども)。アジャイル開発に関する諸契約については専門家(自組織の法務部門等)に確認していただきたい。なんとなく本邦のIT業界には「アジャイル開発モデルは準委任契約を結べば良いという誤解」があるような気がしている。今年、IPAから『日本におけるアジャイル開発に適した契約モデル案』などが出てきているので、それを改めて読みながら論点を整理したいと思った次第。

請負、準委任

いろいろ整理する前提として、請負、準委任というものについて簡単に整理しておく。私の理解が誤っている可能性もあるのでお気づきの点があれば指摘いただきたい。たぶんポイントは「民法上(契約法)」と「労働者派遣法」の2つのスタンダードがあるという事だ。

  • 民法上(契約法)の「請負、準委任」ざっくり
    • 請負:「請負人が仕事を完成し、それに対して注文者が報酬を与えることを約束することで他人の労務を利用する契約(民法632条)」⇒成果物の完成責任を負う
    • 準委任:「法律行為ではない一定の事務を処理することを相手方に委託し、相手方がその目的の範囲内である程度の自由裁量の権限をもって、独立して一定の事務処理行うことを承諾し、その対価としての報酬を支払うという形で労務を利用する形態(準委任、民法656条・643条)」⇒成果物の完成責任は追わない。ただし善意を持って管理遂行する義務がある
  • 労働者派遣法の「請負、準委任」ざっくり
    • 事業の独立性があれば請負(ここには準委任も含まれる)、そうでなければ派遣 ⇒契約後「独立して」作業できる内容でなければならない

これを踏まえて、日本におけるアジャイル開発に適した契約モデル案を読んでみたい。

日本におけるアジャイル開発に適した契約モデル案を読む

IPA日本におけるアジャイル開発に適した契約モデル案だと、結局のところは2つのパターンを提示している。なおここでは「請負・準委任」は区別していない。

  • 基本/個別契約モデル: プロジェクト全体に共通する事項につき、基本契約を締結する。その後、小さな単位(機能単位、リリース単位等)ごとに、開発対象と費用がある程度確定したタイミングで、個別契約(請負/準委任)を順次締結する。
  • 組合モデル: ユーザとベンダが共同でジョイント・ベンチャーとしての組合を組成し、協力してシステム開発(収益性のあるもの)を企画・製作する。開発された成果から得られた収益は、ベンダとユーザに分配される。

日本におけるアジャイル型開発向けのモデル契約案について(講演資料PDF)

「基本/個別契約モデル」は、要は「機能単位など、契約できる程度に内容が固まったものを個別契約する」ということになる。先ほどの整理で言えば、(労働者派遣法における)事業の独立性が確保できるくらい「何を、どの期間で作るかが決めて」契約するということだ。ただ、規模が大きくなった場合には契約が非常に煩雑になるのが課題だろう。

「組合モデル」は、ユーザとベンダーの合同組織を立ちあげて、そこで内製開発するというものだ。まぁ、理論的には理解できるのだけれども・・・スモールスタートにはそぐわないのが問題だと思う。

となると、消去法として「基本/個別契約モデル」を取らざるを得ない、もしくは別のスキームを模索せざるを得ないのではないかと思う。

じゃあ、あの会社はどうやっているのだろう

しかし世の中では様々な場所でアジャイル開発が盛り上がっている(第二次アジャイルブーム)。いったいどのように契約処理しているのかは興味が尽きないのだけれども、なんとなく以下となっているのではないかと考えている。

  • 外部エンジニアを活用せず、自社エンジニアで内製開発している
    • 一部の外部エンジニアは活用するけど、月・週単位などで「やること」をしっかりと合意して管理している
  • 外部エンジニアを派遣で調達している
  • ソフトウェア開発を請け負わず、ビジネスアウトソーシングのような形態で請負う(??)

上記のいずれにもあたらず、実際のところはいままでの契約スキーム(請負・準委任)で続けているということも多いとは思う。それが直ちにダメだという気はさらさらないけれども、「問題がある」という事くらいは押さえておいたほうが良いと思う。あとは個別に専門家(自組織の法務部門等)に確認していただきたい。

(あと、似たような課題は既存のウォーターフォール型開発にもあるのだけれども、それはまた別の話としておく。別にどちらの開発プロセスに肩入れするつもりも無い)