個人情報の利活用の場面において個人情報の匿名化を避けて通ることはできないわけですが、踏み込んだ知識はデータ処理の門外漢には敷居が高く、「完璧な匿名化手法は存在しない」というかの有名な結論については理解できても、そこから進んで「どうするのがベターな匿名化手法なのか」といったことについては今ひとつ理解できずにいました。

そんな中でデータ匿名化手法 ―ヘルスデータ事例に学ぶ個人情報保護の存在を知り、早速読んでみたところ、いくつか腑に落ちたことがあったのでまとめてみます。

  • 匿名化は確率的なものなので、再特定化される可能性をゼロにはできない。(上記の「完璧な匿名化手法は存在しない」と同じこと)
    生データを提供することで得られるメリットは、生データを提供することで発生するリスクとのトレードオフ。
    問題はリスクがゼロかではなく、リスクを正当化できるか。

  • データの開示方法、データの開示を受ける人が既に保有している知識や、再特定化するモチベーション・能力によって匿名化の手法やレベルが変わる
    例えば、コンテスト等のためにデータを公開する場合は厳重に匿名化を施す必要があって、再特定化禁止義務を課した研究者(再特定化モチベーションも再特定能力も高くない)にデータを開示する場合とは必要な匿名化のレベルは大きく異なる。

  • データの用途や分析方法によって、匿名化手法を変える必要がある
    わかりやすい例としては、発生順序が重要なケースにおいては、非特定化のために発生年月日をランダムに変更してしまうと、それだけで全く価値のないデータになってしまう

  • 再特定化のリスクの判断のアプローチには、最大リスク(再特定確率の最も高いレコードを全体リスクとみなす)と平均リスクがある
    公開データに対して再特定化アタックをされる可能性があるようなケースでは、攻撃者は誰か一人でもいいから特定しようと攻撃してくる以上、最大リスクアプローチでリスクを判定する必要がある。
    これに対して、「あ、これってあの人じゃん」的な再特定を防げば良い場合は平均リスクアプローチで考える。

  • ヘルスケアデータは、生データを使って分析をする強い社会的意義(疾病の防止や原因究明など)があるので、再特定化リスクをとってでも利活用するメリットを観念しやすいので、ビジネス利用というか、金儲けの場面では全く同じようには考えられないだろうな(感想)


無個性なイワシの群れを匿名化本の表紙に選んだオライリーのセンスが光るこの一冊、読むのは苦労しましたが、一歩前に進めた気がします。


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

内田・鮫島法律事務所の伊藤 雅浩先生より、ご著書システム開発紛争ハンドブック―発注から運用までの実務対応をご恵贈頂きました。





システム開発をめぐるトラブルを専門とされる弁護士といえばと問われたとき、松島先生と伊藤先生のお二方のお名前が浮かぶ方は少なく無いと思いますが、本書はその松島先生と伊藤先生の共著によるシステム開発紛争をテーマに取り上げた書籍というわけで、その情報だけで購入を決めた方も少なくないのではないでしょうか。
かくいう僕もその一人でした(ご恵贈頂いたので、実際には購入には至りませんでした。なんかすみません・・・)。

さて、本書は、タイトルに「システム開発紛争」を掲げており、実際に裁判例を軸に様々な論点に対して説明が進められていきますが、現に紛争案件を取り扱っているか否かにかかわらず、システム開発関連の契約法務に携わっている方は一読しておくべき一冊だと思います。
というのも、システム開発に関して発生する様々なアクションについて相談を受けた際に、それを裁判所がどのように評価するのかを知らなければ、自分の感覚や、自分なりに考えた理屈を頼りに回答することになってしまいますが、もしそれが裁判所の判断と異なるっていた場合、無意味な、また場合によっては有害なアドバイスをしてしまうことになりかねないからです。

また、裁判例が豊富に掲載されているということは、つまりトラブル事例集としても機能するということでもあります。
システム開発紛争に関する社内研修を行うと、必ずテーマとしてリクエストを受けるのはこの「トラブル事例」の共有なので、日本屈指のシステム開発関連訴訟の専門家が選定したトラブル事例集を手にすることができるという意味では、法務だけでなく、プロマネや情シス部門の責任者の方にも有用なのではないかと思います。

僕も、ひとりよがりなオレオレ理論で会社に損害を与えてしまうことの無いよう、もう一度ドッグイヤーしたページを読み返して、しっかりと自分の血肉にしたいと思いました。


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

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

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

  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

間違えると結構やばいのに、積極的に教えてもらう機会が少ない期間の計算を一回ちゃんと押さえておきましょう、そうしましょう。


