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

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

今回は、前回のブログでご説明した、アジャイル開発外部委託モデル契約～情報システム・モデル取引・契約書〈アジャイル開発版〉（以下、モデル契約アジャイル開発版）に関連し、若干の補足をさせていただければ、と存じます。

DXレポートと法務畑での「温度差」

2018年9月に経済産業省・デジタルトランスフォーメーションに向けた研究会より公表された「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」（以下、「DXレポート1」といいます）では、以下の点が指摘されていました。¹

• クラウド、モバイル、AI、アジャイル開発、DevOps等の新たなデジタル技術や方法を最大限生かすために、企業間のパートナーシップを強化していく必要がある。
• その方策として、現在ベンダー企業にIT人材が偏重していることにかんがみ、ユーザー企業とベンダー企業との間でアジャイル開発での契約を締結することが多くなることが考えられる。
• アジャイル開発での契約締結を推進していくにあたり、従来のモデル契約に対し、スクラムチーム内のプロダクトオーナー・スクラムマスター等の構成員の権限・責任の明確化、バックログの組み方やイテレーションの回し方の明確化、プロダクトオーナーが役割を全うしない場合の対応方法の明確化、についての見直しを行う必要がある。

そのための方策として、アジャイル開発に関する契約についてのガイダンスと、モデル取引契約ガイドラインを策定することとされ、それを受けて策定されたのが「モデル契約アジャイル開発版」となります。²

上記のように見ていくと、DXレポート1においては、モデル契約アジャイル開発版は今後のDXを推進していくためのツールの1つとして、それなりの重みをもった位置づけとなっています。昨年末に出された「DXレポート2（中間とりまとめ）」（以下、単に「DXレポート2」といいます）においても、DXレポート1を受けた取組の成果として、同モデル契約があげられています。

経済産業省（内の研究会）としては、DXレポート1におけるモデル契約アジャイル開発版の位置づけは堅持されている、とみていいと思われます。

これに対し、いわゆる「法務畑」の近辺では、DXの必要性やそれに向けた実務対応が次第に検討されるようになってきておりますが、ことアジャイル開発に関しどのような契約で進めていくべきかといった観点については、AIやIoT、データの活用といった分野と比べると、議論がまだまだ進んでいない、という印象です。本項執筆時点でいくつかの文献や雑誌記事を見る限りでも、モデル契約アジャイル開発版の存在が簡単に紹介される例が散見される程度です。

そのように見ていくと、DXレポート1、2と「法務畑」では、モデル契約アジャイル開発版に対しての「温度差」がある、と感じています。

「温度差」の原因と課題

このような「温度差」が生じてしまっている原因はいくつか考えられるのですが、個人的には、モデル契約アジャイル開発版やその付属文書の「アジャイル開発進め方」の指針だけを見ても、今までのウォーターフォール型開発での契約と比べて、アジャイル開発（スクラム）で、どのように開発が進んでいくのか、「法務畑」の人間に想像がつきにくい、といった点が、背景にあるのではないか、と考えています。

たとえば、「包括的なドキュメントよりも動くソフトウェアを」といわれたところで、従来の仕様書作成に替えてどのようなことを行うのかのイメージがつかなければ、契約形式やその条項等の内容の議論を進めていくことは困難です。

その意味では、「法務畑」の人間も、アジャイル開発やスクラム、というものがどのようなものなのか、より一層きちんと勉強していかなければならないのではないか、と感じております。

ただ、アジャイル開発の考え方の基本理念自体は、今までのソフトウェア開発で、ともすればシステム開発専門の人間でないと分かりにくかった点を、ユーザーにもより分かりやすく示して、開発者とユーザーが対話を進めながらソフトウェアを作っていこう、というものです。³

その一例として、前回コメントや脚注で簡単な紹介にとどまっていた「ユーザストーリー」があげられると思います。
ユーザストーリー自体はXP（エクストリーム・プログラミング）での開発手法の1つで、従来型の仕様書作成等に代わり、「誰が」「何を達成したいのか」「それを求める理由・モチベーションは何か」を分解し、ストーリー上にまとめる手法のことをいいます。

