契約書の管理・共有から契約業務を変革する「Hubble」

「契約書の管理・共有をスマートにする」ことを目指して開発されたサービス「Hubble」。契約書の作成から管理、そして共有まで一貫して行うことができるクラウドシステム。

2019年は「リーガルテック元年」と呼ばれており、Hubbleを始めとするリーガルテックが続々と台頭してきた。新型コロナウイルスの影響によりテレワークが加速し、問い合わせも増えてきているという。

今回はそんな株式会社Hubble取締役CLOの酒井智也氏にHubbleの他社との違いや今後の展望など話を伺った。

契約書の管理・共有をスマートにするソフトウェアHubble

株式会社Hubbleのミッションは「契約をデザインし、合理化する」こと。新しい法務の働き方をテクノロジーで支援している。

同社が提供するサービス「Hubble」は、主に法務が扱っているの契約書の作成~管理までを一貫して扱うシステム。三井不動産、CASIO、ネスレといった大企業にも導入されている。

Hubbleでは、契約書を始めとした法務ドキュメントのバージョン管理や共有をクラウド上でできる。今まで営業から法務、法務から管理職、管理職から役員へとメールで回覧されていた契約書がクラウド上でやりとりできるようになった。もちろん社内だけでなく、社外の取引先との共有も可能。GmailやChatwork、Slackなどとも連携ができるようになっており、情報へアクセス時間を大幅に短縮。

Hubbleの使い方

Hubbleは視覚的に操作ができるように作られている。そのため、他のクラウドサービスを利用したことのある人なら操作に迷うことはほとんどない。

クラウド上にフォルダを作成し、そこにデータをアップロードや保存することができる。そうすることで必要な人すべてがデータにアクセスできるようになり、情報の共有を容易に行うことを可能にしている。IDを作成すれば社内の人、社外の人どちらとも共有ができる。

右側にあるコメント欄でコメントを残せ、さらに@(メンション)機能を利用し、見て欲しい相手に通知を送れる。メールへの通知はもちろんのこと、ChatworkやSlackへも連携によりそれらのチャットツールへの通知も可能であることから、これまでのコミュニケーションツールから乗り換えるようなコストもかからない。

HubbleではMicrosoft Wordのデータをそのまま取り扱うことができる。

Hubbleにアップロードするデータは、Wordの形式のままでいい。これは、契約書の作成でWordが利用されることが多いという法務業界の慣習に合わせている。

慣れ親しんだ契約書作成ツールを変えることなく、契約書を管理するツールだけ変える。Hubbleはこのような使い方ができるシステムだ。

他社製品との違いーHubbleが重視するのは「シンプルさ」

Hubbleと他社製品の大きな違いは、他社は契約に関わる一業務ごとのプロダクトを提供しているのに対して、Hubbleは営業~役員の承認まで契約に関わるフローを一貫してサービスとして提供しているという点だ。

Hubbleと同じように一貫したフローをサービスとして提供している会社もある。その会社とHubbleとの違いは、お互いが提供している価値の違いだ。

Hubbleは「シンプルさ」に大きな価値をおいている。システムによっては、カスタマイズ性を重視して、ユーザーへのフィット感が高まるシステムもあるものの、その反面システムが複雑になってしまうことは否めない。どちらが良いかはユーザーによって分かれるところだが、そこがシンプルさを重視しているHubbleとの違いだ。

「誰にでも使いこなせることが重要」と酒井氏は語る。契約業務にタッチする人は会社の中で多数に及び、様々な属性が想定される。営業、法務、管理職、役員など、部署も立場も違う。そしてITリテラシーの高い人、クラウドサービスの利用に慣れていない人など、システムに対する感度の高さもそれぞれ違っている。そのような人たちがそれぞれ違った場所からHubbleにアクセスする。

そうなってくると「誰にでも使いこなせる」ことはとても重要な意味を持ってくる。視覚的・感覚的に操作が出来ることように開発されたHubbleは、複雑なカスタマイズを含まない分誰にでも操作がしやすい。そこがHubbleが「シンプルさ」を重視する所以になっているのだそうだ。

Hubbleのユーザーはどのように活用しているのか?

ユーザーのHubbleの活用方法は2ケースあると酒井氏。

中小やベンチャー企業で全社的に活用されているケースと大企業の場合は、まずは1部署~数部署の中で活用されているケースだ。

中小やベンチャー企業での活用方法はまさにHubbleの理想とする形だ。社内の契約業務を一貫してHubble上で行う。

