IT企業・インターネットビジネスの法律相談

1．はじめに

 

システム開発契約について調べていると、「フェージング契約」という言葉を目にすることがあります。

フェージング契約とは、システム開発に関する業務を、要件定義、設計、開発などのフェーズ（工程）に分け、それぞれのフェーズについて契約を締結していく契約方式をいいます。

例えば、システム開発を依頼するユーザから、

「まずは当社が希望するシステムについて要望を整理してほしい。もっとも、実際にどのような機能が必要なのかは、まだ十分に固まっていない」

という相談を受けたとします。

この段階で、要件定義からシステム完成までの作業内容・開発費用・納期を正確に確定することは容易ではありません。

それにもかかわらず、企画、要件定義、設計、開発、テスト、導入といった一連の業務を一括して契約し、報酬総額まで固定してしまうと、その後にユーザから追加要望が出てきた場合、「その作業は当初の開発費に含まれている」「いや、当初の仕様には含まれていないので追加費用が必要である」といったトラブルにつながりかねません。

このような問題への対応策の一つが、フェージング契約です。

もっとも、「システム開発であれば、常にフェージング契約にした方がよい」というものでもありません。

開発規模、仕様の確定度、パッケージソフトの利用の有無、ベンダとユーザとの関係などによっては、一括契約の方が実務に適している場合もあります。

そこで本記事では、主としてベンダの立場を念頭に、

・フェージング契約とは何か

・一括契約とは何が違うのか

・どのフェーズを請負・準委任とするのか

・どのような案件でフェージング契約を採用するとよいのか

・フェージング契約にはどのようなメリット・デメリットがあるのか

・契約書を作成する際に何を確認すればよいのか

について、実際のシステム開発取引を踏まえて解説します。

 

※本記事は、主としてウォーターフォール型のシステム開発を念頭に置いています。アジャイル開発については、開発対象全体の仕様をあらかじめ確定させることを前提としないため、別途その特性に応じた契約設計を検討する必要があります。

2．フェージング契約とは

(1) フェージング契約の意味

「フェージング契約」は、民法に定められた契約類型の名称ではありません。

システム開発について、業務をいくつかのフェーズに区切り、各フェーズについて個別に契約を締結しながらプロジェクトを進める契約方式を、実務上「フェージング契約」と呼んでいます。

例えば、「要件定義」「外部設計」「内部設計・プログラミング」「テスト・導入」というフェーズがある場合、

「要件定義から完成までを1本の契約書で契約する」

のではなく、

「まず要件定義について契約し、その結果を踏まえて次の開発工程について改めて見積り・契約を行う」

という形で進めます。

実務上は、各フェーズに共通する秘密保持、知的財産権、損害賠償等について「基本契約」を締結した上で、各フェーズの具体的な業務内容、報酬、納期等について「個別契約」を締結する方法も考えられます。

(2) 「多段階契約」との関係

フェージング契約と似た意味で用いられる言葉として、「多段階契約」があります。

経済産業省が2007年に公表した「情報システム・モデル取引・契約書」では、開発工程の進行に伴って後工程の見積りの前提条件が変化することを想定し、工程ごとに委託料を定めて個別契約を締結するとともに、その都度、必要に応じて再見積りを行う「多段階契約と再見積り」の考え方が採用されています。この考え方は、その後IPAが公表しているモデル契約や関連資料にも引き継がれています。

一方、IT業界では、仕様決定・要件定義・設計・開発などの工程を分け、各工程について段階的に契約を締結する方式を「フェージング契約」と呼ぶことがあります。

このように、「フェージング契約」と「多段階契約」は、用語が使用される場面や由来に違いはあるものの、いずれも、システム開発を複数の工程に分け、仕様や見積りの精度が高まるのに応じて段階的に契約を締結していくという点で、基本的な考え方は共通しています。

もっとも、「フェージング契約」や「多段階契約」は民法上の契約類型を示す用語ではなく、その具体的な分け方も一様ではありません。要件定義と開発を二段階に分ける場合もあれば、要件定義、外部設計、内部設計以降というように三段階以上に分ける場合もあります。

そこで本記事では、このような工程ごとに契約を分けて締結する方式を、主として「フェージング契約」と表記します。なお、経済産業省・IPAのモデル契約等における考え方を説明する場合には、そこで用いられている「多段階契約」という表現も使用します。

