システムは、納品されたら終わりではない。本番で動かし続けるためには、不具合への対応、環境の変化への追従、問い合わせへの対応といった保守・運用が必要になる。ところが開発契約に注目が集まる一方で、保守・運用契約は内容を十分確認しないまま結ばれがちである。その結果、いざ障害が起きたときに「これは保守の範囲なのか」「すぐ対応してもらえるのか」で認識がずれることがある。
本記事は、開発後に必要となる保守・運用契約の読み方を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門の担当者である。保守契約は専門用語が多く読みにくいが、押さえるべき観点はそれほど多くない。なお、契約条項の解釈に迷う点があれば、弁護士などの専門家への確認を前提に進めてほしい。本記事は一般的な確認観点の整理にとどまる。
結論:範囲・水準・費用の3点を具体的に確認する
保守・運用契約を読むうえで、発注前に確認しておきたいのは次の3点である。
- 保守の範囲(何が含まれ、何が含まれないか)を具体的に把握する
- 対応の水準(応答や復旧の目安、対応時間帯)を確認する
- 費用の前提(月額に含まれる範囲と、追加費用が発生する条件)を把握する
「保守をお願いします」という曖昧な合意ではなく、何にいくら払い、どこまで対応してもらえるかを具体化しておくことが、後の認識のずれを防ぐ。
保守・運用の範囲を確認する
まず確認したいのは、その契約で「何をしてもらえるのか」である。保守と一口に言っても、含まれる範囲は契約によって幅がある。
| 区分 | 含まれることが多い例 | 確認したい点 |
|---|---|---|
| 障害対応 | 不具合の調査・修正 | 原因が委託先側か否かで扱いが変わるか |
| 問い合わせ対応 | 操作方法などの質問対応 | 対応の件数・時間に上限があるか |
| 軽微な変更 | 設定変更など小規模な修正 | どこまでが軽微の範囲か |
| 機能追加・改修 | 新しい機能の開発 | 保守の範囲外で別契約か |
| 環境への追従 | OSやライブラリの更新対応 | 含まれるか、別費用か |
とくに区別が曖昧になりやすいのが、「障害対応」と「機能追加・改修」である。既存機能の不具合修正は保守に含まれても、新しい機能の追加は別契約、という整理が一般的である。どこからが保守の範囲外になるかを、発注前に確認しておきたい。改修の規模感はシステム入れ替えの費用も参考になる。
SLA(サービス水準)の読み方
保守契約には、対応の水準を定めた取り決め(SLAと呼ばれることがある)が含まれることがある。これは「どのくらいの早さで、どこまで対応するか」の約束である。
応答と復旧の目安
問い合わせや障害連絡に対し、いつまでに一次応答するか、復旧の目安をどう置くかを確認する。ただし「復旧を保証する」のか「復旧に向けて対応する」のかは意味が異なるため、表現を確認しておきたい。復旧時間を確約する形は委託先にとって負担が大きく、現実には「目安」として示されることも多い。
対応の時間帯
平日の日中のみか、夜間・休日も対応するかを確認する。自社の業務がいつ動いているかと照らして、必要な時間帯がカバーされているかを見ておきたい。24時間対応は安心だが、その分費用も上がるため、業務上の必要性とのバランスで考える。
緊急度の区分
障害の緊急度をどう区分し、それぞれにどの水準で対応するかが定められていると、優先順位が明確になる。すべてを最優先で扱うのは現実的でないため、業務への影響度で区分する考え方が一般的である。
費用の前提を確認する
保守費用は、月額(または年額)で設定されることが多いが、その金額に何が含まれるかは契約により異なる。
- 基本料金に含まれる範囲:障害対応・問い合わせ対応など、定額でどこまでカバーされるか
- 追加費用が発生する条件:機能追加、対応時間外の緊急対応、大規模な調査など
- 作業量の上限:問い合わせ件数や作業時間に上限があるか、超えた分はどう扱うか
- 費用の見直し:契約更新時に費用が見直される条件があるか
「月額いくら」だけを見て安心せず、その金額で何ができ、何が追加になるかまで確認しておきたい。とくに機能追加や大きな改修は別費用になることが多いため、ランニングコストを見積もるときは、保守費用と別に改修の費用も想定しておくと現実的である。
引き継ぎ・乗り換えへの備え
保守を委託する際、見落とされがちなのが「将来、別の会社に乗り換えられるか」である。保守契約に過度に縛られると、不満があっても乗り換えにくくなる。
| 観点 | 確認したいこと |
|---|---|
| ドキュメント | 運用・保守に必要な資料が整っているか |
| ソースコード | 必要な権利とともに引き渡しを受けられるか |
| 環境・アカウント | 運用環境への移行が可能か |
| 解約条件 | 解約の予告期間や手続きが過度でないか |
これらが整理されていれば、保守先を見直したいときにも選択肢が残る。乗り換えのしやすさは、現在の保守先との健全な関係を保つうえでも意味がある。成果物に関わる権利は著作権・知的財産の扱いも確認しておきたい。
開発契約と保守契約のつなぎ目
見落とされやすいのが、開発契約と保守契約の「つなぎ目」である。納品直後の不具合が、開発の契約不適合の対応なのか、保守契約での対応なのかが曖昧だと、責任の押し付け合いになりやすい。
- 保証期間と保守の関係:納品後の一定期間、開発側が無償で対応する取り決め(契約不適合への対応など)と、保守契約の範囲がどう切り分けられているか
- 保守の開始時点:保守契約はいつから始まるのか、納品から保守開始までに空白がないか
- 同じ会社か別の会社か:開発と保守を別の会社が担う場合、不具合の原因の切り分けで対立しないか
理想は、納品後の保証と保守の範囲がきれいにつながり、間に空白がない状態である。開発と保守を別の会社に頼む場合は、とくに切り分けが曖昧になりやすいため、どこまでが開発側の責任で、どこからが保守の範囲かを発注前に整理しておきたい。納品時の検収・保証の考え方は検収・契約不適合の扱いで詳しく扱う。
発注前に整理しておきたいこと
保守・運用契約を結ぶ前に、自社で整理しておくとよい点をまとめる。
| 整理する項目 | 確認の観点 |
|---|---|
| 業務の稼働時間 | システムがいつ使われ、止まると困る時間帯はいつか |
| 求める対応の早さ | 障害時にどのくらいの早さで対応してほしいか |
| 社内の運用体制 | 一次対応を担える担当が社内にいるか |
| 想定する改修 | 今後どの程度の機能追加・改修を見込むか |
| 予算の目安 | 月額の保守費用にかけられる目安 |
これらが整理されていると、過剰でも不足でもない保守の水準を選びやすい。たとえば、夜間に止まっても翌朝の対応で支障がない業務に、24時間対応の高い水準を契約するのは過剰かもしれない。逆に、止まると即座に売上に響く業務なら、相応の水準が必要になる。自社の業務とのバランスで考えることが、納得できる保守契約につながる。
保守契約でありがちな認識のずれ
保守契約は、結んだあとに「思っていたのと違った」となりやすい領域でもある。よくある認識のずれを知っておくと、契約前の確認の精度が上がる。
- 何でも直してもらえると思っていた:新しい機能の追加まで保守に含まれると思い込み、別費用と知って驚く
- すぐ来てもらえると思っていた:対応の時間帯や応答の目安を確認しておらず、急ぎの対応が受けられない
- 費用は固定だと思っていた:問い合わせ件数や作業時間の上限を見落とし、超過分の請求に戸惑う
- ずっと同じ会社が見てくれると思っていた:乗り換えの備えがなく、不満があっても動けない
これらのずれは、いずれも契約の確認不足から生じる。保守契約は地味で読み飛ばされがちだが、「含まれること」と「含まれないこと」、そして「追加費用が発生する条件」を一通り確認しておくだけで、多くのずれを防げる。不明な点は、結ぶ前に委託先に質問し、回答を記録に残しておきたい。
委託先に確認したい質問
保守・運用契約を結ぶ前に、委託先に投げかけておくとよい質問を整理する。
| 質問 | 確認したいこと |
|---|---|
| 何が保守に含まれ、何が別費用ですか | 範囲の切り分け |
| 障害連絡からどのくらいで対応しますか | 応答・対応の目安 |
| 対応の時間帯はいつですか | カバーされる時間帯 |
| 問い合わせや作業に上限はありますか | 追加費用の条件 |
| 将来、保守を別の会社に移せますか | 乗り換えの可否 |
「すべて対応します」という説明には、含まれる範囲と別費用の境目を必ず確認しておきたい。安心できる言葉ほど、具体的な範囲を確かめておくことが、後の認識のずれを防ぐ。質問への回答が曖昧な場合は、その点こそ契約で明確にしておきたい論点である。
なお、保守契約は一度結んだら終わりではなく、システムの使われ方が変われば、必要な保守の水準も変わる。たとえば利用者が増えたり、扱うデータが重要になったりすれば、求める対応の早さも上がる。契約の更新の節目に、いまの保守の水準が業務の実態に合っているかを見直す習慣を持っておくと、過不足のない保守を保ちやすい。見直しのタイミングや費用の変動の条件も、最初の契約で確認しておきたい。
よくある質問
Q1. 保守契約は必ず開発した会社と結ぶ必要がありますか
開発した会社が保守も担うことが多いが、必須ではない。ただし、別の会社に保守を頼むには、ソースコードや設計書、必要な権利が引き渡されていることが前提になる。これらが整理されていれば、保守先を選ぶ余地が広がる。
Q2. SLAで復旧時間は保証してもらえますか
「保証」と「目安」は意味が異なる。復旧時間の確約は委託先の負担が大きく、現実には目安として示されることも多い。表現を確認し、自社の業務に必要な水準と照らして判断したい。解釈に迷う場合は専門家への確認を前提にしてほしい。
Q3. 月額の保守費用に機能追加は含まれますか
一般には、既存機能の不具合対応は保守に含まれても、新しい機能の追加は別費用になることが多い。どこまでが定額の範囲で、どこから追加費用かを発注前に確認しておくと、後の認識のずれを防げる。
保守・運用契約の範囲と費用を、契約前に整理しませんか
GXOでは、システムの保守・運用契約について、対応範囲、サービス水準、費用の前提、将来の乗り換えへの備えといった観点を、発注者の立場で整理するご支援を行います。納品後のランニングまで見据えて確認できます。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
