民法改正？多段階契約？システム構築を委託する際の注意点とは【2024年最新版】

すべてのビジネスの基本は契約書をきちんと交わすことにありますが、システム構築を発注する際の契約内容について、完全に理解していると自信を持って言える担当者の方はそれほど多くないのが実情でしょう。
この理由の１つは、システム開発がまだ目に見えない完成品の設計図を作るところからプロジェクトを開始しなければならないという事情にあります。
開発側企業にも発注者自身にも、まだ完成品の姿が完全に見えて切っていない状態で必要な作業を割り出したり、完成品の引き渡しのための要件を詰めて契約書を作成したりするのは確かに困難な作業です。

大企業であれば、契約書は法務部のリーガルチェックが入ることが原則ですが、専門の法務部などを持たない会社では、発注担当者が開発会社の営業マンが説明してくれる内容を聞いて、特別な疑問点などがない場合には社内の稟議書類の１つとして処理に回してしまうことが一般的でしょう。

IT部門のシステム構築やメンテナンスでその会社との付き合いも長く、担当者だけでなく会社の経営レベルの方とも十分にコミュニケーションが取れているというケースでは確かにこれでもよいかもしれません。
しかし、きちんと相見積もりを取って、内容的にも金額的にも最適な外注先を探そうという正攻法でいくならば、発注担当者にとって契約書の中身をきちんと読み取る基礎知識は必須です。

この記事では、システム開発の現場で評価の高い「多段階契約」や2019年の「民法改正」なども踏まえ、システム構築発注を成功させる契約の基本を解説します。

仕事を外部に発注する際には、「業務委託契約」「請負契約」と２つの契約形態があります。
両方とも仕事を依頼することには変わりはないのですが、何を対価とするかが大きく違います。
この契約の種類を認識しておくことが正しい発注の大前提となりますので、まずはその違いを押さえましょう。

「業務委託契約」とは、業務遂行に対して支払い対価が発生する契約です。
例えばビル掃除やイベントの受付業務などが典型的な業務の委託になります。
業務委託の特徴は、ビル清掃という「納品物」やイベント受付という「納品物」といった具体的なものがないことが特徴です。
どちらも、ビル清掃という業務行為、イベント受付という業務行為に対して報酬が支払われますが、完成品のきれいなビルを納品したり、受付によって発生する成果物を納品したりはしません。
純粋に、業務の遂行に対して対価が発生するのが「業務委託契約」の特徴です。

ここで発注担当者の方はおそらく「完成品がない」ということに不安を覚えると思います。
最終納品物がないため、「仕事はやったから支払いをお願いします」という業務委託をされた側の言い分が常に成立してしまうように思えますが、もちろんそんなことはありません。

業務委託される側には民法用語の「善管注意義務」があります。
善管注意義務とは業務を委任された人の職業や専門家としての能力、社会的地位などから考えて通常期待される注意義務のことを指します。
このため適切な注意義務を怠り、履行遅滞・不完全履行・履行不能などに至る場合は民法上過失があると見なされ、状況に応じて損害賠償や契約解除などが可能となります。

「業務委託契約」が業務の遂行そのものに対して対価が発生するのに対して、「請負契約」では完成品を納品することに対して対価が発生します。
例えばピザの宅配や、一戸建て住宅の建築は引き渡しのときに対価が発生します。
これらの仕事には明確な「注文したとおりのトッピングがのっているピザ」「雨漏りなどの不具合のない住宅」といった完成形の要件を満たした「納品物」があります。
業務委託契約のように「ピザを作る」や「家を建てる」といった行為そのものに意味はありません。
「請負契約」では、あくまでも完成品である納品物が仕上がって、はじめて意味ある仕事が成立するわけです。

「請負契約」は完成品を納品するための契約ですので、業務委託契約のときの「善管注意義務」よりもさらにはっきりとした責任があります。
それは「瑕疵（かし）担保責任」というものです。

瑕疵とは、納品物に取引上普通に要求される品質が欠けていることなど、欠陥がある状態を指します。
そして「瑕疵担保責任」とは支払いの対価の納品物に要求されるレベルの品質が欠けているときに発生します。
システム構築で言えば、インタフェースなどの形はできていても、動作に不具合がある場合などは瑕疵担保責任の対象となります。

システム構築には、「顧客データベース構築」「会計管理システム構築」「受発注業務支援システム構築」などの納品物がすぐにイメージできるものがあります。
こうした完成品を納品してもらう場合には「請負契約」が向いています。
しかし、システム構築においては、こうした明確な納品物がある仕事だけではありません。
例えば既存のシステムを改良して、最新のセキュリティ機能を付加してもらうなどの場合です。こうしたときには、すでに納品されているシステムに追加機能を施す「業務委託契約」を結ぶのが適切になります。

