約5年前、技術評論社の傅さんから「雨宮さん、橋詰さんと一緒に利用規約の本を書きませんか？」とお声掛けを頂いたことが、本書良いウェブサービスを支える「利用規約」の作り方に関わることとなったきっかけでした。

当時、書籍づくりについて、雑誌への寄稿のボリュームアップ版程度の甘えた認識しか抱いていなかった僕は、深く考えることもなく二つ返事でお引き受けしたように記憶しています。
しかし、ある意味自分が書けるテーマについてだけ好きなように書かせてもらえる雑誌への寄稿と、特定のテーマについて、実務の役に立つ解説書を作り上げる書籍づくりとの間には、その困難さにおいて大きな隔たりがありました。

豊富な実務経験と知識を持つAZX法律事務所の雨宮先生と、今では「サインのリ・デザイン」編集長として「その時実務家が知りたいトピック」をいち早くカバーすることで抜群の存在感を発揮する橋詰さんのお二人ととでなければ、良い悪い以前に、完成にまでたどり着くことすらおぼつかなかったのではないかと思います。

初版の執筆時と同様、今回刊行される改訂版の執筆の際も、共著者三名で遠慮せずに徹底的に直しを入れ合いました。中には、一度書いたにもかかわらず、「ウェブサービスの実務的には重要ではなく、ノイズになる。」として大胆に削り落とした部分もあります。
敢えて確認したわけではありませんが、すべての判断基準は、「実務の役に立つか」という点で、共著者間の認識は共通していました。

技術評論社の傅さん、秋山さんのお力添えもあり、改訂版を初めてお手に取られる方にとってはもちろん、初版をお買い上げ頂いた皆様にもしっかり価値をお届けできる内容に仕上がっていると思います。
技術評論社ウェブサイト内の本書の紹介ページからECサイトの予約ページにリンクされていますので、ぜひお手にとって頂ければ幸いです。

一人でも多くのウェブサービス運営者の方のお悩みの解決に、本書を通じて貢献できればこれ以上の喜びはありません。

最後になりましたが、技術評論社の傅さん、秋山さん、とてつもないクオリティで英語版利用規約のレビューをしてくださったAZX法律事務所の林賢治先生、利用規約・プライバシーポリシーのパブリックコメントをお寄せいただいた皆様、そして何より共著者のお二人に、心から御礼を申し上げます。

それでは！

GitHubでドキュメント管理というのはすごく「techしてる」感があって文系職種としてはワクワクするのは事実ですし、実際始めてみればレビューのスムーズさや堅牢性などの点で利便性がすごく高いのは間違いありません。

他方で

• 最初に全規程をmarkdown化するのがめっちゃ大変。特に表は、移植時に一度死に、改定時にもう一度死ぬことになる。
• 全社員がgithubアカウントを持っている会社じゃないとGitHubPages化が必要
• そもそも法務にアカウントが付与されていないと導入に際して追加費用が発生することになる
• 修正内容によっては改定箇所の強調表示が分かりづらいことがある
• 上の人がGitHubでやることをおもしろがってくれない会社では導入のハードルが高い

といった難しい点があるのも事実です。

そこで、規程管理が辛い状態だけど、GitHubを導入してなんとかするほどでもないという皆様におすすめなのが、Googleドキュメントでの規程管理です。
Googleドキュメントは、プルリク→レビュー＆approveみたいな堅牢性はありませんが、大抵の会社では全社員がアカウントを持っていて追加費用は不要で、表も箇条書きもWYSIWYGに作れます。

具体的な手順はこんな感じ

最初の準備

1. おそらくWordで管理されている最新版をGoogleDrive上に作った規程集フォルダにアップロード
2. しっかり規程のフォーマットが構造化されていればほとんど破綻なく変換されているので過去の自分に感謝する（そうでない人は過去の自分を呪いつつ体裁を直す）。
3. 規程集フォルダを閲覧権限で全社員に公開
4. 法務部員等の規程の改定作業をする実務担当者だけに編集権限を付与する。

改定手順

