最近の関心事は、どれだけ効率的に契約法務のスキルを人に伝えられるか、なのですが、その一環として契約書のスタイルガイドを作ってみたので公開します。
こちらからどうぞ

目新しい内容は含まれていませんが、既存のものは、内容が分散していたり、書き方という切り口でまとめられていなかったりと、スタイルガイドとしての使い勝手が悪いことも少なくなかったので、コンパクトにまとめたこと自体に一定の意味があるんじゃないかと期待してます。
また、水野先生のGitLawに関するエントリを読んで初めてGitに興味を持たれた法務畑の方もいらっしゃるのではないかと思いますが、そのような方に「Gitのはじめの一歩」として軽い気持ちでいじっていただく材料としても、ちょうどいいのではないかとおもってます。
→forkからプルリクまでの流れは、このエントリが分かりやすいのでオススメです。

いずれにせよ、これが最終版というわけではなく、今後も更新を続けていきたいと思っているので、お手元に似たようなガイドをお持ちの方(規模の大きな法務事務所や伝統のある法務部には、内部的にはこんな感じのガイドはあるんじゃないかと期待してます)がいらっしゃったら、差異についてご指摘いただけるとすんごく嬉しいです。

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

転職してそろそろ1年が経とうとしています。

今所属している会社は、ありがたいことに売上は右肩上がりで、しっかりと利益も出していて、きれいで先進的なオフィスに、著名なエンジニアも多数所属していることもあり、外部から高く評価していただけていることを実感する機会に出会うことが多々あります。
このことはとても素晴らしく、ありがたいことだなぁと思うのですが、同時にある種の居心地の悪さを感じずにはいられません。

わずか1年前に転職してきたばかりの僕は、このポジティブな評価の源泉である売上にも、利益にも、就業環境にも、メンバーの質にも、直接的には何も貢献していません。それにもかかわらず、イベントの集客の際や、話してみたい人に声をかける際(ランチしませんか、とか)にはこのポジティブな評価からの恩恵をふんだんにうけているのを感じますし、(今のところそのつもりは全くないけれど)もしかすると何年後かにまたすることになってしまうかもしれない転職の際にもきっと役にたつことでしょう。
こんな具合に、自分の貢献が寄与していない評価から実利を得るということは、ありがたいと同時に、なんとも居心地が悪いものなのです。

でもまぁ、今の状態はいわば対価を支払わずにサービスの提供をうけているようなものなので、これはこれでむしろ健全なのかもしれません。
というか、自分が所属している会社に対するポジティブな評価に貢献していないのに、その評価を享受することに疑問を感じなくなっちゃったらマズいじゃないですか。これじゃ、「大企業に所属していることを誇りにしている人」と何も変わらない。

というわけで、2年目以降は、自分も今の会社の価値向上にちゃんと貢献できているという実感をちゃんと持てるように、目に見える成果を出していきたいなーと思う所存です(きれいにまとまった!)

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