(3) 一括契約との違い

フェージング契約と対比される契約方式が「一括契約」です。

ここでいう一括契約とは、企画・要件定義・設計・開発などの複数のフェーズを一つの契約関係にまとめて契約する方式を意味します。

例えば、「企画支援」「要件定義」「基本設計」「プログラム作成」「テスト」「導入支援」までを一つのシステム開発契約書にまとめ、全体の報酬を「総額○○円」と設定するといった方法です。

これに対し、フェージング契約では、例えば、

①要件定義業務について準委任契約を締結する

②要件定義終了後、その結果を踏まえて開発業務を再見積りする

③再見積りを踏まえて開発業務について請負契約を締結する

といった形で進めます。

(4) フェージング契約が採用される背景

システム開発では、プロジェクト開始時点で最終的な仕様が完全には固まっていないことがあります。

特にスクラッチ開発では、ユーザ自身も完成させたいシステムを十分にイメージできておらず、要件定義や設計を進める中で、「この機能も必要だった」「画面を見てみたら、この仕様では使いづらい」「既存システムとの連携が必要になった」といった要望が追加されることが珍しくありません。

ところが、仕様が曖昧な段階で最終的な開発費用を固定しようとすると、ベンダ側としては将来発生する不確定要素を見積額に織り込む必要があります。

その結果、

・見積額が高くなる

・ベンダがリスクを負担しすぎる

・追加費用を巡ってトラブルになる

といった問題が発生します。

そこで、仕様が明確になるにつれて見積精度が高くなるというシステム開発の性質を踏まえ、各フェーズ終了時に次フェーズの見積りを行い、契約を締結する方法が考えられるわけです。

これは、経済産業省・IPAのモデル契約等で示されている「多段階契約と再見積り」の考え方とも共通するものです。

3．各フェーズにおける契約類型―請負と準委任

フェージング契約を採用する場合、単に契約書を複数に分ければよいわけではありません。

各フェーズでベンダがどのような義務を負うのかを踏まえ、請負契約と準委任契約のどちらにするのかを検討する必要があります。

IPAのモデル契約では、概ね次のような整理が示されています。

フェーズ	主な業務	契約類型の一例
企画	システム化の方向性	準委任
企画	システム化計画	準委任
要件定義	要件定義	準委任
開発	システム外部設計	準委任又は請負
開発	システム内部設計	請負
開発	ソフトウェア設計	請負
開発	プログラミング	請負
開発	ソフトウェアテスト	請負
開発	システム結合	請負
開発	システムテスト	準委任又は請負
導入	受入・導入支援	準委任
運用	運用テスト	準委任
運用	運用	準委任又は請負
保守	保守	準委任又は請負

もっとも、この表はあくまで典型例です。

契約の法的性質は、契約書上の名称だけで決まるものではありません。業務内容、仕事の完成義務の有無、成果物の位置付け、報酬の発生条件その他の契約内容を踏まえて判断する必要があります。

その意味でも、フェージング契約では、各フェーズの「名称」以上に、各契約でベンダが何を約束するのかを明確にすることが重要です。

4．フェージング契約（多段階契約）と一括契約、どちらを選ぶべきか

それでは、実際のシステム開発案件では、一括契約とフェージング契約をどのように使い分ければよいのでしょうか。

当然ながら一律の答えはありません。

もっとも、筆者がこれまで受けてきた相談事例等を踏まえると、次のような整理が参考になると考えます。

(1) 自社パッケージをカスタマイズする場合

ベンダ自身が開発したパッケージソフトを利用し、そこに一定の機能を追加・変更する場合です。

この場合、ベンダは、パッケージの仕様、変更可能な範囲、必要な工数、想定される作業期間を比較的把握しやすいため、スクラッチ開発と比べると見積精度を高めやすいといえます。

したがって、カスタマイズの内容がある程度定型化されているのであれば、一括契約で対応することも十分考えられます。

ただし、パッケージソフトである以上、ユーザの希望をすべて実現できるわけではありません。

「現在の業務にシステムを完全に合わせる」のではなく、「システムに合わせてユーザ側の業務フローを変更してもらう」必要が生じる場合もあります。

そのため、

・実装できない機能

・カスタマイズ可能な範囲

