このエントリーは法務系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】契約書「ひな型」再考〜どこまで用意するべきか? - bizlaw_style
を拝見し、
以上、「法務系Tips Advent Calendar」の議論の盛り上がりを機会に、「契約書ひな型」というテーマについても、各社(各所・各人)の取組みや考え方を可能な範囲で共有できたら、なかなか面白いのではないかと思い、とりあげてみました。
との呼びかけに呼応して、自分が日常業務で利用している条項集のサンプルを取り上げてみようと思います。

ちなみに、モノはこんなかんじです。
WS000075



契約書をドラフトする際は、前文・結び文も含めて基本的にこの条項集からコピペしています。
つまり、別の契約書を一部修正する方法で契約書を作成することは、私の場合は基本的には行いません。(例外は、案件間の条件面の相違がほとんどないことが明確な場合や、条項集が想定していな特異な契約をドラフトする場合くらいです)、
ひな形は、そのまま相手方に提示するものであって、それをベースに別の契約書を作成するものではない、というスタンスです。

ひな形であれ、他の案件で実際に使った契約書であれ、既に契約書の体裁で存在しているものをベースにする場合は、形式面での修正漏れや、他の案件特有の条件の混入当該案件にのみ必要な条件を落としてしまうといったミスが発生しがちでしたが、コピペ用途に最適化した条項集を利用するようになってからはこのようなミスはずいぶんと減りました。

そのまま相手に提示できる定型的な契約書面についてはひな形でひと通り揃えておき、案件ごとにカスタマイズが必要な契約書の作成時や相手方から契約書案を提示された場合は条項集で対応するというのがミスの低減と効率化のちょうどいい落とし所じゃないかと最近は思っています。

で、次のステップとしては、安全にカスタマイズできるひな形、つまり契助的なものの活用ということになるわけですが、これをGoogleフォームを使って自前で作ってしまおうという試みに近々チャレンジしてみようと思っています。

ではでは。
このエントリーをはてなブックマークに追加 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

1.はじめに
先日、なんの前触れもなく(まぁ、いつもそうだといえばそうだけど)Appleから「アプリの譲渡ができるようになったから、iTunes Connectにアクセスしてみてね!」という趣旨のメールが届いてびっくりしたデベロッパーの方は多いんじゃないかと思います。

今までアプリとデベロッパーとの紐付けを断ち切るためには「AppStoreからの取り下げ&別アプリとして再申請」という原始的な方法を採るしかなく、それまでに積み上げてきたユーザーやレビュー・ダウンロード数等の実績を引き継ぐ方法はなかったことに悩まされていた方も少なくなかったところに突然銀の弾丸が打ち込まれたわけで、そりゃ驚くのも無理はありません。

もしかすると、これを機にアプリ譲渡のプラットフォームが立ち上がるかもしれませんし、個人が開発したアプリを買い付けて転売する仲介業者が登場する可能性もあります。
この大きな流れの変化を傍観者として見守っているだけというのはあまりにつまらない、ということで、アプリケーション譲渡の際に用いる契約書を作って見ることにしました。

2.アプリ譲渡の実態って・・・
当初は、事業譲渡契約書をベースに、ちょちょいと手を加えたら簡単にできあがると思っていたのですが、実際に作り始めると、そう単純ではない、ということにすぐに気付かされました。

一般的に、「アプリの譲渡」と聞くと、
 1.ユーザーがインストールするアプリのソースコードと、その著作権の譲渡
がまっさきに思い浮かぶと思います。
で、実際単機能のツールなどは、これだけで十分な場合も多いはずです。

しかし、車輪の再発明が各所で行われていた黎明期とは異なり、現在は様々なライブラリやフレームワークを駆使して開発を進めるのが一般的であり、全ての著作権を譲渡できるとは限りません。
このようなケースでは、
 2.第三者が保有する著作権の利用許諾の引き継ぎ
も必要になります。

また、今主流のアプリはスタンドアロンではなく、サーバーと連携して動作するものがほとんどです。そうなると、
 3.サーバーサイドアプリケーションのソースコードと、その著作権の譲渡
 4.サーバー関連のハードウェア(またはクラウドサーバ / ホスティングサーバ利用権)の譲渡

ということもケアしなければならなくなります。
これが自社サーバではなく、第三者が提供するサービスとの連携(例えば、Twitter API経由でのTwitterの利用など)で実現しているものである場合は、さらに
 5.第三者のサービスを利用する権利の引き継ぎ
という問題も発生します。

さらに、ユーザーの位置づけも、大規模なアプリやゲームを中心に、「単なるアプリの利用者」から、「アプリをインターフェースとするサービスの利用者」へと進化しつつあります。
こうなると、
 6.ユーザーとの契約関係・債権債務の承継
という観点も無視出来ません。

