このエントリーは法務系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

みなさん、お元気ですか?
僕は元気です。

さて、昨日(4/10)に開催された「シード・アーリースタートアップのためのウェブサービスを支える「利用規約」の基本」という、おそろしく長いタイトルのイベントに、昨日パネリストとして参加してきました。

タイトルに「シード・アーリースタートアップのための」と書いてあるのに、参加者層は明らかに違う属性のかっちりとした皆様で、利用規約ナイトに続いて「どうしてこうも法務系の人がたくさん参加されるのだろうか(別に呼んでないのに)」という疑問を感じながらのスタートとなったわけですが、考えてみれば、利用規約についてまとまった知識を得られる場って、今までほとんどなかったんですよね。

AZX雨宮さんのセミナーを拝聴したり、利用規約本を書いたりしている中で少し麻痺していましたが、僕自身、利用規約やPPに関するまとまった情報がどこにも存在しておらず、法務として「これでいいのかなぁ」という疑問に常に不安を抱きながら業務にあたっていたわけで、僕だってパネリストとしてお声掛けいただいていなければ、普通に(呼ばれてないのに)参加していたと思うのです。


ところで、当日出た話題の中で
アプリの売買が行われる際、異なるアカウント間でアプリを移動させるためには、移行元アカウントでのアプリの取り下げと移行先アカウントでのアプリの申請を行うしかなく、ダウンロード数等の実績がリセットされてしまうが、これに対して有効な手立てがないか

というものがあり、後で皆さんと意見交換しようと思っていたのにすっかり忘れていたので、ここでこの点について考えたことを書いてしまおうと思います。

まず、GooglePlayはよく知りませんが、少なくともAppStoreにおいては、ランキングに載るか載らないかということは売り上げを大きく左右するとても重要な要素です。その意味で、現在ランキング上位にいるアプリについてアカウント移動のために取り下げ&再申請をするのは合理的な選択とは言えないと思います。
加えて、レビューサイトやブログ等に貼られているアプリダウンロードページへのリンクもおそらく無効になってしまうでしょうから、なおさらです。
となると、既にランキング上位のアプリや、レビューサイト等で取り上げられているアプリについては、アプリの売買の実態を「著作権&ソースコード譲渡とAppStoreへの掲載維持&申請代行&収益の分配等に関する業務委託」契約とするのがいいんじゃないかなぁと考えるわけです。
この方式では、「〇〇によるiPhone App」の欄に譲渡先のアプリを表示できないという問題もありますが、大した問題ではないと思います。

逆に、まだランキングに載っておらず、大手レビューサイトに取り上げられてもいないようなアプリについては、普通に取り下げ再申請方針で譲渡をすればいいんじゃないかと思います。

といったところで昼休みが終わったのでばいばーい。

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

