連載:第27回 IT・SaaSとの付き合い方
契約書管理システムの“リアル”導入事例。情シスが振り返る選定プロセス
![](https://img.bizhint.jp/image/upload/f_auto/production/academy/assets/logo_mark-f3e064fa4697f100e1c508ee888848464fdfd3ae6c7e9587eaaac3e3928e0068.png)
![メインビジュアル](https://dwrowh0ntn9c6.cloudfront.net/public/graph/reports/avatars/000/930/202/large/9c6d37182c69762abc45f601c6a324a0fc4864c1.jpg?1709280838)
ある日「取引先との契約が長年自動更新され続け、実情と合っていない」「契約内容も、契約書がどこにあるかもわからない」といった問題が顕在化したとある企業。それを経営リスクと認識した所から「契約書管理・運用の再構築」が進められました。最終的に、契約管理のクラウドサービス導入に至るものの、その過程は紆余曲折、平たんなものではありませんでした。その検討プロセスで、現場では何を行い、どう判断していったのか?リアルな実情を伺いました。
![メインビジュアル](https://dwrowh0ntn9c6.cloudfront.net/public/graph/reports/avatars/000/930/202/large/9c6d37182c69762abc45f601c6a324a0fc4864c1.jpg?1709280838)
※本記事は取材に基づいて制作しておりますが、インタビュイーの意向により、本筋に影響がない範囲で内容を一部改変しております。
経営リスクだった契約管理。絶対に外せなかった2つの要件
(お話を伺った方)
・製造業/装置・部品製造
・創業50年以上
・従業員数:約800名
・情報システム部門の責任者
・課題:契約書関連の管理・運用効率化および経営リスク解消。検討から導入までの期限は4か月。
――貴社では契約書管理を目的に、契約管理DX ConPass[コンパス]を導入されました。当時の課題や導入検討プロセス、採用理由についてお聞かせください。
もともと当社では、契約書の管理・運用について2つの大きな課題を抱えていました。
1つは “契約の一元管理”。
当社では長年にわたって、契約書の管理が本部であったり各部署であったり、バラバラで運用されてきました。それが事業再編という大規模プロジェクトを進める段になり、子会社や取引先との権利関係の把握に直面した際に大きな問題になりました。
契約書を探し、内容を確認するのに膨大な手間と時間がかかったのです。将来に渡ってスムーズな経営判断をするため “契約書の一元管理”が経営課題と認識されました。
そしてもう1つは、“自動更新契約の把握”。
当社では、継続的に取引する顧客やパートナーとは、最初に基本取引契約を結び、その後は 「〇年経過後に自動更新」 と契約書に記載するのが通例でした。しかし更新時期になっても契約内容の見直しが行われないまま10年、20年と経過し、契約内容と実態とがかけ離れている事例も出てきました。やはりこれも、契約書まわりでの経営リスクと認識されました。
上記を踏まえ当社では、
以下の運用ができる体制づくりを目指すことになりました。
・契約を一元管理する。
・契約終了・自動更新時期に適切な対応を取ることができる。
そしてそれを実現するためのシステム要件として、以下の2つを定義しました。
【2つの要件定義】
1.契約書の原本管理を一元化できる。
2.契約終了期限にアラートできる。
結果として、2023年5月~9月の4か月間で本格的に検討を重ね、日本パープルの「ConPass」というツールの導入に至りましたが、その過程には紆余曲折がありました。
契約書管理システムの自社開発。失敗に至る必然
――プロジェクトの経緯についてお聞かせいただけますか?
私が情報システム部門の担当としてアサインされたのは2022年の末ごろでした。当時の方向性は、ツールの自社開発。スケジュールとしては、2023年9月の稼働が目標でした。
私がジョインする前、このプロジェクトは部門横断的なものということで総務・法務部門が予算化して旗を振り、汎用ツールの機能をベースに、懇意にしている外部SIerが当社用にカスタマイズする、という形で進行していました。
「一元管理」「アラート」というのは一見シンプルな仕様ですし、開発難易度としても高くないという見立てがあったのでしょう。私としても当時は「それでいけるのであれば、むしろありがたい」くらいに考えていました。
しかしこのプロジェクトは、失敗という結末をたどります。2023年4月、上がってきたプロトタイプを評価し、「不採用」と結論したのです。
――なぜそのような結果になったのでしょう?
振り返れば、そこに至った原因や反省すべきことはいくつかあります。
まず、 旗振り役の総務・法務部門はITシステム導入や、プロジェクトリーダーとしての経験が不足していました。またそれに対して、周囲のサポートも十分なものではありませんでした。
そしてシステムの要件定義も遅延。旗を振る総務・法務部門としては、将来想定されるリスクへの対処をできる限り盛り込もうとしたこともあるのでしょう。 仕様がどんどん膨れ上がっていきました。
結局、 要件定義が固まらないまま、パートナーが試作に進行 。我々もそれを認めてしまいました。スケジュールや予算の都合上、進めるしかなかったのです。
そんな状況の中で上がってきたプロトタイプは、実務に耐えるものではありませんでした。何より要件を満たしていない、さらには感覚的にあまりにも使いにくかったのです。
実際に使用することになる現場のスタッフも含め協議し、 自社開発は中止 となりました。
急遽、外部ツールの選定へ。期限は4か月。
――とはいえ稼働目標は2023年9月。残り4か月です。
今後についての話し合いが持たれ、 契約管理ツールについては私が所属する部門で、外部ツールの単独導入 という方向に舵が切られました。稼働目標は2023年9月と、変わりませんでした。
そこでまずやったことは、候補となる外部サービスを洗い出すこと。幸い、私の前任者が1年前に候補を3つに絞ってくれていたので、それを踏襲。「日本パープルのConPass」とA社、そしてB社のサービスとで比較検討を行うことにしました。
結果、冒頭お話しした通り、「ConPass」を採用するに至ります。
契約書管理ツールの選定。絞り込み6つのポイント
――比較の経緯や、ConPassの採用に至った理由について教えてください。
選定のポイントとしては、大きく6つありました。
1.紙の契約書原本の保管場所
日本パープルとA社は、自社で紙の契約書原本保管サービスを提供しているため、管理システムと原本保管が連動しています。 原本を保管する倉庫を別で探す必要がないというメリット がありました。
一方、B社のサービスは原本の保管先を別で探す必要がありました。ツールの活用事例の中で、契約書管理について紹介されていたので候補に入れたのですが、この部分は残り2つとの大きな違いでした。これは実際に話を聞いてみないとわからないことでした。
2.導入・運用知識
実機検証していく中で、A社とB社のサービスは、アクセス制御やワークフロー設定がConPassよりも細かくできることがわかりました。一方、その導入や運用管理において、ある程度のデータベース知識とスキルが必要という点が、トレードオフになっていました。
また 設計思想の違いも感じました 。A社とB社のサービスがフォルダによる階層構造をベースにしているのに対して、ConPassはAI-OCR(後述)で手早く登録して、仕訳は検索表示で行うという考え方。
当社の場合、 そこまで高度な管理は想定していませんでしたので、導入や運用が容易なConPassが優勢 という判断になりました。
3.AI-OCR
印刷物からテキストを読み取ってデータ化するOCRと、そこで使用されるAI。 これはベンダー側と話をしながら、実機のデモを見たことが判断の大きな決め手になった部分 です。
実は当初、私はAI-OCRをあまり信用していませんでした。9割くらいは読み取れても完全ではないだろう、と。この点をA社の担当者に聞くと、やはり同じように「開発テーマになってはいるが、信用はしていない」と。この返答自体には、納得感がありました。
一方、ConPassのAI-OCRのデモ。たしかに完璧ではないものの、契約書の中で必要な項目だけに条件を限定すれば、十分許容できるものでした。そして日本パープルの担当者としても 「OCRとして完璧ではないが、実用には耐える」と同様の認識でした。こうした部分は、ベンダー側の考え方が出る部分だと感じました。
昨今、同様のツールは各所で見かけますが、その多くが「AI」を謳っています。しかしこの AIへのスタンスや目的は、各社様々 です。当社にとっては、ConPassのそれが合致していました。 自社での要求水準を整理したうえで担当者と話をして、実機デモで確認することは必須 だと感じました。
企業の要求水準によっては、ConPassのそれが合致しないことも十分にあり得ると思います。 当社にとってはそれが合致した というだけです。
そしてConPassのAI-OCRについてはもう1つ、うれしい誤算、発見がありました。それは当社が設定したシステム要件の2つ目「契約終了期限にアラートできる」に関するものです。
冒頭触れたように、当社が取り扱う契約書の多くでは、契約終了後も〇年ごとに自動更新、契約終了後も一定期間は機密保持の義務あり…といった 「2段階の期限」が設定されていることがよくあります。
ConPassのAIのチューニングはその部分もカバーできていて、これには本当に驚きました。その後の社内レビューでも、この部分は高評価でした。 社内合意を得る一助になった と思います。
4.ベンダーの対応
機能面でConPassが優勢になってきたのですが、 もう1つ決め手がありました。それがベンダーの対応です。
当社としては初めてのツールの導入ですし、また稼働目標の9月まで時間もなく、細かい相談や要望をベンダー側に投げていました。 そこに素早く対応してくれたのが、日本パープルの担当者でした。
相応の老舗のはずなのですが、OCR-AIでの完璧を求めすぎない割り切りや対応のスピードを見るに、ベンチャー企業のような印象を受けました。
実は前任者が選定を進めている時から、ConPassが合うんじゃないか?という見立てはありました。それから1年が経ち、社内では「この1年で、製品・サービスの進化がとても大きい」と評価していました。ですので将来への期待も込めて、ConPassに決定しました。
5. 紙の原本の保管費用
当社には、 紙の契約書が過去50年分存在していました。そしてその総量は、正確に把握できていない状態。 これらを1か所で管理するとなると、 倉庫での保管体制や保管料が懸念 されました。
A社は倉庫業を手掛けている会社ということもあり、「契約書を一通ずつ取り出せる」といった利便性がありました。保管料は有料です。
一方でConPassは、契約書の取り出しは箱単位と利便性で一歩劣ります。しかしそこは当社にとって重要ではありませんでした。何より、保管料が無料ということが決め手になりました。この条件は日本パープル社との様々な交渉を経ての着地なのですが、 契約書の総量が把握できない当社にとっては大きな安心感 になりました。
6. 販売停止のリスクが少ないと想像される
ConPassは日本パープルが自社開発していることに加え、契約書原本の預かりスキャンから管理システムへの登録サービスまで提供していました。また日本パープル自身が、自社でConPassを使用していることが伺えるような、 実際に使っている人にしかわからないようなツボを押さえた機能 を実現していたため、好印象を持ちました。
開発者自身が、そのサービスをユーザーとしてしっかり使っているから、システム・サービス提供を止める可能性は少ないと判断しました。
将来的に長く使うシステムです。 導入を推進した担当者として、ある日突然なくなってしまうようなことは絶対に避けたい という思いはありました。
つまずきポイントは「契約書の保管・管理」の自社ルール。企業の数だけ答えはある。
――今回、契約書の管理ツール導入に際して、事前に把握・確認できていればよりスムーズに進められたと感じることはありますか?
契約書のライフサイクルは、大きく2つのプロセスに分けられると思います。
1.契約段階 :契約書ドラフトの作成から締結まで
2.保管・管理段階 :契約書原本を管理から契約終了・契約書原本廃棄まで
私がツールを選定していて感じたことの1つは、 多くのツールが「1.契約段階」での特徴や優位性の訴求に重きを置いている という点です。
他方、 「2.保管・管理段階」については、実運用では避けて通れない部分であるにも関わらず、そこへの言及は少ない。 この背景には、契約内容や機密情報の取り扱いルールなどが、企業ごとに大きく異なるという点があると思います。
私自身、 「自社の既存契約書の整理」という課題に向き合う中で、自分では判断がつかない場面に度々直面 しました。例を挙げれば、保管期限はどうするか?というものです。
きっちりやるのであれば各種法令に準拠すべきですし、そうしている企業もあるでしょう。一方で、自社で決めても支障がない分野であれば、その判断をする会社もあるでしょう。
ですので 「2.管理・運用」については世の中に明確な答えがない、それぞれの企業ごとに答えがいくつもあるもの だと感じました。
当社では時間もありませんでしたので、シンプルに「まずは一元管理だけをやる」と割り切って進めましたが、「自社に必要な契約書の管理ルール」が明確化していれば、より当社としての答えにたどり着きやすかったように感じますね。
この記事についてコメント({{ getTotalCommentCount() }})
{{selectedUser.name}}
{{selectedUser.company_name}} {{selectedUser.position_name}}
{{selectedUser.comment}}
{{selectedUser.introduction}}