システム運用保守は、稼働中のシステムを保つ日々の運用と、障害や改修に対応する保守を合わせた業務です。ライフサイクル全体のコストの平均約60%を占めるため、契約範囲・体制・評価方法を決めて設計することが欠かせません。
運用保守の進め方・委託先・費用を詳しく知りたい方に向け、関連解説をまとめました。
- システム運用保守の進め方/やり方/流れや方法/手法/工程/手順
- システム運用保守でおすすめの開発会社/ベンダー6選と選び方
- システム運用保守の見積相場や費用/コスト/値段について
- システム運用保守の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システム運用保守の全体像
システム運用保守を理解する第一歩は、似て非なる2つの業務である「運用」と「保守」を切り分けることです。この境界が曖昧なまま契約を結ぶと、後から「契約範囲外です」「追加費用が必要です」と言われ、トラブルに直結します。まずは両者の定義と、業務システムに固有の安定稼働要件を押さえておきましょう。
「運用」と「保守」の違い
運用とは、システムが正常に稼働し続けている状態を維持するための定常業務を指します。具体的には、サーバーやアプリケーションの稼働監視、データのバックアップ、ユーザーのアクセス権限管理などがあります。問い合わせ対応も含め、いずれも日々ルーチンとして発生する作業です。
つまり運用は、システムが動いている前提で、その状態を守り続ける役割です。一方で保守とは、障害が起きたときの原因究明と復旧、仕様変更やOS・ミドルウェアのアップデートに伴う改修など、システムに手を加える業務のことです。
運用が平常時の維持だとすれば、保守は異常時の対応や能動的な改善にあたります。この2つは性質が違うため、契約では区別して明記することが、トラブル防止の第一歩になります。実際、多くの契約トラブルは、この線引きの曖昧さから生まれています。
業務システムに固有の安定稼働要件
販売管理や生産管理、顧客管理などの業務システムは、会計と並んで企業の事業活動そのものを支えています。そのため、Webサイトのような対外向けシステムとは異なる安定稼働要件が求められます。たとえば月末の締め処理や繁忙期の大量バッチ処理では、特定のタイミングに負荷が集中するため、その局面で確実に動くことが欠かせません。
また、業務システムは長く使い続けられる傾向が強く、法改正や組織変更、取引先の要件変化に応じて、改修が頻繁に発生します。経済産業省の調査でも、企業のIT支出は「従来システムの運用」対「新規構築」がおおむね2対1とされ、既存システムの維持負担が大きいことが示されています。そのため、この維持コストをどう適正化するかが、業務システム運用保守の中心テーマになります。
▶ 詳細はこちら：システム運用保守の進め方/やり方/流れや方法/手法/工程/手順
システム運用保守の進め方
システム運用保守を軌道に乗せるには、行き当たりばったりを避け、体制設計から日々の運用、継続的な改善までを一連のライフサイクルとして組み立てることが必要です。まず体制を整え、次にSLA（サービスレベル合意）を軸とした品質管理を進めます。
内製か外注かの判断と体制づくり
運用保守の進め方は、まず「自社内製で回すのか、外部ベンダーに委託するのか」という判断から始まります。社内にエンジニアと知見が十分にあり、システムへの理解が蓄積されているなら、内製も選択肢になります。一方で、人材不足や属人化のリスクが高い場合は、外注が現実的です。
多くの企業では、監視やヘルプデスクを外部に委託し、業務に直結する改修は社内で意思決定する、ハイブリッド体制を採ります。外注する場合、ベンダー選定には全体で4〜6ヶ月程度を要するのが一般的です。
要件定義からベンダー選定、引継ぎまでを逆算すると、現行契約の満了6ヶ月前には動き出す必要があります。選定では、RFI（情報提供依頼）とRFP（提案依頼）を経て、評価表で比べます。引継ぎには、新担当者1.0人月に加えて、現行担当者が週2日程度サポートに入る体制が効果的とされます。
SLA設計による品質管理
運用保守の品質を数値で管理する仕組みが、SLA（サービスレベル合意）です。サーバーやアプリケーションの稼働率や、障害発生時の応答時間・復旧時間をKPIとして定め、合意した水準を満たしているかを継続的にモニタリングします。これにより、「なんとなく対応が遅い」といった曖昧な不満を、数値の問題として議論できるようになります。
具体的な目標値の参考として、大阪市のガイドラインを見ておきます。サーバ・アプリの稼働率は99.8%以上、基準応答時間の達成率は93%（3秒以内）です。重大障害は年2回まで、障害通知の遵守率は100%（発生後30分以内）、ヘルプデスクの電話応答率は97%以上（平均20秒以内）と示されています。
こうした具体値をたたき台に、自社の業務に合った目標値と、未達時の対応ルール（サービスレベル管理）を設計していくことが、進め方の要になります。実務の具体的な手順は、システム運用保守の進め方/やり方/流れや方法/手法/工程/手順で確認できます。
システム運用保守の開発会社・ベンダーの選び方
運用保守の委託先選定は、開発を依頼する会社選び以上に長期的な付き合いになるため、慎重な評価が欠かせません。委託先を評価するには、どのような基準を使うかが選定の軸になります。具体的なおすすめ会社は専門記事で紹介しているので、あわせて参考にしてください。
評価軸と評価表の作り方
ベンダーを比較するときは、技術力や業務理解度、SLAへの対応姿勢を中心に複数の評価軸を設け、評価表で点数化するのが定石です。コストも評価軸に加えますが、注意したいのは価格の配点を高くしすぎないことです。運用保守は安かろう悪かろうが最も表れやすい領域のため、価格の配点を20点以下に抑えると、安さだけで品質の低いベンダーが上位に来ることを防げます。
点数の付け方にもコツがあります。各項目を「○は5点、△は2点、×は0点」のように差が開く配点にすると、評価者ごとのブレが減り、本当に優れたベンダーが浮かび上がりやすくなります。逆に、なんとなく3点や4点と中間にまとめてしまうと、差がつかず、選定の意味が薄れてしまいます。
管理体制とサポート品質の確認
技術力と並んで重視したいのは、障害時の連絡体制とサポート品質です。一次受付から復旧までの連絡フロー、夜間・休日の対応可否、エスカレーションのルールなどを、契約前に確認しておく必要があります。運用保守は平常時より障害時にこそ真価が問われるため、緊急時の動き方を具体的に質問し、回答の質を見極めます。
既存ベンダーから乗り換えを検討している場合は、現行ベンダーをあえてRFPに参加させるのも有効な手段です。競争原理が働くと、契約条件が大幅に見直されます。その結果、既存ベンダーがそのまま継続するケースも30〜40%程度発生します。
いずれにしても、新しいベンダーへ切り替えるかどうかにかかわらず、複数社を競わせる構図をつくること自体が、条件改善につながります。委託先選びの詳細は、システム運用保守でおすすめの開発会社/ベンダー6選と選び方で解説しています。
システム運用保守の費用相場
システム運用保守の費用は、システムの規模や複雑さ、求めるサービスレベルによって大きく変わります。一般的には、初期構築費用の一定割合を年間保守費として支払う形が多く見られます。まず費用の構造を確認し、そのうえで妥当性を見抜く視点を押さえます。
費用の構造と変動要因
前述のとおり、ソフトウェアのライフサイクル全体に占める運用保守コストは40〜80%、平均では約60%を占めます。開発が終わった後にこそ、長い支出が始まると考えるべきです。年間保守費は初期開発費の15%前後を目安とするケースが多いものの、これはシステムの安定性や改修頻度によって大きく上下します。
費用を左右する主な要因は、システムの複雑さやドキュメント整備の状況、担当エンジニアの習熟度です。加えて、求めるSLAの水準も費用に響きます。とくにドキュメントが整っておらず属人化が進んだシステムは、調査に時間がかかるため保守費が高止まりします。
実際、保守作業で最も時間がかかるのは「調査・分析」で、全作業時間の約30%を占めるとされています。費用を抑えたいなら、まずドキュメントを整えて調査時間を減らすのが近道です。
保守費用の妥当性を見抜く視点
「今払っている保守費用は適正なのか、割高になっていないか」は、多くの担当者が抱える本音です。これを相見積もり以外で確かめる手法が、ITデューデリジェンス（保守費用の妥当性監査）です。ベンダーから提出される作業報告書やサーバーログを突き合わせ、実際に何時間の作業が発生しているかを算出すれば、契約金額に対する実稼働の割合が見えてきます。
もし契約上の人月に対して実作業が著しく少なければ、契約形態の見直しや減額交渉の根拠になります。逆に、作業量が想定を上回っている場合は、値下げよりも品質維持のための適正コストとみなせます。
感覚ではなく、ログという事実をもとに費用を話し合うことが、ベンダーとの健全な関係づくりにつながります。費用の詳細は、システム運用保守の見積相場や費用/コスト/値段についてで解説しています。
システム運用保守の発注・外注方法
運用保守を外部に委託するときは、発注の流れと契約形態の選択が成否を分けます。とくに契約形態を誤ると、責任の所在が曖昧になり、後の障害対応でもめる原因になります。まず契約形態の基本を整理し、そのうえで発注前に準備するドキュメントを確認します。
準委任契約と請負契約の使い分け
運用保守の契約形態は、大きく準委任契約と請負契約に分かれます。準委任契約は、監視や問い合わせ対応のように継続的なサービス提供を約束する契約で、成果物の完成責任は含まれません。一方の請負契約は、特定の機能改修のように明確な成果物の完成を約束する形態です。
日々の運用は準委任、個別の改修案件は請負というように、業務の性質で使い分けるのが基本です。契約形態の選択には、税務上のメリットも関わります。たとえば、保守契約を準委任契約とすると、第7号文書として収入印紙が不要になるケースが多く、コスト面でも合理的です。
どちらが自社の業務に合うかは、求める成果と責任範囲を整理したうえで判断します。
発注前に準備すべきドキュメント
外注を成功させるには、発注前の準備が9割と言っても過言ではありません。最低限そろえたいのは、次の資料です。
- システム構成図：現行システムの全体の構成
- 現行の運用手順書：日々の運用の進め方
- 過去の障害履歴：これまでに起きた障害の記録
これらに求めるSLAの水準を加えてRFP（提案依頼書）にまとめておくと、ベンダーからの提案精度が格段に上がります。
情報が不足したまま見積もりを依頼すると、リスク分を上乗せした割高な金額が返ってきがちです。契約書には、次の事項を明確に書いておくことが欠かせません。
- 保守対象範囲：どこまでを保守の対象とするか
- 費用と支払い方式：保守費用と、その支払いの仕方
- 免責事項：ベンダーが責任を負わない場合の取り決め
- 契約解除の条件：契約を途中で終える場合の条件
これらが不十分だと、「対象外」「追加費用」をめぐるトラブルに発展します。
なお、移行を伴う乗り換えでは注意が必要です。新ベンダーの月額が安くても、移行コストが300〜500万円かかるなら、5年間のTCO（総保有コスト）で見ると有利さが逆転することもあります。目先の月額ではなく、総保有コストで比べて判断します。
発注・外注の方法は、システム運用保守の発注/外注/依頼/委託方法についてで解説しています。
運用保守を変える最新トレンドとライフサイクルの終わり方
AIやクラウドの普及により、システム運用保守の姿は大きく変わりつつあります。同時に、システムには必ず終わりが訪れるため、その終わり方も運用保守の重要なテーマです。運用を効率化する最新のアプローチと、ライフサイクルの締めくくり方を順に取り上げます。
AIOpsとDevOps/NoOpsの潮流
運用業務にAIを取り入れるAIOpsは、アラートの自動切り分けや障害予兆の検知によって、運用担当者の負荷を大きく軽減します。ただし、いきなりワークフロー全体を刷新すると現場が混乱するため、スモールスタートが鉄則です。まずはアラートの一次切り分けのような小さな業務から導入します。
そのうえで、誤検知のリスクや学習データ整備の手間を見極めながら、範囲を広げていくのが現実的です。さらに、開発と運用を一体化するDevOpsや、クラウドのマネージドサービスを活用して運用作業そのものを極力なくすNoOpsという考え方も広がっています。
これらは保守の人手依存を減らす方向の流れです。また、新規システムの構築時から運用を見据えて設計すると、将来の保守負担を抑えられます。属人化したレガシーシステムについては、AIに既存コードを解析させてブラックボックスを解消する取り組みが進んでいます。
EOL/EOSと保守契約の終わらせ方
システムには必ず寿命があります。製品やOSのサポートが終了（EOL/EOS）すると、セキュリティパッチが提供されなくなり、保守を続けること自体がリスクになります。そのため、このタイミングをあらかじめ把握し、リプレイスやクラウド移行の計画を前倒しで立てておくことが、運用保守の最終局面で欠かせません。
サポート切れのシステムを惰性で使い続けるのは、最も避けたい選択です。保守契約を終了させる際にも、いくつかの落とし穴があります。たとえば、ハードウェア保守でHDDを交換した場合、故障部品の所有権は保守会社に帰属するのが一般的です。
機密データの確実な破棄を求めるなら、別途その旨を契約に盛り込む必要があります。データ移行や契約解除の条件を曖昧にしたまま終えると、後からデータの所在やセキュリティをめぐる問題が残ります。終わり方まで設計してこそ、運用保守は完結します。
システム運用保守で失敗しないためのポイント
ここまで見てきた内容を踏まえ、最後に運用保守で失敗を避けるための要点を整理します。よくある失敗パターンを知っておくだけでも、回避できるトラブルは少なくありません。
属人化・ブラックボックス化への対策
運用保守で最も多い失敗が、特定のキーマンに知識が集中する属人化です。その担当者が突然退職すると、システムの仕様が誰にも分からなくなり、障害対応も改修も止まってしまいます。これを防ぐには、平常時からドキュメントを整え、設定変更や障害対応の履歴を組織として残す習慣が欠かせません。
万一ドキュメントが一切ないままキーマンが抜けてしまった場合は、既存コードや設定から逆引きする、つまりリバースエンジニアリングで仕様を再構築するほかありません。近年は、AIに既存コードを解析させて仕様を可視化する手法も実用化が進み、属人化による崩壊からの復旧コストを下げています。とはいえ、事後対応は高くつくため、属人化は起きる前に防ぐのが鉄則です。
責任分界点とセキュリティの明確化
クラウドを利用している場合、責任共有モデルの理解が欠かせません。AWSやAzureなどのクラウドでは、インフラ側をクラウド事業者が担う一方、アプリケーションやデータの設定はユーザー側の責任です。この責任領域を、自社の情シスが負うのか、保守ベンダーに委託するのかを明確にしておかないと、障害時に責任の押し付け合いが起きます。
役割と責任を整理するには、RACIチャートの作成が有効です。実行者と説明責任者、相談先と報告先を表で可視化しておけば、平常時はもちろん障害時にも迷いがなくなります。
セキュリティ事故や障害時の責任の所在、違約金の条件、免責事項が、ベンダー有利に偏りすぎていないかも、契約段階で必ず確認しておきましょう。
まとめ
運用保守の全体像から発注の方法まで、順に見てきました。さらに、最新トレンドと終わり方、失敗を防ぐポイントにも触れました。
運用保守はソフトウェアコストの約60%を占める長期的な営みです。「運用」と「保守」の切り分けや、SLAによる定量管理は、その土台になります。加えて、契約形態の選択や属人化対策といった一つひとつの判断が、システムの寿命とコストを大きく左右します。
大切なのは、開発の延長として惰性で続けるのではなく、ライフサイクル全体を見据えて運用保守を設計することです。より深く知りたいテーマは、具体的な手順や数字を専門記事で解説しています。自社の状況に合わせて、ぜひ参考にしてください。
各テーマの詳細は、以下の関連記事で確認できます。
- システム運用保守の進め方/やり方/流れや方法/手法/工程/手順
- システム運用保守でおすすめの開発会社/ベンダー6選と選び方
- システム運用保守の見積相場や費用/コスト/値段について
- システム運用保守の発注/外注/依頼/委託方法について
▼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を創業。