雑記

守破離(しゅはり)は、日本での茶道、武道、芸術等における師弟関係のあり方の一つ。日本において左記の文化が発展、進化してきた創造的な過程のベースとなっている思想でもある。

まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
引用元:Wikipedia

去年の年末から1年弱、新卒相当の方に法務の仕事を教えるという経験をしてきました。
で、その経験を通じて気づいたことの一つに、「教える側も『守破離』に則った方がいいんじゃないだろうか」ということがあります。
「教える側にとっての守破離」をWikipediaの記載になぞらえるとこういうことになるでしょうか。
まずは教える相手に型を「守らせる」ところから始まる。
その後、その型を研究させることにより、より良いと思われる型をつくることにより既存の型を「破らせる」。
最終的にはもともとの型や、改善した型から「離れる」ことを勧める。

これを物事を教えるときの自分の行動に当てはめると、こんなことに気づきました。

その1
「守」ができたかを判断する前提として、伝えるべき型をしっかり定めておかなければならない。
人にものを教える以上、「やり方は人それぞれ」みたいな逃げ道を残すべきじゃないし、また「まずは言ったとおりにやってみて」といえるだけのクオリティの型を持つ責任がある。

その2
教える対象が、現在「守破離」のどのフェーズにあるのかを把握しなければならない。
そして、「守」ができていないのに型の改善を検討しようとしたり、型から外れようとしたときは、軌道修正をしなければならない。

その3
「守」ができるようになったら「破」へ、「破」ができるようになったら「離」へと進むよう、促さなければならない。
「教える対象が自分の伝えた型を破り、そして離れていくことを妨げる」ようなことは絶対にしてはならない。



振り返ってみると、僕が「良い上司だった」と思える人は、この「教える側の守破離」をバランスよく実践できている方だったように思います。こういう人から受ける指導って、すーっと腑に落ちるんですよね。
僕は今まで、どちらかというと「人に何かを教える」ということについて苦手意識をもっていたけど、この1年弱の経験は長年付き合ってきた苦手意識を乗り越えるきっかけになるかもなぁ、なんて思ったりしました。
このエントリーをはてなブックマークに追加 Share on Tumblr

みなさんお元気ですか?
先日、「歳相応の服装でお願いします。」というご指摘を頂きましたが、僕は元気です。


さて、毎年12月上旬に「あ、今年もやるの忘れてた」と気づくという事態が繰り返されていた法務系Advent Calendarですが、今年は無事12月突入前に思い出すことができたのでやってみたいと思います。

Advent Calendarは、ふつうの意味では「クリスマスまでの日数をカウントダウンするために使うお楽しみカレンダー」ですが、技術系トピックを中心に「12/1から12/25まで、毎日特定のトピックに関するブログエントリーを、持ち回りで自分のブログに投稿し、ひとつのサイトにリンクを集約する」というイベントとしての意味も持つに至っています。
参考:エンジニア達のクリスマス? Webで流行の「アドベントカレンダー」って何?

で、今年やろうとしている法務系Advent Calendarは、これを法務系トピックでやってみよう、というものです。
もともと母数が少ない「法務系ブログ」が対象なので、トピックは敢えて広く取って「企業法務をスムーズ・効率的に進めるためのTips」に設定しました。
法務って企業間はもちろん、企業内ですら業務Tipsが共有されていないケースが結構あって、みんなそれぞれ独自に工夫していることがいろいろあるんじゃないかと思っています。(たとえば、契約書の作り方や保管方法とか、取締役会の運営とか、コンプラ研修のやり方とか、知財権管理とか)
せっかくなので、その工夫を個人止まり・企業内止まりにせずに広く共有してみませんか?
自分では「当たり前」と思ってやっていることも、他の方にとっては目鱗なことって結構あると思います。
変わったことでなくてもOK、大したことでなくてもOK。
気軽にご参加いただければ幸いです。

【要領】
まとめ先
Adventar内の法務系Tips Advent Calendar 2013ページ

参加方法
上記ページからログインし、ブログエントリーをする予定日の「登録」ボタンをポチる。
その後、予定日に自分のブログにエントリーを上げ、上記ページに登録
→ブログを持っていない方は、Facebook、Tumblr、Google+、Twitter(はちょっときついかな?)などなどポストを公開しているSNSを利用してご参加いただいても全く問題ありません。(ウェブ上で公開さえされていればブログである必要はありません)

参加資格
弁護士さん、企業法務担当者さん、その他企業法務にちょっとでも関係している方であればどなたでも



参加者が少ないと僕が「もう来年からは絶対やらねぇ」と泣きながら穴埋めをするか、dtkさんの毎日更新ブログを僕が勝手に登録するはめになりますので、関係各位におかれましてはぜひ積極的にご参加いただきますようお願いします。
なお、参加予定のない方は、Twitter等で「たのしみだなー。」「みんな参加すべき。」「@kataxはまじドM」「加藤あいの結婚は認めません。」などのコメントを上記ページのURL付きで拡散することにより、全力でステマって頂ければ幸いです。

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

こんにちは。
新人の頃や、未経験の部署への異動直後のタイミングで、上司や先輩が「わからないことがあったら何でも聞けよ」と言ってくれたのに、いざ質問をしてみたら嫌な顔をされたという理不尽な経験をしたこと、ありませんか?

その当時は、「わからないことがあったら質問しろって言っといて、そりゃないよ。」としか思いませんでしたが、それなりに歳を重ねて質問をされる機会が多くなると、今度は嫌な顔をする方の気持ちも、少しずつ理解できるようになってきました。

そんなわけで、同じ不幸を一つでも減らすべく、質問することで評価を落としてしまうパターンと改善方法を8つにまとめてみました。
どれも当たり前かもしれないけど、昔の僕は意識できていなかったことです。(そして今でもよく忘れます。)


その1:質問する相手がおかしい
常にどんぴしゃで回答者として適任の人が捕まるとは限りませんし、そもそも誰に聞けばいいのかわからないケースも多いと思いますが、そのような場合には「●●さんは本日お休みされていて質問できないので××さんがご存知であれば教えてください」とか、「誰に質問すればいいのかわからなくて●●さんにお伺いしてしまうのですが」といった枕詞をつけて質問しましょう。

その2:質問するタイミングが悪い
声をかけることで相手の作業を中断しないようにするということに加えて、「今、●分だけお時間頂けますか?」といった感じで対応に必要な時間を最初に伝えましょう。

その3:前提を後だしする
質問をする方は、いろいろ考えたうえで質問しているのでついつい検討するために必要な前提を伝え忘れてしまいがちですが、もし質問に答えた後「いや、実は●●なので、それだと××なんです」みたいなやりとりを何度も繰り返すことになると脱力してしまいます。
前提は最初にもれなく伝えましょう。

その4:複数のことについて一度に質問する
複数の質問を一度に受けても、聞かれた方は一つ目の質問に答えているうちに残りの質問なんて忘れてしまいます。
複数の質問をするときは「いくつ質問するのかを最初に言う」ことと、「質問→答えのセットを繰り返す」ことをお忘れなく。

その5:方針について漠然とした質問をする
相手が偉い人であればあるほど、時間を無駄に使わせないためにも方針決定を丸投げすることが許されなくなります。
また、そうでない場合でもこのようなケースは自分の判断力や知識をアピールする絶好の機会である為、「どうすればいいですか?」みたいなざっくりした質問をしてしまうのはあまりにもったいない。
方針を確認するときは、選択肢と自分の意見、そしてその理由も添えて質問しましょう。

