システム開発契約における多段階契約・一括契約の選択ポイント等を解説

【ご相談内容】

当社はシステム開発を主たる事業としています。

今般、事業用マッチングサイトを通じて、システム開発案件を受注できそうなのですが、ユーザ側もシステム開発を依頼することが初めてとのことで、どのような準備や段取りをとればよいのか分からないとの相談を受けました。

ユーザ側の要望をまとめるだけでも相当な作業量が見込まれること、システム開発自体が途中で頓挫する可能性も否定できないことから、正当な対価確保とリスクヘッジを可能とする契約書を作成したいのですが、どのようにすればよいでしょうか。

 

【回答】

例えば、大規模な社内基幹システム開発の場合、事前に相当時間と労力をかけてシステム開発で実現できることを整理した上で、開発業務を一定のフェーズに分け、その都度ベンダとユーザとで確認しながら作業を進めていくことになります。

このような場合、作業工程ごとでその都度契約を締結する契約モデルである「多段階契約」が適切と一般的には言われています。

しかし、中小のベンダ・ユーザ間の取引の場合、その都度契約を締結することは煩雑であり、企画支援からシステム納品まで一貫させた「一括契約」と呼ばれる契約モデルで契約締結手続きを進めることが多いようです。

本件の場合、一括契約で契約手続きを進めることは一定のリスク（作業分に見合った対価を得られない）を伴うと予測されるため、多段階契約を採用するか、または一括契約を採用するにしても内容を修正する必要があると考えられます。

本記事では、多段階契約と一括契約のそれぞれの利点、どちらの契約モデルを選択するべきかの視点、選択した契約モデルを使用する場合の注意点等を解説します。

 

【解説】

1.契約モデルとしての一括契約、多段階契約

(1)定義、背景

一般的には、「システム開発契約」という契約類型が存在し、1つの契約書を作成すれば足りると考えられているようです。この考え方は、企画から開発まで全てを一括して請け負うという意味で「一括契約」と呼ばれています。

しかし、一口にシステム開発と言っても、次のような工程・プロセスがあり、その工程・プロセスごとで契約の法的性質も異なると考えられます。

フェーズ 工程（業務内容） 契約の法的性質
企画段階 システム化の方向性 準委任
システム化計画 準委任
要件定義 準委任
開発段階 システム設計（システム外部設計） 準委任or請負
システム方式設計（システム内部設計） 請負
ソフトウェア設計 請負
プログラミング 請負
ソフトウェアテスト 請負
システム結合 請負
システムテスト 準委任or請負
受入・導入支援 準委任
運用段階 運用テスト 準委任
運用 準委任or請負
保守段階 保守 準委任or請負

 

上記のように、各工程（業務内容）に応じて、都度新たな契約を締結する方法のことを「多段階契約」と呼びます。そして、経済産業省は、「見積り時期とリスクとの関係を踏まえて、ユーザ・ベンダの双方のリスクアセスメントの機会を確保する観点から、多段階契約（工程ごとに個別契約を締結する。）と再見積り（曖昧さがある段階の見積りを、要件が明確になった段階で見積りなおす。）の考え方」を推奨し、参考となる契約書式を公表しています。

 

（参考）

（独）情報処理推進機構「情報システム・モデル取引・契約書（第二版）」

 

結局のところ、「一括契約」における各工程（業務内容）を分類・抽出し、その分類ごとに新たな契約を締結するモデルが「多段階契約」ということになります。

 

(2)メリット、デメリット

上記(1)で記載した通り、経済産業省は「多段階契約」を推奨していますが、次のようなメリット・デメリットがあるとされています。

契約モデル ベンダ視点 ユーザ視点
一括契約 【メリット】

・まとまった報酬を得られる確実性が高まる（全工程を受注できる）

・契約交渉が楽になる

【デメリット】

・見積りがしづらい

・未完成であれば報酬を得られない

・追加報酬を得にくい

 【メリット】

・予算が立てやすい（全体費用が分かる）

・契約交渉が楽になる

【デメリット】

・高額な見積りを提示される恐れがある

・追加工事の有無につき紛争となりやすい
多段階契約 【メリット】

・正確な見積りを提示しやすい

・責任範囲が限定される

・報酬を請求しやすい

【デメリット】

・次の工程を受注できる保証がない

・契約交渉が煩雑

 【メリット】

・他のベンダへの切替え等の代替措置を確保できる

・中途解約をしやすい

【デメリット】

・予算が立てにくい（全体費用が分からない）

・終了工程分について責任を問いづらい

・契約交渉が煩雑

 

結局のところ、メリット・デメリットを考慮しながら、一括契約or多段階契約かを使い分けることになります。