一方、大企業のケースでは、法務部のようなリーガル部門等が活用しているケースが多い。今まで部署内でメールでやり取りされていた情報をHubbleへ移行する。大企業は組織構造上、部署ごとにセグメントが区切られている傾向が強く、他部署と共同でひとつのシステムを利用することが難しい側面もある。その場合には、まずは1部署~数部署内でのみ利用を開始してもらうことが多いそうだ。

もっとも、そのように利用を開始していくと、社内でHubbleを知ってもらうきっかけになるそう。ある部署でHubbleの評判が良ければ、他の部署にそして全社にとHubbleの噂は広まっていく。「まず1部署で使って頂いて、社内に広がっていってほしい」と酒井氏は望みを語ってくれた。

実は、Hubbleのユーザーには大企業が多いと酒井氏は語る。大手不動産会社や金融会社にも導入されている。それらの会社にHubbleが導入された決め手は「情報が散在している」「属人化していている」という大企業ならではの問題を解決できるツールだったからだ。

社内ネットや部門のフォルダ、個人のメールボックスなど、保存場所が明確に定められていないと契約書はどこに最新版が保存されているのか分かりにくい。また、「どうしてその契約条項になったのか?」といった契約外の背景に至っては、契約を締結した個人を特定しなければ情報が得られないケースも。

これらの問題に大企業の中で気づけているのは主に法務部門のマネージャ―や管理職といった決裁者。それらの人たちにHubbleの利便性が響き、大企業での導入が相次ぐ結果に結び付いた。

これからの法務のあり方ーリーガルテックの発展が戦略法務の出現を後押しする

「法務パーソンに求められる力は3つの要素で成り立っている」。自身も弁護士である酒井氏はそう教えてくれた。

まず、多くの管理系の業務の根底にある事務処理能力。次に、法務知識。民法を始めとする法律に対する高い理解度だ。正確に契約書を作成したり、レビューを行うためにはまずは正確な法的知識が必要となる。最後にリーガルマインド、法的知恵があると考える。これは法的な知識を前提に、考える力といえる。例えば、法的知識を駆使してどう自社のビジネスの発展へどう寄与していくのが考えていくような力がこれに該当すると考える。

既に、リーガルテックの発展で、事務処理業務は大幅に簡素化が進んでいる。事務処理作業から解放されることによって、法務はよりクリエイティブな仕事へ割く時間を確保することができる。

その上、Hubbleや他のリーガルテックの発展は、法務知識を得るために従来必要であった時間も大幅に短縮してくれた。今まで社内に散らばっていた法律情報がHubbleに集約されたことで、アクセスが難しかった情報や他の人の頭の中にあった情報にも簡単にアクセスできるように。

これにより、これからの法務はリーガルマインドを駆使することが求められるようになってくると酒井氏は予測している。個別の取引を超え、会社全体のリスクを鑑みた対応や、新規ビジネスで検討が必要になる法規制について、どう解釈適用することでビジネスが実現できるのか、法やルールを積極的に利用していく姿勢など、今まで「守り」の姿勢であった法務とは違った視点から法を扱う必要がある場面も増えてくるだろう。

今後は法務も「攻め」の視点から会社のビジネスに関わっていくそんな「リーガルマインドが卓越された方が活躍できるし求められてくる」と酒井氏は考えている。

Hubbleの今後の展開

2020年6月15日よりNDAの統一化の取り組み「One NDA」を発表したHubble。酒井氏は本来「契約=法人や個人のコミュニケーションの証跡」であるものの、内容があまり理解されていないまま締結されたり、本来的意義が形骸化している側面がある、「契約のかたちを変えるのはコミュニケーションの形を変えること」だと語る。

加えて、Hubble自身も近いうちにアップデートが予定されている。Hubbleで契約先との対外交渉を可能とする機能を大幅にアップデートする。つまり、Hubbleのプラットフォーム内に相手とのやりとりが全部集約されることになる。そうなると、契約に係るコミュニケーションのすべてが集約されたページができる。

契約書ができる前、契約は会話というコミュニケーションでおこなわれていた。その不確実性を何とかするために契約は紙と押印へ形を変えた。そして近年、電子契約へとさらにその形を変えつつある。

新しいHubbleの登場で、契約のあり方は本来の形に戻ることになるのかもしれない。

「契約に関わるコミュニケーションを一貫して保存することができるHubbleの新機能は、テクノロジーによって契約の本来的意義を取り戻したうえで、これからの契約のかたちとなり得る」と酒井氏はそう語ってくれた。

この記事を書いた人