2009年07月

チョコっとラブ的なにかのmixiの8月18日規約改正について疑問というエントリ経由で知ったんだけど、mixiが今度の規約改定で、このような規定を利用規約に追加するそうな。
mixi利用規約 第14条

(16)自己または第三者の住所、電話番号、メールアドレス等の個人が特定される連絡先を、本サイト内のユーザー全体に公開される箇所に投稿する行為。

利用規約改定のお知らせ

ちなみに、14条柱書は、
ユーザーは、本サービスの利用にあたり、次に掲げる行為を行ってはならないものとします。禁止事項に違反した場合には、強制退会、利用停止、日記等の情報の全部もしくは一部の削除、又は公開範囲の変更等の不利益な措置を採ることがあります。

という非常に強いものです。

続いて目にしたIT Mediaの「全体公開の日記にメアド書かないで」 mixiが規約改定では、この規定を追加した趣旨にも言及されていて、
 全体公開日記にメールアドレスなど個人情報が掲載され、ユーザーがトラブルに巻き込まれるのを防ぐ目的。

 同社によると、全体公開の日記が誰でも閲覧できると意識せず、「携帯のメアド変えました」などと、メールアドレスなど個人情報を日記に掲載するユーザーがいるという。

 規約改定後、こういった日記を事務局が見つけた場合、非公開設定にした上で、ユーザーに対して、公開範囲を「友人限定」に変えるか、削除するといった対応を取るよう伝える。

ということらしい。

電番やメルアドで個人を特定できるのか、という古典的な論点や、「個人が特定される連絡先」と「個人情報」の関係は?という疑問はひとまず置いといて、連絡先を公開するなという規定の趣旨についてだけ考えることにしますが、mixiのシステム(ニックネームそのものが連絡先になる)と矛盾するはずなので、多分mixi自身は、「連絡先の公開が一切NG」とは考えていないはずだと思います。
→もしこれをNGにしたら、マイミク申請ができなくなっちゃうよね・・・

「だったら、『連絡先の公開禁止』なんて規定追加するなよ」、と思うかもしれない(そして、その気持ちはよくわかる)けど、現実にはいろんな思惑に引っ張られて、こういった「そんなつもりはないのに」系の規定が颯爽と登場することがあるんだよね。それも、結構な頻度で。
(訴訟でも、最初は「損害を賠償させよう」という趣旨だった訴訟が、いつの間にか「あいつらをギャフンと言わせてやる」という訴訟になっちゃってる、みたいな形で現れてきたりします。)

なんでそんなことになっちゃうかというと、その理由は単純で、「何を目的にしていたのか」が、調整の過程でおいてけぼりにされてしまうから、または最初から目的が不明確だったからなんじゃないかと思います。

「mixi 利用規約」でググったら、mixiは著作権の利用許諾に関して、1年ほど前に似たような騒ぎを招いていたらしい
このときの目的は(少なくとも建前上は)、「著作権がシステム運営の妨げになるのを防ぐ」というものだったみたいだけど、実際に発表された規定案は全面的な無償利用許諾を求めるもので、このときも規定が目的と乖離していたことがユーザーの反発を招いたのだと思います。(目的が建前どおりのものだったら、という前提はありますけど)
つまり、根っこは同じなんですよね。きっと。

----

残念なことにというか、めんどくさいことにというか、法務に持ち込まれる段階では、「こうしたい」という話しかしてもらえないことの方が多いので、「なぜ、そうしたいのか(目的)」については、積極的に追っていかないとなかなか教えてもらえまないのが一般的な傾向だと思います。

でも、決められた条件どおりに契約書を作るのは、法務の仕事の中では最下層。条件を決めるところに関与できない法務は、来るべき(というか既に到来しかかっている)弁護士大増員時代にはきっと淘汰されるはずで、その意味では、「なんでそうしたいの?」というところは、おろそかにしちゃいけないんだろうと思います。(別にmixiの中の人が、目的を疎かにしていると言いたいわけじゃないですよ。)

