運用保守は、運用と保守の違いの整理から始め、内製か外注かの判断、ベンダー選定とSLA設定、引き継ぎと定常運用への移行の順に進めます。
開発後に本当の意味で予算と工数がかかるのは運用保守で、ライフサイクルコストの40〜80%（平均で約60%）を占めるという調査もあります。それにもかかわらず、「とりあえず開発したベンダーにそのままお願いしている」「請求書の金額が妥当かどうか分からない」という状態で、なんとなく続けてしまっている企業は少なくありません。
「運用」と「保守」の違いの整理
運用とは、システムを正常に稼働させ続けるための定常的な業務を指します。具体的には、サーバーやネットワークの稼働監視、データのバックアップ、アクセス権限の管理、ユーザーからの問い合わせ対応などが該当します。決められた手順に沿って、システムが止まらないように日々まわしていく仕事と考えると分かりやすいでしょう。
一方の保守とは、障害時の原因究明と復旧、あるいは法改正や業務変更にともなうプログラムの改修・アップデートを指します。運用が平常時を維持する仕事なら、保守は異常への対応と変化への追従を担う仕事です。両者は連続していますが性質が異なるため、契約形態も保証すべきレベルも変わってきます。
進め方を組み立てる第一歩は、自社のシステムに必要な運用業務と保守業務を書き出し、どこまでを社内で担い、どこからを外部に任せるかを線引きすることです。この線引きが、以降の工程の前提になります。
進め方の全体ロードマップ
運用保守を立ち上げる、または見直すときは、次の5つのステップに整理して進めます。
- 運用保守の対象範囲と業務内容を洗い出す
- 内製と外注のどちらで担うかを判断する
- 外注する場合はベンダーを選定する
- SLA（サービスレベル合意）を設定して品質を数値で定める
- 既存担当者から新体制へ引き継ぎ、定常運用へ移行する
工程ごとに相応の時間がかかるため、早めに日程を組んでおくことが欠かせません。特にベンダーを切り替える場合、要件整理から選定、契約までに一般的に4〜6ヶ月を要します。
現行契約の満了が近いなら、満了の6ヶ月前には動き出しておく必要があります。そうしなければ、慌てて不利な条件で更新することになりかねません。進め方を考える時点で逆算した日程を引いておくことが、うまく進めるための前提になります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ステップ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で定める指標は、自社の業務影響度に合わせて設定します。参考になるのが、大阪市のシステム調達ガイドラインで公開されている具体的な水準です。サーバー・アプリケーションの稼働率は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（ハードディスク）を交換した際、外した故障部品の所有権は保守会社に帰属するのが一般的です。
機密データが入った媒体を確実に破棄してほしい場合は、その旨を別途契約で取り決めておかないと、データが手元を離れてしまいます。このほか、免責事項がベンダー有利になりすぎていないか、保守対象範囲・追加費用の発生条件・契約解除条件が明確に書かれているかも確認すべき点です。
これらの記載が曖昧だと、いざ障害やセキュリティ事故が起きたときに、責任の所在で揉めることになります。費用が適正かどうかは月額の数字だけでなく、こうした契約条項も含めた総合的な視点で監査することが、賢い運用保守の進め方と言えます。
まとめ
運用保守の進め方は、運用と保守の違いを押さえ、対象範囲を洗い出すところから始まります。そのうえで、内製と外注の判断、ベンダー選定へと進みます。残りの工程は、前に挙げた5つのステップの順に進めます。ソフトウェアのライフサイクルコストの約60%を占める運用保守だからこそ、各工程を「なんとなく」で済ませず、設計されたプロセスとして進めることが、コストと品質の両面で大きな差を生みます。
特に、SLAへのペナルティ条項の交渉、作業報告書とログによる費用監査、HDD所有権や免責事項といった契約の落とし穴への目配りは、他社が見落としがちでありながら効果の大きいポイントです。あわせて、属人化崩壊という最悪のシナリオを想定し、平常時からドキュメント整備と脱・属人化を進めておくことが、安定した運用保守の土台になります。
自社の状況に合わせて本記事の進め方を一つずつ実践し、運用保守の体制を築いてください。なお、運用保守の全体像を改めて俯瞰したい場合は、運用保守の完全ガイドもご活用ください。
▼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を創業。