1. 改定したい規程を開き、提案モードで改定したい内容をガシガシ書いていく。（注：提案モードで編集した内容は、承認するまで閲覧権限ユーザーには見えません）
2. 改定案作成後、docx形式でダウンロード
3. いつものようにフォントがダサくなっているのでフォントだけ一括変換
4. 変更案が変更履歴の形式で表現されているのでこちらで決裁を取る
5. 決裁完了後、再度規程を開いてすべての提案を承諾して、リリース完了
6. うっかり編集しちゃったときに戻れるように、版の名前を「●年●月●日決議版」みたいに変更しておく

いかがでしょうか。
「えっ、マスター版を直接弄っちゃうの？」とか、「間違えて、または意図的に編集モードで編集されたら、公開されてる規程が変わっちゃうじゃん」と思った方。
あなたはまともな感覚の持ち主です。
そして、まともな感覚の持ち主であるがゆえに、規程管理みたいなどうでもい・・・じゃなかった、地道なタスクで苦しむ羽目になってしまっているのです。
重要な業務とは言え所詮は社内のルール。
何かあっても死ぬわけでもないんだし、いざというときは履歴をたどれば戻すことは可能なわけですから、ここらは一つ「こまけーこたーいいんだよ」というスタンスのやわらかな規程管理で苦しさから自分を開放してあげてはいかがでしょうか。（というスタンスが許容される規模・ステージの会社に限られるので、その点はご注意ください。念の為。）

ちなみに、この管理方法を採用すると、気になったポイントを提案モードでガンガン書き込んでいけるため、「細かいから次の改定にまとめよう」と先送りにされた挙げ句に結局忘れ去られがちな軽微修正なども確実に抑えていけますし、コメント機能で簡単な議論も可能です。
↓適当に拾ってきた就業規則でやってみたイメージ


というわけで、久しぶりの法務関連の雑記でした。

ほぼ無風だった2017年とは打って変わって、2018年はまさに激動の一年でした。
その激動の一年の締めくくりとして、12月末で現職を退任し、1月からまた別の会社に移ることになったのですが、それについては一旦横においておくとして、短いながらも人事、経理、財務、広報の入り口を垣間見るとともに、資金調達にキックオフからクロージングまで触れた経験はとても貴重だと思うので、この感覚を忘れないうちに気づいたこと、学んだことを文章に残しておこうと思います。

マニュアルは大切

やるのは自分だけ、という状況下ではマニュアル作りを後回しにしがちですが、忘れっぽい性格であることを自覚していたので、労務・経理系で大量の定型作業が発生することを見越して結構細かい作業についても自分用マニュアルを作るようにしました。
もちろん、マニュアルは手順を忘れないようにするという意味でも役にたったわけですが、それ以上に
・（特に急いでいるときに）作業の抜け漏れを防げた
・別の人への作業の引き継ぎをスムーズに行えた
・迷う時間がなくなり、作業が早くなった
といった効果を得られたことを実感しました。
「そんなの当たり前だろ」と思われるかもしれませんが、他の管理部門と比べると法務にはそれほど定型作業が多くないので、マニュアルを整備するメリットを感じる機会ってそこまで多くないんですよね。
マニュアルは標準化を必然的に伴うので、法務が標準化に今ひとつ弱いのもこういう面が影響しているのかもしれませんね。

職種ではなく、役割・機能で業務を捉える

定期的に話題になる「攻めの法務・守りの法務」や「法務のキャリアパス」は、どちらかというと、職種の観点から法務という業務を捉えています。
他方、役割・機能から法務を捉えるのはどういうことかというと、「この会社にとって必要な法務とは」という視点から法務を見るということを意味しています。
会社の規模、業種、ステージや、役員のマインド等の要素によって、必要な法務の役割や機能は大きく異なるはずなのですが、法務の中にいると、どうしてもこのような観点を失いがち（または意図的に目をそらしがち）になってしまいます。法務の側からの「こうなりたい・こうしたい」という発想ではなく、会社にとってベストな選択肢はどれなのか、という発想から機関運営、契約、知財などの業務を定義できると、「攻めの法務」とか「経営のパートナー」といったお題目以上に、法務が存在意義を発揮できるようになるんじゃないかと今は思っています。

未経験の業務に携わる難しさ

Kohei Kawaguchi@mixingale

