【システム開発・契約形態】システム開発の契約書の重要な役割とは？契約種類や契約書の記載例・注意点まで徹底解説！

「システム開発の契約書って大事なの？」

「システム開発に必要な契約書の書き方も見方も分からない…」

システム開発を行う上で最も重要になるのが契約書ですが、上記のようにシステム開発の契約書の重要性や本来の役割、作成の仕方に対しての知識が乏しく、本来の契約書の在り方について良く分かっていないという担当者は少なくありません。

システム開発の契約書があることで回避できるトラブルやリスクなどはもちろん、契約の種類による違いや必須となる義務などについて、本記事で詳しくご紹介致します。

これからシステム開発を行う、もしくは今まさに契約書の作成を行うという方に、ぜひ読んでいただきたい内容を多くご紹介しておりますので、しっかりと内容を理解し、正しく円滑なシステム開発が行えるよう万全の準備を整えておきましょう。

システム開発における契約書の役割

システム開発を行う際には、依頼した開発会社との契約を交わします。こうした契約書はシステム開発に限らず、会社同士で業務連携や協力体制を構築する際に必ず作成を行うでしょう。しかし、実はこの契約書は担当者によってはあまり重要視されておらず、様々な契約を数多く扱ってきた担当者の中には、契約書そのものをかなり軽く扱っているという事も少なくありません。

しかし、システム開発における契約書には非常に重要な役割があります。契約書を雑に扱い内容の把握が出来ていない場合、後々トラブルが発生した際に、さらに大きな問題へと発展していく事があります。そうならないためにも、契約書の役割をしっかりと認識し、何のために作成するのかを深く理解しておくようにしましょう。

スムーズなプロジェクト遂行のためのルール制定

システム開発の契約書の重要な役割として特に大切なのは、プロジェクトを円滑に進めるためのルールの制定です。食品やファッション、制作物などの形あるものの売買とは違い、最終的に完成する全体像のイメージが明確にできにくいという点があります。

そのため、依頼をした側、依頼を受けた側の間で認識のずれが生じやすくなってしまうという特徴があります。また、システム開発は仕様変更などが起こることも珍しくありません。そのため、当初の計画通りに進めるという事は困難になることが多々あるでしょう。

特に、長期間にわたり行われるプロジェクトなどの場合、経営方針の変更や組織変更、担当者の配置換えなどの社内環境の変化も大きく影響を及ぼします。こうしたシステム開発の特徴を踏まえ、想定された変更が生じた際にどう対処すべきなのかという事をあらかじめ決め、その内容を契約書に記しておくことで、システム開発の関係者全員に共通認識として把握させておくことが出来ます。担当者のみが把握しておくのではなく、開発に携わるすべての人材が理解しておくという事が何より重要と言えるでしょう。

法的リスク

法的リスクの軽減も、システム開発を行う上で外すことのできない重要な項目となるでしょう。契約書は、そのための重要な役割を担っています。民法規定は、「強行法規」「任意法規」の2つに分類されます。

• 強行法規→当事者の意思や意見などに関わらず、強制的に適用される規定の事
• 任意法規→当事者の間で合意がある場合、他の何よりもまず優先されるべき規定の事

例えば請負型の契約の場合、2020年に「瑕疵担保責任」が「契約不適合責任」に変更になったことにより、ベンダーが負う責任が従来よりもさらに重くなりました。これまでは納品物の引き渡しから1年以内が責任のある期間という事になっていましたが、契約不適合責任の場合、事実を知った時から1年という期間になります。そのため、納品を行い2年後に契約不適合と言う事実に気付いたという場合には、そこから1年以内ということになりますので、要は納品から3年経っていても責任を負う必要があるという事です。

