FAQ 集
非ウォーターフォール型開発モデル契約・契約書案
FAQ 集
平成 23 年度版
独立行政法人情報処理推進機構 |
技術本部 ソフトウェア・エンジニアリング・センター |
目次
Q28. 成果物、納期、対価及び支払方法の別紙への記載 12
I. はじめに
本 FAQ は、非ウォーターフォール型開発 WG 契約問題 PT の平成 23 年度活動において、非ウォーターフォール型開発モデル契約書案改訂版にあたり、作成しています。
非ウォーターフォール型開発モデル契約書案は、以下のように構成されています。
① 基本/個別契約モデルの基本契約書案
② 基本/個別契約モデルの個別契約書案（請負型）
③ 基本/個別契約モデルの個別契約書案（準委任型）
④ 組合モデルの契約書案
1. 全体・前提条件等
Q1. 基本契約・個別モデル契約書案の前提条件
基本契約・個別契約モデルの契約書案は、どういった開発を前提条件として作成していますでしょうか。
ユーザによってプロジェクト全体についての企画が完了しており、プロジェクトの全体概要およびその中で開発する機能について、ある程度イメージを持っている。という条件下のもと作成しています。
参照：非ウォーターフォール型開発 WG 活動報告書
「第四部 アジャイル開発にふさわしい契約」 『付録 1 』
Q2. 組合モデル契約書案の前提条件
組合モデル契約書は、どういった開発や企業を前提条件としていますでしょうか。
ユーザとxxxとの間に既に信頼関係が構築されており、出資額を決めるための契約締結段階で、プロジェクトの全体概要、概算予算が決定している。という条件下の元に作成しています。
詳細については、下記に記載がありますので、ご参照下さい。
参照：非ウォーターフォール型開発 WG 活動報告書
「第四部 アジャイル開発にふさわしい契約」 『付録 ５ 』
Q3. 一括の準委任契約としない理由
アジャイル型開発の場合、一括で準委任契約をする場合が見受けられるようですが、なぜ基本契約と個別契約(準委任)もしくは、個別契約(請負)となっているのでしょうか。
アジャイル開発の場合は、プロジェクト開始当初は開発対象が特定できないケースが多いため、成果物の特定を要しない準委任一括での契約を行う場合もあります。しかし、プロジェクトを遂行していく過程において、開発対象が確定されれば、成果物の完成に対して対価を支払う請負契約を締結した方がより適切な場合もあります。基本契約・個別契約モデルでは、基本契約に従ってプロジェクトを遂行する過程において、開発対象が確定した時点で事後的に個別契約を締結する仕組みとすることで、開発対象ごとに、あるいはフェーズごとに、請負契約と準委任契約を使い分けられるようにして基本契約と個別契約に分けることにより、フェーズ単位に個別契約を準委任契約と請負契約を使い分け、柔軟な対応を可能としました。
参照：非ウォーターフォール型開発 WG 活動報告書
「第四部 アジャイル開発にふさわしい契約」
『３．3 アジャイル開発における基本契約/個別契約モデル案 』
Q4. 想定しているスクラム開発の具体的内容
個別契約(請負型)の別紙は、スクラム開発を想定して作成しているとありますが、具体的にはどういった開発を想定しているのですか？
プロジェクトの想定およびスクラム開発については、下記をご参照下さい。
参照：非ウォーターフォール型開発 WG 活動報告書
第四部 付録 『本契約書の前提条件』および『本契約が想定するケース』
参照：非ウォーターフォール型開発 WG 活動報告書
第五部「アジャイル開発にまつわる開発手法体系の歴史と動向」 『5. スクラムモデル』
Q5. フェーズ毎に個別契約の種類変更
計画、準備フェーズでは、個別契約（準委任）を用い、その後の開発フェーズ以降では、個別契約(請負)を用いる等、フェーズ毎で契約形態を変更したい場合でも、基本契約はそのままで問題ないのでしょうか。
基本契約はそのままで、個別契約の契約形態の変更が可能です。
フェーズや状況に応じで、個別契約単位で請負契約／準委任契約形態を変える事が可能です。例えば、プロジェクト初期段階では、開発対象が明確になっておらず、またベンダとユーザが相互の体制や能力を把握できていないため、ある機能を開発するためにどの程度の工数を要するのか不明確なこともあります。そのような場合には、プロジェクト初期段階では「準委任契約」を締結して業務を行いつつ相互の能力を把握し、その後連携等が安定してきて、ある機能の開発に必要な工数等がある程度正確に見積もれるようになったら、請負契約に遷移するなど、柔軟な対応が可能となります。
参照：非ウォーターフォール型開発活動報告書
第四部 『3.2 アジャイル開発における基本契約/個別契約モデル契約案』
2. 基本・個別契約モデル 基本契約書
Q6. 全体プロジェクト完了の法的義務
＜第 2 条 （全体プロジェクト）＞
ユーザとxxxは全体プロジェクトを遂行するために相互に協力するが、全体プロジェクトを完了する法的義務を負うものではない、とありますが、通常システム開発においてはベンダ側が完了義務を負うものではないで しょうか。
アジャイル開発におけるプロジェクト当初の全体計画は、未だ青写真に過ぎないものであり、その後のプロジェクト遂行過程における変動可能性をはらんだものです。そのため、全体計画に法的拘束力を持たせないことで、プロジェクト遂行過程における柔軟な対応を確保し、アジャイル開発の特徴を生かす形としています。
また、もし仮に通常の一括請負と同様にベンダ側がプロジェクト全体の完了義務を負うこととなると、xxxはプロジェクト当初の時点では未だ明確になっていない成果物について、完成させる義務を負うことになり、ベンダの負担が極めて重くなってしまいます。。
そのため、本契約では、ベンダは全体プロジェクトを完了する法的義務を負わないこととしています。
Q7. 個別契約の法的義務
＜第 3 条（個別契約）＞
基本契約書にユーザとベンダは、全体プロジェクトで開発が予定される全ての機能について個別契約を締結する法的義務を負うものではない、とありますが、どういった意図があるのでしょうか。
全機能もしくは、契約時に確定している機能において個別契約の締結をしなければならないような拘束はできないのでしょうか。
基本契約を締結した者が、プロジェクト全体に対しての個別契約を締結しなくても、契約上の債務不履行責任を負うものでは無いという意味であり、実際の法的義務が発生するのは、個別契約を締結した機能(工程)のみとなります。アジャイル開発では、当初の計画がユーザの要望その他の事情によって柔軟に変更されることが見込まれています。当初の計画に法的拘束力を持たせないことで、プロジェクト遂行過程における柔軟な変更対応を可能としています。
Q8. xxxの了承を得ずに再委託
＜第 8 条（再委託）＞
経済産業省のモデル契約書では、再委託を原則禁止する A 案と、再委託を原則自由とする B 案が存在しますが、この雛形には、B 案がありません、
xxxの了承を得ずに再委託は可能としたいのですが、記述について問題ありますでしょうか。
ユーザとベンダが連携し、チームとして作業を行うアジャイル開発の特性上、ユーザに承諾を得ずに再委託を行うような事態は避けるべきとの考えから、再委託にはxxxの了承が必要としています。
Q9. 秘密情報の取扱の規定
＜第 9 条（秘密情報の取扱い）＞
秘密情報の取扱の条項に、本条の規定は、本契約後○年間存続する。とありますが、通常何年程度が妥当なのでしょうか。
個々のプロジェクトの特性により、一概には妥当な期間を定義することは難しいですが、①秘密情報をきちんと管理するためには相応のコストが必要となること、また、②秘密情報といっても時間の経過により陳腐化して秘密性や価値が失われていく場合もあることなどを考慮して、各プロジェクトごとに、合理的な期間を設定することになります。
Q10. 秘密保持条項の期限
＜第 9 条（秘密情報の取扱い）＞
当社の通常の契約では、秘密保持の期限を定めていないが、雛形では期限が定められているのは、どうしてでしょうか。
秘密保持の期限を定めない場合には、理論的には秘密保持義務を永久に負担し続ける可能性があります。しかし、厳格に秘密情報を管理し続けるには相応のコストと労力が必要となりますので、義務を負う側にとっては負担が大きいことになります。本契約書については、義務の負担を現実的かつ合理的な範囲にとどめるよう、一定期間の定めを規定することとしています。
Q11. 個人情報の取扱いの記述
＜第 10 条（個人情報の取扱い）＞
個人データを取り扱うにあたり、セキィリティ事故等の発生した場合の連絡等について、記述がありません。
個人データの取扱いを委託する場合に記載が望ましい事項については、「個人情報の保護に関する法律についての経済分野を対象とするガイドライン(経済産業省)」を踏まえた上で、協議の上明確化する必要があります。本雛形については、汎用性を考慮した結果、詳細な事項は記述していません。
Q12. 報告書の著作権
＜第 11 条（報告書の著作権）＞
報告書の著作権は、ユーザに帰属しないように読み取れますが、どうしてでしょうか
ビジネスモデルの秘密の保護やシステムのノウハウ優位性を維持するためにあらゆる著作権をユー ザに帰属させるという考え方もありますが、本来、営業上の秘密は、秘密保持条項にて保護されるべ きといえます。また、社会経済的な観点からは、ユーザの秘密と無関係な部分については、他のプロジェクトでの再利用を可能とした方がよく、結果的にはユーザもそのコストメリットを享受することができるといえます。こうした考えから、ここでは報告書の著作権はベンダに帰属するものとしています。
なお、請負型契約による成果物の著作権については、個別契約書にて定めています。
Q13. 損害賠償請求期間
＜第 13 条（損害賠償）＞
損害賠償請求期間について、個別契約に定められている期間の経過後は、請求できないとありますが、請求権の消滅期間が短すぎないでしょうか。
個々のプロジェクトの特性や、対象とするフェーズにより、設定されるべき消滅期間は異なると考えられます。そのため、請求権の消滅期限については、個別契約ごとに決定できるものとしています。
Q14. 損害賠償限度額
＜第 13 条（損害賠償）＞
損害賠償限度額の記述があるのですが、どういう意図によるものでしょうか。
情報システムはユーザの業務データを取り扱うものであるため、情報システムトラブルはユーザ業務 に広く影響し、それに起因する損害は莫大なものになるおそれがあります。ベンダとしては、ユーザからの受託の可否や受託の対価を決定する際に、こうした過大な責任を負うリスクを考慮せざるを得ない
ことになりますが、損害賠償限度額の規定は、ベンダのこうしたリスクをある程度制限することで、両当事者の負担の調整を図ろうとするものです。
設定すべき限度額については、プロジェクトの特性、フェーズにより異なると考えられます。本契約においては、帰責事由の原因となった業務に係る個別契約書に定める損害賠償限度額を限度とする A 案と、全体プロジェクトに関連する各個別契約の契約金額（ベンダに対する対価報酬）を合計した金額を限度とする B 案を提示しており、状況に応じて決定できるものとしています。
3. 基本・個別契約モデル 個別契約書(準委任)
Q15. 準委任の開発主体
＜2 項 ベンダの義務＞
ユーザが開発主体となるものであり、ベンダが完了義務を負うものではない、として、開発主体をユーザに限定しているのは、どうしてでしょうか。
個別契約書（準委任）は、ユーザがベンダに対して特定の成果物の完成を委託するのではなく、ユーザがベンダに対して、その専門的知識を生かしたユーザの業務支援を委託するための契約として作成しています。そのため、個別契約書（準委任契約）を用いる場合は、実際にはベンダが開発作業を担うとしても、システム開発の主体はあくまでユーザであり、xxxはその支援を行うという位置付けとなっています。なお、もしxxxが特定の成果物の完成義務を負う形にするのであれば、個別契約書（請 負）を用いることになります。
上記の通り、準委任契約においては、xxxは成果物の完成義務を負いませんが、だからといって、 請負契約と比べて準委任契約の方が、必ずしもベンダの義務が軽いというわけではありません。準委任の受任者（xxx）は、善管注意義務を負担し（民法 644 条）、業務を行うにあたり、受任者の職業・地位において一般に要求される水準の注意を怠れば、債務不履行として損害賠償責任を負うことになります。システム開発における準委任の場合、ユーザは、ベンダがIT の専門家としての高い知識・技能を有しているからこそ、業務支援を委託するわけですから、ベンダが IT の専門家として通常要求される水準を下回る仕事をすれば、善管注意義務に違反しうることになります。なお、善管注意義務違反を原因とする損害賠償責任の消滅時効は、委任事務の内容にもよるものの、基本的には義務違反があった時点から5 年間であるため（商法522 条）、xxxは、請負契約の瑕疵担保期間よりも長期間にわたり責任を負うことが多いといえます。
Q16. スクラム開発以外の個別契約書別紙等の記述
＜別紙＞
スクラム開発ではなく、他の手法にて行う計画です。XP 等他の開発手法を想定した別紙のサンプル等ありますか？また、契約にあたり、注意すべき点などありますでしょうか。
他の手法を用いた場合でも、基本的な記載内容については、変更なく利用して頂けます。
ただし、個々のプロジェクトの特性や開発手法によっては、例えば役割や連絡協議会の構成などにおいて、記載内容の変更を要する場合もあると思われますので、ご留意ください。
Q17. 個別契約別紙の体制
＜別紙＞
個別契約の別紙には、ベンダ側、ユーザ側それぞれの体制の記述がありますが、途中で異動、組織改編等があった場合は、どうしたらよいでしょうか。連絡協議会にて報告、承認を得るのみで問題ないでしょうか。もしくは、変更契約書を締結しなければならないのでしょうか。
変更内容を連絡協議会で提示の上、双方の責任者の記名、押印をもって承認を得ることとしています。別紙の記載例では、”2.作業体制 (5)作業体制の変更”として、変更時の対応を記載していますので、
ご参照下さい。
「基本/個別契約モデルの個別契約書案（準委任型）(Word 形式)」 『別紙 （記載例）』
Q18. 個別契約(準委任) 別紙の記載内容
＜別紙＞
個別契約(準委任型)の別紙には、各項目に対し、詳細な記述を求められていますが、ここまで詳細に記載しなければならないのでしょうか。
なるべく詳細に記載すべきであると考えます。委任対象となる業務が明確に特定していなければ、ユーザが望む業務をベンダが実施しないおそれがあり、他方でベンダとしても、どこまでの仕事をすれば契約上の義務（善管注意義務など）を果たしたことになるのか不明となり、トラブルにつながるおそれがあります。細目については連絡協議会で事後的に決定することも可能ではありますが、事前合意の範囲を可能な限り詳細にすることにより、連絡協議会内での決定範囲を明確化し、紛争のリスクを軽減させることができます。
Q19. 成果物、納期、対価及び支払方法の別紙への記載
＜別紙＞
成果物、納期、対価及び支払方法については、個別契約書の別紙に記載されることになっていますが、なぜ契約書の本体ではなく別紙で定めているのでしょうか。
基本契約・個別契約モデルにおいては、開発対象となる機能ごと、あるいはフェーズごとに、複数の個別契約を締結することを想定しています。そのため、個別契約ごとに契約書の本体の条項を変更してしまうと、契約のチェックに手間がかかることになります。そこで、個別契約ごとに変更される事項については別紙に集約してしまい、契約書の本体については原則として変更しないこととして、契約書のチェック作業をなるべく容易にすることを意図しています。
4. 基本・個別契約モデル 個別契約書(請負)
Q20. 検収基準の扱い箇所
＜5 項 検収基準＞
「検収基準」は、基本契約で扱っていることが多いですが、なぜ基本契約ではなく、個別契約書（請負型）に記載されているのでしょうか？
ここで記載している「検収基準」の「検収」は、システム開発の成果物に対する検収を指していますが、準委任契約の場合には（ベンダが完成義務を負う）成果物がありません。そのため、「検収基準」は個別契約（請負）においてのみ記載しています。
Q21. 検収基準の設定
＜5 項 検収基準＞
ユーザ側ベンダ側双方が開発に関わるアジャイル開発の場合、どうやって検査基準を設けるべきでしょうか。その場合、どう言った基準の設定方法があるでしょうか。
別紙記載例では、”5. 成果物及び納期”内に検査基準として、連絡協議会にて定めるとしています。
「基本/個別契約モデルの個別契約書案（請負型）(Word 形式)」 『別紙 （記載例）』
Q22. 瑕疵担保責任の扱い箇所
＜6 項 瑕疵担保責任＞
「瑕疵担保責任」は、基本契約で扱っている事が多いですが、基本契約ではなく、個別契約書（請負型）に記載されているのは、どうしてですか？
基本契約書は、付随する個別契約として、請負契約と準委任契約に対応できる形で作成していますが、このうち準委任契約には瑕疵担保責任はありません。そのため、瑕疵担保責任の条項は個別契約書
（請負）に規定して、具体的な瑕疵担保期間は同契約書の別紙で定めることとしています。
Q23. 瑕疵担保期間の設定
＜第 6 項 瑕疵担保責任＞
基本契約ではなく、個別契約（請負）で瑕疵担保期間を設定しているのはどうしてでしょうか。
基本契約書は、付随する個別契約として、請負契約と準委任契約に対応できる形で作成していますが、このうち準委任契約には瑕疵担保責任はありません。そのため、瑕疵担保責任の条項は個別契約書
（請負）に規定して、具体的な瑕疵担保期間は同契約書の別紙で定めることとしています。実質的にみても、基本契約締結時においては、未だ開発対象や実施作業が確定していないことが想定されていますので、その時点で具体的な瑕疵担保期間を適切に定めることは難しいと思われます。
Q24. 成果物の所有権移転時期
＜7 項 成果物の所有権移転時期＞
成果物の所有権は、検収完了をもって、ベンダからユーザに移転する、とありますが、納品時ではなく検収完了時となっているのはどうしてでしょうか。
納品の結果、検収不合格となった納品物は、ベンダ自身の所有物として修繕を行うこととした方が、権利関係に混乱が少ないと考えられるため、検収完了時としています。
なお、ユーザからの対価支払が完了した時点をもって、所有権及び著作権を移転するとの定めを行うことも考えられます。この場合は、以下の条項に規定された移転時期を修正することになります。
・基本契約書： 修正なし
・個別契約書（請負型）： 7 項、9 項１号（【B 案】又は【C 案】を採用する場合のみ）
・個別契約書： 7 項 1 号（基本案又は【別案 2 共有案】を採用する場合のみ）
Q25. 著作権に関する記載箇所
＜9 項 著作権の帰属＞
著作権に関する記載が、基本契約ではなく、個別契約に記載されているのはどうしてでしょうか。
著作権帰属の規定については、成果物ごとに帰属先が分かれる可能性を想定して、基本契約書ではなく、個別契約書に記載しています。
Q26. 損害賠償
個別契約書の本文に損害賠償の条項が見当たりません。
基本契約書の第 12 条に損害賠償に記述がありますので、個別契約書には、記述していません。
Q27. 個別契約別紙の体制
＜別紙＞
個別契約の別紙には、ベンダ側、ユーザ側それぞれの体制の記述がありますが、途中で異動、組織改編等があった場合は、どうしたらよいでしょうか。
連絡協議会にて報告、承認を得るのみで問題ないでしょうか。もしくは、変更契約書を締結しなければならないのでしょうか。
変更内容を連絡協議会で提示の上、双方の責任者の記名、押印をもって承認を得ることとしています。別紙の記載例では、”2.作業体制 (5)作業体制の変更”として、変更時の対応を記載していますので、
ご参照下さい。
「基本/個別契約モデルの個別契約書案（準委任型）(Word 形式)」 『別紙 （記載例）』
Q28. 成果物、納期、対価及び支払方法の別紙への記載
＜別紙＞
成果物、納期、対価及び支払方法について、個別契約書に記載される事が多いかと思いますが、なぜ別紙で定めているのでしょうか。
基本契約・個別契約モデルにおいては、開発対象となる機能ごと、あるいはフェーズごとに、複数の個別契約を締結することを想定しています。そのため、個別契約ごとに契約書の本体の条項を変更してしまうと、契約のチェックに手間がかかることになります。そこで、個別契約ごとに変更される事項については別紙に集約してしまい、契約書の本体については原則として変更しないこととして、契約書のチェック作業をなるべく容易にすることを意図しています。
5. 組合契約モデル
Q29. 遅延障害金
損害賠償の条項に遅延障害金についての記述がないが、記述の必要はありませんか。
本契約書では、遅延障害金についての定めを記述していませんが、（少なくとも契約当事者の一方が会社である限り）商法定利率である年 6 分が適用されることになります。これを超える割合の遅延損害金を定める場合には、特約にて記述する必要があります。
Q30. 脱退時の成果物権利
＜第 16 条（除名による脱退） 5 項＞
当該脱退者に帰属していた全ての権利は、その他の組合員に、脱退者の出資割合を控除して再計算した各自の出資割合に従って、当然に無償で移転するものとする、とありますが、成果物の権利は、無条件に移転されてしまうのでしょうか。
本契約書では、契約当事者が一つの共同事業を行うことを目的としていますが、第 16 条により除名となる場合は、除名対象者に権利を保持させたままにすると、残った組合員による以後の共同事業継続ができなくなるおそれがあります。そのため、除名対象者から残った組合員に対して、成果物の権利を無条件に移転することとしています。
III. 参考
コンピュータシステムの導入の狙いと留意点
⚫ ユーザの業務システム全体における「IT」と「人」の受け持つ範囲を改善し、生産性の向上を意図するもの
⚫ 本質的に、ユーザがシステムの要件を定義するもの
⚫ 他方、ユーザは、IT は難しい・判らないという苦手意識から、ベンダにお任せという意識が少なからずあり、システムのあるべき姿を現す要件定義が不明瞭になったり、契約を含めたプロジェクト管理がずさんになりやすい
⚫ ユーザ・ベンダ間で取り決めた（事情に応じて変更した）アジャイル開発のプラクティスを、合意なしに勝手に変更しない、ということを明確にするために、個別契約書案の別紙において、
「プラクティスの保護」という項を設けてある。たとえば、ベンダが、アジャイルと称しつつ、実際にはウォーターフォール的な行動を起こすこともあるので、ベンダ側の義務としている。また、別の例としては、開発フェーズでペアプログラミングを一人で実施されると、これはプラクティスを守っていないことになる。
●ユーザが主体として担当すべき業務
要件の確定（仕様、方式、パッケージ等）業務手順、画面、帳票等の精査
データの精査、運用テストの実施
業務改革に伴う社内規定等の策定・変更
●ベンダが担当すべき業務
（準委任契約）
IT の専門家としての助言、要件に基づく ITの実現方式の検討、パッケージの選定助言、試験の支援
（請負契約）
仕様書に基づく開発、構築業務