参加者の取り組み紹介

藤瀬：デジタルプラクティス誌編集委員の藤瀬です．本日は，お忙しいところをお集まりいただき，ありがとうございます．今回のアジャイル開発の特集においては，各社における開発手法上の工夫を実践した取り組み等に関する多くの論文が寄せられましたが，アジャイル開発の導入を阻害する要因の1つと言われている契約に関するものは残念ながらありません．そこでこの座談会ではその問題をテーマとして取り上げました．ここには，特にアジャイル開発における契約にかかわる取り組みを行われている方々にお集まりいただきましたが，まずみなさま方の取り組み内容について簡単にご紹介願います．

秦泉寺：私は，アジャイル開発の推進に関するNTTグループの議論に参加する中で，ユーザ企業（発注者）の立場で，研究所におけるアジャイル開発促進のための契約の在り方と運用について企画，法務，知財，契約，会計の各々の担当と検討を行ってきました．私は開発現場の立場で参加しました．R&D（Research and Development：研究開発）は試行錯誤の面があり，アジャイル開発がフィットすることが多いのです．後に詳しく紹介しますが，契約書策定とコンプライアンスを遵守した運用設計を行い，開発現場のアジリティとアジャイル開発の効果を損なわない運用を実証するためにトライアルを実施しました．

高岡：私は，情報処理学会の「情報処理に関する法的問題研究グループ（LIP）」の主査を務めています．LIPでは，アジャイル開発のモデル契約書の作成を行っています．2018年の全国大会で初版を紹介したのですが，それに対する意見を踏まえた新しい版が完成したところです．

平岡：私は，弁護士として，契約や紛争解決等の法的実務に携わっていますが，高岡先生のLIPのメンバとして，アジャイル開発のモデル契約作成にも参加しています．

山下：私は，情報処理推進機構（IPA）が行っているモデル契約見直しの検討のうちで，デジタルトランスフォーメーション（DX）時代に求められるアジャイル開発等の新しい開発形態への対応についての検討をとりまとめています．具体的には，IPAが2012年に公開した「非ウォーターフォール型開発に適したモデル契約書」[2]の改定を行っています．そのために設置している「DX対応モデル契約見直し検討WG」には，高岡先生と平岡弁護士にも主査や委員としてお世話になっています．

アジャイル開発の導入を阻害する契約関連の課題

藤瀬：ありがとうございます．それぞれの立場が理解できたと思います．それでは，ここでの議論の始めとして，アジャイル開発の導入を阻害している契約にかかわる課題について，それぞれのご経験をもとにお話しいただけないでしょうか．どなたからでも結構です．

平岡：ここでの議論を始めるにあたっての共通認識を確認する意味で，まず，ソフトウェア開発における契約について，アジャイル開発との関連性から整理しておきたいと思います．

受託でのソフトウェア開発における契約類型としては，請負，準委任，派遣の3種があります．請負は一定の仕事を完成させるもの，準委任は一定の事務を行うものであり，仕事や事務の内容がソフトウェア開発ということです．派遣は，仕事や事務のために人そのものを行かせるものです．請負契約では，契約時に仕事の内容，すなわち開発ソフトウェアの仕様が固まっている必要がありますが，アジャイル開発では，必ずしもすべてが確定しているわけではないし，固まった部分も途中で変更されることがよくあります．これに対して準委任契約では，ソフトウェア開発を行うもののその完成を保証するものではないため，発注者にはリスクが伴います．一方，派遣契約にはこのような問題はありませんが，受託側にノウハウが残りにくいことから，開発企業としては受託しない傾向にあります．

高岡：開発途中での頻繁な要求変更の許容や継続的デリバリを特徴とするアジャイル開発の受発注形態としては，派遣契約が最適と思うのですが，残念ですね．

山下：開発受託企業のビジネスとしては，いわゆる“人貸し”は好まないということですね．

秦泉寺：請負契約は，契約前にすべての要求が確定していることが前提なので，要求が進化するアジャイル開発には根本から馴染まないですね．請負契約を複数回締結することで要求の進化に対応することも考えられますが，納品時の受注側の社内検査の稼働，何度も契約を締結することによる契約稼働によって運用のアジリティが犠牲となることが予想されます．