契約不適合責任は先ほどお話しした任意法規になります。この任意規定の場合、法律によって定められている事項を自由に変えることが可能となっています。そのため、契約書に記載する場合、契約不適合責任は「契約不適合を知ったとき」にするのではなく、検収完了の時点やシステムが稼働した日などに設定を行ってくと、開発会社側の法的リスクを軽減させることになります。ここは双方でのすり合わせが重要となり、お互いが納得した上で取り決めるようにして下さい。この契約項目を正しく認識しておかなければ、大きなトラブルの火種となることがあります。

トラブルが生じた際の根拠

システム開発は、小さなすれ違いや認識の誤差から訴訟トラブルにまで発展する事があります。そのような場合に、契約書は訴訟に発展してしまった際に当事者の合意内容として機能するでしょう。こうした最悪な展開を予想し契約書の作成を行っておけば、後々になって慌てることなく冷静な対応が可能となります。システム開発での訴訟問題は珍しいことではありません。こうしたトラブルになる主な原因として挙げられるのが、納期遅延、仕様変更などにより追加作業を行った時の支払いによるトラブルです。

契約書に詳しく記載があれば、裁判所に対して双方がきちんと合意していたという事を客観的に示すことが可能となります。こうした具体的なトラブルを前もって想定しておき、その場合の対応の仕方、責任の所在を明確にしておくことにより、トラブルの素早い解決、無駄な争いを回避する事にも繋がると言えるでしょう。もちろんこうした事も、開発関係者はしっかり把握しておく必要があります。

システム開発の契約形態・種類とは？

システム開発は、見積もりの確認を行い契約を交わし開発スタートと簡単に進められるものではありません。契約そのものも種類があるため、それらをしっかりと把握し自社にとって何が最適な契約形態なのかという事を理解する必要があります。

システム開発の依頼をするためには、様々な条件の取り決めや見積書の項目確認など、開発を始める前準備というものが非常に多くありますが、契約形態によりその内容も異なってきます。

基本的な契約形態は上記のような内容となります。それぞれの特徴をさらに深く知り、自社のシステム開発にはどのような契約形態がふさわしいのかをしっかりと見極めるようにして下さい。以下でそれぞれについて詳しくご紹介致しますので、知識を収集し、自社ITレベルやスキルなどを考慮しつつ、正しい契約形態を選択するようにしましょう。

請負契約

依頼した仕事が完了する事で報酬が発生する契約形態になります。依頼した業務の完成が約束された契約となり、依頼を受けた側は原則として仕事が完了するまでは報酬の請求を行う事は出来ません。完成した成果物の納品、検収を経ることにより完了したと認識されます。逆に言えば、納品を行っても検収が終わらなければまだ完了したとは言えません。

システム開発の場合は、そのプログラム本体が成果物として扱われることが一般的になります。もしも、この成果物の内容の中に各種設計書やシステム構成図、テストを行った際の結果報告書、ユーザーのマニュアルドキュメントなどというものの提出も望む場合には、契約書にその旨をしっかりと記しておく必要があります。双方で話し合い合意した上で、成果物の詳しい内容を取り決めておきましょう。

請負契約には「契約不適合責任」という義務があります。これは先ほどお話しした2020年の民法改正の際に変更になり、これは成果物の品質が前提条件などの契約に適していない事を意味します。請負契約を行った場合、開発を請け負った側はただ単に開発を行い成果物を納品するだけではありません。その開発を行ったプログラム、すなわち成果物の品質が、契約内容に適合しているという確かな保証をしなければいけないという事です。先ほどの説明でもあったように、成果物が不適合と発覚した場合、受託側がその責任を負うことになります。

準委任契約

仕事や業務の遂行に対する報酬が発生する契約形態です。請負契約のように成果物の納品、検収を経て支払いが生じるという事ではなく、時間や日数と言った期間を基準とし、その期間遂行された業務量、時間に対して報酬を支払うという事になります。準委任契約の場合、法律行為以外の業務を主とした契約となり、受けた側には完成義務が生じることはありません。

しかし、先ほどお話しした2020年の民法改正により、準委任契約の際にも成果物に対して報酬を支払う場合の制定が設けられました。そのため、請負契約と混同されてしまう事がありますが、支払いのタイミングや受託側の義務などは大きく異なっています。

