ソフトウェアは稼働させ続けてこそ価値を生むため、運用保守は、計画、日常運用、改修対応へと進み、評価・改善で見直すサイクルで回すのが基本です。
運用保守コストは、ライフサイクル全体の40〜80%（平均60%）を占めるとされ、進め方が投資の成否を左右します。そこで、運用と保守の違いから工程ごとの進め方、ライフサイクルの終わりまでを、順に押さえていきます。
- 運用と保守の区別、保守の4分類の全体像
- 計画立案、体制構築、日常運用の進め方
- 改修対応と工数見積り、品質管理
- ライフサイクル終焉とレガシー化への備え
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
ソフトウェア運用保守の全体像と4つの分類
ソフトウェア運用保守を進めるうえで最初に押さえたいのが、「運用」と「保守」の区別、そして「保守」が4種類に分かれるという考え方です。
ここを曖昧にしたまま体制を組むと、対応範囲や費用負担をめぐる認識がずれ、後のトラブルにつながります。まずは全体像を整理します。
「運用」と「保守」の違い
運用とは、日々ルーティンとして発生する、ソフトウェアを正常に動かし続けるための定常業務を指します。具体的には、稼働監視やログの確認、データのバックアップを行います。アクセス権限の管理やユーザーからの問い合わせ対応も、運用に含まれます。
一方で、保守とは、ソフトウェア本体に手を加える作業を指します。バグが見つかったときの原因究明と修正、OSやミドルウェアの変更への調整、機能追加や性能改善といった改修が、これにあたります。
運用が「現状維持」であるのに対し、保守は「ソフトウェアを変更する」点で決定的に異なります。だからこそ、この区別を契約書や保守範囲の取り決めに明記しておくことが、後の費用トラブルを避ける第一歩となります。
保守の4分類（是正・適応・完全化・予防）
ソフトウェア保守は、国際規格ISO/IEC 14764で4つのタイプに分類されています。この分類を理解しておくと、保守作業の優先度や費用配分を判断しやすくなります。
1. 是正保守：発見されたバグや障害を修正します。最もイメージされやすい作業ですが、保守全体では一部です。
2. 適応保守：OSの更新、法改正、外部サービスのAPI変更など、環境の変化に合わせて改修します。
3. 完全化保守：性能改善、使い勝手の向上、軽微な機能追加など、より良くするための改善です。
4. 予防保守：将来の不具合を未然に防ぐ保守で、コードの整理（リファクタリング）や脆弱性対策などです。
調査によると、保守作業全体で「是正（バグ修正）」が占める割合は意外に小さく、適応・完全化といった「変化への対応」や「改善」のほうが大きな比重を占めるとされています。ただし、是正保守だけを想定して予算や体制を組むと、環境変化への対応が後手に回り、ソフトウェアの陳腐化を早めてしまうおそれがあるため、注意が必要です。
ソフトウェア運用保守の進め方・全体の流れ
ソフトウェア運用保守は、計画を立てたうえで日常運用と改修対応を回し、評価・改善の結果を次の計画に反映させるサイクルで進めるのが基本です。
ここでは、運用保守を始める段階から定常運用に乗せるまでの工程を、手順に沿って説明します。
ステップ1：保守計画と体制の策定
最初の工程は、保守対象の範囲を明確にし、体制を策定することです。発注側と開発会社は、どのソフトウェアやモジュールを保守対象とするかを決めます。さらに、稼働率や応答時間といった品質目標（SLA）と、障害発生時の連絡体制や対応時間も定めます。
ここが曖昧だと、「これは保守対象に含まれるのか」という議論が後から必ず起きます。体制面では、内製で対応するか、外部ベンダーに委託するかを判断します。
社内に該当ソフトウェアの知見を持つエンジニアがいない場合や、是正保守の頻度が読めない場合は、外部委託も含めて検討する価値があります。委託する進め方は、ソフトウェア運用保守の発注・外注・委託方法で詳しく解説しています。
ステップ2：日常運用と監視の実施
計画と体制が整ったら、日常運用に入ります。この段階の中心は監視で、ソフトウェアが想定どおり稼働しているか、エラーログに異常がないか、レスポンスが遅れていないかを継続的に確認します。
近年は、ZabbixやDatadogといった監視ツールを使い、しきい値を超えたら自動でアラートを通知する仕組みを組むのが一般的です。定期的なバックアップやセキュリティパッチの適用、ユーザーからの問い合わせ対応も、日常運用に含まれます。
特に大切なのは、対応したインシデントや変更を必ず記録に残すことです。「いつ、何が起きて、どう対処したか」を蓄積しておけば、後の原因分析やナレッジ化に生かせるほか、ブラックボックス化の防止にもつながります。
ステップ3：改修対応とリリース管理
バグ修正や機能改善といった改修が必要になったら、改修対応に進みます。まず影響範囲を調べ、改修方針を決めます。そのうえで実装とテストを行い、リリースへ進みます。
特に重要なのが最初の「調査・分析」です。保守作業全体で最も時間を要する工程で、ある調査では、保守作業時間の約30%が調査・分析に費やされるとされています。
改修を本番に反映する際は、テスト環境で必ず動作を確認します。問題があればすぐ元に戻せるよう、ロールバック手順（元の状態へ戻す手順）も用意しておきます。改修が並行する場合は、変更履歴とバージョンを管理し、どの改修がどのリリースに含まれるかを追跡できる状態を保つことが、品質維持の鍵となります。
改修工数の見積りと費用の考え方
ソフトウェア運用保守の進め方を考えるうえで避けて通れないのが、改修工数の見積りです。新規開発と違い、既存のコードに手を入れる保守は、コードの状態に大きく左右されるため、見積りに独特の難しさがあります。
ここでは、見積りの考え方と、費用の妥当性を見極める視点を説明します。
改修見積りの3つの変動要因
改修の工数は、「何行直すか」だけでなく、3つの観点を組み合わせて見積もる手法が知られています。変更の密度、箇所の散らばり、担当者の熟知度の3つです。
・改造密度：一定のコード量あたり、どれだけの量を変更するかです。変更が密集しているほど、影響範囲の確認に手間がかかります。
・改造分散度：改修箇所が何ヶ所に散らばっているかです。1ヶ所にまとまっているか、ファイルをまたいで分散しているかで、難易度が変わります。
・改造母体錬度：担当エンジニアが改修対象のソフトウェアをどれだけ熟知しているかです。経験や習熟度が高いほど、工数は下がります。
たとえば、同じ機能追加でも、ドキュメントが整備され担当者が中身を熟知しているソフトウェアと、誰も全体像を把握していないソフトウェアとでは、必要な工数が数倍変わることも珍しくありません。見積りを依頼する側も、この3要素を意識して自社ソフトの状態を開発会社に伝えると、見積りの精度が上がりやすくなります。
保守費用の妥当性の見極め
毎月支払っている保守費用が適正かどうか、判断に迷う担当者は少なくありません。相見積もりを取るのが基本ですが、ほかにも妥当性を見極める方法があります。
ベンダーから出される作業報告書とサーバーログを照合して、実際にどれだけの作業時間が発生しているかを算出すれば、月額固定費が実態と合っているかを検証できます。
ソフトウェア全体のコストに占める保守費用の割合は40〜80%（平均60%）にのぼるとされ、ライフサイクル全体で見れば開発費を上回る大きな支出です。だからこそ、保守費用の内訳を一覧にして定期的に妥当性を点検することが、トータルコストを適正に保つことにつながります。費用の構造や相場は、ソフトウェア運用保守の費用相場でさらに詳しく解説しています。
属人化・レガシー化を防ぐ運用保守の工夫
ソフトウェア運用保守における最大のリスクは、特定の担当者しか中身を理解していない「属人化」と、古い技術で組まれて誰も手を出せなくなる「レガシー化」です。
進め方のなかに属人化とレガシー化を防ぐ仕組みを組み込めるかどうかが、長期的な保守性を左右します。
ドキュメント整備とナレッジ共有
属人化を防ぐ最も基本的な対策は、ドキュメントを整備することです。システム構成図や改修履歴、運用手順書をまとめておけば、担当者が交代しても保守を続けられます。よくある障害とその対処法も残しておくと役立ちます。
予防保守の一環として、コードの可読性を保つリファクタリングを行い、その理由を記録に残す習慣を持つと効果的です。
ナレッジ共有では、インシデント対応のたびに記録を残し、チーム内で振り返る運用を定着させるのがおすすめです。「あの障害はあの人しか直せない」という状態を作らないことが、安定した運用保守の前提です。
キーマン退職時のサバイバル術
ドキュメントが整備されないまま唯一の開発者が突然退職するケースは、現実に起こります。こうした緊急事態では、まず動いているソフトウェアを止めないことを最優先にします。そのうえで、現存するソースコード、設定ファイル、ログから仕様を逆算する「リバースエンジニアリング」を進めます。
動作を観察しながら入出力の関係を整理し、少しずつ全体像を再構築していく地道な作業です。近年は、この解読作業を生成AIに補助させるアプローチも現実的になってきました。たとえば、既存コードをAIに読み込ませ、処理内容の要約や依存関係の洗い出しを任せることで、ブラックボックス化したソフトウェアの解析を大幅に省力化できます。
ただし、AIの出力は鵜呑みにせず、必ず実機の挙動と突き合わせて検証することが前提です。こうした緊急対応を迫られる前に、日頃から属人化を防ぐ仕組みを整えておくことが何より大切です。
運用保守を成功させるためのポイント
ここまで進め方の工程を見てきました。最後に、運用保守を続けて成功させるための実務的なポイントを整理します。鍵になるのは、仕組みづくりと、ライフサイクルの終わりを見据えた準備です。
SLAによる品質の定量管理
運用保守の品質を「なんとなく良い・悪い」で評価していては、改善の方向性が定まりません。そこで、サービスレベル合意（SLA）として、稼働率や障害復旧時間、問い合わせへの応答時間といった指標を数値で定義し、定期的に達成状況を振り返る運用が効果的です。
たとえば公共分野のガイドラインでは、稼働率99.8%以上、障害発生後30分以内の通知遵守率100%といった具体値が示されています。こうした指標を設定し、未達があれば原因を分析して次の改善につなげるPDCAを回すことで、運用保守は「守りの作業」から「継続的に価値を高める活動」へと変わります。
外部委託する場合は、SLAを契約に組み込み、達成状況を月次でレビューする体制を整えておくと安心です。
EOL/EOSを見据えた終焉計画
ソフトウェアには寿命があります。利用している言語やフレームワーク、ミドルウェアがサポート終了（EOL/EOS）を迎えると、セキュリティ更新が止まり、運用保守を続けること自体がリスクになります。
進め方の計画段階から、いつごろリプレイスや刷新が必要になるかを見据えておくと、行き当たりばったりの延命を避けられます。
ライフサイクルの終わりが近づいたら、データ移行、旧システムの安全な停止、保守契約の終了を計画的に進めます。保守を「始める」だけでなく「きれいに終わらせる」ところまで設計しておくことが、次のシステムへスムーズに移行するための土台となります。進め方全体を俯瞰したい方は、ソフトウェア運用保守の完全ガイドも参考になります。
まとめ
ソフトウェア運用保守は、「運用」と「保守」の区別を押さえ、保守を是正・適応・完全化・予防の4つに整理して捉えることから始まります。
進め方は、保守計画と体制の策定、日常運用と監視、改修対応とリリース管理を、サイクルとして回すことが基本です。改修工数は改造密度・分散度・母体錬度の3つの観点で見積もり、属人化やレガシー化を防ぐ仕組みも組み込んでいきます。
ソフトウェアコストの平均60%を占める運用保守だからこそ、SLAによる定量管理と、EOL/EOSを見据えた終焉計画まで含めて、ライフサイクル全体を設計することが大切です。それが、長く安定して価値を生み出す鍵となります。
この記事で紹介した進め方を、自社のソフトウェア運用保守体制を見直すきっかけにしていただければ幸いです。費用や発注方法について、さらに具体的に検討したい方は、関連記事もぜひ参考にしてください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。