前回ダブルチェックを通じたスキル継承に対する優位性をお伝えした法務版ペアプロですが、本来のペアプロと同様、ただ単に一人が契約書を作る様子をもう一人が眺めているだけでは高い効果を得ることはできません。
というわけで今回は、法務版ペアプロの進め方とコツをお伝えしたいと思います。

    事前準備
  1. 契約書の作成・修正の方法(スタンスや考え方に留まらない、具体的な手順)を教える
    自分が実際にやっている手順でOK
    教える人は事前に棚卸しをしておく必要がある(体に染み付いたことでも、わかりやすく言語化できるとは限りません)
    確固たる手順を持っていない人は、人に教える前に自分が手順を確立する方が先・・・かも・・・
  2. 法務版ペアプロの趣旨を教える人と学ぶ人との間で確認する
    ・スキル継承の手段であること
    ・質問でカットインすることにためらってはならないこと
    ・自分なりのやり方と違っても、言われた方法でやってみること(スキル継承のため)
    は必ず確認すること。

    【進め方・コツ】
  1. 学ぶ人が、自分なりに契約書の作成・修正を行う
    このステップを飛ばすと、学ぶ人の質問が薄くなってしまう
  2. 教える人がドライバー(書く人)、学ぶ人がナビゲーター(見る人)になって、契約書の作成・修正を行う。
    この際、学ぶ人は、1で作成・チェックした契約書を印刷して手元に持っておく。
    学ぶ人は、教える人の修正の意図が分からなかったら、都度質問をする。
    教える人は、考えていることや浮かんだ疑問などをできるだけ口に出す。(別の場所に書いてあるのかな・・・とか、これおかしくないか?とか)
    作成・チェックの完了後、1と2の成果物のギャップを確認し、ギャップが生じた理由を確認する
    最初に学ぶ人が作成・チェックした契約書は無駄になるが、スキル継承のために必要なコストとして割り切る。
  3. 上記2を何度か行い、学ぶ人が契約書の作成・修正の手順を概ね理解できたタイミング(概ね3〜4案件が目安)で、ドライバーとナビゲーターを交代する
    教える人は、言葉遣いに注意!
    過去の否定は、それ自体が人を傷つけてしまうことを忘れずに。
    教える人は別の作業をせず、ナビゲーターに集中すること。
    指摘は理由を必ず添えること。


なお、法務版ペアプロに限らず、スキル継承は、教える人が学ぶ人に継承すべきスキルを持っていることが当然の前提になります。
特に2で教える人が負担する工数が気になってしまうかもしれませんが、そもそもスキル継承には工数がかかるもので、この程度は必要なコストだと思っています(逆に言えば、この程度のコストもかけずにスキル継承をしようとするから、無駄にスキル習得に時間がかかってしまう)。

もし、もっといいやり方があるよ、といったアドバイスがあればぜひ教えてくださいませ〜

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

昨日のエントリーで書いたダブルチェック&フィードバックに代わるスキル伝達方法について、Twitterでこんな言及を頂きました。

そうなんです、これ、ペアプログラミングを契約書作成に適用してみたやつなんです。

一般的に、契約書作成スキルの承継は、ダブルチェックとその結果のフィードバック(DC)を通じて行われていると思いますが、契約書版ペアプログラミング(PP)は、DCが持つ以下のような欠点を補ってくれます。

・フィードバックの効果が高い
DCでは、成果物を作成してからそのフィードバックを受けるまで、短くても数十分、長ければ数日間隔が開いてしまいます。間隔が開けば、それだけ「何を考えて、何に悩んでいたか」に関する記憶が薄れてしまうので、フィードバックの効果が低減します。
これに対してPPでは、フィードバックを即時に得られるので、フィードバックの効果を最大限に活かすことができます。

・やり方を伝えられる
DCでは、チェック結果のやり取りによってスキルの承継を行うことになるので、どうやってその結果にたどり着いたかという「やり方」を伝えることはできません。
これに対してPPは、契約書を作成し、または修正する過程をつぶさに見ることができるので、「やり方」を学ぶことが可能です。

・疑問をその場で解消できる
DCでは、フィードバックをまとめて渡されるので、チェック者を捕まえて確認する程ではない些細な疑問については、そのまま放置してしまいがちです。
これに対してPPは、リアルタイムでフィードバックが渡されるので、個々のフィードバックについて都度不明点等を確認することが可能なので、疑問が放置されにくくなります。

・緊張感を持てる
DCでは、特に業務の繁忙期には、「この後ダブルチェックをしてもらえるから」「自分が見る前に別の人がチェックしているから」という甘えから、チェックが緩くなりがちです。
これに対してPPには上記のような甘えが入り込む余地はなく、それどころか後ろでつぶさに作業を見られるため、通常時以上に緊張感をもって作業にあたることができます。


次回は、法務版ペアプロの具体的な進め方やコツを書きたいと思います〜
このエントリーをはてなブックマークに追加 Share on Tumblr

7月になりました。
今年も半分が終わったという事実に愕然とします。

