雑記 【おしごと関係】

磯崎さんのコラム投資契約を結ぶ際の3つの重要ポイントを読んで、大切なことだけど普段契約書を読んだことのない人には大変だよなぁ、と思ったので、少しでもこんな方々の役に立つことができればと思い、簡単なガイドを書いてみました。

その1:契約書を読む前に、この契約で実現したいことを再確認する
契約書を読みなれていない人は、契約書案が手元に届いても、いきなり読み始めるのはうまいやり方ではありません。
なぜなら、契約書を読みなれていないと、契約書の記載から条件を読み取るのはとても大変だからです。

では最初に何をすればよいかというと、それは、この契約で、自分は何を実現したかったんだっけ?ということを再確認することです。
自分は何を実現したかったのか、とは、つまり投資を受ける契約でいえば「現金を●月●日までに自分の口座に振り込んでほしい」ということであり、物品を買う契約であれば「ある商品を●月●日までに自分の手元に納入してほしい」ということです。この段階では細かいこたぁどうでもいいので、「これがなかったら契約するなんてありえん」というコアが何かを明確にしましょう。

そして、この再確認が終わったら、自分が実現したかったことが、契約書にちゃんと書かれているかを確認するしてください。
この確認作業は、「契約書に何が書いてあるかを頭から読み解いていく」ことよりもずーーーーーっと簡単なので、さくさくっと終わらせることができるのではないかと思います。

その2:自分の義務に、無茶なことが書いてないかを確認する
さて、無事実現したいことが契約書にちゃんと書いてあることが確認できたら、次は「自分の義務」としてどのようなものが規定されているかの確認です。
義務には「●●しなければならない。」というものと、「●●してはならない。」という2種類があることに注意して、蛍光ペンで自分の義務が書いてある部分にラインを引いてしまいましょう。
和文の契約では「●●するものとする。」という。日本語的にどうなの?という書き方で記述されることもあります。
 また、英文契約では、義務には助動詞「shall(禁止義務の時はmay notも)」が義務の目印になります。
そして、ライン引きが終わったら、自分の会社がこの義務をちゃんと守ることができるのかを想像してください。
想像してみて「こりゃ無理だわ」と思った義務については、削除する必要があります。
カッコつけずに「無理ですごめんなさい」と先方に伝えましょう。
なお、文句を言うと、相手方の担当者が「これは紙上の問題で、実際は無視でいいっすよ」と優しい言葉をかけてくれることもありますが、不思議なことに、いざもめ事になると、優しかった担当者の姿が見えなくなってしまったり、担当者の姿は見えても優しさをどこかへ置き忘れてしまっていることがとても多いのでぜひご注意ください。

その3:意味が判らない条項は、思い切って削除する
その1、その2が終わったら、ようやく頭から契約書を読んでもいい頃合いです。
が、結局のところ、読んでも意味のわからない記載はゴロゴロ出てきてしまうと思います。
ここで気をつけてほしいのが、「読んで意味がよくわからない記載については、なぜか自分に有利なように推測してしまう」という、悲しき人間の性です。
ですが、残念なことに、相手方が作った契約書に書いてある意味のわからない記載が自分に有利な意味を持つことはほとんどありません。
そのため、専門家に頼れないケースでは、意味が判らない条項は削除してしまった方が安全ということになります。
ガシガシ削除すると間違いなく先方からは文句を言われますが、後で振り返ってみると意味が判らない条件をのむよりよっぽどマシなことも多いので、がんばる価値はあると思います。


といったところで昼休みが終わりました。
午後もがんばりましょー。
このエントリーをはてなブックマークに追加 Share on Tumblr

最初に断ってしまいますが、いつも通り、タイトルと内容はあまり関連していません。

---

今年は、みずほFGと東京電力という、前期に大問題を引き起こした会社の株主総会に立て続けに出席した。