では初回のシステム構築発注に適しているが「請負契約」で、業務委託契約は追加のバージョンアップのときにだけ使う契約形態なのか、と言うとそうでもありません。
「請負契約」を結ぶためには、完成品の定義を厳密に行う必要があります。
なぜなら、この定義がしっかりと仕様書レベルまで落とし込まれていないと、納品時に何を以て「システムの完成＝完全な納品物」として対価を支払うのかが不明確になるからです。

しかし、この記事の冒頭部分で指摘したように、システム構築では最初に完全な完成形を想定し仕様書などに落とし込んで仕事を発注することが困難なケースが少なくありません。
こうしたときには、無理に完成形を想定して「請負契約」を結ぶよりも、必要な業務を行ってもらう「業務委託契約」が向いているケースも多々あります。
例えば、自社にとって効果的な「顧客データベース」を構築したいという場合、「請負契約」を締結するためには、顧客データベースの中身をどのようなものにするかについて、時間をかけて仕様書をまとめる必要があります。

しかし、自社にとって効果的な「顧客データベース」とは何かについては、システムを営業部門やマーケティング部門に実際に使ってもらい、そのフィードバックを受けながら完成度を高めていく、というやり方のほうが結果的に良いシステムができ上がるケースがあります。
こうしたケースでは、最初からいま見えていることだけを前提として完成形のイメージを固めてしまうよりも、走りながら考え、優先順位が付いた部分的機能を分割発注することが可能な「業務委託契約」のほうが向いていると言えます。

ここまでで、契約の基本的な部分は押さえましたので、次はどちらの契約形態が適切なのかポイントごとに検証していきましょう。

それでは、「このシステム構築の場合、業務委託契約と請負契約のどちらがいいの？」という素朴な疑問に対するヒントについて具体的に解説していきます。

システム開発を行う場合、どこからどこまでを開発の単位とするかを最初に決定することが大切です。
システム開発プロジェクトの失敗で一番多いのはシステム開発で対象とする範囲がいつのまにか巨大に膨れ上がり、納期やコストが大きく膨らみ、最悪の場合にはプロジェクトが空中分解することです。

とはいえ、この部分は再三指摘しているように最初に詳細まで決定することが非常に困難です。
システム開発の見積もり項目でよく目にするのが「システム構築一式」というものです。
見積書をチェックする立場にある人なら必ず見たことのあるこの「システム構築一式」という項目は、システム構築のプロフェッショナルにとっても、システム開発の範囲をプロジェクトの初期に決定することがいかに難しいかを表しています。

３月の決算が終わり５月末日までに旧会計システムで財務諸表を作成した後、ただちに６月１日から新しい会計処理システムを導入する、というようなスケジュールが決まっている場合、完成期日は非常に重要になってきます。
また旅行業界などで、８月９日から８月16日までのお盆シーズンに向けた特別キャンペーンを行いたいので遅くとも８月１日にはシステムが稼働している必要がある、といった場合にもスケジュール厳守は必須となります。

こうして例を挙げると、システム構築には必ずローンチのスケジュールを明確化する必要があるように見えますが、実際にはそうしたケースばかりでもありません。
「現在営業部隊とマーケティング部門にてすべて手作業でやっている優良顧客リストの抽出作業を自動化してほしい」とか「現在稼働している営業支援システムを、営業部の意向を最優先してもっと使い勝手の良いシステムに改良してほしい」などというケースのように、厳密なローンチのスケジュールは決まっていないことのほうが多いのです。

例えば、いま稼働している古いタイプの汎用機システムの耐用年数が迫っており、パソコンベースのオープンシステムに移行したい。
稼働中の汎用機システムから時代遅れの不要な機能を取り除いたり、いろいろな付加価値を付けたりすることも考えたいが、まずはホストコンピューターが不具合を起こす前にすべての機能を移行したい。
こういう場合には、システムの仕様で迷うことはありません。

しかし多くの場合、システムの仕様は最初からは決まっていません。
システム開発においては最初に範囲が決定し切れなくても、ただちにそれがプロジェクトの失敗に結び付くというわけではありません。
例えば、最初から全体の範囲を細かく規定することを積極的に放棄して、開発単位を小さく分割し、小さな納品を繰り返しながら次に着手する優先順位を常に見直していくという「アジャイル型開発」は、この問題を解決する手法です。
範囲が決まっていないのなら、それを前提に契約書を取り交わしましょう。