また、自衛という側面から見ても、文言をめぐって問題がおきたときは、まずはその文言を作った人に矛先が向かうわけだから、その意味でも気をつけないといけないだろうなと改めて思った次第です。

さて、昼休みも終わるので、この辺で。
このエントリーをはてなブックマークに追加

【入力できないことを明確に】
契約書IDは、契約書テーブルを作成したときに「自動入力値」を「はい」に設定したので、自動的に連番が振られます。
そのため、フォーム上でユーザーは契約書IDを入力・変更することはできないので、このことをユーザーに分かりやすく示しましょう。

まず、契約書IDの属性設定ウィンドウを表示してください。
→グループ化の解除をお忘れなく!

そして、「アクティブにする」を「いいえ」に設定してください。

これで、ユーザーは契約書IDの入力フォームをアクティブにする(選択する)ことができなくなるので、「IDを入力できそう」な雰囲気をある程度減殺できます。
デザインモードをオンにして、もう一度できばえを確認したら、保存してフォームを閉じてください。
※デザインモードの切り替え方法は、前回参照。

【データ項目の追加】
さて、契約書を探すとき、契約の概要があると便利な場合があります。
そこで、この契約書管理DBにも、契約の概要を登録する項目を追加してみましょう。
ただ、忙しいときには契約の概要の登録をスキップできるよう、必須入力項目からははずすことにします。

Table_EditModeまず、契約書テーブルを編集モードで開いてください。
※契約書テーブルを右クリック→編集です。





add_gaiyouそして、フィールド名列に「契約の概要」を追加入力してください。





これでテーブルの設定は完了です。
保存して閉じてください。

次に、契約書登録フォームを編集モードで開いてください。
※こちらも、右クリック→編集です。

フォームを開いたら、フィールドの追加ボタンを押してください。
→既にフィールドの追加ウィンドウが表示されている場合は、何もしなくてOKです。

そして、どれでもいいのでコントロールを選択してください。
→例えば、「契約書の登録」と表示しているラベルフィールドなど。

add_gaiyou_formすると、フィールドの追加ウィンドウに、先ほど登録した「契約の概要」が追加されているのが見えるはずですので、前回同様、ドラッグアンドドロップでフォームに追加してください。




このように、「テーブルにフィールドを追加」→「フォームにコントロールを追加」という手順で、データベースを簡単に充実させていくことができるのです。
便利ですね。

つづく
このエントリーをはてなブックマークに追加

少し前から英作文のトレーニングにLang-8を利用し始めたんだけど、これがなかなか良い。

Lang-8(ランゲートと読むらしい)は、自分の母国語を学ぼうとする人のテキストを添削してあげる代わりに、自分が学ぼうとする言語のテキストを、その言語を母国語とする別ユーザーに添削してもらえるというサービスです。

もちろん、「ネイティブの方(ただし素人)に添削してもらえる」というのもありがたいのですが、自分が書いたつたない英語を人に読んでもらえて、何らかの反応を得られるということの方がずっと価値があるように感じます。
やっぱりせっかく書いたテキストですから、誰かに読まれているという実感があると、嬉しいものです。


以下、これからLang-8を始める方のために、Lang-8のコツを。
  1. 日記を書いたら「言語フラグ」を「英語」に設定する。
    これにより、英語ネイティブの方に「あなたの添削を待っている日記」として表示されるようになるはずです。
  2. あまり長く書かない。
    添削する側になるとわかりますが、長く、かつ修正すべき箇所が多いテキストは添削する気になれません。
    長く書きたい場合であっても、複数のエントリーに分けて書きましょう。


では、たのしいLang-8ライフをお送り下さい!
このエントリーをはてなブックマークに追加

最近キャズムを越えつつあると各所でささやかれているTwitterですが、法律関係のアクティブなTwittererはまだまださほどいらっしゃらないのが現状です。

というわけで、私のFollowerからお勧め法律系Twittererをご紹介します。
※紹介されたら困るという方はご一報ください。すぐ削除します。
※「この人は追加すべき」という方がいらっしゃったらぜひ教えてください。
※所属ではなく、つぶやきの内容で取捨選択しました。

