契約書管理のボトルネックをプロセス別に特定!段階的にあるべき姿へ近づくContract Productivity Modelとは

この記事でわかること
  • 契約書業務の各フェーズにおける、あるべき姿を示した「Contract Productivity Model」(生産性モデル)の概要
  • 「生産性モデル」において必要とされている要素
目次

はじめに

みなさん、こんにちは!

企業における契約(書)業務は、その非効率性によって、最大で収益の40 パーセントが失われるとも言われるように、その効率性と正確性がビジネスの成長と直結します。

多くの場合、「契約書管理」は、そのレビューに必要な法的な専門性を有する法務(組織)またはこれに類する職責を持つ方に管掌責任があるでしょう。もっとも、LOLでも繰り返し記載している通り、契約(書)業務は、その審査依頼から契約審査(交渉)、承認・締結、そして契約管理に至るまで、社内外の多くのステークホルダーが関わる非常に複雑なものであり、法務(組織)だけをその効率化のスコープとするだけでは、効率化は完了しないことに注意が必要です。

では、そういった複雑な契約(書)業務の効率化を図るためには、いったいどういった状態を理想とし、どのようなアクションを取るべきなのでしょうか?そのヒントを、日本版リーガルオペレーションズのCOREのように、ステージ別にまとめたモデル「Contract Productivity Model」としてご紹介します。

Contract Productivity Model(生産性モデル)とは

定義と目的

Contract Productivity Model
図1:Contract Productivity Model(生産性モデル)by Hubble inc.

この生産性モデルは、前述の通り、契約書に関する業務が多くの社内外のステークホルダーを巻き込んで遂行されることを念頭に置き、多くの企業法務に従事される皆様からの問題意識や現状をヒアリングし、「契約(書)業務」のあるべき姿を、審査依頼から契約審査(交渉)、承認・締結、そして契約管理のプロセスごとにまとめたものです。

リーガルオペレーションズとの関係

通常リーガルオペレーションズの文脈では、法務(組織)の機能をベースに、その生産性向上やクオリティ向上を中心に据えていますが、この生産性モデルは組織の機能ではなく、業務そのものの生産性向上を念頭に置いており、若干性質が異なります。ただし、この生産性モデルには、日本版リーガルオペレーションズの「業務フロー」や「ナレッジマネジメント」のエッセンスを取り入れており、それらとも矛盾のない内容となっています。

これに加えて、生産性モデルは、明快さの便宜のために「ステージ」という言葉を用いています。多くの項目は、ステージが上がるとその達成難度も上がるという設計になっていますが、全ての企業が、今この時点でレベル3を目指すことを必ずしも想定しているものではない点に注意が必要です。自社の状況に合わせた適切な目標設定をすることをオススメしています。

もちろんこの生産性モデルは、一つの絶対正解として定めるものではなく、いわばβ版として、今後更に発展していくことが想定されています。

審査依頼について

(各項目をクリックまたはタップすることで、詳細な情報が表示されます。)

ステージ1: 基本的な審査依頼の枠組みの設定

1-1:依頼者による契約審査の依頼方法が決まっており、これが告知されている
①構成要素と具体的アクション
構成要素具体的アクション例
以下の3パターンについて、審査の依頼方法が決まっている
自社ひな形での契約作成依頼
相手方ひな形での審査依頼
ゼロからのドラフト作成の依頼
メールやチャットなど、主な依頼方法を決める
審査の依頼方法が告知されている社内イントラへの掲示、説明会の実施、操作マニュアルの共有などを実施する
②補足
  • 本パートでは、あくまで依頼方法を定めることがゴールとなるため、審査依頼の方法を一本化することまでは求めるものではありません。
1-2:最新の自社雛形の格納場所が統一され、依頼部門が使用できる
①構成要素と具体的アクション
構成要素具体的アクション例
自社ひな形を作成している日常的に発生する取引類型についてひな形を作成する
最新の自社ひな形が統一的な場所に格納されている社内ポータルやドライブなどに、ひな形の最新版を保管する
最新の自社ひな形を事業部門が使用できる事業部門に必要な範囲でアクセス権を付与した上で、自社ひな形が格納されている場所を周知する
補足
  • ここでは、まず通常発生する契約類型に関してひな形を作成し、これを事業部門に対して公開することを求めています。どういった類型についてひな形を用意すべきかについては、以下の記事の手順を参考にすると良いでしょう。