・・・さて、先々月から、何度目かの「人に契約法務のスキルを人に伝える」ということに携わっていて、当初から一区切りの時期として設定していた6月末が過ぎたので、備忘録も兼ねて、ここで一度振り返りをしてみたいと思います。

1.ダブルチェックを、スキル伝達ツールとして使わない
今までも何度か「教育係」的な役割を任せられたことがありますが、今思うと本当に申し訳ないことに、なんとなく「とりあえずチェックしてみて」からのダブルチェックで追加修正&フィードバックを重ねる、場当たり的で非効率な方法を採ることしかできていませんでした。
でも、こんなやり方で自分が持つスキルを伝承しようとしたら、何年かかるかわかりません。というか、何年かかってもしっかりとは伝えきれないのではないかと思います。というわけで、今回は「スキルを伝えるための方法として、ダブルチェックは使わない」という方針を立てることにしました。
その代わりにやったのは、
1.自分が契約書を作ったり、修正する作業を全て後ろで見ていてもらう
2.作業をしながら「考え方」や「コツ」を伝える
3.見ていてわからないことがあったら、その場でカットインして質問してもらう
4.質問を受ける都度、作業を中断して理解を得られるまで説明をする
を何度か繰り返し、わかってきたかな、というタイミングで、今度は
1.契約書を作ったり、修正する作業を全て後ろで見る(並行して他の作業はしない)
2.作業を見ながら「考え方」や「コツ」を伝える
3.見ていて意図がわからないことがあったら、その場でカットインして質問する
4.質問の都度、作業を中断して共通認識に至るまで協議する
を繰り返す、という方法です。

2.「考え方」「やり方」を棚卸しして、検証する
教える側にとっての「守破離」というエントリーは、「人に何か教えるなら、教えることについて明確な型を持っている必要がある」と思って書いたものです。
そして今回、自分の「型」を明確にするため、契約書を作ったり修正したりするときに、どのように考え、どのようなツールを使い、どのように作業しているのかを棚卸しして、上記の1に入る前と、上記1の2において伝えるようにしました。

3.ブレない
人に何かを教えていると、どうしても「人にはこんなこと言ってるけど、自分でもできてないかも」という気後れや、「やり方はこれだけじゃないんだよな」という思いが脳裏をよぎり、どうしても断定的な言い方を避けがちになってしまいます。
でも、こういったブレって教える人の保身に過ぎなくて、教えられる人にとっては迷惑でしかないと思うんですよね。正直、「いや、これは人によるんだけどね。」とか言われても、言われた方は困るじゃないですか。
というわけで、最初に「教えたやり方がベストではない可能性はあるけど、6月末までは、とにかく教えたやり方通りにやって欲しい。」と伝え、その後は極力やり方については断定的な言い方で伝えることを心がけました。

4.期限を切る
スキルの継承は明確な終わりが見えづらいタスクないものなので、だらだら進めてしまいがちですが、効果を検証するために、いつまでに、どのレベルまでできているようになるべきか、現時点での到達度はどうかを対象者と日々確認することを意識してスキル継承に取り組みました。



ブラッシュアップする余地はまだまだ大きいですが、それでも日常業務の片手間に、しかも本来は成果物の品質向上のための施策であるダブルチェックを通じてスキルの継承に取り組んでいたときとは段違いに効率的にスキルを継承できた気がします。
とはいえまだ情報が少ない分野だと思うので、「自分はこうしてるよ」といった情報やノウハウがあれば、ぜひ教えて下さい〜。

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

個人情報の利活用の場面において個人情報の匿名化を避けて通ることはできないわけですが、踏み込んだ知識はデータ処理の門外漢には敷居が高く、「完璧な匿名化手法は存在しない」というかの有名な結論については理解できても、そこから進んで「どうするのがベターな匿名化手法なのか」といったことについては今ひとつ理解できずにいました。

