雑記

このエントリーは法務系Tips Advent Calendar 2013の21日目の記事です。



このエントリーは、Google Appsを導入していない企業や事務所にお勤めの方にはあまり意味のない内容になっています。予めご了承ください。

0.導入
Google Appsに含まれるGoogle Driveには、「フォーム」を作成する機能が含まれています。
この「フォーム」が本来想定している用途は、お問い合わせフォームやアンケートフォームのように、不特定または多数の対象者から広く情報を集めるというものなのですが、実はGoogle Apps Scriptという、JavaScriptをGoogleが拡張したスクリプト言語と組み合わせることで、簡単な「依頼受付システム」の入り口にすることも可能です。
とはいえ、これだけではさっぱりイメージが湧かないと思いますので、実際にサンプルを作ってみました。
今回は、このサンプルをベースにGoogleフォームとGoogle Apps Scriptを利用した「依頼受付システム」のご紹介したいと思います。

1.サンプル
※あくまでサンプルなので、メールアドレスは10 Minute Mailなどのサービスで取得したものを利用することをお勧めします(公開設定のスプレッドシートに記載されてしまいます)


(1)Googleフォームから送信された情報がスプレッドシートに記録される(Googleフォームが元々備えている機能)
※Google Apps for BusinessのGoogleフォームではログインID(メールアドレス)を自動取得するよう設定できるので、フォーム上で依頼者のメールアドレスの記入を求める必要はありません。

(2)フォームからスプレッドシートに情報が登録されると、予めスプレッドシートのスクリプトとして組み込み、フォームから申請を受け付けた際に自動実行するよう設定しておいた「requestReceived」という関数が自動実行される。
【フォームから情報を受け付けた際に自動実行するスクリプトの設定方法】

WS000071

WS000072


(3)requestReceivedが、管理簿用の別のスプレッドシートに必要事項を転記しつつ、依頼者のメールアドレスと処理担当者のエイリアス(今回はrequestreceive20131211@googlegroups.com)に受付メールを送付
ちなみに、requestreceive20131211@googlegroups.comに送付されたメールはこちらから確認可能


なお、Google Apps Scriptを利用すると、上記の処理の他にも、例えば「Googleドライブ上に依頼者と処理担当者が共同編集者に設定されたフォルダを自動作成する」とか、「管理簿上のデータ(例えば仕掛り案件数など)を読み取って受付メールに記載する」などの処理も比較的簡単に実現することが可能です。

