TRACERYプロダクトマネージャーの haru です。
システム開発における「保守」とは、稼働中のシステムを安定して利用し続けるために、障害対応、環境変化への適応、軽微な機能改善などを行う継続的な活動を指します。
開発完了後も、システムの品質と有効性を維持し、事業へ貢献し続けるために欠かせない工程です。
本記事では、保守の4つのタイプと、それぞれにおける留意点について解説します。
保守の4つのタイプ
保守には、以下の4つのタイプがあり、国際規格のISO/IEC/IEEE 14764:2022*1 および JIS X 0161:2008*2 によって定義されています。
- 是正保守（corrective maintenance）
- 運用中に発見された不具合や障害を修正する保守
- 予防保守（preventive maintenance）
- 将来的な障害の発生を未然に防ぐため、潜在的な問題を事前に修正する保守
- 適応保守（adaptive maintenance）
- OSやミドルウェアの変更など、利用環境の変化に対応する保守
- 完全化保守（perfective maintenance）
- 性能改善や保守性向上など、機能要件に直接関係しない品質面を改善する保守
- 軽微な機能の改修、改善
保守の4つのタイプを把握しておくことで、保守対応の内容や目的を関係者間で正しく認識できるようになります。
どの作業が契約に含まれるのか、追加費用が発生するのかといった線引きを明確にしやすくなり、不要な誤解やトラブルを防ぐうえでも有効です。
以下に、それぞれの保守のタイプについて説明します。
是正保守
稼働中のシステムにおいて発生した障害や不具合に対応し、正常な状態に戻すための保守活動です。
想定どおりに動作しない、エラーが発生する、業務に支障をきたすといった問題が対象となります。
ユーザーからの報告や監視ツールのアラートを契機に対応が開始され、迅速な復旧が求められるのが特徴です。
また、是正保守の一部として、是正保守実施までシステム運用を確保するための計画外で一時的な修正として『緊急保守』があります*3。
具体例
是正保守の具体例としては、以下のようなものが挙げられます。
- 機能不具合
- 検索機能で正しい結果が出ないロジックミスの修正
- 予約システムで、ダブルブッキングが発生するバグの修正
- インフラ、環境設定不備
- サーバ証明書の設定ミスによりSSL通信が遮断され、通信再開のために設定を修正
- マスターデータ不備、データ不整合
- マスターデータの初期登録漏れにより、データ不整合が発生。マスタデータ投入と不整合データ修正の対応
- 使用ライブラリの脆弱性に起因して障害が発生
- ライブラリのバージョンアップや、影響範囲の調査、データの復旧
- 外部APIの仕様が微細に変更されており、パースに失敗。処理形式を修正
- 外部APIの仕様変更は「外部環境の変化」であり、システム自体に問題があるわけではないので『適応保守』に分類されることが多い
- 外部からの攻撃によりログイン試行が大量に行われたため、アカウントロック機能やIP制限の修正を追加
- 契約時に「一定水準のセキュリティ要件（たとえばブルートフォース攻撃への対策）」が明示されている場合などは瑕疵対応として扱われる可能性がある
留意点
是正保守は、以下の点に留意することで、より効果的に遂行できます。
- 障害の緊急度に応じた優先順位付け
- すべての障害に即時対応するのではなく、業務インパクトの大きさやユーザー影響を考慮して対応優先度を設定する
- 根本原因の究明と再発防止策の徹底
- 表面的な修正で済ませるのではなく、発生原因を特定し、同様の不具合が起きないように設計や運用プロセスの見直しを行う
- 修正による副作用リスクの管理
- 既存システムに手を加えるため、他機能への影響がないかを確認するためのテスト計画やレビューが不可欠
- ナレッジの蓄積と共有
- 対応履歴や原因分析をナレッジとして蓄積することで、チーム内の対応力向上や、類似障害への迅速な対応につながる
是正保守と瑕疵対応の違いを理解しておく重要性
システム開発を外部ベンダーに発注する際は、納品後に不具合が見つかった場合の対応について、「瑕疵対応」と「是正保守」の違いを明確にしておく必要があります。
瑕疵対応（不具合修正）とは、納品されたシステムが契約や仕様に適合していない場合に、ベンダーが無償で修正を行う対応を指します。
納品された成果物が契約書や仕様書で定められた内容に適合しておらず、品質・性能・機能などに欠陥がある状態を「契約不適合」といいます。
一方の是正保守も、不具合の修正を行うという点では共通していますが、こちらは保守契約に基づいて実施される有償の対応です。
不具合の原因が契約不適合に該当しない場合、たとえば環境の変化によって発生した不具合などは、是正保守の対象とされることがあります。
つまり、作業内容は同じであっても、「無償対応か有償対応か」「瑕疵と見なされるかどうか」によって、費用負担や対応範囲が大きく異なってきます。
下表に、保守契約がある場合における是正保守と瑕疵対応の違いをまとめました。
| 区分 | 契約上の扱い | 費用負担 | 説明 |
|---|---|---|---|
| 是正保守 | 保守契約の範囲 | 発注側が負担（有償） | 1. 契約不適合に該当しない不具合 2. 保証期間外に発見された不具合 |
| 瑕疵対応 | 品質保証（契約不適合責任）の範囲 | 開発側が負担（無償） | 仕様書・契約に合致していない不具合を保証期間内に修正 |
これらの違いを認識せずに契約を締結してしまうと、納品後のトラブル対応において認識の齟齬が生じ、追加費用をめぐる争いに発展する可能性があります。したがって、契約時点で瑕疵対応の条件、保証期間、是正保守の対象範囲などを明記しておくことが極めて重要です。
コラム：瑕疵担保責任から契約不適合責任への民法改正
2020年4月の民法改正により、請負契約における「瑕疵担保責任」は「契約不適合責任」へと名称が変更され、あわせて制度の内容も大きく見直されました。
改正前は、成果物に瑕疵（＝契約内容と異なる欠陥）があった場合、原則として引渡し後1年以内であれば、発注者は修正を請求できました。この1年間の請求可能期間は「瑕疵期間」と呼ばれ、契約において特約がなければその期間を過ぎると請求は認められませんでした。
しかし改正後は、「契約内容に適合しない部分（契約不適合）」を発注者が認識してから1年以内または引き渡しから10年以内に通知すれば、修正などの請求が可能とされました（民法第637条、第566条、第166条）。これにより、形式的な瑕疵期間ではなく、実際に問題に気づいた時点を起点とする柔軟な制度へと変更されています。
なお、民法改正前に締結された契約については、引き続き旧制度が適用されます。この場合は、定められた瑕疵期間内でのみ無償対応の義務があり、それを過ぎた場合の対応は原則として有償となります。
2020年4月の改正は、発注者が瑕疵に気づいた時点からの起算を可能にしたことで、請求の実効性が高まり、より実態に即した保護が図られるようになった点が大きな特徴です。
外部要因による不具合：瑕疵に該当するかの判断ポイント
システム稼働後、外部環境の変化を原因とする不具合が発生することがあります。このようなケースでは、必ずしも開発側に責任があるとは限らず、「契約不適合（瑕疵）」に当たるかどうかは、契約内容や設計方針によって判断が分かれます。
以下に、典型的なケースごとの判断ポイントを示します。
1. 使用ライブラリの脆弱性による障害
瑕疵に該当しないケース
- 開発時点では脆弱性が公表されていなかった。
- ライブラリの選定が一般的に妥当（例：業界標準や積極的に保守されているOSS）だった。
瑕疵に該当する可能性があるケース
- 開発時点ですでに脆弱性が公開されていた。
- 契約や仕様書に「OWASP Top10対応」「セキュリティパッチ適用済みライブラリの使用」など、具体的なセキュリティ要件が記載されていた。
- 明らかに避けるべきライブラリ（既に開発終了、または危険視されていた）を使用していた。
2. 外部APIの仕様変更によりパースが失敗
- 瑕疵に該当しないケース
- 契約時点のAPI仕様に基づいて実装されており、納品時点では正常に動作していた。
- 瑕疵に該当する可能性があるケース
- APIの仕様変更が想定されていたにもかかわらず、それに対応可能な柔軟な設計がなされていなかった。
3. 外部からの攻撃によりセキュリティ機能の強化が必要となった
瑕疵に該当しないケース
- セキュリティ要件が契約に明記されておらず、開発側が一般的な対策を講じていた。
- アカウントロックやIP制限の仕様が契約範囲に含まれていなかった。
- 攻撃が通常の想定を大きく上回る高度または大規模なものであった。
瑕疵に該当する可能性があるケース
- 契約時に「ブルートフォース攻撃への対策」など、具体的なセキュリティ要件が明示されていたにもかかわらず、それが実装されていなかった。
このような判断は、瑕疵対応の可否や保守契約の範囲、追加費用の有無に直結します。
あいまいな判断はトラブルの元になりやすいため、契約段階でセキュリティ要件や外部依存の扱いについて明記しておくことが重要です。
予防保守
予防保守とは、システムが故障や障害を起こす前に、それらの発生を未然に防ぐことを目的とした保守活動です。
過去の障害履歴や、ハードウェア／ソフトウェアの老朽化、環境の変化などを踏まえて、あらかじめ点検・更新・設定変更などを行うことで、システムの安定稼働を維持します。
これは、「問題が起きたら対応する」是正保守とは対照的に、「問題が起きないように手を打つ」予測的・計画的な保守アプローチです。
具体例
予防保守の具体例としては、以下のようなものが挙げられます。
- セキュリティパッチの適用
- ミドルウェアやライブラリのバージョンアップ
- 定期的なログ容量やディスク空き容量の監視・清掃
- バッチ処理の性能劣化に備えた処理ロジックの見直し
- 外部連携先の仕様変更を見越した調査・試験
留意点
予防保守は、以下の点に留意することで、より効果的に遂行できます。
- 費用対効果の見極め
- 予防保守は将来の障害防止を目的とするが、実際に「障害が起きなかった」ことの効果は目に見えにくく、発注側にとっては投資対効果が不透明になりがちである。そのため、予防保守の目的とリスク低減の根拠（過去の障害事例や老朽化状況など）を明確に説明する
- 過剰な対応の回避
- すべての要素に対して予防保守を行うと、費用と工数が膨らむ。業務への影響度・発生頻度・対応難易度などの観点で優先順位をつけることが必要
- 対応範囲とタイミングの合意
- 予防保守は計画的な対応であるため、「いつ」「どこまで」「どういった作業を」行うかを事前に関係者と合意しておくことで、トラブルを防止する
- 作業による副作用の管理
- 予防保守でも、システムへの変更や再起動が伴う作業がある。テスト計画、バックアップ、影響範囲の事前確認など、副作用を最小限に抑える準備をする
- ナレッジの蓄積と共有
- 予防保守で実施した作業は、設定変更履歴や対応理由、結果の記録を残すことで、次回以降の判断や後任者の対応に役立つ
適応保守
適応保守とは、システムの稼働環境や外部条件の変化に対応するために行う保守活動です。
具体例
具体例としては、以下のようなものが挙げられます。
- OSのバージョンアップに伴うシステム改修
- 法令対応（インボイス制度、電子帳簿保存法など）に対応した帳票出力仕様の変更
- 他システムのAPI仕様変更に伴う接続方式の更新
- クラウド移行やホスティングサービスの終了に伴う構成変更
- 社内ポリシーの変更（パスワード要件、ログ保持期間など）への対応
留意点
適応保守は、以下の点に留意することで、より効果的に遂行できます。
- 対応の必要性を丁寧に説明する
- 「現状問題なく動いているシステム」に手を入れることになるため、発注者が重要性を見落としやすい傾向がある。「対応しないと将来的に使えなくなる」「環境変化が業務に影響を及ぼす」というリスクを具体的に示す。
- 外部依存の変化を早期に検知する体制の整備
- APIや法制度のように、外部要因による変化は突発的に発生するため、情報収集や変更通知を受け取る仕組みを整備しておくことが求められる
- 対応範囲と影響の見極め
- 環境の一部が変わるだけでも、他の機能や設定に影響する場合がある。影響分析を丁寧に行い、テスト計画を立てることが不可欠
- 長期的な運用を見据えた対応
- OSや外部サービスのバージョンアップなどは、一度対応して終わりではなく、継続的なメンテナンスが必要となる可能性がある。将来的な対応工数や保守計画に組み込む。
完全化保守
完全化保守とは、稼働中のシステムに対して、機能の追加や改善を通じて性能や使い勝手を向上させる保守活動を指します。
現時点で致命的な不具合があるわけではないが、ユーザーの要望への対応や業務上の利便性向上のために、機能を調整します。
一般的に完全化保守で対象となるのは、既存機能に対する軽微な改善に限られます。
具体例
完全化保守の具体例としては、以下のようなものが挙げられます。
- 検索画面にフィルタ機能や並び替え機能を追加
- 入力フォームの入力補助（オートコンプリートや入力チェック）を追加
- 既存帳票に新たな項目を追加
- エラーメッセージの表現をわかりやすく改善
- 該当機能に対するヘルプの追加
留意点
完全化保守は、以下の点に留意することで、より効果的に遂行できます。
- 「どの程度の改修までを保守で対応するか」という基準を契約や運用ルールとして明確にしておく
- 契約や運用ルールの例
- 「月○時間までは保守対応、それを超える要望は追加開発扱い」
- 「画面単位での軽微な調整は保守、それ以外は個別見積」
- 「業務フローが変わるような機能改修は原則追加開発扱い」
- 契約や運用ルールの例
- 改善が他機能に及ぼす影響の管理
- 些細な改善であっても、既存機能との整合性や副作用を十分に確認する。回帰テストやレビューを怠らないことが重要で、そのためのコストを見積もる。
まとめ
システム保守は、安定運用のために欠かせない活動ですが、その範囲や定義を曖昧にしたまま契約すると、後々のトラブルにつながります。
特に「完全化保守」と「追加開発」の線引きは認識のズレが起きやすいため、分類の理解を前提としつつ、具体的な合意項目を契約書に明文化しておくことが、健全な関係構築の鍵となります。
