システムやソフトウェアを開発したあと、本当の意味で予算と工数がかかるのは「運用保守」のフェーズです。ソフトウェア全体のライフサイクルコストのうち、実に40〜80%（平均で約60%）が運用保守に費やされるという調査結果もあり、運用保守をどう進めるかは事業の収益性そのものを左右します。それにもかかわらず「とりあえず開発したベンダーにそのままお願いしている」「請求書の金額が妥当かどうか分からない」という状態で、なんとなく続けてしまっている企業は少なくありません。
この記事では、運用保守の進め方を「運用と保守の違いの整理」から「内製か外注かの判断」「ベンダー選定とSLA設定」「引き継ぎと定常運用」までの一連の流れとして体系的に解説します。あわせて、保守費用が適正かを相見積もり以外で見抜く監査の視点、SLAのペナルティ条項をベンダーにのませる交渉のコツ、キーマンが突然退職してブラックボックス化したときの緊急対応など、現場で本当に困るポイントにも踏み込みます。読み終えるころには、自社の運用保守を「なんとなく」から「設計されたプロセス」へと切り替えるための具体的な手順が見えているはずです。
運用保守の全体像と進め方の前提
運用保守の進め方を考える前に、まず「運用」と「保守」が別の業務であることを正しく分けて理解しておく必要があります。この区別が曖昧なまま契約してしまうと、後から「それは契約範囲外です」「追加費用が必要です」というトラブルに発展しやすくなります。ここでは運用と保守の定義を整理したうえで、進め方全体のロードマップを示します。
「運用」と「保守」の違いを正しく分ける
運用とは、システムを正常に稼働させ続けるための定常的な業務を指します。具体的には、サーバーやネットワークの稼働監視、データのバックアップ、アクセス権限の管理、ユーザーからの問い合わせ対応などが該当します。あらかじめ決められた手順に沿って、システムが止まらないように日々まわしていく仕事だと考えると分かりやすいでしょう。
一方の保守とは、障害が発生したときの原因究明と復旧、あるいは法改正や業務変更にともなうプログラムの改修・アップデートを指します。運用が「平常時を維持する仕事」だとすれば、保守は「異常への対応と変化への追従」を担う仕事です。両者は連続していますが性質が異なり、契約形態も保証すべきレベルも変わってきます。進め方を設計する第一歩は、自社のシステムに必要な運用業務と保守業務をそれぞれリストアップし、どこまでを社内で、どこからを外部に任せるかを線引きすることにあります。
進め方の全体ロードマップ
運用保守を立ち上げる、あるいは見直す際の進め方は、大きく5つのステップに整理できます。第1に運用保守の対象範囲と業務内容を棚卸しすること、第2に内製と外注のどちらで担うかを判断すること、第3に外注する場合はベンダーを選定すること、第4にSLA（サービスレベル合意）を設定して品質を定量化すること、第5に既存担当者から新体制への引き継ぎを行い定常運用へ移行することです。
注意したいのは、これらの工程には相応の時間がかかる点です。特にベンダーを切り替える場合、要件整理から選定、契約までで一般的に4〜6ヶ月を要します。現行契約の満了が近いなら、満了の6ヶ月前には動き出さなければ、慌てて不利な条件で更新する羽目になりかねません。進め方を考える時点で、逆算したスケジュールを引いておくことが成功の前提になります。
ステップ1・2：範囲の棚卸しと内製・外注の判断
進め方の最初の実務は、運用保守の対象範囲を明確にし、それを社内で担うのか外部に委託するのかを決めることです。ここでの判断を曖昧にすると、後のベンダー選定もSLA設計も土台が定まらず、結局「言われたことだけやってもらう」受け身の保守に陥ります。範囲の棚卸しと内製・外注判断を丁寧に行うことが、運用保守全体の質を決めます。
対象範囲を棚卸ししてグレーゾーンを潰す
対象範囲の棚卸しでは、監視・バックアップ・障害対応・改修といった業務を具体的な作業レベルまで分解します。たとえば「障害対応」とひとことで言っても、一次切り分けまでなのか、原因調査と恒久対策まで含むのか、対応する時間帯は平日日中だけか24時間365日かで、業務量も費用もまったく異なります。保守作業のなかで最も時間を要するのは「調査・分析」で、全作業時間の約30%を占めるとされており、ここが範囲に含まれるかどうかは見積もりに大きく響きます。
棚卸しの際は、特に「どちらが担当か曖昧になりがちなグレーゾーン」を意識的に洗い出してください。バージョンアップ作業、軽微な仕様変更、問い合わせ調査の工数などは、契約書に明記されていないと後から追加費用の火種になります。この段階で範囲を文書化しておくことが、後のトラブルを未然に防ぎます。
内製か外注かを判断する軸
内製と外注の判断は、コストだけでなく「自社にノウハウを残すべき領域かどうか」で考えると失敗しにくくなります。事業の中核に直結し、頻繁に改修が発生する部分は、内製または準内製的な体制でノウハウを社内に蓄積するほうが長期的に有利です。逆に、定型的な監視やインフラの一次対応など、専門人材を24時間張り付けるとコストがかさむ業務は、外部に委託したほうが効率的です。
判断のもう一つの軸が、属人化のリスクです。社内の特定担当者しか分からない状態で運用を続けていると、その人が退職した瞬間にシステムが維持できなくなる危険があります。外注はこの属人化を解消する手段にもなりますが、丸投げにすると今度はベンダー依存という別の属人化を生みます。どの業務を外に出し、どの知見を社内に残すかをセットで設計することが大切です。なお、対象システムの性質ごとの運用保守の進め方をさらに詳しく知りたい場合は、システム運用保守の進め方もあわせて参考にしてください。
ステップ3：ベンダー選定の進め方
外注すると決めたら、次は適切なベンダーを選ぶ工程に入ります。運用保守は数年単位で付き合うことになるため、価格の安さだけで決めると後悔します。情報提供依頼（RFI）から提案依頼（RFP）、評価表による比較という王道のプロセスを踏み、品質と価格のバランスを定量的に評価することが進め方の肝になります。
RFI・RFPから評価表までの流れ
選定はまず候補ベンダーへのRFI（情報提供依頼）で各社の実績や体制を把握し、絞り込んだうえでRFP（提案依頼書）を提示します。RFPには棚卸しした保守対象範囲、求めるサービスレベル、報告体制などを具体的に記載し、各社から比較可能な提案を引き出します。提案を受け取ったら、技術力・体制・コスト・SLA遵守姿勢などの評価軸を表にし、点数で比較します。
評価表づくりにはコツがあります。価格の配点を20点以下に抑えると、安さだけで品質の低いベンダーが上位に来るのを防げます。また点数付けは「○は5点・△は2点・×は0点」のように差を開かせると、評価者によるブレが減り、本当に優れた提案が浮かび上がります。なお、いま契約している既存ベンダーをあえてRFPに参加させると競争原理が働き、契約条件を大幅に見直したうえで既存ベンダーが継続するケースが30〜40%の確率で起こるとも言われ、必ずしも乗り換えが正解とは限りません。
準委任契約と請負契約の使い分け
ベンダーが決まったら契約形態を選びます。運用保守では準委任契約と請負契約のどちらか、あるいは両者を組み合わせて使うのが一般的です。準委任契約は監視や問い合わせ対応のように、成果物の完成ではなく継続的なサービス提供を約束するものです。一方の請負契約は、明確な成果物の完成に責任を負う形態で、機能改修やバージョンアップ作業など「何を作るか」が定まっている業務に向きます。
契約形態の選び方には、コスト面で見落とされがちなメリットもあります。保守契約を準委任契約とすると、印紙税法上の第7号文書に該当して収入印紙が不要になるケースが多く、請負契約に比べて事務負担が軽くなることがあります。どちらの契約にするかは、業務の性質と費用、責任の範囲を踏まえて判断してください。発注の進め方や契約実務をさらに掘り下げたい場合は、運用保守の発注・外注方法で詳しく解説しています。
ステップ4：SLA設計と交渉の進め方
運用保守の品質を「なんとなく頑張ってもらう」状態から脱却させる鍵が、SLA（サービスレベル合意）です。稼働率や障害復旧時間といった指標を数値で約束させ、達成状況を定期的に確認することで、サービス品質を客観的に管理できるようになります。ここではSLAの具体的な設定項目と、ベンダーに実効性のある条項をのませる交渉の進め方を解説します。
SLAに盛り込む具体的な指標
SLAで定める指標は、自社の業務影響度に合わせて設定します。参考になるのが大阪市のシステム調達ガイドラインで示された水準で、サーバー・アプリケーションの稼働率99.8%以上、基準応答時間の達成率93%（3秒以内）、重大障害は年2回まで、障害通知遵守率100%（発生後30分以内に通知）、ヘルプデスクの電話応答率97%以上（平均20秒以内）といった具体値が公開されています。これらをそのまま自社に当てはめる必要はありませんが、目標値を決める際の現実的なベンチマークとして役立ちます。
指標を決めるときは、達成すべき「目標値」と、最低限守るべき「保証値」を分けて設定し、保証値を下回った場合にどう対応するかまで決めておきます。さらに、目標未達が続いた際に改善勧告や是正を求めるサービスレベル管理（SLM）の仕組みをルール化しておくと、SLAが形骸化せず実際の品質改善につながります。
ペナルティ条項をのませる交渉のコツ
SLAに目標値を書いても、未達のときに何のペナルティもなければベンダーは本気で守りません。実効性を持たせるには、未達時に保守費用の一部を減額する、といったペナルティ条項を契約に盛り込むことが有効です。ただしベンダー側は当然これを嫌がるため、交渉にはコツが要ります。
一つは、ペナルティ（減額）と同時にインセンティブ（目標を大きく上回った場合の報奨）をセットで提示することです。罰だけでなく報いる仕組みを併せて示すと、ベンダーも前向きに受け入れやすくなります。もう一つは、他社が同様のペナルティ条項を受け入れている事例を交渉材料にすることです。「他社さんではこの条件で契約できている」と示すと、特別に厳しい要求ではないと理解してもらいやすくなります。最初から完璧な条項を求めるのではなく、まずは軽微なペナルティから合意し、契約更新のたびに精緻化していく進め方も現実的です。
ステップ5：引き継ぎと定常運用への移行
ベンダーと契約しSLAを定めても、現行担当者から新体制への引き継ぎが雑だと、移行直後に障害対応が滞るリスクがあります。運用保守の進め方の最後の山場が、この引き継ぎと定常運用への移行です。ここを丁寧に設計できるかどうかで、移行後の安定度が大きく変わります。
引き継ぎ期間と体制の組み方
引き継ぎは一度の説明会で済ませようとせず、一定期間のOJTを組むのが鉄則です。目安としては、新担当の工数を1.0人月程度確保しつつ、現行担当者には週2日程度のサポートに入ってもらう体制が効果的とされています。最初の数週間は現行担当が主導し、徐々に新担当へ実務を移していく形で、2ヶ月ほどかけて段階的に引き継ぐと、知見の取りこぼしを防げます。
移行コストの見落としにも注意が必要です。新ベンダーの月額が現行より安く見えても、移行作業に300〜500万円かかるなら、5年間のトータルコスト（TCO）では逆転してしまうこともあります。引き継ぎ計画を立てる段階で、移行に要する一時費用まで含めて比較することが、進め方として欠かせません。
属人化崩壊への緊急対応も想定しておく
進め方を考えるうえで、最悪のシナリオも想定しておくと安心です。ドキュメントがほとんどない状態でキーマンが突然退職し、システムがブラックボックス化してしまったとき、明日からどう維持するかという緊急対応です。まずは稼働中のシステムを止めない措置を最優先し、設定ファイルやログ、データベース構造から仕様を逆算するリバースエンジニアリングで、現状を解読していくことになります。
近年は、こうした解読作業にAIを活用する動きも広がっています。古いソースコードをAIに解析させ、処理の流れや仕様の推定を省力化するアプローチです。ただしAIの出力は誤りを含むため、必ず人による検証とセットで使う必要があります。いずれにせよ、こうした緊急事態を起こさないために、平常時からドキュメントを整備し、特定個人に依存しない運用体制を作っておくことが、最も確実な備えになります。
運用保守費用の妥当性を監査する進め方
運用保守を続けるうえで、多くの担当者が抱える本音の悩みが「今払っている保守費用は適正なのか」という疑問です。相見積もりを取れば比較はできますが、それだけでは現契約が割高かどうかは見抜けません。ここでは、契約を続けながら費用の妥当性を内側から監査する進め方を紹介します。
作業報告書とログから実稼働を割り出す
費用監査の基本は、ベンダーが提出する月次の作業報告書を鵜呑みにせず、実際にどれだけの工数が発生しているかを裏付けデータから検証することです。サーバーのアクセスログや作業ログを確認すれば、保守作業が実際に行われた時間帯や頻度がある程度わかります。報告書に記載された工数と実稼働の乖離が大きい場合、固定の保守費用に対して実作業が見合っていない可能性を疑う材料になります。
こうしたITデューデリジェンス的な視点を持つだけで、ベンダーとの料金交渉の場で具体的な根拠を示せるようになります。「最近、障害も改修もほとんど発生していないのに、固定費が当初と同額なのはなぜか」と、データに基づいて問いかけられれば、減額交渉も感情論ではなく事実ベースで進められます。費用の内訳や相場観をさらに詳しく知りたい場合は、運用保守の費用・相場で構造を解説しています。
契約書に潜む見落としやすい落とし穴
費用の妥当性を考えるとき、契約書に潜む細かな条項にも目を向けておきたいところです。たとえばハードウェア保守では、故障したHDD（ハードディスク）を交換した際、外した故障部品の所有権は保守会社に帰属するのが一般的です。機密データが入った媒体を確実に破棄してほしい場合は、別途その旨を契約で取り決めておかないと、データが手元を離れてしまうことになります。
このほか、免責事項がベンダー有利になりすぎていないか、保守対象範囲・追加費用の発生条件・契約解除条件が明確に書かれているかも確認すべきポイントです。これらの記載が曖昧だと、いざ障害やセキュリティ事故が起きたときに責任の所在で揉めます。費用が適正かどうかは、月額の数字だけでなく、こうした契約条項を含めた総合的な視点で監査することが、賢い運用保守の進め方と言えます。
まとめ
運用保守の進め方は、運用と保守の違いを正しく分けるところから始まり、対象範囲の棚卸し、内製・外注の判断、ベンダー選定、SLAの設計と交渉、引き継ぎと定常運用への移行という流れで体系化できます。ソフトウェアのライフサイクルコストの約60%を占める運用保守だからこそ、各工程を「なんとなく」で済ませず、設計されたプロセスとして進めることが、コストと品質の両面で大きな差を生みます。
特に、SLAにペナルティ条項をのませる交渉、作業報告書とログから実稼働を割り出す費用監査、HDD所有権や免責事項といった契約の落とし穴への目配りは、他社が見落としがちでありながら効果の大きいポイントです。あわせて、属人化崩壊という最悪のシナリオを想定し、平常時からドキュメント整備と脱・属人化を進めておくことが、安定した運用保守の土台になります。本記事の進め方を一つずつ実践し、自社にとって最適な運用保守体制を築いてください。なお、運用保守の全体像を改めて俯瞰したい場合は、運用保守の完全ガイドもご活用ください。
株式会社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を創業。