はじめに
ベンダー選定を始めるとき、最初に交わす契約書がNDA（秘密保持契約）です。RFPを渡す前、現行システムの資料を見せる前に「とりあえずNDAを結んでおきましょう」という流れになることがほとんどです。
ところが、このNDAは「定型の書類」として扱われやすく、ベンダーから出てきたひな形にそのまま押印してしまうケースが少なくありません。私自身、SIer側にいたときもコンサルとして発注側を支援したときも、NDAの中身が議論になる場面はほとんど見かけませんでした。問題になるのは、何かが起きてからです。
IT契約書で発注側が確認すべき3つのポイントでは本契約の確認ポイントを整理しましたが、今回はその手前、NDAで発注側が確認しておくべきポイントを整理します。
NDAは「情報を渡す前」に効いてくる契約
NDAが他の契約と違うのは、本契約よりずっと前から効力を持つという点です。ベンダー選定の段階では、発注側は次のような情報をベンダーに開示します。
- 現行システムの構成図、設計書、データ項目一覧
- 業務フロー、業務上の課題、今後の事業計画
- 予算感、スケジュール、社内体制
これらは、選定に落ちたベンダーにも渡ります。つまりNDAは、「最終的に取引しない相手」との関係も規律する契約です。コンペに複数社が参加するなら、複数社に同じ情報が渡ることになります。だからこそ、ひな形に押印する前に、最低限の確認をしておく必要があります。
発注側が確認すべき5つのポイント
①秘密情報の定義が自社に不利になっていないか
NDAで最も重要なのが、「何を秘密情報とするか」の定義です。大きく分けると次の2つの型があります。
- 限定型：「秘密」と明示した書面・データ、または口頭で開示後に一定期間内に書面で秘密と特定したものだけを秘密情報とする
- 包括型：開示した情報は原則としてすべて秘密情報とする（例外は別途定める）
情報を出す側である発注側にとっては、包括型の方が守られる範囲が広くなります。限定型の場合、資料に「Confidential」の表示を付け忘れたり、打ち合わせで口頭説明しただけの内容を後から書面で特定しなかったりすると、その情報は保護の対象外になり得ます。
ベンダー側のひな形は、ベンダーにとって管理しやすい限定型になっていることがあります。限定型のまま進めるなら、資料には必ず秘密表示を入れる、口頭での説明は議事録に残して共有するといった運用ルールを自社側で徹底する必要があります。
②例外規定の範囲は妥当か
どのNDAにも、秘密情報から除外される「例外」が定められています。一般的には次のようなものです。
- 開示を受けた時点ですでに公知だった情報
- 開示後、受領者の責によらずに公知となった情報
- 開示を受ける前から受領者が保有していた情報
- 第三者から守秘義務を負わずに正当に入手した情報
- 秘密情報によらず独自に開発した情報
これ自体は標準的な内容ですが、「受領者が独自に開発した」の部分が広すぎると、提案のために見せた業務ノウハウが、後から「自社で独自に考えたもの」として使われても反論しにくくなります。例外に該当することの立証責任を受領者側に置く文言になっているかも確認しておきたいところです。
③目的外使用の禁止が明記されているか
NDAには「秘密を漏らさない」だけでなく、「定められた目的以外に使わない」という条項が必要です。目的の記載が「本件取引の検討のため」のように曖昧だと、何が目的外なのかの判断がつきません。
発注側としては、「〇〇システム刷新に関する提案書作成および提案内容の検討のため」というように、目的をできるだけ具体的に書くことをお勧めします。選定に落ちたベンダーが、自社の業務情報を他社向けの提案資料に流用するといった事態を防ぐための条項です。
④開示できる相手の範囲（再委託先・グループ会社）
ベンダーは、提案書の作成段階から協力会社やグループ会社の力を借りることがあります。ベンダーの多重下請け構造、発注側はどこまで把握すべきかで触れた通り、IT業界では分業が当たり前です。
そのため、NDAでは次の点を確認しておく必要があります。
- 秘密情報を開示できる相手は、受領者の役員・従業員に限られるのか
- 協力会社・グループ会社への開示を認めるか、認める場合は事前承諾が必要か
- 開示先にも受領者と同等の守秘義務を負わせ、その違反は受領者の責任とする定めがあるか
ここが空白のまま進むと、「誰が自社の情報を見ているのか」を発注側が把握できなくなります。オフショア拠点や海外のグループ会社が関わる可能性がある場合は、オフショア開発を使う際、発注側が気をつけるべきことも参照してください。
⑤返還・破棄と有効期間
選定が終わったあと、不採用となったベンダーの手元に自社の資料が残り続けるのは望ましくありません。NDAには次の2点を入れておきます。
- 返還・破棄：開示者の求めに応じて、秘密情報（複製物を含む）を返還または破棄し、必要に応じて破棄したことを書面で報告する
- 有効期間と存続期間：契約の有効期間と、契約終了後も守秘義務が続く期間（例：終了後〇年間）
「契約期間1年、自動更新なし」のNDAで、終了後の存続条項がないと、1年経過後に守秘義務が切れてしまう可能性があります。システム構成や業務ノウハウのように長く価値を持つ情報を出すなら、存続期間は短すぎないように設定すべきです。
個人情報を渡すなら、NDAだけでは足りない
選定段階では通常、本番データは渡しません。ただ、現行データの品質を見てもらうためにサンプルデータを提供するケースはあります。その中に顧客や従業員の個人情報が含まれるなら、NDAの守秘義務だけでは不十分です。
個人データの取扱いを外部に委託する場合、委託元である発注側には、委託先を監督する義務があります。データの持ち出し可否、保管場所、アクセスできる人の範囲、事故発生時の報告などを、NDAとは別の覚書や本契約の条項で取り決めておくのが基本です。そもそも、選定段階ではマスキングしたデータしか渡さないというルールにしておく方が安全です。セキュリティ要件の整理は基幹刷新プロジェクトにおけるセキュリティ要件の整理でも触れています。
実務でのNDAの進め方
最後に、NDAを形骸化させないための進め方を整理します。
- 自社のひな形を用意しておく：ベンダーのひな形を毎回レビューするより、自社に有利な（少なくとも公平な）ひな形を持っておく方が効率的です。法務部門と一度作っておけば、案件ごとの確認は差分だけで済みます
- 開示する情報を棚卸ししてから渡す：「NDAを結んだから何を渡してもよい」ではなく、選定に本当に必要な情報だけを渡します。RFPに添付する資料はRFP（提案依頼書）の作り方で触れた範囲を目安にします
- 誰に何を渡したかを記録する：開示した資料と日付、相手先を一覧で管理しておくと、返還・破棄の依頼や、万一の漏えい時の確認がスムーズです
- 選定終了時に破棄を依頼する：不採用ベンダーには、結果通知とあわせて資料の返還・破棄を依頼します
なお、NDA違反が起きた場合の損害賠償の扱いは、本契約の損害賠償条項とも関係する論点です。本契約での損害賠償の上限については、別の記事で改めて整理します。
まとめ
NDAは定型の書類と思われがちですが、発注側にとっては「選定に落ちたベンダーにも渡る情報」を守る唯一の契約です。秘密情報の定義、例外規定、目的外使用の禁止、開示できる相手の範囲、返還・破棄と存続期間の5点を確認し、個人情報を渡す場合はNDAとは別に取扱いを定めておくことが重要です。
ひな形に押印する前に一度立ち止まり、「自社が何を渡し、それがどこまで守られるのか」を確認する。その手間が、後から取り返しのつかない情報の流出を防ぎます。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント