雑記 【おしごと関係】

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

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

  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

ウェブサイトやアプリに広告を貼ろうと思って広告配信に関する契約を締結しようとすると、広告配信サイドからコンテンツの適法性や適切性について様々な保証を求められることになります。
例: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

法務系Advent Calendarの7日目のエントリーです。
@overbody_bizlaw先生、立ち上げ&とりまとめ、ありがとうございます!

もう5年以上前になるのですが、契約書の管理(締結済み契約書編)というエントリーを書いたことがあり、中途半端な内容の割に、今でも検索エンジン経由で一定のアクセスがあるので、もう少し整理したいと思っていました。
というわけで、この機会に締結済み契約書の管理について、マニュアルっぽく仕立て直すことにしました。

なお、想定しているターゲットは契約締結件数が100件/月未満の規模の企業です。

1.管理簿を作る
  • 管理簿の立ち上げ段階では、項目を「契約書を特定するためのキーとして利用するもの」に限りましょう。
    項目を増やしても、正確な情報が記載されている保証がなければ結局原本をあたることになるので、実務的にはあまり役に立たないのが通常です。
    加えて、契約書を読める人でなければ登録できないような登録簿は、運用コストが高すぎます。
    通常は、管理番号、相手方名、締結日、契約書のタイトル、申請部署、備考・メモ欄程度で充分です。
  • 項目が少ない段階では、エクセルやGoogleスプレッドシートなどの表計算(スプレッドシート)で作成したシンプルな管理簿で充分事足ります。(後述するリーガルチェックとの紐付けをする場合はその情報も)
    また、データベースアプリケーションは、まず間違いなくcsvをインポートできるので、将来データベースアプリケーションへ移行することになった場合もスムーズな移行が可能です。
  • データベースアプリケーションで管理簿を作る場合、「部内のできる人」の属人的なスキルに頼ると、その人が辞めた後、メンテナンスができなくなってしまうという悲劇に陥ることになりかねないので、絶対に避けるべきです。必ず情シスなどを巻き込み、組織的に対応しましょう。
  • GoogleスプレッドシートやZOHO Creatorのようなクラウドサービスを利用しない場合は、管理簿のバックアップをとり忘れないようにしましょう。データは、消える時はサクッと消えるものです。
  • 特に事情がない限り、管理簿への登録は、原本を保管に回すタイミングで行いましょう。
    これにより、「管理簿に記録されている=原本が一旦は保管に回った」という保証がなされるため、原本紛失時の原因探知に役立ちます。

2.原本を保管する
  • 原本は、管理簿の管理番号順に並べて保管しましょう。
    50音順は、「途中に差し込む」という超煩雑な作業が発生することや、外国企業の場所が一意に定まらない(特に中国企業)という問題や、紛失したことが判明しづらい(別の場所に保管されているかも・・・)という問題があるため、絶対に避けるべきです。
    50音順ソートのメリットは特定の企業との契約をまとめてピックアップできることくらいですが、そのような場面はあまり発生しないことに加え、通常はフィルタをかけて一括で取り出すことができるPDFで事足りてしまいます。
  • また、保管用のツールは、バインダーではなく、ボックスファイルとクリアフォルダを使いましょう。
    バインダーはピックアップに手間がかかりすぎる上に、取り回しにも不便です。
  • 参照後に所定の保管場所へスムーズに戻せるよう、契約書の原本の上部に管理簿の管理番号を記入しておきましょう。
  • クリアフォルダは耳付きのものがあるので、耳に管理番号を書いておくことでピックアップのスピードアップに一定の効果を得られます。

