保守開発は、不具合を直すことに加え、障害に備えた予防や機能改修、環境変化への対応を続ける取り組みです。必要な機能は4つに整理できます。
対応範囲と着手時間は契約前に明確にしたうえで、自社に必要な対応が含まれるかを項目ごとに見ていきます。
- 是正保守：バグや障害の原因を特定して修正
- 予防保守：脆弱性や将来の障害に備えた更新・点検
- 適応保守：環境変化に応じた機能改修
- SLA運用：稼働率や着手・復旧時間などの条件の取り決め
保守開発の全体像は、保守開発の完全ガイドでも確認できます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
是正保守の機能（バグ修正・障害対応）
是正保守とは、システムに発生した不具合や障害を「直す」機能のことです。保守開発の中でもっとも分かりやすく、緊急性も高い領域といえます。
システムが止まったり誤動作したりしたときに、原因を特定して修正し、正常な状態に戻すまでを担います。運用の役割が「異常を見つけて知らせる」ことだとすれば、是正保守は「異常をコードに手を入れて直す」役割です。
バグ修正と原因特定の機能
バグ修正は是正保守の中核です。リリース後に発覚した不具合や、特定の操作でのみ起きるエラーを、再現して原因を特定し、修正とテストを経て反映するまで一連の流れで処理します。
単に表面的な症状を抑えるのではなく、根本原因を突き止めて直すことが大切です。応急処置で済ませると、同じバグが形を変えて再発し、かえって保守工数が増えてしまいます。契約では、「どの程度の調査・原因特定まで対応範囲に含まれるか」と「再発を防ぐ恒久対策まで含むか」を明確にしておくと、後のトラブルを防げます。
原因特定の力量は、ベンダーの技術力がもっとも表れる部分です。とくに他社のシステムを引き継いだ場合、コードの全体像を把握していなければ、原因にたどり着くまでに時間がかかります。なお、ドキュメントが残っていないシステムでは、後述するリバースエンジニアリングの能力が、修正のスピードと精度を左右します。
障害対応と緊急復旧の機能
障害対応は、システムが停止したり重大な不具合に陥ったりしたときに、できるだけ早く正常稼働へ戻す機能です。ここで決定的に重要になるのは、「いつ、どれだけ速く対応してもらえるか」という時間軸です。
対応時間帯は平日の日中だけか、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条項は、民法548条の2が定める定型約款の論点とも関わります。保守契約のSLAは、保証か努力目標か、未達時に何があるかを読み込んで評価すると、契約後のトラブルを防げます。
定額・従量・内部組織型の契約形態と対応範囲
保守契約の形態によっても、提供される機能の使い勝手は変わります。代表的なのが、毎月一定額を支払う定額制と、対応した分だけ支払う従量制です。定額制は、決まった範囲の保守を継続的に受けられ、費用が読みやすい反面、契約範囲外の改修は別料金になります。
従量制は、保守の頻度が低いシステムでは割安になりますが、障害が多発すると費用が膨らむリスクがあります。また、保守費用はいずれの形態でも、開発費の5〜15%／年が一つの相場です。近年は、外部ベンダーを自社の内部組織の一部のように位置づける「内部組織型」のメニューも登場しています。
内部組織型は、たとえば月額10万円・最低1か月から利用できる形態もあり、フルタイムのエンジニアを雇うほどではないが、必要なときに改修や障害対応を任せたい企業に適しています。契約形態ごとに、どの機能がどこまで含まれるかを見極めます。定額の範囲や従量の単価、内部組織型の稼働時間を契約で明確にし、自社に合った形態を選ぶことが、機能を過不足なく確保するうえで欠かせません。
まとめ
保守開発の機能は、4つの区分で整理すると漏れがありません。是正保守は障害の修正と復旧を、予防保守は障害を未然に防ぐ対策を受け持ちます。適応保守は環境変化への改修を、SLA運用は稼働率と復旧時間の保証を担います。
とりわけ、障害を未然に防ぐ予防保守と、ドキュメントのないシステムを引き継ぐリバースエンジニアリングは、保守開発の質を左右する機能です。
これらをどこまで契約に含めるかで費用は変わり、保守費用は開発費の5〜15%／年が相場です。そのうえで、必須と任意を切り分けて優先順位を付ければ、限られた予算でも最大の安心を確保できます。
機能の検討は、一覧を眺めるだけでは完結しません。自社のシステムが「止まったら何が困るか」を起点に進めます。必要な保守水準を見極め、稼働率・復旧時間・対応時間帯をSLAとして書き表し、要件定義へ落とし込むことが欠かせません。
riplaはフルスクラッチ受託と国内伴走を組み合わせ、保守機能の網羅的な洗い出しと、自社の事業特性に合わせた契約設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。