地方企業のDX・IT導入と契約リスク：失敗しない実務対応

システム導入を「発注して終わり」にせず、要件・変更・データ・終了まで管理する

1　DX・IT導入の失敗は「契約締結前」から始まる

IT導入で最初に決めるべきなのは製品名やベンダーではなく、「何を改善したいのか」と「どこまでを今回のプロジェクトに含めるのか」です。現場の不便をすべて一度に解消しようとすると、要件が増え続け、予算・期間・品質のバランスが崩れます。

特に専任のIT担当者が少ない企業では、ベンダーへ判断を丸投げしやすくなります。しかし、業務の優先順位や社内ルールを決められるのはユーザ企業側です。発注者側の意思決定体制を作ること自体が、契約リスクを下げる第一歩です。

2　「IT契約」は一つではない

DX案件では、企画・要件定義、開発、導入支援、保守運用、SaaS利用など複数の契約が連続します。契約書の名称だけで請負・準委任等の法的性質が決まるわけではありませんが、成果物の完成を中心とするのか、一定の専門業務を遂行することを中心とするのかで、報酬、検収、責任、終了時の扱いが変わります。IPAの「情報システム・モデル取引・契約書（第二版）」も、受託開発・保守運用に加え、パッケージやSaaS/ASPの活用を分けて整理しています。

一つの契約書ですべての工程を曖昧に包むより、工程ごとの目的・成果・責任を分けた方が、途中で問題が生じたときに何を基準に判断するかが明確になります。

3　要件定義は「ベンダーに任せればよい」ものではない

システム開発で最も重要な契約資料の一つが、要件定義書・仕様書・見積前提資料です。IPAのモデル契約は、ベンダー側のプロジェクトマネジメントだけでなく、ユーザ側の協力も重視しています。ベンダーには技術的な専門性がありますが、自社の業務、例外処理、権限、締め処理、法令上必要な保存、既存データの意味等はユーザ企業が説明し、判断しなければなりません。

3-1　少なくとも確認したい要件

• 対象業務と対象外業務、利用者・権限、承認フローを明確にする。
• 機能要件だけでなく、性能、可用性、バックアップ、ログ、セキュリティ等の非機能要件を確認する。
• 既存システム・会計・EC・決済・外部サービス等との連携方法と責任分界を定める。
• 移行するデータの範囲、形式、名寄せ・重複・欠損の処理、移行後の照合方法を決める。
• 法令・業界ルール・社内規程上必要となる保存期間、アクセス制御、監査証跡等を洗い出す。

RFP、提案書、見積書、要件定義書、仕様書、議事録で内容が食い違う場合に備え、契約上どの文書を優先するのかも定めておくと紛争を減らせます。

4　仕様変更と追加費用は「変更管理」のルールで処理する

IT導入では、開発途中で仕様変更が生じること自体は珍しくありません。問題は、「少し直してほしい」という口頭・チャット上の依頼が積み重なり、後から追加費用・納期延長を巡って対立することです。

変更管理が機能していれば、「当初契約に含まれていたのか」「追加料金なのか」という争いを減らせます。反対に、発注者が承認手続を遅らせれば開発全体が止まるため、社内の意思決定期限も定めることが重要です。

5　検収は「動いたか」ではなく、合意した基準で行う

受託開発では、納品後に何をもって検収合格とするかを契約前に定めます。検収基準が「問題なく動作すること」だけでは、期待した使い勝手と仕様上の完成との区別がつきません。

• 検収対象となる成果物、テスト環境、テストデータ、検収期間を定める。
• 要件・仕様ごとの合格条件と、軽微な不具合が残る場合の扱いを決める。
• 重大不具合と軽微不具合を分け、修補期限・再検収方法を定める。
• 一定期間返答がない場合の「みなし検収」条項は、社内確認に必要な期間と整合しているか確認する。
• 本番移行・料金支払・保守開始を、検収とどのように連動させるか決める。

検収後であっても、契約不適合や保証・保守の問題がすべて消えるとは限りません。民法上のルールと契約条項を踏まえ、通知期間、修補、代替、報酬減額、損害賠償等をどの範囲で定めるか確認します。

6　遅延・失敗時は「どちらが悪いか」より原因と意思決定を記録する