システム開発には、「要求定義」「要件定義」「内部設計」「外部設計」「プログラミング」「テスト」「運用・保守・メンテナンス」などいくつかの工程があります。
このすべてを一括して請け負う契約方式を一括請負方式と言います。
これに対して、工程ごとに最適な方法（「請負契約」が適切な工程なのか、「業務委託契約」が適切な工程なのか）を判断してプロセスごとに個別契約を順次締結する方式を多段階契約方式と言います。

この段階では、まだシステム構築会社がコーディングを始めることはありません。
どのようなシステムが必要なのかを発注者側と詰めていきますので、完全に共同作業であり、作業内容的に言えば主役はむしろ発注者側です。
このため、完成品を納品するということではなく、業務の遂行を依頼する「業務委託契約」が適切です。

基本設計段階では、決められた要件定義に従ってシステム構築会社が設計図を作ります。
これについては、設計図を作るという行為に重点があるのではなく、「要求定義」から「要件定義」段階の共同作業で明らかにされた内容が、きちんと設計に盛り込まれているかどうかを基準にしたその設計図の完成度が問題となります。
したがって、この工程では「請負契約」が適切です。

「プログラミング」～「テスト」までは、仕様に基づきシステム構築会社が作業する工程になります。
また、期待したとおりに動く納品物を仕上げてもらうことが目的となりますので、「請負契約」が適切です。

運用から保守、メンテナンスまではいわゆる「完成品」というものがありません。
例えば医療行為は医師が適切な措置をするために業務を行うことに対して医療費が支払われますが、運用・保守・メンテナンスもそれと同じだと考えればよいでしょう。

医師は適切な治療を行う義務を負いますが、最終的に病気を治すという「完成品」を提供する義務までは負いません。
運用・保守・メンテナンスも同様で、運用・保守・メンテナンスの業務範囲を超えてシステムを修復することが必要といった場合には、その業務に関して新たに「請負契約」を結んできちんと動く完成品を納品してもらいましょう。

以上が、「多段階契約」の基本的な考え方となります。
便利な契約方法なので、ぜひ試してみましょう。

明治に制定されて以来ほとんど抜本的な改正がなかった民法が2019年に大きく変わります。
今回で改正される条文は200以上にのぼり、IT業界でもその契約形式や中身などについて大きな変化があると言われています（現在審議中）。

では、これまで見てきた「請負契約」や「業務委託契約」はどのように変わるのでしょうか？ さっそく確認して、将来的に自社が不利益を被らないように準備しておきましょう。

■ 業務委託契約の支払い条件が明文化される

現在の業務委託契約では、報酬は業務を委託した内容について支払われることが基本ですが、2019年からは契約に「成果に対して支払う」という文言が加えられます。
したがって、業務委託契約の形式を取りながらも、成果物に対する報酬契約を結ぶことが可能になります。

これによって、従来型の支払いパターン（履行割合型）と完成品への支払いパターン（成果完成型）の２つのパターンが選べるようになります。

■ 瑕疵担保責任が分かりやすくなる

請負契約においては、完成品を納品できなかった場合に「瑕疵担保責任」の対象となりますが、新しい民法では「瑕疵担保責任」そのものが条文から削除されます。
と言っても、請負契約において発注先企業の責任を問えなくなるというわけではなく、「瑕疵」や「担保」というやや分かりにくい言葉が使われなくなり、「契約不適合」（最初の完成品の定義からずれている）という、より実態が実感しやすい言葉になります。

■ 代金減額請求権が加わる

完成品の定義から外れた成果物を納品されてしまった場合、業者によってはなかなか追加の修正をしてくれない、もしくは技術力がなくてできない、というケースがあります。
そんなケースを処理する目的もあり、新しい民法では当然要求されるべき追加修正が行われなかった場合、不具合の大きさや重要度に応じて、支払金額を減額請求できることを明記します。

■ 賠償請求の起算点が変わる

現在の民法では、納品されたときを起点として１年以内でないと不具合を発見しても無償の修正や、他社に依頼した場合の費用の請求ができません。
新しい民法では納品から最大５年以内とその期間が延びます。
５年というとIT・システムの世界では一昔前という感覚ですので、納品して５年の製品にまで品質を保証するということは、開発側にとってはかなりの負担になることが予想されます。
逆に言えば、発注側にとってはそれだけ安心材料が増えることにもなるわけです。

ただし、５年という期間を担保するために、開発側では５年間の補償金額をコストとして見積もりに反映させるかもしれませんので、注意しましょう。

■ プロジェクト中断時の責任が明文化される

