これがビットキー法務DX！Slackワークフローで実現した契約業務オペレーション自動化！

はい、まずは契約書依頼の場面がわかりやすいので、そちらをご説明します。
弊社のSlackには「各事業部門とリーガルチームのやりとりをするチャンネル」があるので、依頼部門は、そのチャンネルから依頼用のワークフローを立ち上げます。

はい、このため、まずはどの案件にも共通の情報を入力してもらいます。依頼部署、契約相手方、レビューの締切、契約の類型、自社雛形からの変更案件か否か、などですね。
ちなみに契約書の類型は、法務の中で類型ごとに割り振りを決めたり、CEO承認が必要かを確認することに利用しています。

申請を出すと、申請したチャンネルにそれぞれ入力内容が返ってきます。
それと同時に入力された内容は、法務が管理するスプレッドシートにも一覧化されます。
ちなみに、レビュー本体ではないですが、ここで得た取引先の情報を、別のシートにも飛ばして反社チェックが完了しているかも確認できます。もし完了していなければ、別のワークフローからリーガルチームが反社チェックの申請依頼を依頼者に出します。

まさにここから個別の契約によって条件分岐が走ります。
例えば申請した契約がNDAだった場合には、法務がレビューするために、開示目的や開示する情報といった追加情報が必要です。このため、申請後すぐに申請したメッセージのスレッドに、自動で「NDAの場合には、フォームを入力してください」というメッセージとともに、別途NDA用の情報入力フォームが立ち上げるためのボタンが出ます。
このように自動メッセージに促される流れで、NDAの場合は、依頼者がフォームを立ち上げて必要情報を入力します。

その通りです！
具体的には、Update a spreadsheet rowというSlackワークフローとGoogleスプレッドシートの連携機能があるので、これを活用しています。なお、ここで取得した情報は、この後ご説明する、決裁書作成の際にもリサイクルしてそのまま使うようにしています。

いえ、このおおもとのシートは、リーガルとアカウンティングのチームだけに公開しています。
とはいえもちろん依頼部門も一覧化して確認はしたいと思うので、最初に取得した依頼部門の情報をフックにして、各部門の案件だけを別のシートにそれぞれ書き出しています。
細かい話ですが、ImportrangeとQueryいう関数をスプレッドシート上で使っています。

条件分岐のパターンは240種類ですね。
ただ、これは契約類型だけではなく、この後ご紹介する締結の場面なども含めての数です。ここはフロー構築の際に最も悩んだところでもあります。

はい！基本的に申請したスレッドの配下で実施しています。

私が気づいたタイミングで、元のスレッドにリンクを入れるようにしています。
ただ、その様子を見てなのか、依頼部門の方もほとんど元のスレッドに続ける形でコメントしてくれますね。実際全てのやりとりを把握するという意味では、依頼部門にとっても元のスレッドに書き込んだ方が便利ですからね。

基本的に契約案件はレビューに3営業日を頂いて調整しています。
ただ、その例外として「ロケットスタート🚀」という制度があります。依頼部門の「急ぎの案件」にどのように対応するかという悩みに対する当社の解として生み出した制度です。

依頼部門の申請者が当日中にリーガルチームにチェックして欲しいなど「急ぎの案件」の場合には、「ロケット🚀」のスタンプをクリックします。そうするとその依頼部門の上長にメンションが飛んで、本当に急ぎなのかを確認する、という流れです。

各部門ごとに一週間で使える「ロケットスタート」の回数が決まっているので、事業部門側で、ビジネスの観点で本当に急ぎかどうかをきちんと判断してもらうことができます。

前提として、公平で公正なチームでありたいと考えています。
社歴とか、私とランチに行ったことがあるとか、そういったことで頼みやすくなったり、お願いできてしまうといったことはなるべく避けたいなと考えていました。
そして本当に急ぎなのかは、事業部門にしか判断ができないと思うので、現状の制度になっています。