何度か書いたことあるけど、サラリーマン金太郎(の少なくとも最初の数巻)では、金太郎が新しい仕事にアサインされるたびに大量の文献をものすごい勢いで読み込んでその業務のことを勉強するという描写が入る。ただ、あの漫画を読んでそこを教訓としてtake awayする人は少ないように思う。

2018/12/26 20:30:14

最終出社日の後、１ヶ月以上インプットのための時間を確保することも可能だったのですが、実際には人事系の書籍を数冊読んだだけで業務に飛び込んでしまったのが、今回の蹉跌の大きな原因の一つだったように思います。そもそも、自分が他の人と比べて高い成果を出せる（可能性がある）のは法務の領域だけであり、人事、経理、財務を始めとしたその他の領域では素人同然であったにもかかわらず、危機感が圧倒的に足りませんでした。そして、着任後は怒涛の業務に日々追い立てられ、時間的にというより精神的にインプットを行う余裕はなくなり、負のスパイラルを招くこととなってしまいました。
今思えばなぜ「なんとかなる」と思っていたのか不思議でならないのですが、当然のことながら、新しいことにチャレンジするのはとても難しいことであり、先人に教えを請うたり、書籍を浴びるように読んだりすることはスタートラインに立つために最低限すべきことだったんですよね。
また、新しいことへのチャレンジが難しい以上、もっと慎重に、徐々に領域を広げていくような進め方が必要だったのだろうなとも思います。もちろん、そんなまどろっこしいことをせずに突き進んでいけるスーパーな人は実際に存在するわけですが、自分はそういうタイプの人間ではないということについてはもう少し自覚的であるべきだったな、と。

助けてくれる人のありがたさ

この8ヶ月間、本当に多くの人に、色んな角度から助けていただきました。
資金調達についてアドバイスをくださったVCのパートナーの方や事業会社の投資担当者の方、人事・財務の考え方を基礎からレクチャーしてくれた元同僚の手助けがなければ何倍も右往左往することになっていたと思いますし、退任を決めた後に超短期間で転職先が決まったのも、声をかけてくれた前の上司・同僚や知人のおかげでした。
この感謝の気持ちを忘れないようにするとともに、Pay it Forward的に、同じようなチャレンジをして悩んでいる人がいたら積極的に手を差し伸べていきたいなとも思っています。

といったところで遅い時間になってしまったので続きは明日（というか、もう今日か）に。
資金調達に関して学んだことをまとめてみようと思います。

さて、前回の転職が2014年7月16日づけだったので、3年9ヶ月を経過し、そろそろ4年目に突入しようとしているわけですが、ほら、何か違和感ありませんか？

７６年に１度と言えば、そうですね、ハレー彗星ですね。
２０年に１度と言えば、そうですね、伊勢神宮の式年遷宮ですね。
７年に１度と言えば、そうですね、善光寺のご開帳ですね。
３年に１度と言えば、そうですね、kataxさんの転職ですね。
えっ？嘘でしょ？kataxさんまた転職するの？えっ？（2014年07月11日）

・・・ね？

というわけで、2018年3月30日を最終出社日としてまた転職することになりました。

これまで、日本ウリサインとか、kataxの採用決定を重要事実に含めるべきでないかについて東証が検討中とか散々な言われ方をしてきましたが、次は未上場企業なので市場関係者の皆様に於かれましては一旦ご安心いただければと思います。

で、

誰にも言ってもまったく信じてもらえないのですが、僕はジョブホッパー的に転職を繰り返すことについて1μgたりとも良くは思っておらず、それどころか、できることなら一つの会社にしっかりと根を下ろして働くことの方が、会社にとってはもちろん、本人にとっても良いと心底考えています。
えっ？嘘でしょ？kataxさんまた転職するの？えっ？（2014年07月11日）

との整合性というか、言い訳については、今回は「チャレンジ」の一言に尽きます。

2017年末に一年を振り返ったとき、これまでにないほどの停滞ぶりを目の当たりにして「これが老化というものか」と恐れおののいたわけですが、自分の意識や努力でどうにかできる範囲は限られているのでどうしたもんかと悩んでいたところ、色々あって人事・法務・広報を含む管理部門全般を見るという役回りの職を得るチャンスを得られたため、思い切って飛び込むことにしました。
こういうときは、自分にできるかどうかを考えず、自分がやりたいと思っているか、やらないと後悔しないかを基準に行動した方が良いと思うんですよね。