ステージ2:審査依頼のプロセス統一と効率化

2-1:依頼者による契約審査依頼の方法が統一されている

①構成要素と具体的アクション

構成要素具体的アクション例
以下の3パターンについて審査の依頼方法が統一されている
①自社ひな形での契約作成依頼
②相手方ひな形での審査依頼
③ゼロからドラフト作成の依頼
メールやチャット、受付システムなどいずれかの依頼方法に統一して契約書審査依頼のプロセスを運用する

補足

  • この項目は日本版リーガルオペレーションズのレベル2、「法務案件 (契約・法律相談)の受付窓口を統一している」と同様の要件を課しています。
  • 審査依頼を統一するにあったってどういったツールを活用するかは、いくつか候補が考えられます。その選び方については下記の記事をご覧頂き、企業や法務の規模、契約業務の発生頻度に応じて決定すると良いでしょう。
2-2:契約類型毎に依頼時に伝達必須の情報が決まっており、これを取得する仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
日常的に発生する契約類型毎に依頼者から取得したい必須情報が決まっている契約類型ごとに、依頼者から取得したい情報を決める
依頼者から必須情報を取得する仕組みがあるエクセルやフォームなど、抜け漏れを防止しつつ必要な情報を過不足なく取得できる仕組みを構築して運用する

②補足

  • ここでは、主に業務効率化に資する自社ひな形が使われる場合において、依頼者のスキルやリテラシーに依存せず必要十分な情報を取得できることを目指します。このため、②においては基本的にフォーム形式での情報の取得を想定するものとし、依頼者がメールの本文中に必要な情報をフリーハンドで書く方式は含まれないと考えるべきでしょう。
2-3:法務による契約審査が不要な契約類型または条件が決まっている

①構成要素と具体的アクション

構成要素具体的アクション例
法務による契約審査が不要な契約類型または条件が決まっている事業部門に、以下のイメージで審査不要なパターンを提示する
・契約類型:変更不可な利用規約、秘密保持契約etc
・条件:自社ひな形通りで締結できる場合etc

補足

  • 本項目は、日本版リーガルオペレーションズの「業務フロー」のレベル2の「契約審査の依頼基準を作成している」とほぼ同じ条件を課す項目です。
  • ここでは、法務(組織)と事業部門との信頼関係を加味しつつ、リスクと効率を天秤にかけて、あえて法務に相談を持ってくる必要のない類型を決めるプロセスです。事業部門側の混乱を避けるためにも「事業部門が必要と判断した場合のみ法務に相談する」といったやや曖昧な基準よりも、可能な限り、契約類型や状況を踏まえた形式的な判断基準が定まっていると良いでしょう。

ステージ3:審査依頼に関するデータの取得と活用

3-1:データを取得できる仕組みがあり、これに基づいて業務の見直しをしている

①構成要素と具体的アクション

構成要素具体的アクション例
審査依頼のプロセスにおける各種データを取得できる以下のデータを取得できる
・審査依頼件数
・契約類型
・契約書の言語
・自社雛形の利用率
・依頼部署
・伝達必須項目の入力率
・各契約書におけるラリー数(バージョン数)
データや定性的情報に基づいて、業務の運用フローを見直す仕組みがある以下のような見直し機会を定期的に(年1回程度)作っている
・依頼が多い類型や修正が多いひな形について、ひな形の新規作成や細分化・修正を行う
・契約類型やラリー数から、審査不要な契約類型を見直す
・依頼件数などから、外部リソースの活用を検討する

②補足

  • 審査依頼では、事業部門との役割分担の観点で考慮すべきポイントも多いため、あまりに頻繁な業務フローの変更は現実的に難しいと思われます。事前にアンケートを事業部門にとりながら打ち手を決めるのも良いでしょう。