弁護士・行政書士
  • @ogawalaw
    key:法律豆知識、弁護士の日常
    小川総合法律事務所の所長さんです。程よく流れてくる法律豆知識がおもしろいです。
  • @akiraccyo
    key:行政書士の日常、行政書士のお仕事
    神戸の行政書士さんです。知られざる法務系の行政書士の方のお仕事を垣間見ることができます。
  • @matsui17
    key:弁護士の日常
    大阪の弁護士さんです。やさしそうです。
  • @yjochi
    key:弁護士の日常
    落合洋二弁護士です。刑事系のお話は貴重ですね。
  • @kevinokeefe
    key:法律系アルファブロガー(なのかな?)
    lexblogのCEOかつlawerのkevinさんです。
    時差の関係で、朝起きるとTLがkevinさんの暑苦しいアイコンで埋まっています。


    企業法務
  • @takujihashizume
    key:企業法務一般、労働法、コンプライアンス、チームマネージメント
    企業法務マンサバイバルのtacさんです。
  • @kousyou
    key:法律関係のニュース/記事紹介
    Knotworking.bizの山野光正さんです。


    知財
  • @cc_jp
    key:著作権、Criative Commons
    Criative CommonsJapanのtwitterアカウントです。
  • @ysmatsud
    key:産業財産権の登録実務
    産業財産権周りの実務を垣間見れる貴重なtwittererです。


    ニュース
  • @ABAJournal
    key:海外の法律関係のニュース
    ABA Journalのtwitterアカウントです。
  • @HotLawTopics
    key:海外の法律関係のニュース
    West LegalEdcenterのtwitterアカウントです。
  • @WSJLawBlog
    key:海外の法律関係のニュース
    The Wall Street JournalのLawBlogのtwitterアカウントです。
  • @Bankruptcy_Info
    key:倒産
    帝国データバンクの大型倒産速報です。


    ちなみに、これを書いている僕は@kataxです。

    ではでは〜
  • このエントリーをはてなブックマークに追加

    【フォームに項目を追加しよう】
    さて、テーブルとフォームとの紐付けが終わったので、いよいよ次はデータを入力するコントロールを配置しましょう。

    今回は二つある方法のうち、簡単な方を利用してみます。

    add_Field画面下のツールバーの「フィールドの追加」ボタンを押してください。

    フィールドの追加ウィンドウが表示されたと思いますが、内容がまっさらの場合は、先ほど作成した「契約書の登録」ラベルフィールドをクリックしてください。


    add_Field2続いて、フィールドの追加ウィンドウに表示されている”契約書ID”と、”契約書名”と、”締結日”を、フォーム上にドラッグアンドドロップしてください。





    これだけで、契約書テーブルへの入力が可能なフォームとして最低限の体裁は整いました。
    かんたん!


    【日付の入力を簡単に】
    さて、契約書登録フォームは一応出来上がったものの、これだけでは「データの入力が簡単になった」とはまだまだいえません。

    というわけで、面倒な締結日の入力を簡単にしてみましょう。

    まず、"締結日"と書いてあるラベルフィールドの上で右クリックし、「グループ」から「グループ解除」を選択してください。
    ・・・勘の言い方は気づかれたかもしれませんが、実は、フィールドの追加ウィンドウからのドラッグアンドドロップで追加したコントロールは、ラベルフィールドと入力用のフィールドがグループ化されたものだったのです。

    グループ化というのは、複数のコントロールをひとまとめにして取り扱う仕組みです。
    意味がわからない方は、とりあえず「グループ化を解除しなければならんのだ。よくわからないけど。」と覚えてください。
    いつかわかりますよ、きっと。

    さて、グループ化を解除したら、次は入力用のフィールドの属性設定ウィンドウを表示してください。
    ・・・できましたか?それとも、やり方を忘れてしまいましたか?
    答えは、”コントロールを右クリックして「コントロール」を選択”です。

    そして、”ドロップダウン”を「はい」に変更してください。(下から5つ目のはずです)


    では、ここまでのできばえを確認してみましょう。

    DesignMode画面左のツールバーから”デザインモード オン/オフ”を押してください。
    このボタンを押すと、フォームの画面を編集するモード(デザインモード)と、フォームを使ってテーブルにデータを入力するモードをワンタッチで切り替えることができます。



    Calenderデザインモードをオフにすると、締結日を入力するコントロールの横に▼が表示されていると思います。
    これが、先ほど”ドロップダウン”を「はい」にした効果です。
    この▼をクリックするとカレンダーが表示され、キーボードを使わずに日付の入力を行えますので、利便性がぐっとあがります。

    つづく。
    このエントリーをはてなブックマークに追加

    【とりあえずフォームを作ってみる】
    前回、データベースの根幹部分が完成しましたが、テーブルはあまりデータの入力や閲覧に適した仕組みではありません。
    というわけで、フォームを利用して、データの入力や閲覧の利便性を向上させることにしましょう。

    画面左部のメニューから「フォーム」を選択してください。

    続いて、画面上部のタスクメニューから「デザイン表示でフォームを作成」を選択してください。

    これから、この画面にパーツを配置していきます。



    まずは、タイトルを表示しましょう。
    画面左側のツールバー(ツールバーが左側に表示されていない方は、メニューの「表示→ツールバー→フォームコントロール」にチェックを入れてください。)から「ラベルフィールド」を探してクリックしてください。(四角で囲まれていない"ABC"のアイコンです。)

    Label_Setそして、フォームの左上で適当な大きさにドラッグしてください。
    ※フォームをただクリックするだけでは配置できないのでご注意ください。



    なお、ラベルフィールドは、フォーム上の案内板です。
    それ自体が何か機能を持つわけではなく、フォームが、利用する人にとってわかりやすいものになるように配置するものなので、難しいことを考えずにあなたの美的センスに任せて使ってください。


    ラベルフィールドの貼り付けはできましたか?
    なお、このラベルフィールドや、この後利用するテキストボックスなどは、"コントロール"と呼ばれます。
    しっくりこなければ、「部品」と読み替えてください。

    Label_Set2次に、ラベルフィールド上の文字を変更します。
    ラベルフィールド上で右クリックし、「コントロール」を選択。




    その後表示される属性の設定ウィンドウの"タイトル欄"を、「契約書の登録」に変更し、エンターキーを押すと、先ほど貼り付けたラベルフィールドの表示が「契約書の登録」に変わっていると思います。

    ラベルフィールドに限らず、コントロールの設定を変更する場合は、以後この要領で行ってください。


    【レコードソースの設定】
    さて、先ほど、フォームを使うことでテーブルへのデータの入力や閲覧を便利にできると書きましたが、このフォームは、どのテーブルへのデータの入力に使うものかをまだ設定していないので、続いてこの設定(レコードソースの設定といいます)を行います。

    先ほど作成したラベルフォームの上で右クリックし、今度は「フォーム」を選択してください。

    Form_Property続いて、表示された属性設定ウィンドウの"データ"タブを選択してください。

    そして、内容欄に「契約書テーブル」を入力(というか、選択)してください。



    これで、このフォームが「契約書テーブル」のデータを入力するものと紐付けることができました。
    かんたん!


    さて、ここまでの作業が終わったら、いったん名前をつけて保存しましょう。
    名前は、「契約書登録フォーム」としておいてください。


    つづく
    このエントリーをはてなブックマークに追加

    【契約管理DB爆誕!】
    さて、データベースボタンをクリックして出てくる画面では、何も考えずに完了ボタンを押しましょう。
    そして、適当なファイル名(契約管理DBとか)をつけて保存しましょう。

    これであなたのデータベース「契約管理DB」がこの世に生を受けました。
    おめでとうございます。

    【テーブルの作成】
    さて、あなたのPCの画面には、現在こんな画面が出ていると思います。
    左側のメニューに、「テーブル」「クエリー」「フォーム」「レポート」の4つが並んでいますが、今回はテーブルをいじります。
    テーブルは、1件1件の生のデータ(レコードといいます。)をしまっておく入れ物だと思ってください。
    (クエリーとフォームとレポートは、それぞれ必要になったときにまた説明するのでとりあえず忘れましょう。)

    画面上部の「デザイン表示でテーブルを作成」をおもむろに押すと、無味乾燥な表が表示されたと思います。
    深いことは考えずに、"フィールド名"の列の上から「契約書ID」「契約書名」「締結日」と入力してください。
    TableSet1
    現在の画面→



    次は、フィールドタイプの設定です。
    契約書IDのフィールドタイプを、「整数 [INTEGER]」に、
    締結日のフィールドタイプを「日付 [DATE]」にそれぞれ変更してください。

    TableSet2
    現在の画面→




    最後です。
    契約書IDのフィールドタイプ欄(整数と書いてあるセル)をクリックし、画面の下に出てくる「自動入力値」を「はい」にします。
    →この設定をすると、契約書IDには自動で重複しない連番が割り振られるようになります。
     なぜ重複しない連番が必要なのかと思った方はこちらのリンク先を読んでまた眠くなってください。

    これで、テーブルの設定は終わりです。
    「契約書テーブル」という名前で保存し、いったん閉じてしまってください。

    さて・・・実は、ここまでの作業で、データベースの根幹部分はもう出来上がってしまっているのですが、そのことにお気づきでしたか?。
    試しにさっき作ったばかりの契約書テーブルを開いて見ましょう。
    TableInput
    このエクセルのシートのような画面から直接データを入力していくことでも別に問題は無いのです。

    でも、これじゃデータの入力がしづらいですよね?
    セルの幅は狭いし、日付は全部手打ちしなきゃならないし・・・

    で、ここで颯爽と登場してくるのが「フォーム」です。

    つづく
    このエントリーをはてなブックマークに追加

    ---まえおき---
    以前依頼処理フローや締結済み契約書管理についてのエントリーを書いた影響なのか、"契約書 データベース"をキーワードにここへたどり着く方がそこそこいらっしゃるようなので、タイトルのような特集をやってみることにしました。
    一連の作成過程では、「データベースとは」的な話は一切省略し、説明が面倒な点は「こうゆうものなので」で済ませてしまいますのでご了承ください。

    ---
    【ダウンロードとインストール】
    今回、OpenOffice.orgのBaseを使って締結済み契約書の管理を行うので、まずはOpenOfficeを入手しなければなりません。
    OpenOfficeのダウンロードとインストールについては、こちらのサイトが参考になります。
    ggrks


    【どんなデータベースにしようか?】
    さて、OpenOfficeのダウンロードとインストールの完了を待っている時間に、どんなデータベースにするのかを考えることにしましょう。
    ここで大切なのは、「欲張らないこと」です。
    最初は管理対象をできるだけ絞り込んで、シンプルな構成を目指しましょう。
    というわけで、今回作るデータベースが最初に対象とする項目は「契約書ID」「タイトル」「締結日」の3つだけにします。(後で「相手方」と「失効」と「概要」と「メモ」を追加します。が、それはまた後で。)
    ここで、「タイトルや締結日は必要だけど、俺、契約書IDとかマジ必要ねーし。」と思ってしまって夜眠れなくなってしまう方は、こちらのリンク先を読んで眠くなってください。

    【起動してみよう!】
    さて、そろそろインストールは完了しましたか?

    では、早速間髪いれずに起動してみましょう。
    インストールオプションを小ざかしくいじっていない素直な方のデスクトップには"OpenOffice.org 3.1"という名前のショートカットがあると思いますので、これをダブルクリック。

    OOo_launcherこんな画面が出てきたら、データベースボタンをクリック。
    次からいよいよデータベースの作成です。

    つづく
    このエントリーをはてなブックマークに追加

    さて。

    LAW launcher Mobileのver1.2をリリースしました。

    追加機能は
    ・目次の生成機能を追加
    ・検索履歴の保存機能を追加
    の2点です。
    (LAW.xmlは更新しませんでした。)

    次あたりからブラウザ機能も中で持つかもしれません。
    が、検索できないんですよね。IEコンポーネントをつかったWM向けブラウザって。

    ダウンロードはこちらからどうぞ。
    このエントリーをはてなブックマークに追加

    7/3の勉強会について週末にまとめをしようと思っていたけど、バタバタしているうちに月曜日がやってきてしまい、さらにlove_chocolateさんhase0831さんに内容をまとめていただきました。
    ありがとうございます!


    ・・・で終わってしまうのもなんなので、私は私で、勉強会でしゃべった内容の背景や反省点を書こうと思います。




    契約書を取り交わす意味
    契約書を作る時、「ったりーなー」と感じる理由の一つとして、その必要性を実感できていないから、ということが結構大きいんじゃないかと思っています。
    契約書をなぜ作るか、という問いに対する答えの王道は「トラブル時に合意内容を参照するため」というもので、このこと自体は確かにごもっともではあるんだけど、(業界や相手方の素性・お国柄によって変わるとはいえ)実務上、トラブルの場に契約書が持ちだされる機会はそう多く無い状況下で、この理由だけでは、実際にめんどくさい思いをする人の心を動かすことはできないはず。
    だから、今回はこの王道の理由は軽く触れるにとどめて「契約書を作らなかったら、決めなきゃいけないことを決められないでしょ?契約書の検討という作業があるからこそ、要検討項目についてもれなく検討できるんだよ。」という方向で話を進めることにしました。
    反省点:契約書を作らなかった場合のシミュレーションを飛ばしちゃったせいで、いまいち実感に欠ける内容になってしまった

    契約締結フローにおける法務の役割
    「意思決定をするのは現場(ひいてはそのライン上に位置する決裁者)」という考えを前提に、「決めるのはあなたです。法務はそのために必要な判断材料をできるだけ正確にお伝えします。」という役割分担を明確にするのが狙いでした。
    反省点:上記の前提そのものが会社によってさまざまなので、いろいろな会社の方が参加する勉強会で話す内容としては説得力に欠けてしまった

    契約書の読み方
    パレートの法則的に、分量としては多くない重要な部分だけ押さえることができれば、その契約書の80%は押さえたも同然ということを伝えるのが狙いでした。
    実務者向けの契約研修では、どうしても分かりにくい概念の説明(「瑕疵担保とは・・・」や、「知財とは・・・」など)に終始しがちだけど、契約書の機能として重要なのはもっとずっと単純で簡単なことなんだということです。
    なお、ここで、基本契約と個別契約の位置づけを分かりやすく説明するためにはどういえばいいかについて軽く盛り上がりました。
    ・基本契約はオブジェクトで、個別契約がインスタンス(機能面から)
    ・サイト共通のlink要素で参照するCSSが基本契約で、各ページスタイル要素のCSSが個別契約(適用面から)
    などなど。
    反省点:意図をうまく伝えられない質問を何個かしてしまった。

    契約交渉の進め方
    契約交渉で膠着する大きな原因の一つが、「交渉の外形をとりながら交渉になっていない」というものがあるということをお伝えするのが狙いでした。
    ・「●●してくれ」と言われたら、「なぜ?」と聞く。
    ・合理的な理由に基づく修正(≒交渉の対象になりうる修正)は、実際はほとんどない。
    ・交渉できない場合は、押し切るしかない。
    反省点:「じゃぁ、どう言えばいいの?」というところにもっと時間を割くべきだったかもしれない。

    ---

    参加者の方がどんなところに疑問を感じ、また興味をお持ちなのかを知ることができ、僕自身もとても勉強になりました。
    もうちょっと準備に時間を避ければ、「プログラミングと契約書の類似点と相違点から見る契約のキモ」みたいなことも挟みたかったのですが、残念ながら間に合わいませんでした・・・
    (ちなみに、家の都合で早めに打ち上げ?から失礼せざるを得なかったことが一番の心残りでした。)

    それでは!
    このエントリーをはてなブックマークに追加

    ↑このページのトップヘ