【これが契約DXのロールモデル】「Legal Innovation Conference ～法務DXの壁を越えろ～」イベントレポート

最初に、ビットキーという会社について、少し紹介させてください。
弊社は2018年8月に創業して、現在240名ほどの社員がいる会社になっております。様々な企業さまに出資していただいております。
弊社のミッションは「Connect Everything」ということで「テクノロジーの力で、あらゆるものを安全で便利で気持ちよくつなげる」ということをミッションにやっています。

そんな当社において、我々リーガルが求められていことは「組織集団エージェントであること」です。
これはつまりどういうことかというと、以下のイメージです。

「ん？ちょっと長いけど何かな？」ということなんですけど、これは、サッカーで例えた時に、どうやってスペシャリストである選手、つまり事業部門にピッチで試合に集中し続けてもらうのかを具体化させた表現です。

そして、私たちはスペシャリストが面倒だと感じることを「極限まで刈り取る」ことで、そのミッションを実現しようというふうに考えています。

例えば、どういうことをやるのかなという話なんですけど、よく「これで契約締結をしていいですか？」と、決裁申請書類を依頼部門が作ると思います。ここを、弊社の場合はリーガルチームが作ります。このリーガルが作った決裁申請書類を依頼者のレポートラインで確認・承認をするという流れをとっています(※)。

更に、最終承認の完了確認をするのもリーガルです。
リーガルが自ら、最終承認が完了したことを感知したら、そのあとのプロセス、製本・押印・郵送も、リーガルで文字通り自動的に行っています。

このように、リーガルのチームとして求められていることは何かというと「契約書の決裁申請書類をつくれるほど、ビジネスの交渉に入り込んで契約書を作成する」ということになります。

そして、もう一つ、面倒さを極限まで刈り取るために「依頼者が安心して忘れられるほど抜け漏れのない安定的なオペレーションを実施していくこと」が求められています。
ただ、こちらには課題があります。リソースの問題です。
現在リーガルメンバー、2.5人なんですけれども、契約審査の依頼は月に100件あります。

この100件をどうやって処理していくのか。その解決の糸口が契約DXでした。ここからはこの契約業務のDXのポイントをご説明します。具体的には三つあります。

まず最初に、二つの管理簿を作成しました。この二つの管理簿でフローとストックをそれぞれ管理することを目的としています。

フロー管理として、依頼の管理簿を使っています。依頼の受付から依頼の完了までのステータス管理をしています。具体的には、依頼管理簿に入力されたデータを元に、Googleスプレッドシートの関数でステータスを自動更新し、ステータスを常に最新に把握するということをやっています。

一方、ストック管理は、契約管理簿になっております。社内外で合意して、契約書の決裁段階まできたものだけを管理するという管理簿です。これは、一意の管理番号に対して、管理項目を紐付けて管理しています。そのため、いつでも経緯と結果が取り出せるというものになっています。

二つ目には、これら管理簿への入力をすべてフォーム経由にしたということです。
例えば、このような三つのフォームがありまして。このフォームで取得したものを全て、前述した管理簿に流し込むというコントロールをしています。フォーム経由にすることで、項目に抜け漏れがなくなる、条件分岐をコントロールできるというメリットがあります。

最後、三つ目なんですけれども、一定条件を満たしたときに、メッセージを自動送信するようにしています。これは、例えば「契約書の保管が完了しました」となったら、依頼者に自動でメッセージを送信して「締結済み契約書のPDFをアップロードしたHubbleのURLはこれです」と、自動でメッセージを送るような流れです。
メッセージを自動送信にすることで、案内漏れを防ぐ、コミュニケーションコストを下げるという効果が期待できます。

これらの三つ①管理簿をつくるということ、②管理簿にフォームから流し込むということ、③一定条件を満たしたら自動でメッセージを送るということに対して、利用した主なツールがGoogleスプレッドシート、Slackワークフロー、Hubble（ハブル）ということになります。

これで本当にそんなにできるのかと思われるかもしれないんですけど。先ほどお見せした管理簿に流し込むフォームも、自動メッセージも、どちらもSlackのワークフロービルダー機能を利用して実装できます。

ということで、たぶん、お察しの良い方については「この人、めちゃめちゃSlackのワークフロービルダー機能を使っているな」と思われたかもしれません。
どれくらい使い込んだかというお話は、Legal Ops Lab（リーガルオプスラボ）で取材を頂いたので、そちらで詳しくは記事の公開を待っていただけばと思います！

