システム開発基本契約書（多段階契約型）の意義
【意義】
システム開発基本契約書（多段階契約型）は、システム開発基本契約を締結し、要件定義からテストまでの個々のフェーズごとに請負又は準委任のいずれかを選択しながら個別契約を締結する場合に用いられる契約書でウォーターフォール方式のシステム開発で用いられます。
この多段階契約型は、委託者が受託者に対してシステム開発における要件定義作成業務からテスト業務までを一括して委託する場合の一括請負型とは異なる方法になります。
【委託者のメリット及びデメリット】
システム開発基本契約（多段階契約型）では、開発フェーズ毎に契約交渉を行った上で個別契約を締結することから、システム開発基本契約（多段階契約型）における委託者のメリット及びデメリットは、次のとおりとなります。
「メリット」
工数に応じた委託料の見積提示を受けられる可能性があること。
「デメリット」
委託料の総額を事前に確定できないこと。
【請負又は準委任の別】
要件定義から導入支援までの各フェーズで何を請負にし、何を準委任とするのかの問題については、例えば、次のような形にすることがあります。
(1)要件定義から外部設計まで（準委任）
委託者の役割が大きく受託者だけでは仕事を完成させることができないため。
(2)内部設計からプログラミングまで（請負）
委託者の役割が小さく受託者だけで仕事を完成させることができるため。
(3)テストから導入支援まで（準委任）
委託者の役割が大きく受託者だけでは仕事を完成させることができないため。
【請負又は準委任を区分する重要性】
システム開発基本契約（多段階契約型）では、個別契約において各フェーズの業務が請負又は準委任のどちらに該当するのかを規定することが基本的な形になります。
この区分を行う理由は、システム開発基本契約（多段階契約型）がシステム完成前に途中で解除された場合、受託者が委託者へ委託料の請求を行えるか否かにかかわるためです。
システム開発基本契約（多段階契約型）がシステム完成前に途中で解除された場合の受託者による委託料の請求の可否については、特約がある場合を除き、次のようになり、委託者からすれば、請負が、受託者からすれば、準委任が、それぞれ有利になります。
「請負」
受託者が既にした仕事の結果のうち可分な部分の給付によって委託者が利益を受けるときは、その部分を仕事の完成とみなされ、受託者は、委託者に対し、委託者が受ける利益の割合に応じて委託料を請求することができます。
⇒受託者によって開発中のシステムについて、委託者が第三者に引き継がせて開発作業を行わせていたといった事情がなければ、「委託者が利益を受けるとき」に当たらず、受託者は、委託者に対し、委託料を請求できないことになります。
「準委任」
受託者は、委託者に対し、既にした履行の割合に応じて報酬を請求することができます。
⇒受託者によって開発中のシステムについて、委託者が第三者に引き継がせて開発作業を行わせていたといった事情がなくても、受託者は、委託者に対し、既にした履行の割合に応じて報酬を請求することができます。
なお、委託者の責めに帰すべき事由により受託者の業務が履行不能となったときは、請負及び準委任のいずれの場合であっても、受託者は、委託者に対し、全額の委託料を請求することができます。
【ウォーターフォール方式における各フェーズの内容】
ウォーターフォール方式のシステム開発は、開発作業を複数の工程に分け、一つの工程が完了した後に次の工程に進むという形で行われます。
ウォーターフォール方式における各フェーズの内容は、次のとおりとなります。
(1)要件定義
⇒開発対象となるシステムの内容を定義する段階であり、要件定義書が作成されます。要件定義の内容については、システムの機能に関するもの（＝機能要件）及びシステムの性能等機能要件以外に関するもの（＝非機能要件）があります。
(2)外部設計
⇒要件定義で特定された内容に基づき画面、操作方法、インターフェース等システムの入出力に関する部分を設計する段階で外部設計書が作成されます。
(3)内部設計
⇒外部設計に基づきシステムの内部を設計する段階で、内部設計書が作成されます。
(4)プログラミング
⇒内部設計に基づきプログラムを作成する段階です。
(5)テスト
⇒作成したプログラムをテストする段階で、通常、単体テスト、結合テスト、システムテスト及び運用テストの順で進められます。
なお、ウォーターフォール方式では、上記のように前工程での内容を前提に次の工程へ進むため、原則、前工程へ後戻りをしないように工程管理を行います。
【個別契約】
個別契約においては、請負又は準委任の別のみならず、作業項目、作業期間、納入物、納期等の詳細を取り決めることになります。
なお、上記の作業項目の名称については、次のような形で請負又は準委任のどちらを意図しているのかを意識する必要があります。
ex.要件定義
請負の場合 ⇒要件定義書作成
準委任の場合⇒要件定義書作成支援
【個別契約の締結の考え方】
システム開発基本契約（多段階契約型）における個別契約の締結の考え方については、次のものがあります。
(1)合理的な理由がある場合を除き個別契約の締結を相互に義務付ける場合
⇒契約の拘束力が強くなります。
(2)事由の如何を問わず個別契約の締結を相互に義務付けない場合
⇒契約の拘束力が弱くなります。
【見積書】
システム開発基本契約（多段階契約型）を締結する前にベンダー選定のため受託者から委託者へ委託料総額の概算としての見積書を提出している場合がありますが、その見積書の見積金額は、あくまでもその提出時点での見積もりに過ぎず、実際の個別契約締結時には、その金額が変動している可能性があります。
そのため、受託者としては、システム開発基本契約（多段階契約型）において、事前に提出した見積書に拘束力がないことを規定する必要があります。
【受託者の通知義務】
ウォーターフォール方式での開発では、各フェーズ毎に個別契約を締結することから、あらかじめ委託者において、委託料の総額を把握できず、また、スケジュールどおりに開発が進行できないことが想定されます。
そこでシステム開発基本契約（多段階契約型）において、受託者に次のような通知義務を課す場合があります。
(1)実際の委託料の総額が事前に受託者が見積った委託料の総額に対して一定割合以上上回ることが確実な場合、その原因事由等を委託者へ通知すること。
(2)全ての作業が終了する時期が事前に委託者及び受託者間で確認した開発スケジュールを経過することが確実な場合、その原因事由等を委託者へ通知すること。
【役割分担】
システムを完成させるには、委託者及び受託者が互いに協力して作業を進める必要があり、裁判例においては、次のように委託者には、協力義務が、受託者には、プロジェクトマネジメント義務がそれぞれ課され、委託者又は受託者が自らの義務を怠ったときは、相手方に対して債務不履行に基づく損害賠償責任を負い、かつ、相手方は、システム開発基本契約（多段階契約型）を解除することができます。
「委託者の協力義務」
(1)資料の提供その他受託者からシステム開発のために必要な協力を求められたときは、これに協力すること。
(2)受託者に対して大量の追加開発要望を出す等受託者によるシステム開発を妨害してはならないこと。
(3)委託者内部で要件の意見統一を行った上で要件を決定し、その決定した要件を明確に受託者へ通知すること。
(4)テストの工程において受託者のスケジューリングに協力すること。
「受託者のプロジェクトマネジメント義務」
(1)合意した開発手順、開発手法等に従い開発作業を行うこと。
(2)開発の進捗状況を管理し、開発作業を阻害する要因の発見に努め、その要因へ適切に対処すること。
(3)開発状況の分析、開発計画の変更の要否及び内容、開発計画の中止の要否及び影響等を委託者へ説明すること。
なお、実務では、予測可能性を高めることを目的として上記の義務をシステム開発基本契約（多段階型）等に規定することがあります。
【マルチベンダー体制でのプロジェクト】
複数の受託者が作業を分担するといったマルチベンダー体制によりプロジェクトを実施する場合、一つのソフトウェアの仕様が他のソフトウェアの仕様に影響することがあり、ソフトウェア間の整合性及び受託者間の調整を図らなければいけないことがあります。
この点、ソフトウェア間の整合性及び受託者間の調整については、委託者が全体の状況を知ることができるとから、委託者がその整合性及びその調整を図らなければいけないとすることがあります。
【業務責任者】
システム開発基本契約（多段階契約型）では、開発の現場に多数の者が関与し、権限があいまいになるおそれがあり、また、委託者が受託者の担当者に直接に業務上の指示等を行うと偽装請負となる可能性があるため、業務責任者の規定が定められ、委託者及び受託者は、それぞれの業務責任者を通じて相手方に対して意思決定、同意、指示等を行うこととされます。
ただし、契約変更、契約解除等に関する事項については、業務責任者は、これらの権限を有しないとする形が一般的です。
【業務従事者】
偽装請負を疑われることを防ぐため、システム開発基本契約（多段階契約型）において、業務従事者の選定、配置及び変更、作業スケジュールの作成及び調整並びに技術指導については、受託者が行うことが規定されることがあります。
【開発環境】
システム開発では、客先で業務に従事することが多いため、開発に必要なソフトウェア、ハードウェア、作業場所等の開発環境を委託者が受託者へ提供する旨がシステム開発基本契約（多段階契約型）に規定されることがあり、その条件については、個別契約に委ねることが多いといえます。
さらに委託者の従業員が受託者の従業員に直接指示を出すと偽装請負と評価されるおそれがあるため、作業場所を提供する場合には、受託者の作業区画を定めることがあります。
なお、委託者が開発環境の提供を遅延したことにより、受託者がシステム開発を遅延した場合、受託者は、委託者へ損害賠償責任を負わない旨を規定することがあります。
【連絡協議会】
システム開発基本契約（多段階契約型）では、委託者と受託者の双方の業務責任者等が出席した上で共同作業の進捗状況の確認、報告等を目的として、定期に又は必要に応じて連絡協議会を実施する形が一般的です。
連絡協議会では、決定事項を明確にする観点から、議事録が作成されるのが通常であり、受託者がこれを作成することが多いといえます。
なお、議事録は、委託者と受託者との間の交渉過程、経緯等が記載されていることが多く、紛争時の重要な証拠となり得ます。
【納期】
納入物の納期については、争いを防止する観点及び裁判例では、契約に納期を規定しておけば、特段の事情がある場合を除き、そのとおりに納期が認定されることが多いとされていることから個別契約に規定するのが望ましいですが、中にはこのような対応がなされていないことがあります。
このような場合、どのように納期を認定するのかという問題がありますが、裁判例では、工程表又はメールをはじめとした委託者と受託者とのやり取りの内容を通じて納期が認定されることがあります。
【要件定義書作成支援業務】
受託者が要件定義書作成支援業務を実施するときは、委託者の要件定義書作成作業が適切かつ円滑に実施されるよう、受託者は、調査、整理、提案、助言等を通じて委託者を支援する形になります。
そして、委託者が要件定義書作成を完了したときは、委託者及び受託者は、連絡協議会での決定事項に適合するか否かの確認を行い、適合すると判断したときは、これにより、要件定義書が確定し、その証としてそれぞれの業務責任者がこれに記名押印する形となります。
なお、要件定義書作成支援業務は、仕事の完成を目的とした請負ではなく、準委任であるため、念のため、作業期間内に要件定義書が確定しなかったとしても、受託者は、その点について責任を負わない旨の規定をシステム開発基本契約（多段階契約型）に規定することがあります。
【外部設計書作成支援業務】
受託者が外部設計書作成支援業務を実施するときは、委託者の外部設計書作成作業が適切かつ円滑に実施されるよう、受託者は、調査、整理、提案、助言等を通じて委託者を支援する形になります。
そして、委託者が外部設計書作成を完了したときは、委託者及び受託者は、連絡協議会での決定事項に適合するか否かの確認を行い、適合すると判断したときは、これにより、外部設計書が確定し、その証としてそれぞれの業務責任者がこれに記名押印する形となります。
なお、外部設計書作成支援業務は、仕事の完成を目的とした請負ではなく、準委任であるため、念のため、作業期間内に外部設計書が確定しなかったとしても、受託者は、その点について責任を負わない旨の規定をシステム開発基本契約（多段階契約型）に規定することがあります。
【開発業務】
確定した仕様書に基づき受託者は、内部設計、プログラミング及びテストまでの工程を行うことになります。
【検収】
個別契約のおける受託者の業務が請負の場合、受託者からの納入物が検査仕様書に適合するか否かを委託者が個別契約に定める検査期間内に検査し、検査合格の場合には、検収が完了し、検査不合格の場合には、受託者にその修補を求めることになります。
そして、検査期間内に委託者が検査の結果を受託者に対して通知しないときは、その期間経過後に納入物が検査に合格したものとみなすことが多いといえます（＝みなし検収）。
これは、委託者が特に異議を述べないということは、納入物に問題がないためであろうという合理的な意思解釈を前提とした規定になります。
【検査仕様書】
検査仕様書の定め方については、例えば、次のようなものがあります。
ex.委託者と受託者との間で作業期間等を取決事項とした個別契約を締結した上で調査、整理、提案、助言等を通じて受託者が委託者を支援する形で委託者が検査仕様書を作成し、これが仕様書に適合しているときは、受託者がこれを承認し、その承認をもって検査仕様書を確定させ、その証として承認した検査仕様書に受託者が記名押印する方法
⇒受託者による上記の検査仕様書作成支援は、仕事の完成を目的とした請負ではなく、準委任であるため、念のため、作業期間内に検査仕様書が確定しなかったとしても、受託者は、その点について責任を負わない旨の規定をシステム開発基本契約（多段階契約型）に規定することがあります。
【仕事の完成と検収との関係】
個別契約における受託者の業務が請負の場合、「仕事の完成」が認められないと受託者は、委託者に対し、委託料を請求することができず、「仕事の完成」後においては、委託者は、民法第641条を根拠に個別契約を解除することができません。
また、システムを完成させることができない場合又はその完成が遅れた場合には、それは、「仕事の完成」前の話として、債務不履行の問題に、完成したシステムに契約不適合の問題があるときは、それは、「仕事の完成」後の話として、契約不適合の問題になります。
そのため、「仕事の完成」が重要な概念となるところ、裁判例においては、「受託者が当初予定されていた最後の工程まで仕事を終えている場合」には、「仕事の完成」があったものとされています。
これを検収に当てはめると、検収は、最後の工程に予定されている作業であるため、検収に合格するということは、受託者が当初予定されていた最後の工程まで仕事を終えたということを意味し、「仕事の完成」があったものと評価されます。
なお、理由なく委託者が検収を行わない場合には、受託者として客観的に予定されていた工程を全て終わっているのであれば、たとえ検収が未了であっても、「仕事の完成」があったものとされます。
【契約不適合責任】
検収完了後にシステムについて仕様に適合しないこと又は通常有すべき品質を欠いていることが発見されたときは、委託者は、受託者に対し、その修補のみを請求することができ、委託料の減額請求を認めない形が一般的です。
これは、システム開発については、不具合の発生がつきものであるところ、その都度、委託料の減額請求に応じるのは非現実的であること、また、その減額される具体的な委託料の金額を算定することが困難であるためです。
ただし、無制限に修補を請求できるのではなく、契約不適合が発見された旨を検収完了後一定期間内に委託者が受託者へ通知することを条件とし、その契約不適合が軽微な場合であって、その修補に過分の費用を要するときは、受託者は、修補義務を負わないとすることが多いといえます。
これは、軽微なバグがある場合、これを修補すると受託者に多大な労力が生じる場合があるものの、そのバグを修補しなかったとしても、委託者にとっての不都合は、比較的小さいといえることに基づきます。
【仕様の特定方法】
契約不適合が問題になった場合において、受託者が開発したシステムが仕様に該当するか否かを判断するときは、まずは、その仕様を特定する必要があります。
この点については、要件定義書、外部設計書等のドキュメント類をもとに仕様を特定し、これらのドキュメントでは、仕様を特定することが難しい場合、これらの内容が不明確な場合等では、委託者と受託者との間で行われたメール、議事録等も参照して仕様の特定が行われます。
【導入支援等業務】
受託者が導入支援等業務を実施するときは、委託者が実施するシステムの導入及び運用テストが適切かつ円滑に実施されるよう、受託者は、調査、整理、提案、助言等を通じて委託者を支援する形になります。
導入支援等業務が終了したときは、受託者は、報告書を委託者へ提出し、その内容に疑義がないときは、委託者は、受託者に対して記名押印付の確認書を交付し、これにより導入支援等業務が完了したものとします。
なお、導入支援等業務は、仕事の完成を目的とした請負ではなく、準委任であるため、念のため、作業期間内に導入支援等業務が完了しなかったとしても、受託者は、その点について責任を負わない旨の規定をシステム開発基本契約（多段階契約型）に規定することがあります。
【中間資料の委託者による承認】
作成途中の仕様書又は検査仕様書で最終版に該当しないもの（＝中間資料）について、作業の手戻りを防止するため、受託者が委託者に対して必要な部分を提示した上でその承認を求め、委託者がこれを承認したときは、その部分が確定したものと取り扱うことがあります。
なお、中間資料の承認権者については、現場の担当者による口頭の承認が成立することを回避するため、委託者の業務責任者に限定することがあります。
【未確定事項の取扱い】
委託者が決定すべき事項が未確定となっている場合、その未確定事項の内容、確定予定時期等の事項を記載した書面を委託者と受託者との間で取り交わすことにより、委託者は、未確定事項の確定を留保することができるとする場合があります。
その上で、未確定事項が確定したときは、委託者は、受託者へその確定した事項を通知し、仕様書等の修正を請求することができます。ただし、これにより、納期、作業機関、委託料等の変更が生じるときは、受託者は、委託者へこれらの変更を請求できる形が多いといえます。
さらに、委託者が未確定事項を確定予定時期までに確定できないことにより、受託者の業務継続に支障が生じるおそれがある場合には、受託者は、業務を中断するとともに、委託者へ契約内容の変更を請求することができ、その中断中に生じる体制、設備等の維持に要する費用については、委託者の負担とする形が多いといえます。
【仕様書の変更】
委託者又は受託者が仕様書の変更を希望するときは、相手方に対して変更理由、変更内容等を記載した変更提案書を提出し、これをもとに変更の可否を協議することが多いといえます。
この際に、受託者は、上記の協議が調わないときは、その協議が調うまでの間、業務の実施を中断することができることとし、その中断期間中に人員、設備等の維持のために受託者が要した費用を委託者が負担する形になることがあります。
もし、上記の協議で仕様書の変更を行うことを決定したときは、委託者及び受託者は、次に掲げる事項を記載した書面を作成し、互いに署名又は記名押印した時に変更の効力が生じるとすることがあります。
(1)変更の詳細
(2)変更理由
(3)変更作業のスケジュール
(4)変更のために生じる費用
(5)委託料、納期等システム開発基本契約（多段階契約型）又は個別契約の条件に与える影響
ただし、上記の(5)の影響が存在するときは、委託者及び受託者は、速やかにシステム開発基本契約（多段階契約型）又は個別契約の変更契約を締結し、その締結時に変更の効力が生じるとすることがあります。
なお、仕様書の変更に伴い追加の委託料が発生するにもかかわらず、納期が迫っていることを理由にシステム開発基本契約（多段階契約型）又は個別契約の変更契約を締結せずに、変更作業を行った場合、受託者は、委託者に対し、追加の委託料を請求することができるのかという問題があります。
この場合、受託者は、委託者に対し、次のいずれかの方法により追加の委託料を請求することができることがあります。
(1)黙示の合意
⇒営利事業者である受託者が仕様書の変更に伴う変更作業を行う場合、有償になるのは当然という考え方に基づきます。
(2)商法第512条に基づく報酬請求
⇒商法第512条では、「商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる。」とされます。
この「相当な報酬（＝委託料）」の算定方法については、その算定方法がシステム開発基本契約（多段階契約型）に規定されている場合には、その方法が用いられます。
反対に、もし、その算定方法がシステム開発基本契約（多段階契約型）に規定されていないときは、「工数×単価」といった算式が用いられることがあります。
【変更協議の不調に伴う解除】
仕様書の変更についての協議が不調の場合、完成させるべきシステムの対象を確定できないことになり、そのまま受託者が作業を続けても委託者の望むシステムが完成できないといえます。
そこで、仕様書の変更についての協議が不調になったときは、委託者又は受託者は、システム開発基本契約（多段階契約型）及び個別契約を解除できるとすることがあります。
【権利侵害の責任】
委託者が納入物に関して第三者から権利侵害の申立てを受けた場合において、次の条件を全て満たすときは、受託者は、委託者に対し、敗訴判決の確定又は交渉における和解等の確定的な解決により委託者が支払うべきとされた損害賠償額等を支払う形が一般的です。
(1)委託者が納入物に関して第三者から権利侵害の申立てを受けた場合において、一定期間内にその旨を受託者に対して通知していること。
(2)委託者が受託者に対して第三者との交渉又は訴訟の遂行に関して実質的な参加の機会及び全ての決定権限を与え、並びに必要な援助を行っていること。
(3)委託者の敗訴判決が確定し、又は和解等により確定的に解決したこと。
ただし、次のいずれかに該当するときは、受託者は、上記の責任を負わないとされることがあります。
(1)委託者が納入物を変更し、又は受託者が指定した稼働環境以外の環境でこれを使用したとき。
(2)第三者が開発したシステム又はモジュールとともに委託者が成果物を使用したとき。
【損害賠償責任の制限】
システムの稼働に不具合が生じ、逸失利益が生じた等のトラブルが多く、損害賠償額が高額になりやすいこと、開発したプログラムに不具合が含まれることは避けられないものであること、知的財産権侵害に関する調査の限界等から、システム開発基本契約（多段階契約型）では、一例として次に掲げる項目を規定することにより受託者の委託者に対する損害賠償責任を制限することがあります。
(1)受託者の損害賠償責任の範囲外となる損害
⇒次に掲げる損害が委託者に生じても、受託者は、損害賠償責任を負わないことを規定する。
a.特別事情による損害（予見すべきであったか否かを問いません。）
b.逸失利益
c.データ、プログラム等の無体物の損害
d.第三者からの損害賠償請求に基づく委託者の損害
(2)請求期間の制限
⇒検収完了日又は業務終了日から一定期間を経過した後においては、委託者は、もはや受託者に対して損害賠償請求することができないことを規定する。
(3)損害賠償責任の累計総額
⇒一定期間内に受託者が委託者から現に受領した対価の額、具体的な上限額等を基準に損害賠償責任の累計総額を定める。
(4)損害賠償責任の制限が適用される請求原因
⇒債務不履行、契約不適合、不当利得、不法行為その他請求原因の如何を問わず全てに適用されることを規定する。
(5)損害賠償責任の制限が適用されない場合
⇒受託者に故意又は重過失があるときは、損害賠償責任の制限が適用されないことを規定する。
【特許権等の知的財産権の帰属】
システム開発基本契約（多段階契約型）では、次のような形で受託者が業務を履行している間に生じた特許権等の知的財産権（ノウハウ及び特許その他の知的財産権を受ける権利を含み、著作権を除きます。）の帰属について、規定することが通常といえます（これと同時に委託者及び受託者がそれぞれ自らの従業員から上記の特許権等の知的財産権をあらかじめ取得することを互いに義務付けることがあります。）。
(1)単独で上記の特許権等の知的財産権を発明、考案又は創作した場合
上記の特許権等の知的財産権を発明、考案又は創作した当事者に上記の特許権等の知的財産権が単独で帰属します。
(2)共同で上記の特許権等の知的財産権を発明、考案又は創作した場合
委託者及び受託者のそれぞれの貢献度を考慮して協議で定めた持分割合により、委託者及び受託者が上記の特許権等の知的財産権を共有します。
その上で共有する上記の特許権等の知的財産権について、委託者及び受託者は、相手方の承諾及び相手方に対する対価の支払いをすることなく、自ら上記の特許権等の知的財産権の実施等をし、又は上記の特許権等の知的財産権について、第三者に対して通常実施権等を許諾することができます。
なお、受託者は、許諾の対価が委託料に含まれることを前提に、自らに帰属した上記の特許権等の知的財産権について、委託者がシステムを使用するのに必要な範囲で委託者に対して通常実施権等を許諾することがあります。
【納入物の著作権の帰属】
システム開発基本契約（多段階契約型）では、次のいずれかの形で受託者が業務を履行している間に生じた納入物の著作権の帰属を規定します。
(1)受託者又は第三者が従前から保有していた著作権を除き、受託者から委託者に対して次のいずれかの段階で納入物の著作権（著作権法第27条及び同法第28条に定める権利を含みます。）を移転させた上で、委託者は、上記で受託者に著作権が留保されている著作物を自己利用の範囲で利用できることとし、受託者は、委託者に対して著作者人格権を行使しないとする方法
1.創作時
2.納入時
3.検収時
4.委託料の完済時
(2)委託者又は第三者が従前から保有していた著作権を除き、納入物の著作権（著作権法第27条及び同法第28条に定める権利を含みます。）は、受託者に帰属し、委託者は、上記で受託者に著作権が帰属した納入物を自己利用の範囲で利用できることとし、受託者は、委託者に対して著作者人格権を行使しないとする方法
【受託者による横展開】
システム開発基本契約（多段階契約型）では、受託者による横展開を目的として、納入物の著作権（著作権法第27条及び同法第28条に定める権利を含みます。）が受託者に帰属する場合には、受託者が秘密保持義務に抵触しない範囲で、納入物の著作権（著作権法第27条及び同法第28条に定める権利を含みます。）について、その利用を第三者に許諾し、又はその複製物をパッケージ販売することができる旨を確認することがあります。
【解除】
システム開発基本契約（多段階契約型）では、解除条項において、次の解除を規定することが一般的です。
(1)約定解除
⇒一定の解除事由に該当した場合にシステム開発基本契約（多段階契約型）又は個別契約の全部又は一部の解除を認めるもの
(2)債務不履行解除
⇒相手方がシステム開発基本契約（多段階契約型）又は個別契約のいずれかの条項に違反し、相当な期間をた定めて相手方に対して催告を行ったのにもかかわらず、相手方が債務不履行を是正しない場合にシステム開発基本契約（多段階契約型）又は個別契約の全部又は一部の解除を認めるもの
その上で個別契約が解除された場合（受託者の帰責事由により委託者が個別契約を解除した場合を含みます。）、又は委託者の責めに帰すことができない事由により個別契約上の業務が履行不能となった場合には、受託者は、予定工数に対する解除時点までの完了工数の割合を個別契約で取り決めた委託料に乗じた額について、解除時点までの作業結果を納入物として受託者が委託者へ納入することを条件として、委託者に対して請求できるとすることがあります。
【個人情報】
システム開発基本契約（多段階契約型）では、運用テストの段階で委託者から受託者に対して顧客情報、従業員情報等の個人情報が提供される可能性があるため、受託者がこれらの個人情報を適切に管理し、又は第三者へ開示しないことが規定されることが多いといえます。
個人情報は、受託者に関する情報ではなく、本人に関する情報であるため、これらの義務については、システム開発基本契約（多段階契約型）が終了した場合といえども、引き続き存続する形が多いといえます。
なお、個人情報が漏洩するとその影響が大きいため、まずは、委託者から受託者へ個人情報を提供しないで済むかを検討し、それが無理である場合には、できるだけ個人情報を匿名化することが望ましいといえます。
この点、システム開発基本契約（多段階契約型）において、個人を特定できないように個人情報を加工するよう委託者に努力義務を課す場合があります。
【第三者ソフトウェアの利用】
システムに搭載する機能又はその仕様の一部を実現するために第三者ソフトウェアを利用しなければならないことがあるため、次の事項がシステム開発基本契約（多段階型契約）に規定されることが多いといえます。
(1)受託者が必要又は有益と考えたときは、受託者は、委託者に対し、第三者ソフトウェアの利用を提案し、併せてその第三者ソフトウェアの名称、利用条件、メリット、デメリット、制限事項等を通知する。
(2)委託者は、(1)の提案に基づき自らの責任でその第三者ソフトウェアの採否を決定し、その第三者ソフトウェアの採用を決定したときは、自らの責任と費用負担によりその第三者ソフトウェアのライセンス契約を締結する。
(3)受託者は、その第三者ソフトウェアに著作権侵害その他の権利侵害がないこと及び不具合がないことを保証しない。ただし、委託者がその第三者ソフトウェアの採用を決定した時に、受託者がその第三者ソフトウェアに著作権侵害その他の権利侵害があり、若しくは不具合があることを知り、又は重過失により知らずにその権利侵害若しくはその不具合を委託者へ告げなかったときは、この限りでない。
【臨時に業務範囲外の作業を行った場合の対応】
委託者と受託者との間で合意したセキュリティ要件を充足する開発環境下で受託者が開発作業を実施している間に外部から攻撃を受け、臨時に受託者がその原因を特定し、その原因を解消するための作業を実施する場合等受託者が臨時に業務範囲外の作業を実施したときは、委託者は、受託者に対し、「相当な委託料」を支払うとすることがあります。
【再委託】
システム開発では、2次請け、3次請け等の再委託先により行われることが多いため、システム開発基本契約（多段階契約型）において、受託者が業務の一部について、事前に委託者の同意を得ることなく、再委託できるとする場合があります。
ただし、不適切な再委託先により業務が行われることを防止するため、委託者が請求したときは、受託者は、その再委託先の情報を委託者に報告し、その再委託先が不適切な再委託先であるときは、委託者は、受託者に対し、その再委託の中止を求めることができるとすることがあります。
【委託者による確認の条項の内容】
システム開発の各フェーズにおいて、請負ではなく準委任が選択されたときは、「仕事の完成」という概念がないものの、業務の完了時を明確にするため、委託者による確認の条項が定められることがあります。
委託者による確認の条項では、業務完了後に受託者が委託者へ業務完了報告書を提出し、委託者が一定の期間内にその内容を確認し、委託者が記名押印した上でその報告書を受託者へ交付し、その時点で受託者の業務が完了するという形が多いといえます。
なお、委託者が業務完了報告書の確認等を遅延した場合に備えて、受託者が委託者へ業務完了報告書を提出してから委託者の異議なく一定期間が経過したときは、受託者の業務が完了したものとみなす旨の規定がシステム開発基本契約（多段階契約型）に定められることがあります。
【委託者による確認の条項を規定する場合の注意点】
委託者による確認の条項は、個別契約における受託者の業務が準委任の場合に適用される条項であるところ、請負との混同を避けるため、この条項をシステム開発基本契約（多段階契約型）に規定する場合には、次の点に注意する必要があります。
(1)検収に関する条項を規定しないこと。
(2)検収を委託料の支払条件としないこと。
(3)契約不適合に関する条項を規定しないこと。
【輸出管理】
システム開発基本契約（多段階契約型）の対象となっているシステムを輸出する場合には、委託者は、外国為替及び外国貿易法その他の法令に基づき、所定の手続をとる旨の規定をシステム開発基本契約（多段階契約型）に規定する場合があります。