請負契約の場合、支払いのタイミングは先ほど説明した通り検収完了時が基本となります。しかし、成果型の準委任契約の場合、支払いのタイミングは作業の完了時や引き渡しのタイミングとなります。ですが、準委任契約の責任が軽いという事では決してありません。請負契約は準委任契約の場合、「善管注意義務」というものがあります。

これは、SEやプログラマーとして期待されるレベルの業務を遂行する注意義務を果たさなければいけないという事です。成果型の場合、契約上で取り決めた成果物の納品が出来なかった際には損害賠償や契約解除などの債務不履行責任を負わなければいけなくなります。

準委任契約と委任契約

契約形態には「準委任契約」と「委任契約」があります。この2つの大きな違いは、表で表したように法律的な業務があるかないかという点です。準委任契約の場合は、依頼する側が法律以外の仕事を委託し、委任契約は法律関係の仕事を委任するという形になります。そのため、システム開発の契約の場合には、この委任契約で締結するのではなく、「請負契約」「準委任契約」のどちらかで行う事になるでしょう。

多段階契約と一括契約

システム開発を行うにあたり、スタートから完成の全てにおいて一括で請け負う「一括契約」と、開発を複数工程に分割し、工程ごとに個別での契約を行う「多段階契約」というものがあります。プロジェクト開始前というのはシステムの全貌がまだ明らかとなっていません。そのため、必要な工数や期間などを正確に見積もることが非常に難しいという点があります。そのため、一括契約は依頼をする側、依頼を受ける側の双方にとって適切ではないという事も十分あり得るでしょう。

過少規模での見積もりとなってしまう事もありますし、高額な見積もりの提示が行われてしまうという事もあります。このような場合、システム開発の全てを一気に契約してしまうのではなく、多段階契約にして段階を踏みつつ進めていくという方法があります。規模の大きなプロジェクトなどの場合は、一括契約よりも多段階契約の方がスムーズに開発を行う事が出来るでしょう。

多段階契約の場合、各フェーズの性質を考慮し契約類型の選択をすることが可能となります。着手前にある程度の成果物が具体的に想定できる場合は「請負契約」となり、特定させることが困難な場合は「準委任契約」という事になるでしょう。さらに、要件項目やテストなど、システム開発部門とベンダーが共同で作業を進めていくという場合は、準委任契約での契約を行う事が多くなります。

契約形態それぞれのメリット・デメリット

契約形態は大きく分けて「請負契約」「準委任契約」の2種類に分けられます。また、先ほどご紹介したように、多段階契約や一括契約などもあり、自社にとってどの契約形態で行えばいいのか悩んでしまうという事もあるでしょう。システム開発を行う場合、その契約形態ごとのメリット・デメリットをしっかりと把握し、自社の開発内容と照らし合わせて検討する必要があります。それぞれの内容をしっかりと理解し、正しい選択を行えるようにしておきましょう。

メリット

上記のような内容が、それぞれの契約形態の主なメリットとして挙げられます。発注する側、受注する側双方にメリットは発生しますが、どちらの立場であっても、知識としてそれぞれの内容を把握しておくといいでしょう。請負契約のメリット、準委任契約のメリットを詳しくご紹介致します。

請負契約のメリット

求める成果物が手に入る→請負契約の場合、納期や成果物に関する具体的な取り決めを行ったうえで契約を行います。そのため、指定した基準を満たした納品がされるため、品質の安定が保証されています。万が一契約不履行があっても、修正依頼を行う事も可能ですので、「〇日までにほしい」「〇〇を納品してほしい」という場合は請負契約が適していると言えるでしょう。
コストの把握がしやすい→自社でシステム開発を行う場合、機能追加やエンジニアの増員によるコスト増加、トラブルのための想定以上の予算になるという事は少なくありません。請負契約であれば、発生するコストや開発人員の調整も受注側で行います。成果物に対する報酬はもちろんありますが、受注側の責任になるため余計なコストをかけることなく固定のコストで開発が可能となるためキャッシュフローが明確になります。
縛られることが無い（受注側メリット） →極端な話にはなりますが、「納期までに成果物が完成すればいいため自分のペースで仕事が出来る（もちろん、スケジュールや各フェーズに沿って開発するなど案件により様々です）」などというメリットがあります。請負契約では、発注側が指示を出す権利はありません。納期に間に合いさえすれば、時間やペースなどに縛られることなく作業を進めることが出来ます。