平岡：規模の大きな企業ほど，一般に，社内決裁などに時間がかかるため，短期間に何回も契約を締結する運用は難しいですね．

山下：準委任契約は要求進化と継続的デリバリに親和性が高いので，最近のアジャイル開発では，準委任契約を採用するところが多いと聞いています．

平岡：企業取引で契約書を取り交わす目的は，合意内容を明確にして紛争を予防するとともに，万が一紛争が生じたときに権利・義務を明確にして裁判を通じて紛争を解決することにあります．ところが，アジャイル開発の場合，開発対象は刻々と変容し，また，開発にかかわるプレイヤ（プロダクトオーナー（PO），スクラムマスター，スクラムチーム，開発チーム，等）が従来の請負や準委任の典型的な当事者とは一致しないという特殊な環境の下で行うため，合意内容の確定や権利・義務の構成は，通常の開発委託の契約（請負，委任等）がすんなり当てはまらないんです．

高岡：無理に典型的な契約を当てはめてしまうと，アジャイルの思想がなし崩しになりかねないリスクがありますしね．

山下：そうなんです．そういった問題をどのような工夫により解決するかが，モデル契約の作成においては最も悩んでいるところなのですね．

秦泉寺：従来型の契約の類型および運用がアジャイル開発になじまないことに加え，ソフトウェア開発の取引とその周辺に関する社内の運用方法を策定することが課題でした．加えて，NTTの研究開発のスキームがベースにあって，契約書はそれを反映したものになっていないといけない．そのため，契約書そのものについては，IPAから公表されているひな型をそのまま使えるわけではなく，NTTの制度運用を反映し，さらにコンプライアンスを遵守するための運用を盛り込んだ契約書にカスタマイズして，NTT研究所はこれで行きましょう，となるところまでがすごく厳しかったです．

平岡：確かに，先ほども言いましたが，社内の諸制度がしっかりしている企業ほど，新しい概念を導入することは難しいですね．

髙岡：社内の抵抗も大きいのではないかと思います．

秦泉寺：はい．さらに，契約書以外についても，運用に関するポイントが3つありました．1つは，発注側の立場なので，税制です．つまり，特にサービスに寄与するソフトウェアを作成した場合，サービスに導入する前に固定資産化しないといけないのですよ．開発したソフトウェアを継続的に顧客向けサービスに使用するとなると，必ずそれぞれのリリースタイミングで資産化が必要になります．それをどのように，どういう契機でやっていくのかということが課題でした．

平岡：モデル契約の検討で税制の話は？

山下：IPAでは議論していないですね．

高岡：LIPでもあまり考えていなかったです．

秦泉寺：あるアジャイル開発を推進している受注側企業に資産化の話をしたときに，何ですかそれってって言われてしまったことがあるのです．ということは，受注側からすると見えづらいところかもしれませんね．発注側は絶対にそれはやらないといけないのですけれども．

平岡：契約書の中にそれが出てくるかというと，あまり……．

秦泉寺：出てこない．

高岡：出てこないですよね．

秦泉寺：運用に関するポイントの2番目は，下請法ですね．まだ下請法に該当するような企業とアジャイル開発をやっているわけではないのですけれども，今後はたぶんAIが得意な小規模な企業と協働する機会は増えていくと想像されましたのでその対応について検討しました．下請法では，作業指示と作業に対する支払の期限を書面としてその都度出すこと，が求められているのですね．これを，短期間ごとに個別の契約を繰り返し結ぶようなスタイルにおいて，契約の締結そのものにそれなりの時間を要する中で，どうクリアしていくかということが課題でした．

山下：アジャイルの理念からすれば，開発ソフトウェアについて市場からのフィードバックを素早く得るためにすぐに現場で使ってもらうことを前提にしているので，そうなると納品が発生して，当然そうすると資産にもなっている，償却もしていかなければいけない，下請法的には2カ月以内に支払いをしないといけないという話ですよね．そこを書面で発注書というのがないといけないという……．

秦泉寺：そうです，その通りです．

山下：そのようなところを短いサイクルで生真面目にまわしていくことは，恐らく一般の，特に大企業の法務部門では，不可能ですよね．

秦泉寺：そうですね．

山下：だから特別な何か仕組みを作って，簡易にまわしていく制度が，これは契約というよりも運用ができていないと．

秦泉寺：そうです．