どちらの総会も当然のように荒れ、ヤジと怒号が飛び交う中、株主はここぞとばかりに質問の場で大演説をぶちかまし、動議が出され、そして粛々と決議事項が可決されていった。

中でも東電の総会は、Twitterで詳細な実況をする方が複数登場し、その日のニュースでも大きく取り上げられえたこともあって、その異様な雰囲気は多くの人に知れ渡ったことと思う。
その夜、東電に対するネガティブな感情が文字になってTL上を駆け巡っているのを眺めながら、一体どうすればよかったのか、自分だったらどうしたのか、ということについて考えざるを得なかった。

---

株主総会で会社が想定していない決議がなされてしまうと実務上多大な支障が生じることが明らかである以上、協力株主から委任状や当日の協力を取り付けようとするのは当然の行動であり、非難されるいわれはない。
総会を始める前から勝負が決まっている状態になっていることについても、それはひとえに会社に賛同する議決権が多かったと言うだけのことであって、ほめられこそすれ、貶められる筋合いのものではないのは明らかだ。
また、株式会社の性質上、株主総会の場で渦巻いていた「明らかに反対/賛成の挙手の方が多いのに、なぜ可決/否決されるのだ!」という問いが完全に的をはずしたものであることにも疑問の余地はない。
さらに言えば、株主総会は数カ月の綿密な準備を経てピンポイントで実施される失敗の許されない一大イベントであって、もしかすると取消のネタになるかもしれないような不規則な(他社と横並びでない)対応などは徒にするべきではないということも理解しているつもりだ。

今回の東電の総会だって上記の観点から見ればなんらおかしなことはないのに、それでも違和感をぬぐい去ることはできない。


どうすればよかったのか、しばらく悶々と考えて出た結論は、「出席した株主に、この総会は茶番・無意味だ、と思わせないよう努力する」ことだった。
文字にすると青臭くて自分でも苦笑いしてしまうけど、でも、特に今期の東電のような総会では必要なことだったと思う。

---

例えば、株主質問の場で超早口でわけのわからないことを捲し立てた挙句、「全員原子炉に入って死ね!」と絶叫した株主がいたけれど、それに対して東電側が、「わけのわからない捲し立て」の部分からかろうじて聞き取れたキーワードを質問事項とし、そのことについて答えたという場面があった。
この心底くだらないやり取りを聞いて、「東電は『質問に答えた体』が必要なんだ」と多くの人が感じただろう。
また、「決議の時挙手を求めていながら数えているふしがない」という別の株主質問に対し「ちゃんと数えています」と答えた場面もそうだ。
こんなことを言われて、茶番だと思わない人がいたら、むしろ驚愕してしまう。

「茶番と思わせないため」に、何も独立したアクションを総会に取り入れろなんてことを言いたい訳じゃない。
ただ、一つ一つの対応に、「目の前の株主と真摯に向き合う」という意思を込めるだけでよかったと思う。
(頭の中に渦巻いている思いをうまく文章にできなくて、夢見がちな抽象論のような書きぶりになってしまうのがもどかしくてたまらない)

もちろん、株主総会だからといって株主に媚びを売る必要があるわけではないし、普段であれば、株主の側だってそこまでの期待はしていない。

でも、今の東電は「普段」ではない。
周りを敵に囲まれる中、東電にとって株主は数少ない味方の一人だ。
それにもかかわらず、1万人近い株主を前に自分たちの声をダイレクトに届けられる機会をみすみす棒に振った(というより、逆に不満を募らせることになった)という損失は、これから逆風の中前進を続けなければならない東京電力にとって、思いの外大きなものになるのではないかと思えてならない。
このエントリーをはてなブックマークに追加 Share on Tumblr

英文契約書を初めて読むよ!という方をターゲットに、これを知っておけば役に立つんじゃないかという豆知識をまとめてみました。
ツッコミ、補足大歓迎です。