そんな中でデータ匿名化手法 ―ヘルスデータ事例に学ぶ個人情報保護の存在を知り、早速読んでみたところ、いくつか腑に落ちたことがあったのでまとめてみます。

  • 匿名化は確率的なものなので、再特定化される可能性をゼロにはできない。(上記の「完璧な匿名化手法は存在しない」と同じこと)
    生データを提供することで得られるメリットは、生データを提供することで発生するリスクとのトレードオフ。
    問題はリスクがゼロかではなく、リスクを正当化できるか。

  • データの開示方法、データの開示を受ける人が既に保有している知識や、再特定化するモチベーション・能力によって匿名化の手法やレベルが変わる
    例えば、コンテスト等のためにデータを公開する場合は厳重に匿名化を施す必要があって、再特定化禁止義務を課した研究者(再特定化モチベーションも再特定能力も高くない)にデータを開示する場合とは必要な匿名化のレベルは大きく異なる。

  • データの用途や分析方法によって、匿名化手法を変える必要がある
    わかりやすい例としては、発生順序が重要なケースにおいては、非特定化のために発生年月日をランダムに変更してしまうと、それだけで全く価値のないデータになってしまう

  • 再特定化のリスクの判断のアプローチには、最大リスク(再特定確率の最も高いレコードを全体リスクとみなす)と平均リスクがある
    公開データに対して再特定化アタックをされる可能性があるようなケースでは、攻撃者は誰か一人でもいいから特定しようと攻撃してくる以上、最大リスクアプローチでリスクを判定する必要がある。
    これに対して、「あ、これってあの人じゃん」的な再特定を防げば良い場合は平均リスクアプローチで考える。

  • ヘルスケアデータは、生データを使って分析をする強い社会的意義(疾病の防止や原因究明など)があるので、再特定化リスクをとってでも利活用するメリットを観念しやすいので、ビジネス利用というか、金儲けの場面では全く同じようには考えられないだろうな(感想)


無個性なイワシの群れを匿名化本の表紙に選んだオライリーのセンスが光るこの一冊、読むのは苦労しましたが、一歩前に進めた気がします。


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

内田・鮫島法律事務所の伊藤 雅浩先生より、ご著書システム開発紛争ハンドブック―発注から運用までの実務対応をご恵贈頂きました。





システム開発をめぐるトラブルを専門とされる弁護士といえばと問われたとき、松島先生と伊藤先生のお二方のお名前が浮かぶ方は少なく無いと思いますが、本書はその松島先生と伊藤先生の共著によるシステム開発紛争をテーマに取り上げた書籍というわけで、その情報だけで購入を決めた方も少なくないのではないでしょうか。
かくいう僕もその一人でした(ご恵贈頂いたので、実際には購入には至りませんでした。なんかすみません・・・)。

さて、本書は、タイトルに「システム開発紛争」を掲げており、実際に裁判例を軸に様々な論点に対して説明が進められていきますが、現に紛争案件を取り扱っているか否かにかかわらず、システム開発関連の契約法務に携わっている方は一読しておくべき一冊だと思います。
というのも、システム開発に関して発生する様々なアクションについて相談を受けた際に、それを裁判所がどのように評価するのかを知らなければ、自分の感覚や、自分なりに考えた理屈を頼りに回答することになってしまいますが、もしそれが裁判所の判断と異なるっていた場合、無意味な、また場合によっては有害なアドバイスをしてしまうことになりかねないからです。

また、裁判例が豊富に掲載されているということは、つまりトラブル事例集としても機能するということでもあります。
システム開発紛争に関する社内研修を行うと、必ずテーマとしてリクエストを受けるのはこの「トラブル事例」の共有なので、日本屈指のシステム開発関連訴訟の専門家が選定したトラブル事例集を手にすることができるという意味では、法務だけでなく、プロマネや情シス部門の責任者の方にも有用なのではないかと思います。

僕も、ひとりよがりなオレオレ理論で会社に損害を与えてしまうことの無いよう、もう一度ドッグイヤーしたページを読み返して、しっかりと自分の血肉にしたいと思いました。


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