3.契約書をPDF化する
  • PDF化する場合、ファイル名だけである程度の検索を行えるよう、「管理番号」「相手方名」「契約書名」「締結日」はファイル名に含めましょう。(後述するリーガルチェックとの紐付けをする場合はその情報も)
    ファイル名が長くなることは気にせず、略称は絶対に使わないようにしましょう。検索性が低下してしまいます。
    PDFファイルのファイル名を手で転記するのは面倒であり、また誤記の原因になるので、できるだけ管理簿でファイル名を自動生成し、それをコピペするようにしましょう。
  • PDF化作業の最大の壁は、「溜まっている締結済みの契約書をどうやってPDF化するか」ですが、これは期限を決めて一気にやってしまいましょう。
    「締結済み契約書が全件PDF化されている」という状態は、業務の効率化に大きく寄与します。
    人的リソースが足りない場合は、業務サポート系部門や派遣社員さんの力を借りることも検討してください。
  • 契約書が大量にある場合は、複合機を占領することになってしまうことを避けるため、契約書スキャン専用のスキャナを買ってしまうことをお勧めします。
    ScanSnap SV600であれば、スキャナの設置スペースもほとんど不要で、しかも座ったまま作業できるので、作業者の負担を軽減できます。(但し、フラッドヘッドタイプのスキャナより、行が「ふにゃっ」としがちです。)
  • PDFファイルはフォルダ分けをせず、一つのフォルダに全部保存することをお勧めします。
    申請部門毎や契約ジャンル毎のフォルダ分けは、手間がかかる割に役に立ちません。
    むしろ、検索ができる電子ファイルにおいては、単一のフォルダにまとめておいた方が使い勝手が向上します。
  • PDFファイルの作成後、スキャナ同梱のOCRソフトウェアやAcrobatを用いてOCR情報を付加しておくとPDFファイル内の検索が可能になるので、内容を再確認する際の業務効率がかなり向上します。
    アンダーライン等の装飾がついていない鮮明な活字であれば、かなり正確にOCR情報を付加してくれます。
    なお、上記のSV600の付属ソフトウェアにもOCR機能がついています。
  • 全契約書のPDF化が完了したら、原本は古いものから倉庫や利便性の良くないキャビネットへ移動させて、おそらく特等地だったであろう契約書原本の保管場所を別の用途に転用しましょう
  • 特に事情がない限り、新たに締結された契約書のPDF化作業は、原本を保管に回すタイミングで行いましょう。
    繰り返しになりますが、「締結済み契約書が全件PDF化されている」という状態は、業務の効率化に大きく寄与します。

4.契約書をピックアップする
  • 締結済みの契約書を参照する必要が生じた場合、原本でなければならないときを除いてPDFを参照するようにします。
    また、原本にアクセスできるメンバーは必要最小限に限定しましょう。
  • 契約書原本を保管場所から取り出す場合は、紛失防止のため、クリアファイルごとではなく、契約書原本だけを取り出すとともに、クリアファイルに「取り出した人」「取り出した日」「取り出した理由」を書いたメモを入れておく運用を徹底しましょう。
  • PDFファイルのピックアップには、Launchyなどのランチャーアプリや QTTabBarを使うと便利です。

5.決裁フローとの紐付け
  • 締結済み契約書側から契約締結決裁や捺印決裁の履歴と紐付ける必要は基本的にはありません。
    決裁→保管とフローが繋がっているので紐づけるのは容易ではありますが、役に立つことはほとんどないので具体的な必要性がないならばやめましょう。無駄です。

6.リーガルチェックとの紐付け
  • リーガルチェックについて案件管理がきっちりできている場合は、締結済み契約書とリーガルチェックとの紐付けを行うことを強くお勧めします。
    「締結済み契約書のWord版が欲しい」「どうしてこの条件を受け入れたのか、経緯を知りたい」「当時の担当者・担当部署を知りたい」という良くあるリクエストに瞬時に対応できるようになります。
  • 具体的には、管理簿に「リーガルチェックの管理番号」という列を追加する方法と、PDFファイルのファイル名に管理番号を埋め込んでしまう方法がありますが、余力があればどちらも実施することをお勧めします。
  • リーガルチェックとの紐付けを毎回検索して行うおうとすると事務コストとメリットが釣り合わなくなってしまうので、契約締結決裁や捺印決裁の際にリーガルチェックのキー要素(管理番号など)を記載することが前提になります。
    なお、決裁フローにおける法務のチェックの際には、決裁対象案件に関するリーガルチェックの情報を参照することになるので、契約書の管理とは直接関係しませんが、その意味でも決裁フローとリーガルチェックとの紐付けは有用です。


「これは違う」とか「もっといい方法がある」等ございましたら、ぜひご指摘ください。
ではでは。
このエントリーをはてなブックマークに追加 Share on Tumblr

例えばNDAの「秘密情報の定義」の条項において、秘密指定(Confidential、社外秘など)をつけるか否かを決めるのは、秘密情報管理規程のような社内規程との整合性です。
例えば基本契約の「個別契約の成立」の条項において、みなし承諾を設けるか否かを決めるのは、受発注フローとの整合性です。
例えば業務を受託する個別契約の「著作権の帰属」の条項において、著作権を全部渡して良いか否かを決めるのは、どんな著作権が発生して、それを自社が将来流用するのかです。

有利とか、不利とか、過去がどうとか、他社との契約ではどうとか、そういうことではなく。

契約法務っていうのは、そういうことだと思うんです。
このエントリーをはてなブックマークに追加 Share on Tumblr

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

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



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

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

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

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

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

11月からこっそりと開始していた採用活動が、今月半ばに無事完了しました。
最終的にはいわゆる新卒(企業に勤務した経験の無い方)を採用する結果となったのですが、当初は即戦力採用を目指しており、実際にお会いした方も、採用に至った方を除き全員が法務業務の経験者の方でした。