・標準機能を前提としてユーザ側で変更すべき業務

について、契約締結前に認識を合わせておくことが重要です。

なお、パッケージ開発については、次の記事もご参照ください。

 

パッケージ開発の紛争予防～F&Gから検収・保守まで、契約書に落とす要点

(2) 第三者のパッケージを利用する場合

他社が開発したパッケージソフトを利用し、ベンダが設定、追加開発、連携開発等を行う場合です。

この場合、自社製品と異なり、ベンダ自身がパッケージ内部の仕様や制約を完全に把握しているとは限りません。

そのため、簡易・定型的な導入案件を除けば、いきなり全工程を固定額で一括受注するより、

第1段階：ユーザの要望整理・要件定義

　↓

第2段階：実現可能性を確認した上で開発

という二段階に分けることが考えられます。

中小規模のシステム開発では、すべての工程について契約を分けることは現実的でない場合もあります。

その場合には、少なくとも「仕様を固める段階」と「固まった仕様に基づき開発する段階」を分けるだけでも、フェージング契約を採用する意味があります。

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

オーダーメイドで一からシステムを構築するスクラッチ開発は、フェージング契約との親和性が高い類型です。

スクラッチ開発では、ユーザ自身もプロジェクト開始時点では完成形を十分にイメージできていないことがあります。

このため、要件定義を進める中で新たな要望が出たり、画面設計を確認して初めて必要な機能に気付いたりすることがあります。

もっとも、「要件定義＝準委任」「それ以降＝すべて請負」という単純な二段階にすれば必ず解決するわけでもありません。

実務上は、画面・操作方法などの外部設計が具体化して初めて、ベンダとユーザとの間で完成予定のシステムについて具体的なイメージを共有できることも少なくありません。

そこで例えば、

【三段階方式】

①要件定義：準委任

②システム外部設計：準委任又は請負

③内部設計以降：請負

とする方法や、

【二段階方式】

①要件定義～システム外部設計：準委任

②内部設計以降：請負

とする方法も考えられます。

重要なのは、「フェージング契約だから何段階にしなければならない」という発想ではなく、どの時点で仕様と見積りの精度が十分に高まるのかという観点から、契約を区切るポイントを決めることです。

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

開発期間が長期に及ぶ場合や、ベンダにとって通常案件と比較して相当に規模の大きい案件では、フェージング契約を検討する必要性が高くなります。

大規模なシステム開発では、プロジェクト途中で、予算が確保できなくなった、経営方針が変更された、システムそのものが不要になった、プロジェクトの継続が困難になったなどの理由により、開発が中止される可能性を無視できません。

一括契約のまま途中で開発が中止されると、「それまでに実施した作業についていくら支払うのか」が問題となります。

これに対し、フェーズごとに業務内容と報酬額を決めておけば、少なくとも完了済みフェーズの報酬について整理しやすくなります。

(5) 下請・孫請として開発に参加する場合

ベンダがエンドユーザと直接契約するのではなく、元請会社等から開発業務を受託する場合もあります。

この場合、必ずしも「フェージング契約にするか」という議論が中心になるわけではありません。

むしろ重要なのは、自社が担当する業務範囲を個別契約で明確に限定することです。

下請ベンダは、ユーザと元請会社との間でどこまでが当初仕様として合意されていたのかを十分に把握していないことがあります。

その状態で、「システム完成のために必要な一切の業務」などと広い業務範囲を設定すると、元請会社から追加・変更作業を依頼された場合でも、「当初契約に含まれている」と主張されるリスクがあります。

したがって、

・担当する機能

・作業内容

・成果物

・前提条件

・対象外作業

・追加作業時の費用

を明確に定めることが重要です。

5．フェージング契約のメリット

フェージング契約には、ベンダ・ユーザの双方にメリットがあります。

(1) ベンダ側のメリット

①見積精度を高めやすい

仕様が曖昧な段階でプロジェクト全体を見積もるのではなく、前工程の結果を踏まえて後工程を見積もることができます。

そのため、過大なリスクを見積額に上乗せする必要性を減らすことができます。

②業務範囲と責任分担を整理しやすい

フェーズごとに「何を行うのか」「何を成果物とするのか」「どこまで完了すれば当該業務が終了するのか」を定めることで、業務範囲や当事者間の責任分担を整理しやすくなります。