契約審査について

(各項目をクリックまたはタップすることで、詳細な情報が表示されます。)

ステージ1:基本的な契約審査プロセスの確立

1-1:契約審査の履歴を記録している

①構成要素と具体的アクション

構成要素具体的アクション例
以下の情報を、後から確認可能な状態でもれなく記録している
・契約書のドラフト(最終版以外も)
・関連資料
・社内外の関連するコミュニケーション
共有フォルダやドライブなどに、検討過程のWordファイルや添付資料とこれに関連する社内の議論の過程を記録する

②補足

  • 契約(書)業務において、締結後だけでなく締結に至るまでの経緯を組織に残すことが、現在だけでなく近い将来の効率的な業務に資するという観点から本項目を設けています。ただし、本項目においてはその記録の態様は問わないこととしています。
  • 本項目に限らず、この生産性モデルにおいては、業務の「見える化」を通底する共通テーマとして持っています。今一度「見える化」の意義を確認されたい方は、以下を参照頂くと良いでしょう。
1-2:審査中の契約書のドラフトを社内の関係者がいつでも確認できる

①構成要素と具体的アクション

構成要素具体的アクション例
審査中の契約書のドラフトが、共有可能な場所に格納されている共有フォルダやドライブなどに、審査中の契約書のドラフトを保管(アップロード)する
審査中の契約書のドラフトを必要な社内の関係者が確認できる審査中の契約書のドラフトの格納場所を関係者が認識できるように伝え、必要な関係者のアクセスを許容する(権限を付与する)

②補足

  • ここでは、必要な範囲で法務のみならず事業部門においても、契約書のドラフトが共有できることを求めており、契約の性質上閲覧させる必要がない(適切ではない)メンバーのアクセスを制限することも想定しています。
  • ただ、原則として共有することを前提とするため、ドラフトが各メンバーのPCのローカル環境にしか存在しない、といった状態は本項目との関係では許容されません。
1-3:法務(組織)内で契約審査の精度を担保する仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
契約審査の精度を担保する仕組みがある(人・AIレビューシステムを問わず)ダブルチェック体制を構築する
法務組織内で精度を担保する仕組みが周知され、ルールに沿って運用されている特定の契約類型や条件を除いて、ダブルチェック体制を運用する

②補足

  • ダブルチェックは、常に全件に対して行うことを求めるものではなく、例えば簡易なNDAについてはダブルチェックを不要とするといったルールを組織として運用することでも構いません。
  • 更に、一人法務の場合にはダブルチェックの運用自体が難しいため、以下の記事にも言及があるように、常にセルフチェックで二度確認するなどのルールで運用することでも問題ないでしょう。

ステージ2:効率的な契約審査プロセスの実施

2-1:法務(組織)内で担当者に案件を振り分ける仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
以下のポイントを決定し、運用されている
・案件の振り分けを行う者
・振り分けされたメンバーへその旨を通知する方法
・依頼者へ具体的な担当者を通知する方法
依頼を受け付けたのち、組織長がチャットツールなどでアサインを伝え、別途担当者が依頼者に、自らが担当である旨を伝える、といった業務フローを運用する

②補足

  • 原則として、事業部門から各担当者にバラバラに依頼が来るといった分散型の申請フローの場合は、本項目を満たしていないものします。
  • 一人法務の場合は、そもそも割り振るプロセスが想定されないため、本項目は対象外としてしまって構いません。
図2:「契約審査の受付方法、法務の規模別ベストプラクティスを紹介!」より抜粋
2-2:社内の関係者が審査中の案件の担当者や進捗をいつでも把握できる仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
審査中の案件の担当者や進捗を記録している審査中の案件に関する担当者や進捗の情報をエクセルや専用のシステムなどを用いて一覧化し、都度更新している
審査中の案件の担当者や進捗といった案件管理を、(法務のみならず)社内の関係者も必要な範囲で把握できる仕組みがある審査中の契約書の案件の一覧の存在を周知し、必要な関係者のアクセスを許容する(権限を付与する)

