120年ぶりの民法改正がシステム開発に及ぼす影響・契約書見直しのポイントは？
全国20拠点以上！安心の全国対応
記事目次
2017年5月に成立した改正民法が2020年4月から施行されます。
契約などに関する債権法が約120年ぶりに大幅に改定されたため、IT業界のシステム開発に関する契約なども多大な影響を受けることになります。
今回は改正民法がシステム開発に及ぼす影響や契約書の雛形を見直す際のポイントなどについて解説します。
システム開発に関連する民法は？
民法が制定されたのは明治29年（1896年）なので、現代のようにITが当たり前に活用されている時代が想定されているわけではありません。
そのため、民法には直接的にシステム開発などのフレーズは含まれませんが、該当する条項は存在しています。
システム開発に関連する主な条項は以下の3項目です。
- 瑕疵担保責任（改定後は契約不適合責任）
- 請負契約
- 準委任契約
この3項目は、具体的にシステム開発とどのように関わるのでしょうか。
システム開発は一般的に次のような流れで行われます。
- 企業がシステム開発をベンダーに依頼
- システムに必要な機能などの要件定義
- 要件定義に従って内部設計を行い、システムを開発
- 完成したシステムの単体・結合テストの実施
- バグの修正
- 本番リリース
この一連の流れを一つのプロジェクトとして請負契約や準委任契約という形で契約することになります。
請負契約とは、システム開発の場面で言うと、基本的にクライアント側からの要望に従って、ベンダー側の裁量ですべてのシステムを開発する契約のことを言います。
依頼されたシステムを開発して、クライアント側に納品しない限りは、基本的に報酬を得ることができません。
一方で、準委任契約とは、システム開発の場面で言うと、クライアントが一定の行為や事務を行うことをベンダーに委託する契約のことを指します。
準委任契約が請負契約と大きく違う点は、労働時間や工数、時間などの要素で対価が決定されることです。
また、請負契約の場合は納品したシステムに対して完成する義務を負い、瑕疵が認められた場合には瑕疵担保責任が問われますが、準委任契約の場合は瑕疵担保責任を負うことはありません。
改正民法がシステム開発に与えるインパクト
改正民法がシステム開発に大きな影響を与える主な変更内容は以下の5点です。
- 責任追及期間が延長された
- 代金減額請求が可能になった
- 修補請求に制限がつけられた
- プロジェクトが頓挫した場合の報酬請求権が明文化された
- 成果完成型の準委任契約が新設された
これらの変更はシステム開発にどのようなインパクトを与えるのでしょうか？
ベンダー側が不利になる内容と有利になる内容に分けて説明します。
1.ベンダー側が不利になる変更内容
①責任追及期間の延長
今回の改正によりベンダー側が不利になる可能性が高い変更点の一つが責任追及期間の延長です。
旧民法では瑕疵担保責任は納品物を引き渡しもしくは仕事完了時から1年以内に限るという内容となっていました。
しかし、改正民法では契約不適合の事実を知った時から1年以内となります。
契約不適合の事実を知った時が起算点となるため、システムを納品してから3年後にクライアント側が通常業務ではあまり使用しない処理の不具合を発見した場合でも、責任を追求されてしまうことになります。
ただし、クライアント側が責任追及できる権利は契約から5年経過後に時効で消滅します。
それでも、システム開発から5年間というのは、責任追及期間としてはかなり長いと言えるのではないでしょうか。
5年の間に当時のシステムを開発した担当者のほとんどが退職したり、委託先の会社と連絡がとれなくなったりなどという可能性は十分考えられます。
②代金減額請求が可能
民法改正前は納品したシステムに瑕疵が認められた場合、クライアント側には以下の３つの選択肢がありました。
- 修補請求（バグ等の修正要求）
- 損害賠償請求（損害賠償金の支払い要求）
- 契約解除（契約自体の解除要求）
改正民法ではさらに代金減額請求という選択肢が加わりました。
つまり、納品後のシステムに不具合が見つかり契約不適合と認められた場合は、見積書の金額から不具合に相当する額を差し引いた金額しか支払われない可能性もあるというわけです。
2.ベンダー側が有利になる変更点
①プロジェクトが頓挫した場合の報酬請求権の明文化
民法改正によりベンダー側が不利になる内容について説明しましたが、逆に有利になる変更点もあります。
それは、プロジェクトが頓挫した場合の報酬請求権が明文化されたことです。
システム開発の世界では、プロジェクトを組んで対応しても、途中でプロジェクトが頓挫することがあります。
プロジェクトが頓挫する理由としては、以下のようなケースが考えられます。
- 技術的にあまりに難しく開発が困難になった
- クライアント側の予算変更や担当者変更に伴い中断した
- プロジェクトの途中でクライアントが他の業者に依頼した
- クライアント側の事情でシステム開発の必要がなくなった
請負契約と準委任契約について前述しましたが、請負契約の場合は納品物が完成していないと費用の支払いが原則行われないことになります。
改正前は、クライアント側の都合で請負契約であるプロジェクトが頓挫すれば、そこまでの開発費用などを負担しなければならないので、ベンダー側にとっては非常に不利でした。
しかし、改正民法では未完成のシステムや仕様書などの成果物によってクライアント側が利益を享受できる場合は、その利益に相当する報酬を請求することが可能になります（改正民法634条）。
また、予算や担当者変更などクライアント側の事情でプロジェクトが頓挫した場合（債権者に帰責事由がある場合）は、報酬の全額を請求できるようになります（改正民法536条2項）。
このように報酬請求権が明文化されたことで、プロジェクトが頓挫した場合もベンダーが不利益を被るリスクが軽減されることになります。
例えば、クライアント側から100万円の予算が付いて開発をスタートさせて、70%程度まで開発が進んだ段階でプロジェクトが頓挫した場合、100万円の70%である70万円を請求できるのです。
②修補請求に制限がつけられた
瑕疵担保責任の一つにバグなどの修正を求める瑕疵修補請求があります。
改正前は瑕疵が重要な場合は、過分な費用がかかったとしても瑕疵修補請求ができると定められていました。
しかし、改正後は瑕疵の重要度という考え方自体がなくなり、修補に過分な費用がかかるケースでは、クライアントはベンダーに対してシステムの修補請求ができなくなりました。
この改正により納品物に対して責任を負わずに済むわけではありませんが、比較的ベンダー側の負担の軽減につながる変更点と言えるでしょう。
瑕疵から契約不適合に変わった影響は？
1.システム開発における瑕疵と契約不適合
現行の民法では、ベンダー側が負う責任義務として、瑕疵担保責任があります。
瑕疵とは、一般的には当事者の予期するような状態や性質が欠けていることを意味する言葉ですが、システム開発における瑕疵とは納品物の不具合（バグ）などを指します。
ただし、実際はテストをしっかり行ったとしてもバグを完全に取り除くのはかなり難しいものです。
そのため、一般的には、バグが発見された後にベンダーが遅滞なく補修を終えて完了したり、クライアントと協議して相当と認められる代替措置を講じたりした場合は、バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないとされています。
平成9年2 月18日の東京地裁の判決（判例タイムズ９６４号１７２頁）でも
コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから，コンピューターシステムの構築後検収を終え，本稼働態勢となった後に，プログラムにいわゆるバグがあることが発見された場合においても，プログラム納入者が不具合発生の指摘を受けた後，遅滞なく補修を終え，又はユーザーと協議の上相当と認める代替措置を講じたときは，右のバグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないものというべきである。
との見解が示されています。
つまり、バグが発覚したとしてもベンダーが遅延なく対応すれば瑕疵とは認められないというわけです。
しかし、バグ=瑕疵ではないとすると、どのような状態が瑕疵に該当するかは非常に曖昧で、発注側と受注側の間で「瑕疵担保責任」を巡りトラブルに発展するケースも多くみられました。
そのような現状も踏まえた上で、改正民法では、納品物などに欠陥があった場合に買主側がどのような救済を受けられるのかについて合理的なルールを明確化するべきとの観点から、瑕疵担保責任について全般的な見直しが行われました。
その結果、「瑕疵担保責任」という概念は廃止され、「契約不適合責任」という概念に置き換わっています。
瑕疵が本来備わっているべき性質が備わっていないことを意味するのに対して、契約不適合は目的物の種類、品質、数量などが契約の内容に適合しないことを意味します。
2.契約不適合に改定された影響は？
瑕疵から契約不適合に改定されたことにより、ベンダー側が不利になると考える方もいらっしゃるようです。
しかし、実際は現行の民法でも、瑕疵とは「契約の内容に適合していないこと」を意味するものと解釈されていたため、契約不適合と変わりはありません。
また、不具合（バグ）＝契約不適合とはならないという意味でも現行と変わらないと言えるでしょう。
契約不適合は目的物の種類、品質、数量などが契約の内容に適合しないことと定義されていますが、システム開発における目的物の品質を具体的に定義するのは非常に難しいため、
改正後もその定義を巡って受注側と発注側が争うケースは想定されます。
成果完成型の準委任契約が新設された影響は？
準委任契約については前述しましたが、改正民法では従来の履行割合型に加えて成果完成型が新設されます。
履行割合型と成果完成型の違いは以下のとおりです。
- 履行割合型：提供した労働時間や工数をベースとして報酬を支払う役務提供型の契約
- 成果完成型：システムなどの成果物に対して報酬を支払う契約
履行割合型は、長期のプロジェクトや時間単位で報酬計算したい場合に用いられます。
いわゆるSES契約などでよく用いられ、納品物がなくても費用請求することが可能です。
要件定義～基本設計までを準委任契約、詳細設計～リリースまでを請負契約として受託するケースも多いようです。
改正民法で新設された成果完成型は請負契約と似ていますが、善管注意義務（＊）さえ果たしていれば、予定どおりプロジェクトが完了しなくとも債務不履行責任を負わないという点が異なります。
（＊業務を委任された人の職業、専門家としての能力、社会的地位などを考慮して一般的に期待されるレベルの注意義務）
債務不履行責任を負わないというのは大きなメリットなので、請負契約ではなく準委任契約の成果完成型にすればよいと思われるかもしれませんが、過去の判例をみると一概にそうは言い切れません。
請負契約か否か、プログラムの完成義務を負っていたか否かが争点となった平成3年2 月22 日の東京地方裁判所の判決（判例タイムズ７７０号２１８頁）では、受注側が作成した開発工程表に、プログラムを完成させることを前提としたスケジュールが記載されていたことなどの理由から、請負契約であると判断されました。
つまり、準委任契約か請負契約かは、契約書の表記だけではなく、契約の内容によって判断されることになります。
改正民法に対応した契約書見直しのポイント
1.責任追求期間の明示
民法には強行法規と任意規定がありますが、今回ご紹介した規定は全て任意規定なので、民法の規定と異なる契約を締結することが認められています。
改正民法では、システム開発が完了後、実質5年間は不具合対応をしなければいけないことになりますが、不具合対応は納品後6ヶ月までに限定する旨を明記した契約をクライアントと交わしていれば、6ヶ月以降は不具合対応の責任から逃れることが可能です。
実質5年間の不具合対応はベンダーにとっては負荷が大きいので、不具合対応期間についての規定は契約書に盛り込んでおくとよいでしょう。
また、期間の起算点が契約内容に適合しないことを「知った時」から１年以内とされていますが、この「知った時」という基準は、発注側の主観に左右されることになってしまい、いつが「知った時」なのかで争いになる可能性があります。そのため、こうした紛争を未然に防止するためには、契約書において、改正前のように「引渡し時」からという客観的な用件に改めることも検討すべきです。
2.契約書に明記するべき事項
「瑕疵担保責任」から「契約不適合責任」に改正されたことにより、受注側と発注側の間にトラブルが発生した場合に、システムに欠陥があるかどうかよりも契約の内容に適合するかが争点となる可能性があります。
そのため、契約書には、業務範囲、完成基準、クライアントのシステム環境などの前提条件などをできるかぎり詳細に記載することが求められます。
また、開発フェーズに入ってから仕様変更や追加が発生してトラブルになるケースも多いので、リスクマネジメントの観点からも仕様変更や追加を行う際の手続きや費用負担などに関する規定も契約書に明記しておくとよいでしょう。
また、改正民法で発注側の権利として追加された代金減額請求により減額される金額の算定方法は解釈に委ねられていますので、算定方法についてはあらかじめ明確に定めておくと安心です。
3.上流工程を丁寧に行うことも大切
改正前後に関わらず言えることですが、要件定義などの上流工程を丁寧に行うことは、システム開発でトラブルを起こさないために非常に大切なことです。
上流工程における要件定義や仕様の曖昧さが開発フェーズ以降の混乱につながり、品質低下や開発遅延などの重大なトラブルに発展するケースは非常に多いのです。
平成16年3月10日の東京地方裁判所の判決（判例タイムズ１２１１号１２９頁）では、ベンダー側には成果物を納品するだけではなく、システム開発の専門家として、クライアント側の意見を調整して開発作業を進行させるプロジェクトマネージメント義務があるとの見解が示されています。
クライアント企業の中には情報システム部門を持たない企業もあり、ITリテラシーには格差があります。
ITリテラシーが低いクライアントの担当者とは話が噛み合わないこともあり、クライアント側の要求事項を完璧にシステムに落とし込むのは至難の業に思えるかもしれません。
それでも、プロのシステムエンジニアとして、クライアント側が抱えている現状の問題点を分析し、これから開発するシステムに対して望んでいる本質的な部分をしっかりヒアリングして要件定義書や基本設計書に落とし込むように心がけることは大切です。
契約書の雛形などを作り込んで自社を法的トラブルから守ることも大切ですが、クライアントの満足度を高めることが結果的に法的なトラブルへの発展を最低限に抑えることにつながります。
まとめ
今回は改正民法がシステム開発に及ぼす影響や契約書の雛形を見直す際のポイントなどについて解説しました。
システム開発における契約は、無形のシステムが成果物となるため、契約時に受注側と発注側で成果物に対するイメージを完全に一致させることは非常に難しいという特質があります。
さらに、仕様変更や追加が頻繁に起こるケースも多いため、法的なトラブルが起こる可能性も高いです。
トラブルを未然に防ぐためには改正民法の内容を正しく理解し、早めに契約書の雛形の見直しや上流工程の品質改善に取り組むことが大切です。
社内のメンバーだけで改正民法に対応した契約書の雛形を作成するのは難しいと感じた場合は、IT業界特有の商慣行や取引慣行に精通した弁護士に相談するとよいでしょう。
- 得意分野
- ベンチャー・スタートアップ法務、一般民事・刑事事件
- プロフィール
- 京都府出身
同志社大学法学部法律学科 卒業
同大学大学院 修了
北河内総合法律事務所 入所
弁護士法人アディーレ法律事務所 入所
東京スタートアップ法律事務所 開設
