日比谷の街角 弁護士 稲垣隆一 稲垣隆一法律事務所

稲垣隆一法律事務所 〒100-0006 東京都千代田区有楽町一丁目7番1号有楽町電気ビル南館9階956区 電話:03-6273-4351

システム開発紛争

秘密保持契約のコツと文例

秘密保持契約の勘所は限られている。

第1のコツは「秘密情報」は特定できているか。だ。

昔も今もよくあるのは

甲が委託元,乙が委託先で
「甲乙は,本件委託業務にあたり相手方から開示された全ての情報を秘密として取り扱う」
というパターン。

当事者は,「今回のことで知ったことは全て秘密にしてね」という程度なのだろう。
こんな程度なら,考えるまでもなく,この守秘契約は無効であることは明かだ。

なぜか。

できもしないことを,そうと知りつつ合意していることが明かだからだ。やる気がないことを双方が熟知して文言だけ体裁をととのえても無効というのが,「心裡留保」や「通謀虚偽表示」だ。
こんな難しい概念をつかわなくたって,要するに,守秘する意思がないわけだから,守秘すると契約書に書いても効力を生じない。「法律効果の根拠は行為者の意思だ」というのが近代法の根幹だ。

情報漏洩が起きたときに,この契約条項をもとに賠償請求しても,上のような反論を受けるだろう。

ではどうするか・・・

私がよく使う定義条項のイメージはこのようなもの。

「秘密情報とは,媒体又は文書に,秘密として取り扱うことを明示して開示,委
託され若しくは提供された情報をいう。開示等の後に,同方法により秘密として
取り扱うことを明示されたときは,その時から秘密情報とする。」

要するに,守秘の対象を特定して管理できるようにしたものだ。

この定義は,情報セキュリティ対策の基本である ISO:27002の項番の8.1  特に,8.1.2 b)c) 8.2.1のa)~c)のレベル付(情報格付),8.2.2などを背景にしている。

やりとりする情報に必ず情報格付けが書かれているという環境を前提にすれば,この条文をもとに,守秘条項を作ることができる。

実際に,秘密格付けをしている甲乙の間の契約では,上の「秘密として取り扱うことを明示して」を例えば「秘密レベル3以上であることを明示して」とすれば良い。

第2のコツは,秘密情報を管理する方法の特定だ。

これもできもしないことを契約書に書いても,法は不能を強いない。当事者に効果意思なし,を理由に無効となる。

特定の契約のために,新たにセキュリティ枠組みを構築したり,対策を講じるという事例なら,それを契約してそのコストを報酬に乗せれば良いのだけれど,そうでなければ,今やっているセキュリティ対策に乗せて管理するだけだろう。

ではどうするか・・・・・

私がお勧めするのは

「乙は,甲から,開示された秘密情報を,本契約時に,乙が現に行い,又は,その後改善されたセキュリティポリシーにより管理する。」

という真っ正直なもの。

よく考えると,契約の前に,セキュリティリスクのコミュニケーションを図るだろう。今は,特に,サプライチェーンのセキュリティ対策がうるさく言われていて,セキュリティリスクはそこまで広げてアセスメントするだろう。

だから,こういう内容が最もよいだろう。

「セキュリティポリシー」「情報管理の方法」など事案にあわせて規定する。

第3のコツは・・「秘密」か「機密」か。

どちらにすべきかの基準はない。

けれど,e- Govで,検索をしてみると,機密というのは,どうやら組織の秘密や権限を捉える用語例が多いように思う。

例えば,不正競争防止法も営業「秘密」という規定ぶりで,営業「機密」ではない。
自社に不正競争防止法との関係で,営業「秘密」を定義したり,「秘密」情報目録があるようなときは,その目録と守秘契約を連動させることも容易になる。

というわけで,私は,「秘密」保持契約,「秘密」情報とするのが良いと思う。

第4のコツは,「秘密情報の返却の合意」だ。

情報は利用目的を達したら,用を終えたら廃棄する。無用な情報は持たないというセキュリティ対策というか情報管理の大原則だ。

