契約管理システムの要件定義は、承認ルートの再現から始めて、RFPの作成まで順に進めると、現場で使えるシステムにつながります。実際、導入後に課題を感じる企業は約8割にのぼり、課題の多くは要件定義段階の詰めの甘さに起因します。
全体像は契約管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・契約管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
既存の承認ルートを可視化し再現する要件
実務の慣行を無視すると、現場に合わず、紙や個人のExcelに戻るおそれがあります。そのため、契約管理システムの要件定義では、機能の一覧より先に、契約の起案から保管までの実務を、稟議や承認、締結を含めて可視化します。
現状の承認ルートと例外運用の洗い出し
まず、契約類型ごとの承認ルートをすべて洗い出します。例外運用も、RFPに反映できる形で拾い上げます。
- 承認経路：起案者、承認の順番、最終決裁者
- 金額・契約条件：金額帯で承認者が変わるケースや、法務レビューの要否
- 例外運用：部門長を飛ばす特定取引先の役員直決や、急ぎの口頭承認
契約類型と金額帯のマトリクスにまとめ、現場で実際に行われている運用を記録します。
例外を見落とすと、移行後に業務が回らず、紙へ戻る場合があります。また、業務分割による非効率を課題とする企業は38%でした（出典：ContractS、2023年10月）。
承認ルートと例外運用を正確につかむことが、要件漏れを防ぐ土台です。このため、可視化した承認フローは、そのままRFPの中核要件になります。
再現要件か再設計要件かの切り分け
長年の慣行には、非効率な多段承認や形骸化したハンコリレーが含まれることもあります。そのため、発注側と開発会社は、可視化したルートを再現するか、導入時に再設計するかを決めておきます。
これらをそのままシステム化すると、デジタル化しても業務が遅いままになる場合があります。
- 再設計する：必要な承認段階の選定と、統合・省略できるステップの見直し
- 段階的に変える：まず現状を再現し、運用を見ながら承認フローを簡素化する
再設計は現場の合意を伴うため、一度に変えると反発を招く場合があります。現場の準備度や変革意欲によっては、現状の再現から始めるほうが定着しやすいこともあります。
RFPでは、現状ルートの再現を必須要件とし、条件分岐など変更の柔軟性も定めておきます。そうしておけば、将来の再設計に備えられます。
法対応と外部連携の要件化
契約は法的効力を持つ文書のため、保存要件や証拠力に関わる対応が欠かせません。そのため、法対応と外部連携も、機能と同じように要件として明確にします。
契約データは取引先情報や会計と関わり、法対応と外部連携には技術面の検討も必要です。このため、要件定義の早い段階で詰めておきます。
電帳法・電子署名法の対応要件
発注側は、法令への対応を契約類型ごとに分けて、要件定義書に具体化します。
- 電子帳簿保存法：タイムスタンプ、訂正・削除の履歴、取引年月日・金額・取引先による検索要件
- 電子署名法：立会人型と当事者型の区分、契約類型ごとの本人性の強度
- 電子化できない契約：紙運用を残す契約の特定と、システム上のステータス管理
製品が電帳法の要件を標準で満たすか、追加の対応が要るかを、発注側が確かめます。本人性の強度を使い分ければ、過剰な要件による費用増を避けられます。
たとえば、定期借地契約や任意後見契約は、書面が法的に義務づけられているため電子化できません。こうした契約について、電子化の可否と運用方針を一覧にしておくと、導入後の想定外を防げます。
法対応は、契約管理システムの信頼性を支える根幹です。そのため、要件定義書には曖昧さを残さず明記します。
CRM・会計連携の要件化
まず、契約管理システムをどの基幹システムにつなぐかを決め、連携の前提を揃えておきます。
- CRM/SFA：取引先マスタの共有と、契約・商談の紐付け
- 会計・経費精算：契約金額や支払い条件をもとにした計上の自動化
- 接続条件：システム名とデータ項目、連携の向き（双方向か一方向か）、タイミング（リアルタイムかバッチか）、連携方式（API・CSV・ファイル）の具体化
ベンダーが連携費用を見積もるには、連携条件を決めておく必要があります。標準APIで対応できる場合は追加費用を抑えられる一方、独自のカスタマイズでは数十万〜数百万円かかります。
そのため、標準連携で足りるか、作り込みが必要かを見極めることが、見積りの精度と妥当性の判断を左右します。
必須の連携に絞り、効果を見ながら広げていく計画が現実的です。また、明確な連携要件が、二重入力の解消を支えます。
紙データ移行とメタデータ保持の要件
既存の紙契約や旧システムからの移行は、実務でつまずきやすい論点です。また、導入前の紙データが未処理であることを課題とする企業は33.6%でした（出典：ContractS、2023年10月）。
移行を要件に含めないと、過去の契約が見えず、一元管理が中途半端になります。そのため、要件定義の段階で移行の範囲と方針を決めておきます。
メタデータ保持と移行範囲の要件化
発注側は、移行の対象と検証方法を具体化し、更新管理に必要な情報を保ちます。
- 保持項目：契約相手・契約日・更新日・金額・ステータスの欠落を防ぐ
- 移行仕様：項目マッピング、CSV一括取込やAPIなどの手段の記載
- 検証と切替：移行後の突合方法と、旧契約の解約・新規契約の時期
メタデータが欠けると、更新アラートが機能せず、一元管理の価値も損なわれます。そのため、旧システムとの移行期間中に、データを二重管理しない方法も決めておきます。
紙契約は、全件を一度に処理する前提にせず、優先順位を決めて進めます。更新期限が近い契約、金額が大きい契約、係争リスクのある契約を先に登録し、保管義務だけの古い契約は後回しにします。
優先順位を要件定義書に明記すれば、移行の範囲を現実的な日程に収められます。多くの企業が全件を一度に処理しようとして頓挫するため、段階的な計画を立てます。
AI-OCR・AIレビューの要否の切り分け
要件定義では、契約量、移行件数、法務工数をもとに、AI機能が費用に見合うかを判断します。AI機能は、標準機能か月額数万円の追加オプションかで費用が変わり、誤認識のリスクもあります。
- AI-OCR：契約日や当事者名の抽出による、台帳入力の工数削減
- AIレビュー：不利な条項の指摘による、法務工数の削減
- 要件上の扱い：「必須」「あれば望ましい」「不要」の区分ごとの費用見積り
移行対象が数万件に及び台帳入力が大きな負担になるなら、AI-OCRの工数削減効果が費用を上回る可能性があります。一方、数百件で手入力できる場合は、過剰投資になりかねません。
AIレビューは、月間のレビュー件数と法務の逼迫度で判断します。そのうえで、RFPで費用の内訳を求めれば、過不足のない投資判断につながります。
AI機能の要否を切り分ける視点は、他社の記事では扱いが手薄で、差別化につながる点でもあります。
非機能要件と権限・セキュリティの要件化
移行とAI機能の要否を決めたら、見落とされがちな非機能要件も定義します。機微情報を扱うため、権限とセキュリティも欠かせません。
- 権限制御：部署・役職ごとに閲覧・編集・承認できる契約の範囲
- セキュリティ：通信の暗号化、不正アクセス対策、ログ保存の要件化
- 性能・可用性：想定件数・同時アクセス数、稼働率・復旧時間、バックアップの定め
契約には取引条件・金額・係争情報が含まれます。そのため、本来見るべきでない人に契約が見えない状態をつくり、IPA（情報処理推進機構）のガイドラインなどを参照します。
契約数が多い企業では、検索や台帳表示が遅いと、利用されなくなる原因になります。このため、契約の締結や承認が止まらないよう、性能水準と障害時の体制を決めておきます。
非機能要件が曖昧だと、リリース後に遅延や停止、情報漏れが起こり、現場の信頼を失います。そのため、機能要件と同じくらい丁寧に詰めることが、形骸化しない品質を支えます。
RFPに盛り込む項目と見積りの妥当性判断
要件定義書をもとにRFP（提案依頼書）を作り、複数のベンダーに提案を依頼します。RFPが曖昧だと、見積りも曖昧になり、横並びで比べられません。
契約管理システムは、パッケージのSaaSからフルスクラッチ開発まで、費用の幅があります。そのため、RFPで前提を揃えることが妥当性判断の土台になります。
RFPに必ず盛り込むべき項目
発注側は、RFPに最低限の項目を盛り込み、ベンダーが同じ前提で提案できるようにします。
- 目的・業務：契約事務の削減、更新漏れの防止、ガバナンス強化という目的と、AsIs・ToBeの業務フロー
- 機能・法対応：管理・締結・承認・ライフサイクル各機能の優先度と、電帳法・電子署名法への対応
- 連携・移行：CRM・会計の連携範囲と対象件数、メタデータ保持、移行の優先度
- 実施条件：AI機能の要否、予算・日程の目安、運用・保守体制
承認ルートの再現性と法対応は、機能要件の中核として具体的に書き込みます。内容が具体的であれば、提案が自社の業務に沿ったものになり、ベンダー間で前提がずれるのを防げます。
見落としやすい従量料金とオプションについても、内訳の開示を求めます。たとえば、電子契約の送信料は1件50〜300円で、平均は税込110〜220円です。
AI機能やカスタマイズ連携も、オプション課金になりがちです。そのため、料金の構造をあらかじめ開示してもらう必要があります。
初期費用・月額基本料・送信料・オプションの4構成で見積りを求めると、ランニングコストや件数増加時の費用を試算できます。想定外の従量課金を防ぐ工夫です。
見積りの妥当性の確かめ方
発注側は、集まった見積りの妥当性を判断するために、まず相場観を持ち、提示額の理由を確認します。
- 相場との比較：費用が大きく外れる場合の理由の確認
- 内訳の確認：「一式」になっている設定・移行費やカスタマイズ費の開示
- 追加単価：機能・工程別の工数と単価、追加要件の単価ルールの取り決め
クラウド型の電子契約・契約管理は、初期費用0円が目安です。ただし、連携のカスタマイズを加えると、数十万〜数百万円かかります。また、月額基本料は5,000〜10,000円が目安です。
中小企業では月額数千〜2万円、大企業は見積りです。送信料は1件50〜300円、ワークフローは月額300〜1,000円/ユーザーが目安です。
安すぎる見積りには法対応や移行の漏れが、高すぎる見積りには不要なオプションが含まれている可能性があります。そのため、相場から外れた理由を確かめます。
一式見積りのまま契約すると、追加請求が重なって総額が想定を超えるリスクがあります。内訳と追加単価を事前に固めておけば、予算超過を防げます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件を透明に整理し、見積りの内訳を明示する進め方を重視しています。
要件定義の精度が見積り判断の精度を決めます。契約から文書、稟議、帳票までの業務に必要な投資を見極める土台です。
まとめ
契約管理システムの要件定義は、承認ルートと例外運用の可視化から始めます。そのうえで、電帳法・電子署名法への対応とCRM・会計連携を要件化し、紙データとメタデータ、AI機能の要否も具体化します。
RFPには、目的、連携範囲、移行スコープを明記したうえで、料金の内訳の開示と体制も示します。また、月額基本料は5,000〜10,000円、送信料は1件50〜300円、ワークフローは月額300〜1,000円/ユーザーが相場の目安です。
導入後に課題を感じる企業は約8割にのぼり、課題の多くは要件定義の詰めの甘さに起因します。そのため、要件の質がプロジェクトの成否を左右します。
riplaは発注企業と協働し、現場の可視化からToBe設計、法対応・連携・移行の要件化、RFP作成までを支援します。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。