その通りです。極限まで依頼部門の負担を減らす、というのが経営からリーガルへの要請なので、あまり他の会社では例が無いかもしれませんが、決裁書もリーガルチームで作成しています。

はい。まず契約内容が固まった際には、リーガルチームの方で、これまでの管理番号とは異なる「承認番号」を発行します。

そして、最初の申請依頼のスレッドに、決裁用のスタンプを法務がつけます。
そうすると、決裁申請用の入力フォームが立ち上がり、リーガルチームがHubbleで管理している最新版のURLなどを入力して、合意に至った最終版を改めて特定します。

その後自動メッセージで、今度は依頼部門に入力してもらいたい情報の入力フォームが、依頼者にメンションがついた形で立ち上がります。
依頼者に、取引先とやり取りしないとわからない情報、例えば押印の種類や締結の様式（紙or電子）などを入力してもらいます。

はい。依頼部門から情報が収集できたら、改めて法務の側で、形式不備がないかをチェックします。

チェック後、「形式チェックOK！」のボタンを押すと、Select a spreadsheet rowというSlackワークフローの（Googleスプレッドシートとの）連携機能により、契約書レビューの申請時に依頼者が入力した案件情報など、これまで蓄積した情報がスプレッドシートから引っ張られる形でSlackのスレッドに表示されます。
法務内での確認を経たのち、これを決裁ツールに転記して申請完了となります。

契約業務に関しては、先程の「ロケットスタート🚀」1個だけですね。
依頼部門に数多いスタンプを覚えてもらうのは現実的では無いので。

上記も含めて残りは全てリーガルチームで押します。
とはいえ毎回発生する重要なものは数種類しかないので、元スレッドにスタンプを押すというルールが守られれば、法務も残りのスタンプの意味を忘れてもマニュアルを見れば問題ないという感じですね。逆に依頼部門は、本当に「忘れられる」と思います。

安定的なフローの構築のために「例外も全てフローに組み込む」ということを実施しています。

想いは最初からありました。
ただ、本当に頻度の少ない例外は、出会ってみて初めて気づくものなので、リリース時は7割くらいの完成度です。実際に遭遇してみてチーム内で「法務としてもっとできたことがあったのではないか」と考えた上で、例外もフローに取り込んでいくようにしています。

例えば、取引先に紙の契約書を郵送する場合に、もし依頼部門側で同じタイミングで送った方が良い書類があれば、当然同封して送った方が取引先の期待感にも合いますよね。
なので、ワークフローの最後、契約書面を送付する旨のメッセージとともに、「同封したい書面があれば教えてください、一緒に送ります」とのメッセージを返すようにしました。小さなところですが、常にリーガルチームとしてできることは、このワークフローに込めています。

契約業務については、もうほとんど例外は出てこなくなりました。
おかげさまで事業部門の皆様からも便利になった、との声を頂いています！

冒頭で少しお話ししましたが、契約業務の周辺ですごく非効率な点が目についたので、改善しました。
チェック完了まで従来は3営業日かかっていましたが、これが約1営業日まで短縮されました。こちらでも例外パターンは少なくなってきて、完成形が見えてきてきます。

正直自分でもよくわからないところがあるのですが（笑）、今になって思うと「自分の課題意識」と「解決方法とのちょっとした出会い」そして「アイディアの種とのちょっとした出会い」が化学反応する瞬間があって、これを実行するのが楽しい、ということはあるかもしれません。

さらに加えるとすると、法務アシスタントの業務をより充実させたいという部分もあるかもしれません。アシスタントの方々はミスなく業務をこなすのが当たり前とされていて、それが逆に難しい部分もあります。

そんな方のオペレーションを安定的に実施するようにサポートし、効率化したことで余裕が出た時間を、別のトレーニングの時間に充ててもらい、少しでも成長してもらうというイメージでしょうか。
実際に法務経験がこれまでなかったアシスタントのメンバーもこのフローの構築後、どんどん契約レビューの幅を広げてくれて、私も助かっています。