無資格法務のキャリアパスについてでいうところの、1-bガチマネージメントコースであり、これまでの法務としての経験を活かせる領域は限定的なわけですが、不思議と不安はそれほどなく、今はただひたすら新しいチャレンジを前にワクワクしています。

なお、会社の規模やステージに鑑みると、法務業務の負荷は全体の20%以下になることが見込まれますし、またそうしなければならないとも思うので、タイトルで「法務をやめる」宣言をしてはみましたが、このブログは今後も折に触れて更新していこうと思っていますので、今後ともよろしくお願いします。

あと、次こそ、次こそは、長く勤め上げたいと思っています！

ではでは〜

今年も残すところ2日強となった今になって、2017年がどういう一年だったのかを振り返った時、真っ先に思い浮かんだことは「成長のない一年だった」でした。
これは別に自虐でも何でもなく、ほんとうに「去年までできなかったけれど、今年できるようになったこと」が何も思い浮かばないんです。

これまで年末に一年を振り返れば、新しい分野へのチャレンジの2つや3つ自然と思い起こせるのが普通でしたし、そもそも成長することへの渇望、停滞への危機感の強さだけが自分の取り柄だと思っていただけに、年末になってこの事実に直面したときはショックを覚えました。
そして、更に良くないことは、ただ徒に1年間を過ごしてしまったというその事実だけでなく、あの時あれをやっておくべきだった、といった具体的な後悔もあまりないということです。
これは、成長することへの慣性が働いていないということであり、それはつまり、もう一度意識的にアクセルを踏み込まなければ、来年の年末にも同じことを思う羽目になるということでもあります。
そしてきっと、その時には、今感じているようなショックを受けることはないのでしょう。
こうやって人は成長することを止め、老害への道を辿り始めるのかもしれません。

比べること自体がおこがましいのは承知の上で引き合いに出すと、僕も日野原重明さんのように、生きている間中チャレンジを続けていきたいし、それができるものだと思っていたのだけれど、どうやらそれは、僕にとっては無意識にできるようなことではなかったようです。

そんなわけで、来年は、意識的に新しいことにチャレンジしていきたいと思います。

それでは、みなさま良いお年を！

12/8追記

本エントリーのアップ後に @takujihasizume さんとディスカッションした結果を踏まえ、提案１については主張を撤回します。
→捺印書面は別にいらないんじゃないかな、という趣旨です。

---

このエントリーは法務系 Advent Calendar 2017の7日目のエントリーです。

このエントリーの結論は以下のとおりです。

1. 弁護士ドットコムやリグシーに、電子契約の送付先メールアドレスを収集・管理する一般社団法人を設立・運営してほしい
   
2. さらに、その一般社団法人で標準的な契約条項を管理＆公開して欲しい

---

電子契約の送付先メールアドレスを収集・管理する一般社団法人を運営してほしい

電子契約の導入を検討する際にネックになるのが、相手方の会社としての意思が電子署名に乗っているのかがわからない、ということです。

捺印であれば、二段の推定の一段目によって本人の意思による捺印であることの推定が働くことに加え、仮に推定が覆る事実があった場合でも印章の性質上表見代理が認められる期待もそれなりにできますが、メールアドレスをキーにする電子署名にはこのような期待は通常できません。

もちろん、相手方が本人確認を行う電子署名法に準拠した電子署名を用いて契約を締結してくれればこの問題を解決できはしますが、導入負荷が重すぎて電子署名法準拠の電子署名を電子契約一般に用いるというアイデアは現実的ではないため、本格的に電子契約を導入したければ必然的にDocusignやクラウドサインのようなメールアドレスをキーにした電子署名（カジュアル電子署名）の利用を前提にせざるを得ません。

そのため、カジュアル電子署名を前提に、会社の意思をある程度確実に乗せるためにどのような対応をすればよいかが問題になるわけですが、これはもう印章が持つ力を借りるしかないな、という結論に至っています。
これはつまり、「このメールアドレス宛に送られた電子署名リクエストに応じて付した電子署名は、当社の意思に基づく電子署名ですよ」という宣言を代表者印捺印済みの書面で事前にもらっておく、ということです。

