ＩＴ法務の基本② システム開発契約

　システム開発の委託契約は、多くの場合、請負契約となります。この場合、ベンダは（システム開発という）仕事の完成義務を負い、これに対してユーザは報酬の支払義務を負います。報酬の支払は、システムの納品と引換えでの後払が原則ですが、開発資金に充てるなどの目的で、約定により、前払や中間金が支払われる場合もあります。
　システム開発契約におけるトラブルとしては、まず、契約書などによる明確な合意がないまま、開発の先行着手がなされたものの、結局は折り合わずに開発中止となる、というケースが挙げられます。中止までの作業の費用負担やその前提としての契約の成否が問題となります。
　開発の進行段階で多く見られるトラブルは、ユーザからの要求が契約の範囲内にあるかどうかが問題となるケースです。範囲内であれば仮にどれほど工数がかかってもベンダはこれに応じなければなりませんが、範囲外であれユーザは別途の追加発注として費用や納期の変更を受け入れなければなりません。このような場合、契約書に添付された仕様書や、開発過程でのドキュメントが重要な判断資料となります。
　システム開発が途中で頓挫し、あるいは品質不良が判明する、というのが最も深刻なトラブルです。このような場合、ユーザはなお開発の続行を求めることもできますが、契約を解除した上で前払報酬の返還や損害賠償を請求することも選択肢となります。もっとも、こうした状況では逆にベンダから、責任原因はユーザ側にあるなどとして、未払報酬や損害賠償の請求がなされることも少なくありません。　

システム開発契約　ＴＯＰＩＣＳ (7)

請負契約

　請負契約は、準委任契約と異なり、受託したベンダは仕事の完成（システム開発の業務を予定された工程まで終えること）が求められます。また、完成後も一定期間は、契約不適合（バグ等の欠陥）責任として、不適合の修補、損害賠償、報酬減額、状況によっては契約の解除を受ける責任を負います。この期間は債権法改正により、ユーザが不適合を知った時から１年間と伸長されたため、検収から１年間といった特約を置く例が多くなっています。
　請負契約では、仕事の完成が必要であることから、報酬は完成後の後払が原則で、出来高報酬は認められません。もっとも、成果の一部だけでもユーザに利益となる場合は、出来高的な報酬が認められることがありますが（債権法改正で明文化されました）、成果の引継ぎが困難なシステム開発では、分割検収などの場合を除けばかなり例外的と考えられます。開発の中間成果と報酬支払

多段階契約と再見積

　中小規模の開発の場合は、開発全体を一個の契約で行う「一括請負」の契約もありますが、比較的大規模の開発の場合は、契約時に予見できなかった開発規模や開発期間等の変動が起こりやすく、トラブルを招くことがあります。そのため、工程ごとの見積と契約を繰り返す多段階契約とすることが推奨されています。
　多段階契約には、開発の進行状況を踏まえた精度の高い見積を行える利点がある反面で、開発総額や最終納期に歯止めがないこと、履行や責任の単位が細かく区切られること、開発が完了するまで契約が継続する法的な保証がないことなど、ユーザにとって注意が必要な点があります。なお、一個の契約の中で、工程ごとに分割検収を行う場合、履行と責任の単位が区切られるほかは、これらの特質を引き継ぐことはありません。システム開発の多段階契約と再見積

開発基本合意書

　多段階契約を採用する場合、主にユーザ側のリスクを軽減するために、開発総額や最終納期の目処を置くなど、開発プロジェクト全体に関する基本合意をしておくことがあります。法的な拘束力はあくまで個別契約によって生じるため、額面どおりの効力があるわけではありませんが、例えば「信義則上ないし不法行為上の義務違反の有無を考慮するに当たり意味を有し得る」というように、契約の解釈上一定の意味があると考えられています。
　多段階契約とする場合でも、最終的にはシステムの完成を目指している以上、開発プロジェクト全体の目標について内々の握りはしているものですが、開発基本合意書は、それを紳士協定から一歩進めたものと位置付けることができます。

発注内示書（仮発注書）

　システム開発契約は高額の契約となることが多く、契約の交渉や締結も慎重となりますが、ユーザの都合で稼働時期が既に決まっており、正式の契約締結を待っていたのでは開発が間に合わないことがあります。そのような場合、やむを得ず、ベンダが開発に先行着手するに当たり、リスク軽減のためにユーザに求めるのが発注内示書（仮発注書）です。
　ただ、正式契約の締結前であることから、結果的に開発が取り止めとなる不確実性は残っており、そのような場合、中止までの作業の費用精算を巡ってトラブルとなることが少なくありません。発注内示書は、先行着手がユーザの求めによるものである（したがってベンダの営業行為ではない）ことを示す根拠となり得ますが、契約書に代わる確実なものとは言えません。先行着手と仮発注書

プロジェクトマネジメント義務と協力義務

　システム開発プロジェクトの成功には、ベンダとユーザの協働が不可欠です。そのため、ベンダには所定の開発手法や作業工程の遵守、進捗管理や阻害要因への対処といったプロジェクトマネジメント義務が、ユーザには必要な資料や情報の提供、要件や仕様の決定といった協力義務が、裁判例でも認められています。
　これらはプロジェクトの確実な遂行のために認められているものですので、契約書に記載がある場合ばかりでなく、プロジェクト遂行の必要な場面場面で、システム開発の専門家であるベンダとシステムの対象となっている業務の主体であるユーザのそれぞれの立場や役割にふさわしい義務が生じるものと考えられています。システム開発のプロジェクトマネジメント

仕様確定と仕様凍結

　「仕様確定」とは、ユーザとベンダとの合意の下で開発対象のシステムの外部仕様を確定することをいいます。「仕様凍結」を同じ意味で使うこともありますが、こちらの方は、なお追加変更の要望があり得る状況で、開発プロジェクトの進行上、いったん確定したものと扱う、というニュアンスがあります。ユーザの望む最終仕様に至っていない以上、追加変更の圧力は強いわけですが、スケジュールやコストの都合であえて「凍結」させるということです。
　仕様確定ないし仕様凍結後の追加変更要望については、変更管理の対象とされ、実際に追加変更となった場合は「仕様変更」として追加報酬が認められるのが通常です。仕様確定や変更管理が行われなかった場合でも、事後的に本来の契約内容との差異を明らかにできれば追加報酬が認められることがあります。大規模システム開発訴訟にみる「仕様凍結」

検収と報酬支払

　検収（検査合格）は法的な概念ではありませんが、契約上あるいは実務慣習上、支払の前提手続とされているものです。多くの場合、完成に代わる（あるいは完成を推認させる）報酬発生の条件と位置付けられます。納品後に数週間程度でユーザ側の検査を兼ねた受入テストを行い、これに合格すると検収、あるいは納品までに受入テストを行っておき、合格すれば短期間の形式検査を経て検収、というパタンが通常です。
　検査によって完成を確認するという意味があるため、検収未了のうちは報酬が支払われないのが原則ですが、既にシステムが納品されているにもかかわらずユーザの都合で検査が行われないような場合は、報酬が認められることがあります。契約書にあらかじめ、納品後一定期間内に検査結果の通知がなければ検収とみなす「みなし検収」条項を入れておくこともあります。逆に、完成前であるにもかかわらず、ベンダへの資金融通の趣旨で支払を行うような場合は当然、検収の扱いとすべきではありません。「検収」と「本稼働」の微妙な関係