システム開発では、ベンダーの設計・進行管理だけでなく、ユーザ側の回答遅延、資料不足、仕様変更、データ準備の遅れが工程に影響することがあります。IPAのモデル契約でも、ベンダーのプロジェクトマネジメント義務とユーザ側の協力義務が重要論点とされています。

• 定例会で課題、期限、担当者、未決事項を残す。
• 納期遅延のおそれが出た時点で、原因、回復案、追加費用、優先順位変更を協議する。
• 重要な仕様決定を誰が承認したかを記録する。
• ベンダーからリスク警告を受けた場合、経営・現場側で判断を止めない。

ITプロジェクトでは契約書だけでなく、要件表、課題管理表、議事録、チケット等が実際の合意内容を示す資料になります。紛争予防の観点からも、プロジェクト管理と契約管理を分断しないことが重要です。

6-1　関連裁判例：ベンダーには計画変更や中止を提言すべき場合がある

東京高裁平成25年9月26日判決（平成24年（ネ）第3612号）は、大規模なシステム開発が途中で中止となった事案について、ベンダーのプロジェクト・マネジメント義務を正面から論じています。裁判所は、契約締結後のベンダーには、開発過程で得られた情報を集約・分析し、専門的知見を用いて開発を進め、ユーザに必要な説明を行い、その了解を得ながら必要な修正・調整を行う義務があるとしました。

さらに、この義務の具体的内容は固定的なものではなく、プロジェクトの進行状況に応じて変化するとしています。当初想定した開発費用、開発スコープ、開発期間について大幅な修正が必要となった場合には、ベンダーは開発状況を分析したうえで、計画変更の要否・内容だけでなく、場合によっては開発中止の要否とその影響まで適時適切に説明する必要があります。

本件では、当初想定した条件での開発継続が困難であることが明らかになった段階で、ベンダーには、抜本的な見直しが必要であることや、適切な見直しをしないまま進めれば既に投入した費用や今後の費用が無駄になり得ることを具体的に説明し、ユーザの判断を促す義務があり、危機を回避できない場合には開発中止を提言する義務もあったと判断されました。

一方、裁判所は企画・提案段階について、ベンダーがシステム開発技術に詳しくてもユーザの業務内容まで当然に熟知しているわけではないことを踏まえ、ユーザ側にも、自社業務を分析し、ベンダーの説明を踏まえてシステム開発のリスクを自ら検討することが求められるとしています。ベンダーが専門家であることと、ユーザ企業が業務要件や経営判断を丸投げできないことは両立します。

この判決を踏まえると、地方企業のIT導入でも、次のような運用を契約・プロジェクト管理の双方に落とし込むことが有用です。

• ベンダーからリスクが示された場合に、誰が、いつまでに、継続・変更・中止を判断するかを決める。
• 費用・スコープ・納期の前提が崩れた場合は、影響と選択肢を具体化し、口頭の注意喚起だけで終わらせない。
• 重要な警告、提案、承認、保留事項は、議事録・課題管理表・チケット等で記録する。
• ユーザ側も、自社業務の優先順位、例外処理、必要機能、許容できる費用・納期を判断できる責任者を置く。

なお、本件では、システム開発中止についてユーザ側の責任や過失相殺は認められていません。したがって、この判決を「ユーザにも協力義務違反が認められた事例」と理解するのではなく、ベンダーの専門家としての義務と、ユーザ自身に求められる業務分析・リスク判断の双方を示した裁判例として位置付けるのが適切です。

7　SaaS・クラウドは「利用開始のしやすさ」より出口条件を確認する

SaaSは短期間で導入できる一方、契約条件が事業者の利用規約で定型化され、個別交渉が難しいことがあります。料金と機能だけでなく、サービス停止・仕様変更・データ移行・解約を含めて比較します。

特に基幹業務をSaaSへ移す場合は、サービス終了や乗換え時に必要なデータを標準的な形式で取得できるか、データ抽出に追加費用がかかるか、旧システムとの並行稼働期間を確保できるかを契約前に確認します。

8　個人情報を預ける場合は、委託先監督とクラウドの実態を確認する

顧客・従業員等の個人データをITベンダーやSaaS事業者へ取り扱わせる場合、個人情報保護法上、委託元には委託先に対する必要かつ適切な監督が求められます。個人情報保護委員会のガイドラインは、適切な委託先の選定、委託契約の締結、取扱状況の把握を具体的な監督方法として示しています。