------
shallとmay
契約書においては、ほとんどのケースでshallは義務、mayは権利を示す助動詞として機能します。
shallが出てきたらこの文には義務が、mayが出てきたらこの文には権利が書かれていると割り切ってしまって続きを読むことで、スムーズに権利と義務を整理することができます。

大文字で始まる単語は定義されてる
文頭でも固有名詞でもない(通常の英語のルールでは大文字で始まるはずが無い)のに大文字で始まっている単語は、契約書のどこかでその意味が定義されています。
このような単語は、通常とは異なる意味が付与されていますので、文意を誤解してしまわないよう、定義済み(のはず)の用語を見かけたら、その意味を確認する必要があるのです。
逆に、契約書の最初に登場する定義をまとめた条項は、それだけ読んでも何の意味もないので、通読する際は読み飛ばしちゃってOKです。

条文のタイトルで内容を推測する
多くの契約書では、内容を一言で言い表すタイトルがつけられており、タイトルから内容を推測してから読み始めると、内容を理解しやすくなります。
なお、以下のタイトルは日常ではあまり用いない表現だったり、内容とタイトルが正反対だったりするので、内容と一緒に覚えてしまった方が手っ取り早いと思います。
  • Force Majeure
    不可抗力、つまり、当事者ではどうにもならないことに起因する義務違反に関する免責が定められています。たまにとんでもないことが不可抗力として列挙されていることがあります。
  • Representation and Warranty
    相手方に対して「ここに書いてあることはほんとだよ」と保証する旨が定められています。たまに神様でもない限り保証できっこないことや、驚くほど白々しい嘘がちゃっかり書かれていることがあります。
  • Assignment
    契約上の地位や権利、義務の譲渡・移転を”禁止”する旨が定められています。
  • Severability
    契約条件の一部が無効になった場合でも、他の条件は生き残る旨が定められています。丁寧な契約書だと、例外として、契約書もろとも無効になる条項を別途指定していることもあります。
  • Waiver
    権利を行使しない場合であっても、その権利を放棄したわけではない(後で行使することができる)旨が定められています。
  • Entire Agreement
    この契約が、契約締結以前になした合意よりも優先する旨が定められています。契約書に規定した内容が、交渉時の議事録等でひっくり返されるのを防ぐ条項です。
  • Whereas/Recitals
    WhereasやRecitals はタイトルではありませんが、この後ろに「契約書がなぜ締結されるに至ったか(締結の背景)が書かれている」という目印になります。とはいえ、WhereasやRecitalsには、大抵、毒にも薬にもならないようなことしか書いてありません。

全部大文字の条項
契約書の中には、全てが大文字で記載されている条項が登場することがあります。
これは、「よく読め!」という意味だそうで、大抵は原案作成者に有利な条件、多くの場合は「保証などの責任を制限する内容」が定められています。

原則例外パターン
多くの条項は、原則と例外・条件の組み合わせで構成されています。
以下の用語が登場したときは、ここから先は例外・条件だ、と認識しながら読むことで、立体的に把握することができるようになります。
  • Notwithstanding 〜,
    〜に関わらず、という意味で、Notwithstanding the foregaing,(上記の規定に関わらず)や、Notwithstanding Section 2.1(2.1条の規定に関わらず)といった形で登場します。
  • , unless 〜
    〜の場合を除き/〜しない限り、という意味で、unless otherwise agreed(別途合意しない限り)といった形で登場します。
  • , provided that 〜/, provided, however, that 〜
    (但し)〜ならば/〜という条件で、という意味で、provided that the other party uses best efforts to 〜(相手方が〜するために最善の努力を払うことを条件に)といった形で登場します。

契約書特有の表現
契約書特有の表現は上げればきりがありませんが、これだけは覚えておくと絶対に役に立つというものが一つあります。
それは、here+前置詞というもの。
契約書では、hereunderやらhereinやら、やたらとこのhere+前置詞が登場しますが、これは全て前置詞+this agreementと読み替えてください。
例えば、set forth hereinと書いてある部分は、set forth in this agreement(本契約に定められた)と読み替え、grant a right hereunderと書いてある場合は、grant a right under this agreement(本契約に基づいて権利を許諾する)と読み替えればいいのです。

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