JavaScriptを一度も触ったことがないという方にとっては一見意味不明かもしれませんが、難しいこと、複雑なことは一切していませんので、ちょっとした知識を身につけるだけで何をやっているかはすぐにわかるようになるはずです。
わからないなぁという方も、この機会に冬休みの課題としてJavaScriptを触ってみてはいかがでしょうか。
→Codecademy(http://www.codecademy.com/ja/tracks/javascript
→ドットインストール(http://dotinstall.com/lessons/basic_javascript

2.requestReceivedのコード
https://docs.google.com/document/d/1FFBMdX_bCT0CElJu-dSDSklFswR_rNRCIw3OdO88Qsk/edit

3.フォームで依頼を受け付けることで得られるメリット
ここまで読んで、「こんなめんどくさいことをしなくてもメールで依頼を受け付ければいいじゃん」と思われた方もいらっしゃるかもしれませんので、メールでの依頼受付では実現できないメリットに触れておきたいと思います。

(1)必要な情報を効率的に収集できる
フォームには「必須記載事項」を設定できるため、「依頼時に必要な情報が揃わない」という状況になるのをある程度抑制できます。例えば謄本請求依頼を受ける際に「現在事項?履歴事項?」「コピーでOK?」「3ヶ月以内縛りあり?」といった情報が依頼時についてくるようになるのです。

(2)管理簿を自動作成できる
管理簿を作ることで、業務の繁閑期や担当者の処理件数などの分析や、仕掛り案件の状況把握が容易になりますが、その一方で、管理簿に全ての受付案件を登録することは面倒です。
フォームとGoogle Apps Scriptを組み合わせることで、この管理簿への登録処理の多くを自動化することが可能になります。

(3)依頼の見落としを防げる
メールによる依頼は、他のメールに埋もれて見落としてしまう可能性がありますが、フォームとGoogle Apps Scriptを組み合わせることにより、
1.管理簿に自動的に転記される
2.所定のタグを本文や件名に埋め込むことにより、非常に精度の高いメール振り分けが可能になる
という2点から、依頼を受けたのに見落としていた、という事態を防ぐことができます。

(4)依頼者の安心感につながる
一日に何件も新規依頼を受け付ける場合には、受け付けた時点で受付メールを手動送信するのは面倒です。
他方で、依頼後になんのリアクションもないと、依頼者は「依頼した件、ちゃんと処理を開始してもらえたのだろうか」という不安を抱くものです。
フォームとGoogle Apps Scriptを組み合わせることで受付メールを自動送付できるようになるため、依頼者の安心感にもつながります。

(5)組織としての対応が容易になる
メールは基本的に個人が個人に送付するものなので、メールで依頼を受け付ける仕組みでは、どうしても自分の知っている担当者個人に宛てて依頼をしてしまい、担当ローテーションの妨げになってしまったり、ノウハウの属人化の一因になってしまう可能性があります。
フォーム経由の依頼は「個人宛て」のイメージを伴わないため、組織としての対応が容易になります。


やっていることは単純なので、最初の一歩さえ踏み出してしまえば思いのほか簡単に扱えるようになるGoogleフォーム+Google Apps Scriptでの依頼受付システム。
プログラミングが必要というだけで毛嫌いせずに、ぜひチャレンジしてみることをお勧めします。

上記のメリットの他にも、事前の準備をせずに手っ取り早くプログラミングの楽しさを味わえるという点も見逃せないポイントです。


というわけで、法務系Advent Calendar21日目は以上で終わりです。
明日はyoucutherhairさんです。
よろしくおねがいします〜
このエントリーをはてなブックマークに追加 Share on Tumblr

このエントリーは法務系Tips Advent Calendar 2013の1日目の記事です。



いよいよ始まりました法務系Advent Calendar。
いつものこととはいえ今回も事前調整ゼロで見切り発車したわけですが、いやぁ、なんとかなるものですね。この世界は優しさで満ち溢れているようです。

さてさて、早速ですが、本題に入ります。
今日のテーマは「ランチャーアプリ『Launchy』を使って快適な法務生活を送ろう!」です。

1.Launchyって何よ
Launchyの基本的な機能は、ランチャーというからには当然ではありますが、「指定されたファイルを開く」というもの。
一般的にランチャーというと、メニューから開くファイルを選択する「メニュー型のランチャー」と、キーボードでファイル名を打ち込んで開くファイルを選択する「コマンドライン型(キーストローク型)のランチャー」の2つに大きく分けることができますが、Launchyは後者の「コマンドライン型のランチャー」です。
Launchyを起動すると、Alt+スペース(僕はCtlr+スペースの方が使いやすいので変更してます)でLaunchyの検索ウィンドウをポップアップさせることができるようになります。
そして、その検索ウィンドウに「chr」と打つとGoogle Chromeがサジェストされ、エンターを押すとChromeが立ち上げることができるといった具合に利用します。
Launchyが対象とするのはファイルだけではなく、ウェブページやコントロールパネルも含まれます。

2.で、そのLaunchyと法務の業務がどう関係すんの?
アプリケーションを立ち上げるだけなら、正直なところ法務にとってコマンドラインランチャーを使う意味はあまり大きくはないかもしれません。
必須アプリケーションであるブラウザもWordも、朝から晩まで起動しっぱなしですもんね。普通。せいぜい、マウスに手を伸ばさずにPDICを立ちあげられるくらいでしょうか。
ですが、ファイルやフォルダの命名規則をしっかり定めている会社では、こいつが法務業務で大活躍することになるわけです。

3.え?とういうこと?
抽象的な話ではイマイチわかりづらいと思うので、とある会社の話を具体例にします。
その会社では、リーガルチェックを受け付けると自動的に「管理簿への登録」「採番」「共有フォルダ作成」が行われます。
そして、その共有フォルダのフォルダ名は、「【管理番号】相手方名_案件サマリー」と設定されます。「【123】株式会社ホニャララ_占い師へのコンサルティング契約」みたいな感じですね。
んで、Launchyの設定で、共有フォルダの親フォルダを検索先として設定しておくとしましょう。
するとどうなるかというと、「この前返してもらった株式会社ホニャララとのコンサル契約になんだけど、占いが外れた時の損害賠償責任についてちょっと聞いていい?」なんて内線がかかってきたとき、「Alt+スペース」→「ホニャララ」で、「【123】株式会社ホニャララ_占い師へのコンサルティング契約」のフォルダがサジェストされ、即座に契約書案を確認できる状態になるわけです。
WS000065

もちろん、「ホニャララ」が付くファイルやフォルダが複数あれば複数サジェストされてしまいますが、その会社ではフォルダ名と同じものを案件のやり取りのメールの件名にするというルールが徹底されており、「それって何番のホニャララ案件ですか?」と聞くと「123のやつ」と答えが帰ってくるので、今度は「Alt+スペース」→「123」でドンピシャのフォルダがサジェストされます。

さらに、その会社では、締結済みの契約書は全てPDF化され、「管理番号_締結日_社名_タイトル」というファイル名が付されることになっています。
ということは・・・もうわかりますよね。「去年の今頃ホニャララと締結した業務委託契約の期間を2ヶ月延ばして対価を1.2倍にする覚書を作って」という依頼を受けたとき、原契約を2秒で探せるわけです。それどころか、Launchyは1行電卓の機能もあるので「対価975万円の1.2倍を知りたい」場合には、「Alt+スペース」→「975*1.2」と打ち込むと、Launchyのウィンドウ上には「1,170」と表示されているというわけです。(+エンターでクリップボードにコピーされます)
WS000063

細かい話ですが、よく使う2号文書の印紙税額のリストはinshi.txtというフォルダに転記してあるので2秒で印紙税額を確認できますし、ウェブページを登録できるプラグイン(weby)にグループミーティング用資料のGoogleスプレッドシートのURLを登録しているのでこちらも2秒で更新に取り掛かれますし、Googleと打った後にTabでGoogle検索もできます。

4.そこまで言うなら使ってみるか・・・
Launchyは、http://www.launchy.net/からダウンロードすることが可能です。
スキンを適用することで見た目をガラッと変えることもできるので、ぜひ自分好みのスキンを探してみてください。(僕は、Loupeというスキンを愛用してます。)

というわけで、法務系Advent Calendar一日目は以上で終わりです。
二日目は「世界が滅びても毎日更新されるのではないか」とまことしやかにささやかれているdtkさんです。
よろしくおねがいします〜
このエントリーをはてなブックマークに追加 Share on Tumblr

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

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

↑このページのトップヘ