たとえば、オンライン書店を開発する場合、以下のようなストーリーに分けていくことが考えられます。⁴

• 「利用者として〔誰が〕、本はジャンル別に探せるようにしたい〔何を達成したいのか〕。自分が好きな種類の本を見つけられるように〔それを求める理由・モチベーション〕」
• 「利用者として〔誰が〕、本を選んだら『買い物かご』へ入れてから購入できる機能が欲しい〔何を達成したいのか〕。購入前に抜け・漏れや余分なものがないのかを確認できるように〔それを求める理由・モチベーション〕」
• 「管理側のプロダクトマネージャーとして〔誰が〕、利用者の購入履歴を把握できるようにしたい〔何を達成したいのか〕。そうすれば履歴にあわせてお勧めの本を表示できるからだ〔それを求める理由・モチベーション〕」

実際の開発に当たっては、詳細な仕様書を作成し、ソフトウェアをコーディングして、全機能が仕様書通りとなっているかを最後に初めて確認するのではなく、上記のストーリーごとに機能が実装されているかどうかを、ユーザーの方に短い期間（スクラム開発であれば、各スプリントの期間）で見ていただくことになります。

あくまで個人的な意見にはなりますが、上記のような開発方式を徹底していけば、ユーザーが自分の欲しい機能、すなわち付加価値の高い機能が本当に実装されているのかをこまめに見ながら開発を進めていくことが可能になるはずです。

従来の一括請負型のソフトウェア開発では、完成した製品の全機能を、ソフトウェアの検収や運用準備・移行支援の工程で、初めて動かしてみる中でチェックする、ということになりがちでした。これが検収や契約不適合責任（従来の瑕疵担保責任）等でのシステム開発トラブルを生んでしまう原因の1つとなっていました。
ユーザストーリーの考え方を開発工程に上手く取り入れることができれば、このようなトラブルは減らせそうだ、というイメージは、「法務畑」の方にも付けていただけるのかな、と思っております。

付言いたしますと、ユーザー企業がアジャイル開発でのソフトウェア開発をベンダー企業に発注しようとする場合、「各スプリントでソフトウェアがどのように実装されているのかを、どのように確認するのか」をチェックするようにしていただくとよいのではないでしょうか。
「アジャイル」というキーワードだけで請負よりもベンダー側に有利とされがちな準委任契約に持ち込もうとされてしまったり、実際に約束した通りに開発が進まなかったりする事態（例えば、スプリント毎に動くプログラムをレビューするはずであるにもかかわらず、なかなかプログラムが出てこない、等）を早い段階で察知できるようになるか、と考えております。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

DXレポート1、2をあらためて読み直しておりますと、DXというのはレガシーシステムの刷新にとどまらず、事業の在り方そのものをデジタルに変革していく野心的な内容である、との思いを強くします。

「法務畑」の人間としては、自社の行う事業・業務に精通しておく、というのは最低限度の倫理だと思っています。この倫理感は、「法務畑」の人間であれば、多かれ少なかれ持ち合わせているものだと考えています。
その事業そのものが変革される場合、それについていくこと自体、なかなかに大変なことではあります。

ただ、法律の分野から少し手を広げ、言葉の意味を1つ1つ追っていき、具体的な例やイメージをつける努力を怠らなければ、DXやアジャイルの内容は必ず理解できる、と信じています。社内・外の人間が研鑽と対話を積み重ねていくという、まさにビジネスの基本そのものが、形こそ変え、改めて問われているのではないか、と感じています。

1. DXレポート1 P40～P46参照
2. DXレポート1 P51参照 
3. アジャイルソフトウェア開発宣言（日本語訳）参照
4. 以下の例は、ジェフ・サザーランド〔石垣賀子 訳〕「スクラム－仕事が4倍速くなる“世界標準”のチーム戦術」（早川書房2015）P174を基に、一部追記をいれております。