システム開発の保守契約｜納品後の対応範囲の確認点
システム開発の保守契約では、「保守」という一言の中に何が含まれているのかを、契約前に具体的に確かめておくことが大切です。この記事では、納品後に対応してもらえる範囲を種類ごとに分け、契約書や見積書で確認したい項目、不具合と仕様変更の線引き、新規事業ならではの考え方を整理します。
保守契約で起きやすい「言った・言わない」
システムを納品してもらうまでは、機能や画面、スケジュールの話が中心になります。一方で、納品後にどこまで面倒を見てもらえるのかは、開発の打ち合わせの終盤に軽く触れられるだけで、詳しく詰めないまま契約に進むことが少なくありません。
その結果、運用が始まってから次のようなすれ違いが起きがちです。
- 「保守に入っていると思っていたのに、機能の追加は対象外だった」
- 「夜間に止まったのに、連絡がつくのは翌営業日だった」
- 「不具合だと思って連絡したら、仕様どおりなので修正は別対応と言われた」
- 「サーバーのOSやライブラリの更新は誰がやるのか決まっていなかった」
どれも、どちらかが悪いというより、「保守」という言葉の指す範囲が両者で違っていたことが原因です。保守契約は、納品後の安心を買うための契約であるはずなのに、中身を確認しないままだと、いざという時に期待と実際がずれてしまいます。
このずれを防ぐには、「保守」を一つのかたまりとして見るのをやめて、業務の種類ごとに分けて確認するのが近道です。
保守に含まれる業務を5つに分けて考える
システム開発における保守・運用の業務は、大きく次の5つに分けられます。契約書には「運用保守一式」とだけ書かれていることもあるため、それぞれが含まれるかを一つずつ確かめます。
1. 障害対応
システムが止まった、画面が開かない、データが表示されないといった事態への対応です。確認したいのは、次の点です。
- 連絡を受け付ける窓口と手段（メール、電話、チャットなど）
- 受け付けの時間帯（平日の日中のみか、夜間や休日も含むか）
- 連絡を受けてから最初の返答までの目安
- 原因調査と復旧のどこまでを対応範囲とするか
「24時間365日対応」のような体制は、人員の確保が必要なため、通常は契約の条件が変わります。事業としてどの時間帯に止まると困るのかを先に整理し、必要な対応時間を合わせることが重要です。
2. 不具合の修正
納品したシステムが、本来の仕様どおりに動いていない箇所を直す対応です。ここでは「どの期間の不具合が対象か」と「何を不具合とみなすか」が論点になります。
請負契約の場合、納品物が契約の内容に合っていないときに、開発会社が負う責任（民法上の契約不適合責任）があります。この責任と保守契約の不具合修正は、別々のものとして定められていることが多く、両者の期間や対象が重なるのか、保守契約に入ってからは保守の範囲で扱うのかは、契約書を読んで確認する必要があります。納品直後の不具合は、検収の段階で見つけるのが基本です。検収の進め方はシステム開発の検収とは｜納品時の確認項目と進め方で詳しく整理しています。
3. 監視・バックアップ・定期点検
システムが正常に動いているかを見守り、データを定期的に保存し、問題の芽を早めに見つける作業です。確認したいのは次の点です。
- 稼働状況の監視を行うか、行う場合は何を対象にするか
- データのバックアップの頻度、保存期間、復元の手順
- 定期点検や報告書（月次レポートなど）の有無
バックアップは「取っている」だけでは不十分で、実際に復元できるかが肝心です。復元の訓練や手順の共有まで含まれるのかも、確認しておくと安心です。
4. 環境の更新対応
サーバーのOS、プログラミング言語、ライブラリ（他人が作った部品）、クラウドサービスなどは、時間とともにサポートが終わったり、セキュリティ上の修正が出たりします。これらへの追随をどこまで保守に含めるかは、見落としやすい項目です。
- OSやライブラリのセキュリティ更新を誰が判断し、誰が実施するか
- 外部サービスのAPI仕様が変わった場合の対応は、保守の範囲か別対応か
- 更新によって動作確認が必要になったときの作業の扱い
セキュリティ面の考え方は、AI生成コードのセキュリティ｜確認点と人の役割も参考になります。AIが書いたコードかどうかにかかわらず、納品後の更新を誰が担うのかは、運用の前提として決めておきたい点です。
5. 軽微な改修・機能追加
「ボタンの文言を変えたい」「項目を一つ増やしたい」「帳票のレイアウトを直したい」といった、小さな変更への対応です。保守契約の中で最も解釈が分かれやすい部分です。
- 軽微な改修を保守に含めるか、別の見積もりにするか
- 含める場合の上限（月あたりの作業量、件数など）
- 上限を超えた場合の扱い
- 機能追加の依頼から着手までの流れ
「どこまでが軽微な改修か」は、言葉だけで線を引こうとしても揺れます。たとえば「画面の文言・項目の追加は含む」「新しい画面や新しいデータ連携の追加は含まない」のように、具体例で線を引いておくと、後のやり取りが楽になります。
契約書や見積書で確認したい7つの項目
5つの業務の整理ができたら、次は契約書や見積書のどこを見ればよいかです。次の7項目を確認すると、抜けを減らせます。
1. 対応する範囲と対象外の範囲
「対応する」ことだけでなく、「対応しない」ことが明記されているかを見ます。対象外の記載が全くない契約は、解釈の余地が大きいということです。対象外の項目と、その場合の扱い（別見積もりで対応する、対応しないなど）が書かれていれば、後で話が食い違いにくくなります。
2. 対応時間と連絡手段
受け付け時間、返答までの目安、窓口を確認します。緊急時と通常時で連絡先が分かれていることもあります。担当者が不在のときの代替窓口があるかも見ておきます。
3. 対応の水準（返答や復旧の目安）
サービスの水準を定めた取り決めを、一般にSLA（Service Level Agreement）と呼びます。「連絡から何時間以内に一次返答をする」「月間の稼働率の目標」などを定める考え方です。小規模なシステムでは厳密なSLAを結ばないことも多いですが、その場合でも、返答の目安がどこかに書かれているかを確認しておきます。復旧の「保証」ではなく「努力目標」として書かれていることもあるため、表現も読み取ります。
4. 契約の期間と更新
保守契約は、一般的に1年単位などの期間で結び、更新していく形が多いです。確認したいのは次の点です。
- 契約期間と自動更新の有無
- 解約するときの通知期限
- 途中で内容を見直せるタイミング
新規事業では、運用開始後に事業の方向が変わることがあります。固定の期間に縛られすぎないか、内容を見直せる機会があるかは、事前に確認する価値があります。
5. 責任の範囲
障害でデータが失われた場合や、事業に損害が出た場合に、開発会社がどこまで責任を負うのかは、契約書の「責任」「損害賠償」の条項に書かれます。多くの契約では、責任の上限が定められます。内容を読み、事業への影響とのバランスを確認します。判断が難しいときは、法務の担当者や専門家に相談するのが安心です。
6. 第三者サービスの扱い
決済、メール配信、地図、認証、クラウドなど、外部のサービスを使うシステムでは、そのサービス側の障害や仕様変更が影響します。外部サービスそのものの障害は保守の範囲外になるのが一般的ですが、その際に原因の切り分けや代替策の相談まで対応してもらえるかは、契約ごとに異なります。
7. 引き継ぎに関する取り決め
将来、保守を別の会社に移したり、自社で担当したりする可能性に備え、次の点を確認します。
- ソースコード、設計書、環境構築の手順書などが納品物に含まれるか
- ソースコードの権利（著作権）が誰に帰属するか
- 契約終了時に、データや資料を受け取れるか
権利については、費用を支払っても自動的には移らない点が見落とされがちです。詳しくはソースコードの著作権譲渡｜費用を払っても自動では移らないにまとめています。開発会社の変更を検討する場面はシステム開発会社の乗り換え前に確認したい引き継ぎの要点が参考になります。
不具合と仕様変更の線引きを先に決める
保守の相談で最も揉めやすいのが、「これは不具合なのか、仕様変更なのか」という線引きです。
不具合は、あらかじめ決めた仕様どおりに動かないことです。一方、仕様変更は、決めた仕様とは別の動きを求めることです。「使ってみたら思っていたのと違った」という場合、利用者の感覚では不具合でも、仕様書の上では仕様どおり、ということがあります。
この線引きを曖昧にしないために、次の点を準備しておくと役立ちます。
- 仕様を示す資料（要件をまとめた文書、画面の設計、動くプロトタイプなど）が納品物に含まれている
- 仕様が書かれていない部分の動きを、どう扱うかの方針がある
- 「仕様どおりだが使いにくい」という要望の扱い（改善要望として別枠で受ける、など）が決まっている
言葉だけの仕様は、読む人によって解釈が変わります。実際に動くものを見ながら仕様を確認しておくと、納品後の「これは不具合か」という議論が減ります。仕様変更全般の扱い方はシステム開発の仕様変更への対応｜追加要望の扱い方で整理しています。
新規事業の保守は「育てる前提」で考える
ここまでは、保守契約の一般的な確認点でした。新規事業のシステムには、もう一つ考えたい視点があります。それは、運用が始まってからが本番だという点です。
既存業務を置き換えるシステムと違い、新規事業のシステムは、利用者の反応を見ながら機能を足したり、直したり、やめたりします。最初に決めた仕様が、半年後もそのまま正解とは限りません。このため、次のような考え方が合います。
不具合を直すだけの保守では足りないことがある
不具合修正と障害対応だけの保守契約では、事業の変化に追いつけないことがあります。小さな改善を重ねる前提なら、軽微な改修や機能追加を、定期的に依頼できる枠組みがあるほうが運用しやすくなります。
ただし、改修の枠を広げれば契約の条件も変わります。事業の段階に応じて、「まずは安定稼働を優先する時期」と「改善を重ねる時期」で、保守の中身を見直せるかどうかを確認しておくと、無理のない運用ができます。システムを納品後の改善で育てるという考え方は、システムは納品後の改善で育てる｜新規事業の考え方で詳しく書いています。
開発を担った会社が運用も担う利点と注意点
開発を担当した会社がそのまま保守も担当する場合、システムの中身を熟知しているため、原因の調査や改修が進めやすい利点があります。一方で、特定の会社に依存しすぎると、将来の乗り換えが難しくなることがあります。
依存を避けるために、前述の7項目のうち「引き継ぎに関する取り決め」を、契約の最初の段階で確認しておきます。引き継ぎ資料が整っていれば、別の担当者や会社に移すこともできますし、運用を続ける側にも良い緊張感が生まれます。
AIで作られたコードの保守
近年は、AIを活用して開発する会社も増えています。AIが生成したコードでも、保守のために確認したい点は基本的に同じです。ただし、「誰がそのコードの中身を理解し、改修の責任を持つのか」「設計書や仕様の記録が残っているか」は、より丁寧に確かめたいところです。詳しくはAI生成コードの保守は可能か｜引き継ぎと改修の確認点をご覧ください。
契約前に開発会社へ聞いておきたい質問
最後に、保守契約を結ぶ前に、開発会社へ直接聞いておくとよい質問を挙げます。契約書の文面だけでは読み取れない運用の実態が分かります。
- 連絡を受けてから、最初に返答するまでの実際の流れを教えてください
- 夜間や休日に障害が起きた場合、どのように連絡し、どう動いてもらえますか
- 軽微な改修として扱う具体的な例と、別見積もりになる具体的な例を教えてください
- OSやライブラリの更新は、いつ、誰の判断で行いますか
- バックアップからの復元は、実際に試したことがありますか
- 担当者が変わる場合、引き継ぎはどのように行われますか
- 契約を終了するとき、ソースコードや資料はどのように受け取れますか
- 外部サービスが原因の障害では、どこまで相談に乗ってもらえますか
答えを聞く際は、「対応します」という返事だけで終わらせず、具体例や運用の流れまで聞くのがコツです。具体的に答えられる会社ほど、運用の実態が整っていることが多いからです。回答は議事録やメールで残し、契約書に反映してもらうと、後の確認がしやすくなります。
見積もりの金額だけでなく、前提や範囲を比べる姿勢は、保守契約でも同じです。考え方はシステム開発の見積もりの違い｜金額より先に見る前提と範囲で整理しています。外注全体の流れはシステム開発の外注｜メリット・デメリットと失敗しない進め方も合わせて読むと、全体像がつかみやすくなります。
まとめ
システム開発の保守契約で大切なのは、「保守」という言葉の中身を、納品前に具体的に確かめることです。要点を振り返ります。
- 保守は、障害対応、不具合修正、監視・バックアップ、環境の更新、軽微な改修の5つに分けて確認する
- 契約書では、対応範囲と対象外、対応時間、返答の目安、契約期間、責任の範囲、第三者サービスの扱い、引き継ぎの7項目を見る
- 不具合と仕様変更の線引きは、仕様を示す資料と具体例で先に決めておく
- 新規事業では、運用開始後に育てる前提で、改修の枠組みと見直しのタイミングを確認する
- 質問への回答は文書に残し、契約書に反映してもらう
保守契約は、トラブルが起きたときにはじめて真価が分かるものです。だからこそ、契約前の確認に時間をかける価値があります。
JustFitは、納品して終わりではなく、業務に合わせてシステムを育て続ける伴走型の技術支援を行っています。システムの維持や不具合の修正に加え、毎月ひとつの機能追加までを対応する形です。納品後の運用をどう組み立てるかも含めて、新規事業の進め方を考えたい場合は、JustFitのサービス紹介をご覧ください。