2009年07月

twitter中継の真の効用は、誰でもいつでも生の事実に触れられるってことなんだろうなと思う。
突然始まる実況を追うのはそりゃ楽しいけど、それじゃ現場で話を聞く行為の延長でしかない。
でも、いったんtwitterを通じて会場で放たれて即座に消えていく運命にあった発言がアーカイブされ、誰でもその発言を振り返ることができるってことは、恐ろしいと同時に結構すごいことなんじゃないだろうか。

なんていうか、総議事録化っていうか。

つまり、過去の発言を引用されて批判されたことのある人は、ほとんどの場合「そんなこと言ってない。」って嘆きを覚えるはずで、だから「そんなことは言ってない。ここを読めばわかる。」ってときの「ここ」があるということが重要なんだろうなと。

---

と、実はここまではtwitterでつぶやいたことの焼き直しなんだけど、今読み返してみると、こんなことは机上の空論でしかないってことも同時に思ったりする。

結局さ、人がどんな発言をしたのかを正確に把握したいと思ってる人なんて、そんなにいないんだよ。
みんなマスコミやブロガーなりが切り取ったわかりやすく話題に乗せやすい断片しか求めてないんだから。
だから、「そんなことは言ってない。ここを読め。」なんて言ってもどうせはてブの荒波にさらわれて太平洋のど真ん中あたりに置き去りにされるだけなんだろうなって。


で、何が言いたかったかというと、「今日の勉強会に参加した皆さん、お疲れ様でした。」ってこと。
それだけ。

ではでは。
このエントリーをはてなブックマークに追加 Share on Tumblr

ふと思いついたので、NDAの作成過程を噛んで含めるように追ってみることにした。
昼休みが終わるまで続きます。
もちろん、推敲ゼロです。

-----

秘密保持契約の記載内容をチェックする前に、まず
・この契約に基づいて重要な秘密情報が開示されるか
を検討しましょう。

秘密保持契約を締結する場合であっても、実はそれほど重要な秘密情報が開示されないことはよくあります。
(ここで言う「重要」は、漏洩した際に具体的な問題に繋がる可能性が高いという意味です)
重要な秘密情報が開示されないケースでは、そもそも秘密保持契約の内容にはさほど意味は無いので、遵守できない条件や事実と異なる記載が無い限り、あまりごちゃごちゃいう必要はありません。
このような場合における秘密保持契約の締結は、一種のセレモニーです。
うるさいことを言わずに、気持ちよくセレモニーを実施させてあげましょう。


ある程度重要な秘密情報が開示されることがわかったら、いよいよ内容の検討に入ります。
まず最初に検討するのは
・どんな場面を対象にした秘密保持契約か(目的)
です。

この”場面”については、「●●に関する協業の検討」や、「●●(製品)の導入の検討」といった程度までは、具体的に適用される場面を特定しましょう。
これは、想定していないケースにまで秘密保持義務が波及してしまうことをことを防ぐための配慮です。

なお、個人情報保護契約等の特殊なケースでは、適用される場面を特定せず、当事者間の情報のやり取りのすべてを対象にすることもありますが、そのような場合は、次の「秘密情報の定義」でちゃんと絞りを利かせてあげましょう。


場面の特定が終わったら、次は
・どのような情報を秘密に取り扱うか(秘密情報の定義)
の検討に入ります。

パターンとしては、
【開示された情報】
1.秘密表示がなされている情報
2.特定の種類の情報
3.案件に関連して開示されたすべての情報
【開示されないのに知っちゃった情報】
A.知った場面を限定
B.案件に関連して知ったすべての情報
の組み合わせで構成されます。

3やBは、一見すると便利なように見えますが、これらには「何が秘密情報なのかが、実務担当者にわかりづらくなる」という問題があります。
どんな重要なケースでも、すべての情報を秘密にしなければならないということはありえないため、現場では当然(意識的にせよ、無意識的にせよ)秘密情報とそうでない情報の選別がなされます。そして、現場での選別は、なし崩し的に「本当に秘密に取り扱ってもらいたい情報も秘密情報として認識されなくなってしまう」という事態を招きかねません。
秘密情報は漏洩したら元に戻せないことをあわせて考えると、このような規定はあまり好ましくありません。
セレモニー向けの条件にしておいたほうが無難です。

2は、特定のソフトウェアのソースコードを開示する場合や、特定の顧客の個人情報を開示する場合など、秘密に取り扱ってもらいたい情報が限定される場面では最も適しています。

1は、もっともオーソドックスな条件ですが、前提として、秘密情報の開示の際には、必ず秘密表示を行うことが社内的に周知されている必要があります。
この前提が満たされていない場合は、秘密保持契約書云々の前に、秘密情報の開示ルールを整理しましょう。
つまり、「細かいことにこだわる前に、やるべきことがある」状態です。

なお、AやBについては、事業所への立ち入りを許可する場合や、秘密情報を記録したサーバへのアクセスを許可する必要がある場合など、開示を伴わない秘密情報の知得をカバーする際に利用します。

また、この項目に関連し、もれなく「秘密情報の例外」を設定する必要が生じますが、これは検討する余地は無く、1.開示時点ですでに公知だった情報
2.開示時点ですでに情報を受け取った当事者が知っていた情報
3.開示後に、情報を受け取った当事者の責めに帰すべからざる事由によって公知になった情報
4.開示後に、正当な開示権限を有する第三者から秘密保持義務を課されずに開示された情報
5.開示後に、開示当事者が開示した秘密情報と無関係に情報を受け取った当事者が開発した情報
が設定されます。
1と2は、開示前の話で、3と4と5は開示後の話です。
個人的には、5をもっとうまく書けば4を統合させることができるように思うのですが(統合すると、きれいなマトリックスが書ける)、この5種類を例外として設定するのがスタンダードなので、細かいことは考えるのはやめておきましょう。(我流の工夫は読みにくい契約書の第一歩です)

秘密情報の定義が終わったら、次はいよいよメインディッシュ
・秘密保持義務の設定
に入ります。

まず当然の内容として
・第三者への開示または漏洩の禁止
を据えてから、例外規定(開示または漏洩が禁止されない第三者)を設定するという手順になります。

シンプルに済ませたい場合は、例外を設定を省略するという選択もありでしょう。
れいg(残念。ここでお昼休みが終わってしまいました。)
このエントリーをはてなブックマークに追加 Share on Tumblr

↑このページのトップヘ