準委任契約のメリット

労働力が確保しやすい→例えば「システム管理を依頼したい」という要望の場合、準委任契約であればこの業務依頼のみを遂行してくれるエンジニアを効率よく確保する事が可能となります。契約の期間を細かく取り決めたうえで依頼することになりますので、多くの会社では繁忙期のタイミングに合わせて行っているという事よくあります。
仕様変更に柔軟な対応が可能→請負契約の場合、「〇〇日までに◇◇を納品」というような契約の形になりますので、一度契約を結んでしまうと発注側が後から納品物に対する指示を出すことは出来ません。準委任契約の場合、業務遂行のみでの契約内容であれば、こうした仕様変更などにも融通の利く契約形態と言えます。
完成しなくても報酬が発生する（受注側メリット） →メリットとして請負契約との違いと言えば、その報酬のタイミングです。準委任契約の場合、請負契約のような成果物がなかったとしても、これまでの業務遂行に対する報酬が支払われます。準委任契約は完成責任を問わない形になるため、完成してもしなくても、仕事を行えば行った分の報酬を受け取ることが可能となります。

デメリット

請負契約、準委任契約のどちらでも、当然メリットがあればデメリットも存在します。デメリットを前もって把握しておくと、もしもの際に落ち着いた冷静な対処が可能となりますので、しっかりと内容を把握しておくようにしましょう。以下で、それぞれの細かな内容についてご紹介致します。

請負契約のデメリット

エンジニアのスキルが上がらない→自社内でアプリやシステムの開発を行う場合、業務を行うと同時にエンジニアの成長やスキルアップを見込めますが、請負契約は「外注」という形での開発になるため、自社内のエンジニアの成長を促すことは困難と言えます。開発スキルやノウハウが自社内に蓄積することが出来なくなってしまうため、請負契約は必要な分だけの利用に留めるようにするといいでしょう。
仕様変更が困難→先ほど、準委任契約のメリットとして「仕様変更に柔軟な対応が可能」というお話をしましたが、請負契約の場合はそれとは逆に対応が困難という点があります。請負契約は「契約通りの成果物の納品」という仕組みになっているため、仮に設計に不備があったとしても、不備を抱えたままの成果物として納品されます。発注を行った後に変更や追加をこなうのは困難なため、契約を行う際に要件定義をしっかりと行っておくようにしましょう。
「成果が絶対的条件」となる（受注側デメリット） →検収・納品を行うまでは何が合っても報酬が発生することはありません。納期までに完成した成果物を納品する事が絶対的条件となりますので、完成し検収を行うまで受け取れるものは何もないという事になります。また、請負契約では契約不適合責任も負うことになります。納期厳守はもちろんの事、その責任は非常に重いという事を強く自覚する必要があるでしょう。

準委任契約のデメリット

