DX対応・民法改正で変わる情報システム取引に関する契約③

はじめに

シナプスイノベーション 法務室です。

前回のブログでは、独立行政法人情報処理推進機構（IPA）と経済産業省が連名で公表した、
①情報システム・モデル取引・契約書の民法改正対応版（以下、モデル契約民法改
正対応版）
②アジャイル開発外部委託モデル契約～情報システム・モデル取引・契約書〈アジャイル開発版〉（以下、モデル契約アジャイル開発版）¹
のうち、①モデル契約民法改正対応版の概要と、そこで最大の論点となった契約不適合責任の起算点について解説させていただきました。
本日は、②モデル契約アジャイル開発版につき、その前提となる開発モデルを説明の上、本モデル契約の特色を簡単に紹介させていただければ、と存じます。

アジャイル開発
-従来のソフトウェア開発とは異なる手法-

モデル契約民法改正対応版をはじめ、従来の経産省モデル契約は、「ウォーターフォール型開発／モデル」による開発を前提としています。²
「ウォーターフォール型開発／モデル」は、ソフトウェア開発の工程を大きく「要件定義→設計→製造・開発→運用」に分け、各工程間での手戻りは行わない（ことが望ましい）とする開発モデルです。
従来より、一定以上の規模の開発では、この「ウォーターフォール型開発／モデル」をベースとして開発が行われることが多かったといえます。どの工程で何を行うのかにつき、（程度の差こそあれ）ユーザー／ベンダーのシステム担当者間で認識の一致も取れていました。

もっとも、この「ウォーターフォール型開発／モデル」では、「要件定義→設計」の工程を踏んでから初めて実際のソフトウェアの製造・開発に当たることになります。そのため、「要件定義→設計」の後にビジネス上でのシステムに対する要求や機能の優先順位が変わってしまうような場合に、必要な要求や機能の実装が難しくなってしまう、という問題点がかねてから指摘されていました。

経済産業省のデジタルトランスフォーメーションに向けた研究会が2018年に出した「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開」（以下、本稿では単に「DXレポート2018」といいます）でも、「今後、DXを実行していく上で、要求仕様が不明確な状態で小刻みな開発を繰り返すことで具体化していくような案件もある。このような案件では、開発手法として従来のウォーターフォール開発ではなく、アジャイル開発の方が適している場合がある」とされています。³

ただ、従来はアジャイル開発についてどのような契約を行えばよいのかにつき、実務での共通認識が取れていませんでした。これがアジャイル開発をシステム開発の現場に浸透させていく上での障害の1つとなっていました。

その障害を解消する試みとして、DXレポート2018での提言⁴を受け、IPA「モデル取引・契約書見直し検討部会」下の「DX対応モデル契約見直しWG〔ワーキンググループ〕」で検討された成果がモデル契約アジャイル開発版となります。

一口にアジャイル開発といっても様々な開発手法があるのですが、プロジェクト・チーム運営に関しては「スクラム」という手法を前提とし、開発のプラクティスについてはXP（エクストリーム・プログラミング）に由来するものを取り込んでいくもので説明がされることが多いです。⁵今回のモデル契約アジャイル開発版も、「スクラム」によりプロジェクト・チーム運営をしていくことを前提としております。⁶

スクラム
-スプリント毎に反復開発を行う開発手法-

スクラムとは、あるプロジェクトを、工程ではなく「スプリント」といわれる一定の時間枠（1週間～4週間）で区切り、プロダクトオーナー／開発チーム／スクラムマスターの三者が協働してスプリント毎に反復開発を行う開発手法のことをいいます。
上記のイメージを分かりやすく図解したものを、以下に引用します。⁷

ここで、プロダクトオーナー／開発チーム／スクラムマスターの役割について整理します。⁸「プロダクトオーナー」とは、簡単に言うと「何を開発するのかを決める人」です。開発チームに最も価値の高いソフトウェアを開発してもらうために、プロダクトに必要な機能を定義し、その機能を含む要求事項の優先順位を決定します。
「開発チーム」は、「実際に開発業務に携わる人々」です。従来のウォーターフォール型開発／モデルでは、各工程ごとの担当者が細かく分かれてくる事が多かったのですが、スクラムにおいては開発チーム内で明示的な区分けはあえて持たず、それぞれの従来の担当の垣根を越えて貢献することが求められる、とされています。

「スクラムマスター」は、「スクラムプロセスをうまく回し、生産性を高めることに責任を持つ人」です。スクラムチーム（開発チーム＋スクラムマスター）が自律的に協働できるよう、開発チームを支援し、スクラムチームをマネジメントする役割を担うことになります。

スクラムを前提としたソフトウェア開発についての契約書を作ろうとした場合、上記のような「プロダクトオーナー」「開発チーム」「スクラムマスター」の役割をどう落とし込むかが悩ましいポイントとなります。⁹これが、実務においてアジャイル開発を前提とした契約がなかなか用いられなかった原因の1つとなっていました。

モデル契約アジャイル開発版で特筆すべきなのは
優先順位を決定するのはユーザーであること

モデル契約アジャイル開発版では、スクラムチームにおける役割につき、ユーザー側から「プロダクトオーナー」を、ベンダー側から「スクラムマスター」を選任するという想定で整理されました。¹⁰

