契約
アジャイル開発は請負か準委任か、IPAのモデル契約が選んだ答え
IPAのアジャイル開発版モデル契約は、成果物の完成に対価を払う請負ではなく、準委任を前提にしました。その理由を読むと、固定価格のアプリ開発がなぜ変更依頼のたびに揉めるのかが見えてきます
アジャイル開発について、IPAのモデル契約は請負ではなく準委任を前提にしています。請負は特定した成果物の完成に対価を払う契約、準委任は専門家として注意を尽くして業務を行うこと自体に対価を払う契約です。それでも請負を使うなら、仕様が比較的明確で開発が確定している部分だけに限り、仕様が固まるごとに個別の請負契約を繰り返す方法が望ましい、というのがIPAの答えです。
出典は、2020年3月に公開され、いまも更新が続いているIPAのアジャイル開発版モデル契約です。ユーザ企業、ベンダ企業、業界団体、法律の専門家が参加して作られたもので、どちらか一方に有利な書き方にはなっていません。
2つの契約類型
請負では、ベンダが決められた成果物を完成させることを約束し、対価はふつう事前の見積もりに基づく固定金額です。合意した内容と違えば、ベンダが責任を負います。
準委任では、ベンダは専門家として、善良な管理者の注意をもって業務を行うことを約束します(民法第644条、第656条で準用)。対価は、完成したものではなく業務そのものに払われます。
経済産業省の2018年の「DXレポート」は、日本では要件定義の段階から請負契約を結ぶケースも少なくないと指摘し、これを発注側からベンダへの「丸投げ」と表現しています(IPAのモデル契約の解説資料に引用されています)。結果にお金を払うほうが安心に感じるのは自然です。ページ構成の決まったWebサイトなら、たいていそれで正解です。実際のユーザーが触ってから変わっていくことが前提のアプリについては、モデル契約は逆の立場をとっています。
IPAが準委任を選んだ理由
解説は、アジャイル開発の性質から話を始めます。開発の途中で機能が追加され、変更され、優先順位が入れ替わる。ユーザ企業の判断で開発対象から外れるものもある。最初のリリースの後も改善が続く。あらかじめ特定した成果物の完成を義務づける契約とは、相性がよくありません。
そのうえで、アジャイル開発で一括の固定価格の請負を結ぶリスクを2つ挙げています。1つは対価と実際の工数が大きく離れるリスクです。範囲が膨らんだり、仕様変更で手戻りが出たりすると、ほとんど何も分からない時点の見積もりの負担をベンダが背負います。もう1つは利害対立のリスクです。対価が固定されていると、ベンダには変更を抑えたい理由ができます。アジャイルを選んだ目的とは正反対です。
発注側が実感するのは2つ目です。新しいアイデアがすべて変更依頼と交渉になり、プロジェクトの速度が、ユーザーに必要なものではなく契約によって決まっていきます。
準委任でもベンダの義務はある
準委任は「頑張ります」という約束ではありません。解説は、ベンダが契約本体と別紙で定めた範囲で誠実に自らの役割を果たし、プロダクト開発を進める義務があると明記しています。変更が代金やスケジュールに影響するときは、変更管理の手続きで両者が合意して契約を変えます。
変わるのは、リスクの置き場所です。準委任では、チームの時間と技能にお金を払うので、範囲が想定より大きくなるリスクは発注側に寄ります。その代わり、方向を変えるたびに契約を交渉し直さなくて済みます。
発注側が用意しなければならないもの
発注側が読み飛ばしがちなのはここです。モデル契約では、プロダクトの方向性と内容に責任を持つプロダクトオーナーをユーザ企業が選任します。開発チームが必要とする情報や意思決定を適時に提供し、ステークホルダーとの調整も担います。ベンダはスクラムマスターを選任し、バックログへの助言や技術的なリスクの説明を行います。
日本の発注側にとって、一番埋めにくいのはこのプロダクトオーナーです。DX人材の質が足りていると答えた企業が3.8%にとどまるのと同じ理由です。
IPAは、両者が記入する「契約前チェックリスト」も公開しています。アジャイルの提案を受ける前に読んでおきたい項目を抜き出します。
- プロジェクトの目的(少なくとも当面のゴール)が明確で、ステークホルダーと共有されているか
- 1チーム(最大で10名程度)の継続的な対応で開発できる規模か
- ユーザ企業が適切なプロダクトオーナーを選任し、権限を委譲できるか
- ベンダがアジャイル開発の経験を持つスクラムマスターを選任し、開発チームを固定できるか
- 本契約が準委任契約であることを両者が理解しているか
プロダクトオーナーについての答えが正直に言って「いいえ」なら、問題は契約類型ではありません。発注側に決める人がいないアジャイルは止まりやすく、AIのPoCが製品にならない理由とよく似た形で行き詰まります。
偽装請負の心配について
アジャイルのチームは直接、頻繁にやりとりします。そのため、ベンダのエンジニアと密に協働すると偽装請負とみなされないか、という懸念が出ることがあります。IPAは、厚生労働省が2021年9月21日に公表した「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)に関する疑義応答集(第3集)」を挙げ、これを参考に進めれば懸念の解消が期待できるとしています。社内で話題になったら、法務と一緒に読んでください。
それでも請負が合う場合
仕様が固まっている仕事もあります。キャンペーンサイト、ページ構成の決まったリニューアル、移行先の決まったデータ移行。こうした仕事には請負がよく合います。ウォーターフォール型の開発なら、2020年12月22日に公開された「情報システム・モデル取引・契約書」第二版が基準になります。工程ごとに個別契約を結ぶ形で、要件定義の作成支援は準委任、外部設計は準委任か請負を選び、ソフトウェア開発そのものは請負としています。
アジャイルでも固定価格にしたい場合、解説は中間の道を示しています。仕様が比較的明確で開発が確定している部分だけを請負にし、仕様が固まるたびにその部分の契約を結び直す。仕様を書ける部分にだけ固定価格を置き、残りは準委任のまま進めるやり方です。