平岡：現実には非常に難しいですね．契約書には書いていないけれども，そういう運用体制を作る，それを簡易にやれるような，ワークフローのシステムを作っていくということをお勧めする，というかたちになるのでしょうね．契約の中で明示的にアジャイル開発方式を採用すると明言してあり，できれば何らかの具体的な開発標準のようなものが参照されていれば，契約本文中に運用体制が書かれていなくても，契約の変更なしに運用で回していくことも可能になるかもしれません．

秦泉寺：3つ目の運用に関するポイントは，これは請負でも同様なのですけれども，偽装請負リスク回避に関することですね．これについては皆さんが悩まれているようでして，アジャイル開発は密なコミュニケーションをとることを最大の特徴としているので，どうやってその課題をクリアしていくんだと．以上の3つ，税制対応，下請法対応，偽装請負リスク回避が，契約の周辺にある運用上の主な課題ということになります．

平岡：要は，組織固有の内部統制に準じ，契約書はその運用を反映し，各種帳票は外部監査に耐えられるものでなければならない．同時に，制度運用が開発現場のアジリティを損なうものではあってはならない．こういうことでしょうか．

藤瀬：ありがとうございます．それでは，以降，これまでに挙げられた課題についてひとつひとつ議論していきましょう．

アジャイル開発の理解不足も一因

高岡：それぞれの課題について議論する前に，こういったことが課題として挙げられるということ，あるいはアジャイル開発がうまくいかないということの根本には，アジャイル開発についての理解不足があるような気がするのですけど．

山下：そうですね．そもそもアジャイルという新しい開発スタイルがどのようなものかについて，正しく理解されていないことも導入を妨げているということですね．そのために，従来の契約との整合がとれずに契約に踏み切れなかったり，ウォーターフォール型の場合と同様の契約で開発を始めてもうまく進まずに途中で頓挫したりする．

平岡：実際のトラブル事例を見ても，ユーザ企業，ベンダ企業それぞれに問題があるのですが，当事者間の理解不足のまま開発を開始していることが原因となっているケースが多いですね．

高岡：よく「なんちゃってアジャイル」とか言われますけど，アジャイルっぽいことをしているけれどそれはアジャイルではない，というのがよくありますね．そういう人たちに本来のアジャイルがどういうものかを分かってもらうことも重要ですね．

山下：はい．IPAではアジャイル開発のモデル契約について検討しましたが，契約の前に，アジャイルについて適切に理解することが重要だという共通認識が検討メンバにあって，そのための啓発メッセージも発信しているところです．

秦泉寺：アジャイルの理解不足と言えば，企業のいろいろな部門がアジャイル開発を理解していないと運用が回らないと思いました．今回の取り組みで分かったのですが，アジャイルは従来のウォーターフォール型とは異なる新しいスタイルなのに，ウォーターフォールの考え方から抜け出せない．いろんなことをどうしてもウォーターフォールの枠組みで考えてしまう．やはり，そこには無理があり，ゆがみが生じますね．

山下：アジャイル開発を多く受託されている，あるベンダの方から聞いたのですが，社内ルールとして請負契約しかできないから，請負契約でアジャイル開発をやってほしい，と言われたことがあるそうです．製造業の会社だそうです．

秦泉寺：経営層からマインドを変える必要がありますね．

高岡：確かにそう思います．

アジャイル開発にかかわる社内の制度設計例

藤瀬：その話題については今日はここまでにして，それでは秦泉寺さん，先ほど紹介されたNTT研究所でのアジャイル開発促進のための制度設計について，詳しく説明願います．

秦泉寺：はい，アジャイル開発の特徴に関連した法制度面において，特に留意しなければいけないと思われる点は，先ほどお話ししたように，下請法，税制，偽装請負リスク回避の3点です．すなわち，下請法適用会社に対して，発注側は適切な作業指示と期支払をしなければならないとされています．具体的には，支払期限と発注内容を含む事項の発注書面化と給付から60日以内の支払義務があります．また，アジャイル開発では継続的デリバリによってサービスに利用するソフトウェアが逐次生産されるため，これらソフトウェアの適切な資産化が必要です．そして，厚生労働省のガイド[3]では，（アジャイル開発の場合に限らず）労働者派遣法に抵触しないために，「注文主と労務者に指揮命令関係を生じない」ことを基本としています．受発注双方の作業責任者を通じたコミュニケーションが必要ということです．