だから,委託契約を終えたら,当事者は関係を失い,情報もやりとりの目的を達成し,あるいは,失い,用済みとなるので,返還・廃棄せよ,とか,複製を含めて保持するなという条項を定めることが多いし,実は,セキュリティ対策としても当然のように言われることだ。改正個人情報保護法19条も消去の努力義務が定められ,個人情報保護委員会も特にその旨をガイドしている。
https://www.ppc.go.jp/news/careful_information/data_syokyo/

しかし,法務は安易に同意して良いのか?

「利用目的」に紛議に備えるという利用目的はないのか?わかりやすい例でいうと,委任契約がおわっても,例えば債務不履行の紛議があるとき,予測されるときは,債務者は履行の状況を立証する必要がある。とすれば,履行状況を示す秘密情報を安易に廃棄したり返還すれば,立証方法を失うことになる。こうした場合は,紛議処理の限度で法律関係はまだ続いているわけで,契約は期限がきたとしても,終了したとはいえない。

以前,システム開発紛争で追加料金を請求する訴訟で,ベンダ側の代理人をしたことがある。契約は解除されていた。契約書の守秘条項には,「契約が終了したときには全ての情報・データ,複製を返却し保持しない」という条項が定められていた。

でもベンダは,全ての仕事のプロセスと成果物のファイルをもっていた。だからこそ,訴状も書けたし,証拠も提出できた。

第一回期日で,ユーザーの訴訟代理人が元気いっぱいに主張した。「本件訴訟はただちに却下されるべきだ。守秘契約にもとづき,ベンダは主張や証拠として提出している情報の保持を禁じられている。守秘契約に反して提起された本訴は却下(門前払い)すべきだ」と。

中年の裁判官は,ニコニコしながら,無視して手続を進めた。

訴権を放棄するような効果を守秘条項に込めるならそれなりの合意をすべきだろう。

こうした煩わしさから開放されたいと考えるなら,こんな但書も良いだろう。
当然のことの確認的な但書だが,余計な争点を作らずにすむだろう。

「・・・返還し保持しない。但し,甲乙間に紛議が存在し,又は紛議のおそれがあるときはこの限りでない。」









瑕疵担保の契約条項

瑕疵担保の期間をどう定めるかは一つの問題だ。

民法637条は、請負契約の瑕疵担保の期間を1年と定めている(637条)。
この期間は除斥期間と考えられており、時効期間のように中断がないから、請求やベンダーが承認したからといって、伸びることはない。

そこで大切になるのは、この期間の始期をどう定めるかだ。


「引渡」を「納品」とする例は多い。納入した成果物が、検収に通って、納品となるから、検収を受けた時からということにする例だ。ヴァリエーションとしては、検収書の交付を受けてからというものもある。

しかし、実務では、まず、ユーザー検収拒否を想定した場合、これでいいのか?ということになる。ベンダは検収拒否に合うと、ずっと完成義務や瑕疵担保責任に付き合わされる。要員は確保しておけないから、極めて困難な状況を生じる。逆に、ユーザーは、完成義務や瑕疵担保を長期に主張できることになり、安心しがちだが、ベンダーから、契約で定めた期間は検収拒否の場合まで想定したものではないと主張されることにもなる。

逆に、検収書は出されたが、その検収書が、適切な検収を経ずに、形式的に出されたような場合、ユーザー側は、やっと完成して引渡を受けたが障害が生じて瑕疵担保を主張したが、基幹系を主張されて紛議になるケースがあり、その時は、検収書はあるが検収の実体がなかったことを主帳立証することになる。

そこで瑕疵担保責任の起算点を、「基本契約との不一致を知ったとき」とすることが考えられる。こうすると、実体のない検収を理由とするトラブルを回避することが可能になる。





システム開発契約の論点 第1回 請負契約か準委任契約か

