基幹システム・ERPを外部へ依頼する時の契約上の注意点

基幹システム・ERPを外部へ依頼する際は、契約書本文だけを読んでも判断しきれません。実務では、基本契約、個別契約、要件定義書やSOW、見積書、提案書、保守契約、SLA、利用規約、セキュリティ別紙まで突き合わせて、業務範囲、責任分担、追加費用、検収条件、終了時対応がそろっているかを確認する必要があります。

この記事では、読者が知りたい順番に沿って、どの文書を見て、何を確認し、どこで止めるべきかを整理します。読み終える頃には、契約案の比較、差し戻しポイントの整理、社内稟議に残すべき確認事項の洗い出しができる状態を目指せます。

基幹システム・ERPを外部へ依頼する際は、契約書本文だけでは判断しきれません。基本契約、個別契約、要件定義書やSOW、見積書、保守契約、SLA、利用規約まで照合し、業務範囲、責任分担、追加費用、検収条件、終了時対応がそろっているかを確認する必要があります。

この記事では、どの文書をどの順番で見て、何を確認し、どこで止めるべきかを整理します。読後には、契約案の比較、差し戻し論点の整理、社内稟議に残すべき確認事項の洗い出しを進めやすくなります。

契約確認は契約書本文だけでなく、関連文書一式を6つの確認軸で照合して進めると整理しやすくなります。

01Section契約確認は「契約書1枚」では終わらない

最初に押さえたいのは、契約確認を契約書本文だけでなく、文書一式の照合作業として進めることです。IPAの情報システム・モデル取引・契約書では責務整理や契約ひな型が示されており、IPAの講演資料でも、工程ごとに契約類型を見分け、運用段階・保守段階を別契約で確認する整理が示されています。

最初に集めるべき契約文書

先に読む順番と文書不一致の見つけ方

確認の順番を固定すると、文書の食い違いを見つけやすくなります。

文書の優先順位は一般論で決め打ちしないことが大切です。優先文書条項、個別契約による上書き、別紙参照関係の書き方で変わるため、現物の条文で確認します。

契約類型で見方が変わるポイント

02Section契約前に社内で決めておく前提は何か

契約案の良し悪しは、社内前提が固まっていないと判断しにくいものです。対象業務や標準運用の方針が曖昧なままでは、見積も契約条件もぶれます。契約を見る前に、自社で何を決めるべきかを切り分けておくことが先です。

対象範囲と標準運用の方針

特に基幹システム・ERPでは、「標準に寄せる」と言いながら、帳票、権限、連携、締め処理だけ個別要件が多く残ることがあります。ここが固まっていないと、見積時は標準前提、契約後は個別開発前提というズレが起きやすくなります。

誰が要件を決め、誰が受け入れるのか

要件の決裁者と受入判定者が別々なのに、契約上の承認者が曖昧なままだと、要件確定も検収も止まりやすくなります。業務部門、情シス、法務、決裁者のうち、誰が最終承認を持つのかを先に決めておくと、ベンダー側の責任分担も整理しやすくなります。

稼働後を含めた社内体制の最低ライン

運用開始後の問い合わせ窓口が未定のまま契約すると、保守契約の対象範囲が合っていても実際の運用が回りません。初期安定化の窓口、定常保守の窓口、障害時の連絡系統は、導入前から契約条件とそろえておく必要があります。

03Section業務範囲・責任分担をどこまで書面化するか

この章の判断軸は明確です。対象と対象外が同じ粒度で書かれているか、工程ごとに主担当が分かるか、成果物と顧客側協力義務が曖昧でないかを見ます。ここが曖昧だと、追加費用、納期遅延、責任の押し付け合いが起きやすくなります。IPAの見直しポイントでも、ユーザの協力義務や責任制限など、発注側が見落としやすい論点が整理されています。

「対象」と「対象外」を同じ粒度で書く

対象業務、対象機能、対象拠点だけでなく、移行、連携、帳票、教育、初期安定化、旧システム側作業、データクレンジングまで並べて確認します。対象だけ細かく、対象外が「別途協議」のままでは比較になりません。

工程別の役割分担を切り分ける

役割分担は、工程ごとに「ベンダー主担当」「顧客主担当」「共同確認」「止めるべき状態」を並べると整理しやすくなります。会議体や体制図だけで判断せず、各工程の責任をSOWや個別契約まで落として確認することが重要です。

成果物と顧客側協力義務を曖昧にしない