その6:何について聞きたいのかがよくわからない
当事者への経緯確認、意見が欲しい、知ってたら教えて、など、質問のパターンは様々で、質問を受ける人は、そのどれについて聞かれているかを知りません。
質問する前に「ご意見を頂きたいのですが」「ご存知であれば教えていただきたいのですが」といった一言を添えるだけで質問を受ける人の負担は軽くなります。

その7:一度説明されたことについて質問する
このような質問はしないに越したことはないのですが、その必要が出たときは、必ず「一度説明されたことを認識していること」と、「もう一度聞く理由」を質問の前に伝えましょう。
確実を期すために、とか、前提が変わったなどの合理的な理由がある場合には、このような質問はむしろプラス材料になります。

その8:調べればすぐに答えがわかることについて質問する
聞く前に調べましょう。
もう一度言います。
聞く前に調べましょう。





と、いろいろ書きましたけど、結局は「思いたった後すぐに質問しちゃうんじゃなくて、事前準備と頭出しにも気を使おうね」というだけのことでしかありません。

質問って、される方にとっては常に割り込み案件なので、おかしな質問をしちゃうと「割り込んできておかしなことを言ってる」という最悪な状態になってしまいます。
相手に媚びる必要は全くありませんが、割り込む側として、ある程度の配慮は必要だよね、というお話でした。
このエントリーをはてなブックマークに追加 Share on Tumblr

もはやどこがやってるかよりもどこがやっていないかを発表したほうが話は早いんじゃないかとすら感じる状況になってきている食品偽装事案ですが、実際に偽装をしているのは現場の仕入れ担当者だったり料理人だったりするのに、テレビカメラの前で頭を下げるのは基本的には偉い人だけです。

なぜコンプライアンス違反の事案が発生した際に、偉い人が出てきて謝るかというと、まぁ、最大の理由は、そうしないとマスコミがもっと騒いでめんどくさいことになるから、ではありますが、仮にそうでなかったとしてもコンプライアンス違反は、やっぱり偉い人が出てくる必要のある問題なのだと思います。


不正の3要素でいうところの機会の認識(チェックなし。客にもまずばれない。)も正当化(味が悪くなるわけじゃない)もある現場なんだから、プレッシャーをかけたら遅かれ早かれ不正が起こるのはもはや当然です。
これをなんとかするには、会社ぐるみでのチェックや実効性のある内部通報制度などの仕組みを構築するしかありません。
で、その仕組みを作る責任を負っているのは、あの偉い人たち。だから、偉い人が「自分の仕事の懈怠について」非難を受けるべき事案なのです。

たまたま自分が偉い人だったから普段下げない頭を下げるはめになったんじゃなく、自分がやるべきことをやらなかったから頭を下げるはめになったんです。


といったことを、「響か!数年前の響か!」と突っ込みたくなるような謝罪会見を横目で見かけて思ったりしました。
このエントリーをはてなブックマークに追加 Share on Tumblr

昨日、TwitterのTLに流れてきた「イノベーションはいつも危なっかしい」という危なっかしいインタビュー記事を読んだことがきっかけで、パーソナルデータの匿名化周りで良く出てくるトピックを整理しようと思い立ったので、せっかくなのでブログに書いてみました。

---

1.「匿名化=氏名到達性の削除」じゃない
経済産業省のガイドライン【個人情報に該当する事例】に
生年月日、連絡先(住所・居所・電話番号・メールアドレス)、会社における職位又は所属に関する情報について、それらと本人の氏名を組み合わせた情報

特定の個人を識別できるメールアドレス情報(kizai_ichiro@meti.go.jp等のようにメールアドレスだけの情報の場合であっても、日本の政府機関である経済産業省に所属するケイザイイチローのメールアドレスであることがわかるような場合等)

という例が挙げられていることもあってか、かつて個人識別性の要素として氏名到達性の有無が非常に重視されていたこともありましたが、少なくともここ最近は、氏名到達性がなくても個人識別性は生じうると考えるのが一般的だと思います。

2.匿名化には濃淡がある
一口に「匿名化」と言っても、その内容は一義的ではありません。
1でNG例として挙げた「氏名の削除」から、k-匿名化、データの抽象化・一般化など、その手法は様々であり、また匿名化のレベルも異なります。
「どこまで匿名化すれば『匿名化できている』といえるのか」をきっちり設定していないもかかわらず、いきなり「このデータは匿名化できているか?」の検証を始めてしまうと議論が華々しく宙を舞うことになります。

3.連結可能性は、匿名化ができた後の話でしかない
連結可能性、つまり、個人をバッチリ特定できる生データと、匿名化したデータを照合することができるかは、「匿名化したデータ」が、適切に匿名化できた後に初めて出てくる話でしかありません。
Suicaの案件では連結可能性が無いことが強調されたこともあり、「ちゃんと匿名化できているのか」と連結可能性の切断がごっちゃに議論されてしまっているのを見かけることがあります。

4.連結可能性は、照合キーの削除だけの問題じゃない
連結可能性を考える際には、主に「生データ」と「匿名化データ」を照合するキー(例えばユーザーIDなど)が存在するか、という観点で語られることが多いですが、電子化されたDBであれば、k-匿名化がなされていない限り、実データ(例えば乗降時間と乗降駅と性別)の照合によっても容易に連結可能なのがむしろ通常だと思います。
連結可能性の判断には、アクセス権設定やファイヤーウォールも重要になる、ということでしょうか。

5.生データのまま匿名化を担保することは、基本的にすんごく困難
基本的に、生データを生データのまま「完全に匿名化できた」という状態にすることはとても困難です。
たとえば、k-匿名化をしても、そのk個のIDが実は裏では同一人に紐付いていた、なんてことはあり得る話ですし、一般化・抽象化をしても、その一般化・抽象化の枠内に当てはまった人は一人だけ、なんてこともあるでしょう。

---
時間のある限り気づいたことをつらつら書きつらねましたが、まだまだ自分自身も鋭意勉強中の分野ですので、お気づきの点がございましたら、本エントリーのコメントか、twitter(@katax)からご指摘いただければ幸いです。
このエントリーをはてなブックマークに追加 Share on Tumblr

そう、昨日は利用規約ナイトvol.2の日でした。
前回のvol.1は、募集開始直後に満席になり参加できなかった利用規約ナイトですが、vol.2では企業法務マンサバイバルのはっしーさんにお声かけ頂き、登壇者として参加することができました。

Arts and Lawの水野先生、Evernoteの井上さんに挟まれた2番目にしゃべるという位置づけから、一体何をお話しすればいいのかしばらく悩みましたが、とにかく参加した人が聞きたいであろう話をお伝えすればそれでいいんじゃないかなと開き直って「サービス運営者目線の利用規約」というテーマを設定し、以下のような感じでお話ししてきました。

スライドを見るだけだと意味不明な箇所(特に”けもの道”とか)も多々あると思いますが、そこら辺はまぁ、説明し始めるとめんどくさいので想像力を駆使してみてください。