法務としての実務経験のある方の面接をする際、僕は必ずある質問をしていました。
それは、「他の法務担当者の方々と比較して、ご自身が優れていることは何ですか?」です。
しかし、残念ながら、この質問はあまり奏功しませんでした。
つまり、ほとんど魅力的な回答を得る事ができなかったのです。

翻って、ウェブ上では、(最近は特にGoogle+で感じる事が多いのですが)多くの方がご自身の専門領域について有益な情報をシェアされています。(明示的に語られてはいませんが、一連のエントリーから強みが浮き出てくる方がたくさんいらっしゃいます)
また、今月末で退職する僕の上司は、退職時の挨拶で、転職理由として「自分はエンターテイメント分野でのコンテンツ周りの法務を得意としており、それをより活かせる場に行く事にした」といった内容を語りました。

いずれも、中途採用面接で受けた「あれ?それが、ですか?」感とは正反対です。

この対比を目の当たりにしたことにより、最近麻痺してしまってきていた「自分はこのままだとヤバい」感が再びわき上がってきました。
ある程度安定的な立場を得た事により、無資格法務が本来的にはらんでいる「別にいなくてもなんとかなる」という危うさを忘れてしまっていたことに気づいたのです。

そんなわけで、「自分が人より優れていること」「人にはできないが自分にはできること」をより明確にするということを、来年以降の大きなテーマとしようと思ったりしたのでした。
このエントリーをはてなブックマークに追加 Share on Tumblr

2回目の月一プレゼン。
早くも月一というペースに不安を感じてきました。

今回もKeyNoteを利用していますが、前回よりもアニメーション・遷移の癖が掴めてきたので、煩さは減少しているのではないかと思います。

肝心の中身についてですが、ターゲットはスタートアップの経営者で、投資を受けることを検討している場面を念頭に置いています。
果たしてこの状況に当てはまる人が現在何人いるのかまったくわかりませんが、もしうっかり誰かの役に立つようなことがあれば嬉しいです。
あと、見返したら「エージェントコスト」の説明がちょう雑ですね。
ま、大目に見てください。

ではでは。


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

今年の新企画、月一プレゼンです。
出だしからギリギリのアップになってしまって自分でもどうかと思うんですけど、とにかく今月は目標達成。先が思いやられます。

今回はMacを新調したことと、諸般の事情でKeyNoteを使う用事ができたこともあって、慣れないKeyNoteで資料を作成しています。

では、どうぞー。



---

本筋とは関係ないけど、誰でも簡単にカッコいいプレゼン資料を作れるというふれこみだったKeyNoteは、本当にすごかった。

資料作成(下書きも含めて)に数時間。
エフェクトを付けるのなんて、1時間もかからずに完了したからねぇ。

見栄えにあまり留意しなくていいというのはこんなにも快適なことだったのかと感心しました。

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

この前、昼休みに思い付きで「コンプライアンス違反が起こるパターン」をまとめてみたんだけど、それだけじゃ何にも産み出せていないので、さらにもう一日分の昼休みをかけて「パッと思いつくコンプラ違反の事例との関連付け」もやってみたら、シートがすんごく汚く・見づらくなったこととの引き換えに一つわかったことがありました。




それは、ほとんどのコンプラ違反事例が「ばれない」ことを前提にしてるということ。
いや、考えてみれば当たり前のことなんだけど、こう「ばれないと思ってた」に矢印が怒涛のように突き刺さる様を見ていると、実感がわいてくるわけです。
「ばれない」っていう期待というか思い込みは怖いな、と。

コンプライアンス研修ではよく、「人に見られているとしても同じ行動を取るのか?」という判断基準を与えることがあるけど、結局のところ「ばれない」って思ってる人にそんなこと言っても全然意味ないんだよね。
だって、「同じ行動はとらないけど、ばれないからまぁ大丈夫」ってなっちゃうわけだから。

といことは、「ばれないと思わせちゃうかどうか」がコンプライアンス違反が止まるか否かを画するわけなので、コンプライアンス研修ではまず、知識とか意識とかの前に、「何かやったらばれるかんな!」ってことを強調することから始めなきゃならないのかもしれません。
もちろん、この脅しが空振らないようにするための当然の前提として、「何かやったらばれる」体制・システムの構築も必要になります。
今までは、どちらかと言うと「やらせねぇよ」という観点で体制・システムを考えていましたが、もしかすると、正解は「やったら見逃さねぇよ」の方なのかもしれません。

ここら辺を見なかったことにして「そもそもコンプライアンスとは、法令遵守にとどまる概念ではなく・・・」とか、「下請法と言う法律によって、資本金3億円以下の事業者に・・・」とか、「今や会社が潰れるような事態にも・・・」とか言ってみたってあんまり効果ないんだろうな、なんて思ったりしました。

んでは、また!

おっきい図はこちらから
このエントリーをはてなブックマークに追加 Share on Tumblr

↑このページのトップヘ