ソフトウェア運用保守は、リリース後のシステムを安定して動かし続け、改善を重ねるために欠かせない活動です。
実際、ライフサイクル全体の費用のうち40〜80%（平均でおよそ60%）が保守フェーズに費やされるといわれ、開発そのものより運用保守のほうがIT予算を圧迫するケースも珍しくありません。
運用の進め方・ベンダー選び・費用・発注方法を関連記事で確認できます。
- ソフトウェア運用保守の進め方/やり方/流れや方法/手法/工程/手順
- ソフトウェア運用保守でおすすめの開発会社/ベンダー6選と選び方
- ソフトウェア運用保守の見積相場や費用/コスト/値段について
- ソフトウェア運用保守の発注/外注/依頼/委託方法について
業務システム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
ソフトウェア運用保守の全体像と4分類
ソフトウェア運用保守は、「運用」と「保守」の2つに分けて理解すると、全体の構造が見えてきます。
運用は、システムを正常に動かし続けるための定常業務です。
保守は、不具合や変化に対応してソフトウェアそのものに手を入れる業務を指します。
ソフトウェア固有の視点として、国際規格ISO/IEC 14764の4分類を押さえると、自社に必要な作業の性質がはっきりします。
運用と保守の違い
運用とは、システムが日々問題なく稼働するよう維持する定常的な業務です。具体的には、サーバーやアプリケーションの稼働監視とデータのバックアップが中心で、アクセス権限の管理やユーザーからの問い合わせ対応も含まれます。運用は、あらかじめ決めた手順に沿って繰り返し行う性質が強く、トラブルを未然に防ぐことが主な目的です。
一方の保守は、障害が起きたときの原因究明と復旧、仕様変更や機能追加に伴うソフトウェアの改修を指します。運用が「正常状態の維持」であるのに対し、保守は「変化や異常への対応」にあたります。
この境界は、契約の段階で明確にしておくことが、「対象外」「追加費用」といったトラブルを避ける第一歩になります。
ISO/IEC 14764による保守の4分類
ソフトウェア保守は、国際規格ISO/IEC 14764によって、不具合の修正、環境変化への対応、改善、潜在的な問題の予防という目的ごとに4つに分類されています。
- 是正保守：発見された不具合（バグ）を修正する作業
- 適応保守：OSやミドルウェアのバージョンアップ、法制度の変更などの外部環境の変化に合わせる作業
- 完全化保守：性能改善や使い勝手の向上など、より良くするための改修
- 予防保守：まだ顕在化していない潜在的な問題を事前に取り除く作業
自社の保守ニーズがこの4つのどこに重心を置いているかを把握すると、依頼範囲や見積りの妥当性を判断しやすくなります。とくに予防保守と完全化保守は、やればやるほど良い反面コストが膨らみやすいため、優先順位づけが重要です。
運用の全体像は、関連記事「ソフトウェア運用保守の進め方/やり方/流れや方法/手法/工程/手順」で確認できます。
ソフトウェア運用保守の進め方
ソフトウェア運用保守は、まず内製と外注のどちらで担うかを決めるところから始まります。
外注するなら、ベンダー選定、SLA設定、引継ぎの順で進めていきます。
場当たり的に着手すると、ブラックボックス化や費用の膨張を招くおそれがあります。そのため、ライフサイクル全体を見据えた進め方が欠かせません。
内製・外注の判断とベンダー選定
最初の分岐点は、保守を自社で内製するか、外部のベンダーに委託するかの判断です。社内に該当ソフトウェアを理解したエンジニアがいて、属人化のリスクを許容できるなら、内製も選択肢になります。一方で、人材確保が難しい場合や24時間の監視体制が必要な場合は、外注のほうが現実的です。
外注する場合、ベンダー選定には全体で4〜6ヶ月かかるのが一般的です。要件定義のあとにRFI（情報提供依頼）とRFP（提案依頼）を行い、評価表で比較して選定します。
既存の保守契約がある場合は、契約満了の6ヶ月前には動き出すことが推奨されます。さらに評価では、価格の配点を20点以下に抑えると、品質の低いベンダーを排除しやすくなります。
SLA設定と引継ぎ
ベンダーが決まったら、SLA（サービスレベル合意）で品質基準を数値で定めます。サーバー稼働率や障害発生時の応答時間・復旧時間をKPIとして設定し、目標未達時の対応ルールまで決めておくことが重要です。たとえば公的機関のガイドラインでは、稼働率99.8%以上、障害発生後30分以内の通知遵守率100%といった具体値が示されています。
ベンダーを切り替える際は、引継ぎの設計も成否を左右します。新担当者に1.0人月程度を割り当て、現行担当者が週2日程度サポートに入る体制が効果的とされています。保守はソフトウェアの内部仕様を深く理解していないと務まらないため、ドキュメントの整備と並行して、知識移転の期間を十分に確保することが望ましいといえます。
運用設計の手順は、関連記事「ソフトウェア運用保守の進め方/やり方/流れや方法/手法/工程/手順」で確認できます。
ソフトウェア運用保守の開発会社・ベンダーの選び方
ソフトウェア運用保守を委託するベンダーは、開発実績の多さだけで選ぶと失敗しがちです。
保守は長く付き合う関係になるため、技術力に加えて、対応の速さ、体制の安定性、コミュニケーションの取りやすさを合わせて評価する必要があります。
実績と技術力の確認ポイント
確認すべきは、自社のソフトウェアと近い技術スタックや業務領域での保守実績があるかどうかです。使っている言語やフレームワーク、インフラ環境に詳しいベンダーであれば、障害発生時の原因特定が速く、改修の品質も安定します。
とくにレガシー化したシステムを引き継ぐ場合は、リバースエンジニアリングで既存コードを解析できる技術力があるかどうかを見極める必要があります。
あわせて、保守作業のうち最も時間を要するのは「調査・分析」で、全作業時間の約30%を占めるといわれます。この調査力で保守ベンダーの実力差が出るため、過去の障害対応事例や原因分析の進め方をヒアリングすると、見えにくい技術力を推し量ることができます。
体制とサポートの評価
保守は長期の伴走が前提となるため、属人化していない体制かどうかを確認します。担当者が1人に依存していると、その人が離職した際に保守が止まるリスクがあります。一方で、複数名でナレッジを共有し、ドキュメントを継続的に整備する文化があるベンダーは、安定したサポートが期待できます。
また、問い合わせへの応答時間、夜間・休日対応の有無、障害発生時のエスカレーションフローなど、サポート体制を契約前に具体的に確認することも欠かせません。そのうえで、これらの基準を満たした候補を相見積もりで比較すると、納得感のある選定につながります。
▶ 詳細はこちら：ソフトウェア運用保守でおすすめの開発会社/ベンダー6選と選び方
ソフトウェア運用保守の費用相場
ソフトウェア運用保守の費用は、システムの規模や複雑さ、求める対応レベルによって大きく変動します。一般的な目安として、初期開発費用の年間5〜15%程度を保守費用とするケースが多く見られます。
ライフサイクル全体では保守費用が大きな割合を占めるため、構造を理解したうえで、その妥当性を判断することが大切です。
費用構造と規模別の目安
保守費用の中心は人件費で、エンジニアの稼働工数（人月）で多くが決まります。月額制の固定契約や作業量に応じた従量制など、契約形態によって料金体系は異なります。規模で見ると、小規模なソフトウェアなら月額数万円から、基幹システムのように複雑で停止が許されないものでは月額数十万円から数百万円規模になることもあります。
費用を左右する大きな要因は、ソフトウェアの規模だけでなく、ドキュメントの整備状況や担当者の習熟度です。設計書が整っていればベンダーは状況を把握しやすく工数を抑えられますが、ドキュメントがなくコードから解析する必要があると、調査工数が膨らんで費用が上がります。
改造開発の見積りでは、改造密度・改造分散度・改造母体錬度の3つの観点から生産性を定量的に評価する手法も用いられます。
費用の妥当性を見抜く視点
「今の保守費用は適正なのか」という疑問は、相見積もりだけでは解消しきれないことがあります。そこで有効なのが、作業報告書やサーバーログから実際の稼働時間を割り出し、支払っている金額に見合った作業がなされているかを検証するアプローチです。
実際、月額固定でほとんど作業が発生していないのに、高額を払い続けているケースは少なくありません。こうしたITデューデリジェンスの視点を持つことで、ベンダーとの交渉材料が得られます。費用の内訳を、監視や定型作業、障害対応、改修などの項目に分けてもらい、それぞれの工数の根拠を確認することが、適正価格に近づける近道です。
▶ 詳細はこちら：ソフトウェア運用保守の見積相場や費用/コスト/値段について
ソフトウェア運用保守の発注・外注方法
ソフトウェア運用保守を外注する際は、発注先の種類を理解し、適切な契約形態を選び、必要なドキュメントを準備することが成功の鍵です。
準備が不十分なまま発注すると、想定外の追加費用や対象範囲をめぐるトラブルにつながりかねません。
発注先の種類と契約形態
発注先には、開発を担当したベンダーに委託する方法、保守専門の会社に切り替える方法、フリーランスのエンジニアに依頼する方法などがあります。開発元への委託は内部仕様を熟知している安心感がある一方で、費用が割高になりやすい面もあります。そのため、コストや専門性のバランスを見ながら選ぶことが大切です。
契約形態では、準委任契約と請負契約の使い分けが求められます。監視や問い合わせ対応のような継続的サービスは、完成責任を負わない準委任契約が向いています。機能改修のように明確な成果物がある作業は、請負契約が適しています。
保守契約を準委任契約とすると、第7号文書として収入印紙が不要になるケースが多く、実務上のメリットです。
発注前に準備すべきドキュメント
発注前には、システム構成図や設計書、運用手順書といったドキュメントを、できる限り揃えておくことが望ましいです。過去の障害履歴も含めて揃っているほど、ベンダーは現状を正確に把握でき、見積りの精度が上がり、引継ぎもスムーズに進みます。逆に資料が乏しいと、調査に余計な工数がかかり、費用が膨らみます。
契約書には、保守対象範囲、費用と支払い方式を明記し、免責事項と契約解除条件も定めておくことが必須です。とくに、どこまでが保守の対象で、どこからが追加費用なのかを明確にしておくことが、後のトラブル回避につながります。免責事項がベンダーに有利になりすぎていないかも、あわせて確認しておきたいところです。
▶ 詳細はこちら：ソフトウェア運用保守の発注/外注/依頼/委託方法について
ソフトウェア運用保守で失敗しないためのポイント
ソフトウェア運用保守でつまずく企業には、いくつかの共通したパターンがあります。属人化、契約の曖昧さ、そして終わらせ方の準備不足です。
これらを事前に意識しておくことで、長期にわたって安定した保守体制を維持できます。
属人化とブラックボックス化への対策
最も多い失敗は、特定の担当者だけがソフトウェアの仕様を把握している状態で、その人が退職するとシステムがブラックボックス化してしまうことです。これを防ぐには、日頃からドキュメントを整備し、知識を複数名で共有しておくことが基本です。
万が一、仕様を知る人がいない古いシステムを引き継ぐことになった場合は、既存コードをAIに解析させるリバースエンジニアリングが有効な手段になります。
これにより、開発当初の仕様が分からないレガシーソフトウェアでも、構造を把握しながら保守を続けられる可能性が高まります。そのため、属人化が崩壊する前に、こうした省力化の選択肢を知っておくことが安心につながります。
EOL/EOSと保守契約のクロージング
ソフトウェアには必ず終わりがあり、EOL（提供終了）やEOS（サポート終了）を迎えるものや、リプレイスで役目を終えるシステムでは、保守契約をどう安全に終了させるかも重要なテーマです。データ移行や残存リスクの整理を計画的に進めないと、移行先での障害や情報漏えいにつながりかねません。
運用そのものを軽くする動きも、近年は広がっています。
- DevOps・NoOps：開発と運用を一体化させたり、運用負荷を極力減らしたりする考え方
- AIOps：アラートの一次切り分けをAIに任せて省力化する取り組み
これらは一気に導入すると現場が混乱するため、小さな業務からスモールスタートで進めることが鉄則です。ライフサイクル全体を見据え、終わらせ方まで含めて設計することが、後悔しない運用保守につながります。
失敗を防ぐ進め方は、関連記事「ソフトウェア運用保守の進め方/やり方/流れや方法/手法/工程/手順」で確認できます。
まとめ
ソフトウェア運用保守は、運用と保守の違いを理解し、ISO/IEC 14764の4分類で自社のニーズを整理するところから始まります。
進め方では、内製・外注の判断、ベンダー選定、SLA設定と引継ぎが鍵となります。選定では、実績と技術力に加えて、属人化していない体制かどうかを見極めることが大切です。
費用はライフサイクル全体の大きな割合を占めるため、構造を理解し妥当性を検証する視点が欠かせません。
発注時には、契約形態の使い分けとドキュメント整備が重要で、契約書の対象範囲を明確にすることでトラブルを防げます。
そして、属人化対策やEOL/EOSへの備えまで含めて、ソフトウェアのライフサイクル全体を見据えることが、失敗しない運用保守の条件です。
関連記事では運用保守の各テーマを詳しく解説しています。
- ソフトウェア運用保守の進め方/やり方/流れや方法/手法/工程/手順
- ソフトウェア運用保守でおすすめの開発会社/ベンダー6選と選び方
- ソフトウェア運用保守の見積相場や費用/コスト/値段について
- ソフトウェア運用保守の発注/外注/依頼/委託方法について
開発前に確認したい無料ホワイトペーパーはこちらです。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。