契約審査のワークフローはあえてキレイな形にしない 自社の課題と徹底的に向き合うことで見つける最適解-ロコガイド 片岡玄一法務部長-<前編>

法務業務の多くを占める契約書の審査業務。ワークフローを試行錯誤している方も多いのではないでしょうか?

日々多くの契約書をレビューする法務部門では、キレイなフローを作ることがベストだと思うかもしれませんが、株式会社ロコガイドでは異なるアプローチを取っています。

自社の課題と向き合いアップデートし続けることが大切だと語る片岡玄一氏に、契約審査の方法を伺いました。

目次

法務に相談してもらえば100点 情報は固有のIDで一元管理

山下 俊

本日は宜しくお願い致します。さっそくですが、御社の契約業務のフローについて伺いたいと思います。事業部門から依頼を受けるときにはどのような手段を取られていますか?

片岡 玄一

入口は「何でもいい」としています。口頭でもメールでも、Slackでも何でもいいよと。ただ実際には、9割5分がSlackですね。SlackにLegalというパブリックチャンネルを設けて、依頼を投げてもらっています。

法務の方では、メールで来たものも口頭で来たものも全てSlackのパブリックチャンネルに集約しています。M&Aなど秘匿性の高い案件だけ、プライベートチャンネルやメールでやり取りするイメージです。

山下 俊

なるほど、基本的にはそのチャンネル内の情報は、皆さんが見られる状態になっているんですね。受け付けた後、修正案を返す場合など依頼者とのやりとりもそのままSlackで行うというイメージでしょうか?

片岡 玄一

そうですね。法務チームとしては、依頼されたポストにスレッドで返信すると決めていますが、依頼者には求めていません。ルールとして徹底するのは難しいためです。

この点に限らず、依頼者に対しては、法務への依頼に関するルールを極力設けないようにしています。その理由は、法務に相談する敷居を下げて、とにかく話をもってきてもらうことに重きを置いているからです。

どういうやり方でもいいから、法務に相談を持ってきてもらえば、それで100点としようと。

片岡 玄一

ただ、同時に、対応履歴を追跡できる状態を作ることは案件管理上必須なので、法務側で各案件にユニークなIDを振って、スレッドの中に記載する方法でその対応を行っています。

こうするだけで、IDさえわかればその案件に関するやり取りを検索できるので、スレッドが分断されていたとしても情報の散逸は防げます。このIDは、Googleドライブ内に案件ごとに作られるフォルダの名前にもなっていて、そのフォルダ内に、案件に関係するリサーチ結果や契約書のドラフト、依頼者から渡された資料、相手からきたコメントを含めたドキュメントなどを全て保管しています。

各案件に自動で振られるIDをハブにして、ツールが複数に横断していても検索で辿れるようになっている。

真面目な方が損する仕組みにはしない

依頼時の自由度が高そうですが、「こういう項目を埋めてきてください」といった申請フォームを設ける方法は取らないのでしょうか?

片岡 玄一

過去在籍した企業でそのような運用をしていた経験もあるのですが、この方法は真面目な人が損する仕組みになりがちなので、意識的に避けています。

真面目な方は一生懸命考えて項目を入力してくれますが、そうでない方は悪気なくフォームを無視して依頼しがちです。依頼を受けた以上、法務としても「フォームを埋めて再度依頼してください」と突き返すわけにもなかなかいきませんし、そもそもピントがずれた内容でフォームが埋められた依頼も受けざるをえないものですから。

片岡 玄一

契約審査について言えば、法務部門の競争相手は、外部の法律事務所です。そして、「この項目を入れてくれないと依頼を受けません」という法律事務所は存在しないので、そういった観点からも決まったフォームに埋めさせることが合理的なのかは、一考の余地があると思います。

なお、このようなルールやフォームがなくても、法務が欲しい情報を初手できっちり網羅して依頼をしてくれる方も勿論いるので、そういう方はめちゃめちゃ褒めますね。「やりやすかったです、さすがですね!!」って。依頼をくれた方の上司をCCに入れてメール送ります。

山下 俊

すごいですね、事業部門の方を褒めるというか、盛り立ててあげるイメージですね。

片岡 玄一

盛り立てる意図があるわけではなく、とにかく「話を持っていけば、あとは流れでなんとかしてくれる」をベースラインにしているので、それを越えてくれたらシンプルにありがたいという感じですね。

山下 俊

法務側からすると、キレイなワークフローが作りたくなると思うのですが、そういった方向とは完全に逆というか。

片岡 玄一

