開発が終わってからが、本当のスタートです。ITシステムの保守管理は、保守の種類を理解し、年間保守計画に落とし込み、工程と体制を決めて進めます。
保守管理は、是正・予防・適応・完全化を使い分けて、年間を通じて計画的に行う仕事です。場当たり的な対応を続けると、障害が頻発し、コストが膨らみ、担当者が疲弊します。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム保守管理の全体像と保守の種類
ITシステム保守管理を正しく進めるには、まず「保守」が指す業務の幅を整理することが欠かせません。保守管理は、単なる障害修理ではなく、システムの価値を保ち、変化する環境に合わせ続けるための継続的な活動です。そこで、保守業務の分類と運用との違いを整理し、全体像をつかんでおきます。
保守の4分類（是正・予防・適応・完全化）
ソフトウェア保守の国際規格であるISO/IEC 14764では、保守業務を大きく4つのタイプに分けています。自社の保守作業がどのタイプに当たるかを切り分けておくと、計画や見積もりの精度を高められます。
①是正保守（修正保守）：すでに発生したバグや障害を直す、最も一般的な保守です。
②予防保守：将来起こりうる潜在的な不具合を、表面化する前に見つけて手を打つ保守です。
③適応保守：OSのバージョンアップや法改正、税率変更など、外部環境の変化にシステムを合わせる保守です。
④完全化保守：性能改善や保守性の向上など、システムをより良くするための保守です。
- 是正保守：発生したバグや障害の修正
- 予防保守：潜在的な不具合の事前発見と対処
- 適応保守・完全化保守：環境変化への対応と性能改善
多くの現場では是正保守に追われがちですが、コストを下げる鍵を握るのは、本来、予防保守と完全化保守です。障害が起きてから直す是正保守は緊急対応になるため、工数も精神的な負担も大きくなります。したがって、計画的な予防保守へ移るほど、全体のコストは安定していきます。
適応保守は見落とされやすいものの、消費税率の変更やインボイス制度への対応のように、放置すると業務が止まる重大な領域です。
第5の保守「予測保守」と運用との違い
近年は、前述の4分類に「予測保守」を加えた5分類で語られることが増えています。予測保守とは、システムから収集したログやメトリクスをAIやデータ分析で解析し、障害が起こる兆候を事前に察知して対処する手法です。
ただし、規格上は予防保守に内包される概念で、機械学習やデータアナリティクスの発展により、実務では独立した技術領域として扱われるようになっています。たとえば、ディスク使用率の異常な伸びやレスポンスタイムのわずかな悪化を早期に捉え、深夜の障害を未然に防ぐといった取り組みが現実になっています。
ここで押さえたいのが「保守」と「運用」の違いで、運用は、監視、バックアップ、定時バッチ処理、アカウント管理など、システムを現状のまま動かし続ける定常業務を指します。一方の保守は、障害修正やプログラム改修、ハードウェア交換など、システムそのものに手を加える変更業務です。そのため、契約書や仕様書で「どこまでが運用で、どこからが保守か」を明文化しておくと、責任の押し付け合いを防げます。
ITシステム保守管理の進め方と年間保守計画
保守管理を「依頼が来てから動く」受け身の体制で続けると、対応にばらつきが出て、属人化も避けられません。そのため、保守の種類を踏まえて年間を通じた計画に落とし込むことが、安定したシステム運営の土台になります。年間保守計画の組み立て方と、優先順位の付け方を順に見ていきます。
年間保守計画の立て方
年間保守計画は、定期的に発生する保守と、突発的に発生する保守を分けて設計します。定期保守には、サーバーやミドルウェアのアップデート、セキュリティパッチの適用、ハードウェアの点検、バックアップデータのリストアテストなどが含まれます。これらは、あらかじめ実施月を決めておくことで、業務への影響が少ない時期に集中させられます。
実際、官公庁の維持管理業務委託仕様書では、「定期保守は原則年1回12月」「定期報告は年4回（3月・6月・9月・12月末）」といった具体的な頻度を定めている例があります。こうした公的仕様は、自社の保守スケジュールを組むときの良い物差しになります。計画づくりの最初のステップは、対象システムを洗い出すことです。
資産台帳には、稼働しているサーバー、アプリケーション、ミドルウェアを整理し、サポート期限やライセンス更新時期を一覧にします。次に、過去の障害履歴から、どの時期にどんなトラブルが起きやすいかの傾向をつかみます。これらをカレンダーに落とし込み、適応保守（法改正・OS更新）、予防保守の点検、完全化保守の改善テーマを年間スケジュールに書き込みます。
保守タスクの優先順位付けと体制設計
保守タスクは、業務影響度と緊急度の2軸で優先順位を付けるのが基本です。たとえば、売上に直結する基幹システムは最優先で復旧目標時間を厳しく設定する一方、社内向けの参照系システムは、ある程度の遅延を許容して対応レベルを下げ、コストを抑えます。すべてのシステムに同じ手厚さを求めると、保守費用は際限なく膨らんでしまいます。
そのため、システムごとに「守るべきレベル」を明確に分けることが、効率化の出発点になります。体制設計では、一次受付から本番適用までの役割分担を決めておきます。
担当者一人にすべてを背負わせると、その人が不在のときにシステムが止まるリスクが生まれます。したがって、最低でも二名以上で対応できる体制を組み、手順書を整えて、誰が対応しても同じ品質になるよう標準化することが、属人化を防ぐ最大のポイントです。体制づくりや内製と外注の使い分けについては、ITシステム保守管理の発注/外注/依頼/委託方法についての記事も参考にしてください。
保守作業の具体的な工程と手順
保守作業には、計画どおりに進めるべき明確な工程があります。とくに本番環境に手を加える保守は、一つの誤りが大きな障害につながるため、検証と承認の手順を踏むことが鉄則です。是正保守と予防保守、それぞれの代表的な工程を順に見ていきます。
是正保守（障害対応）の工程
障害が発生したときの是正保守は、スピードと正確さの両立が求められます。障害を検知して影響範囲を特定したら、まず被害の拡大を止めるため、サービスの切り離しや代替手段への切り替えといった暫定対応を最優先で行います。そのうえで、原因調査、恒久対策、本番適用と進み、再発防止策を記録に残します。
復旧時間の目標は、あらかじめ数値で決めておくべきです。たとえば、自治体の維持管理仕様書には、「障害発生時、再委託先は1時間以内に現地到着・対処を開始」「対応開始から1時間以内に内容と予想作業時間を報告」「初期報告から原則4時間以内に完全復旧」といった例があります。
こうした目標復旧時間を自社でも設定し、達成状況を測れば、保守品質を客観的に評価できます。さらに、すべての対応について「開始・終了時間、所要時間、原因、再発防止策」を記録として残すことを義務付ければ、ブラックボックス化の防止にもつながります。
予防保守・適応保守の検証と本番適用
予防保守や適応保守は緊急性こそ低いものの、本番環境への変更を伴うため、慎重な工程管理が必要です。経産省の「システム管理基準」では、保守プロセスは「保守計画の立案、変更内容の検証、本番への適用」という手続きを厳格に踏むよう求めています。具体的には、変更内容を検証環境（ステージング）で十分にテストし、問題がないことを確認したうえで、責任者の承認を得てから本番に適用します。
本番適用の際には、必ず切り戻し（ロールバック）の手順を用意しておきます。アップデート後に予期せぬ不具合が起きても、元の状態へ素早く戻せるようにしておくことで、業務停止のリスクを最小化できます。
加えて、変更前には必ずバックアップを取得し、適用後には動作確認を行うという基本動作を、手順書として定型化しておくことが大切です。こうした地道な工程管理の積み重ねが、システムの安定稼働を支えています。
保守管理の費用相場とコストの内訳
保守管理にかかる費用は、システムの規模や保守の手厚さによって大きく変わります。そのため、相場の目安とコストの内訳を知っておくと、見積もりの妥当性を判断しやすくなります。費用相場の考え方と、保守タイプによるコスト差を順に見ていきます。
保守費用の相場と「開発費の15〜20%」の根拠
ITシステムの年間保守費用は、一般的に「開発費の15〜20%」が相場とされています。たとえば、1,000万円で開発したシステムであれば、年間150万〜200万円程度が保守費用の目安です。金額の幅で見ると、小規模システムは年50万円程度から、大規模で複雑なシステムでは年800万円を超えることもあり、対象範囲やサービスレベルによって差が出ます。
この比率は便利な目安ですが、そのまま鵜呑みにすると危険です。システムが複雑であるほど、また外部連携やセキュリティ要件が厳しいほど、比率は上振れします。逆に、ドキュメントが整備され、構成がシンプルなシステムであれば、比率を抑えられます。
見積もりを受け取ったら、この比率から大きく外れていないか、外れている場合はなぜかを確認することで、妥当性を見極められます。保守費用の詳しい内訳や見積もりの判断基準は、ITシステム保守管理の見積相場や費用/コスト/値段についての記事で深掘りしています。
保守タイプ別のコスト差とランニングコスト
保守費用は保守のタイプによってもコスト構造が異なります。たとえば是正保守は障害の発生頻度に左右されるため、予測しにくい変動費の性格を持ちます。一方、予防保守や定期点検は、工数を見積もれる固定費として計画できます。長期的に見れば、予防保守へ投資して障害そのものを減らすほうが、突発的な是正保守の緊急対応コストを抑えられ、トータルコストは下がる傾向にあります。
保守費用の内訳は、主に人件費、監視ツールやライセンスの費用、インフラの利用料で構成されます。とくに人件費が大きな割合を占めるため、どこまでを人手で対応し、どこを自動化するかで、コストが大きく変わります。
監視ツールや運用自動化プラットフォームを導入すれば初期コストはかかりますが、削減できる人件費とのバランスを試算すれば、投資対効果を経営層へ示せます。さらに、ツール導入費と削減人件費を比較するROIの考え方を持っておくと、保守をコストセンターから価値ある投資へと位置づけ直せます。
保守管理を成功させるためのポイントと注意点
保守管理を計画どおりに進めても、落とし穴に注意しないと、品質やコストの問題が生じます。そこで、SLAによる品質の明文化、ブラックボックス化の解消、外注先の見極めという、実務で特に重要な3つのポイントを取り上げます。
SLAによる保守品質の数値化
保守品質を曖昧にしないために、SLA（サービスレベル合意）で具体的な数値を取り決めておくことが欠かせません。代表的な項目は、システムの稼働率（たとえば99.9%以上）、障害発生時の一次回答までの時間、目標復旧時間（RTO）、定期報告の頻度などです。こうして「できる限り早く対応する」のような曖昧な表現を避け、明確な数値で定義しておけば、提供側と発注側の認識のズレを防げます。
さらに踏み込むなら、SLAの未達時にどう対応するか、たとえば料金の減額や改善計画の提出といったペナルティ条項まで決めておくと、品質への責任が明確になります。また、SLAは運用状況に合わせて定期的に見直すことが大切です。
たとえば、稼働率が安定して高い水準にあれば基準を引き上げ、逆に頻繁に未達となる項目があれば、目標が現実的かどうかを再検討します。こうしたSLM（サービスレベル管理）のサイクルを回すことで、保守品質を継続的に高められます。
ブラックボックス化とレガシーの解消
長年運用されてきたシステムでは、当時の担当者がすでに退職し、仕様書も残っておらず、誰も中身を把握できないブラックボックス状態に陥っていることが珍しくありません。この状態のまま保守を続けると、ちょっとした改修にも過大なリスクが伴い、保守費用も高止まりします。
解消の第一歩は、現状のソースコードや設定からシステムの構造を読み解く、リバースエンジニアリングです。具体的には、稼働中のシステムのデータベース構造、画面遷移、処理ロジックを調査し、業務処理定義書やER図といったドキュメントへ落とし込んでいきます。
一度に全体を解明しようとすると膨大な工数がかかるため、障害が起きやすい箇所や今後改修の予定がある機能から、優先的にドキュメント化していくのが現実的です。こうして見える形にしていくことで、属人化を解消し、保守の品質と効率を底上げできます。
外注先の見極めとパートナー選び
自社のリソースだけで保守をまかないきれない場合は、外部のパートナーへ委託する選択肢が有効です。外注には、24時間365日の監視体制や高度な技術力を利用でき、情報システム部門をDXなどのコア業務に集中させられるというメリットがあります。一方で、任せきりにするとノウハウが社内に蓄積されず、ブラックボックス化が進むデメリットもあります。
これを防ぐには、対応範囲の明文化、ドキュメント整備の義務付け、定期報告の取り決めを、契約段階で固めておくことが欠かせません。外注先を見極める際は、提案書や見積もりの内容を丁寧に確認します。
保守の対象範囲や対応時間、エスカレーションの仕組みが具体的に書かれているか、複数名での対応体制が示されているか、過去の障害対応実績が語れるかが、信頼できるパートナーかどうかの判断材料になります。おすすめの開発会社やベンダーの比較はITシステム保守管理でおすすめの開発会社/ベンダー6選と選び方で、全体像をまとめて把握したい方はITシステム保守管理の完全ガイドをあわせてご覧ください。
まとめ
ITシステム保守管理の進め方は、まず是正・予防・適応・完全化、そして予測という保守の種類を理解し、それぞれを年間保守計画へ落とし込むことから始まります。場当たり的な是正保守に追われる状態から抜け出し、計画的な予防保守や予測保守へ移っていくことで、障害を減らし、コストを安定させ、担当者の負荷を軽くできます。
是正保守と予防保守それぞれの工程を標準化し、SLAで品質を数値化し、ブラックボックス化したシステムを着実にドキュメント化していくことが、保守管理を成功させる王道です。さらに、保守費用は開発費の15〜20%が一つの目安ですが、システムの複雑さやサービスレベルに応じて妥当性を見極めることが大切です。
自社だけで抱えきれない場合は、対応範囲の明文化やドキュメント整備の義務付けを前提に、信頼できるパートナーへの外注を検討するとよいでしょう。なお、riplaは、コンサルティングから開発・運用保守まで一気通貫で支援できる企業です。
IT事業会社として社内DXを推進してきた経験を活かし、システムを安定稼働させながらビジネスの成果につなげる保守管理の設計をお手伝いします。保守管理にお悩みの際は、ぜひお気軽にご相談ください。
▼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を創業。