③各フェーズの報酬を確保しやすい

要件定義や企画支援も、それ自体を独立した有償業務として契約できます。

ベンダにとっては、開発契約を受注できなかった場合でも、それまでに行った専門的作業について報酬を確保しやすくなります。

(2) ユーザ側のメリット

①プロジェクトを段階的に判断できる

各フェーズが終了するたびに、「このまま開発を続けるのか」「仕様を変更するのか」「別のベンダに切り替えるのか」を検討できます。

②必要以上のリスクコストを負担しなくて済む可能性がある

一括契約では、仕様が不明確なことによるリスクをベンダが見積額に上乗せする場合があります。

フェージング契約では、仕様が明確になった後で後工程を見積もるため、より実態に即した価格交渉が可能となります。

6．フェージング契約のデメリット・注意点

もっとも、フェージング契約にすればすべての問題が解決するわけではありません。

(1) 契約手続が増える

各フェーズについて個別契約を締結するため、一括契約と比較すると契約交渉や社内手続が増えます。

小規模案件では、契約手続のコストの方が大きくなる場合もあります。

そのため、実務上は、

・基本契約を共通化する

・個別契約を注文書・注文請書形式にする

・フェーズを細かく分けすぎない

などの工夫が必要です。

(2) プロジェクト全体の費用が当初段階では確定しにくい

ユーザにとって大きなデメリットとなるのが、最終的な開発費用が当初段階では確定しにくいことです。

そのため、ユーザから、「総額だけでも先に提示してほしい」と求められることがあります。

この場合の対応については、後述する「概算総額の提示」が重要な問題になります。

(3) ベンダは次フェーズを受注できるとは限らない

各フェーズを別契約とする以上、前工程を担当したベンダが当然に後工程も受注できるわけではありません。そのため、前工程の価格設定や成果物の取扱いを検討する際には、後工程を受注できない可能性も考慮しておく必要があります。

(4) 契約を分けても前工程の責任が消えるわけではない

各工程を別契約としても、前工程の不備が後工程に影響した場合には、前工程について責任が問題となることがあります。契約を分割することと、各工程の法的責任が完全に切断されることは同じではありません。

7．フェージング契約でよくあるトラブル

(1) 概算総額を示したところ「この金額で完成させる約束だ」と言われた

フェージング契約では、後工程の仕様が確定していないため、契約開始時点で最終的な報酬総額を確定できないことがあります。

もっとも、ユーザとしては予算を確保する必要があるため、「概算でよいので総額を教えてほしい」と求めることがあります。

そこで見積書、提案書、覚書等に、「システム開発総額○○万円」などと記載すると、その金額が単なる参考額なのか、それとも契約上の上限額・固定額なのかが問題となります。

ベンダとして概算額を提示するのであれば、

・現時点における概算額であること

・前提となる仕様・条件

・今後の要件定義等によって変更される可能性があること

・変更が生じる場合の説明・再見積りの方法

を明確にしておく必要があります。

単に「総額○○円」と記載することは避けた方が安全です。

(2) 仕様変更なのか当初業務なのかで争いになった

システム開発トラブルで典型的なのが、

ベンダ：「それは追加機能なので別料金です」

ユーザ：「最初からお願いしていた機能なので当初金額に含まれています」

という対立です。

フェージング契約を採用しても、各契約の業務範囲が曖昧であれば、この問題は解消しません。例えば開発工程については、

・要件定義書

・仕様書

・画面仕様書

・機能一覧

・見積条件

などを契約書と関連付け、それらに記載されていない機能追加・仕様変更について、別途費用が発生することを明確にしておく必要があります。

また、変更内容だけでなく、「誰が変更を申し出るのか」「ベンダが費用・納期への影響をどのように提示するのか」「誰が承認すれば変更が確定するのか」という変更管理の手続まで定めることが有用です。

(3) 前工程を終えたのに、次工程を受注できなかった

フェージング契約では、各工程について個別に契約を締結するため、前工程を担当したベンダが当然に次工程も受注できるとは限りません。

例えば、要件定義を行った結果、必要な機能や作業範囲が当初の想定よりも増え、ベンダが開発工程について当初の概算額を上回る金額を提示したとします。

この場合、ユーザから、「当初聞いていた金額より高いので、この金額では発注できない」と言われることがあります。