ここで重要なのは、顧客側作業を「協力すること」で終わらせないことです。提供物、期限、遅延時の納期・費用影響まで書かれていなければ、後半工程で責任が曖昧になりやすくなります。

成果物定義は、納品物の名前だけでは不十分です。何を含み、何を含まず、どの形式で提出され、どれが検収対象かまで見ます。

04Section費用・追加請求・変更管理はどう見るか

費用を見るときは、総額から入らないことが重要です。比較や稟議に使えるのは、「何にいくらかかるか」より前に、「どの区分で増えるか」を分けて見た整理です。IPAの調達管理ガイドやデジタル庁の標準ガイドライン解説書でも、見積の内訳や前提条件を妥当性確認できる粒度で捉える考え方が示されています。

まず費用の構造を分ける

費用は総額だけでなく、どの区分で増減するかまで分けて見ると比較しやすくなります。

最低でも、初期費用、定常運用費、変更・追加対応費、終了時費用の4つに分けると整理しやすくなります。初期費用の中も、要件定義、設定、追加開発、移行、テスト、教育、初期安定化を分けて見ると、比較しやすくなります。

追加費用が起きやすいトリガーを押さえる

追加費用が出やすい場面は、要件追加、仕様変更、データ不備の補正、連携先変更、支援回数超過、夜間休日対応などです。大事なのは、どの場面で増えるかだけでなく、どの文書にその条件が書かれているかを合わせて確認することです。

変更依頼と承認フローを契約で管理する

変更管理は、着手前の書面化が基本です。変更内容、影響範囲、費用、納期、既存契約との差分、承認者、承認日が残らないまま進むと、後で予算管理が崩れます。稟議へは次の形で1案件1行、または変更依頼1件1行で転記すると整理しやすくなります。

稟議転記テンプレート

• 費用区分:
• 含まれる作業:
• 前提条件:
• 対象外:
• 追加費用トリガー:
• 承認者:
• 終了時費用:

この7項目がそろうと、総額だけでなく「どこで増えるか」「どこまで含むか」「将来いくら残るか」を同じ視点で比較できます。実単価や追加改修費は公開情報だけでは横並びにしにくいため、候補比較では同一前提・同一数量での再見積確認が必要です。

社内試算は、次の式で別枠管理にしておくと実務で使いやすくなります。

総費用見込 = 初期費用 +（運用月額 × 想定利用月数）+ 予定変更費 + 終了時費用

運用メモ

• 変更依頼書なしで着手しない
• 累積増額を月次で可視化する
• 一定額超は再稟議に回す

予定変更費は契約金額本体と混同せず、想定変更項目に応じて別管理します。見積前提が崩れた場合に再見積へ切り替える条件まで確認できると、契約締結後の増額説明がしやすくなります。

05Section納期・検収・品質・責任制限で止めるべきポイント

納期や品質の条項は、単独で見ると判断を誤りやすい論点です。マイルストーン、検収、再検収、支払条件、責任制限を一続きで読むと、どこで止めるべきかが見えてきます。IPAの非ウォーターフォール型開発WG活動報告書では、準委任型を含む開発で、点検期間やみなし確認の考え方が整理されています。

マイルストーンと前提条件を揃える

納期は稼働日だけでは足りません。要件確定日、データ受領日、移行リハーサル日、受入テスト期間など、中間判定が置かれているかを見ます。顧客側の提供遅延で納期がどう変わるかも、ここで確認します。

検収・再検収・支払条件を一緒に見る

検収条件は、再検収や支払条件と切り離さずに確認すると判断しやすくなります。

最低限、検収対象、受入基準、テスト方法、検収期間、不適合時の通知方法、修正期限、再検収手順、みなし検収の条件、部分検収の可否、支払条件との連動を同じまとまりで確認します。検収基準が「正常に稼働すること」だけなら止めるべきです。業務シナリオ、例外処理、締め処理、連携失敗時、権限、帳票まで含めた受入条件が必要です。

品質不良と責任制限を自社影響で読む

責任制限は、上限額の一般論より自社の業務影響で読むほうが実務的です。会計締め、出荷、受発注、請求処理が止まった場合に、どこまで代替できるか。直接損害の範囲、除外事項、報告義務や復旧協力義務がどう切られているかを、自社の停止許容度と照らして確認します。重要事故でも一律上限なのか、個人データ、秘密保持、知財侵害、故意重過失がどう扱われるかは、個別条文で確認が必要です。

