業務システムを構築して稼働させた後に必ず発生するのが「運用保守」の業務です。せっかく多額の費用をかけて導入したシステムも、日々の監視やトラブル対応、改修といった運用保守を疎かにすれば、すぐに止まってしまったり、現場で使われなくなったりします。とはいえ、社内に運用保守を担える人材や知見が十分にある企業は多くありません。「何から手をつければよいのか」「自社でやるべきか外注すべきか」と悩む担当者の方は非常に多いのが実情です。
本記事では、システム運用保守の進め方を、内製・外注の判断からベンダー選定、SLA（サービスレベル合意）の設定、引継ぎ、そして定常運用までのライフサイクルに沿って具体的に解説します。ベンダー選定にかかる4〜6か月の標準スケジュールや、保守費用が適正かを見抜く監査の視点、属人化を防ぐドキュメント整備のコツなど、実務で本当に役立つノウハウを数字とともにお伝えします。この記事を読めば、自社のシステム運用保守をどう設計し、どう進めればよいかの全体像がつかめます。
システム運用保守とは何か｜進め方を理解する前提知識
システム運用保守の進め方を考える前に、まず「運用」と「保守」が何を指すのかを正しく整理しておく必要があります。この境界線が曖昧なままだと、後でベンダーと「どこまでが契約範囲か」を巡るトラブルに発展しやすいためです。ここでは運用保守の定義と、業務システムにおける運用保守の特徴を確認します。
「運用」と「保守」の違い
「運用」とは、システムを正常に稼働させ続けるための定常的な業務を指します。具体的には、サーバーやアプリケーションの稼働監視、データのバックアップ取得、アクセス権限の管理、ユーザーからの問い合わせ対応などが含まれます。あらかじめ定められた手順に沿って日々繰り返す、いわばシステムの「健康管理」にあたる業務です。
一方で「保守」とは、障害が発生した際の原因究明と復旧、あるいは法改正や業務変更に伴うプログラムの修正・改修を指します。突発的に発生する「治療」や「機能追加」にあたる業務です。運用が予定された定常業務であるのに対し、保守は非定常的かつ専門性の高い対応が求められる点が大きな違いです。進め方を設計する際には、この両者を分けて業務範囲とコストを定義することが、後のトラブル防止の第一歩になります。
業務システムの運用保守が持つ特徴
販売管理や顧客管理、生産管理といった基幹となる業務システムは、止まると即座に事業へ影響が及ぶため、高い安定稼働が求められます。そのため運用保守においても、障害発生時の復旧速度や、業務時間帯における稼働率の確保が特に重視されます。たとえば自治体のガイドラインでは、サーバ・アプリの稼働率99.8%以上、重大障害は年2回までといった具体的な基準が示されており、業務システムの運用保守がいかに厳密な管理を求められるかが分かります。
また、ソフトウェアのライフサイクル全体で見ると、運用保守コストは決して小さくありません。ソフトウェア全体にかかるコストのうち、運用保守が占める割合は40〜80%、平均で約60%にのぼるとされます。経済産業省の調査でも、従来システムの運用と新規構築への支出割合は全産業平均で約2対1と報告されています。つまり「作って終わり」ではなく、運用保守をどう進めるかが投資全体の成否を左右するのです。
システム運用保守の進め方｜全体の流れと5ステップ
システム運用保守の進め方は、大きく5つのステップに整理できます。①内製か外注かの判断、②要件整理とベンダーへの提案依頼（RFP）、③ベンダーの選定、④SLA設定と業務の引継ぎ、⑤定常運用とPDCAによる改善、という流れです。ここでは各ステップを順を追って解説します。
ステップ1｜内製か外注かを判断する
最初に決めるべきは、運用保守を社内で内製するか、外部のベンダーに委託するかの方針です。判断軸は、社内にインフラやアプリケーションの知識を持つ人材がいるか、24時間365日の監視体制を組めるか、そして運用保守に割けるリソースとコストのバランスがとれているかの3点です。
自社の業務に深く根ざした改修が頻繁に発生する場合は内製に向いていますが、人材の確保と育成にコストがかかります。一方、定型的な監視や一次対応が中心であれば、外注によって人件費の変動費化と専門性の確保を両立できます。多くの企業では、定常的な監視や問い合わせ対応を外注し、業務に直結する改修判断だけを社内に残す、というハイブリッド型が現実的な選択肢となります。
ステップ2｜要件整理とRFPの作成
外注を選んだ場合、次に行うのが運用保守の要件整理と、それを文書化したRFP（提案依頼書）の作成です。RFPには、対象システムの構成、求める作業範囲（監視・バックアップ・障害対応・改修）、対応時間帯、目標とするサービスレベル、そして引継ぎの条件を明記します。ここで要件が曖昧だと、提案を比較する基準がぶれてしまい、適切なベンダーを選べなくなります。
RFPの前段としてRFI（情報提供依頼）で各社の対応領域や実績を集めておくと、提案依頼先の絞り込みがスムーズになります。なお、現行のベンダーがいる場合は、あえてそのベンダーもRFPに参加させることをおすすめします。競争原理が働くことで契約条件が大幅に見直され、結果的に既存ベンダーが30〜40%の確率でより良い条件のまま継続するというケースも珍しくありません。
ステップ3｜ベンダーの評価と選定
提案を受けたら、評価表を用いて各社を客観的に比較します。評価軸は、技術力・実績、対応体制、コスト、SLAへの対応姿勢などです。ここで重要なのが、価格の配点を全体の20点以下に抑えることです。価格の比重を高くしすぎると、品質の低い安価なベンダーが上位に来てしまい、運用保守の質が犠牲になりかねません。
点数の付け方は「○5点・△2点・×0点」のように差が開く配点にすると、評価のブレを防ぎやすくなります。必要に応じて、契約前にPoC（概念実証）として一部業務を試験的に任せ、実際の対応品質を確認するのも有効です。ベンダー選定は全体で4〜6か月かかるのが一般的で、現行契約の満了6か月前には動き出しておくと安心です。
ステップ4｜SLA設定と業務の引継ぎ
委託先が決まったら、SLA（サービスレベル合意）を設定し、業務を引き継ぎます。SLAについては後の章で詳しく解説しますが、稼働率や障害復旧時間といった具体的な数値目標を契約に盛り込むことが肝心です。引継ぎは、いきなり全業務を移すのではなく、現行担当者がサポートしながら段階的に移行するのが安全です。
具体的な体制としては、新しい担当者を1.0人月ほど投入しつつ、現行担当者が週2日程度サポートに入る形が効果的とされています。引継ぎ期間は2か月程度のOJTを設けると、ドキュメント化されていない暗黙知も含めて移転しやすくなります。この引継ぎを丁寧に行うかどうかが、移行後の障害対応スピードに直結します。
ステップ5｜定常運用とPDCAによる改善
引継ぎが完了したら、いよいよ定常運用のフェーズに入ります。ここで終わりではなく、SLAの達成状況を定期的にレビューし、未達があれば原因を分析して改善につなげるSLM（サービスレベル管理）のサイクルを回すことが重要です。月次や四半期ごとに報告会を設け、障害の傾向や問い合わせの内容を共有することで、運用品質を継続的に高められます。
近年では、定型作業の自動化や、生成AIを活用したアラートの一次切り分け（AIOps）といった効率化のアプローチも進んでいます。ただし、いきなり運用全体を刷新すると現場が混乱するため、まずはアラートの自動仕分けのような小さな業務からスモールスタートで導入するのが鉄則です。定常運用のなかで少しずつ効率化を積み重ねていく姿勢が、長期的なコスト最適化につながります。
運用保守の品質を決めるSLAの設計方法
運用保守の品質を契約として担保する仕組みがSLA（サービスレベル合意）です。SLAを曖昧なまま進めると、障害が起きても「どこまでが約束だったのか」が分からず、責任の所在を巡って揉めることになります。ここでは具体的な目標値の設計と、未達時の取り決めについて解説します。
具体的な目標値の決め方
SLAでは、サービスレベルを定量的なKPIに落とし込みます。代表的な指標は、サーバーやアプリケーションの稼働率、障害発生時の応答時間と復旧時間、ヘルプデスクの電話応答率などです。実際の自治体ガイドラインを例にとると、サーバ・アプリの稼働率99.8%以上、基準応答時間の達成率93%（3秒以内）、重大障害は年2回まで、障害通知遵守率100%（発生後30分以内）、ヘルプデスク電話応答率97%以上（平均20秒以内）といった水準が設定されています。
これらの数値は高ければよいというものではありません。稼働率を99.99%まで引き上げるには冗長構成や24時間体制が必要となり、コストが跳ね上がります。自社の業務にとって本当に必要なレベルを見極め、過剰品質を避けながら目標値を設定することが、コストと品質のバランスをとるコツです。業務時間帯と夜間で目標値を分けるなど、メリハリをつけた設計も有効です。
未達時のペナルティ条項と交渉のコツ
SLAを実効性のあるものにするには、目標未達時の取り決めを契約に盛り込む必要があります。具体的には、稼働率が基準を下回った月は保守費用の一定割合を減額する、改善計画の提出を義務づける、といったペナルティ条項です。一方で、ペナルティ一辺倒ではベンダーのモチベーションを下げかねないため、目標を継続的に上回った場合のインセンティブ報酬と組み合わせると、健全な緊張関係を保てます。
ベンダーに厳しめのSLAを受け入れてもらう交渉では、他社の契約事例を材料に提示するのが効果的です。「他社ではこの水準が標準になっている」と示すことで、過度に高い要求ではないことを伝えられます。発注側として、SLAは一度決めたら終わりではなく、運用実績を見ながら毎年見直していく姿勢を持つことが、長期的に良好なパートナーシップを築く鍵となります。
契約形態と費用の妥当性を見極めるポイント
運用保守を進めるうえで、契約形態の選び方と、提示された費用が適正かどうかの見極めは避けて通れません。ここを押さえておかないと、「対象外」「追加費用」を巡るトラブルや、相場より高い保守費用を払い続ける事態に陥ります。契約と費用の両面から実務的なポイントを解説します。
準委任契約と請負契約の使い分け
運用保守の契約は、大きく準委任契約と請負契約に分かれます。準委任契約は、継続的にサービスを提供する形態で、成果物の完成責任を負いません。監視や問い合わせ対応といった、結果よりもプロセスの遂行が求められる業務に適しています。一方、請負契約は明確な成果物の完成を約束する形態で、特定の機能改修やバージョンアップなど、完成物が定義できる業務に向いています。
運用保守は定常的な業務が中心となるため、準委任契約をベースにするケースが一般的です。準委任契約には、印紙税の観点でメリットがある点も見逃せません。保守契約を準委任契約とすると、請負契約に課される収入印紙（第7号文書）が不要になるケースが多く、長期契約ではコスト面でも有利に働きます。契約書には、保守対象範囲、費用と支払い方式、免責事項、契約解除条件を必ず明記し、後の解釈の食い違いを防ぐことが重要です。
保守費用が適正かを見抜く監査の視点
「今払っている保守費用は妥当なのか」という疑問は、多くの担当者が抱えています。相見積もりを取るのが基本ですが、それだけでは見抜けない場合もあります。そこで有効なのが、ベンダーから提出される作業報告書やサーバーログをもとに、実際の稼働時間を算出する監査の視点です。月額の保守費用に対して、実稼働がどれくらいかを照らし合わせれば、費用が適正か割高かをある程度判断できます。
保守費用を理解するうえで知っておきたいのが、保守作業の内訳です。保守作業のなかで最も時間を要するのは「調査・分析」で、全作業時間の約30%を占めるとされています。つまり、改修そのものより、原因を突き止める調査に大きな工数がかかるのです。ドキュメントが整備されていれば調査時間を圧縮でき、結果的に保守費用も抑えられます。日頃から仕様書や障害対応履歴を残しておくことが、費用の妥当性を保つうえでも効いてきます。なお、費用相場の詳しい内訳はシステム運用保守の費用相場を解説した記事でも詳しく扱っています。
属人化・ブラックボックス化を防ぐ進め方の工夫
運用保守で最も恐ろしいのが、特定の担当者しかシステムを理解していない「属人化」と、中身が誰にも分からなくなる「ブラックボックス化」です。キーマンが突然退職すれば、システムの維持自体が危うくなります。進め方の段階から、こうしたリスクを防ぐ仕組みを織り込んでおくことが欠かせません。
ドキュメント整備と運用の標準化
属人化を防ぐ基本は、運用手順書・システム構成図・障害対応履歴といったドキュメントを整備し、常に最新の状態に保つことです。担当者が変わっても同じ品質で運用を引き継げるよう、作業手順を標準化しておきます。ドキュメントが整っていれば、前章で触れたように障害時の調査時間が短縮され、保守費用の抑制にもつながります。
外注する場合も、ベンダー任せにせず、構成情報や対応履歴を発注側でも把握できる状態にしておくことが大切です。ベンダーを切り替える際の引継ぎがスムーズになるだけでなく、特定ベンダーへの過度な依存（ベンダーロックイン）を防ぐ効果もあります。運用の標準化は、長期的な選択肢の自由度を確保する投資と捉えるべきです。
キーマン退職時の緊急対応とAI活用
万が一、ドキュメントが乏しい状態でキーマンが退職してしまった場合は、緊急のサバイバル対応が必要になります。まずは現存するソースコードや設定ファイル、ログを集め、システムの挙動から仕様を逆算するリバースエンジニアリングに取り組みます。優先順位は、業務が止まると致命的な機能から順に解読し、最低限の維持体制を確保することです。
近年は、こうしたレガシーシステムの解読にAIを活用するアプローチも現実的になっています。開発当初の仕様を知るスタッフがいない古いシステムでも、AIに既存コードを解析させることで、ブラックボックス化の解消や省力化を進められます。ただしAIの解析結果は誤りを含む可能性があるため、必ず人の目で検証する前提で活用することが重要です。属人化対策を最初から運用設計に組み込んでおけば、こうした緊急事態そのものを避けられます。詳しい外注のコツはシステム運用保守の外注方法をまとめた記事もあわせてご覧ください。
まとめ｜システム運用保守は設計段階で勝負が決まる
システム運用保守の進め方は、内製・外注の判断から始まり、RFPによる要件整理、評価表を用いたベンダー選定、SLA設定と段階的な引継ぎ、そして定常運用とPDCAによる改善という5つのステップで構成されます。ベンダー選定には4〜6か月かかるため、契約満了の6か月前から動き出すこと、価格の配点を20点以下に抑えて品質を確保することが、失敗しないための要点です。
あわせて、SLAの目標値を自社の業務に合わせて適切に設計し、準委任契約をベースに契約条項を明確化すること、そして作業報告書やログから費用の妥当性を監査する視点を持つことが、運用保守を健全に保つうえで欠かせません。さらに、ドキュメント整備による属人化対策を最初から織り込んでおけば、キーマン退職といった緊急事態のリスクも大きく減らせます。運用保守は「作った後の付随業務」ではなく、システム投資全体の成否を左右する重要な工程です。本記事を参考に、自社に最適な運用保守の進め方を設計してみてください。
システム運用保守の各テーマについては、運用保守のおすすめ会社を比較した記事や、全体像を網羅したシステム運用保守の完全ガイドでも詳しく解説しています。自社の状況に合わせて、ぜひ参考にしてください。
株式会社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を創業。