上手に使うと業務効率向上の大きな武器になる反面、暴走しちゃうと社内に混乱をもたらす諸刃の剣、それが契約書のひな形ですが、これまで数社を渡り歩く中で利用者のとっての利便性の確保と法務にとっての管理の容易性が釣り合う落とし所がが見えてきたので、ベストプラクティス案として一旦とりまとめてみようと思います。
一つ一つは当たり前のことですけど、こういう当たり前をきっちりやりきるのって、結構たいへんなんですよね。

【解決すべき課題(混乱の素)】

  1. 「法務チェック済みの汎用的な契約書フォーマット」と、性格が全く異なる書面、例えば以前同種の案件で利用した個別案件用の契約書などが、「ひな形」で一括りにされがち
  2. ひな形の改定後も、古いバージョンのひな形が利用されがち
  3. 内容が微妙に異なるひな形が混在しがち
  4. 想定外の用途に転用されてしまいがち
  5. 改定が滞りがち

【ベストプラクティス案】

  1. 「ひな形」とは呼ばない
    いきなりですが、法務が管理するひな形は「ひな形」とは呼ばず、多義的な「ひな形」とは別物という位置づけにします。(過去の経験では、法務が指定したひな形という趣旨で、「指定フォーマット」や「指定フォーム」と呼ぶことが多かったです)
    これにより、課題1を解決します。
    →このエントリーでも、普通名詞としてのひな形と区別するために、「指定フォーム」と呼びます。

  2. 最新バージョン以外の利用を禁止する
    指定フォームは、法務以外のメンバーはダウンロードのみ可能な設定にしたファイルサーバやファイル共有システムから、最新版のみを提供します。
    また、指定フォームは、常に利用時にダウンロードすることを求めます(他案件用にローカルに保存したひな形の転用を見つけたらNGにする)。
    指定フォームのファイル名末尾とヘッダーにバージョン番号を記載し、古いバージョンが利用されていた場合にすぐに気づけるようにします。
    これにより、課題2を解決します。

  3. 提供方法を2つに分ける
    指定フォームの中にも、汎用的なNDAや外注時の取引基本契約のように、どの部署でも利用する可能性があるものもあれば、出版契約や特定のコンテンツのライセンス契約など、特定の部署でしか利用しないものも存在します。
    このように、特定の部署でしか利用しない指定フォームについては、指定フォームの共有フォルダまたは提供システムの設定で、利用部署だけにアクセス権を付与したり、それが手間であれば、特定の部署だけにファイルパスやURLを開示するといった方法で、指定フォームを入手できる部署を限定します。
    これにより、課題4を解決します。

  4. 1ページ目を説明書にする
    指定フォームがカバーしている用途を1ページ目に書き、契約書本文は2ページ目からスタートさせます。
    これにより、課題4を解決します。
    なお、当然のことではありますが、相手方も見ることになるので、余計なことは書かないように注意しましょう。(一ページ目は相手方に出しちゃだめ、的な指示が守られることはまずありません)

  5. フォームのみ編集可の保護をかける
    指定フォームには、相手方社名、締結日などの案件によって変更する必要がある項目にテキストボックス等のフォームコントロールを設置し、フォームのみ編集可の文書保護をかけます(保護の解除は法務以外には行えないようにパスワードを管理します)。
    これにより、課題3を解決し、加えて相手方からの趣味の修正を抑止する効果も得られます。
    なお、フォームコントロールについては冒頭にすべて取りまとめることで、指定フォームの使い勝手が格段に向上します。

  6. 修正は特約事項で対応
    指定フォームには、必ずテキストボックスを設置した特約事項欄を設けておき、相手方から指定フォームの契約条件の修正を求められた場合は、原則として特約事項への追記で変更に対応します。
    また、修正点が多い等の理由で特約事項で対応できない場合は、ヘッダーのバージョン番号の後ろに「一部変更」等の追記を行い、指定フォームから内容が変更されていることが明確になるようにします。
    これにより、課題3を解決します。

  7. 効果を明確に
    指定フォームを利用した場合にのみ、内容に変更がなければ法務の事前チェックを省略できるという効果を得られることを明確にし、指定フォームと、指定フォーム以外のひな形の取り扱いを分けます。
    これにより、課題1を解決します。
    また、最新版ではない指定フォームは、指定フォームであっても上記の効果を得られないことも明確にします。
    これにより、課題2を解決します。

  8. 改定の責任者・手順を固めておく
    一度リリースしてしまった指定フォームは改定が滞る傾向にあるので、指定フォームの品質確保にコミットする担当者を法務内で選任するとともに、改定手順を明確にしておきます。
    また、各法務担当者が相手方から受けた指摘や、気づいたことを手軽に放り込んで一時的にストックしておく仕組みを用意しておきます。これにはRedmineやTracなどのバグトラッキングに適したシステムを利用できるととても便利なのですが、むずかしいようであれば、専用のエイリアスを作ったり、最悪エクセルなどに書き込むのでもいいと思います(ただ、経験上、エクセル管理はうまく回らない(だれも登録してくれない)ことが多いです。とにかく簡単に放り込めるようにすることを重視してください。)
    これにより、課題5を解決します。

    以上です。
    「もっといい方法があるよ」とか「これもやったほうがいいよ」といったご指摘をいただければ嬉しいです。