ところで、上記(1)に記載した通り、経済産業省は多段階契約を推奨しています。しかし、執筆者が知る限り、少なくとも中小のベンダ・ユーザ間での取引実務では、多段階契約が積極的に用いられているわけではありません。

この理由は必ずしも分かりませんが、中小のベンダ・ユーザ間の取引の場合、そもそも契約書を締結しない事例も相当数見られるところ（受発注書のやり取りだけで済ませることが多い）、工程ごとで新たな契約書を締結するだけの時間的余裕や労力を当てることができないという実情があるからと推測されます。

 

(3)アジャイル開発との関係

ところで、上記(1)及び(2)で記載した一括契約or多段階契約は、いわゆるウォーターフォール開発を念頭に置いた議論となります。

いわゆるアジャイル開発の場合、開発対象全体の要件や仕様を確定してから開発を行うウォーターフォール開発とは異なり、ユーザにとって優先度の高いものから順次開発・リリースを進め、運用時の技術評価結果や顧客の反応に基づいて素早く改善を繰り返すという開発法となります。この結果、あらかじめ特定した成果物の完成に対して対価を支払う請負契約という性質はなじまず、ベンダが専門家として業務を遂行すること自体に対価を支払う準委任契約と整合的です。

したがって、アジャイル開発においては、契約モデルとして一括契約か多段階契約かを論じる意義は乏しいと考えられます。

 

（参考）

（独）情報処理推進機構情報システム・モデル取引・契約書（アジャイル開発版）

 

2.どちらの契約モデルを採用するべきか

上記1.で記載した通り、ウォーターフォール開発を前提にしたシステム開発を行う場合、一括契約か多段階契約かのどちらかの契約モデルを採用することになります。

この点、経済産業省は多段階契約を推奨していますが、執筆者が知る限り、中小のベンダ・ユーザ間での契約で多段階契約が用いられる事例は多くないこと、先述の通りです。

とはいえ、中小のベンダ・ユーザ間の取引の場合であっても、多段階契約が望ましいという場面もあります。

執筆者がこれまでにご相談を受けた事例を踏まえると、次のような使い分けを行ったほうが良いのではないかと考えられます。

 

(1)ベンダが開発したパッケージソフトを前提としたパッケージベース開発の場合

受注者であるベンダが開発したパッケージソフトがあり、このパッケージソフトに一部機能を追加・変更するなどしてシステム開発を行う場合、ベンダは工数と納期の予測を立てやすく、上記1.(2)で記載した一括契約のデメリットを打ち消すことが可能となることが多いように思われます。

したがって、この場合は原則的に「一括契約」を念頭においても差支えないと考えられます。

ただし、パッケージソフトを前提にする以上、汎用的な機能・構成・ユーザインターフェースとならざるを得ず、ユーザの要望全てに応えることができないことを明確化することが重要となります。特に、ユーザの業務体制の見直しを伴う場面が生じてきますので、この点は見積もりの際に、ユーザに十分に説明し了解を取り付けたいところです。

 

(2)第三者が開発したパッケージソフトを前提としたパッケージベース開発の場合

上記(1)とは異なり、第三者が開発したパッケージソフトに対し、一部機能の追加や変更を加えるなどしてシステム開発を行う場合、定型的な作業で工数もかからず、作業期間も予測可能という例外を除き、多段階契約の方がベターと考えられます。

もっとも、中小のベンダ・ユーザ間で行うシステム開発の場合、小規模な開発に留まることが通常であり、仕様が固まったら直ちにコーディング作業に移行することが多いように思われます。そして、この種のトラブル事例の大半は、ユーザが希望する機能がシステムに実装されていなかったというものが多いようです。

そうであれば、要件定義段階（現場実務では、ユーザが求める機能や構成、ユーザインターフェースなどの仕様が確定した段階と言ったほうが良いかもしれません）としての準委任契約、及び開発段階の請負契約の二段階契約で必要十分ではないかと考えられます。

なお、要件定義段階を独立の契約とする目的は、ベンダとユーザとの間で機能・構成・ユーザインターフェース等の仕様について認識の共有化を図り、かつ完成させなければならないシステムの最終ゴールを明確化し、後戻り作業を発生させないためです。すなわち、開発段階に移行してからのユーザによる機能追加等の要望を極力抑え込み、当該要望を実現するのであれば追加作業となることをユーザに理解させることで、トラブルを防止することに意義があるからです。

