OUTSOURCING

システムの保守契約で決めておくこと

システムの保守契約で、発注者と開発会社が事前に決めておきたい項目を整理します。対応する範囲、受付と対応の時間帯、費用の形、更新と終了、終了の後の引き継ぎまで、IPAのモデル契約書を参考に説明します。

開発の発注と契約(OUTSOURCING)のコラム

この記事の要点

  • 保守契約では「何を直すか」と「何を対象外とするか」を、まず書き分けておくことが大切です
  • 受付時間・応答時間・復旧時間のように、測れる言葉で対応の約束を決めると食い違いが減ります
  • 費用の形と、更新・終了・引き継ぎの段取りは、契約を結ぶときに決めておくのが安全です

システムの保守契約で決めておきたいことは、大きく分けて「対応する範囲」「対応の時間帯と速さ」「費用の形」「更新と終了」の4つです。開発が終わって公開した後のシステムは、不具合への対応、部品の更新、使い方の問い合わせなど、手がかかる場面が続きます。保守契約は、その手のかけ方を発注者と開発会社で前もって決めておくための約束です。

ここでは、IPA(情報処理推進機構)が公開している「情報システム・モデル取引・契約書」の考え方を参考に、契約書に書いておきたい項目を順に整理します。内容は2026年11月時点で公開されている資料にもとづいています。

保守契約とは

保守契約とは、公開した後のシステムについて、不具合の調査と修正、部品やソフトウェアの更新、問い合わせへの対応などを、開発会社などに続けて任せる契約です。開発の契約とは別に結ぶことが多く、準委任の形で、月ごとの費用を払う形がよく見られます。

保守とよく並べて使われる言葉に「運用」があります。保守はシステムを直したり更新したりすること、運用は日々の監視やバックアップなどシステムを動かし続けることを指すのが一般的ですが、会社によって使い方が違います。言葉の違いは保守と運用に、社内と外部の分担の決め方はシステムの保守と運用は何が違うかにまとめています。契約書では、言葉の定義よりも、具体的な作業の一覧で範囲を示すほうが、食い違いが起きにくくなります。

IPAのモデル契約書(パッケージ、SaaS/ASP活用、保守・運用)の第二版追補版は、保守業務の内容を、SLA(サービスレベル合意)にもとづいて事前に合意しておくことが重要だとしています。

出典:情報システム・モデル取引・契約書(第二版)(IPA)

対応する範囲を書き分ける

保守契約で食い違いが起きやすいのは、対応する範囲です。「不具合は直す」と書いてあっても、どこまでを不具合と呼ぶかで、発注者と開発会社の考えが分かれることがあります。

範囲は、含むものと含まないものを両方書いておくと、判断に迷いにくくなります。

書いておく項目例
含む作業不具合の調査と修正、セキュリティの修正版の適用、問い合わせへの回答
含まない作業新しい機能の追加、画面の作り直し、利用者の増加に合わせた作り替え
対象のシステム対象の画面・機能・サーバー・つないでいるサービス
対象外の部品他社のパッケージ製品や外部のサービスで、別の契約で保守されているもの

新しい機能の追加は、保守の範囲に含めず、別に見積もる形にしておくと、月ごとの費用が膨らみにくくなります。開発の途中の仕様の変更と同じく、範囲の外の作業は手順を決めて扱います(開発の途中で仕様を変えたいときの進め方)。

IPAのモデル契約書は、ネットワークを含むシステム全体の障害の切り分けを任せる場合には、保守業務の範囲とともに、不具合の調査費用の扱いを決めておく必要があるとしています。原因が保守の対象の外にあったときに、調査にかかった時間をどうするかは、後で揉めやすい点です。

対応の時間帯と速さを、測れる言葉で決める

対応の時間帯と速さは、「すみやかに対応する」のような言い方ではなく、時間で決めておくと食い違いが減ります。IPAのモデル契約書は、保守の範囲・期間・金額とともに、受付時間・応答時間・復旧時間などを、測定できるサービスの内容として合意することを求めています。