このエントリーをはてなブックマークに追加 Share on Tumblr

間違えると結構やばいのに、積極的に教えてもらう機会が少ない期間の計算を一回ちゃんと押さえておきましょう、そうしましょう。


・関連する条文(民法)
第百三十八条 期間の計算方法は、法令若しくは裁判上の命令に特別の定めがある場合又は法律行為に別段の定めがある場合を除き、この章の規定に従う。
第百三十九条 時間によって期間を定めたときは、その期間は、即時から起算する。
第百四十条  日、週、月又は年によって期間を定めたときは、期間の初日は、算入しない。ただし、その期間が午前零時から始まるときは、この限りでない。
第百四十一条  前条の場合には、期間は、その末日の終了をもって満了する。
第百四十二条  期間の末日が日曜日、国民の祝日に関する法律 (昭和二十三年法律第百七十八号)に規定する休日その他の休日に当たるときは、その日に取引をしない慣習がある場合に限り、期間は、その翌日に満了する。
第百四十三条  週、月又は年によって期間を定めたときは、その期間は、暦に従って計算する。
 週、月又は年の初めから期間を起算しないときは、その期間は、最後の週、月又は年においてその起算日に応当する日の前日に満了する。ただし、月又は年によって期間を定めた場合において、最後の月に応当する日がないときは、その月の末日に満了する。


・時間単位で定めた期間
  1. 時間、分、秒で定めた期間は普通に計算すればOK(§139)
    以下、日、週、月、年で期間を定めた場合のルール