既にGoogle+で「作ってみる」と宣言していなければ、検討すべき要素の多さを前に、めんどくさくなって放り出してしまっていたことは間違いない状況でした。

3.がんばってつくってみた
という状況下で、想像をふくらませながら作ってみた契約書がこちらです。
「なんでこの条文があるの?」とか、「この条文の意味は何?」といった疑問や、「これ、おかしくね?」といったご指摘があれば、ぜひ本エントリーのコメント欄でご指摘いただければ幸いです。

WS000048




4.おわりに
今回アプリケーション譲渡契約書を作ってみて思ったのは、ものすごく単純なケース(せいぜい4止まりのケース)を除いては、瑕疵担保やら保証やらで事後的にどうにかしようとするのはかなり無理がありそうだ、ということでした。

んじゃぁどうすんだよ、ということですが、これはもう、
・対Appleのアカウントと権利は譲り受ける一方で、外注先として運営はそのまま譲渡当事者にやってもらう
・人も含めて承継を受する(もはや、アプリの譲渡というより事業譲渡)
しかないのかなぁ、と思うわけです。
あまりおもしろくない結論で申し訳ないのですが、アプリの譲渡って簡単じゃないよね、ということが契約サイドからも垣間見えました、ということで、午後もがんばりりましょう!

最後になってしまいましたが、今回作成した契約書のブラッシュアップに、企業法務マンサバイバルのはっしーさんに様々なアドバイスをいただきました。
はっしーさん、ありがとうございました!
このエントリーをはてなブックマークに追加 Share on Tumblr

こんにちは。
突然ですが、師匠、商法総則参照し賞賛を素早く3回口に出して言ってみてください。
どうでしたか?

じつはこれ、難しいのは「総則」のところだけなんです。
難しいように見えて、実はかんたんということ、世の中には結構たくさんあるみたいですよ。


えー、さて、タイトルのとおり、今回のテーマは「登録不要の無料サービスに関する利用規約」についてです。

登録不要の無料サービスと言うのは、たとえばニュースサイトとか、お天気情報サイトを想定しているわけですが、これがなんでわざわざブログで取り上げるようなテーマになるかと言うと、このようなサービスは、ユーザーから明示的な同意を取るチャンスが基本的にはない、という特徴があるからです。(だからこそ、気軽に利用でき、ユーザーのすそ野を広げやすいわけですが。)

この点について、先日開催された利用規約ナイトVol2のパネルディスカッションで「ユーザーから利用規約に対する許諾を取らなくても利用規約によって拘束できるような方法はないか」という質問を頂き、また先日の長い名前のイベントでもまた同様のご質問がありました。

ご存知の通り、契約は意思の合致によって成立する法律行為なので、ユーザーからの明示的な同意を取れないとなると、「利用規約によってユーザーを拘束する」=「ユーザーとの間で利用規約を内容とする契約を締結する」ということは、とても難しいということになります。
そのため、利用規約ナイトVol2での回答も「原則として、同意を取らなきゃユーザーを拘束できません」であり、先日の長い名前のイベントでの回答も「同意を取らないと厳しいが、同意を取れないのであれば、ユーザーの目につきやすい場所に利用規約を常に表示しておくことでなんとか・・・」といった感じだったと記憶しています(完全に僕の記憶頼りの再現なので、勘違いや誤解をしていたらごめんなさい。)

この回答は、契約の原則に照らせば当然の結論ではあるのですが、その一方で、どうしても違和感を拭い去ることができません。
そんなわけで、今日のお昼にお弁当を食べながらもう一度考えてみたところ、どうやら違和感の源泉は、「登録不要の無料サービスって、そもそもユーザーとサービスプロバイダの間に何の契約もないんじゃね?」ということに思い至りました。
これはつまり、何の契約もなければサービスプロバイダはユーザーに対して契約責任は負わないので、まっとうなウェブサービスを展開しているだけであれば、ユーザーに対してもともと何の責任も負ってない(だから、利用規約なんて不要)と言うことになるんじゃないか、ということです。

「仮にユーザーに対して法的責任を負わないとしても、事実上のクレームを捌くために利用規約はあった方がいいんじゃないか」、というご指摘もあるかもしれませんが、そもそもユーザーに対して何の責任も負っていないのであれば連絡先を明らかにする必要もないわけで、連絡先を隠しちゃえばクレームどころかユーザーから何の連絡も受けずに済んでしまいます(それをサービスプロバイダが望むことかはわかりませんが・・・)

といったところで、お昼休み終わりでーす。




【追記】
Twitterで以下のご指摘を頂きました。ご指摘の通りだと思いますので、本エントリー中の「登録不要」は、「ユーザーから同意を得るチャンスの無い」に読み替えていただければと思います。
ご指摘ありがとうございました!



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

↑このページのトップヘ