また、金額だけでなく、納期その他の契約条件について折り合いがつかない場合や、ユーザが相見積りを行った結果、開発工程について別のベンダへ発注する場合も考えられます。

フェージング契約では、前工程を開始する時点では、後工程の具体的な業務内容や報酬額がまだ確定していないことが通常です。前工程を通じて仕様や作業範囲を具体化し、その結果を踏まえて後工程について改めて見積りを行い、契約条件を協議することになります。

したがって、前工程の契約を締結したからといって、その時点で当然に後工程の契約まで成立しているわけではなく、前工程終了後の協議の結果、後工程について契約が成立しないこともあり得ます。

この点は、基本契約を締結している場合も同様です。基本契約は通常、秘密保持、知的財産権、損害賠償、再委託、契約解除など、複数の個別契約に共通する条件を定めるものであり、基本契約を締結したことだけで、将来の各工程についてユーザに発注義務が生じるとは限りません。

そのため、ベンダとしては、後工程を受注することを前提として前工程の報酬を低額に設定すると、後工程を受注できなかった場合に、前工程で行った業務に見合う報酬を確保できないおそれがあります。

フェージング契約を採用する場合には、

・各工程がそれぞれ独立した契約であるのか

・ユーザに次工程の発注義務があるのか

・後工程の報酬その他の条件をどの時点で協議・決定するのか

・当初提示する開発総額が概算なのか、上限額なのか

・次工程について合意できなかった場合、前工程の成果物をどのように取り扱うのか

といった点について、あらかじめ整理しておくことが重要です。

(4) 後工程で前工程の問題が発覚した

フェージング契約では、原則として各フェーズについて別の契約が成立します。

もっとも、例えば、「要件定義に重大な誤りがあり、その結果、後工程で予定していたシステムを完成できなくなった」という場合、単に、「要件定義契約は既に終了しているので責任を負わない」と処理できるとは限りません。

各契約の関連性、問題の内容、債務不履行の有無等に応じて判断する必要があります。

そのため契約書では、

・前工程成果物の後工程における利用方法

・前工程成果物を誰が、どの時点で承認するのか

・承認の効果

・承認後に問題が判明した場合の取扱い

・ユーザに求める確認・協力事項

・ベンダが負う確認・説明等の範囲

なども検討する必要があります。

(5) 次工程の契約を締結しないまま作業を開始してしまった

フェージング契約では、前工程の終了後、次工程の業務内容や報酬等を確定し、契約を締結した上で次の作業に進むことが基本となります。

もっとも、実際のシステム開発では、納期の都合などから、「契約書は後で締結するので、先に作業を進めてほしい」と依頼され、そのまま次工程の作業を開始してしまうことがあります。

この状態で作業を進めると、後になって、

・どの範囲まで作業を依頼されていたのか

・報酬はいくらなのか

・当初予定された業務なのか追加業務なのか

・いつまでに何を完成させる必要があるのか

などについて、ベンダとユーザの認識が食い違うおそれがあります。

契約書を作成していないからといって、直ちに契約が成立していないことになるわけではありません。しかし、契約条件が曖昧なまま作業を開始すると、後から業務範囲や報酬を巡る紛争が生じやすくなります。

そのため、フェージング契約では、各工程について契約条件を確定してから作業を開始するという運用を徹底することが重要です。

やむを得ず正式な契約書の締結前に作業を開始する場合でも、少なくとも業務範囲、報酬又はその算定方法、作業期間などについて、発注書、覚書、メール等で確認しておくことが望まれます。

8．フェージング契約を採用する際の13の契約書チェックポイント

ここまで解説した内容を踏まえると、フェージング契約を採用する場合、少なくとも次の事項を確認しておきたいところです。

①どの工程で契約を区切るのか

要件定義、外部設計、内部設計、開発等のどこで区切るのかを決めます。

工程を細分化すればよいわけではなく、仕様・見積りの精度が高まるタイミングと契約事務の負担のバランスを考える必要があります。

②各工程を請負・準委任のどちらにするのか

契約書の名称ではなく、実際にベンダが負担する義務との整合性を確認します。

③各フェーズの業務範囲が特定されているか

「要件定義支援一式」などの抽象的な記載だけではなく、可能な限り具体化します。

④成果物が明確になっているか

