今回ご紹介するのは、「Hubble」というリーガルテックサービスです。
契約書などの法務ドキュメントを共同管理することができ、作成・編集のナレッジを溜めて活用することもできます。
サービス概要について
いつもどおり、早速図解から。
図解してみる
サブスクリプションモデルですが、特徴的なのは上の方。
バージョン管理がしにくい法務ドキュメントを一箇所に集約
会社の業務をやっていると、あらゆるドキュメントが量産されていきます。
その中でも、顧客先との契約やNDA、利用規約、社内規則などの「法務ドキュメント」は内容が日々に更新されていくんですね。
自分一人で編集しているならまだ良いのですが、色々な人がチェックをして中身を更新していくことがザラ。
そうすると、普通にファイル管理しているのでは、
・どれが最新なのか
・最新のファイルはどこの収納されているのか（メールなのかクラウド上なのか等）
・どの部分をチェックするか
等々、ドキュメントを更新していくたびにコミュニケーションコストが嵩んでしまい大変です。
Hubbleは、この辺に注目してファイル管理をHubbleのサービス上に集約し、時系列順にファイル変更履歴をたどることができるUI/UXでバージョン管理を容易にしています。
しかも、ファイル単位でHubble上でチャットによるコミュニケーションが取れるようになっており、ファイル更新・管理がスムーズにできるようになっています。
自動で修正箇所の差分が表示される
また、ファイルを更新すると、どこを修正したかという差分が自動で表示されるようになっています。
何も対策せずにファイル更新してしまうと、更新前のファイルと見比べながら内容をチェックしなければいけないところ、ひと目で更新内容がわかるのは楽でいいですよね。
ツールを使うためにゼロコストで導入できる強み
もっとも、修正差分の管理はWord単体でもできます。
常に同じファイル１つだけを使って編集するのであれば、ファイル内部でバージョン管理もある程度できますし、Google Docsなどを使えばリアルタイムで共同編集したり、編集履歴を残すことも可能です。
しかしながら、 こうした機能をフルに使うには、ユーザー一人ひとりが使い方を覚えてツールを統一しなければなりません。（しかもUI/UXが微妙。）
典型的なところで言うと、契約書管理は契約の相手方もいる話なので、相手にまで同じツールを使うこと（「Google Docs使ってください」など）を強要することもできません。
要は、機能を使うためにユーザーが払わなけらばならないコストが高いのですね。
Hubbleがスゴいのは、UI/UXを徹底的に磨き、こうした機能を使いやすくリデザインし提供しているところ。
ユーザーが使うツールはWordでOKなので、新しく習得すべきスキルはありません。
しかも、Wordはほとんどの人が使うPCに入っているので、Hubbleを導入するだけで劇的にファイル管理をラクにすることが可能。
ユーザー一人ひとりがツールを使うために払うコストがほぼゼロなんですよ。
使うべき機能を見極めて不要なものを削ぎ落とし、使う機能の利便性を徹底的に突き詰めて、高品質なサービスを提供しているところが良いなと思いました。
法律面について
Hubbleのサービスに関連して、法律面の話を２つします。
サブスクリプションモデルと契約解除の話
本ブログでもたびたび登場しているサブスクリプションモデルですが、特に問題がない限り自動更新されるものがほとんどです。
サービス利用をやめたい場合は、事前に申し込むことで継続利用を停止することができます。
しかし、様々な事由で契約更新をすべきでないと判断した場合には、契約解除のフローをしっかり決めておかないと意外とやっかいです。
普通に考えると準委任に引きつけて任意解除権で処理すればよく、あとは損害賠償で解決すれば良さそうなんですが、継続的契約に関しては内在的制約があるとして任意解除権を制限する判例も散見されるところ。
ユーザー側が規約違反行為をしたとしても、ただちに任意解除権を発動できないケースが考えられるのですね。（提供者側が「サービス提供を継続できない」と考えた場合にも発生する問題です。）
この辺はしっかり契約書に落とし込むか、考えられるケースを想定してフローを決めておくと良い感じです。
SLAについて
Hubbleに限った話ではないのですが、クラウド上で提供されるサービスに欠かせないのがSLAです。
SLAとは「Service Level Agreements」の略で、定義された可用性以上でサービスが利用できるよう努力することを合意する（もしくは保証する）ものです。
AWS（Amazon Web Service）を例に取りますが、基本的にAWS上で展開するサービスは以下のような構造を取ります。
ここで、AmazonのAWSに障害が起きると、利用者はサービスにアクセスできなくなり、サービス提供者はサービスを提供することができない状態になります。
サービス提供者としては、Amazonに「サービス提供できなかった分の補償してくれや」と言いたいところですが、Amazonも「いやーサーバー障害はある程度しょうがないとこ、あるんすよ」と。
そんな両者の間で結ばれるのがSLAで、「これくらいのサービス品質でサービス提供できるように努めます」という約束をするわけです（「1.」の契約に附随して締結される）。
その約束が守れなかった場合（障害が発生した時など）には補償をするわけですが、補償の内容や範囲が限定されていることがほとんどです（でないと莫大な損害を補償しなければならないので大変）。
実際、8月23日にAWSに障害が発生して数時間サービスが使えなくなる事態が起こりましたが、障害時間に対応する返金・バウチャーの発行等にとどまったと見られています。
つまり、サービス提供者としては、利用者からのクレームをAmazonに投げることができないわけです。
なので、こうしたトラブル時の対応フローを定めておくと、有事でも慌てず済むわけですね。
手っ取り早いのは、「3.」の契約中に責任制限・免責事項として、こうしたトラブルがあっても一切保証しませんと規定してしまうことです（無効判断がされるかはさておき）。
もう少しユーザーに寄り添って、利用できなかった時間に応じた返金対応や、ユーザー窓口の設置などの対応をすることも考えられるでしょう。
ある意味ユーザーからの信頼を強固にする機会でもあるので（クレームをきっかけにファンになっってもらう手段は常套）、この辺の対応がしっかりしていると好印象を与えられそうです。
今後の展開について
さてさて、今後のHubbleの展開について妄想考察してみるお時間です。
横展開とか外国語対応とかは考察する必要がないと思うので、それ以外で２つほど。
変更履歴を学習させて自動修正機能を実装する
まずは、Hubbleで管理される変更履歴を上手く使う方向性です。
想像ですが、Hubbleを使う企業・事務所によって修正する箇所や文言などの特徴が出てくるはず。
これらをまとまったナレッジとして共有・活用する仕組みは今まで無かったはずなので、何らかの仕組みを入れて、Hubbleを使うチームならではのナレッジを「見える化」することで、メンバーの入れ替えがあってもその特色を継続的に活かすことができそうです。
ある程度データが溜まったら自動修正機能が使えるようになるとクールですが、そこまではなかなか難しいですよねー。
現実的には、契約書を類型別に分類して、どの契約条項の修正が多く、その場合はどのように修正しているかとか、同じ文言を修正するときはどの文言を使っているかとか、その辺を一覧できると面白そう。
GitHub的なプラットフォームはとっても面白そう
少なくとも僕のまわりの修習生や受験生では読んでる人が多い、水野祐先生の『法のデザイン』。
この本で触れられている「GitLaw」の思想と、Hubbleはかなりフィットしそうだと思ったのですね。
GitLawの思想とは、超ざっくり言うと、「みんなで法律の中身を作っていこうよ！」という考えのことです。
法律というのは、内閣提出の法律案について言えば、その具体的な中身は各省庁で決められています。（法律案の原案を各省庁が策定し、諸手続きを経て国会で審議・決定される）
ですが、法律というのは私人である私達一人ひとりに関わりのあるものであり、みんなで議論・策定した方がコンセンサスを取れるはず。
こういう考え方は「オープンソース」「オープンデータ」の外に開いていく思想にとても近いのですね。
で、プログラムの編集・改良をオープンにして、ソースコードの変更履歴等のバージョン管理をしやすくする「GitHub」というオンラインプラットフォームを、法律にも持ってこようという考えに至っているわけです。
（アメリカのGitLawはなぜか404で見れなくなってます。）
実際、Hubbleの酒井さんもこんなことを呟かれていました。
常々、法文はプログラムに似ていると思っていて、GitHub的な仕組みでオープンにひな形を作成できるプラットフォームがあれば楽しそうだなと思っていたんですね。
そんな中、僕は（恥ずかしながら）とあるセミナーで初めてHubbleの具体的な内容を知ったのですが、そこでまず思ったのが「Hubbleの仕組みをうまくWeb上に持ってこれれば、そんな環境を実現できるのではないか」ということでした。
この「GitLaw的なプラットフォーム」に期待しているのは２つで、①法律などの策定の軌跡を国民が気軽に見られるようにすること（意見や改定案の提示なんかもできると尚良い）、②各種契約書の雛形をここから発信すること、です。
①は先ほどの説明から想像がつくと思うので、②について少しだけ。
「トリトンの矛」の記事で触れたのですが、 NDAのひな形が世に溢れていて、当事者間で微妙な文言の調整に難航して非効率な場合が散見されるので、ガイドラインとして経産省がNDAのひな形を公開したという流れがありました。
これは、経産省という権威性のあるところがひな形を出すことで、契約書の標準化を行った例です。
この流れを「GitLaw的なプラットフォーム」主導でやろうという話。
法律家の知恵を持ち寄って作ったひな形であれば、その内容の信頼性は担保されるはずで、それをみんなが使うようになれば無駄なコストが発生せずハッピーじゃんという。
（とはいえ、類型化されないような契約書については各事務所の内側に溜めておきたいと思うので、すでに公開されているような、コモディティ化した契約書類型に限られるとは思うのですが。逆にそういうモノにこそ、このプラットフォームの利用価値がある。）
まとめ: Hubbleは文化を作れるか？
もうねー、正直なところ、企業や事務所（特に事務所！！）がWordから離れる可能性なんて無さそうだし、の割にファイル管理めんどくさいし、みんなHubble使ったら幸せになれると思うんですよね。
「01_業務委託契約書（〇〇株式会社）0601_田中作成_山本修正0610v2」みたいな謎のファイル名、誰も見たくないじゃないですか。
（余談ですけど、僕もライターの仕事を業務委託でいただいて執筆していて思うことで、先方が複数名でチェックしていると、こっちで修正するときにどの意見や改善案を取るべきか判断に迷うことがあるのです。クラウド○ークスなどにライター業務発注している会社さんは、みんなHubble導入しましょう、ね。）
（さらに余談ですけど、GitHubをMicrosoftが買収したように、Hubbleも将来的にMicrosoftが買ってくれて標準機能になったら最高）
個人的には、GitHubがオープンソースという文化を作っていったように、Hubble（とGitLaw的なサービス）には、GitLawの思想に根付いた文化を醸成する素養があるんじゃないかと思っています。
これからの展開が非常に楽しみです！
コメント