このやり方は手間と得られる効果のバランスがとれた良い方法だとは思うのですが、いかんせん各企業が独立して対応するのはあまりに非効率なので誰かにぜひ取りまとめてもらいたい。
そして、特定の事業者が取りまとめてしまうと、それ以外の事業者が提供するサイニングシステムのユーザーが利用しづらくなるので、ぜひ一般社団法人を設立し、（少なくとも外形的には）中立の立場から取りまとめを推進してもらいたいと願っています。
クラウドサインの弁護士ドットコムさん、Holmesのリグシーさん、いかがでしょうか！

標準的な契約条項を管理＆公開して欲しい

先日、永井先生とランチをご一緒し、契約法務業務の効率化について意見交換をさせていただいた際に、契約条項をウェブ上で公開し、各社がその契約条項を参照して契約を締結するようになれば劇的に業務を効率化できるのではないか、というアイデアを検討する機会がありました。
これは、

• 各企業におけるドラフティングの手間を省略できるだけでなく、
  
• （語弊を恐れずに言えば）セミプロの手による完成度の低い契約条項を修正しなければならないという面倒も未然に防ぐことができ、
  
• 標準契約やひな形のようにカスタマイズが入る恐れもないので一度内容を把握すれば次から再び読む必要はなくなり、
  
• またCreative Commonsのように重要な条件をわかりやすく利用者に提示してくれれば契約書を読み慣れていない人も適切な契約条件を選択できるようにもなる

というなかなか悪くない施策だと思うのですが、いかんせん特定の企業がそのような取り組みを始めたとしても、当該特定企業が当事者にならない契約において利用されることは期待できないのがネックです。
そこで、電子署名用のメールアドレスのDBを管理する一般社団法人が設立された暁には、各事業者から一歩引いた存在としてこの契約条項の公開と管理も担って欲しいのです。

紙＋捺印で契約書を取り交わすことを前提にすると、このような施策は紙からウェブ上の規約を参照するという歪な状態を受け入れる必要があり、あまり現実的ではありませんでしたが、もし電子契約が主流になった暁には特段の違和感はないのではないかと思います。
それどころか、サイニングシステムが契約条項のインポートに対応しさえすれば、宛型のメールアドレスを記入し、契約条項を選択し、期間等の変数部分を入力すれば、相手方に電子署名が付された完成した契約書を送付することも可能になります。

技術的には何一つとして難しいことをしていないので、しかるべき団体がやる気を出せば、さほど時間をかけることなく運用を開始できるのではないでしょうか。
クラウドサインの弁護士ドットコムさん、Holmesのリグシーさん、いかがでしょうか！（二度目）

続いてはcaracalooさんです〜

先日の法務系LTイベント「法務＆知財系ライトニングトーク2017 ＜リーガルテック祭＞」において、シティライツ法律事務所の平林先生が

Genichi Kataoka@katax

もうちょっといい方法がないか。
契約書はプログラミングに似ている
コードをモジュール化、ライブラリ化できないか
契約書も条項ごとにモジュール化・ライブラリ化できるのでは
シティライツはライセンス契約について作ってみたが、課題が見えてきた
#LegalTechLT

2017/10/05 21:08:18

※誤字修正しています


というご発言をされたのを受け、僕も日々契約書を書いていた頃に使っていた条項集を公開しちゃおうと思いたちました。
公開先はこちらです。

公開することを想定していない資料なので、実際にはめったに使わない条項も含まれてしまっていると思いますが、お気づきの点があれば教えてください〜

エンジニアとのミーティングでFacebookのBSD+PATENTSライセンスについての当社の対応方針を質問されたのですが、その時点ではこの騒動を全く認識しておらず、「えっ、初耳です」的な、法務としてはなんとも情けないリアクションをしてしまうことになったので、ちょっと調べてみました。

という書き出しでことの概要をまとめようと思ったのですが、マンサバにきっちりまとめられていたので概要はそちらを参照していただくとして、ここではこのライセンスとどう向き合うべきかを書いてみたいと思います。