納期アリの仕事には不向き→何度もお話しするように、準委任契約には仕事を完成させる義務というものがありません。仕様変更などといった柔軟性に長けてはいますが、納期がある契約には不向きと言えるでしょう。仮に納期までに完成品が上がらないという場合でも、受注側に責任はありません。こうした業務の結果に対しては、発注側に責任がある契約形態になるという事をしっかりと頭に入れておきましょう。
契約内容が曖昧になりやすくなる→業務上の「成果」というものが存在しないため、契約内容が曖昧になりがちという点があります。契約内容の認識のずれにより、業務遂行や報酬の支払いにおいて何かしらのトラブルが起きてしまうという事っ珍しくはありません。準委任契約を行う際には、報酬の支払い対象業務、契約有効期限などについて細かく取り決めを行い、相違がないように徹底しておくと安心です。
仕事内容に決定権がない（受注側デメリット） →準委任契約は、受ける仕事内容を決定することが出来ません。発注側から業務範囲を指定され、そこを忠実に行うという契約になりますので、得意分野での活躍が出来ない、作りたいものややりたい作業があっても選べないというデメリットが生じます。また、受二人契約ではシステム開発の一部工程のみの依頼のため、根幹にかかわるという仕事は非常に少なく、実力を発揮できないと嘆く方も多くいるでしょう。

担当者の3人に1人は契約内容の把握が出来ていない！？

システム開発の契約における内容は、実は多くの担当者がその全貌を全て把握できていないという事が少なくありません。実際、中小企業やベンチャー企業でのシステム開発依頼の際に、その契約書の内容を正しく全て把握できているという方は全体の30％弱となっており、実に7割以上の担当者は契約内容を完全に理解していないという実態があります。

3人に1人の割合で、契約内容を把握できていないという事になり、その内の4割以上の担当者は何かしらのトラブルに遭遇しており、契約締結に1か月以上かかってしまったという事もあります。

契約書の把握が出来ていない会社の開発で、最も多いトラブルが、「納期遅れ」「責任の所在」「成果物の質」の3つになります双方で作り込んだ契約書の内容を正しく完璧に博しておけば、こうしたトラブルを回避する事にも繋がりますが、実際は契約書は流し読み程度で終わってしまい、詳しいその中身を理解しているという方は非常に少ないのが現状です。

把握が出来ていない担当者と言うのは、新人に限った話ではありません。何度も同じようなシステム開発を依頼しているベテラン担当者であっても、その内容を把握できていないという方も多くいるでしょう。むしろベテランだからこそ、「確認しなくても大丈夫」「トラブルが起きた際はその都度対処できるから必要ない」と考えている方も珍しくありません。

そのため、契約書の内容をじっくり見て把握するという工程を省いてしまう事もよくあります。しかし、それではトラブル回避をスムーズに行うことが出来ません。また、いらぬトラブルを引き起こす要因にもなってしまうでしょう。契約書の内容はかならず把握し、開発に携わっている全ての関係者にも共有しておくようにしましょう。

契約書の様式の違いと記載例

IT業界では、こうしたシステム開発の契約書を作成する場合、「業務委託契約」「SES契約」という言葉をよく耳にするでしょう。しかし、実際これらは法律上に存在しない契約になります。ではどんなことを指しているのか。この「業務委託契約」「SES契約」というのは、すなわち本記事で紹介している請負契約や準委任契約などの契約形態の事となります。

システム開発の契約書は、成果物に対する知的財産権の帰属を明確化させ、保守管理、メンテナンス方法、月額料金などを定める必要があります。この保守管理などについては、別途の契約書作成を行ってもいいでしょう。さらに、双方の守秘義務に関する項目などについても明確にしておくと、いらないトラブルを回避することが出来ます。ここでは、請負契約と準委任契約の主な記載例をご紹介致します。

請負契約の契約書

請負契約の場合、「業務委託契約書」として締結されることが非常に多いため、このタイトルで契約書の作成を行っても問題はありません。業務請負と業務委託を区別するために、「業務請負契約書」とタイトルを付けるという事も多くあります。

• ソフトウェア開発契約書（プログラミング）
• システム構築契約書
• デザイン制作契約書

上記のように、開発する内容に合わせたタイトル表記を行うという事も多くあり、一概にタイトルは「〇〇でないといけない」という決まりはありません。

また、請負契約の場合準委任と異なるのは先ほどもお話しした「契約不適合責任」です。

１　乙は甲に対し、甲が指定する仕様書通りの成果物が開発されていることを保証する。

