- システム開発契約の注意点：発注・外注でトラブルを防ぐ完全ガイド
- NDAと知的財産権の扱い｜見落としがちな契約項目を整理
- 保守契約・費用・トラブル対策の実務ガイド｜契約でプロジェクトを守る方法とは？
開発パートナーに機密情報を共有する以上、**秘密保持契約（NDA）**の締結は不可欠です。
さらに、完成したシステムの著作権やソースコードの権利が誰に帰属するのか、納品物に何が含まれるかなど、契約書で明記すべき重要事項が数多くあります。
本記事では、NDA・著作権・ライセンス・再利用制限といったテーマを実務ベースでわかりやすく解説します。
Contents
秘密保持契約（NDA）の重要性
システム開発を依頼する際には、プロジェクト遂行のために様々な機密情報を開発会社と共有することになります。ビジネスのアイデアや業務フロー、顧客データなど、外部に漏れては困る情報も含まれるでしょう。そこで重要になるのが**秘密保持契約（NDA: Non-Disclosure Agreement）**です。
NDAを結ぶことで、提供した機密情報が外部に漏洩したり不正に利用されたりするのを防ぐことができます。特に、新規事業のアイデアや独自技術を使ったシステム開発では情報漏洩は致命的になりかねませんので、NDAは欠かせない契約と言えます。
具体的には、NDAを締結しておけば開発会社が知り得た情報を他のクライアントに流用したり第三者に漏らしたりすることを禁止できます。また、「どの情報をどこまで共有してよいか」「プロジェクト以外の目的に使ってはいけない」といったルールを明確化する効果もあります。必要な範囲内でのみ情報を共有するなど、情報管理の範囲をはっきりさせられるのです。
さらに、NDAの効力は契約期間中だけでなく契約終了後にも続くのが一般的です。「プロジェクトが終わったら秘密を話していい」ということにならないよう、契約終了後○年間は秘密保持義務を継続するといった条項を入れることが多いです。業界によっては、NDAをしっかり結んでおくことが自社の競争優位性を守るうえでも非常に重要になります。
NDAに含めるべき条項
NDA（秘密保持契約）を締結する際には、以下のような条項を盛り込んでおくと安心です。
- 開示範囲：どの情報を「機密情報」として扱うかを明確に定めます。例えば「本プロジェクトに関する仕様書・設計書」「顧客データベース情報」「業務プロセスの詳細」など具体的に列挙するとよいでしょう。加えて、開発会社の社内でその情報をどこまで共有可能か（プロジェクト担当メンバーのみ共有可、社内全社員に共有可など）も決めておくと安心です。
- 保持期間：秘密保持義務を負う期間も重要です。一般的には「契約期間中および契約終了後○年間有効」とするケースが多いです。プロジェクト終了後も情報漏洩のリスクは残るため、少なくとも契約終了後2～5年程度は保持期間を設定しておくのが無難でしょう。場合によっては「期間を定めず永久に保持する」とすることも可能ですが、あまりに厳しい条件だと開発会社が契約に応じにくい場合もあります。お互い納得できる期間を設定しましょう。
- 違反時の対応：万が一、開発会社がNDAに違反して機密情報を漏洩した場合のペナルティも明記しておきます。例えば「違反した場合は損害賠償を請求できる」「一律で○○円の違約金を支払う義務が発生する」など、具体的な罰則を決めておくと万一のトラブル時にもスムーズに対応できます。また、意図しない情報漏洩（社員のミスなど）が起きた場合の対応策についても触れておくと、より万全なリスク管理が可能です。
NDA締結時の注意点
NDAを締結する際には、以下のポイントにも注意しましょう。
- 双方の義務を明確に：秘密保持契約というと「情報を守るのは開発会社側の義務でしょ？」と思いがちですが、実際には発注者側にも義務が発生します。契約書で「開発会社側は知り得た機密情報を契約目的以外に使用しない」「関係者以外には一切開示しない」といった義務を課す一方で、発注者側も「機密情報の管理を適切に行う」「必要以上の情報は提供しない」などの責任を負うのが一般的です。契約内容を確認し、どちらか一方だけに過度な負担がかからないようバランスを取ることが大切です。
- 情報共有の範囲の確認：NDAを結ぶ際には、「開発会社内で情報をどこまで共有してよいか」も確認しておきましょう。例えば「開発プロジェクトのメンバーに限定する」「開発会社内の関連チームにも共有可能」など、社内での情報取扱いルールを決めておくと不要な漏洩リスクを防げます。また、外部の協力会社やフリーランスエンジニアが開発に関わる場合、その人たちにもNDAの義務を適用するのかも重要です。開発会社が外部の人材を使う場合には、彼らにも同等の秘密保持義務を負わせる取り決めをしておきましょう。
責任範囲とリスク管理
システム開発の契約では、お互いの責任範囲を明確にし、リスクに備える取り決めをしておくことが重要です。特に「開発中や納品後に起こり得る変更や不具合への対処」について契約段階で決めておくと、いざというときに慌てずに済みます。
開発範囲の明確化と仕様変更への対応
システム開発では、最初に決めた仕様がプロジェクト途中で変わることは珍しくありません。「この機能を追加したい」「やっぱり別の方法で実装したい」などの要望が出てくることも多いでしょう。こうした仕様変更や追加開発が発生した際にトラブルにならないよう、契約時に対応ルールを決めておくことが大切です。
例えば、「仕様変更が発生した場合は改めて見積もりを提出し、発注者の承認を得てから対応する」というフローを契約書に明記しておく方法があります。これなら、開発会社が勝手に作業を進めて後から追加請求してくるのを防げますし、発注者側も費用のコントロールがしやすくなります。また、「軽微な変更と大幅な変更の線引きをあらかじめ決めておく」こともポイントです。どこまでが契約内の修正対応で、どこからが追加費用を伴う変更なのかを両者で合意しておくことで、「この変更は契約内？それとも別料金？」と揉めずに済みます。
同様に、追加開発についても「どの段階で相談するのか」「どの範囲なら既存契約内で対応可能か」を取り決めておくと安心です。プロジェクト後半で「これって最初の契約に含まれてる？」といった認識違いが起こらないように、事前のルール作りをしっかり行いましょう。契約前の打ち合わせ段階で想定シナリオを話し合い、納得したうえで契約に盛り込むことが重要です。
瑕疵担保責任と免責事項（バグ発生時の対応）
システム開発では、納品後に思わぬバグ（不具合）が発生することもあります。そこで押さえておきたいのが**「瑕疵担保責任（かしたんぽせきにん）」という考え方です。簡単に言うと「納品したシステムに欠陥（瑕疵）があった場合に、開発会社がどこまで責任を負うか」を定めるものです。契約段階でバグ対応の範囲や期間**を決めておけば、納品後に不具合が見つかったときのトラブルを防ぎやすくなります。
例えば、契約書に「納品後○カ月以内に発見された不具合は無償で修正対応する」といった条項を盛り込むケースが一般的です。ただし、全ての不具合が無償対応になるわけではありません。仕様変更による問題や発注者側の誤操作による不具合など、原因によっては開発会社が対応しない（有償対応になる）こともあります。どこまでが開発会社の責任で、どこからが別料金対応になるのか、契約時に明確にしておくことが重要です。
併せて確認しておきたいのが**「免責事項」**です。これは「開発会社が責任を負わない事項」を定める条項です。よくある例としては「外部サービスの障害が原因でシステムにトラブルが生じた場合は保証しない」「納品後に第三者がシステムを改変して生じた問題は責任を負わない」などがあります。後から「バグなのに修正してもらえない！」と発注者が不満に思うことがないよう、契約時にどの範囲まで開発会社が対応してくれるのかをしっかりチェックし、双方納得の上で契約に盛り込んでおきましょう。
損害賠償と契約解除の条件
万が一プロジェクトがうまくいかなかった場合に備え、「損害賠償」と「契約解除」の条件を契約でしっかり決めておくことも大切です。これは最悪のケースを想定した取り決めですが、事前に決めておくことでリスクに備えることができます。
例えば、開発が大幅に遅延したり、納品されたシステムが契約時の要件を満たしていなかったりした場合、発注者側に業務上の損害が発生することも考えられます。そうした場合にどの程度まで開発会社が責任を負うのか、契約時に明確にしておく必要があります。
損害賠償については、一般的に上限額を設けることが多いです。例えば「開発費用の範囲内で損害を賠償する」「契約金額の○％を上限とする」といった具合に、開発会社が負う賠償額に上限を設定します。こうすることで、万一の際にも開発会社の負担が無制限に膨らまないようにできます。また逆に、発注者側が契約違反をした場合にも違約金や賠償責任が発生するケースがありますので、そちらも注意深く確認しましょう。
契約解除の条件も重要です。例えば「開発の進捗が著しく遅れ、目処が立たない場合」や「○ヶ月間まったく報告がない場合は契約を解除できる」など、契約を途中で打ち切れる条件を設定しておくと、不測の事態に対処しやすくなります。契約解除時の費用負担（すでに作業済みの分の費用精算をどうするか等）についても決めておくと安心です。事前に契約終了のルールを作っておけば、お互いフェアな形で契約を終わらせることができます。
支払い条件とコスト管理
システム開発では大きな金額が動くため、支払い条件を明確にし、コストを適切に管理することが重要です。契約段階で支払いスケジュールや追加費用発生時のルールを決めておき、後から「聞いていない出費が…」とならないようにしましょう。
支払いスケジュールの設定（着手金・中間金・検収後の支払い）
開発プロジェクトの規模や期間によっては、一度に全額を支払うのではなく段階的に支払う方がお互い安心です。一般的な支払いスケジュールは次のとおりです。
- 着手金：契約が成立した段階で支払う前払い金です。プロジェクト開始の保証のようなもので、開発会社が安心して作業に取りかかれるよう契約金額の一部（目安として30%～50%程度）を支払います。発注者にとっては先に支払うリスクがありますが、その分開発会社も本格的に人員をアサインして作業を開始してくれるメリットがあります。
- 中間支払い：開発期間が長期に及ぶ場合、途中の節目で中間金を支払うことがあります。例えば「基本設計完了時点で○%支払い」「開発完了時にさらに○%支払い」といった具合です。長期プロジェクトでは複数回の支払いを設定することで、開発会社側のキャッシュフローを安定させつつ、発注者側も進捗に応じて適切に支払いができるメリットがあります。プロジェクトの規模に応じて支払い回数やタイミングを調整しましょう。
- 成果物検収後の支払い：システムが完成し、発注者側で検収（動作確認）を行った後に最終的な支払いを行います。一般的には最終納品後に残金を支払う形になり、例えば契約金額の20%～30%を最後に支払うことが多いです。ただし、ここでポイントとなるのが検収期間を設けることです。「納品物を受け取って○週間以内に不具合がないか確認する」というルールを作り、問題がないことを確認してから最終支払いを行うようにすると安全です。納品物をしっかりチェックし、必要なら修正対応をしてもらった上で支払うことで、「お金を払った後に重大なバグに気付いた…」といったトラブルを防ぐことができます。
追加費用が発生する場合の対応
システム開発では、プロジェクト進行中に「やっぱりこの機能を追加したい」「ここを変更したい」といった要望が出ることがよくあります。しかし、こうした仕様変更や追加開発には当然コストが発生します。契約時にこれへの対応ルールを決めておかないと、後で費用面のトラブルに発展しかねません。
一般的な取り決め方法として、「仕様変更が発生した場合は改めて見積もりを行い、発注者の承認を得てから対応する」と契約書に盛り込んでおく方法があります。これにより、開発会社が発注者に無断で作業を進めて勝手に追加請求してくる事態を防げますし、発注者側も都度見積もりを確認して予算オーバーを防ぐことができます。要するに、「勝手に進めない・お互い合意の上で進める」というルールを明文化しておくわけです。
また、「軽微な修正」と「大幅な仕様変更」の基準を決めておくことも大切です。例えば「軽微な修正（例：画面レイアウトの微調整や文言変更）は無償対応」「大きな仕様変更（例：新機能の追加や設計変更）は追加費用を請求」といったように、どこまでが無料で、どこからが有料対応かを契約書に明記しておきます。これによって、開発中に「この変更は無料対応？追加費用かかる？」と揉めずに済みます。事前に線引きをしておくことで、**「言った・言わない」「聞いてない追加料金だ」**というトラブルを防げるのです。
見積もりのチェックポイント（不明瞭な費用を防ぐ）
契約前に提示される見積もりの段階で、費用面の不明点はしっかり確認しておきましょう。見積もりを見る際は、単に総額を見るだけでなく内訳が明確かをチェックすることが重要です。金額の根拠が曖昧なままだと、後になって「思ったより高額になった」「追加費用を請求された」といったトラブルにつながりかねません。
まず、「作業項目ごとの費用が明確になっているか」を確認します。例えば見積もり項目が「開発一式：○○万円」といった大まかな書き方ではなく、「要件定義：○○万円」「基本設計：○○万円」「プログラミング：○○万円」「テスト：○○万円」「保守準備：○○万円」のように、工程ごと・作業内容ごとに費用が細分化されているかを見るのです。こうすることで、どの工程にどれくらいコストがかかっているのかが分かり、見積もり額の妥当性を判断しやすくなります。また、どの部分にお金がかかっているか把握できれば、予算調整の検討もしやすくなります。
次に、「追加費用が発生する条件が明記されているか」も重要なポイントです。例えば「仕様変更が発生した場合は別途見積もり」「軽微な修正は○回までは無料」といったルールが見積もりや提案書に書かれていれば、後々「それは別料金です」と急に言われるリスクを減らせます。逆にそういった記載がない場合は、契約前に開発会社に確認しましょう。「この要件は見積もりに含まれていますか？」「どんな場合に追加費用が発生しますか？」といった質問をして、不明確な部分をクリアにしてから契約することが大切です。
知的財産権の取り扱い
システム開発の契約で見落としがちなのが、完成したシステムの知的財産権（著作権など）をどう扱うかという点です。お金を払って開発してもらったからといって、自動的にそのシステムの権利が自分のものになるとは限りません。以下のポイントについて契約時にしっかり確認しておきましょう。
著作権と利用権の違い（システムの権利は誰のもの？）
著作権とは、システムのソースコードやプログラムといった創作物に関する権利のことです。基本的には実際に開発を行った側（開発会社やエンジニア）に帰属するのが一般的です。一方で利用権とは、そのシステムを使用する権利のことで、発注者が契約に基づいてシステムを利用できる権利を指します。
つまり、システム開発を発注してお金を支払っても、システムの著作権が発注者側に移転されるとは限らないということです。著作権が開発会社に残っている場合、発注者はそのシステムを自由に改変・再販することができませんし、場合によっては追加のライセンス費用が発生することもあります。特に、自社でシステムを運用したり今後改修したりする予定がある場合は、契約時に著作権の帰属先をはっきりさせておくことが重要です。
契約を交わす際には、「システムの著作権を発注者に譲渡するのか、それとも開発会社が保持したまま発注者に利用権を与えるのか」を明確に決めましょう。著作権の譲渡には別途費用がかかるケースもありますので、事前に確認したうえで、自社のビジネスモデルに合った形で契約を結ぶことが大切です。
ソースコードの権利と納品物
システム開発を依頼する際は、ソースコードを受け取れるかどうかもしっかり確認しましょう。一般に、開発会社がシステムを開発して納品する場合、完成したプログラム（実行ファイルや利用できる形のシステム）は渡されても、ソースコード自体は納品物に含まれないケースがあります。極端に言えば、「発注者はシステムを利用することはできるが、中身のコードを自由に変更できない」という状態になり得るのです。
自社でシステムを保守・改修したい場合や、将来的に別の開発会社に引き継ぎたい場合は、契約時に**「納品物の範囲」にソースコードを含める**よう取り決めておくことが重要です。例えば「システム一式（プログラム実行ファイル等）に加えて、ソースコード一式と関連ドキュメントも納品するものとする」と契約書に記載してもらうと安心です。また、ソースコードを納品してもらう場合は、開発環境の設定情報やシステム構築手順書なども一緒に提供してもらえば、後々自社でメンテナンスするときにスムーズでしょう。
加えて、ソースコードに関する権利も確認しておく必要があります。先ほど触れたように、ソースコードの著作権が開発会社にある場合、発注者はそのコードを勝手に改変・再利用できない可能性があります。ソースコードの著作権も発注者に譲渡してもらうのか、開発会社に残したまま使用権だけもらうのか、将来困らないよう事前にルールを決めておきましょう。
開発物の再利用・ライセンスの取り決め
もう一点、開発してもらったシステムやコードの再利用についても確認が必要です。開発会社によっては、一から新規にコードを書くのではなく、自社で持っている既存テンプレートや共通モジュールを活用して効率的に開発することがあります。そのため、納品されたシステムのどこまでが発注者オリジナルで、どこからが開発会社の一般的な技術なのかを明確にしておく必要があります。
特に、自社専用のシステムを開発する場合、同じものを他社に使い回されると困ることがあります。競合に同じシステムや機能を提供されてしまうと、競争上の優位性が薄れる可能性があるからです。そのため、契約書に**「納品物は発注者専用のものとし、開発会社が第三者に提供・転用することを禁止する」**と明記するケースもあります。これにより、少なくとも納品されたシステム一式がそのまま他社に再利用されないよう担保できます。
ただし、開発会社側にも事情があります。開発会社がもともと持っている独自の技術やライブラリを使って開発するケースでは、発注者側がその技術自体を独占するのは難しいこともあります。契約時には「どこまでが発注者に納品・譲渡される部分で、どこからが開発会社の汎用技術なのか」を双方で認識合わせし、お互い納得できる形で再利用やライセンスに関する取り決めを行うことが大切です。例えば「開発会社の既存ライブラリ部分については他プロジェクトで再利用可だが、カスタマイズ部分は再利用不可」など具体的に決めておくとよいでしょう。
知財やNDAの取り扱いを整理したら、最後は保守契約・費用・トラブル対策を理解しておきましょう。
第3部では、契約後の運用にまつわる費用・SLA・追加費用の考え方や、トラブルを未然に防ぐ実務的な契約のコツを解説します。
コメント