②補足

  • この要件は、ステージ1-2と関連しており、実際に検討中のドラフトだけでなく進捗状況などをも共有できる状態にすることを求めるものです。②に記載されている適切な権限管理を求めると、運用コストも含めて、従来のエクセルなどで実現するのは難しく、システムの導入が必須級であるため、レベル2に配したものです。
  • なお、Googleスプレッドシートで上手く進捗管理表の権限管理を実現できている例は、以下の通りです。
2-3:社内の関係者が審査の参考になる過去の契約書のやりとりを検索できる仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
以下のような過去の契約書とこれに関連する情報をタイトルや文面自体、または関連するメタ情報などで検索できる状態
・過去の契約書(ドラフトを含む)
・過去の契約書に関するやり取り
本文検索可能なドライブシステムや専用のシステムを用いて、検索可能な環境を構築し、運用する
過去の契約書などを、(法務のみならず)社内の関係者も必要な範囲で把握できる仕組みがある過去の契約書(のドラフト)の存在を周知し、必要な関係者のアクセスを許容する(権限を付与する)

②補足

  • この項目は、過去に締結した契約書の限りにおいては、後述する「管理」のステージ1と相関します。
  • 過去のドラフトも含めた契約書作成プロセスの管理が必要となる理由は、以下の記事に記載していますので、是非ご覧ください。
2-4:条項集やプレイブックが整備され、法務(組織)内で公開されている

①構成要素と具体的アクション

構成要素具体的アクション例
条項集やプレイブックが作成されている過去の契約案件のドラフトややりとりの蓄積を活かし、一般条項の条項集や自社ひな形への修正提案に対するカウンターパターンをまとめたプレイブックを作成する
条項集やプレイブックが組織内で公開されて活用できる状態にある条項集やプレイブックを、少なくとも法務組織内で誰でもアクセスできるように公開する。

②補足

  • 契約業務の効率的な運用のために必要なアイテムとして、LOLでは条項集、ひな形、プレイブック(およびマイルール)をご紹介しています。一般的な傾向として、ひな形に比して、条項集とプレイブックの優先度は後になることが多いことから、ひな形は審査依頼のステージ1に配した一方で、残りの2つには契約審査のステージ2に配しました。

ステージ3:契約審査に関するデータの取得と活用

3-1:データを取得できる仕組みがあり、これに基づいて業務の見直しをしている

①構成要素と具体的アクション

構成要素具体的アクション例
契約審査のプロセスにおける各種データを取得できる以下のデータを取得できる
・依頼件数
・部署ごとの依頼数
・担当者ごとの案件数
・担当者ごとの進捗スピード
・個別に依頼が来た案件
・自社雛形/先方雛形
・・条項の検索数・引用数
データや定性的情報に基づいて、業務の運用フローを見直す仕組みがある以下のような見直し機会を定期的に(月1回〜年1回程度)作っている
・担当ごとの進捗スピードから、担当者ごとの負荷の計測や割り振り基準の見直し(随時)
・条項の引用状況を確認し、プレイブックへやひな形への組み込みを検討する(随時)

②補足

  • 契約審査における業務フローの見直しで重要なのは、今この瞬間の業務負荷のバランスが過度に崩れないように配慮するという短期的視点と、近い将来の業務がより効率的に運用されるための仕込みを行うという中長期的視点それぞれが求められることです。
  • 以下の記事は、既存のサービスを上手く連携しながら、メンバーの業務負荷を上手く調整している事例です。

承認・締結について

(各項目をクリックまたはタップすることで、詳細な情報が表示されます。)

ステージ1:基本的な承認・締結プロセスの確立

1-1:契約締結に必要な承認フローが決まっている

①構成要素と具体的アクション

構成要素具体的アクション例
「当該契約書の内容で締結をすること」を会社の意思決定とするための承認フローが決まっている法務の組織長が承認し、事業部門の長が承認すれば、契約締結可、といった確定したフローを確定する
承認フローが告知されている社内イントラへの掲示、説明会の実施、マニュアルの共有などを実施する