ござ先輩のエントリーを読んで、久しぶりに法務ブログっぽいエントリーを書こうと思い立ちました。
題材は、永和システムマネジメントの例のスキームです。

このスキームを目にした方が最も印象的に感じるのは「初期費用を無料にして、運用費だけで回収する」「しかも、途中解約に制限・ペナルティはない」という回収モデルの部分だと思います。
永和システムマネジメントは、どのようにしてプロジェクトが赤字に終わってしまうリスクを回避しているのでしょうか。

1.対価の発生時期を早める
永和システムマネジメントの例のスキーム(永和スキーム)は、ウォーターフォール(最初から完成品を作る)モデルでも、対価の回収方法を変えれば実現自体は可能です。
つまり、実のところ、永和システムマネジメントがアピールしているアジャイル(ちっちゃく作った後完成品目指して追加開発していく)は、永和スキームの必要的要素ではないのです。
ただ、アジャイルはウォーターフォールに比べると最初のリリースまでの時間が圧倒的に早いため、結果として、リリース後に発生することになっている対価の発生時期を早めることが可能になります。
永和システムマネジメントは、アジャイルの特性の「ちっちゃく作って…」を、こんな面からも活用しているんですね。

2.リリース前のコストを圧縮する
アジャイルで開発する以上、最初のリリースまでに必要な工数はウォーターフォールよりもずっと低くなります。
また、純粋な開発工数以外にも、成果物の仕様が限定されているため、仕様変更に振り回される危険も低くなります。(仕様追加に至っては、「リリース後にやりましょう」と切り捨てることが可能)
さらに、著作権を譲渡しないこと、着手時点でリスクを取っているのは主に永和システムマネジメント側であることから、通常の受託開発よりもユーザーの無茶な要求に振り回されにくいという面もあるかもしれず、そうであればコスト圧縮に大きく寄与すると考えられます。
対価発生前のコストが圧縮できれば、当然立ち上げ時の赤字幅も小さくなりますよね。

3.リリース後もコストをかけない
永和スキームの紹介ページを見ると、トライアル開始されるプランSSにおいて、月次で委託できる工数は1チケット。
”1チケットで1日程度の保守・サポート対応が可能です。”とのことですので、これが1人日という意味なのであれば、アジャイルの継続開発というより、どちらかと言うと保守・サポートに近い印象を受けます。
最初のリリースから次のバージョンのリリースに1人月必要だとすると、ユーザーがチケットを買い増さない限り、1年近くかけて開発することになります。(本当の意味での保守が発生する可能性を考慮すると、1年を超過する可能性も多いにあります)
このように、リリース後にかかる工数を限定することで、黒字化までの期間を短縮できるってわけです。

なお、永和スキームの紹介ページを見ると、プランSSの料金は15万円なので、1人日15万円という前提で単純に人月単価に換算すると300万円(4年目以降は半額になるそうなので、150万円)ということになりますね…
ただ、買い増しチケットの単価は15万円よりも安いかもしれません。

4.成果物を転用する
永和スキームでは、著作権は永和システムマネジメントに留保されますので、特段の事情が無い限りコードの転用は永和システムマネジメント側で自由に行えます。
ワークフローの様な汎用性の高い案件を受注できた場合には、これを転用することで次の案件のコストをぐぐっと圧縮できる可能性があります。
ものによっては、パッケージ化してライセンスで収益を上げることだって可能になるかもしれません。

