IT導入時・システム開発の契約の基礎
IT導入やシステム開発を進めることが決まったら契約となります。
しかし契約と言っても単純ではなく、一度してしまったら変えるのは困難です。
よって慎重に進めるないといけません。
契約については、IPA（情報処理推進機構）にてモデル契約書が提示されていますので、参考にしてください。
請負契約と準委任契約
ITシステム開発においては、基本的には民法上の扱いとして請負と準委任の契約形態となります。
後から揉めないよう、よく知っておく必要があります。
請負契約とは
仕事の完成義務がある契約となります。
発注した仕事が完成することが完了条件となりますので、発注側としては分かり易いものとなります。
先に決められていた金額と期間で、所定のものが出来上がるという発注ですから、予定が立てやすいということなります。
契約が成立するのは、成果物の内容が具体的に特定できることが前提となります。
ところが、そんなに簡単ではないというのが、ITシステム開発です。
準委任契約とは
請負とは別の契約形態として、準委任契約があります。
請負とは違い、完成義務を負いません。
完成の責任のない発注というのは果たして成り立つのでしょうか？そんな発注するでしょうか。
準委任契約があるのは、成果が形として見えないものであったり、始めに明確にできなかったりする場合に行われるのが通例です。
では、形が見えなかったり、始めに明確でなかったからと言って、いつまでも終わらず、追加費用がいくらでも発生する、ということでは、発注する側は契約できないですね。
ただ単に人を一定期間調達する、ということとは違う点があります。
それは、善管注意義務というものです。善良な管理者の注意をもって委任事務を処理する義務を負うということです。
そんなこと言われてもわかりにくいですね。
民法の解釈では、取引の通念に従い相当と認むべき人となっています。
ますますわかりにくいのですが、相当と認むべきというのは、それなりのプロであることだと言えます。
よって、エンジニアであったりプロジェクトマネージャというべき人が、進めるべく内容を計画に従い進めることができるという前提で契約していると思っていいです。
準委任契約だといつまで経っても完成しなくてもよいのか？
準委任ですと完成義務はありません。
よって、受注側が有利と言えます。しかし、成果の完成を求めることができるようになりました。
2020年4月の改正民法により、成果に対して報酬が支払われるケースが定義されました。
それにより二つのケースが存在することになります。
| 履行割合型 | 履行の割合に応じた報酬を請求できる、つまり完成に関係なく時間単位での契約 |
| 成果完成型 | 成果に対して報酬が支払われる合意がある場合、完成により報酬が発生する、つまり請負に類似した契約 |
成果完成型は受委任ではありながら完成による報酬ですので、請負と同じように扱うことができ、なおかつ始めにきっちり決めていなくてもいい、柔軟で使い勝手のいい契約ということでしょうか。
いやそこまで都合はよくないです。
あくまでも準委任の範囲ですので、受託側に完成責任はありません。
ますますわかりにくいかもしれません。
基本的は完成してもらうということなるでしょうが、なんらかの条件により完成できない事象が発生することもあり得るということを前提に、マネジメントされることを含めた契約になるということでしょう。
契約したものが出来上がらなかった場合はどうなるのか
請負で完成しなかった場合
完成したものに不具合があった場合は、契約不適合責任として請負人に請求可能となります。
| 追完請求 | 不具合部分の修理の請求が可能 |
| 損害賠償請求 | 損害が発生した場合は損害賠償請求が可能 |
| 代金減額請求 | 請負代金の減額の請求が可能 |
ただし、代金減額請求ができるのは、原則として修理を請求したが請負人が応じない場合に限られます。
| 契約解除 | 契約を解除して代金の返還を請求することが可能 |
ただし、契約解除ができるのは、原則として修理を請求したが請負人が応じない場合に限られます。
民法上「不具合を知ったときから1年以内」に不具合の内容を発注者に通知することが必要となっています。
10年有効ですが、契約書で行使期限をより短く設定することや長く設定することが可能なので、通常1年となっていることが多いです。
このように請負は、完成しなかった場合は厳しい扱いとなりますので、請負人側は慎重になります。
少しでも不明確なものがある場合は、請け負いたくありませんし、リスクは積んでくるので高額になります。
準委任で完成しなかった場合
準委任契約だと契約不適合は追及はできません。
ただし、善管注意義務を怠ったことにより結果が伴わなければ、善管注意義務違反として債務不履行責任を負います。
| 履行の強制 | 履行遅滞における履行請求や、追完可能な不完全履行における追完請求は、履行不能であるときは、債権者は、その債務の履行を請求することが不可能 |
| 契約の解除 | 契約によって生じた債権の場合には契約の解除が可能 |
| 損害賠償 | 債務者に帰責事由がある場合は、損害賠償を請求可能。履行請求権や解除権があれば、合わせて行使可能 |
準委任は完成に対して義務がなく、受注者が有利と言えます。
しかし、善管注意義務をもって進めなければならないため、その点を追求できるのであれば、契約解除や損害賠償請求までできるので、ただたんに遅れたり、できなかったりしていないかを発注側もマネジメントしている必要があります。
ITシステム開発フェーズごとのよくある契約形態
一括契約と段階的契約
ITシステム開発においては、すべてを契約する場合と段階的に契約する場合とがあります。
段階的に詳細化され、徐々に明確になってくるのが一般的であるため、一定規模であれば段階的契約であることが多いです。
ただ、段階的であると、途中工程まで終わった時点で全体の金額が思ったより増えてしまい、予算オーバーとなる危険性もあります。
発注側としては、できるだけ少ない回数で確定させたいところですが、徐々に内容が決まってくるのも実態です。
よって、要件定義とそれ以降、もしくは基本設計までとそれ以降といった契約が多く見られます。
フェーズごとの契約形態について見ていきます。
企画フェーズの契約形態
企画フェーズにおいては、これから何をするのかを考えるフェーズとなっていますので、事前にやることが確定していることのほうが少ないはずです。
自分たちで実行できない場合は発注して支援を頼むことになるかと思います。
一般的に準委任契約となります。
要件定義フェーズの契約形態
企画段階で要求内容が明確になっているのであれば、要件定義を請負で契約することは可能です。
しかし、多くのベンダーは準委任にさせて欲しいと言います。
やはり、ある程度実施範囲が決まっているように見えても、要件定義はこれからどう作るかを決めていくものなので、想定外のことが出てくることは予想されるからです。
ベンダーから見ると、相手から要件を引き出すということにおいては、相手に依存したことなので、完全にコントロールできるとは限らないという思いもあります。
よって、多くの場合は準委任契約となります。
基本設計フェーズの契約形態
基本設計フェーズになると、要件が決まっているはずなので、発注側としては後の工程は請負で進めたいと考えます。
しかし、ベンダーは準委任で進めたいと考えます。
準委任にしたい理由は、基本設計は外部設計であるユーザ操作周りを決めるにあたって、コントロールしきれないことが発生すると考えているからです。
要件が決まっていたとしても、実現すべく設計は幾通りもあります。
決めるにあたっては、人に依存する部分も出てくるため、どうしてもコントロールしきれないことは出てきます。
総じて言えば、準委任契約か請負契約ということになるでしょう。
詳細設計・ソフトウェア開発・結合テストフェーズの契約形態
詳細設計から結合テストのフェーズは開発行為になります。
ここまでくるとすべきことは決まっていることが前提となっているため、請負契約となることが多いです。
ただし、準委任を要求してくるベンダーもあります。
これは、システム開発の特性によります。
一つは、開発段階になっているからと言ってやはりコントロールしきれない部分が残るような開発であることです。
ある程度実現できたものを確認したら、やはりこうしたほうがいいというやり取りをしながら進めることになるであろう開発です。
基本設計で決めたものの、出来上がりに調整が入ることが前提になるようなものはあります。
始めからアジャイルで進めるべき類のものと言えます。
もう一つは、他からの影響を受ける可能性のあるものです。
他からと言いましたが、開発対象そのものの場合もあります。
影響を受けるというのは、開発していく中で、他が改修されることで開発範囲に影響が出るということです。
開発対象そのものに影響を受けるというのは、改修案件だったとして、改修元のプログラム資産に潜在的な誤りがあったようなケースです。
総じて言えば、開発フェーズは請負契約が多く、稀に準委任契約となるでしょう。
システムテストフェーズの契約形態
システムテストは開発の最終段階と言えます。基本設計が終わっているのであれば、やるべき内容も決まっていると言えます。
よって請負でいけるはずです。
ところが実態は準委任になることのほうが多いと思われます。
それはなぜかというと、ユーザ側のエンドユーザの参画や他システム連携などにより、コントロールしきれないことが出てくることが想定されるからです。
もちろん、その開発プロジェクトの特性によります。
受入・運用テストフェーズの契約形態
受入や運用テストは発注側であるユーザ企業側が主体となります。
よってベンダーはその支援ということになりますので、通常準委任契約となります。
保守・運用フェーズの契約形態
保守運用については、準委任と請負の両ケースがあります。
稼働後にユーザ企業側で保守運用を基本的には行い、ベンダーには人数×月数にて準委任にてお願いするというケースはあります。
しかしユーザ企業側では保守運用ができないため、ベンダーにまるっきりお願いするケースもあります。
保守運用業務においては、問い合わせ等の変動要素があるため、請負にはならなそうな気もしますが、その変動要素を管理することにより、請負となっているケースはあります。
マネジメントをベンダーに委ねることになりますので、金額のコントロールはできますが、割安とは限りません。
段階的契約での留意すべきこと
各フェーズにより契約形態が変わることもあるため、段階的契約はよく行われます。
段階的に要件・仕様が確定していくことから考えると、契約も段階的のほうがスムーズと言えるかもしれません。
しかし、実務を考えると、必ずしもスムーズとは言えません。
すべて一括の請負契約であれば、契約は1回で検収を最後にすればいいだけになります。
検収すべきは出来上がっているかどうかだけです。
しかし段階的ですと、複数契約をする必要があります。それだけで手間は増えることになります。
前工程が完了し、その後の範囲と見積が明確になり、後工程の契約をするということに額面上はなります。
ところが、まともにそのように運用すると、プロジェクトは契約間では中断せざるを得ません。
中断になるということは人の手配の問題からすると、効率的ではありません。
契約行為があるので、実態としては主要なメンバは稼働しています。
この問題を解決するために進めるやり方としては、途中工程で中断の可能性があるかどうかで違ってきます。
中断の可能性、すなわち前工程で要求・仕様が膨らみ、後工程はもうできないと判断することがあるかということです。
あり得るのであれば、額面通り進めるべきです。
もしそうではなく、最終納期は決まっていて、基本的には前に進めるということであれば、契約間で途切れないように契約期間を重ねる等の工夫が必要になってきます。
コメント