②補足

  • 本項目は、スタートアップなどこれから承認フローを整えようとしている企業のファーストステップの目線で作成しています。このため、承認プロセスとして「法務が承認していればOK」とするルールでも良いでしょう。
  • 契約の稟議においては、取引を実施することを承認する決裁に契約書の内容に関する稟議も内包されている場合も多く存在すると思われますが、この場合も、①は充足していると整理しています。
  • 加えて、ワークフローシステムを導入している場合には、あえて承認フローを明示していない(フローに乗せれば自動的にその通りに決裁される)ケースも多く存在します。この場合も②は充足しているという整理で良いと考えています。
1-2:取引先と合意した内容を取り違えずに社内承認・締結ができる仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
稟議申請時に最終版のドラフトを取り違えないための仕組みがある最終版のドラフトをクラウドサービスに格納し、そこから一意に発行されるURLを稟議に添付する
契約締結時に最終版のドラフトまたは決裁された契約書を取り違えないための仕組みがある最終版のドラフトがクラウドサービスやワークフローシステムに格納されており、ここから印刷または電子契約の送付を行う

②補足

  • 本項目の①は、基本的に随時共有可能な場所に保存されていくことを想定するものであり、審査依頼のステージ1-2「審査中の契約書のドラフトを社内の関係者がいつでも確認できる」との関連性が高いものとなります。

レベル2:効率化され、統制のとれた承認・締結プロセスの設計

2-1:契約締結に必要な承認フローが社内規程に明記されている

①構成要素と具体的アクション

構成要素具体的アクション例
「当該契約書の内容で締結をすること」を会社の意思決定とするための承認フローが社内規程に明記されている承認規程や稟議規程に、契約書の決裁に関する承認フローが記載されている

②補足

  • ステージ2に配していますが、上場を目指すなど、一定の規模を備えるに至った企業においてはほぼ必須の項目となります。
  • なお、上場準備と関連し、以下の記事では上場準備の文脈における社内規程作成の時期についてもご紹介しています。
2-2:各契約案件に承認フロー通りの承認がなされた証跡を残す仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
社内規程に記載されている通りの承認フローが運用されている承認規程や稟議規程に、契約書の決裁に関する承認フローが記載されている
承認した実績について証跡が残っているワークフローシステムを使って稟議を行い、その実績が記録されている

②補足

  • 本項目も上場を目指すなど、一定の規模を備えるに至った企業においてはほぼ必須の項目であり、基本的にはワークフローシステムの導入を前提としています。ただし、契約書に関する承認に特化しているシステムである必要は必ずしもなく、汎用のワークフローシステムでも十分ワークします。
2-3:契約案件の承認権限が適切に移譲されている

①構成要素と具体的アクション

構成要素具体的アクション例
以下のような要素に応じて、決裁権限が適切に複数のレイヤーに委譲されている
・契約の類型、発生件数
・当該契約の取引金額の大小
・その他リスクの大小
承認規程や稟議規程に、契約書の類型に応じた承認フロー変更が見られる(同様にシステムで制御されている)

②補足

  • 通常、スタートアップ企業は、すべての契約書の署名欄に代表者の名前が記載され、かつ社内的な承認も当該代表者、つまり社長が決裁することがほとんどです。これに対し、企業規模が一定以上になった場合においては、特に社内的な決裁を(簡易な契約も含めて)すべて社長が行うということは現実的ではありません。上記のような要素に応じて、決裁権を移譲するケースを決めることを求めるものとなります。
  • ただし、この決裁権の変更は、企業の統制に関わる重要なトピックで、法務(組織)などの一存で実行することは難しいため、ステージ2に配すこととしています。

レベル3:承認・締結に関するデータの取得と活用

3-1:データを取得できる仕組みがあり、これに基づいて業務の見直しをしている

①構成要素と具体的アクション

構成要素具体的アクション例
承認・締結のプロセスにおける各種データを取得できる以下のデータを取得できる
・決裁者ごとの承認の起案から承認完了までの経過時間
・例外的な承認フローを経た件数
・差し戻しが発生している件数とそのパターン
データや定性的情報に基づいて、業務の運用フローを見直す仕組みがある以下のような見直し機会を定期的に(年1回程度)作っている
・決裁者ごとの承認の起案から承認完了までの経過時間から、権限委譲を行う可能性を検討する
・例外的な承認フローの件数が多い場合には、当該例外パターンを類型化し、原則的な承認フローに組み込むことを検討する