5.成長を見せることで期待感を持たせる
システム変更時には、ユーザーとしても教育や運用の変更などの対応をせざるを得ないため、たとえ開発費/構築費が0であってもそう簡単に新しいシステムの利用をやめる訳には行きません。
これに加え、アジャイル開発の下では、リリースされたシステムに要望していた機能が追加され、(運が良ければ)使い勝手も向上していくのを目の当たりにしたユーザーが「来月・来年はもっと良くなっているかもしれない」と期待することにより、さらにその効果が高まるんじゃないかと思います。想像ですけど。
当然ながら、リリース後は単月では黒字になるように値決めしているはずなので、継続期間が長期化はそのまま黒字幅になるわけですね。



このように見て行くと、目先のキャッシュだけ工面できれば、通常の受託開発と比較しても、それほど危ない橋を渡っていないように思えてきませんか?
ぜひ技術力に自信のある他社さんも、丸パクリではなく、「ご紹介キャンペーン(顧客を紹介してくれたら1年間収益分配する、とか)」「余ったチケットをコンサルティングetcに流用できる仕組み」「ボーナスチケット(汎用性のあるシステムについてはチケットを上積みしてあげる)」のような工夫を追加して新しい契約スキームを盛り上げて頂ければと思います。

ではでは〜

五回目くらいらしいBLJの読者交流会に行ってきました。

いい意味で緩く、肩肘張らずに様々な会社の法務の方からお話をお伺いできる数少ない機会の一つだと思いますので、まだ参加されたこことのない方は、次回はぜひお申し込みされることをオススメします。