高岡：そういえば，2年前の情報処理学会全国大会のLIPセッションでは，偽装請負に関する議論がたくさんありましたね．

平岡：そうでした．

秦泉寺：はい，私も聴いていました．話を続けますと，これらの課題への対応方法について説明する前に，前提として，私どもの契約スキームを紹介した方が理解しやすいと思います．NTT研究所の契約スキームでは，開発対象全体の契約期間および概算金額を合意した準委任契約を1本締結した上で，その契約の下で，一定期間ごとに個別業務を設定し，個別業務での作業指示と支払を繰り返します．具体的には，個別業務開始時に作業内容を「個別業務指示書」で定義し連絡調整会議の場にて受発注双方で合意する，支払時には個別業務の精算根拠として実稼働時間を記載した「作業終了報告書」を連絡調整会議にて発注側が確認する，個別業務期間中に新たな作業が生じた場合は，その都度連絡調整会議を開催し，発注者と受注者が合意の上，個別業務指示書を修正する，というものです．

平岡：民法には，準委任とはいっても，善良な管理者の注意義務をもって債務を履行しなければならないという規定があります．

秦泉寺：そうですね．何を指示したのかを監査に耐えられるだけの証跡として残す必要があると私たちは考えていました．だからそういうような形式にしています．さて，それでは，各課題への具体的対応方法について説明します．

まず，下請法を遵守するために，個別業務開始日から60日以内に支払を実施する必要がありますが，精算額の決定，請求書発行，支払などの個別業務終了以降の社内プロセスを考慮すると，60日以内の期限を遵守するには，個別業務期間，すなわち1イテレーションの期間は最長でも4週間程度としなければいけないことが分かりました．したがって，これをルール化しました．

次に，資産化については，個別業務ごとの成果物に対して資産化を可能とすることにしました．支払い時は，作業終了報告書に基づき個別業務単位で金額を確定します．

3番目の労働者派遣法対応では，「注文主と労務者に指揮命令関係を生じないこと」を徹底したコミュニケーションを改めて意識することを狙いとして，受発注双方の作業責任者がプロジェクトの進捗報告や問題点の洗い出しの上で指示内容を合意する場とする連絡調整会議を設けることとしました．

これらの仕組みについてトライアルを行い，法制度遵守と運用のアジリティ，アジャイル開発の効果の両立が達成できたことを確認しました．しかし一方で，契約・会計システムの利用，帳票での管理，コミュニケーションにおいて限界や課題があることが分かりました．詳細については，情報処理学会の研究会で発表しています[4]．

藤瀬：ありがとうございます．こういった取り組みについてはあまり外部に紹介されることがないと思いますので，大いに参考になりますね．

アジャイル開発のモデル契約例

藤瀬：それでは次に高岡先生，先ほど紹介されたLIPでのモデル契約作成について，詳しく説明願います．

高岡：ありがとうございます．LIPでは，2年前の学会セッションで最初のモデル契約を公開しましたが，それは，アジャイル開発を実施していく上で最低限，ITシステム開発ベンダとITシステムの発注者が守らなければならない事項を盛り込んだものでした．その後，そのモデル契約に関する議論の内容を踏まえてその改訂版を作成し，今年（2020年）3月の全国大会で公開予定だったのですが，新型コロナウィルス感染拡大の影響で全国大会が中止になりましたので，モデル契約の公開も延期することにしました．5月のアジャイルジャパン2020^☆1の前までにLIPのWebページ^☆2で公開する予定です．改訂にあたっては，ユーザとベンダ双方がメリットを感じられる契約形態として準委任型をベースとした契約書の作成を試みました．そして，当事者（発注者・受注者）双方が，開発にかかわるプレイヤ（プロダクトオーナー，スクラムマスター，スクラムチーム，開発チーム等）とともに，刻々と変化するビジネスや技術環境等に応じてどのような役割を担い，どのような善管注意義務や協力義務を尽くすべきであるのか，という点について，契約書の中，特に前文に結構細かく書き込みました．そのため，できあがったモデル契約書は，作成に携わった実務家と法律家がそれぞれの立場からの思いを込めたものとなっています．