②補足

  • 本項目は、業務の見直しにおいても、申請フローやワークフローの仕組みの見直しを伴うものとなるため、ステージ2と同様に法務のみで完結することは殆どなく、他チームとのコラボレーションが必須となります。

(契約書)管理について

(各項目をクリックまたはタップすることで、詳細な情報が表示されます。)

ステージ1:基本的な締結後の契約書管理プロセスの確立

1-1:紙・電子を問わず締結した契約書の格納場所が統一されている

①構成要素と具体的アクション

構成要素具体的アクション例
紙・電子を問わず契約書が格納されている有効に存続している契約書を中心に、(紙の契約書はPDF化の上)電子データとして保管する
格納場所が統一されている契約書のPDFデータをリーガルテックやGoogleドライブなどのクラウドストレージに保管することがルール化されている

②補足

  • 電子帳簿保存法が、電子取引(電子契約で締結した契約)において、原則として電子での保存を義務付けていることもあり、紙の契約書と電子契約とを一元管理する場合には、全て出力(印刷)して保管することでは、本項目の①を満たさないこととなります。
1-2:締結した契約書に関する情報が一覧化され、関係者がいつでも確認できる仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
締結した契約書に関する情報が一覧化されているエクセルやスプレッドシート、契約台帳のリーガルテックなどで、いわゆる契約台帳を作成している
当該一覧が、共有可能な場所に格納されているクラウドストレージなど、契約台帳の格納場所を関係者が認識できるように告知する

②補足

  • 一覧化が必要な項目については、各社によって異なりますが、以下の記事にも言及がある通り、以下の10項目が管理されていれば十分と言えるでしょう。
    • 管理番号
    • 相手先
    • タイトル
    • 締結日
    • 契約開始日
    • 契約終了日
    • 自動更新の有無
    • 自動更新期間(更新時の周期)
    • 契約の有効 or 失効
    • 取引金額
1-3:締結した契約書に適切な権限を付与し、閲覧範囲のコントロールをしている

①構成要素と具体的アクション

構成要素具体的アクション例
契約書のファイルおよび契約台帳を、(法務のみならず)社内の関係者も必要な範囲で閲覧できる仕組みがある当該関係者の職務上必要な範囲にに限って権限を切り分けて契約書のファイルと台帳を作成する

②補足

  • ここでいう「社内の関係者」には、もちろん事業部門など法務以外の部署のメンバーも含まれています
  • 契約管理台帳においても権限を分けて管理する場合には、例えば部署ごとに台帳を分けてエクセルやスプレッドシートで作成することが必要になるケースもあるため、台帳のファイル自体が分かれることは、本項目との関係では許容しています。権限を分けて台帳を作成するための具体的方法論は、 「契約審査」のステージ2-2をご参照ください。

ステージ2:効率化され、抜け漏れのない契約管理プロセスの設計

2-1:締結した契約書に関する情報が抜け漏れなく入力され、この情報に基づいて検索できる仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
締結した契約書に関する情報が抜け漏れなく入力される仕組みがある業務フロー上、締結後の契約書の台帳への入力がもれなく行われるようなルール(いつ、誰が)が定められ、告知され、運用されている
締結した契約書に関連するメタ情報などで、特定の契約書を検索できる状態メタ情報ベースでの検索ができるエクセルやスプレッドシート、契約台帳のリーガルテックで契約台帳を作成している

②補足

  • もちろん、AI等を用いて、自動で情報が入力される仕組みが構築されている場合も①との関係では許容されます。本項目では、入力された情報の正確性の担保については言及していませんが、「人の目」を入れるダブルチェックも実行できた方が望ましいでしょう。
2-2:締結した契約書の期日管理が実施できる仕組みがある

①構成要素と具体的アクション