２　前項の保証期間は納入日から３ヶ月とし、同期間内に前項の保証事項に反することが原因で成果物に不具合が生じた場合には、乙は、自らの費用と責任において改修作業を行うものとする。

３　成果物が第三者の特許権等又は著作権を侵害して、当該第三者より成果物の使用を差し止められた場合又は損害賠償を求められた場合、乙は、第４条に定める委託料総額を限度として、甲に生じた損害を賠償するものとする。

https://www.ys-law.jp/IT/450/45023/

上記の記載例の場合、「前項の保証期間は納入日から３ヶ月」と記してあります。ここの部分は、本記事の冒頭「システム開発における契約書の役割・法的リスク」でもご紹介した通り、保証期間がいつからになるのかははっきりと明記しておかなければいけません。納品をした日なのか、システムが稼働した日なのかにより、保証期間がいつまでになるのかが変わってきます。

準委任契約の契約書

準委任契約は、何度もお話ししたように完成義務が生じません。そのため、明確な目的物がない以上は瑕疵担保責任、契約不適合責任は負わないものとなります。しかし、その反面先ほどもお話ししたように準委任契約の場合は善管注意義務を負っていますので、持ち得る能力を最大限発揮し、期待されるレベルの仕事を全うする責任があります。

もしも職務怠慢、致命的ミスなどといったトラブルが発生し、この義務に違反してしまった場合、債務不履行に基づいて損害賠償の請求や契約解除などという事にも繋がるでしょう。完成義務は負わない代わりに、適切な業務を遂行したのかを確認するための作業報告書の提出が重要になります。

第〇条 乙は、前条に定める要件定義書の確定後○日以内に、業務終了報告書を作成し、甲に提出する。

甲は、個別契約に定める期間（以下「要件定義作成支援業務終了の点検期間」という。）内に、当該業務終了報告書の確認を行うものとする。

甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、 乙に交付し、要件定義作成支援業務の終了を確認するものとする。

要件定義作成支援業務終了の点検期間内に、甲が書面で具体的な理由を明示して異議を述べない場合には、甲は要件定義作成支援業務終了の点検期間の満了をもって、業務の終了を確認したものとみなされる。 　

https://monolith-law.jp/corporate/system-development-contract-check-quasi-mandate

上記記載のように、業務終了報告書の提出義務についてしっかりと定めており、報告書の確認が遅れることの無いように点検期間まで明確に記してあります。また、業務終了は「業務終了確認書に記名押印の上、 乙に交付し、要件定義作成支援業務の終了」と定められており、ユーザーの記名と押印がなければ業務終了とはなりません。

また、最後は書面に対する異議がなかった場合のみなし終了確認について記されています。ここは非常に重要で、何かしらの理由から確認手続きを怠ってしまった場合、後の作業に遅れが発生してしまったり確認の有無をしないままに次の作業へ移ってしまったという場合に、双方の責任が曖昧になってしまうという事を避けるために記してあります。具体的な理由の提示と異議がない場合にのみ業務終了となり、仮に異議があるという場合は業務終了にはなりません。

契約書に記載するべき主な項目

次に、契約書に記載すべき重要な項目についてご紹介致します。何度も言うように、契約書は非常に重要な書類です。そのため、その内容はしっかりと作り込み双方にとって納得できるものにする必要があります。ここで紹介する項目は、契約書の作成があるにもかかわらず、特に問題が生じやすい項目となりますので、内容の把握、理解を深め、トラブルを未然に防げるよう正しい記載を行うようにして下さい。

開発・設計対象の範囲

開発や設計の対象となる範囲は明確にしておきましょう。仮にプロジェクトの開発途中で仕様変更などがあった際、発注側が契約書に記載されている範囲を超えているという認識をしてもらうことで、受注側は追加費用の正当な請求を行うための根拠になります。曖昧な表現での記載は極力避け、専門用語には説明を加えるなどの方法で明確に記しておくようにして下さい。双方で共通の認識が出来るよう、表現は客観的に行うといいでしょう。