平岡：アジャイル開発の最大の特徴として，開発途中で仕事の内容が頻繁に変化することがあると思うのですが，それを法律というか契約に取り込むためには，大きく2つのアプローチがあると考えています．1つは，契約内容の確定方法からのアプローチであり，アジャイルについてのそのような特徴が共有されているという前提で，対象とする開発がアジャイルで進められていたという事実さえ契約条項中で認められれば，たとえ契約書にアジャイル開発の進め方に関する具体的な条項がなくても仕事等の内容変化が法的に有効なものとして認められる，というものです．もう1つは，事後的な変化を許容するアプローチであり，元々事情変更の原理は予見できなかった場合にのみ認められていたものを，アジャイルで開発するという合意があった場合には，この予見可能性の要件を緩和して仕事等の内容変更を有効なものとして認める，というものです．LIPのモデル契約では，前者のアプローチを志向しています．

高岡：私たちは，アジャイルの思想や現場のプラクティスを最大限尊重した望ましい契約を作るという難題にチャレンジしたと自負しています．

藤瀬：先生，ありがとうございます．それでは，IPAでのモデル契約の見直しは，どのようなものですか．

山下：はい，では，IPAでのモデル契約の見直しについて説明します．IPAでは，2012年に，基本／個別契約モデルと組合モデルという2種のアジャイル開発，当時は非ウォーターフォール型開発と言っていましたが，それ向けのモデル契約書を公開しました[2]．しかし，当時のアジャイル開発の普及状況や社内制度上の対応等の事情から，データはとっていないのですが，あまり利用されてはいないと思われます．その後，アジャイル開発は徐々に普及してきていると考えています．また，一昨年から，経産省がDXの推進に取り組みはじめ，DX時代の有力なシステム開発スタイルの1つとしてアジャイル開発がこれまで以上に注目され出しました．ところが，契約にかかわる課題があってアジャイル開発の普及が阻害されているということで，モデル契約見直しの検討がスタートしたのです．検討は，ユーザ企業，ベンダ企業，関連業界団体に法律専門家からなる委員会で議論し，中立的な立場でユーザ企業・ITベンダいずれかにメリットが偏らない契約書の作成を目指しました．高岡先生と平岡弁護士にもお世話になっています．今回のモデルでは，世の中の実情を踏まえ，準委任契約1本の形態を採用しました．特徴の1つは，アジャイル開発における各プレイヤの役割やプラクティス等の詳細については，「アジャイル開発進め方の指針」として別文書に抜き出し，契約書の外側に位置付けたことです．これは，アジャイルのプロセスを契約書の条文に細かく書きすぎると，アジャイルが有するせっかくの柔軟性を損なってしまいかねないという懸念があったためです．実際の現場でも，具体的な開発の進め方については社内開発標準を参照するというように，このような方法が使われています．このモデル契約は，今年3月末に公開しています[5]．

平岡：IPAのモデル契約の本旨というか，1つの特徴というのは，あまり契約本体にやり方そのものを細かく書きすぎないで，アジャイルの開発のやり方自体は，指針とかそういったものに譲って，それでそこを，ちょっと曖昧な言い方だけれども，ふんわりと契約が参照している．法律の言葉で言うと，契約には普通，当事者の意思表示が表れているのですけれども，その意思表示というのはやはり全部書き切れないのですよね，所詮，言葉なので．開発というのは背景にいろんな思想や事情があるのだけれども，全部は契約では規定し切れないので，その行間を埋めるためのものとして，指針が機能する．法律の言葉で言うと，「契約当事者の合理的意思解釈を行う」とよく言うのですけれども，その契約書そのものを見てもはっきりとは書いていない．裁判官でもこういう規定があるということは，この裏には当事者はこういうことを考えていたんでしょと，合理的に考えられるので，当事者の意思を解釈しますと言って，あなたにはこういうことをする義務があったのにしていないからお金を払いなさい，というようなことになるのですね．それがおそらく今回の指針だと，その合理的意思解釈の部分は指針に書いてあるので，裁判所は揉めたときに，契約書以外にそれも見て，でも指針にこう書いてあるから，あなたはこの義務があったんじゃないのと言って，あなたの負けです，みたいなことをたぶんやるようになるのだと思います．

藤瀬：ありがとうございます．2つのモデル契約それぞれに特徴があって興味深いですね．