ちなみに、第三者が開発したパッケージソフトの場合、自社開発したパッケージソフトよりも一層変更できる範囲に制限が課されます。したがって、ユーザの要望全てに応えることができないこと、及びユーザの業務体制の見直しを伴う場面が生じることにつき、十分な説明と了解を取り付けることが重要であること、上記(1)の場合と同様です。

 

(3)スクラッチ開発の場合

スクラッチ開発とは、オーダーメイドでゼロからオリジナルのシステムを開発する手法のことをいいます。

スクラッチ開発となる場合、ユーザも完成させたいシステム内容につき十分にイメージできていないことが多く、五月雨式にユーザより要望が出されてくることが通常です。したがって、作業工程や作業時間を予測することが極めて困難である以上、多段階契約が望ましいと考えられます。

ところで、多段階契約の場合、要件定義段階の契約にて、ユーザの要望をすべて掴み取り、要件定義書に反映させることが念頭に置かれています。しかし、現場実務において、要件定義段階の契約で全てのユーザの要望事項を拾い上げることはおよそ不可能と言わざるを得ません。また、ユーザも要件定義段階では失念していた事項、あるいは開発作業が進むにつれて改めて気が付いた事項などがあり、どうしても要件定義段階で全ての要望事項を伝えることが難しいという実情もあります。

したがって、要件定義段階の準委任契約と開発段階の請負契約で分割するだけの二段階契約は、ベンダ・ユーザ双方にとって使い勝手の悪い契約になりがちです。

とはいえ、上記1.(1)で記載した個々の工程につき、その都度新たな契約を締結するとことは中小のベンダ・ユーザ間の取引実務では現実的ではありません。

あくまでも執筆者個人の感覚に過ぎませんが、ユーザより追加要望が出されるのは、システムの外部設計段階までのように思います（外部設計＝ユーザインターフェースが出来上がった段階で、ベンダ・ユーザ間で最終的なシステム内容に対する認識の共有化を図ることができるため）。そうであれば、①要件定義段階の準委任契約、システム外部設計の準委任契約、内部設計以降の請負契約という三段階契約とする、②要件定義からシステム外部設計までを準委任契約とし、内部設計以降の作業については請負契約の二段階契約とする、といった工夫をするのも一案ではないかと考えます。

 

(4)大規模なシステム開発の場合

何をもって大規模とするのか、ベンダの能力・経験・属性等にもよるかと思うのですが、これまでに対応したことがある案件と比較して、作業期間が1.5倍以上になることが見込まれる場合、大規模なシステム開発と捉えてもよいのではないでしょうか（あるいは年単位での作業期間が見込まれる場合など）。

執筆者個人の感覚に過ぎませんが、大規模なシステム開発の場合のトラブルといえば、何らかの理由でシステム開発が中止となるパターンが多いように思われます。そして、開発中止に伴う報酬の清算方法（成果の算定とそれに対する対価の算出など）につき、ベンダとユーザとの間で意見が対立し、なかなか報酬を支払ってもらえないという事態に陥りがちです。

上記のようなトラブルを防止する観点からすれば、工程（業務内容）ごとで業務内容とその対価を定める契約方式である多段階契約の方が、ベンダにとってはメリットが大きいと考えられます。

 

(5)ユーザ（注文者）と直接契約が無い場合（下請など）

ベンダがシステム開発に携わる場面は、ユーザと直接契約を行う場合に限られず、下請けや孫請け等で開発作業に関与することも十分あり得ます。

この場合、間に入っている事業者とのシステム開発契約については、多段階契約というよりは業務内容を明確化（限定）した個別契約で対応するべきです。

なぜなら、一括契約にした場合、ユーザの要望であるとして次々と追加・変更業務の依頼を受けた場合に、追加報酬請求することが極めて難しいからです。

すなわち、そもそも当初の開発範囲について、下請・孫請けベンダは情報を持ち合わせておらず追加の有無につき判断が付かないことが通常です。また、間に入っている事業者からすれば、定額支払いによる作業要員という認識であり、追加報酬を支払うという発想を持ち合わせていないことが多いという実情もあります。

3.ベンダ視点からの各種契約モデルの注意点

契約モデルとして一括契約or多段階契約のどちらかを選択した場合、次の事項を意識して契約内容を定めることが有用ではないかと考えます。

 

(1)一括契約の場合

①契約締結のタイミングを考えること

一括契約の場合、例えば次のような条項が定められていたりします。

第×条

委託者は受託者に対し、××（以下「本件システム」という）の開発に関する以下の業務を委託する。

①企画支援業務

②要件定義作成支援業務

③基本設計業務

④プログラム作成業務

⑤移行・運用準備支援業務

 