損害賠償の期間や上限額

請負契約の場合、民法改正により瑕疵担保責任から契約不適合責任へと変化し、損害賠償期間の起算点が変わりました。最初は適切に稼働していたとしても、納品から数年たって普段使用しない機能などにバグが見つかるという事も少なくありません。そのため、受注側は長期にわたり損害賠償責任を負うという事になります。これは受注側には大きなリスクとなるでしょう。また、発注側も、損害賠償期間をハッキリとさせることで、システムに関する責任の所在を明確にさせることが出来ます。

契約不適合責任の起算点を「納品完了日」とするか「システム稼働日」とするかは、双方でしっかりと話し合い、お互いに納得した上で記載するようにして下さい。また、仮に契約不適合責任を追及された場合、その損害賠償金額においての上限額も決めておきましょう。一般的には、契約書に記載案件の報酬金額を上限とすることが多くあります。

協力義務

要件定義は、プロジェクトを成功へ導くために非常に大きな影響を及ぼします。業務の流れや課題をできる限り正確に把握する必要があり、業務内容を熟知している担当者の協力は必須と言えるでしょう。ですが、中には開発は丸投げすればいいと考えている企業も少なくありません。そのため、契約書の中で協力義務に関する記載をし、受注側は義務として課せられているという事を強く認識する必要があります。

著作権

特に大きなもめごとに発展してしまうのが著作権です。開発したシステムの著作権をめぐり、受注側と発注側がトラブルを起こしてしまうという事は珍しくはありません。そのため、契約書に著作権の帰属について明確に記載しておくようにしましょう。ここもまた、曖昧な表現で分かりにくいと後々になってトラブルになってしまいますので、著作権はどちらになるのかをハッキリ記載しておくようにして下さい。凡用的に活用できるものであれば受注側、その他に関しては発注側に帰属するなどバランスを見て決めるといいでしょう。

変更管理手続き

システム開発案件では、仕様変更などによる追加の作業というのは少なくありません。そのため、仕様変更によって工数が増加した場合などの手続きを明確に提示しておくと、大きなトラブルを回避することが出来ます。この際には、仕様変更により追加作業が発生した場合の費用負担などについても明記しておきましょう。金銭的な問題は、大きなトラブルを起こす要因になります。そのため、契約書に明記し事前に追加作業が発生した場合の対応について双方で認識を共有しておくことが重要です。

「経済産業省」が公表しているモデル契約書を参考に

実際に契約書を作成する場合、経済産業省が後悔している「情報システム・モデル取引・契約書」を参考にするといいでしょう。モデル契約書と呼ばれており、第一版は2007年に公開されました。これは大規模案件向けの内容でしたが、2018年には中小企業などの比較的小規模な案件を盛り込んだ追補版が公開され、さらに2019年には、民法改正に対応した最新のモデル契約書が公開されました。

実際の案件の内容を落とし込み、それに合わせた規定を盛り込むなどして作成を行うようにするといいでしょう。その際、今お伝えした特にトラブルとなる内容については、入念な話し合いやミーティングなどを行い、受注側と発注側のどちらかのみに有利になることの無いようにする必要があります。

契約の際に注意すべきポイント

契約を行う上で、特に注意すべきポイントを3つご紹介致します。契約書を作成して開発依頼を行ったとしても、何かしらのトラブルは起こってしまうでしょう。そういった場合、大きなトラブルに発展させないため、また、問題を早期解決させるためには契約の際に注意すべき大事な項目があります。契約書はこうしたイレギュラーな場面でその効力を大きく発揮します。もちろん、何のとあブルもなくスムーズな開発が行われることが一番の理想ではありますが、前もって回避するためにはどうすべきか、契約前に何を行うべきなのかをよく理解し、受注側、発注側双方が気持ちいい仕事が行えるようにしておきましょう。