キレイなワークフローを作ろうという意識はないですね。先程例に出たフォームに必要項目を書かせるような運用もダメというわけではなく、例えば大規模な会社だと、そうでもしないとさばききれないという事情もあるのではないかと思います。ただ、今の当社ではそれがベストなやり方ではないというだけのことです。

その意味で、当社の運用が常に正しいとも思っていません。全ての施策は課題を解決するためにあるものなので、今の当社の課題を解決するために何が適切な運用なのかだけが、私が気にしているポイントです。

片岡 玄一

ワークフローについても、そこにある課題を発見して、その解決のために最適な施策を考え、施策の運用開始後も常にアップデートし続けることが重要だと思います。

私は、現時点の当社におけるリーガルチェックに関する一番の課題は、「法務に依頼すべき案件について依頼されないこと」だと考えているので、その課題に対応するためにこういった緩いワークフローになっているわけです。

山下 俊

「規模」という話も出ましたが、片岡さんとしては、社員数何人くらいまでだったら、こういったフローで回っていくと思いますか?

片岡 玄一

実際は社員数だけでなくて、業態によるところも大きいと思います。ただ、私がこれまで所属していた200-300人規模の企業でも、今と同じような運用をしていましたが、特に支障はありませんでした。

チケット管理システムや法務専用システムなどを用いたある程度カチッとしたワークフローが必要になるのは、「法務のメンバーが増えてある程度きっちり管理をしなければ品質を維持できない」や、「画一的な処理を大量にこなさなければならない」という課題があるケースなのではないかと思います。

自社の課題を正確に認識し、解決するために最適な方法をとる

山下 俊

管理簿はあくまでレビュー段階の管理用というイメージでしたが、いわゆる契約管理台帳は作っていますか?

片岡 玄一

別途締結した契約の管理簿もあります。こちらは、決裁システムが振り出すIDとは紐づいていますが、レビュー時の案件管理用のIDとは紐づいていません。抽象的には紐づけられていた方が良いだろうなとは思うのですが、どうしても人が判断して紐付ける必要があるので、具体的なニーズが強くない現段階では、ここに工数をかけるべきではないと判断しています。

片岡 玄一

抽象的なニーズをかなえようとすると、どんどん対応すべきことが増えていくので、解決すべき課題があるところにリソースを集中させるよう割り切る必要があると思っています。

繰り返しになってしまいますが、大切なのはやはり課題で、この課題を解決するために必要なことをする、ということに尽きるのだと思います。

ただ、それだけをやっていると「つぎはぎ」になるんですよ。まさにこの、レビュー時の管理簿と締結した契約の管理簿のように。

だから、どこかで全体最適の観点で歪みが出ていないかを見直す必要もあると思っています。「本当にこれでいいんだっけ」と。

片岡 玄一

人は、そのとき自分がベストだと思って構築した運用が現状にマッチしなくなった場合でも、過去の自分を否定したくないあまり、現行の運用を正当化したくなってしまうものだと思います。そのため、これはベストじゃないかもしれない、もっといいやり方はないのだろうか、と、常に自分に問いかけないといけないと考えています。

例えば、私は、契約の審査依頼の受付方法については、検索性や外部とのやり取りも集約できるという意味でメールが最適だと考えていたんです。ですが、あるときに現状に照らすともはやメールはベストな受付方法ではないということに気づいちゃったんですよ、メールじゃないほうがいいんだっていうことに。気づくまで2年くらいかかりました。

山下 俊

課題に基づいて、今やるべきことと捨てておくことを明確に分けられていることがすごいですね。この課題認識の部分で気をつけるべきポイントなどありますか?

片岡 玄一

実のところ、課題を正確に認識することが一番難しいと思います。課題さえシャープに理解できると、解決法は割と簡単に作れるんですよね。

そして、課題を正確に捉えるためには、自社を客観視する必要があるわけですが、自分の力だけで視点を変えることはなかなか難しいので、他社の運用を聞いてみることが重要だと思っています。他社の運用の背後には、その運用で解決した課題があるものなので、他社が解決した課題は、自社で積み残されていないかという視点で、自社を客観視することができます。

逆に、他社の運用を聞いて、それをそのまま自社に持ってきても、課題が共通でない場合にはうまくワークしないはずです。その意味では、他社の話を聞く際に重要なのは、どうやっているかより、どうしてそうしようと判断したのか、なのだと思います。

前編はここまでです。後編は6月21日(月)公開予定!お楽しみに!

→公開されました!

よかったらシェアしてね!
目次
閉じる