契約書に定める事項としては、上記の通りで一応間違いないのですが（※できれば具体的かつ詳細な業務内容を明記したいところです）、現場実務を見ていると、①企画支援業務及び②要件定義作成支援業務を行っている段階では、契約書を締結していないことが多いようです。すなわち、現実に契約を締結するタイミングは、開発業務に入ったときになる事例を多く見かけます。

おそらくは、ベンダ・ユーザともシステム開発の本質は開発業務であり、その前段階は商談にすぎないという意識があるからだと思われますが、ベンダとしてはタダ働きになるリスクを抱えることになります。そして、企画支援又は要件定義作成段階で開発が中断した場合、契約書の締結が未了という理由で、法的にもベンダは作業賃さえ支払ってもらえない状態になると考えられます。

一括契約の場合、なぜか契約書を締結するタイミングが後ろ倒しになる傾向があるようですので、注意を要します。

 

②開発業務が中止となった場合の清算方法を定めること

一括契約において、開発業務が途中で中止した場合、次のような条項が定められていることがあります。

第×条

1.委託者は、本契約をいつでも解約することができる。

2.前項の場合、委託者と受託者は報酬の清算方法につき別途協議する。

 

ベンダは上記条項に基づき、作業分の報酬請求を行うことになります。

しかし、ユーザは、作業内容が不透明であること、成果物が無いことを理由に報酬の支払いを渋ってくることが多く、ここでトラブルに発展することになります。

そうすると、協議が決裂した場合、法律で報酬請求を行うことになるのですが、厄介なのが民法の規定です。

 

【民法第634条】

請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなす。この場合において、請負人は、注文者が受ける利益の割合に応じて報酬を請求することができる。

 

2020年4月1日より施行された改正民法で、請負契約の場合であっても出来高報酬が認められるようになったと言われています。

たしかに、その通りなのですが、問題はその要件です。

すなわち、「作業成果を分離させることができること」及び「納品された作業成果につき、注文者に利益があること」の2つの要件を満たして、はじめて出来高報酬が請求できるとされています。この点、システム開発の場合、そもそも作業成果を分離することができるのか（特にプログラムであれば分離させることは難しい）、注文者が利益を受けたといえるのか（一部のプログラムだけが納品されたところで、注文者にとっては利用価値が無い）という疑義が発生し、民法第634条に基づき、出来高報酬を請求することは困難ではないかと考えられます。

したがって、一括契約の場合、例えば工程（業務内容）に応じた清算金又は計算方法を契約書に明記するなどの工夫が必要となります。

 

なお、請負の場合、注文者による一方的な解約により、ベンダは損害賠償請求権を取得することになりますが（民法第641条）、損害内容の特定、金銭評価、その立証については難問となります。この観点からも、契約書に清算方法を明記することが無難となります。

 

③追加費用が発生する場面を定めること

一括契約の場合、報酬については次のように固定額で定められていることが一般的です。

第×条

委託者が受託者に支払うべき本件業務の対価は、総額金××円とし、甲は、これを以下の通り乙に支払う。

（※分割等の支払い条件を明記）

 

もっとも、このような条項の場合、作業中にユーザから変更要望があった場合、たとえ作業の大幅な増加につながっても追加費用を徴収することが難しいというのが実情です（ユーザからすれば、成果物＝ユーザが望むシステムの完成が契約目的であり、完成までのプロセスについて関心が無い、あるいはプロセスとなる作業に対して報酬を支払うという考えを持ち合わせていないため）。

したがって、ベンダとしては、「本件業務」に含まれる業務内容は何かを具体的に特定し、その業務内容から外れる作業は別途費用が発生することを契約上明確にするといった対策を講じる必要があります。

この点、上記①のサンプル条項のような内容では不十分です。

検討するとすれば、開発業務を行う前に作成していることが多い要件定義書（但し、中小のベンダ・ユーザ間の取引では作成されないことが多く、現場実務では、ユーザが求める機能や構成、ユーザインターフェースなどの仕様をまとめた書類…をイメージしたほうがよいかもしれません）を引用し、この要件定義書に記載されていない内容、例えば要件定義書から外れる機能の追加、ユーザインターフェースの変更は追加業務であり、別途費用が発生することを明記するといったことが考えられます。具体的には次のような条項を定めておくことが考えられます。

「本契約に基づき作成された仕様書（※取引実情に応じて名称を変更する必要あり）に記載のない機能の追加、遷移の変更、ユーザインターフェースの修正等を委託者が希望する場合、委託者は、本件業務の対価とは別に両者協議の上定めた対価を支払う。」

 