契約書の内容について詳しく精査し把握する

システム開発におけるトラブルは、その多くが契約書の確認不足から起こります。そのため、再度しっかりと内容を精査し、項目それぞれをよく把握するようにして下さい。

• 実態に即した内容となっているか
• 自社のリスクは最低限となっているか
• 内容が合理的・公平になっているか

主となるのは上記3点です。それぞれを強く意識し、契約書の確認を行うようにして下さい。以下でその内容について詳しくお伝えいたします。

契約内容について双方が正しく理解しているか確認する

契約書を作成し開発がスタートしてから、実は契約書の内容を把握していなかったという事は珍しくありません。本記事でもお話しした通り、担当者の3人に1人は契約内容の把握が出来ていないという現状があります。もしも開発途中で何かしらのトラブルが起きた際、内容を把握できていなければ、「そんな話は聞いていない」「責任はこちら側は取らない」などという大きなトラブルになってしまうでしょう。

契約書の内容は、双方の責任者が同席した際に読み合わせを行い、不明点がないかしっかりチェックしておくようにしましょう。その際、何かしら疑問点などがあればその場で解決し、お互いの認識の違いをなくすようにして下さい。責任者は、契約書の内容をプロジェクトに携わる全員に内容を共有し、自社内でも情報のずれがないように徹底しておく必要があります。

会議内容は必ず記録する

トラブル回避のためには、ミーティングや打ち合わせなどの会議の記録を残しておくことが非常に大切です。システム開発案件の場合では、ベンダーはシステム開発のプロとして、発注側企業の意見を聞きながら開発作業を行う「プロジェクトマネジメント義務」というものがあります。会議の記録などは、このプロジェクトマネジメント義務を正しく果たしたという確固たる証拠になります。また、会議の記録はどこでどのような話が行われどう進んでいったのか、この意見はいつ出されたのかなどと言った進行具合もお後から確認することが出来ます。

そのため、「言った・言わない」論争が起こることなく、スムーズに開発までの道のりを進んでいけるようになるでしょう。こうした記録はミーティング後の数日以内に作成を行い、開発メンバーにメールなどで送り内容の相違がないかよく確認をしておくようにして下さい。この際、口頭で伝えるだけでは受け取り方に違いが出てしまったり、記憶違いで正しい確認が出来ないという事が起きてしまいますので、必ず書面にし、保存できるようにしておきましょう。

現在のシステム開発に多い契約形態とは？

現在のシステム開発の契約形態は、多くが「請負型」「混合型」となっています。そのため、システム開発を受注する企業は成果物責任に対するリスク管理が必要不可欠となっています。発注側も、こうした受注側が負うリスクに対する知識を深めておくようにしましょう。また、発注側は開発依頼の範囲や、追加作業における費用などについても良く理解しておく必要があります。

「契約書にはこう書いてあるからこれ以外の費用は払いません」となれば、追加の作業は行ってもらえなくなりますし、最悪の場合訴訟問題にまで発展してしまいます。本記事で紹介した注意点やポイントをよく理解し、大きなトラブルを未然に防ぎつつ、円滑なシステム開発が行えるようにしていきましょう。

まとめ

システム開発は契約1つで大きなトラブルを招いてしまう非常に難しい依頼となります。しかし、契約書を正しく正確に作成することが出来れば、問題も小さく収めることが出来、早期解決や双方の負担を最小限にとどめることが出来るでしょう。

• 契約書の役割の認識
• 契約形態の把握
• メリット・デメリットの理解
• 契約書に記載すべき重要な項目と注意点

上記内容に対する知識をよく深くし、受注側・発注側共に効率よく円滑なシステム開発を行っていきましょう。正しく綿密に精査された契約書であれば、双方の関係をよりよいものとするための役割も果たしてくれます。システム開発の契約書やその内容に対して疑問点や不安なことなどがあれば、曖昧なままにせずしっかりと1つ1つを解決しながら契約を進めていくようにしましょう。