参加者は80人ということで、かなり準備や運営は大変だったんじゃないかと思いますが、主催者の藤川さん、イベレジの皆さん、mixi広報のお二方をはじめとした運営の皆さんのご尽力により、非常にスムーズで、かつ参加者にとって快適なイベントだったのではないかと思います。
お疲れさまでした&ありがとうございました。
このエントリーをはてなブックマークに追加 Share on Tumblr

利用規約ナイトVol.2を明日に控えて、利用規約に関するあるあるネタを1つ。

定期的に火柱が上ってウェブの大空を赤く染める、それが利用規約の炎上という存在なのですが、この週末にも一本すごいのが打ち上げられました。
そう、スクエニ メンバーズ 利用規約の改定です。

その内容は、禁止事項に「本サービスに対する不満を流布する行為」が追加されたということであり、スラドにアップされた情報によると、今月10日の利用規約改定での追加条項だそうです。

ネタがネタだっただけに、既にSNSでもスラドでも2chでもすごい勢いで今回の規約改定は非難を浴びているわけですが、僕がここで書きたいのは今回追加された禁止事項の内容についてではなく、利用規約炎上という現象について、です。


さて、今まで古くはlivedoorやmixiから、最近ではinstagramまで(そしてもちろん、今回のスクエニも)、古今東西を問わずウェブサービスの利用規約はちょいちょい炎上を繰り返しているのですが、その炎の中に目をやると、火種には大きく2種類あることに気づきます。
それはつまり、
1.目的自体に火種があるケース(オラオラ型
2.書き方に火種があるケース(うっかり型
の2つです。
→誤読や誤解に火種があるケースもあるとは思いますが、ほとんど事故のようなもので影響も軽微なのでここではスルーします。

「オラオラ型」は、たとえば「無料でサービスを提供してるんだから、これくらいのは当然ユーザーは受け入れてくれるだろう」と考えて、事業者側に過度に有利な条件を設定したり、ユーザの権利や情報を吸い上げたりしてユーザーの反発を受けてしまうケースです。また、「ばれない」と思ってこっそり変えてみたらばれちゃったというのもこのケースの一つと言えると思っています。
このパターンの炎上の原因は、一言でいえば「読みを誤った」ということに尽きます。
読みを誤ってしまった背景には、サービス事業者としては、(特に無償サービスだと)「サービスを提供して上げている」という意識を抱きがちな一方、ユーザーはむしろ「数ある他のサービスの中からこれを使ってやっている」と考えているというギャップがあることもあります。

このパターンの炎上は、「ユーザーがその目的を受け入れてくれるか」という読みを当てる必要があるため、これを防ぐことはなかなか難しいのですが、エグい規約変更を行うような場合には、リリース前に、
・当該条項の目的を公にできるか
という観点で変更内容を再確認することは、ある程度有用なんじゃないかと考えています。


また、「うっかり型」は、たとえば円滑なサービス運営のためにユーザーが著作権を持つ著作物を部分的に利用する必要があるような場合に、うっかり著作権の無制限許諾や譲渡を規定してしまってユーザーの反発を受けてしまうといったケースが該当します。
このパターンの炎上は、「条項を作る人が、依頼者が抱いていた目的を正確に把握できていなかったこと」や、「目的を規約の条項へと正確に落とし込めていなかったこと」が原因で発生します。
さらに、「サービス事業者側は目的から入り、ユーザーは規約の文言から入る」というスタンスの違いも目的と書いてあることのギャップを広げるのではないかと思っています。目的がまっとうなものであればあるほど、出来上がった規約の文言がおかしさを見逃してしまいがちということですね。利用規約に限らず、書面作成一般において、ダブルチェックを経ないと陥りがちな落とし穴です。
お決まりの弁明は「そのような意図はございません」なのですが、たとえそれが真意であったとしても「オラオラ型」の後付謝罪だととらえられがちなのもポイントですね。

もちろん、実際の利用規約の炎上のパターンは、この2つのハイブリッドであることも往々にしてあると思います。


いずれにせよ、ひとたび利用規約が炎上すると、徹底的に叩かれてしまい、サービスのレピュテーションは相当傷ついてしまうのが紛れもない現実です。
従来の考え方では、「利用規約はサービス事業者側に有利なことだけを書いておく」「利用規約を表に出すのは最低限に留める」となりがちでしたが、今後はこのスタンスを徐々にでも改めていく必要があるのだろうな、なんてことを感じた週末でした。
このエントリーをはてなブックマークに追加 Share on Tumblr

4回にわたって続けてきた利用規約比較シリーズですが、いよいよラストの第5回です。

その1はこちらから、その2はこちらから、その3はこちらから、その4はこちらからどうぞ。

最終回のテーマは、個人情報の第三者提供+αです。
今回もプライバシーポリシー(PP)を含めて比較します。

1.個人情報の第三者提供
GREE
PP3
当社は、ユーザーに関する集積された又は個人特定されていない本情報を、広告主、出版者、ビジネスパートナー、出資者、その他の第三者と共有する場合があります。又、当社は以下の場合に本情報を開示することがあります。
  1. 当社が、適用される法令(情報提供者の居住国以外の法令を含みます。)又は法的手続を遵守するために開示が必要であると合理的に判断した場合。
  2. 開示することが、身体の受傷若しくは財産の毀損を防ぐため、又は当社、当社の子会社及び関連会社、ユーザー若しくはその他の情報提供者の運営、権利、プライバシー、安全性若しくは資産を保全・確保するために必要な場合(本サービスの提供に適用される条項を実施するため、又は当社が利用可能な救済策を求め、若しくは当社が被る可能性のある損害を限定するために必要な場合を含みます。)。
  3. 当社が第三者のサービスプロバイダーのサービスを利用して、ウェブホスティング、データ分析、支払処理、クレジットカード処理、受注処理、インフラ及びネットワークの供給、ITサービス、サポート及びメンテナンス、顧客サービス、メール配信サービス、監査サービスその他類似のサービスを提供する場合。
  4. 当社が、組織再編、合併、売却、合弁事業、譲渡、移転又は当社の事業、資産若しくは株の全部又は一部の処分をする場合(破産又は類似の手続きに関連して行う場合を含みます。)。
  5. 公衆衛生の向上又は児童の健全な育成のために開示が必要な場合。
  6. 国の政府機関、地方公共団体、公共機関又はこれらの機関の委託を受けた者から協力を要請された場合(情報提供者の居住国以外の政府機関、団体、公共機関又はこれらの機関の委託を受けた者を含みます。)。
  7. 情報提供者が、当社に対し、情報開示に関し明示の同意を与えた場合。


4−2
ユーザーの同意なく、機密保持契約を結んだ協力企業以外にユーザーの個人情報を開示することはありません。ただし、以下の場合に、個人情報を開示することがあります。
  1. 法令に基づいて、開示が必要であるとグリーが合理的に判断した場合
  2. 人の生命、身体または財産の保護のために必要がある場合であって、本人の同意を得ることが困難であると判断した場合
  3. 公衆衛生の向上または児童の健全な育成の推進のために特に必要がある場合であって、本人の同意を得ることが困難であると判断した場合
  4. 国の機関もしくは地方公共団体またはその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合であって、本人の同意を得ることにより当該事務の遂行に支障を及ぼすおそれがあると判断した場合
  5. 合併その他の事由によりサービスの主体が変更され、サービスの継続のため個人情報を移管する必要があると判断した場合
  6. 本サービスの利用料金の支払いについて、グリーが提携する決済代行会社、クレジットカード会社等に対して、クレジットカード決済等に必要な範囲内、およびクレジットカード決済等の不正が疑われる場合等において、その真偽を確かめる為に必要な範囲内で提供する場合。

mobage
PP3
当社は、以下に定める場合には、個人情報を第三者に提供することができるものとします。
  • オークションサービスにおいて、出品者、落札者双方に落札者の決定したこと、落札価格、相手方の電子メールアドレスを電子メールで連絡し、また、出品者及び落札者が相手方の入力した氏名または法人名、住所、電話番号並びに代表者名および担当者名(法人の場合)を閲覧できるようにする場合
  • 本人の同意がある場合
  • 裁判所、検察庁、警察、税務署、弁護士会またはこれらに準じた権限を持つ機関から、個人情報の開示を求められた場合
  • 保険金請求のために保険会社に開示する場合
  • オークション会員の方が当社所定の取引支援用ツールを利用した場合で、出品者または落札者に開示する場合
  • 当社または出品者に対し支払うべき料金その他の金員の決済を行うために、金融機関、クレジットカード会社、回収代行業者その他の決済またはその代行を行う事業者に開示する場合
  • 当社が行う業務の全部または一部を第三者に委託する場合
  • 当社に対して秘密保持義務を負う者に対して開示する場合
  • 当社の権利行使に必要な場合
  • 合併、営業譲渡その他の事由による事業の承継の際に、事業を承継する者に対して開示する場合
  • 個人情報保護法その他の法令により認められた場合
  • その他当社の各サービスにおいて個別に定める場合


第6条
  1. 当社は、以下に定める場合には、モバゲー会員の個人情報を第三者に提供することができるものとします。
    1. モバゲー会員の同意がある場合
    2. 裁判所、検察庁、警察、税務署、弁護士会またはこれらに準じた権限を有する機関から開示を求められた場合
    3. モバゲー会員が当社に対し支払うべき料金その他の金員の決済を行うために、金融機関、クレジットカード会社、回収代行業者その他の決済またはその代行を行う事業者に開示する場合
    4. 当社が行う業務の全部または一部を第三者に委託する場合
    5. 当社に対して秘密保持義務を負う者に対して開示する場合
    6. 当社の権利行使に必要な場合
    7. 合併、営業譲渡その他の事由による事業の承継の際に、事業を承継する者に対して開示する場合
    8. 個人情報保護法その他の法令により認められた場合
  2. 2011年10月27日以降に新たに会員登録したモバゲー会員またはスマートフォン端末(Apple Inc.が提供するオペレーティングシステムソフトウェア「iOS」及びその後継オペレーティングシステムソフトウェア、Google Inc.が提供するオペレーティングシステムソフトウェア「Android」及びその後継オペレーティングソフトウェア、又はその他当社が別途指定するオペレーティングシステムソフトウェアを搭載した端末をいいます。)を介してMobageの利用を開始したモバゲー会員は、かかるモバゲー会員のうち当社が定める方法により株式会社エヌ・ティ・ティ・ドコモ(以下、「ドコモ社」といいます。)の利用者であると認定する者のメールアドレスその他認証IDを含むモバゲー会員記述情報、MobageのユーザID、ニックネーム、血液型、誕生日、地域、職業、趣味、その他Mobageのサービスを利用する上でモバゲー会員が記述、登録した情報を、当社がドコモ社に対して提供することを承諾します。ドコモ社に提供された情報は、ドコモ社により、ドコモ社の定める「お客様の個人情報に関するプライバシーポリシー」に従って管理され、当社は一切責任を負いません。(参考:ドコモ社の「お客様の個人情報に関するプライバシーポリシー」)
  3. 当社は、モバゲー会員に対し、第三者の広告又は宣伝等のために電子メールその他の広告宣伝物を送信できるものとし、モバゲー会員はこれを予め承諾するものとします。


前述の通り、GREEのPPは、その対象情報を個人情報保護法上の個人情報には限定していないため、本情報のうち一定の情報については柔軟に第三者提供することを定めています。
そもそも個人情報保護法上の個人情報のみを対象としているPP下では、個人を特定できない情報(統計情報など)は対象とされないわけで、広くユーザーに関する情報をPPの対象としつつ、情報の性質によって保護のレベルを分けているという点でも、GREEのPPは旧来のPPと一味違うといえると思います。
ところで、DeNAは「当社に対して秘密保持義務を負う者に対して開示する場合」「当社の権利行使に必要な場合」というそれ、なんでもいけますやん・・・規定を設けていますね。へぇ。
また、DeNAはドコモユーザーだと判断した会員の情報をドコモに提供するそうですが、一切責任を負わないそうです。ふぅん。

また、両者とも、サービス主体の移管を念頭に置いた規定を設けています(GREEはPP3-4や利用規約4-2の5、mobage規約の第6条4項g)が、包括承継の場合はともかく、事業譲渡の際にユーザー情報を円滑に引き継ぐことができるかはDDの際に必ず気にされることではあるため、このような規定があるとそんな場合に役に立つのかもしれません。

いずれにしても、ドコモのプライバシーポリシーにおける第三者提供条項のような「どのような情報を」「誰に」「何を目的として」提供するのかをがっちり書いてあるようなPPと比較すると、物足りない感はあります。
GREEのPPは、利用目的の条項で第三者提供に関する記述も一部含んでいるので、せっかくなら、第三者提供の条項を利用目的と統合しちゃえばいいのに、なんて思ったりしました。

また、GREEのPP3の柱書が「個人をユーザーに関する集積された情報」を「個人特定されていない本情報」を「又は」でつないでいる点や、GREEの利用規約4−2の柱書第1文は(反対解釈をすると)機密保持契約を結んだ協力企業には同意なく個人情報を開示すると読める点については、純粋に文章構造の問題だとは思いますが、やや違和感を覚えました。


2. 国外の子会社、関連会社又は第三者への情報の移転
GREE
PP4
当社は、情報提供者の本情報を、情報提供者の居住国以外の国に存在する当社の子会社、関連会社(グリー株式会社、GREE International, Inc.、GREE Beijing, Co., Ltd、GREE Korea Inc.、GREE Singapore Pte. Ltd.、GREE UK Limited、GREE Netherlands B.V.、GREE Brazil Servicos e Consultoria de Internet LTDA. , GREE Middle East FZ-LLC、GREE Canada, Ltd.を含みます。)又は当社のビジネスパートナー及びサービスパートナー(携帯電話会社、決済代行業者及びコンテンツ提供者を含みますがこれらに限られません。)に移転させることがあります。欧州に居住している情報提供者は、自らの本情報が居住国以外の国及びEUの外部の国(米国、日本などのEUと同等の本情報保護のための法的フレームワークを有しない国を含みます。)に移転される場合があることを認識する必要があります。この本情報には、決済代行会社その他のビジネスパートナーへの移転が行われた日時等、その開示目的により、取引及び支払いに関する詳細な本情報が含まれる場合があります。

情報提供者は、本サービスの利用のため本情報を提供することにより、以下に同意しているとみなされるものとします。
  1. 本プライバシーポリシーに従った、当社による本情報、の獲得、保存、処理、移転及び保有
  2. 当社又はその関連会社が設備(第三者が運営しているクラウドストレージやクラウドコンピューティングを含みます)を利用することが出来るか、当社がサービスプロバイダーと契約しているいかなる国における、情報提供者の本情報の保存及び処理
  3. 米国を含む、情報提供者の居住国外の国(情報提供者の居住国とは異なるデータ保護規則を有する可能性がある国もあります。)への本情報の移転


GREEは、単なる開示だけでなく、第三者への情報の移転についても項目を設けています。
EUデータ保護指令関係ですね。
つまり、僕にはこの項目について、何も語れることはないということでもあります。
だれか、たのむ!

なお、本項以外にも、GREEのPPは9項のドイツの未成年者対応、10項のカリフォルニア民法に基づく情報開示請求、末尾のオーストラリアやカナダの特則など、国際色豊かな規定が盛りだくさんなので、各国のプライバシー法制を垣間見る、いいのぞき窓になっているかもしれませんが、実際のところよくわかりませんごめんなさい。




さて、GREE及びmobage(DeNA)の利用規約比較シリーズはこれで一応終わりなのでまとめ的なものも書いておきます。
まず、前提として、僕は今までGREEの規約もmobageの規約もちゃんと本腰を入れて読んだことはありませんでした。そのため、比較をするにあたっては、「きっと両社とも研究しあって似たような内容になっているんだろうな」という先入観を抱いていました。
しかし、実際に比較してみると、両者の規約・PPは全く違っていることがわかったのです。ざっくりと言ってしまうと、GREEは国際的に統一した規約を適用すること前提にかなりがっちり作りこんでいる一方で、mobageはあっさりとした内容にとどまっていたのです。

僕が以前、約款ビジネスを営む通信事業者で勤務していたころ、約款は契約法務とは別の部門が面倒を見ていました。
彼らは、約款のどこに何が書いてあるのかもがっちりと把握し、ビジネススキームや法規制が変わるたびに即座に約款をメンテナンスしていました。まさに、生き字引です。(もちろん、彼らはそれだけをやっていたわけではありませんが)

もちろん相応のコストは必要になったでしょうが、そうでもしなければ日々変わるビジネスや法規制に足並みをそろえた約款のメンテナンスなんて、正直やってられなかったわけです。利用規約は、作るよりもメンテナンスをし続ける方がずっと大変ですから。
それを考えると、もしかしたら、GREEも同じように利用規約やPPの面倒を見る体制や仕組みを持っているのかもしれないな、と思ったりしました。


最後に、今回の比較をするまで意識すらしていなかったこと、比較して初めて気づけたことが多かったので、今後も利用規約比較はぼちぼちと続けて行こうと思います。
次にやるとしたら、LineとCommとカカオトークかな?

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

ちょっと間が空いてしまいましたが、その4です。
その1はこちらから、その2はこちらから、その3はこちらからどうぞ。

さて、今回のテーマは個人情報。
両社とも、利用規約に個人情報に関する規定を設けてはいますが、やはりメインはプライバシーポリシー(PP)であり、PPを外して個人情報関連の規定を比較することにあまり意味は無いので、PPも比較対象に含めます。
なお、GREEのPPはこちら、DeNAのPPはこちらです。

ちなみに、これは両社とは無関係な一般論ですが、ある程度の規模以上の会社においては、PPは個人情報保護や情報セキュリティを専門的に取り扱う部門が作成・メンテナンスし、利用規約は法務部門が作成・メンテナンスしていることがあります。
そして、このようなケースで、必ずしも両社の発想や温度感が共通していない(平たく言えば、お互いに「あいつらほんとわかってねぇな」と思っている)ことから、利用規約とPPの内容にズレが生じてしまうことがたまにあったりなかったりします。
繰り返しますが、これは一般論ですからね!

1.保護の対象とする情報
GREE
PP1柱書
情報提供者は、本サービスの利用及び当社とのコミュニケーションに際しては、名前、住所、電話番号、メールアドレス等の個人を特定し得る情報の提供を求められる場合があります。本サービスの利用に関連して、当社では、その他の情報、即ちブラウザ情報、サーバーログファイル、クッキー経由で取得された情報、ピクセルタグその他の技術情報、並びに人口統計的情報その他の集合情報等の個人を特定しない情報も取得する場合があります。当社は、これらの情報(以下「本情報」といいます)を本プライバシーポリシーに従って取り扱います。当社は、かかる本情報を本プライバシーポリシーに定める目的のために利用することができます。 

mobage
PP1
個人情報とは、個人に関する情報であり、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。)を指します。
当社(株式会社ディー・エヌ・エー 所在地:〒150-8510 東京都渋谷区渋谷二丁目21番1号 渋谷ヒカリエ)は、個人情報を収集することがあります。当社は、個人情報の利用目的を公表します。


GREEはブラウザ情報やログファイル等、さらには個人を特定できない統計情報までもPPの適用対象としています。これは、日本のウェブサービスとしてはかなり珍しいケースなのでは無いでしょうか(全く検証していないので、個人的な感想です)。
対してDeNAは、生存要件を含まない個人情報をPPの適用対象としています。GREEと比較してしまうと狭く感じるかもしれませんが、むしろこちらの方が圧倒的な主流派だと思います(個人的な感想であることについて同上)。

なお、データ蓄積量の増大や、データ解析技術の向上とともに「容易に照合」の範囲が拡大し、旧来の「個人情報」の範疇には入らなかった情報が個人情報に該当する可能性は高くなっており、その意味で、定義を変えない場合でも実務上の対応が必要になる情報が拡大する可能性は今後高まってくるはずです。もし実務上、cookieや抽象化した情報も個人情報として取り扱うのであれば、GREEのようにいっそ明示してしまった方が好ましいことは間違いと思います。
また、Google Analyticsはトラフィックデータ収集のためにcookieを使用している旨をPPに明示することを求めており(利用規約7参照)、このような流れが加速すれば、外部サービスとの連携のためという理由でPPの適用対象の書きぶりが変化することもあるかもしれません。


2.個人情報の取得・収集
GREE
PP1
  1. 本情報を取得する場合
    当社は、以下の場合に情報提供者の本情報を取得します。
    1. 本サービスに入会又は登録する場合
    2. 本サービス内でプロフィールページを作成・編集する場合
    3. ユーザーが本サービスを利用する場合(ボタンのクリック、アプリケーションのダウンロード又はリンクを開く行為を含みます)
    4. 当社のサポートサービスに対して連絡をした場合
    5. アプリケーションを開発するために当社に登録をした場合
    6. 情報提供者のインターネットブラウザにあらかじめ設定されている頻度で、インターネットブラウザの履歴情報フォルダから情報を取得する場合。
    7. ウェブブラウザのクッキーから情報を取得する場合。
      「クッキー」とは、文字列が記入された小さいデータファイルのことで、情報提供者がアクセスするウェブサイトから、当該情報提供者のブラウザに送信され、そのブラウザによって情報提供者のコンピューターのハードドライブ等の記憶装置に保存されます。情報提供者のシステムにクッキーが保存されることで、当社は簡便に本サービスをユーザーに合わせてカスタマイズし、本サービスの利便性を向上させることができます。また、この機能は、当社が問題を検証し、本サービスを管理するためにも役立ちます。クッキーを無効にしたい場合は、クッキーの無効化に関する設定をしてください。ただし、本サービスの一部の機能が正常に機能しなくなることがあります。
    8. ピクセルタグ、ウェブビーコン、クリアGIFその他の類似技術により取得する場合。
      当社は、本サービス及び当社が情報提供者に対して発行するHTML形式のメールに関連して、とりわけユーザーやメール受領者の反応履歴を確認するために、これらの技術を利用する場合があります。これには、当社のマーケティング活動の成果を評価する場合並びに使用率及び回答率に関する統計を作成する場合を含みます。

  2. 本サービスのユーザーより取得する本情報
    1. ゲストユーザー登録 (当社の分類による制限付きアプリケーションを利用するために登録するユーザー)
      登録時に取得することがある本情報:ユーザーID、ユーザーデバイスID、登録の種類、会員のステータス、ユーザーがGREE又はOpenFeintのサービスを過去に利用したかどうか、登録の日時、IPアドレスから確定された居住国、IPアドレスから確定された所在地、選択した言語及び選択した住所に基づいたタイムゾーン。ゲストユーザーがSNSサービスの使用を選択した場合は、当社は生年月日の情報を取得することがあります。もし生年月日(及びユーザーID)を提供しない場合は、ゲストユーザーはSNSサービスを使用することは出来ません。
    2. 制限ユーザー登録(当社の分類による制限付きアプリケーション及びSNSサービスを利用するために登録するユーザー)
      登録時に取得することがある本情報:ゲストユーザーから登録時に取得することがある情報と同様の本情報、名前、性別、ニックネーム、電子メールアドレス、パスワード、誕生日等の会員情報(プロフィール画像等、任意に提供した本情報を含みます。)、制限ユーザーのユーザーとしての登録日。これらの本情報を用いてユーザーのプロフィールが作成されます。
      • ユーザーが登録時に既に当社の他のプラットフォーム(OpenFeintを含みます)、若しくは子会社の製品又はサービスの会員である場合、かかるその他のプラットフォーム、製品、及びサービスのユーザーの会員情報は、当社に伝えられ、登録フォームに転送される場合があります。
      • ユーザーが登録時にFacebook Connectを使用することを許諾し、ユーザーのFacebookのID及びパスワードを入力した場合、当社は、名前、ニックネーム、電子メールアドレス、Facebook ID、誕生日、性別、プロフィール画像その他の会員情報(ユーザーのFacebook上の友達)を含む、ユーザーのFacebookのアカウントの本情報にアクセスし、登録フォームにかかる本情報を転送する場合があります。
      • 当社は、ユーザーが登録フォーム上に送信した本情報を保持します。当社が取得した本情報が、別途Facebook Connectと同期されることはありません。ただし、Facebook Connectにより取得された本情報が、登録の要件を満たすのに十分ではない場合は、ユーザーが登録フォームに自分で入力した本情報と統合される場合があります。
    3. 認証ユーザー登録(本サービスのすべての機能を利用するために登録するユーザー)
      登録時に取得することのある本情報:制限ユーザーが登録時に取得することのある本情報と同様の情報、電話番号、誕生日(制限ユーザー登録時に取得済でない場合)。
      • 当社は、ユーザーの電話番号の取得に当たり、身元の確認及び複数のユーザー登録の防止のために、取得した電話番号をハッシュ化されたデータに変換しますが、入力された電話番号そのものは保持しません。
    4. 登録後に全てのユーザーから追加的に取得される本情報
      当社は、ユーザーによるサービス登録後に、ユーザーのログイン日及び関連するデバイスのIDを取得することがあります。また、友人への招待メール、日記、コミュニティ、掲示板、プロフィール写真、その他の写真、ユーザーメール、ユーザーの短いコメントに含まれているか、それらにおいて利用可能である本情報を取得することがあります。当社は、IPアドレス、ユーザーが利用するデバイスの種類、それらデバイスの利用言語、利用するブラウザの種類、バージョン、アクセス歴、利用するアプリケーションのバージョン情報を取得することがあります。
      当社は、本サービスを通じて又は本サービスに関連して発生した支払代金を集金する第三者による支払サービス(支払集約事業者を含みます。以下「決済代行会社」とします)を利用することがあります。ユーザーが支払いを行いたい場合、当社ではなく、決済代行会社(又は決済代行会社のサービスプロバイダー)の運営するウェブページ(以下「決済代行会社のページ」とします)に移動させられる場合があります。この場合、領収書発行のために、決済代行会社に対してユーザーの電子メールアドレスが提供されます。クレジットカードやデビットカードの番号、パスワード、銀行口座、電信送金の情報を含む、ユーザーが決済代行会社のウェブページ上で提供する全ての情報は、決済代行会社により取得されるものであり、当社はこれを取得しません。決済代行会社が当社に支払いについて問い合わせた場合、当社は、以下の本情報を提供する場合があります:問い合わせ番号、ユーザーが利用したサービスの内容、支払日、ユーザーの名前、住所及び連絡先、GREE ID,ユーザー登録日、カスタマーサポートへの連絡回数、購入活動、アカウントへのログイン・アクセス。
      当社は、ユーザーの「ライフログ」その他のアクセスログにより取得された本情報を取得することがあります。ライフログとは、ユーザーが利用するサービス及びアプリケーション、購入する製品及びサービス、訪問するウェブページ及び広告、並びにこれらを利用した時間帯に関する本情報を指します。
    5. ユーザーが選択した場合に取得される本情報
      アドレス帳同期機能又は第三者のサービスへの接続機能により、他のユーザーを検索することに同意した場合、当社は、ユーザーの携帯電話に登録されているメールアドレスを取得することがあります。もし、取得されたアドレスが、GREEユーザーとして既に登録されているアドレスと合致した場合、当社は、ユーザーに対し、当該アドレスと関連付けられているニックネームとアバタ―を表示します。
    6. ユーザーが本サービスを経由して、第三者によるサービスに接続する場合に取得される本情報
      ユーザーが本サービスを経由して第三者によるサービスに接続した場合、当社は当該第三者によるサービスに接続するために使用されたID及びパスワードを取得することがあります。当社は、本サービスが当該第三者によるサービスに接続した後、これらの本情報を保持することがあります。
  3. 就職希望者より取得する本情報
    就職希望者から取得する本情報の内容及びその情報の使途については、採用応募に関するプライバシーポリシーを参照して下さい。
  4. 1.4. 本サービスのデベロッパーより取得する本情報
    デベロッパーが当社のデベロッパーセンターに登録した場合、当社はデベロッパーの名前、電子メールアドレス、電話番号を取得します。
  5. 当社のウェブサイトにアクセスした者から取得する本情報
    当社のウェブサイトにアクセスした場合:当該アクセスをした者のIPアドレスその他のアクセスログ。ユーザー登録をしたユーザーが、当社のウェブサイトにアクセスした場合:本サービスへのアクセスログや利用履歴(情報提供者が利用されたサービス、ソフトウエア、購入された商品、ご覧になったページや広告の履歴情報、利用時間帯、利用の方法、利用環境)、情報提供者のIPアドレス、cookie情報、位置情報、端末の個体識別情報などの履歴情報及び特性情報を、本プライバシーポリシー第2項において後述する目的に加え、当社のサービスの品質向上や情報提供者の嗜好性把握、広告表示の最適化の目的で、当社または当社と秘密保持契約を結んだ第三者(コンテンツ・情報提供者、広告主、出版社)が収集し、共有する場合があることを、予めご承諾頂きます 。このような情報取得を望まれない場合は、お問い合わせフォームから当社に通知してください。。当社は第三者が取得した本情報を情報提供者のクッキー情報と照合、紐づけて共有することによって、さらなる広告表示の最適化を行います。
  6. 広告主から取得する本情報
    当社ウェブサイトから、広告出稿または広告枠販売代行(すなわち、顧客を代行し、広告を売買する販売会社により提供されるサービス)のお申し込みをする場合:会社名、担当部署名、担当者名、住所、メールアドレス、及び電話番号等の連絡先。

mobage
なし
※第6条(個人情報について)1項に「モバゲー会員になろうとする方は、当社所定の情報を当社に登録する必要があります。」との規定はある。


プライバシーポリシーにおいて、どのような個人情報を収集するかに加え、どのような場面で個人情報が収集されるのかを明示しているケースは現時点では決して多くはありませんが、特にユーザーの登録等を経ずにSPが能動的に情報を情報を収集するようなケースでは、ユーザーが情報を収集されていること自体に気づけないことも少なくないため、どのような場面で個人情報が収集されるのかを明示することはユーザーにとって好ましいことであるのは間違いないと思います。
ただその反面、運用が変更された際にPPも追随しなければならないため、個人情報保護部門が事業部門にがっちりと食い込んでいないとなかなか怖くて踏み込めない領域でもあります。
この点、GREEは非常に高いレベルで特定を行っていますね。
GREEのように、個人情報を収集するケースを明示しているPPとして、GoogleのPPがありますが、GREEのPPは、Googleよりもさらに特定を徹底しているように感じます。

3.個人情報の利用目的
GREE
PP2
  1. プロフィールページの作成
    名前、性別、写真、誕生日その他本サービスに登録された本情報は、各ユーザーのプロフィールページを作成するために利用する場合があります。ユーザーは、本サービスを利用することにより、自らがプロフィールページに登録したこれらの本情報及びコンテンツが他のユーザーに閲覧可能となることに同意するものとします。メールアドレスと電話番号は、プロフィールページには表示されません。
  2. ユーザー間のコミュニケーション
    本サービスには、ユーザー間のコミュニケーションを促進するために、友人への招待メール、日記、コミュニティ及び伝言板等の機能があります。ユーザーはこれらの機能を利用することにより、他のユーザーとのコミュニケーションのために様々な本情報を発信することができます。ユーザーがユーザープロフィール以外のページに任意に入力した情報は、本サービスにより、ユーザーがかかる本情報の表示を制限できる場合を除き、ユーザーその他の者に閲覧可能となる場合があります。ただし当社は利用規約に基づきかかる本情報の監視を行うことができます。ユーザーがこれらの機能により名前、連絡先その他の本情報を公開することは、アプリケーションデベロッパーである第三者による、アプリケーション配布や保守の目的のためのかかる本情報の利用につながる場合があります。
  3. 当社とユーザーとのコミュニケーション
    当社及びそのサービスプロバイダーは、ユーザーとのコミュニケーションの手段として、本サービスに登録されたユーザーのメールアドレス及び端末固有の識別子を利用する場合があります。これには、例えば、ユーザーに対して、本サービスに関する情報、ユーザーが関心を有する可能性があるプロモーション情報(ユーザーの好みに最適化された広告等)及び日々の「新着お知らせメール」を提供することを含みます。当社及びそのサービスプロバイダーはまた、ユーザーのメールアドレス及び端末固有の識別子を利用して、本サービスに関する質問に回答することがあります。
  4. ユーザー以外とのコミュニケーション
    当社及びそのサービスプロバイダーは、ユーザーが本サービスに新しい友人を招待するために本サービスの招待機能を利用する際、ユーザーが本サービスに登録した名前、メールアドレス、写真、端末固有の識別子その他の本情報を利用する場合があります。この場合、登録済みのプロフィールの写真は、招待メールの受取人に送信されたメールに含まれるURLから誰でも閲覧可能となります。
  5. プロモーション目的
    当社及びそのサービスプロバイダーは、当社に登録されたユーザーのメールアドレスその他の本情報を、当社又は第三者の製品及びサービスのプロモーションを目的として利用する場合があります。これらのプロモーションはユーザーの性別や年齢、ご利用態様別に行われることがあります。
  6. サービスの改善
    当社及びそのサービスプロバイダーは、サービスの品質の改善、ユーザーの好みの把握及び広告表示の最適化のために、集合化し加工した本サービスのアクセスログや履歴の形式での統計情報等の本情報を利用する場合があります。また当社は、サービス利用度の計算、サーバーの問題の検証及びサービスの管理等のために、IPアドレスを使用する場合があります。
  7. その他任意に提供された情報の利用
    当社又はそのサービスプロバイダーは、本サービスに関連して、ユーザーに調査、キャンペーンその他の活動に関連する本情報の任意による入力を依頼する場合があります。ユーザーがかかる本情報を提供した場合、提供された本情報は、かかる調査、キャンペーン、監査、その他の活動に関連する本サービスを提供するために利用され、また本プライバシーポリシーの他の箇所に記載された用途及び当該本情報を取得する際に当社が明示した用途に利用される場合があります。
  8. 広告取引支援サービスの提供のための利用
    当社及びそのサービスプロバイダーは、情報提供者に代わって広告を購入又は販売する際に、広告取引支援の運営者と取引を行うため、必要に応じて、当該広告取引支援の運営者に本情報を提供する場合があります。
  9. その他の本情報
    当社は、問い合わせへの回答時又はその他の本サービスの提供時に、本情報を取得する場合があります。この本情報は、本プライバシーポリシーに記載された用途に利用され、また当該本情報を取得する際に当社が明示した用途に利用される場合があります。

mobage
PP2
  • オークション、ショッピングモール、コンテンツその他の情報提供サービス、システム利用サービスの提供のため
  • 当社及び第三者の商品等(旅行、保険その他の金融商品を含む。以下同じ。)の販売、販売の勧誘、発送、サービス提供のため
  • 当社及び第三者の商品等の広告または宣伝(ダイレクトメールの送付、電子メールの送信を含む。)のため
  • 料金請求、課金計算のため
  • 本人確認、認証サービスのため
  • アフターサービス、問い合わせ、苦情対応のため
  • アンケートの実施のため
  • 懸賞、キャンペーンの実施のため
  • アフィリエイト、ポイントサービスの提供のため
  • マーケティングデータの調査、統計、分析のため
  • 決済サービス、物流サービスの提供のため
  • 新サービス、新機能の開発のため
  • システムの維持、不具合対応のため
  • オークションサービスにおける会員記述情報の掲載のため
  • その他当社の各サービスにおいて個別に定める目的のため


第6条3項
  • ゲーム、オークション、ショッピングモール、コンテンツその他の情報提供サービス、システム利用サービスの提供のため
  • 当社及び第三者の商品等(旅行、保険その他の金融商品を含む。以下同じ。)の販売、販売の勧誘、発送、サービス提供のため
  • 当社及び第三者の商品等の広告または宣伝(ダイレクトメールの送付、電子メールの送信を含む。)のため
  • 料金請求、課金計算のため
  • 本人確認、認証サービスのため
  • アフターサービス、問い合わせ、苦情対応のため
  • アンケートの実施のため
  • 懸賞、キャンペーンの実施のため
  • アフィリエイト、ポイントサービスの提供のため
  • マーケティングデータの調査、統計、分析のため
  • 決済サービス、物流サービスの提供のため
  • 新サービス、新機能の開発のため
  • システムの維持、不具合対応のため
  • 会員記述情報の掲載のため


GREEはPPにのみ利用目的を記載し、mobageは、DeNAのPPとmobageの利用規約の両方に利用目的を記載しています。
PP同士の比較で言うと、GREEは、「コミュニケーション」「プロモーション」「サービス改善」「広告」という大きなくくりをした上で、各項目の中で詳細に説明を加えている一方で、DeNAは、オーソドックスな単純列挙方式を採用しています。
また、GREEは「利用目的」と「収集する個人情報」とを結びつけており、その意味で自律の度合いが強い「新しいPP」と言えるのではないかと思います。
ただ、GREEのPPの利用目的は、目的を示す部分が文章中にとけ込んでしまっているため、結局のところ利用目的が何であるのかは一目で分かりづらくなってしまっている印象を受けます。

なお、DeNAは、一見PPの「その他当社の各サービスにおいて個別に定める目的」として利用規約で利用目的を追記しているのかと思いきや、その実態はほとんどPPのミラー(ゲームを追加している)なので、PPの利用目的にmobageを組み込んでしまい、利用規約からは利用目的を削除してしまった方がわかりやすくなるのではないかと感じます。


長くなってしまったので一旦ここで切ります。
次回は個人情報の続きで、第三者提供とGREEの追加条項もろもろを見てみます。

ところで、もしGREEのご担当者がこのエントリーをご覧になっていましたら、PPに「本サービス」の定義(前文の「GREEのオンラインソーシャルネットワークサービス」?)がない点について、意図通りかご確認いただければ幸いです。

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

その1はこちらから、その2はこちらからどうぞ。

GREEとmobageの利用規約比較の第3回目は、著作権の帰属と許諾についてです。
著作権の帰属とSPに対する利用許諾については、古くはライブドアブログやmixi、最近ではinstagramと、古今東西を問わずやたらと炎上する論点なのですが、我が国を代表する2大SNSは、ここのところをどう処理しているのでしょうか。

1.ユーザーが創作した著作物の著作権
GREE
5−2 ユーザーが本サービスを利用して投稿・編集した文章、画像、映像(動画)等の著作権については、当該ユーザーその他既存の権利者に留保されるものとします。ただし、本サービスを利用して投稿・編集された文章、画像、映像(動画)等については、グリーおよびグリーと提携するサイトまたはその他の媒体・サービスにおいて、グリーが必要と判断する処置を行った上で、グリーが利用できるものとします。ユーザーは、本項に基づくグリーによる著作物の利用について、著作者人格権を行使しないものとします。

mobage
なし


・・・読んで探し、「著作」をキーワードに検索し、「権」をキーワードに検索しました。
でも、みつからないんです。モバゲー会員規約には、ユーザー著作物の著作権の帰属について、特に定められていないんです。
GREEの規約との比較対象がモバゲー会員規約であっていたのか、不安になってきました。
でも、モバゲー会員として日記を書いたりメッセージをやり取りする際に適用されるのはこの規約であるはずなのですが・・・。
となると、mobageのユーザーがアップロードしたコンテンツは著作者であるユーザーに帰属し、DeNAには移転はおろか、許諾もされないということになります。
どこまで杓子定規に著作権法を適用するかによりますが、例えばサーバストレージの多重化やUIの都合で行う抜粋などのために「事業運営上必要な範囲での著作物の利用許諾(と著作者人格権の不行使)」程度は明示しておくのが主流であることからすると、珍しいケースであるように思います。

かたやGREEは、著作権をユーザーに留保しつつ、「一見制限をかけているように見えるけど、実際にはほとんどなんでもできる利用許諾」を受けています。
GREEの利用規約がユーザー著作物の著作権処理の面でやり過ぎという評判は少なくとも私は聞いたことはありませんし、ユーザーが著作権の譲渡をすることはほとんどないであろうということからすると、ユーザー著作物の著作権処理についてはユーザーに留保しつつ、あっさりと利用許諾を受けておくのが現時点での正解なのかもしれません。
ただ、これはあくまで利用規約の規定ぶりの話であって、これを文言通り最大限に活用してユーザー著作物を自由自在に利用してしまうと、利用規約が磔にされて炎上するのは明らかなわけですが。


2.SP著作物の著作権の許諾
GREE
5−3 前項に定めるユーザーが本サービスを利用して投稿・編集した文章、画像、映像(動画)等についての著作権を除き、本サービスおよび本サービスに関連する一切の情報についての著作権およびその他知的財産権はすべてグリーまたはグリーにその利用を許諾した権利者に帰属し、ユーザーは無断で複製、譲渡、貸与、翻訳、改変、転載、公衆送信(送信可能化を含みます)、伝送、配布、出版、営業使用等をしてはならないものとします。

9−3 ユーザーに対して提供されるサービスのうち、「ゲットする」「買う」「購入する」等の表示がなされている場合でも、ユーザーはサービス内で定められた範囲の利用権を有するのみであって、所有権、知的財産権等の権利を取得するものではありません。

mobage
第11条コンテンツ使用許諾の条件
  • モバゲー会員は、本サービスのコンテンツを電気通信回線を通じて当社の指定する設備に接続することによって当社の定める範囲内でのみ使用することができるものとします。
  • 本サービス内で当社が提供する全てのコンテンツに関する権利は当社が有しており、モバゲー会員に対し、当社が有する特許権、実用新案権、意匠権、商標権、著作権、ノウハウその他の知的財産権の実施または使用許諾をするものではありません。
  • モバゲー会員は、本サービスのコンテンツをいかなる方法によっても複製、送信、譲渡、貸与、翻訳、翻案その他の利用をすることはできないものとします。
  • モバゲー会員は、本サービスのコンテンツにつき再使用許諾をすることはできないものとします。
  • 本サービスのコンテンツの使用許諾は、非独占的なものとします。
  • コンテンツの使用権の有効期間は各コンテンツ毎に定められており、本サービス内で当社が定める方法により告知されます。
  • 前項に関わらず、退会等によりモバゲー会員が会員資格を喪失した場合は、コンテンツの使用権も消滅するものとします。
  • 当社はいつでもコンテンツの使用権の有効期間を変更できるものとします。


第9条2項 モバゲー会員は、モバゴールドを当社の定める方法により利用し、当社の定める範囲のコンテンツの使用権を取得することができるものとします。(以下略)


GREEもmobageも、
1.権利の許諾は否定しつつ、
2.コンテンツを一定の範囲内で使用できる
という構造になっています。
権利の許諾が不要なコンテンツの使用については、もともとユーザーが自由に行えるものである以上、「許諾」ではなく、「使用方法の制限」という建て付けにした方が筋は通るとは思いますが、主流は2社と同様、「許諾」方式なんでしょうか。
でも、あらゆる知財権の許諾を否定しつつコンテンツの使用を許諾するって、わかりづらくないですか?
僕はmobageの規約をはじめて読んだとき、意味が良く分かりませんでした。
また、自分は今まで普通に知財権の許諾にしてきたので、知財権の許諾を否定しつつコンテンツの使用権を付与するという建て付けの意味をぜひ知りたいとも思いました。


といったところで著作権編は終わりです。
このエントリーをはてなブックマークに追加 Share on Tumblr

↑このページのトップヘ