• どの個人データを、何のためにベンダーへ取り扱わせるかを限定する。
• アクセス権、暗号化、ログ、バックアップ、削除、従業者管理等の安全管理措置を確認する。
• 再委託先・サブプロセッサの範囲と管理方法を確認する。
• 漏えい等が発生した場合の通知期限、調査協力、本人・当局対応を定める。
• 契約終了時の返却・削除と、バックアップ上の残存データの扱いを確認する。

8-1　海外クラウドは「サーバ所在地」だけで判断しない

海外クラウドでは、サーバが国内にあるかだけで個人情報保護法上の扱いは決まりません。個人情報保護委員会は、外国事業者が保存された個人データを取り扱う場合には、国内サーバであっても外国にある第三者への提供に該当し得る一方、事業者が個人データを取り扱わない契約・技術構成であれば扱いが異なるとしています。また、外国で個人データを取り扱う場合には、安全管理措置として当該外国の制度等を把握すべき場面があります。したがって、契約主体、実際のアクセス権限、サポート拠点、データ保存・処理場所を確認します。

9　サイバーセキュリティは「ベンダー任せ」にしない

経済産業省・IPAのサイバーセキュリティ経営ガイドラインVer.3.0は、経営者のリーダーシップ、自社だけでなくサプライチェーン全体への目配り、平時・緊急時のコミュニケーションを基本原則として示しています。IT導入契約でも、セキュリティを「一般的な対策を行う」とだけ書くのではなく、対象システムに応じた要求を具体化します。

中小・地方企業では、自社だけで高度な対策を内製することが難しい場合があります。その場合こそ、「どこまでをベンダーが担い、何を自社で運用するのか」を契約・運用手順で分ける必要があります。

10　知的財産は「全部自社帰属」にすればよいわけではない

システムには、ベンダーが従来から保有するプログラム、汎用モジュール、オープンソースソフトウェア、第三者製品、新たに開発する個別部分などが混在します。すべての知的財産権を一律にユーザ企業へ移転させる条項は、現実の開発構造と合わない場合があります。

• 既存プログラム・汎用ノウハウと、個別開発部分を区別する。
• 著作権を移転しない部分について、自社が必要とする利用・複製・改変・保守委託の権限を確保する。
• 第三者ソフトウェア・OSSのライセンス条件と費用を確認する。
• ソースコードの納品が必要か、将来別ベンダーへ保守を移せるかを検討する。
• 既存技術を使った追加開発を別拠点・関係会社で利用する場合の権限を確認する。

重要なのは「権利を多く取ること」ではなく、導入後の運用、改修、ベンダー変更、事業承継等に必要な権限を確保することです。

11　データは「所有権」だけでなく利用・持出し・削除を決める

データは有体物のような所有権だけで整理しにくいため、入力データ、システムログ、分析結果、加工データ等について、誰が何の目的で利用できるかを具体的に定めます。

• 自社が入力・蓄積した業務データをベンダーが自社サービス改善等に利用できるか確認する。
• 統計化・匿名化したデータの二次利用条件を確認する。
• 契約終了時に取得できるデータの範囲、形式、媒体、取得期限、費用を定める。
• 削除証明やバックアップ消去について、重要度に応じて確認する。
• 他システムへ移行するためのAPI仕様、エクスポート仕様、移行支援を確認する。

DXが進むほど、データは次の経営判断や新サービスの基礎になります。契約終了時に自社データを実用的な形で回収できない状態は、システムそのもの以上に大きなロックインとなり得ます。

12　解約・ベンダー変更は導入時から設計する

IT契約では「うまくいくこと」を前提に契約しがちですが、実際には事業方針変更、料金改定、品質問題、サービス終了、ベンダー変更等が起こり得ます。終了条件を契約当初から設計しておくと、移行時の事業停止リスクを下げられます。

本番稼働後に「他社へ変更したい」と考えてから出口条件を交渉するのでは遅いことがあります。特に基幹システムや長期利用するSaaSでは、移行可能性をベンダー選定の評価項目に入れることが有用です。

13　損害賠償・責任制限は、事故類型ごとに確認する