このような整理の背景には、〈実際にソフトウェア／プロダクト／システムを用いるのはユーザーである以上、どのような機能が必要かを定義し、優先順位を決定するのはユーザーであるべき〉、という価値判断があるように思われます。
モデル契約アジャイル開発版の解説でも、「…アジャイル開発はユーザ企業にとって価値の高いプロダクトの開発にあり、そのためにはユーザ企業が主体的に開発対象の管理・変更に関わる必要があるから、プロダクトに対して責任を持つプロダクトオーナーの職務自体をベンダ側に委ねるべきでない」とされています。¹¹
モデル契約アジャイル開発版の策定の契機となったDXレポート2018でも、「…ユーザ企業にとってはどのような機能が必要になるのかということをベンダー企業に任せればよいと誤解することがあり、プロダクトのオーナーシップの責任まで放棄してしまうと、結果的に開発がうまく進まない」とされています。³

コメント
-契約段階での説明、開発工程において手法の実践が重要-

〈実際にソフトウェア／プロダクト／システムを用いるのはユーザーである以上、どのような機能が必要かを定義し、優先順位を決定するのはユーザーであるべき〉という価値判断に対しては、ユーザーからは、「ソフトウェアについて専門的な知識があるわけでもないのに、プロダクトオーナーなんてできないのでは？」というご懸念が当然生じることになるか、と拝察いたします。

私見ですが、このようなご懸念に対しては、ベンダーとしてもアジャイル開発の理念を自社の開発にきちんと取り入れた上、ユーザーにその内容を丁寧に説明することで、真摯に向き合っていくべき、と考えています貼り

スクラムをはじめとしたアジャイル開発の根本的な理念の1つには「包括的なドキュメントよりも動くソフトウェアを」というものがあります。¹²
XPにおけるユーザストーリー¹³等、上記の理念を具体化したプラクティスを取り込むことで、ユーザーにスプリント（1週間から4週間）の単位で実際に動くソフトウェアを見ていただけることになります。そうすることで、「何が必要で、何を優先すべきか」を、ユーザーにもご理解をいただきやすくなり、ひいてはプロダクトオーナーとして適切な判断を行っていただくことにもつながってくるはずです。

ベンダーとしては、ユーザーの懸念を払拭するため、契約段階での説明と、開発工程においてのアジャイル開発の実践が、今後より重要になってくる、と考えます。アジャイル開発のプラクティスでは、上記のユーザストーリーをはじめ、実際のソフトウェアをお見せし、検証しやすくなる工夫が提唱されています。モデル契約アジャイル開発版を利用するベンダーには、このようなプラクティスを自社の開発工程の標準に落とし込み、契約の段階でユーザーに説明し、それを着実に実践していくことが、求められることとなります。

上記のような説明と実践で、ユーザーがプロダクトオーナーとして適切な判断を行っていくことができるよう、システム開発のプロフェッショナルとして支援を行っていくことが、モデル契約アジャイル開発版を利用する場合にベンダーが負うべき責務・責任となってくるでしょう。

▼注釈

1. なお、2020年12月22日より、IPAのホームページで民法改正に関わらない論点の改訂を反映した「情報システム・モデル取引・契約書」第二版が公開されています。改訂されたポイントは、A セキュリティ、B プロジェクトマネジメント義務及び協力義務、C 契約における「重大な過失」の明確化、D システム開発における複数契約の関係、E 再構築対応の5つです（A、Bは条項の見直しを含む。C～Eは解説のみ見直しのみ）。本稿では取り急ぎ脚注でのご案内に留めます。
2. モデル取引・契約書見直し検討部会「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）〈民法改正を踏まえた、第一版の見直し整理反映版〉」P7等
3. 「DXレポート2018」P20
4. 「DXレポート2018」P42～P44参照
5. 平鍋健児＝野中郁次郎「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」（翔泳社2013）P60以下、等
6. モデル取引・契約書見直し検討部会DX対応モデル契約見直し検討WG「～情報システム・モデル取引・契約書＜アジャイル開発版＞～アジャイル開発外部委託モデル契約」（以下「モデル契約アジャイル開発版解説」）P2
7. モデル契約アジャイル開発版の付属文書「～情報システム・モデル取引・契約書＜アジャイル開発版＞～アジャイル開発進め方の指針」（以下「アジャイル開発進め方の指針」）P15
   
8. 以下の説明につき、「アジャイル開発進め方の指針」P16、前掲平鍋=野中P43～46を参照。なお、ジェフ・サザーランド〔石垣賀子 訳〕「スクラム－仕事が4倍速くなる“世界標準”のチーム戦術」（早川書房2015）P227～232も参考になる。
9. アジャイル開発が提唱された欧米、特に米国では、ユーザーがIT技術者を直接採用し、内製化していることが多い、とされています（英繁雄「ITプロジェクトのトラブルを回避する 揉め事なしのソフトウエア開発契約」（日経BP社2017）P8～10、なお「DXレポート2018」P21も参照）。これをベンダー側にIT技術者が集中し、請負・準委任での外注が一般的である日本で行おうとした場合、スクラムにおけるどの役割をユーザー、ベンダーのどちらが担うのか、という問題が生じることになります。
10. モデル契約アジャイル開発版第4条第2項
11. 「モデル契約アジャイル開発版解説」P19
12. アジャイルソフトウェア開発宣言（日本語訳）参照
13. 前掲平鍋＝野中P61～63の他、吉羽龍太郎「ユーザストーリーとは」を参照。なお、前掲ジェフ・サザーランドP170～179も参考になる。