・期間の起算
  1. 「(あるイベントの発生日)の●日後」と定めた場合は、午前0時にイベントが発生するような超例外的な場合を除いて翌日が起算日になる(§140本文→初日不算入の原則
  2. 「(あるイベントの発生日)から起算して●日後」と定めた場合は、起算日の特約があるため、特約通り当日が起算日になる(§138)
  3. 「(特定の日付)の●日後」と定めた場合は、午前0時からその日は始まるので、当日が起算日になる(§140但書)

・期間の終了
  1. 期間の終了は、期間の末日の深夜24時(§141)
    →期間の末日の翌日の午前0時と同じ時間ではあるが、別の日(12/31に著作権が消滅する著作物は、翌年1/1から発効する改正著作権法による著作権の存続期間延長の対象にはならない)
  2. 月初起算の1年間は、翌年前月の末日に終了する
  3. 月初起算の1ヶ月間は、当月の末日に終了する
  4. 1月30日や8月31日など、翌月には応当日が存在しない日の「翌月」と期間の満了日を定めた場合は、翌月末日に期間が満了する(§143驚⊇顱
  5. 期間の末日が日曜・祝日の場合は、(一般的な会社の場合は休業するので)翌日に期間が終了する(§142)

・遡る期間の考え方
  1. 時間の流れに沿うよう逆算して上記のルールを適用する
    →「●日前までに通知する」を、「通知してから●日後」に読み替える
  2. 結論としては、初日不算入の原則により、「中●日間」になる
    →末日が休日だった場合の処理なども適用されるので、結論だけをただ覚えるのは危険

・実務上の留意点
  1. 契約期間を「締結日から1年間」と定めると、初日不算入の原則により翌年同日が契約期間終了日になって現場の認識と食い違う
    →更新期間も同様
    →「締結日から起算して1年間」または「(特定の日付)から1年間」と定めておくと認識のズレが生じない


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

ウェブサイトやアプリに広告を貼ろうと思って広告配信に関する契約を締結しようとすると、広告配信サイドからコンテンツの適法性や適切性について様々な保証を求められることになります。
例:nend利用規約第 18 条(禁止行為)1項1号
1.メディアパートナーは、nendメディアパートナーサービスを利用するにあたり以下各号に定める事項を行ってはならず、当社から是正の要請のあった場合には、すみやかに応じなければならない。
(1) メディアサイト等(メディアサイト等に掲載されるバナー、メディアサイト等のユーザーが投稿した記事・音声・動画等の情報を含む)に、アダルト、暴力・虐待の推奨、人種差別の推奨、その他、公序良俗に反する、当社を含む第三者の著作権その他の権利を侵害する、又は法令に違反する等、当社が不適当と判断するコンテンツの掲載行為


アドネットワーク事業者等からすれば、おかしなサイトに広告を配信するわけにはいかないので当然の要求ではあるのですが、メディア側でUGC(ユーザーが生成したコンテンツ)を受け入れている場合、事前に全件チェックをしているような例外的なケースを除き、メディア上のコンテンツを全てコントロールすることはできません。

というわけで、UGCに関する免責を設定する必要があるわけですが、じゃぁ具体的にどんな感じで免責を定めるかを段階的に膨らましてみよう、というのが今回のお話です。



Level 1
まずは、UGCに関しては完全に免責を受けるというパターン。
だれが受け入れるんだよ、と思う向きもあるかもしれませんが、試しに言ってみたらOKがでてこっちがびっくりすることもたまにあるという風のうわさを耳にしたことがあります。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信した情報については、メディア運営者は何らの責任も追わないものとする。


Level 2
続いて、ユーザーに義務を課すから勘弁してね、というパターン。
ちょっと中途半端感があって、これに落ち着いたという経験は僕はありません。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信(以下、本稿において「投稿等」という。)した情報(以下、本項において「UGC」という。)については、メディア運営者が広告掲載メディアのユーザーに対し、【内容保証を定めた条項】に反するUGCを広告掲載メディアに投稿等しないよう義務付けることを条件に、メディア運営者は何らの責任も追わないものとする。


Level 3
さらに、違反コンテンツは削除するから勘弁してね、というパターン。
ここら辺から徐々に条件に合理性が出てきます。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信(以下、本稿において「投稿等」という。)した情報(以下、本項において「UGC」という。)については、メディア運営者が以下の各号を遵守すること条件に、メディア運営者は何らの責任も追わないものとする。
(1)メディア運営者が広告掲載メディアのユーザーに対し、【内容保証を定めた条項】に反するUGCを広告掲載メディアに投稿等しないよう義務付けること
(2)メディア運営者が【内容保証を定めた条項】に反するUGCを発見した場合、すみやかに広告掲載メディアから削除すること


Level 4
一歩進んで、発見のための努力もするよ、というパターン。
ウェブメディアでは言われてなくてもやってるよ、というところも少なく無いと思います。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信(以下、本稿において「投稿等」という。)した情報(以下、本項において「UGC」という。)については、メディア運営者が以下の各号を遵守すること条件に、メディア運営者は何らの責任も追わないものとする。
(1)メディア運営者が広告掲載メディアのユーザーに対し、【内容保証を定めた条項】に反するUGCを広告掲載メディアに投稿等しないよう義務付けること
(2)広告掲載メディアの性質に鑑みて合理的な頻度及び程度で、メディア運営者が【内容保証を定めた条項】に反するUGCが広告掲載メディアに投稿等されていないことを確認すること
(3)
メディア運営者が【内容保証を定めた条項】に反するUGCを発見した場合、すみやかに広告掲載メディアから削除すること


Level 5
保証違反の判断を広告配信側にもさせるパターン。
だんだんエグみが出てきました。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信(以下、本稿において「投稿等」という。)した情報(以下、本項において「UGC」という。)については、メディア運営者が以下の各号を遵守すること条件に、メディア運営者は何らの責任も追わないものとする。
(1)広告掲載メディアのユーザーに対し、【内容保証を定めた条項】に反するUGCを広告掲載メディアに投稿等しないよう義務付けること
(2)広告掲載メディアの性質に鑑みて合理的な頻度及び程度で、【内容保証を定めた条項】に反するUGCが広告掲載メディアに投稿等されていないことを確認すること
(3)【内容保証を定めた条項】に反するUGCを発見した場合、すみやかに広告掲載メディアから削除すること
(4)広告配信事業者から【内容保証を定めた条項】に反する旨を通知されたUGCを、広告掲載メディアからすみやかに削除すること


Level 6
そもそも技術的に水際で食い止めてよパターン。
とりあえずNGワードリストでいかがでしょう。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信(以下、本稿において「投稿等」という。)した情報(以下、本項において「UGC」という。)については、メディア運営者が以下の各号を遵守すること条件に、メディア運営者は何らの責任も追わないものとする。
(1)広告掲載メディアのユーザーに対し、【内容保証を定めた条項】に反するUGCを広告掲載メディアに投稿等しないよう義務付けること
(2)広告掲載メディアの性質に鑑みて合理的な頻度及び程度で、【内容保証を定めた条項】に反するUGCが広告掲載メディアに投稿等されていないことを確認すること
(3)【内容保証を定めた条項】に反するUGCを発見した場合、すみやかに広告掲載メディアから削除すること
(4)広告配信事業者から【内容保証を定めた条項】に反する旨を通知されたUGCを、広告掲載メディアからすみやかに削除すること
(5)【内容保証を定めた条項】に反するUGCを合理的な範囲で探知しうるNGワードリストを作成及び更新し、NGワードリストに該当するUGCが投稿等された場合に、広告掲載メディアに掲載しないこと


Level 7
投稿の都度、ユーザーに注意喚起することを求められるパターン。
ここまで来ると、サービスへの影響が・・・。
【内容保証を定めた条項】の規定にかかわらず、広告掲載メディアのユーザーが広告掲載メディアに投稿その他の方法によって送信(以下、本稿において「投稿等」という。)した情報(以下、本項において「UGC」という。)については、メディア運営者が以下の各号を遵守すること条件に、メディア運営者は何らの責任も追わないものとする。
(1)広告掲載メディアのユーザーに対し、【内容保証を定めた条項】に反するUGCを広告掲載メディアに投稿等しないよう義務付けること
(2)広告掲載メディアの性質に鑑みて合理的な頻度及び程度で、【内容保証を定めた条項】に反するUGCが広告掲載メディアに投稿等されていないことを確認すること
(3)【内容保証を定めた条項】に反するUGCを発見した場合、すみやかに広告掲載メディアから削除すること
(4)広告配信事業者から【内容保証を定めた条項】に反する旨を通知されたUGCを、広告掲載メディアからすみやかに削除すること
(5)【内容保証を定めた条項】に反するUGCを合理的な範囲で探知しうるNGワードリストを作成及び更新し、NGワードリストに該当するUGCが投稿等された場合に、広告掲載メディアに掲載しないこと
(6)広告掲載メディアのユーザーが投稿等する際に、【内容保証を定めた条項】に反するUGCの投稿等が禁止されていることを明示すること


といったところで時間切れ
「こんな規定もありじゃね?」みたいなアイデアがあれば、ぜひ教えて下さいませ〜
このエントリーをはてなブックマークに追加 Share on Tumblr

↑このページのトップヘ