IT契約では、損害賠償額の上限、間接損害・逸失利益の除外、サービス停止時の免責等が定められることが一般的です。責任上限を「高い・低い」だけで判断せず、事故類型と事業影響を踏まえて確認します。

• 開発遅延、重大障害、データ消失、情報漏えい、知財侵害等を分けて想定する。
• 通常の債務不履行と、故意・重大な過失等を同一の責任上限で扱うか確認する。
• 自社の顧客への補償や業務停止損害が発生した場合、契約上どこまでカバーされるか確認する。
• SaaSのサービスクレジットが唯一の救済手段になっていないか確認する。

契約交渉で全てのリスクをベンダーへ転嫁するのは現実的ではありません。重要業務ほど、契約上の責任分担に加えて、自社のバックアップ、代替手段、BCP等を組み合わせます。

前記東京高裁平成25年9月26日判決では、故意・重過失がない場合の責任制限条項について、大手企業間で弁護士等の助言を受けながら交渉して合意した事情などを踏まえ、有効と判断されています。もっとも、責任制限条項の有効性や適用範囲は、当事者の属性、交渉経緯、条項内容、問題となる義務違反等によって異なるため、この判決だけから一律に判断できるものではありません。

14　地方企業がDX・IT導入を進める実務手順

15　弊所の実務上の視点

地方企業のIT導入で契約書を確認するとき、最初に見るべきなのは損害賠償条項だけではありません。まず、経営側・現場側が「何を作るのか」「何をベンダーへ依頼するのか」「誰が決めるのか」を共有できているかを確認します。仕様が固まっていない状態では、どれだけ精緻な責任条項を書いても、追加費用や納期を巡る問題を防ぎにくいためです。

そのうえで、①契約類型と工程、②要件・仕様、③変更管理、④検収、⑤SaaS・クラウド条件、⑥個人情報・セキュリティ、⑦知財・データ、⑧損害賠償、⑨解約・移行を一枚の論点表にして確認すると、経営・現場・ベンダーの認識差を見つけやすくなります。IT専任者が少ない企業ほど、契約レビューを「法務だけの確認」にせず、プロジェクト運営そのものと一体で行うことが重要です。

16　DX・IT導入前チェックリスト

17　よくある質問

18　弁護士への相談を検討すべき場面

• 基幹システム・ERP・CRM等を新規導入又は刷新する
• 要件定義が固まらないまま高額な開発契約を締結しようとしている
• 開発途中で追加費用・納期延長についてベンダーと認識がずれている
• SaaS・クラウドへ顧客・従業員の個人データを保存する
• 海外クラウド・海外ベンダーを利用する
• 自社独自のデータ・ノウハウ・アルゴリズムをベンダーへ提供する
• 契約の責任上限・免責が事業影響に比べて大きく偏っている
• 解約、ベンダー変更、データ移行の条件が不明確である
• 開発遅延、不具合、検収拒否、追加請求等の紛争が生じている

19　まとめ

地方企業のDX・IT導入では、契約書を締結すること自体よりも、経営目的、要件、変更、検収、運用、終了を一貫して管理することが重要です。ITベンダーの専門性を活用しつつも、自社の業務要件と意思決定まで丸投げすることはできません。

受託開発では要件定義・変更管理・検収、SaaS・クラウドではSLA・データ・料金・解約、いずれの場合も個人情報、セキュリティ、知的財産、責任制限、終了時移行を確認します。特にIT専任者が少ない企業では、経営・現場・IT・法務を同じ論点表でつなぐことで、導入後に「想定と違った」「追加費用が止まらない」「データを持ち出せない」という事態を避けやすくなります。

20　主要な一次資料

• IPA「情報システム・モデル取引・契約書（第二版）」
• IPA「情報システム・モデル取引・契約書（アジャイル開発版）」
• 経済産業省「DX推進指標」
• 経済産業省「デジタルガバナンス・コード」
• 経済産業省「サイバーセキュリティ経営ガイドラインと支援ツール」
• 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」
• 個人情報保護委員会「個人情報保護法ガイドライン（外国にある第三者への提供編）」
• e-Gov法令検索「民法」
• e-Gov法令検索「個人情報の保護に関する法律」
• 東京高裁平成25年9月26日判決（平成24年（ネ）第3612号）