IPA の アジャイル開発版「情報システム・モデル取引・契約書」

IPA から アジャイル開発版「情報システム・モデル取引・契約書」が公開された。

【プレス発表】
DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開
https://www.ipa.go.jp/about/press/20200331.html

【成果物公開ページ】
https://www.ipa.go.jp/ikc/reports/20200331_1.html

私はこの1年間、IPA の「社会実装推進委員会 モデル取引・契約書見直し検討部会 DX対応モデル契約見直し検討WG」の委員としてこのモデル契約書の策定に関わってきた。
モデル契約策定にあたって、私が特に実現できてよかったと思うことを書いていきたい。

準委任契約を前提とすることができた

2012年にIPAから出された「非ウォーターフォール型開発に適したモデル契約書」(当時、IPAではアジャイルと言わずに非ウォーターフォールと言っていた)には請負型と準委任型の2通りが存在する。
契約形態をどうするかというのは今回のWGでも議論になったが、早い段階で準委任型一本に絞ることで委員の意見が統一できたことはとてもよかった。

ユーザ企業がPOを選任すると言い切った

これも委員のあいだで非常に議論になったところである。ユーザ企業の担当者が忙しくPOを立てられない場合があるのではないかというような意見もあがったが、そもそもそういったケースではアジャイル開発をスタートしてはいけないのではないかというところに落ち着いた。モデル契約だけでさまざまなケースに対応するのではなく、ユーザ・ベンダ双方がアジャイル開発が適する条件やその適切な進め方を正しく認識できるよう啓発していくとが大事だという結論に至った。

なお、準委任契約を前提とすることやユーザ企業がPOを選任する理由については私が同人誌『アジャイルコーチからのアドバイス』に寄稿した文章があるので、一部抜粋してご紹介する。

スクラムではプロダクトオーナー、スクラムマスター、開発チームという3つのロールが定義されている。さらに、スクラムチームの外側にステークホルダー(実際にプロダクトを使うユーザーやプロダクトを持っている組織の役員や上司など)が存在する。

アジャイルと契約(図表).005


ユーザーとベンダが開発を進めていく場合には、プロダクトオーナーをユーザーとベンダのどちらがやるのかというのがポイントになる。
プロダクトオーナーはプロダクトの価値を最大化することに責任を持つ。そのためにプロダクトバックログの優先順位を決める。契約形態とプロダクトオーナーの所属(ユーザーかベンダか)を2軸で整理したのが下の表である。

アジャイルと契約(図表).006

ベンダがプロダクトオーナーを担い、請負契約をするのであれば、これは完全に丸投げである。これではユーザーがオーナーシップを発揮しているとは言えない。
では、ベンダがプロダクトオーナーを担い、準委任契約ならどうだろうか。ベンダにとってはリスクのない形となるが、ここまでコントロールを預けてしまってはユーザーは本気で開発に取り組んでいるのかどうが疑問である
ユーザーがプロダクトオーナーを担い、請負契約をするなら、ユーザーがいかようにもプロダクトバックログの優先順位を変更できるにも関わらず、完成責任をコミットメントしなければならないということで矛盾が生じる。
このようにユーザーとベンダが相互に担う役割の視点から考えても、ユーザーがプロダクトオーナーを担当し、準委任契約で進めるのが最適と言えるだろう。

そもそも契約が問題なんじゃない

契約の前に、アジャイル開発に対する理解を深める
~DX 対応モデル契約見直し検討 WG からのメッセージ~
https://www.ipa.go.jp/files/000081483.pdf

そもそも契約が問題なのではなく、アジャイル開発をユーザ・ベンダ双方が都合よく解釈していたり、アジャイル開発を適用するための前提条件が揃っていないのに無理にアジャイル開発をやり方を当てはめてしまったうことがトラブル原因としては多く見られる。
IPAからこのようなメッセージを出すことができたことは非常に意義深い。

担当者の変更は事前に通知

甲又は乙が、自らの業務従事者を変更する場合は、委託業務の遂行に支障を及ぼさないよう、事前に相手方に対し、新旧の業務従事者の氏名及び交替理由を書面により通知するものとし、変更に当たって十分な引継ぎを行わせるものとする。

そんなの当たり前じゃないかと思われるかもしれないが、トラブル事例として多い割にはなぜか契約の条文として盛り込まれていることが少ない。
アジャイル開発の性格上、チームやチームを構成するメンバーに寄るところが大きくなることから担当者変更はユーザ・ベンダが双方に納得した上で行ってほしいという意味からどうしてもこれは入れたかった。

契約金額の合意を開発チームで括った

別紙に契約金額を記載しているが個人毎ではなく開発チーム単位とした。これも私のこだわりである。アジャイル開発ではチーム開発が前提となることに加え、個人毎の単価×時間で契約をするという行為自体がソフトウェアエンジニアという高度な専門知識を持ったナレッジワーカーを「代替可能なリソース」「作業員」と捉えていることの表れであると感じていたためである。

また「作業」という言葉も当初たくさん使われていたが、ソフトウェアの開発に関わる仕事は創造的、探索的であり、専門家の知識と協調によって成立するものということで、「作業」という言葉は一切削除してもらった。

実施責任者は残念

甲及び乙は、それぞれ本件業務の実施責任者を選任し、本件業務に関する指示、要請、依頼等の連絡を行う場合には、双方の実施責任者を通じて行う。

唯一、心の残りがあるのは実施責任者の箇所である。現場の実態とかけ離れすぎている。WGで「ウォーターフォールでもそんなことやってないでしょう」と指摘したら他の委員には失笑されてしまった。
弁護士の先生方も知恵を絞ってくださり、さまざまな案を出してくださったのだが、労働関係法令との関連でここは変えられなかったのである。

アジャイル開発外部委託モデル契約(解説付き)に詳しい説明がある。

おわりに

1年間の議論を経て、実際の契約で使える契約書になったと思う。そして、私の立場でやれることは何とかやり切れたかなと思っている。私の所属する永和システムマネジメントでもぜひ活用していきたい。

ともに議論してきたWGの委員の方には感謝している。前向きで建設的な議論ができた。
そして、アジャイル開発そのもののことやアジャイル開発の現場のこと(状況や課題など)を真剣に理解してくださり、WGの議論を契約書に落とし、62ページにもおよぶ解説を書かれた弁護士の梅本先生には感謝を申し上げたい。

このモデル契約およびメッセージがさらなるアジャイル開発の活用に繋がることを祈りたい。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

78
(株)永和システムマネジメント アジャイルコーチ 2005年頃からXPを開発現場で実践。「まっとうなアジャイル開発」を標榜して日々コンサルティング活動に従事。 監訳書 : 『アジャイルプラクティス』、『アート・オブ・アジャイル デベロップメント』

この記事が入っているマガジン

マガジン2
マガジン2
  • 1312本
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。