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