なお、上記②の「開発業務が中止となった場合の清算方法を定めること」に関係しますが、分割等の支払い方法を定める場合、できる限り工程（業務内容）に対応する形式で定めたほうが、システム開発契約が途中で頓挫した場合の清算基準として準用することができ、対処しやすいという点も押さえておきたいところです。

 

(2)多段階契約を採用した場合の注意点

①見積書、提案書などの法的拘束力の有無を確認すること

ユーザにおいて多段階契約を回避する動機の1つとして、システム開発に要する総額が分からないという点があります。

たしかに、この不安に対してベンダも何らかの対応は行う必要があり、この結果、見積書や提案書に総額を明記する、あるいはシステム開発契約書とは別に総額を定めた覚書等を作成するといったことが行われたりします。

このような対応はユーザ向けサービスとして仕方がないところがあるのですが、一方でベンダとして譲れない一線があります。それは、総額はあくまで見込み額であり、今後の作業の進捗如何によって増額があり得る点を明確にしておくということです。この点、見積書や提案書であれば、注記としてその旨明記すれば対処可能です。

問題なのは覚書等を作成する場合です。単純に「システム開発に要する総額は×円とする」と定めてしまうと、この総額で固定され（法的拘束力が生じる）、その後のユーザ主導による変更要望に応える形で作業量が増加しても、追加費用を徴収することは困難となります。したがって、言い回しは難しいのですが、この総額は変動があり得ることを明記することが重要となります。

なお、法的拘束力がないことを明記する代わりに、ユーザへの配慮として、費用総額を超える請求を行う場合、ベンダは合理的な説明を行う義務があることを合わせて明記することも一案かもしれません。

 

②契約が解除された場合の範囲を押さえること

多段階契約の場合、工程（業務内容）ごとで新たな契約を締結するという方式となります。

したがって、何らかの解除事由が発生したとしても、解除事由が発生した当該契約のみ解除可能であって、既に履行済みの前工程の契約には影響を及ぼさない（＝別契約に基づく報酬の返還義務は生じない）と考えるのが原則となります。

もっとも、前工程の契約と現工程の契約が不可分一体と言えるほどの密接な関連がある場合、例えば、開発工程でシステムを完成させることが困難となったところ、その原因を探ったら要件定義工程でベンダが根本的なミスを犯していたという場合、開発工程のみならず、遡って要件定義工程まで解除可能ということもあり得る話です。

多段間契約の場合、ベンダ視点では責任範囲が制限される（＝前工程の報酬返還義務が発生しない）と言われることがありますが、絶対的なものではないことを押させておく必要があります。

 

③次工程を受注する保証がないこと

これは上記1.(2)でも記載した通りですが、多段階契約の場合、各工程で新たな契約を締結することになる以上、ユーザの意向次第では、次工程を別のベンダに依頼するということもあり得る話です。裏を返せば、ベンダは次工程の受注を期待したとしても、その期待は法的保護に値しないということを意味します。

ところで、次工程の受注が約束されていた証拠として、基本契約書を利用することができないかとベンダより相談を受けることがあります。

もちろん、基本契約書の内容にもよりますが、多段階契約における基本契約書の内容は、工程（業務内容）ごとの新たな契約において共通に適用される条項（例：秘密保持条項など）が抽出されて定められているにすぎず、各工程（業務内容）に関する契約については、別途個別契約にて定めるという表現に留まることが通常です。したがって、基本契約書を締結していたから次工程の新たな契約の締結まで保証されていたとは言い難く、むしろ新たな契約を締結するか否かは各当事者において自由であると評価せざるを得ません。

基本契約書の締結と次工程の受注とは関連性が無いことを理解しておくことが重要です。

 

4.当事務所でサポートできること

経済産業省が多段階契約を推奨していることは上記で記載した通りですが、少なくとも中小のベンダ・ユーザ間の取引では、多段階契約が普及しているとは言い難い状況です。

ただ、ベンダ視点で言えば、多段階契約の方が色々と都合が良いのも事実です。

そこで、多段階契約の利点を現場実務で用いる一括契約書に取り入れる、あるいは二段階の契約を取り入れることが、スムーズな取引交渉及びトラブル回避のために重要となります。

さて、当事務所は、顧問契約をしていただいている取引先のうち、約3分の1がIT企業であり、システム開発契約に関連する様々な問題を日々取扱っています。そして、こられの対応により蓄積された知見・ノウハウ等は相当なものになっていると自負しています。

当事務所をご利用いただく皆様に対して、これらの知見・ノウハウを最大限活用したサービスをご提供することが可能です。

多段階契約or一括契約かの契約モデルを含むシステム開発契約に関するご相談があれば、是非当事務所をご利用ください。

 

＜2023年7月執筆＞

※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。