Concordが目指す「契約書ワークフローの一元管理」がもたらす功罪
昨年だけで2回のファイナンスに成功し、リーガルテックベンチャーとして注目を集めるConcord。企業向けの契約マネジメントSaaSという市場で同社が狙うのは、「契約書を起点としたワークフローによるロックイン」戦略です。
企業向けにフォーカスした契約管理SaaSベンチャー
契約書の作成・レビューに関わる問題をAIで解決する、そんな派手なプロダクトがどうしても目立ってしまう最近のリーガルテック市場。
そうした 派手さはなくとも、既存のテクノロジーを組み合わせて企業法務の課題を解決し、市場から評価を集めているサービス もあります。今回紹介するConcordは、2018年1月に10百万ドルを、そして同年10月に追加で25百万ドルを調達した、成長著しい契約マネジメントSaaSのベンチャーです。
Concordの特徴は、「決裁承認ワークフロー」機能をベース に、
- 契約書ファイル保存・アクセス制限
- 契約書作成時のテンプレート管理
- 契約書変更履歴のバージョン管理
- 契約条項の検討過程で行われるコミュニケーションやノウハウの蓄積・共有
- 電子サイン
- タグ付け・キーワード検索
といった 契約書管理に必要な機能すべてパッケージ し、1アカウント75ドル前後のサブスクリプションで提供している点にあります。
クラウド＋GoogleライクなUIで契約書のライフサイクルを管理
2000年以降に企業のデジタル化が進む中、こうした契約書マネジメントシステムがいくつも生まれては消えてきました。ApptusやiManage Workなど、そうした競争を生き抜いた定評あるプロダクトもいくつか存在しています。
そんな市場に新規参入したConcordは、オンプレミスの面影を引きずった契約管理システムとは一線を画し、クラウドネイティブな設計・Googleライクな直感的UIを採用した、軽快で扱いやすいプロダクト として注目を集めています。
その中心を支える決裁承認ワークフロー機能をチェックしてみましょう。社内承認を得たい文書ファイルを開いたら、画面右手の欄から［Workflow］タブをクリック。
このデモでは、“Company Workflow”としていくつかの承認ルート（Executive Approval / HR Workflow / Legal Workflow）があらかじめ登録されているのが確認できます。申請者が承認ルートを個別に設定する“Custom Workflow”も作成可能です。
承認ステップごとに、いずれか一人の承認者の決裁があれば足りるのか（Anyone）、割り当てられた承認者全員の決裁が必要なのか（Everyone）も設定可能です。
なお順番が前後しますが、契約の承認決裁の前に、法務部門や相手方との条項の修正過程で交わすコメントや修正履歴も一元的に管理できるサービスとなっていて、このUIもGoogle Docsをかなり意識していることがわかります。
さらに電子サイン機能も（DocusignやHelloSign等の電子契約サービスとのAPI連携をあえてせずに独自で）実装しており、クラウド上で契約のゆりかごから墓場まで、ライフサイクルの一切を管理できるプロダクトです。
契約書ワークフローからユーザーをロックインする戦略が吉と出るか凶と出るか
このように、Concordが目指すのは、契約書を起点として企業のワークフローとコミュニケーションのすべてを一元化・集約し、自社サービスにユーザーをロックインしようというチャレンジ です。
一方、採用するユーザー企業の立場としては、ワークフロー全体を特定企業のシステムに依存するのは相当なリスクを伴う判断となります。ロックインされるのを嫌うのが普通ですし、そもそも契約書をワークフローの起点にして管理すること自体、業務のフレキシビリティを損なう危険もあるでしょう。
こうしたConcordの戦略と対照的なのが、ビジネスチャットツールの覇権を握った上で、企業のワークフローの掌握を目論むSlackの戦略です。
▼「チャット」がSlackの本質ではない?! 変革を実現するのは「ワークフロー」
フランク氏はチャンネルをはじめとした各種機能がSlackの特徴だとしつつも、真に重要なのは、コミュニケーションによって何が達成できるか――つまり、実際のワークフローにどう落とし込むかだと説明。「変革を実現するのはチャットではなく、ワークフロー」とも述べ、チャットの利用そのものが業務効率改善につながるものではないと、注意を呼び掛けた。
（https://internet.watch.impress.co.jp/docs/news/1179195.html 2019年8月21日最終アクセス）
自己のプロダクトの機能を極力シンプルに絞りこみ、拡張性はサードパーティとのAPI連携に委ねる。まずはコミュニケーションの機能に特化することで、上位概念のワークフローを緩やかに掌握していく。そんな戦略が同社の発言の端々から伺えます。
Concordのような、重要な文書を起点にその周辺のワークフローすべてを一気に一元化し掌握するアプローチが受け入れられるか
Slackのような、プロダクトはあえて部分に特化し、API連携で機能を拡張しながら緩やかにワークフローを取り込んでいくアプローチが受け入れられるか
それぞれの行く末を見守ってみたいと思います。
（橋詰）