・関連する条文(民法)
第百三十八条 期間の計算方法は、法令若しくは裁判上の命令に特別の定めがある場合又は法律行為に別段の定めがある場合を除き、この章の規定に従う。
第百三十九条 時間によって期間を定めたときは、その期間は、即時から起算する。
第百四十条  日、週、月又は年によって期間を定めたときは、期間の初日は、算入しない。ただし、その期間が午前零時から始まるときは、この限りでない。
第百四十一条  前条の場合には、期間は、その末日の終了をもって満了する。
第百四十二条  期間の末日が日曜日、国民の祝日に関する法律 (昭和二十三年法律第百七十八号)に規定する休日その他の休日に当たるときは、その日に取引をしない慣習がある場合に限り、期間は、その翌日に満了する。
第百四十三条  週、月又は年によって期間を定めたときは、その期間は、暦に従って計算する。
 週、月又は年の初めから期間を起算しないときは、その期間は、最後の週、月又は年においてその起算日に応当する日の前日に満了する。ただし、月又は年によって期間を定めた場合において、最後の月に応当する日がないときは、その月の末日に満了する。


・時間単位で定めた期間
  1. 時間、分、秒で定めた期間は普通に計算すればOK(§139)
    以下、日、週、月、年で期間を定めた場合のルール

