相見積もりを取ろうと、3社の開発会社に声をかけた。それぞれの担当者に、既存システムの構成、顧客リストのサンプル、社内の業務フローを説明した資料を送った。より正確な見積もりをもらうためには、実態を隠さず見せるのが一番だと思っていたからだ。
数日後、ふと不安がよぎった。あの資料には取引先の名前や、独自に組み上げた業務フローの詳細まで書いてあった。もし発注しなかった2社が、あの情報をどこかで使い回したら。あるいは、担当者が転職先で似たような提案をしたら。そう考えて初めて、秘密保持契約(NDA)を一度も結んでいなかったことに気づいた。
この感覚は、多くの経営者や発注担当者が一度は通る道だ。自社の情報を守りたいという当たり前の気持ちと、良い提案をもらうために情報を開示しなければならないという現実の間で、判断が後手に回ってしまう。壁を越えて新しいシステムを作ろうとする人たちは、技術的な壁だけでなく、こうした情報管理の壁とも向き合わなければならない。この記事では、NDAとは何か、いつ結ぶべきか、何を確認すべきかを、非エンジニアの発注担当者にも分かるように整理する。
NDA(秘密保持契約)とは何か
NDAとは、Non-Disclosure Agreementの略で、日本語では秘密保持契約や機密保持契約と呼ばれる。取引の過程で開示する情報を、契約相手が第三者に漏らさない、契約の目的以外に使わないと約束する契約書のことだ。英語表記のまま「NDA」と呼ばれることが多いが、中身は日本の民法や商慣習に沿った、ごく一般的な契約の一種にすぎない。
システム開発の発注では、次のような情報が開示の対象になる。
- 顧客リストや取引先データベースの構造
- 既存の業務フロー、社内の承認ルール、稟議の流れ
- これまでのシステムのソースコードや設計資料
- 売上データ、原価構造などの経営数値
- 新規事業の企画書や特許出願前のアイデア
システム開発では、要件定義の段階で業務の中身をかなり具体的に開発会社へ説明する必要がある。どの部署がどんな承認フローで動いているか、どのデータをどう扱っているか。これは会社の内部構造そのものであり、競合他社に渡れば経営上の不利益につながりかねない。だからこそ、開発を依頼する前提として、情報の取り扱いルールを契約で明文化しておく必要がある。
NDAは、開発会社を疑うための契約ではない。むしろ逆だ。お互いに何を守るべきかを最初に言葉にしておくことで、担当者同士が安心して率直に情報を出し合えるようになる。壁を越えるための土台を先に作る作業だと考えるとよい。
NDAを結ぶべきタイミング
冒頭の例のように、見積もり依頼の時点で相応の情報を渡してしまうケースは少なくない。NDAを締結すべきタイミングは、原則として次の通りだ。
見積もり依頼・相見積もりの前
複数社に声をかけて比較検討する段階では、まだ発注先が決まっていない。つまり、情報を渡した相手のうち何社かとは、最終的に取引をしないことになる。取引をしない相手にこそ、情報の扱いを縛る契約が必要だ。見積もりの精度を上げるために業務フローの詳細を見せるなら、その前にNDAへの署名を求めるのが筋である。
要件定義の前
発注先が1社に絞られた後、本格的な要件定義に入る前も重要な節目だ。見積もり段階よりもさらに深い情報、たとえば既存システムのソースコードやデータベースの中身、社内の未公開の意思決定プロセスなどを共有することになる。基本契約とは別にNDAを単独で締結しているケースでも、この段階で対象範囲を再確認しておきたい。
契約書のどこに位置づくか
NDAは、独立した契約書として結ぶ場合と、業務委託契約書の一条項として盛り込む場合の両方がある。独立したNDAを先に結び、その後に開発の請負契約や準委任契約を別途締結する進め方が一般的だ。取引の初期段階から情報開示が始まるなら、本契約を待たずにNDA単体を先行させる。
NDAに記載すべき基本項目
提示されたNDAの雛形をそのまま受け入れる前に、次の4つの観点で中身を確認したい。これは法律相談ではなく、契約実務として一般的に確認されているポイントの整理である。
秘密情報の範囲
何が秘密情報にあたるのかが曖昧なままだと、後で「それは秘密情報ではなかった」と主張されるリスクがある。確認すべき点は次の通りだ。
- 口頭で伝えた情報も対象に含まれるか(書面のみが対象だと、打ち合わせ中の会話が抜け落ちる)
- 「秘密」である旨を明示したものだけが対象か、業務上明らかに秘密と分かるものも含むか
- 公知の情報や、相手が既に保有していた情報など、除外される例外規定は何か
特に注意したいのは、書面で「秘密」と明記したものだけを対象にする条項だ。実際の商談では口頭やチャットでのやり取りが大半を占める。すべてのやり取りに「秘密」のスタンプを押すのは現実的ではないため、口頭情報も一定期間内に書面で確認すれば対象に含める、といった柔軟な規定になっているかを見ておく。
利用目的の制限
開示した情報を、何のために使ってよいかを限定する条項だ。「本契約に基づく検討及び業務遂行の目的にのみ使用する」といった一文があるかを確認する。この一文がないと、極端な話、開発会社が自社の営業資料に事例として無断で使う、といった事態を止める根拠が弱くなる。
有効期間
NDAには、契約自体の有効期間と、秘密保持義務そのものの存続期間の2種類がある。契約期間が終了しても、それまでに開示された情報の秘密保持義務は一定期間(1年、3年、あるいは無期限など)続く、という設計が一般的だ。この存続期間が明記されているかを必ず確認する。期間の定めがない、あるいは極端に短い場合は、取引終了後の情報漏洩リスクに無防備になる。
返却・破棄義務
取引が終了した際、あるいは契約が解除された際に、開示した資料やデータをどう扱うかを定める条項だ。原本の返却だけでなく、相手がローカルに保存したコピー、バックアップ、印刷物まで含めて破棄する義務があるか。破棄した証明として報告書の提出を求められるかも、確認しておきたいポイントである。
発注者側が見落としがちなポイント
基本項目を確認しただけで安心してしまうと、実務上の抜け穴を見過ごすことがある。特に発注側が見落としやすい2点を挙げる。
再委託先への情報共有
システム開発では、開発会社がすべての工程を自社だけで完結させるとは限らない。デザイン、インフラ構築、一部の機能開発などを別のパートナー企業や個人のエンジニアに再委託することは珍しくない。ここで問題になるのが、自社が渡した情報が、契約相手だけでなく、その先の再委託先にも共有されるという点だ。
NDAに再委託についての規定がない場合、契約相手は法的にはNDAの当事者に対してのみ義務を負う。再委託先が同等の秘密保持義務を負っているかどうかは、別問題になってしまう。確認すべきは次の点だ。
- 再委託する場合は事前に発注者へ通知、または承諾を得る義務があるか
- 再委託先にも、元のNDAと同等の秘密保持義務を課すことが契約上定められているか
- 再委託先が義務違反を起こした場合、元の契約相手が責任を負う旨が明記されているか
この確認を怠ると、自社の情報が想定していなかった第三者の手に渡っていた、という事態が起こり得る。発注前の打ち合わせで、開発体制に外部パートナーが関わる予定があるかを率直に聞いておくとよい。
契約終了後のデータ削除
プロジェクトが完了し、システムが無事に稼働を始めると、NDAへの関心は薄れがちだ。しかし、開発期間中に開発会社のサーバーやクラウド環境、担当者のパソコンには、テストデータとして使われた実際の顧客情報や業務データが残っている可能性がある。
返却・破棄義務の条項があっても、それが自動的に実行されるとは限らない。発注側から明確に削除を依頼し、可能であれば削除完了の報告を書面やメールで受け取っておくことをお勧めする。特に、開発中に本番同等のデータを使ってテストを行っていた場合は要注意だ。個人情報を含むデータであれば、削除の徹底はコンプライアンス上も避けて通れない。
よくある失敗パターン
実際の現場でつまずきやすいパターンを整理しておく。
相見積もり段階での情報過多
冒頭の例のように、まだ発注先が決まっていない段階で、詳細な資料を渡してしまうケース。見積もりの精度を上げたい気持ちは理解できるが、必要最小限の情報で見積もりを取り、詳細な情報はNDA締結後の絞り込んだ1、2社にのみ開示する、という順序を守るほうが安全だ。
雛形をそのまま使い、内容を確認しない
開発会社側が用意したNDAの雛形をよく読まずに署名してしまうケース。雛形は一般的な内容でまとまっていることが多いが、有効期間が極端に短い、返却・破棄義務が曖昧、再委託についての規定がない、といった抜けがあることは珍しくない。自社が渡す情報の重要度に応じて、修正を依頼する交渉の余地は十分にある。
NDAを結んだことで安心しきってしまう
NDAに署名さえすれば情報は守られると考え、その後の情報開示の範囲を無防備に広げてしまうケース。NDAはあくまで契約上の抑止力であり、万能の防御壁ではない。本当に機密性の高い情報は、契約の有無にかかわらず、開示する範囲とタイミングを慎重に見極める姿勢が欠かせない。
担当者レベルの口約束で済ませる
「信頼できる担当者だから」という理由で、書面でのNDA締結を省略してしまうケース。担当者個人がどれだけ誠実でも、その担当者が異動や退職をすれば、情報管理の責任の所在が曖昧になる。会社対会社の契約として、必ず書面で残すことが、双方の信頼関係を長く保つための土台になる。
まとめ
NDAは、システム開発という壁を越えるプロジェクトの、最初の一歩を支える契約だ。自社の大切な情報を外部に預けるという不安は、経営者であれば誰もが抱くものだが、その不安は無視すべきものではなく、契約という形で具体的に手当てできるものでもある。
見積もり依頼の前、要件定義の前という節目でNDAを締結すること。秘密情報の範囲、利用目的の制限、有効期間、返却・破棄義務という基本項目を自分の目で確認すること。そして、再委託先への共有や契約終了後のデータ削除といった、見落としやすい実務のディテールまで踏み込んで確認すること。この一連の準備があってはじめて、開発会社と対等な立場で率直な情報交換ができるようになる。
新しいシステムを作ることは、自社の業務を見直し、次のステージへ進むための挑戦だ。その挑戦を支える契約実務を丁寧に整えることは、決して後ろ向きな作業ではない。むしろ、安心して挑戦を進めるための、前向きな準備そのものだと言える。
なお、この記事で紹介した内容は一般的な契約実務の知識であり、個別の契約書の法的な妥当性を判断するものではない。実際の契約内容に不安がある場合は、弁護士など専門家への相談も検討してほしい。