運用保守は、リリース後のシステムを支え続ける業務です。監視やバックアップ、障害復旧、仕様変更への対応まで範囲が広く、ソフトウェア全体のコストの40〜80%（平均で約60%）を占めるとも言われます。属人化などの現場の課題も踏まえて整理し、詳しい内容は専門の解説記事で確認できます。
▼関連記事一覧
業務システム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
運用保守の全体像
運用保守を正しく理解するには、まず「運用」と「保守」という2つの言葉を区別することが第一歩です。
この境界線が曖昧なまま契約を結ぶと、「それは契約範囲外です」「追加費用が必要です」といったトラブルが起きやすくなります。そのため、業務範囲とライフサイクル上の位置づけを押さえておくことが大切です。
「運用」と「保守」の違い
運用とは、システムを正常に稼働させ続けるための定常的な業務を指します。具体的には、サーバーやネットワークの稼働監視、データのバックアップ、アクセス権限の管理、利用者からの問い合わせ対応などが含まれます。日々滞りなくシステムが動き続けるよう「守りを固める」のが運用の役割です。
一方の保守とは、障害が発生した際の原因究明と復旧、あるいは法改正や業務変更に伴うプログラムの改修・アップデートを指します。何か問題が起きたとき、または変化に合わせて手を加えるときの「変化への対応」が、保守の本質です。運用が予定された業務であるのに対し、保守は突発的・計画的な改善対応を含む点が大きな違いです。
業務範囲とライフサイクル上の位置づけ
運用保守は、システムのライフサイクルの中で開発・リリース後の最も長い期間を占める工程です。一般的にシステムの寿命は5年から10年に及び、その間ずっと運用保守が必要になります。また、経済産業省の調査では、既存システムの運用への支出が新規構築のおよそ2倍とされ、IT投資の大部分が「守り」に充てられている実態が見えてきます。
業務範囲としては、監視・バックアップといった日常運用に加え、障害対応、セキュリティパッチの適用、軽微な機能改修、ドキュメント整備などが含まれます。これらをどこまで内製し、どこから外部に委託するかが、後の費用や品質を大きく左右します。そのため、まず自社システムの運用保守の範囲を一覧にすることが出発点になります。
▶ 運用保守の定義や業務範囲をさらに詳しく知りたい方は 運用保守の進め方/やり方/流れや方法/手法/工程/手順 をご覧ください。
運用保守の進め方
運用保守を進めるときは、まず「内製か外注か」の判断から始めます。外部に委託する場合は、ベンダー選定、SLA設定、引継ぎ、定常運用の順に進みます。その際は、場当たり的に対応するより、体制設計から始めたほうが安定稼働への近道になります。
内製と外注の判断とSLA設計
まず判断すべきは、運用保守を社内で担うか外部に委託するかです。社内に十分なエンジニアと知見があるなら内製にも利点がありますが、人材不足や属人化のリスクが高い場合は外部委託が現実的な選択になります。また、コア業務に集中するために運用保守を外部に任せる企業も増えています。
外注する場合、品質を担保する鍵となるのがSLA（サービスレベル合意）です。サーバー稼働率や障害時の応答・復旧時間を定量的な目標値として定め、未達時の対応ルールまで合意しておきます。
たとえば大阪市のガイドラインでは、アプリ稼働率99.8%以上、障害発生後30分以内の通知遵守率100%といった具体値が示されています。こうした水準を参考にすると、自社に合ったSLAを設計できます。
引継ぎと定常運用のサイクル
ベンダーを切り替える際や新たに委託する際に意外と軽視されがちなのが、引継ぎのプロセスです。現行の担当者やベンダーから新担当へ業務を移管する際は、おおむね2ヶ月程度のOJT期間を設けるのが効果的です。さらに、新担当が1.0人月で参画し、現行担当者が週2日程度のサポートに入る体制を組むと、知識の断絶を防ぎやすくなります。
運用保守は一度設計して終わりではなく、継続的に改善していく営みです。引継ぎが完了すると、監視・障害対応・改修・報告という定常運用のサイクルが回り始めます。ここで重要なのは、対応の記録を残し、ドキュメントを継続的に整備することです。記録が積み重なると、属人化を防ぎ、将来のベンダー切り替えや内製化の選択肢も広がります。
▶ 運用保守の具体的な手順やフェーズごとの進め方は 運用保守の進め方/やり方/流れや方法/手法/工程/手順 で詳しく解説しています。
運用保守を委託する開発会社の選び方
運用保守を任せるパートナーは、長期にわたるシステム品質を左右する意思決定です。そのため、技術力・体制・透明性を多面的に見て選ぶことが、失敗を避ける鍵になります。個別の会社名ではなく、どの基準でパートナーを評価すべきかという選定の考え方から見ていきます。
実績と技術力の確認ポイント
まず確認したいのは、自社と似た規模・業種のシステムを運用保守してきた実績です。同種のシステムを扱った経験があれば、想定される障害パターンや改修要望への対応力が期待できます。
あわせて押さえたいのは、対応可能な技術領域の広さです。インフラからアプリケーション、クラウド環境まで幅広くカバーできるベンダーは、障害時の責任の押し付け合いを避けられます。
選定を客観的に行うには、技術力・コスト・SLAなどの評価軸を設けた評価表を使うのが有効です。「○5点・△2点・×0点」のように差が開く配点で採点し、価格の配点は20点以下に抑えると、安さだけで品質の低いベンダーを選ぶリスクを下げられます。複数社を同じ基準で比較することで、評価のブレも防げます。
体制とサポートの評価
運用保守は長期の信頼関係が前提となるため、サポート体制を見極めることが欠かせません。障害発生時の連絡窓口や対応時間帯、エスカレーションの流れが明確かどうかを、事前に確かめておく必要があります。24時間365日の監視が必要なシステムであれば、夜間休日の対応体制も評価項目の一つになります。
もう一つ見ておきたいのが、対応内容の透明性です。月次で作業報告書を提出してくれるか、どの作業にどれだけの工数がかかったかを開示してくれるベンダーは信頼できます。作業報告書やサーバーログから実稼働時間を算出できれば、保守費用が妥当かを自社で検証することも可能になり、長期的なコスト適正化にもつながります。
▶ 具体的なおすすめ会社や比較のポイントは 運用保守でおすすめの開発会社/ベンダー6選と選び方 で紹介しています。
運用保守の費用相場
運用保守の費用は、システムの規模や求める品質、対応範囲によって大きく変動します。一般的には、初期開発費用の一定割合を年間保守費用とする考え方が用いられます。そのうえで、内訳と変動要因を理解しておくと、見積りの妥当性を判断しやすくなります。
規模別の費用目安と内訳
運用保守費用を考えるうえで押さえたいのは、ライフサイクル全体に占める保守コストの大きさです。ソフトウェア全体のコストのうち40〜80%、平均すると約60%が運用保守に充てられるとされています。さらに、開発費用よりもリリース後に支払い続けるコストの方が大きくなるケースも珍しくありません。
費用の内訳としては、監視やバックアップなどの定常運用にかかる人件費、障害対応や改修にかかる工数、サーバーやライセンスなどのインフラ費用が中心です。なかでも保守作業で最も時間を要するのは「調査・分析」で、全作業時間の約30%を占めると言われます。つまり、すぐ直せる作業よりも、原因を突き止める工程にコストがかかっているのです。
費用を左右する主な要因
費用を左右する要因として大きいのは、対象システムの習熟度とドキュメントの整備状況です。仕様書や設計書が残っていれば調査時間を短縮できますが、ドキュメントが不足しているシステムは解析に手間がかかり、その分コストが上振れします。さらに、属人化が進んだシステムほど、保守費用が高くなりやすい傾向があります。
提示された保守費用が妥当かを見抜くには、相見積もりに加えて、作業報告書やサーバーログから実稼働時間を割り出し、適正価格を逆算する監査の視点が有効です。「毎月固定で支払っているが、実際の作業はわずか」という状態が見えてくれば、価格交渉の材料になります。費用の中身を理解することが、ぼったくりを防ぐ最大の防御策です。
▶ 費用相場や見積りの詳しい内訳は 運用保守の見積相場や費用/コスト/値段について で詳しく解説しています。
運用保守の発注・外注方法
運用保守を外部に発注するときは、依頼先の種類を理解したうえで、RFP（提案依頼書）の準備や契約形態の選択を計画的に進める必要があります。発注前の準備の質が、その後の運用品質とトラブルの有無を大きく左右します。
発注前に準備すべきドキュメント
運用保守の発注は、要件定義から始まり、RFI（情報提供依頼）、RFP（提案依頼）、評価表による比較・選定という流れで進みます。全体としておおむね4〜6ヶ月を要するため、現在の契約満了の6ヶ月前には動き出すのが理想です。準備が遅れると、選択肢が狭まり、不利な条件で契約せざるを得なくなります。
準備すべきドキュメントとしては、現行システムの構成図、対応してほしい業務範囲を明記した要件一覧、希望するSLA水準などが挙げられます。また、既存ベンダーをあえてRFPに参加させると競争原理が働き、契約条件の大幅な見直しによって既存ベンダーの継続が30〜40%の確率で発生するとも言われます。この緊張感のある選定が、結果的にコスト適正化につながります。
契約形態の選び方と落とし穴
運用保守の契約は、継続的なサービス提供を約束する準委任契約と、明確な成果物の完成を約束する請負契約に分かれます。準委任契約は完成責任を負わない監視や問い合わせ対応に、請負契約は機能改修などのプロジェクト型業務に向いており、業務の性質に応じて使い分けます。また、保守契約を準委任契約とすると収入印紙が不要になるケースが多いなど、実務上のメリットもあります。
契約には見落としがちな落とし穴もあり、たとえばハードウェア保守でHDDを交換した場合、故障部品の所有権は保守会社に帰属するのが一般的です。機密データの確実な破棄を求める場合は、別契約が必要になります。契約書には保守対象範囲、費用、免責事項、解除条件を明記しておくと、後の「対象外」「追加費用」トラブルを防げます。
▶ 発注・外注・委託の具体的な進め方は 運用保守の発注/外注/依頼/委託方法について で詳しく解説しています。
運用保守で失敗しないためのポイント
運用保守を長期にわたって安定させるには、属人化への備え、クラウド時代の役割分担、最新トレンドの活用が欠かせません。現場でつまずきやすい論点を順に見ていきます。
属人化・ブラックボックス化への対策
運用保守の最大のリスクの一つが、特定の担当者しかシステムの中身を理解していない属人化です。キーマンが突然退職し、ドキュメントも残っていない状態に陥ると、明日からの障害対応すらおぼつかなくなります。これを防ぐには、日々の作業記録とドキュメント整備を習慣化し、複数人で知識を共有する体制をあらかじめ作っておくことが欠かせません。
万が一ブラックボックス化してしまった場合でも、近年はAIに既存コードを解析させるリバースエンジニアリングで、仕様を知る人がいないレガシーシステムの構造を読み解く手法が登場しています。こうしたAIを活用した解析は、ブラックボックス化の解消と省力化の両面で有効な選択肢となりつつあります。
クラウドの責任分界と最新トレンド
AWSやAzureといったパブリッククラウドを利用する場合、責任共有モデルの理解が不可欠です。クラウド基盤そのものはクラウド事業者が守りますが、その上に構築したアプリケーションやデータの管理はユーザー側の責任になります。この責任領域を情シスが負うか保守ベンダーに委託するかを、RACIチャートなどで明確にしておくと、障害時の責任の押し付け合いを防げます。
最新トレンドとしては、運用業務にAIを活用するAIOps、開発と運用を一体化するDevOps、クラウドの活用で運用そのものを極力なくすNoOpsといった概念が広がっています。ただしAIOpsは、いきなり全体を刷新すると現場が混乱するため、アラートの一次切り分けといった小さな業務からスモールスタートするのが鉄則です。
あわせて、システムの終焉に伴うEOL/EOS時のデータ移行や保守契約の安全な終了まで見据えると、ライフサイクル全体を見通した運用保守が実現できます。
まとめ
ここまで、運用保守の全体像から進め方、開発会社の選び方、費用相場、発注・外注方法、失敗しないためのポイントまでを解説してきました。
運用保守は、ソフトウェアコストの約60%を占める長期の営みです。運用と保守の定義を理解し、SLAや契約条項を適切に設計することが、安定稼働とコスト適正化の両方を実現する鍵になります。
属人化への備え、クラウドで誰が何を受け持つか、AIOpsやEOL/EOSまで見据えれば、後顧の憂いを絶ったシステム運用が可能になります。
各テーマの詳細は下の関連記事で深掘りしています。自社の課題に近いものから読み進め、最適な運用保守体制づくりにお役立てください。
▼関連記事をテーマ別に確認できます。
▼開発を相談する前に読みたい無料ホワイトペーパーはこちらです。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。