ツボ【6】アジャイル開発版「情報システム・モデル取引・契約書」
前回のnoteが2019/4だったので，丸っと1年ぶりになってしまいました。この間に，経産省・IPAからモデル契約の改正民法対応のワーキンググループWGのお仕事もさせていただきましたが，今回紹介するのは，もう１つのWGである「DX対応モデル契約見直し検討WG」の成果物であるアジャイル開発版「情報システム・モデル取引・契約書」です。
WGがもっとも伝えたかったことは，「正しく使ってほしい」ということ
2020年3月31日に，IPA（情報処理推進機構）が，DXに対応した情報システムの開発契約として，アジャイル開発向けのモデル契約書をリリースしました。
本文は，PDFで64頁と大部であり，その多くは契約条項の解説に費やされていますが，その特徴は，前半部分で「用法用量を守って正しくお使いください」というメッセージに溢れているところにあります。要は，DXだ，アジャイルだといって，モデル契約書に飛びついてはいけない，という注意です。
上記のリンク先からもWGからのメッセージを読むことができます。
開発に着手する前に、開発の当事者であるユーザ企業及びベンダ企業が、ともにアジャイル開発に関する適切な理解を有していることを確認し、その活用に対する期待を共有しておく必要があります。
アジャイル開発が、要件を曖昧にしたままでも必要な機能がすぐに開発されるというように、あたかもユーザ企業にとっての魔法の杖のように思われているとすれば、そのような考えは改められなければなりません。ユーザ企業が、自らの今後のビジネスにどのようなプロダクトが必要なのか、なぜ必要なのかを十分検討し、利害関係者と調整のうえ、開発プロセスの中でタイムリーな意思決定をしなければ、開発は期待通りには進みません。
また、実際に開発を行うためには、ベンダ企業とユーザ企業の緊密な協働が必須です。相互にリスペクトし、密にコミュニケーションしながらプロダクトのビジョンを共有して開発を進めることが求められます。関係者はこのことを肝に銘じておく必要があります。
などのフレーズが目に飛び込んできます。契約書ひな形だけが独り歩きして，実態と乖離してしまうことは避けたい，せっかく作ったモデル契約は実務に役立つものにしたい，というWGメンバーの強い思いが伝わってきます。
準委任契約を採用
ここで採用されている契約形態は「準委任契約」です（モデル契約1条）。
あらかじめ内容が特定された成果物を予定したとおりに完成させることを義務付ける請負契約より、専門家としての注意義務を果たしながら業務を遂行することを義務付ける準委任契約の方が、その性質上、アジャイル開発契約には馴染み易い。（8頁）
こうした記述を見かけると，拒絶反応を示す発注者（ユーザ）の担当者もいるかもしれません。しかし，アジャイルがおよそ請負契約と馴染まないと言っているわけではなく，このモデル契約が想定している取引・開発形態が準委任契約が適していると言っているにすぎません。開発形態によっては，請負契約の下で進められるアジャイル開発もあるということが言及されています（9頁）。
また，準委任契約だからといって，ベンダの義務が軽いというわけではなく，高度な専門家としての注意義務を果たされることが求められています。
契約条項の特徴
このモデル契約の特徴は，冒頭の2条からも見て取ることができます。
第 2 条（アジャイル開発方式）
1. 甲及び乙は、本プロジェクトにおけるアジャイル開発の方式としてスクラムを用いるものとし、別紙第 4 項記載のとおり、主にプロダクトオーナー、スクラムマスター及び開発者からなるチーム（以下「スクラムチーム」という。）を組成して開発を行う。
2. 本契約における開発の対象は、別紙第 2 項記載のプロダクト（以下「開発対象プロダクト」という。）とし、甲及び乙は別紙第 3 項記載のスケジュールに従って開発を行う。
3. 甲は、開発対象プロダクトに関する甲の要求事項（開発する機能のほか、非機能要件への対応、リファクタリング、文書作成等の関連業務を含む。）及びその優先順位について乙と協議を行い、プロダクトバックログ（甲の要求事項を列挙して優先順位を付けたリストをいう。）を作成する。
4.（以下略）
そのほか，第3条（体制），第4条（甲（ユーザ）の義務），第5条（乙（ベンダ）の義務），第6条（変更管理），第7条（問題解消協議）あたりは，従来型のウォーターフォール型モデル契約や，民法の条文をなぞっただけのものとは大きく趣が異なって具体的・実務的な記載が多くみられます。言い換えれば，抽象度を高めた契約書ではないため，個々の取引・案件に応じてカスタマイズする必要が高そうです。このあたりも「用法用量を・・」ということが当てはまります。
また，完成責任を負わない準委任契約であることが明記されていることから，納入，検査・検収，契約不適合責任といった規定はいっさい置かれていません。
その他，知財権の帰属や一般条項等は，従来のモデル契約と大きな違いはありません。なお，第21条（損害賠償）では，「実際に支払った委託料の合計金額」を上限とするようになっています。
偽装請負とアジャイル
システム開発の業界では，偽装請負がホットトピックの一つです。厚労省のいわゆる37号告示やそのQ&Aを見ると，なかなか厳しい区分がなされていて，現場からは「そんな厳しい基準だとやってられない」という声もあがります。さらには，アジャイルになると，「偽装請負を（完全に）避けようと思ったらアジャイルは採用できない」という声すら聞きます。
ややアンタッチャブルかと思われたこの問題に対し，本モデル契約は正面から検討しています（16頁以下）。単に結論のみを示すのではなく，「ある委員から・・という意見が出された」「この意見に対し，複数の法曹資格を有する有識者委員から、賛同の声が上がり」といった詳細な議論の過程が示されており，この貴重な議論はもっと広く目に留まるべきだろうと思います。
アジャイルに関する開発現場と法務の架け橋
私自身，ウォーターフォール型開発は90年代後半から00年代にかけてどっぷりと浸かっていた一方，アジャイル型開発は，現場での経験はありません。00年代前半にはすでに「これからはアジャイルだ」とも言われていたものの，それほど多く浸透している印象はなく「アジャイルもどき」が広がっているだけなのではないかという疑念もあります。
今回のモデル契約は，さまざまな形態があるアジャイルの中でも特定のスタイルを念頭に置きつつ，「理想形」を目指したものだと思われますが，正直なところ，実務がどこまで追随してくるかは未知数です。しかし，このモデル契約（及びその付属資料群）を通じて，ベンダとユーザ，あるいは，開発現場と法務のアジャイルに対する理解が深まることが期待されます。
ユーザとしては，「準委任契約での開発？それで責任取ってくれるの？」みたいな固定観念ではなく，逆にベンダとしては，「アジャイルだから完成責任を負いません」で責任逃れに終始するのではなく，当事者間の役割を理解するためのツールになるのではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？