【OSSと特許の関係】
ライセンス条件に従っているにも関わらずOSSの利用が第三者の権利侵害を構成するというという状況にしっくりこない方もいらっしゃるかもしれませんが、仮にOSSが提供している機能について当該OSSと全く無関係の第三者が特許権を保有していた場合、当該OSSの利用は特許権侵害となる可能性が高いはずです。
もし特許権者に悪意があったら、協力者の顔をして開発中のOSSに自分の特許権を持つ技術を組み込んでしまい、広く普及したところで特許権に基づく主張を始めるという戦術も理論上は取ることが可能ですらあります。（Apache License2.0ではContributorによる特許ライセンスが明記されていますが、第三者を通じて特許権侵害コードを組み込むことで容易に回避できるので、悪意のある特許権者に対してはあまり有効な対抗策にはならないと思っています。）

【BSD+PATENTSライセンスの意味】
BSDLでソースコード及びバイナリコードの利用がざっくり許諾されていますが、同時にPATENTSで特許権のライセンスが特に記載されていることからすると、BSD+PATENTSライセンスのBSDでは特許権はライセンスされていないと考えるのが自然だと思います。
逆に言えば、当該OSSに特許権を有していない場合は、BSD+PATENTSライセンスとBSDLに違いはないということでもあります。
だとすると、BSD+PATENTSライセンスを敢えて選択し、多くの変更要請を受けながらもこれを維持したFacebookは、何らかの特許権を当該OSS（の機能）に関して保有しているのだろうということが推測できます。
そして、もしFacebookが当該OSSに関して特許権を保有している場合は、そっくり同じ機能を持つ別のソフトウェアを当該OSSに依拠せずに制作すると、当該別のソフトウェアはFacebookの特許権を侵害している可能性が高い、ということになります。

【BSD+PATENTSライセンスを採用したOSSを利用するのは危険なのか】
BSD+PATENTSライセンスを採用しているOSS、例えばReact.jsを利用している場合、PATENTSの条件により、自社や自社の関連会社（subsidiaries/affiliates）や代理店（agents）がFacebookに対して特許権に基づく主張をすると自動的にReact.jsの特許権ライセンスが終了するということになります。
これを受けて「Facebookの競合他社やFacebookに特許権の主張をする可能性がある会社はReact.jsの使用を差し止めるべき」という指摘がなされているようですが、React.jsについてFacebookがどのような特許権を保有しているのかを把握していない段階でこのような対応をするのはやり過ぎではないかと思います。（使っても使わなくても開発に影響がないライブラリであるなら別ですが、React.jsはそういった種類のものではないと理解しています。）
というのも、もしReact.jsの利用を差し控えて、例えば自社で必要な機能を開発したり、他のライブラリから必要な機能を調達したとしても、それがFacebookのReact.js関連特許に抵触している場合は、結局特許権侵害になってしまうことには代わりはないからです（React.jsを使う限りはPATENTSに基づいてライセンスを受けられますが、そうでない場合はライセンスのない実施にしかならない）。
そもそも、PATENTSに基づくライセンスはFacebookに特許権の主張をするまで終了しないので、もしFacebookに対して特許権の主張ができそうな状態になったら、そのタイミングで初めてReact.jsの利用停止を検討すれば良いだけのことです。
さらに言えば、もしFacebookがReact.jsに関する特許権を一切保有していなかったとしたら、特許権ライセンスが終了しても、当然のことながらReact.jsの利用は妨げられません（そりゃそうだ）
このような前提に鑑みると、BSD+PATENTSライセンスへの強い反発は、損得勘定というより、優越的地位を振りかざして非合理的な主張を押し付けるFacebookへの抗議という側面が強く、その利用は別段危険なものではない、というのが現時点における私の感触です。

【まとめとお願い】
BSD+PATENTSライセンスの存在をしったのもつい先日のことで、リサーチもウェブ上の資料を当たっただけなので、僕自身の特許に対する知見の欠如も相まって上記の内容に重大な誤りや勘違いが含まれている可能性があります。
にも関わらずこうして記事に書いたのは、偏に「間違いがあれば早めに気づきたい」という一心によるものなので、ぜひ間違っている（ようにみえる）ところがあれば、コメントやTwitter等でご指摘頂けるとうれしいです。

ではでは