保守
保守とは、稼働開始時に正常だった機能が何らかの原因で働かなくなったり（機能停止）、働いてはいてもパフォーマンスが低下（機能低下）した場合に、その機能を正常な状態に戻すために行う業務のことです。
システムの場合は全ての構成要素が保守の対象になります。
例えば、ハードウェアについては部品の故障への対応が保守として考えられ、ソフトウェアでは利用開始当初に気付かなかった不具合を修正する場合も保守の対象になります。
データベースについても不要なデータの除去や、データ配置状況の改善のために保守が必要とされます。
保守を行わずに安定したシステムの運用は不可能であり、「保守は避けられないもの」という意識が重要です。
保守作業を自社で行うことができない場合、外部企業に保守業務を委託することになります。
その際、委託方法としては「定期保守」と「スポット保守」があり、一般的に年次費用または月次費用を支払う「定期保守契約」を締結して発注先に対応を依頼します。
定期保守の場合は異常の際の対応だけではなく、異常の有無やその兆候を定期的にチェックする診断や、その診断をもとにした予防保守が行われることもあります。
一方、保守契約を結んでいない場合は、「スポット保守」として異常が発生したタイミングごとに保守作業を依頼することになります。
「スポット保守」の場合、異常の発生が少なければ費用を抑えることができますが、適切なタイミングで保守されず、業務が停止してしまう危険性もあります。
契約時に注意しなければいけないのは、開発したシステムが複数の要素で構成され、それぞれの担当の会社が違う場合（いわゆるマルチベンダ）です。
この場合は、責任の範囲を明確にして、保守の遂行に支障がないようにしなければなりません。全体を取りまとめる企業に一括して保守を委託する場合もあります。
なお、保守を受けた際には「保守報告書」が重要です。
この保守報告書には、保守の内容とともに、対応履歴、対応作業時間、将来の異常発生の可能性、改善提案等が記載されます。
それにより、発注者側は保守契約の見直し、システムの改善計画の検討が可能になります。
目次
よくある質問
保守契約の範囲を定める際、発注者が特に注意すべきポイントは何でしょうか？
保守契約の範囲を明確に定めないと、障害対応や改善作業において「契約内か追加費用か」の判断が曖昧となり、発注者が不利益を被る可能性があります。
発注者は、対象範囲・対応内容・責任分担を契約段階で具体的に定義することが重要です。
注意すべき主なポイント
1. 対象範囲の明確化
・対象となるシステムやモジュール、機能を明確に列挙する。
・ハードウェア・ネットワーク・クラウド基盤が含まれるかどうかを確認する。
2. 作業区分の定義
・障害復旧（是正保守）、法改正対応（適応保守）、改善・機能追加（改善保守）の線引きを契約に明記する。
・改修や追加開発が必要となった場合において、保守契約の中で実施するのか、または別途改修費用が必要となるのかについて、対応内容に応じた判断基準を明確にすることが重要です。
3. 対応レベルとSLA（サービス水準）
・障害発生時の対応時間・復旧時間（例：稼働率99.9％、重大障害は4時間以内に復旧）を数値で定義する。
・対応窓口の受付時間・休日対応の有無も明確化する。
4. 責任分担の整理
・複数ベンダーが関与する場合、障害切り分けや対応責任をどこまで担うかを契約に記載する。
・発注者側の役割（利用者からの一次受付や運用ルール策定）も明示する。
5. 契約外対応の取り扱い
・契約外作業が発生した場合の費用算定方法や合意手続きをあらかじめ定めておく。
保守契約のポイントは、「対象範囲」「作業区分」「サービス水準」「責任分担」「契約外対応」を明文化することです。
曖昧さを残さないことで、発注者は予期せぬ追加コストやトラブルを防ぎ、安定したシステム運用を実現できます。
ベンダーに保守を任せきりにした場合、発注者にはどのような問題が起こり得るでしょうか？
ベンダーに保守を任せきりにすると、発注者自身がシステムの状況を把握できなくなり、依存度が高まります。
その結果、コストや品質の面で不利益を被るリスクがあり、将来的なシステム刷新や改善の選択肢も狭まります。
主な問題点
1. 知識・ノウハウの喪失
・障害対応や改修の経緯が発注者側に蓄積されず、システム全体を把握できなくなる。
・担当者交代時に業務継承が難しくなる。
2. コスト管理の不透明化
・ベンダーが提示する追加費用や契約外対応の妥当性を判断できず、費用が膨らむ恐れがある。
・発注者が主体的に管理できないため、長期的なコスト最適化が困難になる。
3. 品質・対応力の低下
・報告内容を鵜呑みにせざるを得ず、復旧の遅延や対応不十分があっても気づきにくい。
・結果としてシステム利用部門の業務に影響が及ぶ。
4. ベンダーロックインの加速
・特定ベンダーに依存し、他社への切替や段階的刷新が極めて難しくなる。
・調達や契約更新時に発注者が不利な立場に置かれる可能性が高まる。
5. 説明責任の欠如
・発注者がシステム状況を把握していないと、監査対応や利用部門への説明ができず、信頼を損なう。
保守をベンダー任せにすると、「依存によるコントロール喪失」が最大の問題となります。
発注者は最低限の知識や情報を把握し、コスト・品質・契約面で主体的に判断できる体制を維持することが望まれます。
複数ベンダーが関与するシステムの保守を行う際、発注者が考慮すべき体制やルールは何でしょうか？
複数ベンダーが関与する場合、障害対応や改善作業の責任分担が不明確になりやすいため、発注者が全体統制を担う体制と共通ルールを整備することが重要です。
特に「責任の明確化」「情報共有」「調整プロセス」の3点を意識する必要があります。
主な考慮ポイント
1. 責任範囲と役割分担の明確化
・ベンダーごとに対象範囲（アプリ、インフラ、ネットワークなど）を契約に明記する。
・障害発生時の一次対応・切り分け責任をどこが担うかを定義しておく。
2. 共通ルール・基準の設定
・障害の分類基準（軽微・重大）、報告フォーマット、対応時間を統一する。
・各ベンダーが異なる基準で報告することを防ぎ、比較可能性を高める。
3. 情報共有の仕組み
・チケット管理システムや共有ポータルを用い、障害・改修情報を一元管理する。
・発注者・ベンダー間でリアルタイムに情報を共有できる体制を構築する。
4. 調整プロセスの整備
・ベンダー間で責任の押し付け合いが起きないよう、発注者が調整役を担う。
・定例会議や合同レビューを設け、課題や改善策を共有する場を持つ。
5. 監査・評価の仕組み
・各ベンダーの対応状況を定期的に評価し、SLA（サービス水準）の遵守を確認する。
・発注者自身が品質・コストを統制できる仕組みを備える。
複数ベンダー体制での保守では、「責任範囲の明確化」「共通ルール整備」「情報共有と調整」が成功の鍵です。
発注者は全体統制者としてルールを定め、システム全体の安定稼働を確保することが望まれます。
法改正などに伴うシステム改修は、どこまでを保守業務に含め、どこからを追加開発・更改として扱うのが望ましいでしょうか？
法改正対応の改修は「システムを現状の環境で安定稼働させるために必要な最小限の対応」であれば保守業務に含まれるのが一般的です。
一方、業務プロセス全体の見直しや大規模な機能追加を伴う場合は、追加開発・更改として扱うのが望ましいといえます。
境界が曖昧になりやすいため、契約段階で基準を定めておくことが重要です。
判断基準の例
1. 保守業務に含まれるケース
・法改正により帳票様式の一部を修正する場合
・税率や計算ロジックの改定に伴う軽微な修正
・表示項目や入力項目の追加・削除など、既存機能の範囲内での対応
2. 追加開発・更改に該当するケース
・法改正を契機に新たな業務プロセスを導入する場合
・複数モジュールに跨る大規模な改修が必要な場合
・他システムとの新規連携や新機能追加を伴う場合
3. 契約での工夫
・「〇人日以内は保守、それ以上は追加開発扱い」など規模基準を明記する
・「法改正に伴う軽微な対応は保守範囲に含む」といった具体例を示す
・境界領域での判断方法や費用算定ルールを契約条件に盛り込む
法改正対応は 「既存機能の延長線上での改修」＝保守、
「新機能追加や大規模な再設計」＝追加開発・更改 と整理するのが望ましいです。
発注者は曖昧さを残さず、契約時に線引きを明示しておくことが重要です。
あわせてこの用語と記事をチェック
・運用とは
この記事の編集者
武田 祥太郎
大学時代法学部で労働基準法の研究を進める中で日本の労働生産に課題を感じ、ITによる企業体質の健全化を目指して（株）グローバル・パートナーズ・テクノロジーに新卒入社。 民間企業のITガバナンス、マネジメント支援業務に従事し、同社のナレッジ活用知見を活かしてIT調達ナビで記事の展開にも携わる。