要件定義書、仕様書、設計書、ソースコード等、各工程で作成・納品するものを確認します。

⑤業務完了・検収の条件が定められているか

特に請負契約では、「何をもって完成とするのか」を明確にする必要があります。

⑥各フェーズの報酬が明確になっているか

フェーズごとの報酬を定めておくことで、中途終了時の清算もしやすくなります。

⑦後工程の再見積り方法が定められているか

前工程終了後に、どの資料・仕様を前提として後工程を見積もるのかを確認します。

⑧仕様変更・追加業務の手続が定められているか

口頭やチャットで変更が積み重なり、後から費用で争うことを防ぐため、変更管理手続を定めます。

⑨プロジェクト中止時の清算方法が定められているか

既実施作業、成果物、外注費、ライセンス費用等をどのように清算するのかを確認します。

⑩次フェーズの発注・受注義務の有無が明確になっているか

ユーザに次工程の発注義務があるのか、ベンダに受注義務があるのか、それとも次工程について改めて合意することを予定しているのかを明確にします。

⑪前工程の成果物に問題があった場合の責任が整理されているか

フェーズをまたいで問題が発覚した場合の取扱いを検討します。

⑫他ベンダへの引継ぎを想定しているか

次工程を別ベンダが担当する可能性がある場合、設計書、ソースコード、データ等をどこまで引き渡すのかを確認します。

⑬成果物・知的財産権の帰属が定められているか

工程ごとに成果物が発生するため、著作権等の帰属や利用権限についても整理する必要があります。

 

以上の13項目は、フェージング契約を採用する際の基本的な確認事項です。既存のシステム開発契約書を転用する場合にも、単に契約書を工程ごとに分けるだけでなく、上記の事項が相互に整合するように設計されているかを確認する必要があります。

9．まとめ―自社に適した契約方式を検討するために

フェージング契約は、要件定義、設計、開発などの工程ごとに契約を分け、前工程の結果を踏まえて次工程の契約内容や見積りを確定していく契約方式です。

システム開発では、プロジェクト開始時点ですべての仕様や工数を正確に把握することが難しい場合があります。そのような案件では、最初から開発全体について固定額で契約するのではなく、仕様の具体化に応じて契約と見積りを段階的に行うフェージング契約が有効な選択肢となります。

特に、スクラッチ開発や大規模なシステム開発など、開発を進める過程で仕様が具体化していく案件では、フェージング契約を採用することで、見積りの精度を高めたり、各工程における業務範囲や責任範囲を明確にしたりすることが期待できます。

もっとも、すべてのシステム開発についてフェージング契約を採用すればよいわけではありません。

例えば、自社パッケージを利用した比較的小規模なカスタマイズで、契約締結時点で作業内容や必要工数を十分に把握できるのであれば、一括契約の方が契約手続も簡便であり、取引実務に適している場合があります。

 

また、フェージング契約を採用するとしても、どの工程で契約を区切るかは案件によって異なります。

要件定義と開発の二段階に分ける方法もあれば、要件定義、外部設計、内部設計以降という三段階に分ける方法も考えられます。工程を細かく分ければよいというものではなく、仕様や見積りの精度がどの段階で高まるのかを踏まえて、実務上扱いやすい区切り方を検討する必要があります。

したがって、重要なのは、「フェージング契約」という名称や形式を採用すること自体ではなく、個々の案件の特性に応じて契約の区切り方や契約条件を設計することです。その上で、

・どの段階で仕様が固まるのか

・どの段階で正確な見積りが可能になるのか

・開発途中で追加要望や仕様変更が生じる可能性はどの程度あるのか

・プロジェクトが途中で終了した場合のリスクをどのように分担するのか

・各工程について、請負と準委任のどちらが実態に適しているのか

といった点を整理した上で、契約方式を設計することが重要です。

 

さらに、フェージング契約を採用する場合でも、単にシステム開発契約を複数の契約に分割すればよいわけではありません。

各工程の業務範囲、成果物、報酬、再見積りの方法、仕様変更の手続、次工程の発注の有無、中途終了時の清算、前工程で作成した成果物の取扱いなどについて、プロジェクト全体を見据えて契約条件を整理する必要があります。

 

フェージング契約は、システム開発に伴う不確実性をなくすための契約方式ではありません。

