システム・ソフトウェア開発を委託する時にトラブルを避けるための契約書作成のポイント

IT・情報セキュリティ

 当社では、業務システムの刷新を予定しており、ITベンダにシステム開発を委託する予定ですが、システムが想定していたように稼働しなかったり、新たなシステムへのデータ移行に問題が生じたりして稼働が遅延し、ITベンダと紛争になっている例も多いと聞いています。そのような事態を回避するために、どのような契約上の工夫が考えられるでしょうか。

 システム・ソフトウェア開発委託においては、当初の契約段階において仕様を確定させないまま開発を進めてしまうことが往々にしてあります。そのような場合でも契約段階で、少なくとも①開発を進める中でベンダとの間で仕様を確定または変更するプロセスを明確化することに加え、②最終的に開発プロジェクトが頓挫した場合の責任分配を明確化しておくことが重要です。

解説

目次

  1. システム開発委託における現実
  2. 開発プロジェクトが頓挫する原因
  3. 契約段階における対応事項

システム開発委託における現実

 システム開発を進めていく中で開発中のシステムがユーザの要望に合致しない事態に至った場合に、ベンダにおいて当初想定していた作業期間または納期、委託料およびその他の契約条件からは開発できないことが明確となった時点でユーザに開発計画の変更や中止を説明・提言する義務(プロジェクトマネジメント義務)とユーザにおいてそれに対して協力する義務のそれぞれの違反を巡って争われる事例1が増えています。

 システム開発は「企画→要件定義→外部設計→内部設計→プログラミング→テスト→運用・保守」という理想的なプロセスによって実行されることが望ましいですが、そのようにならないケースも散見されます。

 たとえば、パッケージソフトウェアを選定し、それをユーザの要望に応じてカスタマイズするような開発案件においては、当初の契約段階では、要求仕様も確定せず、しかも外部設計や内部設計も十分に行わないまま、ベンダがユーザの要望を聞きながら、都度仕様を確定させてカスタマイズし、開発を進めていく例も往々にしてあるように思われます。

 このような場合、開発を委託する契約段階においては、ユーザはパッケージの機能に対する理解も十分でなく要求仕様は漠然としたものである一方で、ベンダはパッケージのカスタマイズで対応できる範囲での開発として受託したと認識しており、契約段階でユーザとベンダ間において認識している開発の範囲に齟齬が生じていることが多いと思われます。

ユーザとベンダの間で認識している開発の範囲に齟齬が生じていることが多い

開発プロジェクトが頓挫する原因

 ベンダは、ユーザからの要望に応じてカスタマイズすべき部分を協議して、仕様を確定していくことになりますが、ベンダが当初想定していた以上の要望をユーザから受けると、当初の契約段階で想定されていた開発の範囲外として追加開発ということになり、追加報酬の支払の要否を巡って紛争となります。

 さらに、ユーザの要望するような仕様は、そもそもパッケージソフトウェアのカスタマイズでは対応できないことがわかると、その時点でユーザは履行遅滞・瑕疵担保による解除を理由に、報酬の支払を拒否して納期遅延の損害賠償を求め、他方、ベンダは開発を中止して報酬を請求するという形で、相互に多額の請求額を求める紛争になります。

相互に多額の請求額を求める紛争になる

 当初の契約段階で想定していた開発の範囲について、ユーザとベンダの認識に齟齬がある以上、当然の帰結ではあるのですが、契約書や発注書でも仕様を明確にできていないため、ユーザとベンダの双方が過去の提案資料、担当者間のメールや議事録等の膨大な証拠資料を提出し、自らが認識していた開発の範囲が正当であると主張し合うという深刻な事態に陥るわけです。

契約段階における対応事項

 上記のような事態を避けるには、契約段階では仕様は確定していないことを前提に、開発の中で仕様を確定させていくプロセスを契約書で明確化しておくほかありません

 たとえば、以下のように、ユーザとベンダ間の連絡協議会における議事録に双方が記名押印することで仕様を確定していくようなプロセスを合意し、かつそれを適切に運用していけば、開発プロジェクトが頓挫するような原因となるユーザの要望を早期に絞り込むことができ、双方で認識に齟齬がある開発の範囲を巡って、双方が膨大な証拠資料を提出し合うような事態は回避できます。

連絡協議会によるプロセス合意の条項例

第◯条 本契約の具体的な内容は、ユーザ及びベンダが、第*条に定める連絡協議会において、本件業務の具体的な内容の確認を行い、その時点までに確定していなかった仕様を確定し、また必要に応じて確定されていた仕様についての変更を行った上で確定させる。この場合の内容の確定は、第*条に定める連絡協議会議事録を作成し、これにユーザ及びベンダの責任者が記名押印することによって行う。

 また、最終的に開発を進めてもユーザの要望が実現できないことが発覚した場合の責任分担について、ベンダにおけるプロジェクトマネジメント義務を前提とした、以下のような条項を定めて明確化しておけば、上記のような相互に多額の請求額を求め合うような事態を回避できます。

仕様確定の不調による責任分担の条項例(ベンダにおけるプロジェクトマネジメント義務を前提)

第◯条 ユーザが要望する仕様又は仕様の変更の内容が、個別契約の作業期間又は納期、委託料及びその他の契約条件に影響を及ぼす等の理由により、ユーザ又はベンダのいずれの要求によるかは問わず。個別業務が中止されたときは、ユーザはベンダに対し、ベンダがユーザから当該要望を受けた時点までに遂行した個別業務についての委託料の支払及びその時点においてベンダが出捐すべきこととなる費用その他ベンダに生じた損害を賠償するものとし、その余の委託料の支払及びベンダに対する損害賠償については免責されるものとする。

 以上のように、ユーザとベンダの双方が契約段階で仕様も確定していないのに、開発プロジェクトが頓挫することはないなどと過信することなく、頓挫した場合の責任を分担する考えを持つことが重要だと思われます。


  1. スルガ銀行・日本IBM事件(東京高裁平成25年9月26日判決・金判1428号16頁)、病院情報管理システム事件(札幌高裁平成29年8月31日判決)等 ↩︎

関連する実務Q&A

無料会員登録で
リサーチ業務を効率化

90秒で登録完了

無料で会員登録する