受付時間は、連絡を受け付ける時間帯です。応答時間は、連絡を受けてから最初の返事をするまでの時間です。復旧時間は、連絡を受けてから業務を続けられる状態に戻すまでの時間です。3つを分けて決めておくと、「連絡したのに返事がない」と「返事はあったが直らない」を区別して話し合えます。

保守の対応の時間を、3つに分けて決める

  • 受付時間連絡を受け付ける時間帯
  • 応答時間連絡を受けてから、最初の返事をするまでの時間
  • 復旧時間連絡を受けてから、業務を続けられる状態に戻すまでの時間

分けて決めておくと、「返事がない」と「返事はあったが直らない」を区別して話し合えます

時間の約束を決めるときは、次の点もあわせて確かめておきます。

  • 平日の昼間だけか、夜間・休日も受け付けるか
  • 不具合の重さで分けるか(業務が止まるもの、一部が使えないもの、見た目の不具合など)
  • 復旧の時間は、元どおりに直すまでか、代わりの方法で業務を続けられるようにするまでか
  • 時間の約束を守れなかったときの扱い

夜間・休日の対応や、重さで分けた細かい時間の約束は、その分の体制が要るため、費用に影響します。数字の決め方はSLA(サービスレベル合意)の決め方で詳しく説明しています。

費用の形を選ぶ

保守の費用には、いくつかの形があります。どの形が合うかは、問い合わせや修正がどのくらい起きそうかで変わります。

費用の形内容向いている場合
月ごとの定額決めた範囲の作業を、月の費用で受け持つ作業の量が毎月ある程度決まっている
時間の枠月に使える作業の時間を決め、超えた分は別に払う作業の量に波がある
都度の見積もり作業のたびに見積もって払う作業がめったに起きない

月ごとの定額の場合は、その費用で何時間分の作業まで含むかを決めておくと、範囲の解釈で食い違いにくくなります。時間の枠の場合は、使わなかった時間を翌月に繰り越せるかも決めておきます。

更新と終了の段取りを決めておく

保守契約は、1年などの期間を決め、申し出がなければ自動で更新する形が多く見られます。更新と終了について、次の点を契約書で確かめておきます。

  • 契約の期間と、更新の扱い(自動で更新するか、毎回結び直すか)
  • 終了を申し出る期限(期間の満了の何か月前までか)
  • 費用を見直す時期と、その手順
  • 終了するときに受け取るもの(ソースコード、設計書、サーバーやサービスのアカウント、作業の記録)

終了するときの受け取りは、契約を結ぶときに決めておくほうが安全です。保守を別の会社に替えるときに、資料やアカウントがそろわず、引き継ぎに時間がかかることがあるためです。設計書や引き継ぎ資料を、保守の作業の中で更新し続けることを、範囲に入れておく方法もあります。替えるときの進め方は開発会社を替えるときの引き継ぎで扱っています。

契約の前に確かめておきたいこと

保守契約を結ぶ前に、発注者の側で次の点を整理しておくと、開発会社との話し合いが進めやすくなります。

  1. 止まると困る業務と、止まってもよい時間の長さ
  2. 社内の窓口になる人と、連絡の手段
  3. 保守の対象にするシステムと部品の一覧
  4. いま別の会社と結んでいる保守やサービスの契約

部品の一覧には、使っているオープンソースのソフトウェアやクラウドのサービスも含めておくと、更新やサポートの終了(EOL)への備えがしやすくなります。本記事は保守契約で決める項目を一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。

当社のご支援

当社は、Webシステム開発やAIインテグレーションで、公開した後の運用と改善まで続けて受け持っています。PHPで動くサイトの版上げの後の保守は、PHPのバージョンアップ支援でお受けしています。いまの保守の範囲や費用の形を見直したい場合は、相談や小さな開発を月単位で頼めるAIタイムシェアも含めて、お問い合わせからご相談ください。

  • 保守契約
  • SLA
  • 発注
  • 契約

この記事に出てくる用語

この記事を書いた人

石田 誠 グループCTO

インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

あわせて読みたい

開発の発注と契約のコラムを見る コラムの一覧に戻る

無料で相談する無料の診断