「請負契約」では、成果物の完成が支払いの条件となりますので、プロジェクトの完成は必須事項です。
そのため、法律上の条文としてはプロジェクトが中断になった場合の規定が何もありませんでした。
しかし、システム開発の現場では、実際に最後まで完成することができなかった「請負契約」によるプロジェクトも多数あります。
こうした事態に対処するため、新しい民法では、プロジェクトが中断した場合でも支払い義務があると明文化することになりました。

最後に、これまでとりあげた「請負契約」「業務委託契約」「多段階契約」に共通するその他の注意点についてまとめます。

■ システムの権利帰属を明記しておく

開発されたプログラムの著作権は誰が所有するかについては思い込みによる誤解も多く、トラブルの種になっています。
発注側としては「料金を支払ってシステム構築の依頼をしたのだから、その成果物に関する一切の権利は当然自分たちのものである」と考えがちです。

しかし、著作権法上はプログラムの制作者側に権利が帰属するのです。
したがって特別な取り決めのない限りは、開発会社が自分の会社に納品したソースコードをそっくり使って、競合他社のシステム構築を格安で請け負うということもなんら違法性のない行為になってしまいます。

このことを防ぐためには、契約書にプログラムのソースコードを含めてシステム納品時にすべての権利が譲渡されるということを明確に規定しておく必要があります。

■ 第三者からの知的財産権の侵害申し立てに対処する

自社へ納品されたシステムのプログラムに、本来ライセンス料を支払って使用しなければならないソースコードが無断で多数使用されていた、というケースがあります。
そのシステム開発会社が過去に似たような案件を手がけ、パッケージ製品を使って構築した経験があるとします。そのシステム構築会社が新しいライセンス料金を払わないままに、手元にあった知的財産権を有する資産を流用した、などでこうしたトラブルが起きる場合があります。

こうした場合には、発注元はその事実すら知らないというケースが多いわけですが、知的財産権侵害の申し立てに連名で告発されないためにも、契約書に第三者から知的財産権侵害申し立てがあった場合の対処について責任を明確化する項目を入れておきましょう。

■ 下請け・孫請けは可能かを明記する

システム構築会社のなかには、営業部隊だけが存在していて、肝心のシステム構築作業はすべて発注者の知らないところで外部の格安業者、東南アジアなどのオフショア開発企業などに丸投げしているというケースもあります。

開発会社が下請けを使うことそれ自体は違法でもなく、実際にそうした形態で問題なく仕事の実績を残している会社もあります。
問題となるのは、将来的に納品物に不具合が起きたときに、実際の開発業務を行った会社が倒産するなどしていた場合です。
システム構築を実際にやってくれていたとばかり思っていたシステム構築会社が実は何もしていなかったという場合、トラブルに対処することはかなり困難だと言わざるを得ません。

問題は、そうした形態で開発を進めていたことを発注者が知らなかったというところにあります。
したがって契約書に、下請け・孫請けを使うとすればどんな内容の開発で使うのか、またその制限事項などについても明記しておくことが大切です。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

さて、いかがだったでしょうか。
「契約書は重要だ」という認識は持っていても、実際にどんなケースでどんな契約書を交わすことが必要なのかということについては意外と知らないことが多かったという実感を持った担当者の方が多かったのではないでしょうか。

完成形のまだ見えていないシステム構築を成功裏に終わらせるためには、契約書をしっかり交わすことが重要です。
このことはシステム構築会社もよく分かっているはずなのですが、実態としては「システム構築一式」という項目に逃げてしまい、具体的なシステム構築の仕様を見積書に的確に落とし込めない業者も多いのです。

こうした業者と「システム構築一式」契約を結んでも、その契約書の内容自体に価値がありませんので、プロジェクトの成功にはつながりません。
取りあえず動くプログラムは作れても、きちんとした打ち合わせを経て、工数を正確に出すことが苦手なシステム構築会社と組んでしまうと、プロジェクトの先行きが非常に不安です。

さらに、こうした業者は「仕様は最初から決めにくいので、一式としました」ということを口にしたがります。
当然、決めにくい部分の工程については「業務委託契約」を利用して「請負契約」と補完させ、プロジェクト全体を「多段階契約」でまとめるノウハウを持っているわけではありません。
また、積極的にプロジェクトの目的の見直しを行う「アジャイル型開発」に精通しているわけでもなく、単によく分からないので「システム構築一式」としているケースは要注意です。

こうした場面で不安を感じたら、ぜひ「アイミツ」にご相談してください。
「アイミツ」に相談していただければシステム開発の技術水準が高いというだけでなく、案件ごとに最適な契約を締結してプロジェクトを成功に導くことのできる、優良システム構築会社をご紹介いたします。