1.はじめに
BtoCの契約には消費者契約法という法律が適用され、その消費者契約法の中には「消費者に一方的に不利な条件は無効になる」という規定が存在しています。
そして、無効とされるケースの一つとして、事業者の不法行為や、事業者が義務を果たさなかったことによって消費者に生じた損害の賠償責任について
A. 全部免責する条項
B. 事業者側に故意または重過失があるケースで一部を免責する条項
が定められています。(消費者契約法第8条1項1号〜4号

この消費者契約法の制限は、仮に消費者が同意していたとしても覆せない性質のものであるため、避けて通ることはできないのですが、ウェブサービスにおいては多くのユーザーから薄く広く売り上げを上げるモデルを採ることが通常です。そこで、事業者としてはユーザーによる損害賠償請求からは極力逃れようとがんばるわけです。
そこで今回のエントリーでは、有名どころのウェブサービスがどうやって消費者契約法に対応しているかについて、実例を見ていこうと思います。

2.他社の実例
GREEhttp://gree.jp/?mode=doc&act=misc&page=terms
9-2 (略)また、ユーザーは、グリーに故意または重過失がある場合を除き、いかなる場合においても、(i) かかる損害賠償の対象となる損害が、グリーの責に帰すべき事由に起因して現実に発生した、直接かつ通常の範囲の損害に限定されること、および(ii)グリーがユーザーに対して賠償する損害の累積額は、グリーが本サービスに関連してユーザーから支払を受けた金銭の合計額を上限とすることに同意します。

GREEのスタンスは、
1.損害賠償の範囲を直接損害・通常損害に限定
2.ユーザーが支払った金銭の合計額を損害賠償の上限として設定
という限定をかけつつ、
3.上記1&2の限定は、故意または重過失がある場合には適用しない
という構造で、消費者契約法第8条1項の制限ギリギリを狙っています。
消費者契約法にヒットする部分を除いて制限をかけるというオーソドックスなスタイルですが、GREEは基本無料のサービスであり、無料でGREEを利用しているユーザーにとっては本項が「A. 全部免責」となってしまう点がどう判断されるのかやや気になるところではあります。


mobgehttp://yahoo-mbga.jp/page/kiyaku/index2.html
第12条
4 本規約において当社の責任について規定していない場合で、当社の責めに帰すべき事由によりモバゲー会員に損害が生じた場合、当社は、1万円を上限として賠償します。
5 当社は、当社の故意または重大な過失によりモバゲー会員に損害を与えた場合には、その損害を賠償します。

mobageのスタンスは、
1.DeNAの故意または重大な過失により会員に損害を与えた場合には損害を賠償する
という原則を5項で規定しつつ、
2.DeNAの責任について規定がない場合は1万円を損害賠償の上限として設定
という制限を4項でかけてます。
5項が「DeNAの責任について規定がある場合」に該当するため、GREEと同様の消費者契約法にヒットする部分を除いて制限をかけるというオーソドックスなスタイルと言えると思います。
しかし、
・DeNAの規約の12条4項が除外対象としているのは「規約に当社の責任について規定がない場合」であって5項以外も上限が外れてしまう場合が文理上はあり得るという点、
・12条5項は故意・重過失時の責任限定を明示的には排除していないため、他の条項に損害賠償責任の免責が規定されていた場合に「故意・重過失時に責任が限定されている」と解釈される可能性が文理上はあり得るという点
で、やや危うさを感じました。

LINEhttp://line.naver.jp/terms/ja/
14.2. 当社は、本サービスに起因してお客様に生じたあらゆる損害について一切の責任を負いません。ただし、本サービスに関する当社とお客様との間の契約(本規約を含みます。)が消費者契約法に定める消費者契約となる場合、この免責規定は適用されません。
14.3. 上記14.2.ただし書に定める場合であっても、当社は、当社の過失(重過失を除きます。)による債務不履行または不法行為によりお客様に生じた損害のうち特別な事情から生じた損害(当社またはお客様が損害発生につき予見し、または予見し得た場合を含みます。)について一切の責任を負いません。また、当社の過失(重過失を除きます。)による債務不履行または不法行為によりお客様に生じた損害の賠償は、お客様から当該損害が発生した月に受領した利用料の額を上限とします。

LINEは、GREE及びmobageと異なり、
1.最初に全部免責としたうえで、
2.消費者契約法が適用される場合に上記の全部免責を外し、
3.さらに消費者契約法が適用される場合において、
 (1)過失(重過失を除く)によって生じた特別損害を賠償対象から外し、
 (2)損害発生月の利用料の金額を損害賠償の上限額として設定
するというスタイルを採っています。
LINEも基本無料なので、3(2)について、無料で利用しているユーザーにとっては事業者の全部免責になってしまうという点がやや気になります。

Yahoo! Japanhttp://docs.yahoo.co.jp/docs/info/terms/chapter1.html#cf1st
13.免責事項
当社の債務不履行責任は、当社の故意または重過失によらない場合には免責されるものとします。

なお、お客様との本利用規約に基づく当社のサービスのご利用に関する契約が消費者契約法に定める消費者契約に該当する場合、上記の免責は適用されないものとし、当社は、当社の故意・重過失に起因する場合を除き、通常生じうる損害の範囲内で、かつ、有料サービスにおいては代金額(継続的なサービスの場合は1か月分相当額)を上限として損害賠償責任を負うものとします。

Yahooは、
1.故意・重過失によらない場合は債務不履行責任について免責
と定めつつ、
2.消費者契約法が適用される場合に上記の免責を外し、
3.消費者契約法が適用される場合において
 (1)故意・重過失時を除いて損害賠償の範囲を通常損害に限定し、
 (2)故意・重過失時を除いて、有料サービスに関しては代金額を損害賠償の上限として設定
するとしています。
不法行為責任は免責の対象とせず、また消費者契約法が適用されない場合にも故意・重過失時の免責を放棄している点が特徴的です。
また、金額限定を有料サービスに限定することにより、GREEやLINEの「無料ユーザーはどうなるんだ?」という疑問も回避しています。

3.どうやって消費者契約法に対応すればいいのか
事業者の債務不履行と不法行為に基づく損害賠償責任の免責に関しては、
1.事業者に故意・重過失がある場合は事業者の損害賠償責任を免責しないことを明記する
2.事業者に軽過失(重過失でない過失)がある場合は、損害賠償の範囲を限定し、上限金額を設定する
の2段構えで対応するのが最もスタンダードな対応です。
なお、消費者契約法には、「消費者の利益を一方的に害する条項は無効」というキャッチオール規定(同法第10条)が存在しており、また、そもそも重大な事故が発生した場合に免責規定で損害賠償請求をすべて突っぱねることはレピュテーションが激しく傷ついてしまう可能性も高いので、特に有料サービスで、かつトラブル発生時には利用者に損害が生じることが見込まれるケースでは、免責でがんばるよりも、賠償責任保険やシステム上の手当てでがんばる方がベターな場合もあるという点には注意が必要かもしれません。

4.話は変わりますが
4/10に「シード・アーリースタートアップのためのウェブサービスを支える「利用規約」の基本」というイベントが開催されるのですが、このイベントにパネリストとして登壇してきます。
このブログをご覧になっている方でその属性にヒットしている方がいらっしゃるか極めて不安ではありますが、ベンチャー企業の経営者の方やウェブサービスを営んでいる個人の方は、ご興味があればぜひエントリーをお願いします。
なお、参加者からの事前質問も受け付け中です。→事前質問はこちらから


3/19に発売になった利用規約本も、引き続きよろしくおねがいしまーす。

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

↑このページのトップヘ