なぜ、私が、こんなにSlackのワークフロー機能を使うことにしたか。それは弊社のリーガルチームは、依頼者の面倒を刈り取るということをすごく重視していて、依頼者の体験を本当に重視したからです。
その結果として、レビューを依頼するときと、契約の締結が終わったときの依頼者の体験を二つ、分けて考えることにしました。

つまり、レビュー依頼時は「Slackから依頼者を動かさない」ということを重視しました。
このため、例えば、レビューして欲しいよというときに、Wordファイルは依頼者がHubbleにアップするのではなくて、依頼者がSlackのスレッドにファイルを貼ると、リーガルがHubbleにアップロードしてURLを通知するという流れにしています。

一方、契約締結後は、Slackではなくて、むしろ、すべてHubbleで検索してもらうことにしています。やはり、バージョン管理ができているので、契約締結後はHubbleで検索した方が、依頼者としては使いやすいということが分かったからです。
なお、依頼者がHubbleで検索を容易にするための工夫として、ドキュメントの名前を、保管時に統一するようにしています。具体的には【管理番号＿締結日＿取引先名＿契約書名】で保管するというルールを徹底しています。

以上が、当社の契約業務DXの事例です。
ありがとうございました！

ありがとうございます。
当社が最初にDXやリーガルテックの導入を考えたときの課題は大きく二つあります。
一つ目が、Wordの修正履歴をつけない、サイレント修正がどうしてもあるよねという話。二つ目が、依頼部門から「最終版のWordファイルが欲しいんだ」という依頼がとても多くて。最終版のWordファイルをどうやって統一管理できるかなというのが大きな課題でした。このため、まずはそこに焦点を当ててやろうとなりました。

そうですね、実際に、推進する法務としては、「点」から着手しました。
ただ、進めていく中で、点だけで本当に会社全体として良くなるのかなというところが、やはり課題として感じるところが大きくなってきたので、今の形に落ち着いたなと思います。

そうです！
やっぱり、最終的には、私たちって何を目指しているんだっけというところで。依頼者の体験だよねと。全部繋がっていないと体験が良くならないねと。

依頼者の方々からすると「法務はなんで、そんな契約管理をしたいって言うんだろう？」という疑問が大きかったと思います。共通理解を得られていなかったことが、一つの障壁だったのかなと、今になって振り返ると思います。

法務をやっていると当たり前だよねということも、もしかしたらちゃんと伝わっていないのかもと思って、「契約はなぜ締結するのか」といったセッションを会社でやったりしました。
ウェブで大阪の他拠点のメンバーにも参加してもらって、40人くらいに質問を当てるっていうことをやりました(笑)。「改めて背景を理解できた」「証跡を残す重要性を実感した」といったお声を頂きました。

すごくあると思います！
結局、DXするって何がいいかというと、ステップが明確になることだと思います。契約書が必要だというのはこういう条件で、そしたらこのようにレビューして、このように契約書の決裁をとって、締結完了ですといった、各ステップがすごく見やすくなります。
依頼者にとっても、代表にとっても、非常に見えやすい形に型化されるかなと思います。

先ほど申し上げた依頼者に対する勉強会というのは、私はHubble導入後に実施したのですが、元々そういうことに取り組んでいれば、もっとスムーズにリーガルテックの導入の話にいけたのかなと思いました。依頼者側からも、もっと声をもらえたかもしれません。
そうなれば経営に対してもっと費用投資対効果の部分も含めて説明しやすいということは、他社さまでもあるんじゃないかなと思います。

ありがとうございます。約半年かかりました。
ちょっと長いかなというふうに思われる方もいらっしゃると思いますが、最初の3カ月と、後半の3カ月で、方向転換をガラっとしたというのもあって、トータル半年かかっています。

最初の3カ月は、私がまだ依頼者の体験を重視しきれていないところがあって、冒頭で申し上げた決裁申請も依頼者につくってもらうというフローでした。
ただ、それだと、やはり手間だという声があって。どうしたらいいかというディスカッションを依頼者と重ねた結果、今の形がいいねとなりました。そのために、それまでつくったフローを、一回捨てることになったという背景があります。

依頼者が契約書をレビューするときに「こういう案件の内容で、こういう条件なんです」という情報をSlackのワークフローからフォームに入力してもらっていますが、この情報はずっとリサイクルして使い続けていきます。リーガルが契約書の決裁申請をつくるときもリサイクルします。
このため、二重管理にはならないですね。

また、フォームを入れるチャンネルが複数に分かれていて、情報管理の観点から、依頼者は「ここのチャンネルしか見れない」と分けています。依頼者の間では壁があるという状態で運用ができていますね。