・期間の起算
  1. 「(あるイベントの発生日)の●日後」と定めた場合は、午前0時にイベントが発生するような超例外的な場合を除いて翌日が起算日になる(§140本文→初日不算入の原則
  2. 「(あるイベントの発生日)から起算して●日後」と定めた場合は、起算日の特約があるため、特約通り当日が起算日になる(§138)
  3. 「(特定の日付)の●日後」と定めた場合は、午前0時からその日は始まるので、当日が起算日になる(§140但書)

・期間の終了
  1. 期間の終了は、期間の末日の深夜24時(§141)
    →期間の末日の翌日の午前0時と同じ時間ではあるが、別の日(12/31に著作権が消滅する著作物は、翌年1/1から発効する改正著作権法による著作権の存続期間延長の対象にはならない)
  2. 月初起算の1年間は、翌年前月の末日に終了する
  3. 月初起算の1ヶ月間は、当月の末日に終了する
  4. 1月30日や8月31日など、翌月には応当日が存在しない日の「翌月」と期間の満了日を定めた場合は、翌月末日に期間が満了する(§143驚⊇顱
  5. 期間の末日が日曜・祝日の場合は、(一般的な会社の場合は休業するので)翌日に期間が終了する(§142)

・遡る期間の考え方
  1. 時間の流れに沿うよう逆算して上記のルールを適用する
    →「●日前までに通知する」を、「通知してから●日後」に読み替える
  2. 結論としては、初日不算入の原則により、「中●日間」になる
    →末日が休日だった場合の処理なども適用されるので、結論だけをただ覚えるのは危険

・実務上の留意点
  1. 契約期間を「締結日から1年間」と定めると、初日不算入の原則により翌年同日が契約期間終了日になって現場の認識と食い違う
    →更新期間も同様
    →「締結日から起算して1年間」または「(特定の日付)から1年間」と定めておくと認識のズレが生じない


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

先日、弁理士で会計士なサラリーマンブロガーatakaさんにインタビューをしていただきました。

katax × IPFbiz 〜企業法務のキャリアについて考える〜

今年に入ってatakaさんが対談シリーズを開始された時は、「知財法務」というくくりだったこともあり、自分に話が回ってくるとは思っても見なかったのですが、伊藤先生から「長くブログを続けている」ということでご紹介いただき、このようなチャンスに巡りあうことが出来ました。

ヨモヤマ話に終始してしまって、終わった後もう少し中身のある話をすべきだった・・・と反省しきりだったのですが、atakaさんの編集力でしっかりとまとめていただけました。
ほんと、まとめる立場を踏まえないインタビューイーで申し訳なかったです。
あたかも僕がしっかりとした人のように読めますが、実際はご存知の方はご存知の通り、行き当たりばったりで人生を送っているタイプなので、割り引いていただければ幸いです。

atakaさん、このような機会をいただき、ありがとうございました。
また、伊藤先生も、ご紹介いただき、ありがとうございました。

今後も対談シリーズ楽しみにしてます!
このエントリーをはてなブックマークに追加 Share on Tumblr

先日、タイトルだけ見て買った法務のお仕事系の書籍が、ちょっと自分の期待していた内容と違っていて、ややがっかりした後になんとなく手にとった知って得する ソフトウェア特許・著作権 改訂六版が素晴らしかったのでご紹介。

上記の、僕が勝手にがっかりした本と違う意味で、「タイトルから想像する内容」と「実際の内容」が異なる一冊でした。

まずおどろくべきことに、この本、特許権と著作権と同じボリューム・レベル感で、商標権についてもがっつり書かれているんです。なんでタイトルに商標権が入ってないんだ!(まぁ、初版には入ってなかったとか、そういうことなんだろうけれど)で、要所要所で意匠権についても触れられています。

もう一つ驚いたのが、「知って得する」という語感から受ける概説書・入門書的イメージと異なり、カバーするトピックの幅広さと深さは、それだけでしっかりと実務に使えるレベルのものになっています。具体例も多く、例えばパッケージソフトウェアの商標権の類似群コードは「11C01」「42X11」「35K08」だよ、なんてことが明記されていたり、特許のアイデアを具体化するためのブレストの進め方なんてトピックもあったりします。

さらに、「ソフトウェア」特許・著作権とは謳っているものの、基礎となる「ソフトウェアに限定しない」特許・著作権(と商標権)についてしっかり論じたうえで、具体例としてソフトウェアで当てはめをしたり、ソフトウェア特有のトピックを出したりしてくれるので、ソフトウェアにとどまらない知財の知識をおさらいすることが可能です。

文章もとても読みやすく、厚さの割にサクッと読み進められるので、週末の一冊にお勧めです。

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

先週、社内の法務部門の勉強会で、ISMS担当を兼任する同僚が個人情報関連をテーマに取り上げていたんですけど、その中で「もし当社で個人情報漏洩事件が発生したら、どのように対応すべきか」という項目があって、それがすごく盛り上がりました。
ベネッセさんの対応が資料中で例示されていたんですけど、
  • 同じ立場に立たされたとしたら、同じスピード感で対応できたか
  • 漏洩が発覚した時にまずすべきことはなにか
  • 誰に相談すべきなのか
といったことを話し合っていると、これは避難訓練のように、全社で情報漏洩対応訓練をすべきじゃないかという気がしてきました。

「●階で火災が発生しました」の代わりに、「●●から●●情報が漏洩しました」というアナウンスがなされて、初動や官公庁報告、プレスリリースをシミュレーションする感じで。
これ、ディープな個人情報を持っている会社や過去情報漏えい事故を起こしたことがある会社さんはやられているんじゃないかと推測するんですけど、実際のところどうなんでしょうか。
実際に情報漏洩対応訓練を回している会社さんがあったら、ぜひお話をお伺いしたいです。


というタイミングで、企業法務のFirst Aid Kit 問題発生時の初動対応 First Aid Kit@kyoshimine先生からご恵贈頂き、勉強会で取り上げられた個人情報漏洩についても入っているのかな・・・と、早速目次を眺めてみると、ばっちりありましたよ、「自社が管理する個人情報の漏洩事故が発生しました。初動対応はどうすればよいでしょうか。」って項目が。

First Aid Kitというだけあって、初動でどうするかに全力でフォーカスしており、これだけで各インシデントへの対応を網羅できるというものではありませんが、その分様々な事例、しかも、Q&A形式でありがちな「答えを書くために質問を立てる」系を最小限に留めて実務あるあるを354も集めているのは圧巻です。
この本に掲載されているインシデントに対して即座にある程度的確な初動のToDoを出せるようになったら1人前なのだとすると、1人前までの道は程遠いですね・・・

そう考えると、もしかするとこの本、初動対応を学ぶための本というより、企業法務の問題集としての価値のほうが高いのかも、なんて思ったりしました。


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

もう10年以上昔のことになってしまいましたが、僕が最初に勤務した会社は、それはもう素晴らしくホワイトな会社で、自分の自由になる時間をふんだんに確保できました。
加えて、毎日が新しい経験の連続の日々だったので、「企業法務についてあれこれ」というウェブサイト(当時はホームページってみんな呼んでましたね)を立ち上げて、仕事で得られた知見をそこにまとめて公開していました。
で、そのウェブサイトの1コーナーに「雑記」というWeb日記みたいなページがあったんです。
ただ、正直htmlタグをポチポチ打ち込んでFTPでアップロードするのってすごくめんどくさくて、更新は滞りがちでした。
そんな時に出会ったのがブログでした。
これがもう、画期的で。

いつしか更新はもっぱらブログに移行した雑記だけになり、そしてプロバイダの移行とともに雑記以外のコンテンツは消滅し、残ったのは「企業法務についてのあれこれの雑記」だけとなりました。

で、いつだったかは忘れましたが、ブログのデザインを変更した際、タイトルがあまりに長いというだけの理由で「企業法務について」に名称を短縮した、というのがここの名前の生い立ちです。

@takujihashizumeさん、ご理解いただけましたでしょうか。
このエントリーをはてなブックマークに追加 Share on Tumblr

↑このページのトップヘ