■システム開発契約の法的性格を巡っては,請負と捉えるか,準委任と捉えるかが論じられている。
私も報告書作成のタスクフォースに加わった経済産業省の情報システムの信頼性向上のための取引慣行・契約に関する研究会「情報システム・モデル取引・契約書モデル契約プロセス」の報告書」でも,超上流から外部設計までは準委任(外部設計には請負あり),内部設計からシステムテストの前までは請負,システムテストから運用テストまでは準委任(システムテストには請負あり),運用と保守は準委任と請負を原則とするというように分けている。
この分類は,これから契約をする場合にどちらの類型を使うかを決める指標としては役立つことは間違えない。
しかし,要件定義は請負が正しいとか,すでに今目前にある契約が請負,準委任かどちらかを判断する指標になるとまではいえない。

■システム開発契約と請負か準委任かという問題のとらえ方のギャップ
システム開発契約を請負が,準委任かという問いは,担当者に基礎的な法的知識を与えるフェーズでは有効だが,実は,無理がある。
そもそも,日本の民法の請負契約と準委任契約のモデルはシステム開発契約など存在しなかった明治以前の社会のありかたいて規定されている。(本当は,さらにドイツ民法の成果を踏まえている・・・まあドイツにもシステム開発契約などなかったわけで,おなじことだが)。しかも,この二つの契約類型の差は,歴史的に形成されてきたのであって,理論的に区別されるわけではない。
請負なのか準委任なのかは,理論的に区別されるものではない。事実によって区別される。
どのような事実か。
それは,当事者が何に対して対価を支払うと考えたのかという事実だ。
仕事の結果・完成に対して払うなら請負,仕事を精一杯してもらったことに対して払うなら準委任だ。
具体的には,対価を支払う成果を,発注者が検証・評価する方法,判断の基準をどれほど具体的に決められるか,その内容を決めるにあたりベンダ側の裁量がどれほど多く認められるのかが分かれ目になると言えるだろう。





システム開発契約のコツ

契約書の解釈を巡る紛争はよくあることだ。
特にシステム開発請負契約などでは,仕事の内容を特定することが大問題。
最近こういう文案に接した。
「本契約の解釈に甲乙間の相違があるときは,甲の解釈を優先する」
感心した。
まず,この文言を考えた人の経験の豊富さ。過去によほど痛い目にあったにちがいない。
しかし経験を蓄積し,契約書に生かすという知恵は素晴らしい。皮肉ではない。心底そう思う。
ところでこの文言の効果はどうか。文字通り全てに甲の解釈を優先できるのか?
争いになったときは,おそらく,「合理的な範囲において」という限度で有効ということになるだろう。
契約の本質は合意だ。だから,こうした文言が有効な範囲は,契約の経緯,利害の公平などを考慮して,当事者の合理的な合意の内容がまず最優先されることになるだろう。その限度で,この規定は有効だろう。
とはいえ,当事者の合意の解釈をめぐる指針」という)意味では評価してよい規定だと思う。
たしかにこの文言からは,ユーザー側の強引さが伝わってくる。
しかし,契約内容は,終局的には力関係で決まるのだ。



システム開発契約紛争 瑕疵か追加か トラブル防止の秘法

システム開発契約のトラブル,瑕疵か追加かの争いをやっていて,つくずく感じる問題点。それは,ユーザーもベンダも発注内容をイメージでしか理解していないことだ。一番大事な合意の内容が,詰められていない。いくらベンダやコンサルタントがインタビューしても,当事者がレビューをしても,検収しても,回答をイメージや願いを語り合うだけでは詰められない。代金は円単位で考えていることを思い出せといいくなる。
じゃどうしたらいい?
ポイントは,文字化だ。ところがどっこい,やってみるとそれは意外に難しい。なぜか。日常生活でそれほどの粒度が要求されることはない。仮にあっても,十分にできないとしても精一杯やってもらえばそれでよいというのが日常生活だからだ。
そこで提案。文字化のプロセスを弁護士にやらせる。弁護士の能力の中核は,証拠をそろえ,その証拠にもとづいて合理的に推論すると主張が認められるということを文字で表すことだ。だから紛争に耐えられる粒度で,発注内容を文字化し,その証拠をそろえるには適任なのだ。餅は餅屋。弁護士を紛争予防に使う。これがあたりまえになれば法務コストはぐっと下げられる。

QRコード
QRコード
  • ライブドアブログ