秦泉寺：ところで，それぞれのモデル契約では，先ほど議論のあった偽装請負について，どのように扱っていますか．

山下：そこはかなり時間をかけて議論されたところです．こういうことが偽装請負になる／ならないというよりは，アジャイル開発の標準的なプロセスはこういうものだということを明確にして，それがいくら見たとしても偽装請負の入る余地がないというふうに思わせるようなものをきちんと定義すればいいのでは，という考え方が委員会内では大勢でしたが，そのことを具体的にモデル契約書に落とし込むのが大変でした．私個人のアイディアとしては，タスクが並べられ，自分からその1つを取りに行って仕事をして返す，誰かから命令されるのではなく自らの意思で行うというやり方ですよと，あらかじめ決めておくことでよいのではと思います．それが本来の自律型のアジャイルのはずなので．

平岡：恐らく，まず指揮命令の定義があるのですよね？指揮命令というのは何なんだと．要するに別の会社の従業員に指揮命令すると駄目なのですね．だから，それでアジャイルでやっている開発チームの中で，別の会社の人が交じっているわけじゃないですか．その中で，やっていることは指揮命令ではないんだということをまず明確にしてあげればよくて，そのためには指揮命令というのは何かというところをちゃんと明らかにする．指揮命令というのは，言ったら逆らえずに必ずやらないといけないような指揮なのだと思うのですよね，基本．よほど不合理じゃない限り．その点，アジャイルで言っているお互いのサジェスチョンだったりというのは，反論することもできるし，従わなくてもいいわけじゃないですか．だから指揮命令では本当はない．

高岡：指揮命令の定義をちゃんとするというのはいいのですよね．こういう場合はもう指揮命令に当たらないと．それがどこかに，ガイドラインになんか書かれるとすごくいいかなと．

山下：指揮命令とはという，解説とかで．

高岡：そう，解説に．

山下：実際にあり得るのは，プロダクトオーナーから開発メンバに対して，勘違いするPOがいて，自分が指揮できると思いこんで指揮をしてしまうみたいなのは本当に指揮命令になってしまうので，それを防ぐための何か，それは教育が必要ですね．加えて，契約書には，POは指揮命令はするものではないと．

高岡：そうそう．

山下：明確に書くか．

高岡：そう，書くか．

山下：そういうふうに書かれていれば，仮に指揮命令を受けてしまった人は，いや，契約書にこう書いてあるでしょと言って反抗することによって偽装請負になることを未然に防げる，という良いところもある．

秦泉寺：たぶん皆さん指針が欲しい．本当に指針があれば，それを参照して，こういうふうにやっているんだよというふうに言えるから．みんなそうですよ，発注側なんて．そういうお墨付きが欲しい（笑）．

今後の期待

山下：ここにきて，情報処理学会とIPA／経済産業省という2つの機関でそれぞれモデル契約が作成されたり，NTT研究所におけるアジャイル開発促進のための社内制度の実践例が紹介されたりということから，今後，それらを参考としたアジャイル開発の導入が進むことが期待できますね．

秦泉寺：私どもの研究所では，今回の運用設計の結果，アジャイル開発の採用案件が1年半のトライアル期間において30契約に迫り，劇的に増加しています．やはり，仕組みをきちんと作ることが重要だと思いました．

平岡：たぶんウォーターフォールだって，それができたころはなじみがなかったと思うのですよ．基本設計だ，詳細設計だとか言ったって，今から30年前，40年前か知りませんけれども，最初はたぶん法務の人も，なんだこれはと思ったんだと思うんです．だからやはり時代が変わって，今度，アジャイルの要素が入った契約が出てくれば，最初は戸惑うかもしれないけれども，まあそのうち慣れてくるんじゃないのかなという気もちょっとしますけれどもね．

山下：そうこうするうちに，DXが進むと内製が多くなり，究極的には，システム開発の契約は，特にアジャイル開発の契約は，なくなってしまうかもしれませんね．

高岡：そうは言っても，AIとか自動走行とかの分野では，内製だけになることは考えにくいのではないかと思います．

藤瀬：DX時代の関連ビジネスの黎明期において，アジャイル開発手法の適用は必須ということですね．そして，アジャイル開発手法をうまく適用するための工夫が重要ということでしょうか．

本日は，どうもありがとうございました．