むしろ、システム開発には一定の不確実性が存在することを前提として、その不確実性をどの段階で確認し、見積りや契約条件に反映させていくのかをあらかじめ設計するための契約方式と捉えるのが適切です。

10．システム開発契約に関するリーガルブレスD法律事務所のサポート

リーガルブレスD法律事務所では、システム開発会社をはじめとするIT企業に対し、契約方式の検討から契約書の作成・レビュー、取引先との交渉・紛争対応、継続的な法務支援まで、案件の状況に応じたサポートを行っています。

以下、主なサポート内容をご紹介します。

(1) 契約方式について相談したい

システム開発案件を受注するにあたり、

・一括契約とフェージング契約のどちらが適しているのか

・フェージング契約を採用する場合、どの工程で契約を区切るべきか

・要件定義、設計、開発などの各工程を請負・準委任のどちらにするべきか

といった点について、個別案件の内容を踏まえてご相談いただけます。

システム開発では、契約書を作成する前に、そもそもどのような契約構造にするのかを整理することが重要です。

特に、仕様が十分に固まっていない案件や、開発規模が大きい案件については、当初から一括契約を締結することが適切なのか、段階的に契約を締結する方がよいのかを事前に検討しておくことで、後のトラブルを防止しやすくなります。

(2) 契約書を確認・作成してほしい

既にシステム開発契約書がある場合には、その内容を確認し、ベンダ側に過度なリスクが生じる条項がないか、案件の実態と契約内容が整合しているかなどをレビューすることができます。

また、新たにシステム開発契約を整備する場合には、

・システム開発契約書

・基本契約書

・個別契約書

・要件定義業務に関する契約書

・開発工程に関する契約書

など、取引形態に応じた契約書を作成することも可能です。

現在、一括契約を前提とした契約書を使用している場合でも、案件の内容に応じて、基本契約と個別契約を組み合わせるなど、フェージング契約を前提とした契約体系に見直すことが考えられます。

その際には、契約書を単に複数に分割するだけではなく、

・各工程の業務範囲

・成果物

・報酬

・再見積り

・仕様変更

・次工程の発注

・中途終了時の清算

などについて、プロジェクト全体との整合性を確認しつつ法務支援を行います。

(3) 取引先との交渉・トラブルに対応してほしい

システム開発では、契約締結時には想定していなかった問題が、プロジェクトの進行中に発生することがあります。

例えば、

・ユーザから追加の機能開発を求められたが、追加費用の負担について合意できない

・仕様変更なのか、当初契約に含まれる作業なのかについて認識が食い違っている

・開発途中でプロジェクトの中止を求められた

・次工程の契約条件について折り合いがつかない

・契約解除や損害賠償を巡って紛争になっている

といった場面です。

このような場合には、契約書だけでなく、要件定義書、仕様書、見積書、議事録、メール、チャット等も確認しながら、当事者間でどのような合意が成立していたのかを整理する必要があります。

また、紛争が深刻化する前の段階であれば、追加費用の請求方法、仕様変更への対応、相手方への説明内容などについて検討することで、交渉による解決を図れる場合もあります。

契約締結後に問題が生じた場合にも、必要に応じて、相手方への通知内容や交渉方針の整理から、交渉代理、紛争対応まで対応します。

(4) 継続的にIT法務を相談したい

システム開発会社では、一つの案件だけでなく、複数の案件について継続的に、

・契約書のレビュー

・見積条件の確認

・仕様変更への対応

・追加費用の請求

・顧客からのクレーム対応

・契約終了・解除への対応

などの法的判断が必要になることがあります。

特に、案件ごとにその都度契約書を作成・修正していると、契約条件が統一されず、会社としてどのようなリスクを負っているのか把握しにくくなる場合があります。

継続的な法務支援により、個別案件への対応だけでなく、

・システム開発契約書の標準化

・フェージング契約を採用する場合の社内ルールの整備

・見積書・注文書等の運用方法の整理

・仕様変更や追加費用が発生した場合の対応フローの整備

など、会社全体としてシステム開発に伴う法的リスクを継続的に管理しやすい体制を整えることができます。

 

＜2023年7月執筆、2026年9月改訂＞

※本記事は、執筆時点における一般的な法的整理を示すものであり、個別案件への適用は具体的な事情により異なります。