システム保守契約に含めるべき内容とSLA

システムが完成すると、開発会社から保守契約の提案を受けるのが一般的です。しかし「月額費用に何が含まれているのか分からない」「障害が起きたとき、どこまで対応してもらえるのか曖昧なまま契約してしまった」という声は少なくありません。保守契約の内容があいまいだと、いざというときに対応が遅れたり、想定外の追加費用が発生したりする原因になります。
この記事では、システム保守契約に含めるべき項目と、サービスの品質水準を取り決めるSLAの考え方、契約前に確認すべきポイントを、発注者目線で整理します。
- 保守契約では「何を」「いつ」「どこまで」対応するかを具体的に書くことが最重要
- SLAは対応時間や復旧目標などの品質水準を数値で約束する取り決めで、中小規模のシステムでも簡易版を作る価値がある
- 月額に含まれる作業と、別途見積もりになる作業の線引きを明確にしておく
- 契約終了時の資料・ソースコードの引き渡し条件も必ず盛り込む
目次
システム保守契約とは?SLAとの関係
システム保守契約とは、稼働中のシステムの不具合修正、障害対応、ソフトウェアの更新などを、開発会社や保守会社に継続的に依頼するための契約のことです。多くの場合、月額または年額の固定費用で契約し、あらかじめ決めた範囲の作業を提供してもらいます。
一方、SLA(Service Level Agreement:サービス品質保証)とは、保守サービスの品質水準を数値で取り決めたものです。「障害の連絡から何時間以内に対応を始めるか」「稼働率を何%以上に保つか」といった目標を定め、守れなかった場合の扱いも含めて合意します。保守契約が「何をしてもらうか」を決めるものだとすれば、SLAは「どの水準でしてもらうか」を決めるものといえます。
保守契約書とSLAの役割分担
保守契約書で決めること
- 対象となるシステムと範囲
- 作業内容と費用
- 契約期間・更新・解約
- 責任範囲と免責
SLAで決めること
- 受付時間と連絡手段
- 初動・復旧の目標時間
- 障害の重要度の定義
- 報告の頻度と内容
保守契約に含めるべき主な項目
保守契約書で最低限定めておきたい項目は次のとおりです。特に「作業範囲」は、後からトラブルになりやすいため具体的に書くことが大切です。
- 対象システム:システム名、対象となるサーバーや機能、関連する外部サービス
- 作業範囲:不具合修正、障害対応、問い合わせ対応、OS・ミドルウェアの更新、バックアップ確認など
- 対応時間:平日日中のみか、夜間・休日も含むか
- 費用と支払条件:月額費用、含まれる作業時間の上限、超過時の単価
- 契約期間と更新・解約:自動更新の有無、解約の申し入れ期限
- 責任範囲:損害賠償の上限、免責となるケース
- 再委託:保守会社がさらに別の会社に作業を任せる場合の条件
- 契約終了時の引き渡し:ソースコード、設計書、アカウント情報などの返却・引き渡し方法
「月額に含まれる作業」と「別途見積もり」の線引き
保守トラブルで最も多いのが、「これは保守の範囲だと思っていた」「それは追加開発です」という認識のずれです。一般的な線引きの例は次のとおりですが、会社によって扱いが異なるため、契約時に個別に確認しましょう。
| 作業 | 月額に含まれることが多い | 別途見積もりになりやすい |
|---|---|---|
| 不具合(バグ)の修正 | 納品時の仕様どおりに動かない箇所 | 仕様そのものの変更 |
| 問い合わせ対応 | 操作方法や不具合の切り分け | データの大量修正の代行 |
| OS・ソフトウェア更新 | セキュリティパッチの適用 | PHPやOSのメジャーバージョンアップ |
| 機能追加・改善 | 月◯時間までの軽微な修正 | 新しい画面や帳票の追加 |
「軽微な修正を月◯時間まで含む」のように、作業時間の上限で範囲を決める方法もよく使われます。この場合、使わなかった時間を翌月に繰り越せるかも確認しておくとよいでしょう。
SLAで取り決める項目と目安
SLAというと大企業向けの仕組みと思われがちですが、中小企業の業務システムでも、障害時の対応目標だけでも決めておくと、いざというときの混乱を防げます。
障害の重要度を定義する
SLAの基本は、障害の重要度(レベル)を決めて、レベルごとに対応目標を設定することです。
| 重要度 | 状態の例 | 初動の目標(目安) |
|---|---|---|
| レベル1(緊急) | システム全体が停止し、業務ができない | 受付から1〜2時間以内 |
| レベル2(重大) | 主要機能の一部が使えないが、代替手段がある | 受付から当日中 |
| レベル3(軽微) | 表示の乱れなど、業務への影響が小さい | 受付から数営業日以内 |
上記は一般的な目安です。24時間365日の対応や短い目標時間を求めるほど、保守費用は高くなります。自社の業務で「何時間止まったら困るか」を先に考え、必要十分な水準を選ぶことが大切です。
その他に決めておきたい項目
SLAを守れなかった場合に保守費用を減額する取り決めは、大規模なサービスでは一般的ですが、中小規模の保守契約では「改善計画の提出」にとどめるケースも多くあります。罰則を厳しくするほど費用に上乗せされる傾向があるため、バランスを考えて決めましょう。
保守契約を結ぶ前のチェックポイント
保守契約は一度結ぶと数年単位で続くことが多いため、契約前に次の点を確認しておきましょう。
- 自社の要望を整理する業務が止まったときの影響、必要な対応時間、社内の窓口担当者を決める
- 作業範囲を具体化する月額に含まれる作業と別途費用の作業を一覧にしてもらう
- 費用の妥当性を確認する年間の保守費は開発費の10〜15%程度が一つの目安。内訳と作業時間の根拠を確認する
- 終了時の条件を確認する解約予告期間、資料・ソースコード・アカウントの引き渡し方法を明記する
関連記事システム保守費用の相場は開発費の何%?内訳と契約形態
契約後の運用で気をつけること
保守契約は結んだら終わりではありません。月次の作業報告で、実際にどのような作業が行われたか、SLAの目標は守られているかを確認しましょう。報告の内容が「特になし」ばかりの場合は、予防的な作業が行われているかを質問してみることも大切です。また、業務の変化やシステムの利用状況に合わせて、年に1回程度は契約内容を見直すと、実態に合わない範囲や費用を放置せずに済みます。
無料テンプレートシステム開発の無料テンプレート集|RFP・要件定義書・見積もり比較表・保守契約チェックリスト
よくある質問
- 保守契約は必ず結ぶ必要がありますか?
- 法的な義務はありませんが、業務で使うシステムであれば結んでおくことをおすすめします。保守契約がないと、障害時に対応を依頼しても順番待ちになったり、その都度割高な費用がかかったりすることがあります。
- 中小企業の業務システムでもSLAは必要ですか?
- 本格的なSLAでなくても、障害の重要度ごとの初動目標と連絡手段だけは決めておくと安心です。対応水準を高くするほど費用も上がるため、業務への影響を踏まえて必要十分な水準を選びましょう。
- 保守費用の相場はどれくらいですか?
- 一般的には、年間で開発費の10〜15%程度が目安とされています。対応時間の長さや、機能改善の作業時間が含まれるかどうかによって上下します。
- 保守会社を途中で変更することはできますか?
- 可能です。ただし、解約予告期間やソースコード・資料の引き渡し条件が契約で定められているかが重要になります。契約時に終了時の取り決めを入れておくと、変更がスムーズに進みます。
まとめ
システム保守契約では、対象範囲、作業内容、対応時間、費用、終了時の引き渡しを具体的に定めることが大切です。SLAは障害時の対応水準を数値で約束するもので、中小規模のシステムでも重要度ごとの初動目標だけでも決めておくと効果があります。「月額に何が含まれるか」を一覧で確認し、発注者と保守会社が同じ認識を持てる契約にしましょう。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る