06Sectionデータ・権利・終了時対応はどこまで先回りするか

情報漏えい対策だけを見て終わると、更改や解約時に困ります。基幹システム・ERPでは、個人データだけでなく、業務データ、ログ、マスタ、設定値、スキーマ、データレイアウト、追加開発成果物、マニュアルまで、扱いを分けて確認することが重要です。

機密情報と個人データの扱い

秘密保持では、対象情報、例外、利用目的、開示先制限、返還・削除、保存期間を確認します。個人データを扱う場合は、個人情報保護委員会のガイドラインが示すように、委託先・再委託先への必要かつ適切な監督が前提です。再委託の事前通知や承認、事故報告、監査・取扱状況把握の条件が見当たらない場合は、そのまま進めないほうが安全です。

また、委託先が委託元から受け取った個人データを独自データと突合したり、新しい項目を付けて戻したりできるかは、個人情報保護委員会のFAQも確認先になります。

成果物・設定情報・利用権の見方

デジタル庁の標準ガイドライン解説書では、データやログ、スキーマ、データレイアウトの扱いを明確にする重要性が示されています。ここで大事なのは、帰属と利用権を分けて見ることです。たとえば、設定資料や追加開発成果物の帰属がベンダー側でも、顧客が利用、複製、改変依頼、次期移行で使用できる権利が不足すると、更改時に支障が出ます。

返却・削除・引継ぎ支援を導入前に確認する

終了時は、返却対象、返却形式、抽出回数、抽出期限、削除期限、削除証跡、引継ぎ支援、費用を見ます。デジタル庁のクラウド利用に関する基本方針でも、データ移行性や合理的な価格体系、導入プロセスの透明性が重視されています。

07Section導入後支援・保守運用・SLAの境界はどう確認するか

導入が終われば同じ条件で保守へ続く、とは限りません。IPAの講演資料でも、運用段階・保守段階を別契約で整理する考え方が示されています。導入契約に含まれる初期安定化と、別保守契約で始まる定常支援の境界を分けて見ることが重要です。

導入契約と保守契約の切り分け

導入契約に入りやすいのは、受入支援、導入支援、初期安定化、稼働直後の問い合わせ対応です。一方、定常問合せ、障害受付、SLA運営、継続改修は保守契約で定められることが多くなります。境界日や対象障害の範囲が曖昧なままだと、「これは導入後の無償対応か、保守の有償対応か」で揉めやすくなります。

SLAで見るべき項目

METIのSLAガイドラインでは、SLAを数値項目だけでなく、前提条件、委託範囲、役割と責任、結果対応、運営ルールで見る考え方が整理されています。比較時は、受付時間、優先度定義、一次回答目標、復旧目標に加え、対象外条件や未達時の扱いまで確認します。

法改正・軽微改修・追加教育の扱い

見落としやすいのが、法改正対応、軽微改修、追加教育です。ここは公開情報だけでは同条件比較が難しいため、個別契約、SLA、見積で確認します。確認するときは、月額内か別費用か、軽微の定義があるか、回数や対象者が決まっているかという順で読むと整理しやすくなります。

08Section契約案を差し戻す時の進め方

最後は、契約案の読み方を差し戻し実務へつなげます。差し戻しは感覚で返すより、「どの論点が」「どの文書で」「どう食い違い」「何に影響し」「誰に直してもらうか」をそろえるほうが通りやすくなります。

不一致の洗い出し方

まず、範囲、検収、費用、再委託、データ返却、保守境界のように論点ごとに並べ、契約本文、個別契約、SOW、見積書、提案書、SLA、利用規約を横に置きます。不一致があれば、優先文書条項の確認に進む前に、事実として差分を一覧化します。

ベンダーへの優先質問

最初に聞くべきなのは、含む作業と対象外作業、検収完了条件、追加費用の起点、終了時に返却されるデータと費用、初期安定化と保守開始の境界です。営業だけでなく、PM、法務、情報システム部門の誰が修正窓口かも合わせて確認すると、差し戻しが止まりにくくなります。

署名前の最終整理

署名前は、止める条件を論点単位で確認すると漏れを減らせます。

契約確認の目的は、条文をたくさん読むことではなく、導入後に揉める論点を署名前に減らすことです。範囲、責任分担、費用、検収、データ、保守の6軸で文書をそろえ、食い違いをメモ化できれば、比較・差し戻し・稟議の精度は大きく上げられます。