さて、今回のキーワードです。
  • 自然原料を発酵させて作っているので安全です
  • 名刺が五種類
  • 表紙は坊主頭でバカ売れ
  • 前橋のイントネーション
  • 何のゲーム買ったんだっけ…

    そんじゃ、またね〜
  • このエントリーをはてなブックマークに追加 Share on Tumblr

    マイコミジャーナルでWebデベロッパ初心者がおかしがちな10の誤ちというエントリーに影響を受け、契約法務バージョンを作ってみました。

    1. 案件を止める
      案件を止めるのは依頼者や決裁者の役割で、依頼者や決裁者に正確な情報を伝えるのがあなたの役割です。

    2. 交渉の場に出ない
      10通のメールより、10分直接話した方が交渉が進展するケースも少なくありません。

    3. 根拠資料にあたらない
      条文、書籍、官公庁のウェブページなどの資料にちゃんとあたらないと、思わぬ大けがをすることがありますよ。

    4. 実務上の影響を念頭に置いていない
      理屈の上では不利な条件であっても、実務上はぜーんぜん問題ないというケースはよくあります。
      「実務上、どんな問題が生じるの?」と聞かれて答えられないような文句はつけないようにしたいものです。

    5. 回答が変わる
      同じ前提条件のもとで同じ内容の依頼を受けた場合、同じ回答ができなくてはなりません。
      これは、メンバーが増えれば増えるほど難しく、かつ重要になってきます。

    6. 税務、財務の都合を考えていない
      狭義の法務としては問題なくても、税務・財務的に問題があれば、会社としては見過ごすことはできないわけで。

    7. 自社の業務に関する知識に欠けている
      自社がどんな仕事をして何で儲けていているのかが理解できないと、契約内容も充分に理解できません。

    8. 一般名詞で定義する
      以下「ソフトウェア」という。

    9. 実現可能性を考慮していない契約条件を設定する
      エキセントリックな通知条項を見たことありませんか?

    10. メンテナンス性が低い契約条件を設定する
      構造がしっかりしている(内容によって条項が分けられている)契約書であれば、修正が必要になった場合も素早くかつ確実に対応することができます。


    例によって昼休みにちゃちゃっと作ったやつなので、ツッコミ大歓迎です。
    あと、「おまえはどうなんだ!」と詰め寄るのは勘弁してください。
    ま、いうのはかんたん、やるのはたいへん、ということですね。
    このエントリーをはてなブックマークに追加 Share on Tumblr

    先生!渾身って、どう読むんですか?ふんどしですか?


    さて、契約法務という仕事には「そのクオリティの高低が滅多に第三者の評価にさらされない」という特殊性があります。

    それが経理担当者であれば、一人しか担当者がいない場合でも、すっとぼけた仕事をしていれば顧問の税理士さんなり会計士さん(もしいれば監査法人)からお叱りを受けることになりますし、もっと言えば税務署からお叱り以上のものを頂戴することにもなりかねませんので、その仕事の品質は常に他者の評価にさらされています。
    また、プログラマなどの技術者も、成果物が使い物にならなければお客さんは激怒するわけで、「かの邪智暴虐のプログラマを除かなければならぬ」などと言われかねません。
    いわんや営業をや。

    しかし、契約法務は、びっくりするほどのひどい仕事振りであっても、トラブルが発生するまではその成果物(典型的には契約書)が白日の下にさらされることはありません。
    さらに言えば、もしトラブルが発生したとしても、間にいる自社の営業担当・相手方の営業担当という強力な緩衝材が「まぁまぁまぁ」と”運用でカバー”してくれることも少なくないため、その傾向はさらに拍車がかかります。

    そんなわけで、契約法務の担当者は、たまにびっくりするほどぱっぱらぱーな人が紛れている率が結構高いのです。
    (と、人ごとのように書いてますが、実は僕だってその一人で、上記の理由からそれを自覚していないだけかもしれません。)

    と、前置きが長くなってしまいましたが、このように法務担当者は、その実力のボラティリティがスカイツリーのように高いので、うまいことダメ法務を除外する必要があるのです。
    しかし、初めて契約法務の担当者を採用する場合は、残念ながら候補者の実力を測ることのできる人が社内にいないため、この問題はより深刻さを増します。

    そこで、ようやくこのエントリーの本題、”法務に縁のない人が使える法務担当者を採用するために有効なテスト”の登場です。
    じゃじゃーん!
    1. 実際に利用した契約書と黄色の蛍光ペンを渡し、問題と感じた箇所にマーキングしてもらう
    2. マーキングが終わったらピンクの蛍光ペンを渡し、「相手方が修正点は最低限にしてほしいと言っている前提で、それでも修正すべきと考える点」にマーキングをしてもらう。
    3. 黄色のマーキング部分について「修正不要と判断した理由」を説明してもらう
    4. 黄色+ピンクでオレンジ色になったマーキング部分について、「修正しないとどんなまずい現象が起こるのか」を説明してもらう

    この、3と4について、法務担当者ではない人によくわかるように説明することができない人や、法務担当者ではない人がすんなり納得できない理由を上げる人は、実務ではあまり役に立ちません。
    この方法なら、法務に縁のない人でも、いや、むしろ法務に縁のない人だからこそ、効果的に優良な法務担当者を選別することができるのです。
    (二人目からは、他の候補者の指摘と食い違う点について「こうは考えられませんか?」と聞くのもいいと思います。)
    ポイントは、どこにマークしたかではなく(その適切性は判断できないので)、どうしてかをちゃんと説明できるか、です。

    法務担当者を初めて採用するという方が現時点でどの程度存在しているのか甚だ不安ではありますが、見事この条件にマッチした方はぜひお試し頂き、その結果を教えてくださいませませ。

    なお、この方式では「間違ったことを堂々と言い放つ」タイプの問題児を見抜くことはできませんので、その点はご注意ください。
    (こっちのタイプはtacさんのエントリーの質問であぶりだせますね。)

    そんじゃ、おやすみなさーい
    このエントリーをはてなブックマークに追加 Share on Tumblr

    企業法務マンサバイバル : 【雑誌】BUSINESS LAW JOURNAL No.26 5月号 ― 仕様書のチェック、してますか?で、
    @kataxさんみたいに、自身でプログラムを書けるぐらい技術に通じて仕様書の中身もチェックできる人が、法務パーソンとしては理想的なんでしょう
    と言及をいただいたので、返信代わりに自分が感じていることをポストします。


    僕は今まで、システム開発やソフトウェア開発を営んだり発注する会社に法務として3社所属したことがありますが、そのいずれでも、契約締結段階で検査基準や瑕疵の基準として有効に機能しうる程度に仕様がしっかりと定められていることは稀だったと思います。
    そしてこれは、発注側の怠慢、つまり、まともな要求仕様やRFPを書かない(というか、書けない)ことに起因していたように感じます。

    このような状況下では、契約書に添付されている仕様書という名の「よろしくやっといてよ」をちょっと長くしたような書面を精査できることよりも、どのようにして(本来の意味の)仕様が定まり、変更されるのかを現場に即してしっかり定められることのほうが有意義なんじゃないかと思うのです。

    よく「現場を知らなければ良い法務にはなれない」と言われることがありますが、この「現場を知る」というのは、現場の営業や技術者と同じようなスキルを持つという意味ではなく、どのように営業や技術者が動くのかを把握するということのはずです。
    その意味では、法務がプログラミングをできるようになっても、直接のメリットはほとんど無いと思うのです。

    というわけで、プログラミングに縁遠い法務の皆様、ご安心下さい&もっと現場の話を聞こう!という趣旨のエントリーでした。

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

    javascriptプログラマのレベル10 : tech.kayac.com - KAYAC engineers' blogを読んで、法務でも作ってみたら面白そうだと思ってやってみました。
    ただ、法務と言っても僕が知っているのは契約法務の世界だけなので、契約法務限定になります。あしからず。

    -----------------

    レベル1:
    契約書の記載内容が契約条件となることは知っていますが、それ以外のことは何も知りません。
    過去取り扱った契約書を流用することはできますが、契約内容を理解していないので、必要のない条件や不適切な条件まで流用してしまうことがあります。
    また、契約条件の有機的な繋がりを理解していないため、流用にあたって変更を加えた際に矛盾が生じてしまう(文中と記名欄とで会社名が異なる、有効期間と締結日が全く違う、など)ことがよくあります。
    契約と契約書を同じものだと思っています。
    訴訟が提起されると「倒産」という二文字が頭を過ります。

    レベル2:
    口頭でも契約が成立すること、にもかかわらず契約書を取り交わす意味について理解しています。
    また、秘密保持や合意管轄などの基本的な条項の趣旨は理解していますが、各条項で用いられている法律用語や特殊な用例の意味まではしりません。(期限の利益の喪失というサブタイトルを見て、日本語として破たんしていると感じる。対当額という単語を見て、誤字だと感じる。悪意という単語を見て、俺はそんなに悪い奴じゃないと憤慨する。など。)
    訴訟が提起されると、大変なことになったな、とへこみます。

    レベル3:
    契約書で用いられる、日本語として不自然な言い回しの意味を理解しています。
    素直な日本語で書くよりも、日本語としては不自然な専門用語で書いた方が、簡単かつ正確に条件を規定できることを理解できていますが、0から条項案をドラフティングすることまではできません。
    弁護士の力を借りる必要がある場合に、自社の顧問弁護士にまともな依頼をすることができます。
    また、弁護士からの回答を読んで、何を言わんとしているかも概ね理解できます。
    訴訟が提起されると、とりあえず弁護士に連絡しようと思います。

    レベル4:
    民法・商法に関する知識の習得を始めます。また、契約書に書かれている条項の意味は一通り理解できます。
    初級法務担当者向けの研修だと退屈に感じるようになります。
    訴訟が提起されると、とりあえず訴状を一通り読んでから弁護士に連絡します。

    レベル5:
    民法・商法に関する基礎的な知識を有しています。また、契約書に含まれる問題のある条件について、修正案を作成することができます。
    弁護士の力を借りる必要がある場合に、案件によって依頼する弁護士を選択できます。
    訴訟が提起されると、まず社内の誰を巻き込むべきかを考えながら訴状を読みます。

    レベル6:
    民法・商法に関する知識を有しており、また民事手続法や自社の関係する特別法・業法に関する基礎的な知識を有しています。
    契約書の中に散らばった複数の契約条件間の論理的な矛盾に気づくことができます。
    契約書を0からドラフティングすることができます。
    内容がこってりしていない法務担当者向け研修には物足りなさを感じてしまいます。
    訴訟が提起されると、わくわくしてきます。

    レベル7:
    同じ相手方と過去に締結した契約や、関連する別の契約との平仄まで考慮に入れて契約条件を検討することができます。
    また、修正案を作成する場合は、実務上の問題が生じないレベルの妥協点を念頭において柔軟にふるまうことができます。
    さらに、相手方の法務担当者・弁護士との交渉に立ち会い、その場で折衷案や落とし所を提案することもできます。
    相手方から出された契約書案は、大抵自分が書いた契約書案よりも(有利不利の問題ではなく)出来が悪いと感じます。
    訴訟が提起されると、「訴訟提起するのは構わないけど、なんで今なんだよ。」と憤りを感じます。(但しいつでも)

    レベル8:
    立証責任のレベルで条件を調整できます。また、一見同じように見えて、手続法上は大きな違いの出る条件を設定することもできます。
    社外の法務担当者向けの研修で講師を務めることができます。
    訴訟が提起されると、相手方の代理人を見て、今後の流れを予想してみたりします。

    レベル9:
    もはや個別の契約書のチェックを自ら行うことはあまりありません。合併や大型の共同開発などの案件で、名指しで担当することを求められます。
    暇な時に法改正があると、無駄とは知りつつパブコメを送ることもあります。
    忙しい時の法改正は、パブコメを送ろうとは思いますが、気づくと期限が過ぎています。
    業界団体等の法務関連のワークグループに呼ばれます。
    書籍執筆の依頼を受けます。
    訴訟は、おもしろそうな案件かどうかが最大の注目点になります。

    レベル10:
    法律関係の雑誌に連載を持つようになります。
    研修で講師を務めると、名前で受講生が集まります。
    書籍が名前で買われるので、出版社に重宝されます。
    転職したことを伝えていない人にも、なぜか転職したことが知れ渡っていたりします。

    -----------------

    昼休みに思いつくままちゃちゃっと作ったので、レベル間のバランスや内容は結構適当です。
    おかしなところがあったらツッコミお願いします。

    ところで、コーポレート法務でレベル10を作ったらどんな感じになるんでしょうか。
    他にも、弁護士のレベル10や裁判官・検察官のレベル10なんかもあったら見てみたいですね。

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

    法務のように大量の文書ファイルを処理する必要のある職種の方に特にお勧めの小ねたです。

  • デスクトップにtempフォルダを作る
  • 改めて保存する必要の無いファイルやフォルダは、すべてtempフォルダに作成/保存する
  • tempフォルダの中身がたまってきたら、何も考えずに削除して整理する

    ポイントは、何も考えずに削除できる状態を維持することと、何も考えずに削除することです。
    例えば、メールの添付ファイルは、メーラーに原本が存在するので、一時的に外に出す場合はtempフォルダ行き。
    例えば、圧縮ファイルを解凍するときは、圧縮ファイルが原本になるのでtempフォルダに解凍。
    例えば、ネットからダウンロードしたファイルは、ネット上に原本があるのでtempフォルダに保存。
    といった感じです。

    おまけとして、タスクバーで右クリック→ツールバー→デスクトップを選択することで、タスクバーからデスクトップへのショートカットアクセスを作成できます。
    また、Winキー(田ミ)とMを押すことで、デスクトップを露出させることができます。(Shift+Win+Mで元に戻せます。MacのExposeと同じですね)

    ファイルがとっ散らかって、どれを捨ててよかったのか、どれを保存しなければならなかったのかがわからなくなってしまう方は、ぜひお試しください。
  • このエントリーをはてなブックマークに追加 Share on Tumblr

    ↑このページのトップヘ