保守開発を外部に委託しようと検討するとき、最初の関門になるのが「保守開発のサービスには、具体的にどんな機能や対応範囲が含まれるのか」という整理です。保守開発は、システムをただ眺めて監視する運用とは違い、バグ修正・障害対応・機能改修・セキュリティ更新といった「変更を加える非定型業務」が中心になります。ここを曖昧にしたまま契約すると、いざ障害が起きたときに「その対応はメニュー外です」と言われ、想定外の追加費用に直面しかねません。だからこそ、保守開発が提供する機能・役割を体系的に押さえることが、契約前の必須作業になります。
本記事は、保守開発サービスが提供する機能・役割を、是正保守（バグ修正・障害対応）・予防保守（セキュリティ更新・劣化対策）・適応保守（改修・影響調査）・SLA運用メニューという4つの軸で体系的に解説する「機能特化」の記事です。さらに、ドキュメントが残っていないシステムを引き継ぐためのリバースエンジニアリングや、保守契約の形態ごとの対応範囲の違いまで、保守開発の実務に即して具体的に整理します。読み終えるころには、自社が保守契約で何を確保すべきかの「機能チェックリスト」が頭の中に描けるはずです。なお、保守開発の全体像をまだ把握していない方は、まず保守開発の完全ガイドから読むことをおすすめします。
是正保守の機能（バグ修正・障害対応）
是正保守とは、システムに発生した不具合や障害を「直す」機能のことです。保守開発の中でもっとも分かりやすく、かつ緊急性が高い領域で、システムが止まったり誤動作したりしたときに、原因を特定して修正し、正常な状態に戻すまでを担います。運用が「異常を見つけて知らせる」役割だとすれば、是正保守は「異常をコードに手を入れて直す」役割を担う、という違いがあります。
バグ修正と原因特定の機能
バグ修正は、是正保守の中核です。リリース後に発覚した不具合や、特定の操作でのみ起きるエラーを、再現・原因特定・修正・テスト・反映という流れで処理します。ここで重要なのは、単に表面的な症状を抑えるのではなく、根本原因を突き止めて直すことです。応急処置だけで済ませると、同じバグが形を変えて再発し、かえって保守工数が増えてしまいます。保守開発の機能としてバグ修正を評価するときは、「再発を防ぐ恒久対策まで含むか」を確認すべきです。
原因特定の力量は、ベンダーの技術力がもっとも表れる部分でもあります。とくに他社が作ったシステムを引き継いだ場合、コードの全体像を把握していなければ、バグの原因にたどり着くのに時間がかかります。ドキュメントが残っていないシステムでは、後述するリバースエンジニアリングの能力が、バグ修正のスピードと精度を左右します。是正保守の機能を契約に盛り込む際は、「どの程度の調査・原因特定まで対応範囲に含まれるか」を明確にしておくことが、後のトラブルを防ぎます。
障害対応と緊急復旧の機能
障害対応は、システムが停止したり重大な不具合に陥ったりしたときに、できるだけ早く正常稼働へ戻す機能です。ここで決定的に重要になるのが、「いつ、どれだけ速く対応してもらえるか」という時間軸です。平日の日中だけ対応するのか、24時間365日対応するのか、障害発生から何時間以内に復旧に着手するのか。これらは保守契約のSLA（サービス品質保証）として明記されていなければ、いざというときに「その時間帯は対応外」と断られてしまいます。
障害対応の機能を評価するときは、復旧時間の目標値（たとえば「重大障害は4時間以内に復旧着手」など）と、対応時間帯（営業時間内か、夜間休日を含むか）の二つを必ず確認します。24時間対応や即時対応を求めるほど保守費用は上がりますが、システムが止まると事業が止まる業態であれば、その投資は正当化されます。逆に、夜間に止まっても翌営業日対応で問題ない業態であれば、対応時間帯を絞って費用を抑えるという判断も合理的です。障害対応は「速さ」と「費用」のトレードオフを、自社の事業特性に照らして設計する機能だと言えます。
予防保守の機能（セキュリティ更新・劣化対策）
予防保守とは、障害が起きてから直すのではなく、障害を未然に防ぐために手を打つ機能です。是正保守が「事後対応」であるのに対し、予防保守は「事前対策」にあたります。地味で効果が見えにくい領域ですが、ここを怠ると、ある日突然システムが動かなくなったり、セキュリティ事故に発展したりするため、保守開発の中で最も重要度が見落とされがちな機能でもあります。
セキュリティ更新とパッチ適用の機能
セキュリティ更新は、予防保守の最重要機能です。システムが利用しているOS、ミドルウェア、フレームワーク、ライブラリには、日々新しい脆弱性が発見されます。これらを放置すると、攻撃者に悪用され、情報漏えいやサービス停止といった重大事故につながります。保守開発では、こうした脆弱性情報を継続的に監視し、影響のあるものについてセキュリティパッチを適用したり、バージョンを更新したりして、システムを安全な状態に保ちます。
注意すべきは、パッチ適用やバージョン更新が「ただ当てればよい」ものではない点です。ライブラリを更新したことで既存機能が動かなくなる、という副作用は珍しくありません。だからこそ、セキュリティ更新には、更新が他の機能に与える影響を事前に調べる「影響調査」と、更新後に問題が起きていないかを確認する「テスト」がセットで必要になります。セキュリティ更新の機能を契約に含める際は、「脆弱性の監視」「パッチ適用の判断」「適用後の動作確認」までを一連の対応範囲として明確にしておくことが大切です。
劣化対策と稼働監視の機能
予防保守のもう一つの柱が、システムの劣化対策です。長期間稼働するシステムは、データ量の増加によって処理が遅くなったり、ログやキャッシュがたまってディスクを圧迫したり、依存している外部サービスの仕様変更で一部機能が使えなくなったりします。こうした「徐々に進む劣化」を定期的に点検し、性能が落ちる前に手を打つのが劣化対策の機能です。稼働状況を継続的に監視し、異常の兆候を早期に捉えることも、ここに含まれます。
劣化対策は、是正保守(事後の修理)と密接に関わります。予防保守で劣化の兆候を早期に発見できれば、本格的な障害になる前に小さな改修で済ませられ、結果として是正保守の緊急対応コストを抑えられます。つまり、予防保守への投資は、長期的に見れば是正保守の負担を減らす「保険」として機能します。保守開発の機能を設計するときは、是正保守だけに目を奪われず、予防保守をどこまで含めるかを意識的に判断することが、トータルの保守コストと安定稼働の両立につながります。
適応保守の機能（改修・影響調査・ドキュメント整備）
適応保守とは、外部環境やビジネス要件の変化にシステムを合わせて「変える」機能です。法改正への対応、事業の拡大に伴う機能追加、利用しているクラウドサービスの仕様変更への追従など、システムを取り巻く環境は常に変化します。この変化にシステムを適応させ続けるのが適応保守であり、ここに「開発を伴う保守」という保守開発の本質がもっとも色濃く表れます。
機能改修と影響調査の機能
機能改修は、既存システムに新しい機能を加えたり、既存の機能を変更したりする作業です。新規開発と異なるのは、すでに動いているシステムに手を入れる点で、「ある機能を変えたら、別の機能が壊れた」というリスクが常に伴います。だからこそ、改修の前段として欠かせないのが影響調査です。変更しようとしている箇所が、システムの他のどの部分とつながっているかを調べ、改修による波及範囲を見極めてから手を入れます。
この影響調査の精度が、改修の安全性を決めます。影響範囲を見誤ったまま改修を進めると、予期しない箇所で障害が発生し、是正保守の緊急対応に追われることになります。とくに大規模で複雑なシステムや、長年改修を重ねてきたシステムでは、影響調査に相応の工数がかかります。適応保守の機能を契約に含める際は、改修そのものだけでなく、その前提となる影響調査が対応範囲に含まれるかを確認しておくことが、安全な改修の前提になります。改修要件をどう整理しベンダーに伝えるかは、要件定義のプロセスと一体で進めるべきで、詳しくは関連記事もあわせてご覧ください。
ドキュメント整備とリバースエンジニアリングの機能
適応保守を安全に続けるための土台が、ドキュメント整備の機能です。設計書やデータベース定義、改修履歴といったドキュメントが最新の状態に保たれていれば、誰が保守を担当しても、システムの構造を素早く把握して影響調査や改修を進められます。逆に、ドキュメントが古いまま、あるいは存在しないままだと、保守のたびに担当者がコードを読み解くところから始めることになり、属人化とコスト増を招きます。保守開発では、改修のたびにドキュメントを更新し続けることも、重要な機能の一つです。
そして、ドキュメントがそもそも残っていないシステムを引き継ぐ場合に不可欠なのが、リバースエンジニアリングの機能です。ソースコードからシステムの仕様を読み解き、必要な範囲で設計情報を復元することで、ドキュメントのないシステムでも保守を継続できます。実際に、ドキュメントが存在しないシステムに対してリバースエンジニアリングで伴走し、保守を引き継ぐサービスも提供されています。この能力は、他社が作ったシステムの保守を引き継ぐうえで決定的に重要で、保守開発パートナーを選ぶ際の重要な評価軸になります。
SLA運用と保守契約形態の機能差
ここまで見てきた是正・予防・適応の各機能を「どの水準で、いつまでに提供するか」を取り決めるのが、SLA（サービス品質保証）と保守契約です。同じ保守メニューでも、SLAの内容や契約形態によって、実際に受けられるサービスの質は大きく変わります。機能の有無だけでなく、その保証水準まで含めて評価することが、保守契約を選ぶうえで欠かせません。
稼働率保証・復旧時間とSLA／SLOの違い
SLA運用の中核は、稼働率と復旧時間の保証です。たとえば「月間稼働率99.9%以上」「重大障害は◯時間以内に復旧着手」といった数値を契約で取り決め、未達の場合は利用料の減額や返金といったペナルティを定めます。ここで注意したいのが、SLA（保証）とSLO（努力目標）の違いです。実在例で言えば、Amazon S3は稼働率95%未満で100%返金という明確なSLAを定める一方、サイボウズは稼働率をSLO（努力目標）と位置づけつつ、規約20条で「連続24時間以上停止しないことを保証する」という形を取っています。
つまり、同じ「稼働率」という言葉でも、それが法的な保証なのか、あくまで努力目標なのかで、未達時の扱いはまったく異なります。SLAが努力目標にとどまる契約では、稼働率が下回ってもペナルティは発生しません。なお、こうしたSLA条項は、民法548条の2が定める定型約款の論点とも関わります。保守契約のSLA機能を評価するときは、「保証なのか努力目標なのか」「未達時に何があるのか」を必ず読み込むことが、契約後のトラブルを防ぐ最大のポイントです。
定額・従量・内部組織型の契約形態と対応範囲
保守契約の形態によっても、提供される機能の使い勝手は変わります。代表的なのが、毎月一定額を支払う定額制と、対応した分だけ支払う従量制です。定額制は、決まった範囲の保守を継続的に受けられ、費用が読みやすい反面、契約範囲外の改修は別料金になります。従量制は、保守の頻度が低いシステムでは割安になりますが、障害が多発すると費用が膨らむリスクがあります。保守費用は、いずれの形態でも開発費の5〜15%／年が一つの相場です。
近年は、外部ベンダーを自社の内部組織の一部のように位置づける「内部組織型」のメニューも登場しています。たとえば月額10万円・最低1か月から利用できる形態もあり、フルタイムのエンジニアを雇うほどではないが、必要なときに改修や障害対応を任せたい企業に適しています。重要なのは、契約形態ごとに「どの機能がどこまで含まれるか」を見極めることです。定額の範囲、従量の単価、内部組織型の稼働時間などを契約で明確にし、自社の保守ニーズに合った形態を選ぶことが、機能を過不足なく確保する鍵になります。
まとめ
保守開発が提供する機能は、是正保守（バグ修正・障害対応）、予防保守（セキュリティ更新・劣化対策）、適応保守（改修・影響調査・ドキュメント整備）、SLA運用（稼働率・復旧時間の保証）の4つで整理すると漏れがありません。とりわけ、障害を未然に防ぐ予防保守と、ドキュメントのないシステムを引き継ぐリバースエンジニアリングは、保守開発の質を左右する重要な機能です。これらをどこまで契約に含めるかで費用は変わり、保守費用は開発費の5〜15%／年が相場です。必須と任意を切り分けて優先順位を付ければ、限られた予算でも最大の安心を確保できます。
機能の検討は、一覧を眺めるだけでは完結しません。自社のシステムが「止まったら何が困るか」を起点に必要な保守水準を見極め、稼働率・復旧時間・対応時間帯をSLAとして明文化し、要件定義へと落とし込むことが不可欠です。riplaはフルスクラッチ受託と国内伴走を組み合わせ、保守機能の網羅的な洗い出しと、自社の事業特性に合わせた契約設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。