構成要素具体的アクション例
締結された契約書の通知期限が把握できる状態契約台帳に契約書の更新または解約の通知期限を入力している
締結された契約書の通知期限または契約終了日に基づき、これよりも前に期日の到来が近いことを関係者が認識できる状態契約書の通知期限または契約終了日が近いことを伝える通知を設定している
期日到来が近い場合に取るべきアクションが決まっている状態常に事業部門の担当者が、契約の継続の判断をする、自動更新の案件については営業事務が支払等のみ対応するなど、フローを構築している

②補足

  • 抜け漏れを防ぐ観点では、システムを導入して機械的に期限到来が近い旨の通知を受けられる仕組みが望ましいです。もっとも、本項目との関連では、必ずしもシステムの導入を求めるものではなく、契約書の通知期限または契約終了日が近いことを認識するための確認の業務フローが確立している場合も許容することと整理しています。

ステージ3:契約書管理に関するデータの取得と活用

3-1:データを取得できる仕組みがあり、これに基づいて業務の見直しをしている

①構成要素と具体的アクション

構成要素具体的アクション例
(契約書)管理のプロセスにおける各種データを取得できる以下のデータを取得できる
・自動更新条項の有無
・各契約書の売り買いの別
・金額
・紙/電子いずれでの締結か
・自社雛形への修正の有無
・締結までのリードタイム
・締結版の格納率(部署別)
・契約書情報の入力率
・イレギュラーな契約条件(支払いサイト、企業独自のリスク条項)の有無
データや定性的情報に基づいて、業務の運用フローを見直す仕組みがある以下のような見直し機会を随時作っている
・自社雛形への修正が多く入って締結に至っている場合、そもそも当該ひな形の条件に変更を加える、または「利用規約」に変更することを検討する
・契約書情報の入力率の計測から、取得の実益が小さい項目を炙り出し適正化を検討する
・電子契約の利用率からコスト削減効果の算出を行う

②補足

  • 最終の合意版である締結後の契約書に関しては非常にデータが豊富に存在し、ここから企業の契約業務のボトルネックを特定するのに役立ちます。
  • 特に近年では、リスクが低減されている限りにおいて、取引開始までの効率性を重視し、契約書の標準化を進める動きがあることには、留意するべきでしょう。

まとめ

この記事のまとめ
  • 「Contract Productivity Model」(生産性モデル)の概要
    • 「契約(書)業務」のあるべき姿を、審査依頼から契約審査(交渉)、承認・締結、そして契約管理のプロセスごとにまとめたもの
    • 業務そのものの生産性向上を念頭に置いている点が特徴
  • 「生産性モデル」において必要とされている要素
    • 審査依頼
      • ステージ1:基本的な審査依頼の枠組みの設定
      • ステージ2:審査依頼のプロセス統一と効率化
      • ステージ3:審査依頼に関するデータの取得と活用
    • 契約審査
      • ステージ1:基本的な契約審査プロセスの確立
      • ステージ2:効率的な契約審査プロセスの実施
      • ステージ3:契約審査に関するデータの取得と活用
    • 承認・締結
      • ステージ1:基本的な承認・締結プロセスの確立
      • ステージ2:効率化され、統制のとれた承認・締結プロセスの設計
      • ステージ3:承認・締結に関するデータの取得と活用
    • 管理
      • ステージ1:基本的な締結後の契約書管理プロセスの確立
      • ステージ2:効率化され、抜け漏れのない契約管理プロセスの設計
      • ステージ3:契約書管理に関するデータの取得と活用
本記事の著者情報

山下 俊(やました しゅん)

2014年、中央大学法科大学院を修了。日系メーカーにて企業法務業務全般(主に「一人法務」)及び新規事業開発に従事しつつ、クラウドサインやHubbleを導入し、契約業務の効率化を実現。
2020年1月にHubble社に1人目のカスタマーサクセスとして入社し、2021年6月からLegal Ops Labの編集担当兼務。2023年6月より執行役員CCO。近著に『Legal Operationsの実践』(商事法務)がある。

リーガルオペレーションズの他のCOREなどについての解説はこちら!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次
閉じる